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
| ||
|
Date: Fri, 14 Dec 2018 16:58:28 -0800 (PST) From: David Miller <davem@...emloft.net> To: ap420073@...il.com Cc: netdev@...r.kernel.org, daniel@...earbox.net, ast@...nel.org Subject: Re: [PATCH net 1/2] net: bpfilter: restart bpfilter_umh when error occurred From: Taehee Yoo <ap420073@...il.com> Date: Wed, 12 Dec 2018 10:19:26 +0900 > When bpfilter error occurred bpfilter_umh will be stopped via __stop_umh(). > The bpfilter_umh() couldn't start again because there is no restart > routine. > > The section of bpfilter_umh_{start/end} is no longer .init.rodata > because these area should be reused in the restart routine. hence > the section name is changed to .bpfilter_umh. > > Test commands: > $ iptables -vnL > $ kill -9 <pid of bpfilter_umh> > $ iptables -vnL > [ 480.045136] bpfilter: write fail -32 > > $ iptables -vnL > iptables v1.8.1 (legacy): can't initialize iptables table `filter': No child processes > Perhaps iptables or your kernel needs to be upgraded. > > Then, iptables command is always failed. > > Fixes: d2ba09c17a06 ("net: add skeleton of bpfilter kernel module") > Signed-off-by: Taehee Yoo <ap420073@...il.com> Thank you for this fix, but I am unsure if this is a complete solution. First of all, you can only kill the bpfilter_umh as root right? It is a big problem to allow the userspace to kill the umh program because that will result in the pipes being leaked. Normally the kernel takes down bpfilter_umh and calls fput() on the pipe file descriptors via shutdown_umh(). In the kill -9 example above, that does not happen and that is why we get the fd leak. In this situation it will not reset info->pid to zero, and it also will leave bpfilter_process_socktop non-NULL. Therefore, it seems like the kernel has to perform these cleanup actions if the bpfilter_umh process dies (from kill -9, or just crashing). And I think if you manage that properly it will fix this bug too.
Powered by blists - more mailing lists