Segmentation fault using ndpiReader on live capture.

[aouinizied]

We are facing a segmentation fault using npiReader (master) when running on live capture.
This happens in a random fashion (sometimes after hours and sometimes after minutes from startup).
We succeeded to reproduce using gdb with compilation optimization disabled in order to gather more informations as follows:

There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/.
Find the GDB manual and other documentation resources online at:
http://www.gnu.org/software/gdb/documentation/.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ndpiReader...done.
(gdb) r -i ens192f1 -t
Starting program: /home/pacman/nDPI/example/ndpiReader -i ens192f1 -t
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

---

• NOTE: This is demo app to show some nDPI features.
• In this demo we have implemented only some basic features
• just to show you what you can do with the library. Feel
• free to extend it and send us the patches for inclusion

---

Using nDPI (3.3.0-2382-39ae57e6) [1 thread(s)]
Capturing live traffic from device ens192f1...
[New Thread 0x7ffff7610700 (LWP 5309)]
Running thread 0...

Thread 2 "ndpiReader" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff7610700 (LWP 5309)]
0x00005555555ade36 in ndpi_strdup ()
(gdb) bt
#0 0x00005555555ade36 in ndpi_strdup ()
#1 0x00005555555ab070 in process_ndpi_collected_info (workflow=0x555555d35ed0, flow=0x7fffe37c2130) at reader_util.c:1096
#2 0x000055555559a171 in node_proto_guess_walker (node=, which=, depth=,
user_data=) at ndpiReader.c:1337
#3 0x000055555559a284 in node_idle_scan_walker (node=, which=, depth=,
user_data=) at ndpiReader.c:1761
#4 0x00005555555c0aca in ndpi_trecurse ()
#5 0x00005555555c0ae3 in ndpi_trecurse ()
#6 0x00005555555c0b0c in ndpi_trecurse ()
#7 0x00005555555c0ae3 in ndpi_trecurse ()
#8 0x00005555555c0b0c in ndpi_trecurse ()
#9 0x00005555555c0fb0 in ndpi_twalk ()
#10 0x00005555555a6738 in ndpi_process_packet (args=, header=0x7ffff760fba0, packet=0x7ffff7686086 "")
at ndpiReader.c:2804
#11 0x00007ffff7d89616 in ?? () from /lib/x86_64-linux-gnu/libpcap.so.0.8
#12 0x00007ffff7d8a2c4 in ?? () from /lib/x86_64-linux-gnu/libpcap.so.0.8
#13 0x00007ffff7d920cd in pcap_loop () from /lib/x86_64-linux-gnu/libpcap.so.0.8
#14 0x000055555559a0a4 in runPcapLoop (thread_id=) at ndpiReader.c:2906
#15 0x000055555559a7f9 in processing_thread (_thread_id=0x0) at ndpiReader.c:2961
#16 0x00007ffff7d69fa3 in start_thread (arg=) at pthread_create.c:486
#17 0x00007ffff79794cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
(gdb)

Best regards,
Zied

[lucaderi]

please provide a core dump with debug info as what you put above is not enough

[aouinizied]

@lucaderi We restart it and will upload the core file once reproduced.
with -g -O0 this will include all required debug information, right?

[aouinizied]

@lucaderi Done. Please find here the core file + full gdb log.
http://pekar.s.cnl.sk/debug/

[aouinizied]

Update. The one referred first was dumped here and seems to come from ndpi_strdup
http://pekar.s.cnl.sk/debug/4148c5e065d32128eea17c0e228e372ad72eef82

New commits results in other segfault which are more systematically and looks coming from TLS dissectors and are refered by their commit hash within the shared directory.

[utoni]

It would be nice to have a pcap file to reproduce this SIGSEGV.

[aouinizied]

@lnslbrty Sorry for delayed answer. But such behavior was obtained using live capture on a campus network. It was happening from time to time (random behavior) so we were unable to get a correspnding pcap capture.

[utoni]

I'm not sure, but it may possible that the issue is related to the strlen function call in ndpi_strdup, which wants a \0 terminated string. This assumption is dangerous especially in the networking business.

[aouinizied]

@lnslbrty Indeed I fixed it in the Python part by evicting the call to ndpi_strdup.