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: Tue, 14 Nov 2017 15:47:20 +0900 (KST) From: David Miller <davem@...emloft.net> To: vvs@...tuozzo.com Cc: netdev@...r.kernel.org, steffen.klassert@...unet.com, linux-nfs@...r.kernel.org, trond.myklebust@...marydata.com, anna.schumaker@...app.com, courmisch@...il.com, linux-ppp@...r.kernel.org, paulus@...ba.org, herbert@...dor.apana.org.au, yoshfuji@...ux-ipv6.org Subject: Re: [PATCH v5 00/13] exit_net checks for objects initialized in net_init hook From: Vasily Averin <vvs@...tuozzo.com> Date: Sun, 12 Nov 2017 22:26:44 +0300 > OpenVz kernel team have a long history of fighting against namespace-related bugs, > some of them could be prevented by using simple checks described below. > > One of typical errors is related to live cycle of namespaces: > usually objects created for some namespace should not live longer than namespace itself. > > Such kind of issues can be invisible on usual systems where additional namespaces > are not used, because initial namespaces usually lives forever and never destroyed. > > However in systems with namespaces it can lead to memory leaks or to use-after-free. > Both of them are critical for systems with running containers. > As you knows it's quite hard to find the reason of such issues, > especially in rarely-triggered scenarios on production nodes on default kernels > without specially enabled debug settings. Any additional hints can be useful here. > > This patch set should help to detect some of these issues. > It is based on assumption that objects initialized in init hook of pernet_operations > should return to initial state until end of exit hook. > > Many drivers and subsystems already have such checks, however I've found number > of places where list_empty check would be useful at least as smoke test. > > These checks are useful for long-term stable kernels, > they allows to detect problems related to incomplete or incorrectly > backported patches. All applied to net-next except patch #9 and #10 which need to go via the NFS maintainer.
Powered by blists - more mailing lists