phaag / nfdump

Netflow processing tools
Other
770 stars 202 forks source link

Segmentation fault while processing some packets (fragments?) #555

Closed Enrico204 closed 1 month ago

Enrico204 commented 1 month ago

I am processing a large PCAP with nfpcapd, and I encountered a segmentation fault (I tested the 1.7.1 from Debian, the 1.7.4 and master from source). After some digging, I was able to pinpoint the crash to the line:

https://github.com/phaag/nfdump/blob/56c7ddf3c5d3899759d71c6853ee98cdf9e1dcd5/src/nfpcapd/pcaproc.c#L357

Apparently, Node->payload can be NULL (or, at least, it is for one node). Unfortunately, I don't have many details as I was busy, and I tried to work around the problem anyway. I know that both frag_offset and len are not zero, and also dataptr is pointing to something (not NULL).

I tested the code adding the allocation when the payload is NULL, and it is working (see https://github.com/phaag/nfdump/commit/4eaad6b9c99153afaa4b9c3d6f3794cb5a408130 ).

    if (!Node->payload) {
        // allocate enough memory for packet
        Node->payload = calloc(1, 65536);
    }

However, by looking at the code in the function, there should be no way for the payload field to be NULL, unless the Node is inserted/modified elsewhere and the payload is not allocated/freed.

I will reproduce the problem and (hopefully) have the gdb backtrace after finishing importing the PCAP. With that, I will try to pinpoint the exact packet that triggers the segfault, so that I can provide some information to reproduce the issue.


Edit: here the gdb backtrace of the latest master:

Thread 3 "nfpcapd" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffed4f66c0 (LWP 2709138)]
__memcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:233
233     ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S: No such file or directory.
(gdb) bt
#0  __memcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:233
#1  0x000055555555e8b5 in ProcessIPfrag (packetParam=, hdr=, ip=, eodata=) at pcaproc.c:357
#2  0x00005555555604b0 in ProcessPacket (packetParam=, hdr=, data=) at pcaproc.c:899
#3  0x000055555555d05a in pcap_packet_thread (args=) at packet_pcap.c:283
#4  0x00007ffff7dba134 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
#5  0x00007ffff7e3a7dc in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
phaag commented 1 month ago

Thanks for the report! Looks like, there is an issue in the defragmenting code, when the first fragment is missing or out of order. I would very much appreciate, if you could send my the pcap in question, or at least that part with the fragmented packets. You can send it to the email in the authors file.

Enrico204 commented 1 month ago

I was able to isolate the fragments that are responsible for the crash, and I can consistently replicate the crash. I am sending the PCAP via e-mail now :-)