Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 02 Jul 2023 13:49:47 +0000
From:      bugzilla-noreply@freebsd.org
To:        bugs@FreeBSD.org
Subject:   [Bug 272332] pipebomb: kern.ipc.maxpipekva exceeded
Message-ID:  <bug-272332-227@https.bugs.freebsd.org/bugzilla/>

next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D272332

            Bug ID: 272332
           Summary: pipebomb: kern.ipc.maxpipekva exceeded
           Product: Base System
           Version: 13.2-RELEASE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: kern
          Assignee: bugs@FreeBSD.org
          Reporter: koston@iki.fi
 Attachment #243133 text/plain
         mime type:

Created attachment 243133
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D243133&action=
=3Dedit
pipe() bomb

kern.ipc.maxpipekva sets hard limit on kernel address space allocated to
mapping pipe buffers. Exceeding this limit causes pipe() return -1 and
"kern.ipc.maxpipekva exceeded" message, as it should.

This causes a local denial of service, if the pipe() failure is ignored. Th=
is
can happen due to buggy software (as it did in my case), or it can be trivi=
ally
triggered by a malicious local user. Regardless, it is a pain to deal with,=
 if
the offending process doesn't voluntarily give up on it's bad manners.

The kernel is already capable and willing to forcibly terminate a process,
which has exhausted system memory capacity. Should it do the same for a pro=
cess
exhausting pipe buffers?

Attached C code demonstrating the issue.

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-272332-227>