pipe() resource exhaustion

[Konstantin Belousov]

On Tue, Apr 08, 2014 at 02:12:22PM +0200, Mateusz Guzik wrote:
> On Tue, Apr 08, 2014 at 01:02:06PM +0200, Eduardo Morras wrote:
> > On Mon, 7 Apr 2014 07:25:22 -0500
> > Mark Felder <feld at freebsd.org> wrote:
> > 
> > > On 2014-04-07 06:02, Ivan Voras wrote:
> > > > Hello,
> > > > 
> > > > Last time I mentioned this it didn't get any attention, so I'll try
> > > > again. By accident (via a buggy synergy server process) I found
> > > > that a simple userland process can exhaust kernel pipe memory 
> > > > (kern.ipc.pipekva
> > > > sysctl) which as a consequence has that new processes which use pipe
> > > > cannot be started, which includes "su", by which an administrator
> > > > could kill such a process.
> > > > 
> > > 
> > > That's a pretty painful local denial of service :(
> > 
> > Yes it is. Perhaps there should be 8% fd reserved for root, su and setuid family syscalls like in filesystem space or postgresql reserved connections for db admin.
> > 
> 
> There is an fd reserve already. Report talks about problems with
> creating a new *pipe*, not any fd in general.
> 
> That said, supporting a reserve for this one sounds like a good idea and
> not that hard to implement - one can either play with atomics and double
> check or just place a mutex-protected check in pipespace_new (before
> vm_map_find).
> 
> I implemented the second one, which turned out to be surprisingly ugly.
> For now it abuses PRIV_MAXPROC and has a reserve taken out of the blue.
> 
> Thoughts?
> 
...

I think more reasonable behaviour there is to just fall back to the
buffered pipe if the direct buffer allocation fails. Look at the
pipespace_new() calls in the pipe_create(); probably ignoring the error
would do the trick.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20140408/4acc8c24/attachment.sig>