Date: Sun, 24 Apr 2016 03:01:36 +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-w1qGDWc2xj@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 csjp@sqrt.ca changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |csjp@sqrt.ca --- Comment #2 from csjp@sqrt.ca --- This thought had crossed my mind when I implemented this. This is one of the reasons I don't like the sysctl(2) interface for this sort of thing. It's a= lso subject to race conditions when the number of BPF descriptors change after = the size calculation but before we retrieve the data. The main reason I didn't bound check the size was for two reasons: the amou= nt of data to allocate is a function of the number of BPF descriptors that are allocated. There isn't a limit on this (outside of the file descriptor limitations). The second reason you point out, is this operation requires privilege. The reason I make the statement in the comment is because although by default o= nly root can open this device, it is possible (though not very likely) that the permissions were changed on the underlying BPF device node, resulting in a = BPF descriptor being created by somebody who wasn't root. I don't believe the patch as written is correct either, because there is no connection to this value and the number of descriptors which could be in us= e at the time the stats are retrieved. Having said that, I don't think its a bad idea to bounds check this value either. --=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-w1qGDWc2xj>