Bug 25503
| Summary: | readudp() in libstand(3) can return incorrect packet lengths | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | jbrowne <jbrowne> | ||||
| Component: | misc | Assignee: | freebsd-bugs (Nobody) <bugs> | ||||
| Status: | Closed FIXED | ||||||
| Severity: | Affects Only Me | ||||||
| Priority: | Normal | ||||||
| Version: | Unspecified | ||||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| Attachments: |
|
||||||
State Changed From-To: open->closed Patches applied; thanks for the fix! |
I noticed that readudp() in libstand(3) returns the UDP packet length to the caller by taking the length of the packet from the netif device and subtracting the size of a UDP and IP header. If the netif interface is unable to strip link-level padding bytes, those extra bytes will be incorrectly passed on to the caller. I noticed this problem because my netif driver which works with LANCE style chips is unable to strip Ethernet padding bytes on short Ethernet frames since it has no way to determine the true length of the Ethernet frame and since the LANCE chip does not strip padding bytes on short Ethernet frames. So, if the UDP packet was less than 46 bytes long, up to 14 Ethernet padding bytes could be passed up by the netif driver. readudp() was happily passing those extra bytes on to TFTP which meant that TFTP files whose length satisfied: ((length % 512) < 14) would have the incorrect length (up to 14 bytes longer) when TFTPd. Also, the shortest valid TFTP packet is 4 bytes, not 8. A patch to fix the problem is included below. Fix: bash-2.04$ grep \$FreeBSD /usr/src/lib/libstand/tftp.c * $FreeBSD: src/lib/libstand/tftp.c,v 1.2.6.2 2000/05/04 13:47:52 ps Exp $ bash-2.04$ grep \$FreeBSD /usr/src/lib/libstand/udp.c * $FreeBSD: src/lib/libstand/udp.c,v 1.1.2.1 2000/04/15 03:09:29 ps Exp $ bash-2.04$ diff -c2p /usr/src/lib/libstand/tftp.c /tmp/tftp.c