[DragonFlyBSD - Bug #1816] (Closed) p->cc can go negative in libpcap

[bugtracker-admin at leaf.dragonflybsd.org]

Issue #1816 has been updated by tuxillo.

Description updated
Status changed from New to Closed
% Done changed from 0 to 100

Already fixed some 12 years ago in this commit:

https://github.com/the-tcpdump-group/libpcap/commit/b26d8d2aa849c8021cdfa872901e82fb469460ef

We have a version that has the fix.



----------------------------------------
Bug #1816: p->cc can go negative in libpcap
http://bugs.dragonflybsd.org/issues/1816#change-14273

* Author: guy
* Status: Closed
* Priority: Normal
* Assignee: sjg
* Target version: 6.4
----------------------------------------
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.

This can be reproduced by running 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.

See the attached patch, which also fixes a case where, if you break out of the packet read loop due to a pcap_breakloop() call, p->bp isn't advanced and p->cc isn't reduced.

---Files--------------------------------
patch.txt (1.18 KB)


-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account