| 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
| ||
|
Message-ID: <56BD9BA2.2060706@pmhahn.de> Date: Fri, 12 Feb 2016 09:45:22 +0100 From: Philipp Hahn <pmhahn@...ahn.de> To: Jiri Slaby <jslaby@...e.cz>, Willy Tarreau <w@....eu> Cc: stable@...r.kernel.org, linux-kernel@...r.kernel.org, "David S . Miller" <davem@...emloft.net>, Hannes Frederic Sowa <hannes@...essinduktion.org> Subject: Re: [PATCH 3.12 32/64] unix: properly account for FDs passed over unix sockets Am 12.02.2016 um 08:57 schrieb Jiri Slaby: > On 02/11/2016, 06:32 PM, Willy Tarreau wrote: >> On Thu, Feb 11, 2016 at 02:59:08PM +0100, Jiri Slaby wrote: >>> From: willy tarreau <w@....eu> >>> >>> 3.12-stable review patch. If anyone has any objections, please let me know. >>> >>> =============== >>> >>> [ Upstream commit 712f4aad406bb1ed67f3f98d04c044191f0ff593 ] >>> >>> It is possible for a process to allocate and accumulate far more FDs than >>> the process' limit by sending them over a unix socket then closing them >>> to keep the process' fd count low. >>> >>> This change addresses this problem by keeping track of the number of FDs >>> in flight per user and preventing non-privileged processes from having >>> more FDs in flight than their configured FD limit. >>> >>> Reported-by: socketpair@...il.com >>> Reported-by: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp> >>> Mitigates: CVE-2013-4312 (Linux 2.0+) >>> Suggested-by: Linus Torvalds <torvalds@...ux-foundation.org> >>> Acked-by: Hannes Frederic Sowa <hannes@...essinduktion.org> >>> Signed-off-by: Willy Tarreau <w@....eu> >>> Signed-off-by: David S. Miller <davem@...emloft.net> >>> Signed-off-by: Jiri Slaby <jslaby@...e.cz> >> >> A possible issue was reported regarding this patch, and Hannes >> implemented a fix that's not yet in mainline. I guess it's >> preferable to postpone this patch for now. > > yes definitely. Thanks for noting. Yes and no: the above mentioned patch looks innocent now after more bisecting, but there is <https://patchwork.ozlabs.org/patch/577653/> as a folow-up to the FD-accounting. > For reference: > http://article.gmane.org/gmane.linux.kernel/2142236 Better read the full thread: <http://thread.gmane.org/gmane.linux.kernel/2142236>; the suspected bad patch is unix: avoid use-after-free in ep_remove_wait_queue Philipp
Powered by blists - more mailing lists