pcap file not written to disk for ring size 5GiB

[tklauser]

Reported by Michal Purzynski (see http://article.gmane.org/gmane.linux.network.netsniff-ng/519 for details)

I've tried to run netsniff-ng with 5GB of ring size, it started but it's 
not writing anything to disk.

3GB buffer size - everything works.

root <at> nsm1:~# ./netsniff-ng -i eth2 -o 
/nsm/sensor_data/nsm1-eth2/dailylogs/2014-04-30/ --user 2551 --group 
2551 -s --prefix snort.log. --verbose --ring-size 3GiB --interval 
1500MiB --mmap --filter /etc/nsm/nsm1-eth2/bpf-pcap.ops
pcap file I/O method: mmap
RX,V3: 3072.00 MiB, 49152 Blocks, each 65536 Byte allocated
Running! Hang up with ^C!

.(+1525530/-128792).(+1205512/-0).(+948890/-0).(+1171243/-0).(+953868/-0).(+1132016/-0).(+1027858/-0).(+1096132/-0).(+1082889/-0)^C

Cannot set NIC flags!

But with 5GB buffer

root <at> nsm1:~# ./netsniff-ng -i eth2 -o 
/nsm/sensor_data/nsm1-eth2/dailylogs/2014-04-30/ --user 2551 --group 
2551 -s --prefix snort.log. --verbose --ring-size 5GiB --interval 
1500MiB --mmap --filter /etc/nsm/nsm1-eth2/bpf-pcap.ops
pcap file I/O method: mmap
RX,V3: 5120.00 MiB, 81920 Blocks, each 65536 Byte allocated
Running! Hang up with ^C!

.(+1436563/-142770)

^^ no further statistics is printed, netsniff-ng isn't writing to disk

rw-r--r-- 1 sguil sguil 1.8G Apr 30 19:14 snort.log.1398885248.pcap

root <at> nsm1:/nsm/sensor_data/nsm1-eth2/dailylogs/2014-04-30# date

Wed Apr 30 19:18:09 UTC 2014

The last file is from a few minutes before, data were last written with 
the 3GB buffer.

[tklauser]

I currently suspect an integer overflow related to the mmap size (of the pcap file).

[expressoCoder]

I believe this issue may be caused by kernel security patch to net/patacket/af_packet.c. The patch has been backported to older kernels. It will prevent you from allocating a ring buffer greater than 4 GiB. The largest you can get is --ring-size 4194303KiB (2^32 - 1024 bytes).

https://googleprojectzero.blogspot.com/2017/05/exploiting-linux-kernel-via-packet.html https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-7308