Re: [PATCH 3.12 32/64] unix: properly account for FDs passed over unix sockets

[Willy Tarreau]

On Fri, Feb 12, 2016 at 09:45:22AM +0100, Philipp Hahn wrote:
> 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@xxxxxx>
> >>>
> >>> 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@xxxxxxxxx
> >>> Reported-by: Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx>
> >>> Mitigates: CVE-2013-4312 (Linux 2.0+)
> >>> Suggested-by: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
> >>> Acked-by: Hannes Frederic Sowa <hannes@xxxxxxxxxxxxxxxxxxx>
> >>> Signed-off-by: Willy Tarreau <w@xxxxxx>
> >>> Signed-off-by: David S. Miller <davem@xxxxxxxxxxxxx>
> >>> Signed-off-by: Jiri Slaby <jslaby@xxxxxxx>
> >>
> >> 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.

It was not the only issue reported, as I remember there is a possibility
that for processes having to pass FDs from one socket to another (eg:
dbus), the wrong user could be credited. I don't remember the exact
detail but since the fix is pending and the current patch fixes an
issue which is as old as kernel 2.0 or so, there's no need to rush it
into stable kernels.

Willy