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>