Re: Buffer overwrites with pcap_next_ex

[Guy Harris <guy () alum mit edu>]

On Jan 25, 2009, at 2:05 AM, Andreas Rieke wrote:

> I have forgotten to mention that I use libpcap 1.0.0.

...which means that, at least on Linux, libpcap's probably using the  
memory-mapped interface...

> Since I placed a debug output before and after each call to pcap, I am
> very sure that no pcap functions are called - especially not those you
> mention.

...and:

	in the memory-mapped interface, each packet in the buffer shared  
between the kernel and userland has a status flag indicating, among  
other things, to whom the packet "belongs";

	when the callback for a packet returns, the packet is marked as  
belonging to the kernel, which means the kernel can reuse that space  
in the shared buffer;

	pcap_next() and pcap_next_ex() use pcap_dispatch() plus a callback  
which fills in pointers to the packet header and the packet data, and  
then, after pcap_dispatch() returns (which means the callback routine  
has returned), returns.

This means that, with the memory-mapped interface, the packet is  
subject to being overwritten by the kernel after pcap_next() or  
pcap_next_ex() returns.

This is probably fixable only by releasing the packet to the kernel  
before we call the callback for the *next* packet rather than after  
the callback for *that* packet returns.

For now, the workaround would be not to use pcap_next() or  
pcap_next_ex(), but to use pcap_loop() or pcap_dispatch(), and not to  
assume that you can do anything with the packet data once your  
callback returns.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.