Bug 150176 - [libpcap] [patch] pcap(3): pcap_read_bpf() p->cc can go negative
Summary: [libpcap] [patch] pcap(3): pcap_read_bpf() p->cc can go negative
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: Unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs mailing list
Depends on:
Reported: 2010-09-01 09:00 UTC by guy
Modified: 2018-01-03 05:13 UTC (History)
0 users

See Also:

file.diff (1.32 KB, patch)
2010-09-01 09:00 UTC, guy
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description guy 2010-09-01 09:00:10 UTC
In pcap_read_bpf(), ep is set based on the return value of read(), but read() from a BPF device doesn't necessarily return a value that's a multiple of the alignment value for BPF_WORDALIGN().  However, whenever we increment bp, we round up the increment value by a value rounded up by BPF_WORDALIGN(), so we could increment bp past ep after processing the last packet in the buffer.

Fix: Patch attached with submission follows:
How-To-Repeat: Run a program that opens a capture device with a timeout of 0, in a loop, calls pcap_dispatch() with a cnt argument of 1, and reports when it returns a value of 0.  The timeout of 0 means that the read() that libpcap does shouldn't return until there's packet data, so a timeout won't cause pcap_dispatch() to return 0.  Do a large amount of network data transfer, to fill up the BPF bucket; notice that, on occasion, the program will report that pcap_dispatch() returns 0.
Comment 1 guy 2010-09-01 09:15:38 UTC
(Note: that's a patch to tcpdump.org's libpcap on the trunk, but it =
looks as if it applies to top-of-tree FreeBSD as well, albeit with an =
Comment 2 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 07:59:28 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