[Bug 157700] tftpd(8) in 8.2-RELEASE expects more data after EOF

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=157700

--- Comment #6 from commit-hook at 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 <barry_mishler at yahoo.com>

  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 check
  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 user
  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, then
  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

-- 
You are receiving this mail because:
You are the assignee for the bug.