From owner-freebsd-bugs@freebsd.org Mon Apr 16 16:34:44 2018 Return-Path: Delivered-To: freebsd-bugs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 13763F91A75 for ; Mon, 16 Apr 2018 16:34:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 95F3072DF2 for ; Mon, 16 Apr 2018 16:34:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 52D13F91A74; Mon, 16 Apr 2018 16:34:43 +0000 (UTC) Delivered-To: bugs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2A672F91A73 for ; Mon, 16 Apr 2018 16:34:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B6B4D72DEE for ; Mon, 16 Apr 2018 16:34:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id E89A21C71A for ; Mon, 16 Apr 2018 16:34:41 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w3GGYfbh030988 for ; Mon, 16 Apr 2018 16:34:41 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w3GGYfKk030987 for bugs@FreeBSD.org; Mon, 16 Apr 2018 16:34:41 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 157700] tftpd(8) in 8.2-RELEASE expects more data after EOF Date: Mon, 16 Apr 2018 16:34:42 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 8.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 16:34:44 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D157700 --- Comment #6 from commit-hook@freebsd.org --- A commit references this bug: Author: asomers Date: Mon Apr 16 16:33:36 UTC 2018 New revision: 332609 URL: https://svnweb.freebsd.org/changeset/base/332609 Log: MFC r330710, r330718-r330720 r330710: tftpd: Flush files as soon as they are fully received On an RRQ, tftpd doesn't exit as soon as it's finished receiving a file. Instead, it waits five seconds just in case the client didn't receive the server's last ACK and decides to resend the final DATA packet. Unfortunately, this created a 5 second delay from when the client thinks it's done sending the file, and when the file is available for other processes. Fix this bug by closing the file as soon as receipt is finished. PR: 157700 Reported by: Barry Mishler r330718: tftpd: Verify world-writability for WRQ when using relative paths tftpd(8) says that files may only be written if they already exist and are publicly writable. tftpd.c verifies that a file is publicly writable if = it uses an absolute pathname. However, if the pathname is relative, that ch= eck is skipped. Fix it. Note that this is not a security vulnerability, because the transfer ultimately doesn't work unless the file already exists and is owned by us= er nobody. Also, this bug does not affect the default configuration, because the default uses the "-s" option which makes all pathnames absolute. PR: 226004 r330719: tftpd: Abort on an WRQ access violation On a WRQ (write request) tftpd checks whether the client has access permission for the file in question. If not, then the write is prevented. However, tftpd doesn't reply with an ERROR packet, nor does it abort. Instead, it tries to receive the packet anyway. The symptom is slightly different depending on the nature of the error. = If the target file is nonexistent and tftpd lacks permission to create it, t= hen tftpd will willingly receive the file, but not write it anywhere. If the file exists but is not writable, then tftpd will fail to ACK to WRQ. PR: 225996 r330720: tftpd: reject unknown opcodes If tftpd receives a command with an unknown opcode, it simply exits 1. It doesn't send an ERROR packet, and the client will hang waiting for one. = Fix it. PR: 226005 Changes: _U stable/11/ stable/11/libexec/tftpd/tests/functional.c stable/11/libexec/tftpd/tftp-transfer.c stable/11/libexec/tftpd/tftpd.c stable/11/usr.bin/tftp/tftp.c --=20 You are receiving this mail because: You are the assignee for the bug.=