Date: Sun, 24 Apr 2016 07:03:24 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 208985] DoS / heap overflow in bpf_stats_sysctl Message-ID: <bug-208985-2472-T7hhta865l@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-208985-2472@https.bugs.freebsd.org/bugzilla/> References: <bug-208985-2472@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D208985 --- Comment #3 from CTurt <cturt@hardenedbsd.org> --- Thanks for your response. I firmly believe any `malloc` with an unchecked size from userland to absolutely be a bug. As demonstrated by my PoC code, when accessible, this = can be used to at minimum panic a system. Even when accessible to root only, ha= ving a bug like this present makes the system slightly less stable, no matter how rarely it may occur. It shouldn't really matter what requirements the function has; it is always better to fix it to eliminate the possibility of this becoming critical in = the future if the code were ever to be altered. For example, you mention having interest in altering this code in the future such that under a rare circumstance, it would be accessible with normal user privileges. My original patch set an arbitrary upper limit, which may not be appropriat= e. However, if this limit is either increased or changed to be variable, I wou= ld suggest removing the `M_WAITOK` flag and returning an error for when the ca= ll fails instead. --=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-208985-2472-T7hhta865l>