Bug 178055
| Summary: | tftp / tftpd file transfer ends up with incorrect size | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | Richard <rsitze> | ||||
| Component: | bin | Assignee: | Alan Somers <asomers> | ||||
| Status: | Closed FIXED | ||||||
| Severity: | Affects Only Me | CC: | asomers | ||||
| Priority: | Normal | Flags: | asomers:
mfc-stable11+
asomers: mfc-stable10+ |
||||
| Version: | Unspecified | ||||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| Attachments: |
|
||||||
|
Description
Richard
2013-04-22 18:20:00 UTC
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped Reproducible on FreeBSD 12. The problem isn't the file's size; it's got to do with the netascii encoding. If a transfer block ends with CR, tftpd erroneously omits the leading NUL from the following transfer block. I have a fix for that. However, what I don't understand is why the bug doesn't occur more often. Sometimes tftp is able to correctly decode the incorrectly-encoded packets, and sometimes it isn't. I don't know why but I've already spent too much time trying to figure it out, so I'm just going to fix the bug in the server instead. Created attachment 196452 [details]
A reproduction case
This is the smallest file I could craft that triggers the bug. extract it, then transfer it in netascii mode. One NUL byte will be dropped at about the halfway point.
A commit references this bug: Author: asomers Date: Wed Aug 22 23:31:28 UTC 2018 New revision: 338216 URL: https://svnweb.freebsd.org/changeset/base/338216 Log: tftpd: Fix data corruption bug with netascii Transferring files in netascii format requires, among other things, translating all CR characters to a CR,NUL pair. tftpd does this correctly except when the CR occurs as the last octet of a packet. In that case, it erroneously drops the NUL which should be part of the following packet. The bug was caused by using 0 as a sentinel value in a variable that could legitimately hold 0. Fix it by switching the sentinel value to -1. PR: 178055 Reported by: Richard <rsitze@gmail.com> Reviewed by: cem MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D16853 Changes: head/libexec/tftpd/tftp-file.c A commit references this bug: Author: asomers Date: Mon Oct 1 16:04:07 UTC 2018 New revision: 339057 URL: https://svnweb.freebsd.org/changeset/base/339057 Log: MFC r338216: tftpd: Fix data corruption bug with netascii Transferring files in netascii format requires, among other things, translating all CR characters to a CR,NUL pair. tftpd does this correctly except when the CR occurs as the last octet of a packet. In that case, it erroneously drops the NUL which should be part of the following packet. The bug was caused by using 0 as a sentinel value in a variable that could legitimately hold 0. Fix it by switching the sentinel value to -1. PR: 178055 Reported by: Richard <rsitze@gmail.com> Reviewed by: cem Differential Revision: https://reviews.freebsd.org/D16853 Changes: _U stable/11/ stable/11/libexec/tftpd/tftp-file.c A commit references this bug: Author: asomers Date: Mon Oct 1 16:11:09 UTC 2018 New revision: 339062 URL: https://svnweb.freebsd.org/changeset/base/339062 Log: MFC r338216: tftpd: Fix data corruption bug with netascii Transferring files in netascii format requires, among other things, translating all CR characters to a CR,NUL pair. tftpd does this correctly except when the CR occurs as the last octet of a packet. In that case, it erroneously drops the NUL which should be part of the following packet. The bug was caused by using 0 as a sentinel value in a variable that could legitimately hold 0. Fix it by switching the sentinel value to -1. PR: 178055 Reported by: Richard <rsitze@gmail.com> Reviewed by: cem Differential Revision: https://reviews.freebsd.org/D16853 Changes: _U stable/10/ stable/10/libexec/tftpd/tftp-file.c |
