--- Comment #6 from ---
A commit references this bug:

Author: asomers
Date: Mon Apr 16 16:33:36 UTC 2018
New revision: 332609

  MFC r330710, r330718-r330720

  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

  Fix this bug by closing the file as soon as receipt is finished.

  PR:                   157700
  Reported by:          Barry Mishler <>

  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

  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

  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

  PR:           226005

_U  stable/11/

You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________ mailing list
To unsubscribe, send any mail to ""

Reply via email to