netdev - bpfilter causes a leftover kernel process

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 26 Aug 2018 18:08:16 +0200
From:   Olivier Brunel <jjk@...cky.com>
To:     netdev@...r.kernel.org
Subject: bpfilter causes a leftover kernel process

Hi,

(Please cc me as I'm not subscribed to the list, thanks.)

I'm running an Arch Linux x86_64 system, and recently updated to a 3.18
kernel, which led me to encounter what I believe to be a kernel bug
related to the bpfilter framework.

What happens is that upon boot, there's a "leftover kernel process"
running (shown as "[none]" in ps), which doesn't seem to do anything
(anymore) but does have references/fds open to the root fs, and so when
trying to shutdown the system umounting the root fs fails (EBUSY)
because of it, leading to expected issues.

Simply killing that process allows umounting the root fs fine and
"resolves" all issues. This process/behavior wasn't there with any
previous kernel, and is there with all tried kernels from 4.18.0 to
4.18.4, without any other change to the system -- although this is due
to CONFIG_BPFILTER=y in the kernel config.

Indeed I managed to compile a kernel 4.18.4 myself using the Arch Linux
config[1] with a single change of unsetting CONFIG_BPFILTER, and with
the resulting kernel I don't have this "leftover kernel process"
anymore, everything is back to normal.

Now, about this process, here's a few outputs to try and describe what
it is:

rafus# pgrep none
920

rafus# cd /proc/920

rafus# readlink exe
/ (deleted)

rafus# ls -l fd
total 0
lr-x------ 1 root root 64 Aug 26 17:17 0 -> 'pipe:[13366]'
l-wx------ 1 root root 64 Aug 26 17:17 1 -> 'pipe:[13367]'
lrwx------ 1 root root 64 Aug 26 17:17 2 -> /dev/console

rafus# cat status
Name:	none
Umask:	0022
State:	S (sleeping)
Tgid:	920
Ngid:	0
Pid:	920
PPid:	2
TracerPid:	0
Uid:	0	0	0	0
Gid:	0	0	0	0
FDSize:	64
Groups:	 
NStgid:	920
NSpid:	920
NSpgid:	0
NSsid:	0
VmPeak:	    2296 kB
VmSize:	    2296 kB
VmLck:	       0 kB
VmPin:	       0 kB
VmHWM:	     748 kB
VmRSS:	     748 kB
RssAnon:	      60 kB
RssFile:	     684 kB
RssShmem:	       4 kB
VmData:	     176 kB
VmStk:	     132 kB
VmExe:	       8 kB
VmLib:	    1452 kB
VmPTE:	      44 kB
VmSwap:	       0 kB
HugetlbPages:	       0 kB
CoreDumping:	0
Threads:	1
SigQ:	0/7861
SigPnd:	0000000000000000
ShdPnd:	0000000000000000
SigBlk:	0000000000000000
SigIgn:	0000000000000000
SigCgt:	0000000000000000
CapInh:	0000000000000000
CapPrm:	0000003fffffffff
CapEff:	0000003fffffffff
CapBnd:	0000003fffffffff
CapAmb:	0000000000000000
NoNewPrivs:	0
Seccomp:	0
Speculation_Store_Bypass:	vulnerable
Cpus_allowed:	1
Cpus_allowed_list:	0
Mems_allowed:	00000001
Mems_allowed_list:	0
voluntary_ctxt_switches:	65
nonvoluntary_ctxt_switches:	1

rafus# cat stack
[<0>] pipe_wait+0x6c/0xb0
[<0>] pipe_read+0x20a/0x2d0
[<0>] __vfs_read+0x13a/0x180
[<0>] vfs_read+0x8a/0x130
[<0>] ksys_read+0x4f/0xb0
[<0>] do_syscall_64+0x5b/0x170
[<0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[<0>] 0xffffffffffffffff

rafus# file -L exe
exe: ELF 64-bit LSB pie executable x86-64, version 1 (SYSV),
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for
GNU/Linux 3.2.0,
BuildID[sha1]=b247cedd3f8daaea3eee38477aa641d84b77f0ba, not stripped

rafus# stat -L exe
  File: exe
  Size: 16832     	Blocks: 40         IO Block: 4096   regular
file Device: 1h/1d	Inode: 13361       Links: 0
Access: (0777/-rwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2018-08-26 17:17:37.334261924 +0200
Modify: 2018-08-26 17:14:27.787595262 +0200
Change: 2018-08-26 17:14:27.787595262 +0200
 Birth: -

rafus# sha1sum exe
723d59584abe5e1e9917f0ec41d7e9120514afe7  exe

rafus# strings exe|grep bpf
Started bpfilter

I'm not actually sure what the process is, I'm guessing some kind of
helper is spawned at some point during boot, and for some reason it
never ends.

Although I can reproduce it (it happens on every boot with a kernel
4.18 and CONFIG_BPFILTER=y), I'm unfortunately not sure what is
actually needed to be done in order to trigger it.
I don't use bpfilter myself/directly, as said this happens with the
exact same system as with previous kernels, but I obviously have some
network configuration (done using iptables/iproute2) set up during boot.

Let me know if you need more information or need me to test things, and
I'll do my best.

Thank you.

[1]
https://git.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/linux