lsof segfaults in FreeBSD jails

[utrenkner]

Describe the bug

Earlier this month, I started to see segfaults of lsof in several FreeBSD jails. This was after updating both, the operating system to the latest patchlevel and also the lsof package.

The segmentation fault occurs, when security/rkhunter checks for possibly malicious open ports.

To Reproduce

This is an example of the lsof use by rkhunter which leads to a segmentation fault:

/usr/local/sbin/lsof -wnlP -i TCP:65535

Program output

lsof: kvm_open(execfile=/boot/kernel/kernel, corefile=/dev/mem): Invalid argument
Segmentation fault

Note, the Invalid argument can be observed in all of my jails. However, not in all of them does this lead to a segmentation fault.

Expected behavior

No segmentation fault.

Environment (please complete the following information):

OS: FreeBSD 13.1-RELEASE-p2
lsof: 4.96.4
package (from official FreeBSD quarterly repo): version 4.96.4,8

[lrosenman]

I poked the FreeBSD developers.

[emaste]

Can you get a backtrace, either lldb -core <corefile> or lldb /usr/local/sbin/lsof -- -wnlP -i TCP:65535

[utrenkner]

This is the the output of lldb:

Process 5499 launched: '/usr/local/sbin/lsof' (x86_64)
lsof: kvm_open(execfile=/boot/kernel/kernel, corefile=/dev/mem): Invalid argument
Process 5499 stopped
* thread #1, name = 'lsof', stop reason = signal SIGSEGV: address access protected (fault address: 0x8011afffb)
    frame #0: 0x0000000823e1db5f libc.so.7`memmove + 607
libc.so.7`memmove:
->  0x823e1db5f <+607>: rep    movsq	(%rsi), %es:(%rdi)
    0x823e1db62 <+610>: cld    
    0x823e1db63 <+611>: movq   %rdx, %rcx
    0x823e1db66 <+614>: andb   $0x7, %cl

I hope, this is what you were looking for (I have never used lldb before and had to find a howto to understand how to make lldb do something useful).

[BenBE]

@utrenkner Can you try to also extract a backtrace from the crash? Just having the crash location itself usually is just part of the necessary information as you e.g. need to know which copy/move operation exactly caused the crash. Something like bt all should give this information, cf. here.

[utrenkner]

Here is the full backtrace:

* thread #1, name = 'lsof', stop reason = signal SIGSEGV: address access protected (fault address: 0x8006b4ff9)
  * frame #0: 0x000000082248bb5f libc.so.7`memmove + 607
    frame #1: 0x0008244151800000
    frame #2: 0x000000000020c2c4 lsof`___lldb_unnamed_symbol243 + 1700
    frame #3: 0x0000000000213269 lsof`___lldb_unnamed_symbol271 + 8169
    frame #4: 0x000000000020a420 lsof`___lldb_unnamed_symbol354 + 256