Edit: ref: https://xcancel.com/ortegaalfredo/status/2057109561702580311
This appears to come from dressing up like Elton John in a feather suit and hiring a marketing team.
> The bug was silently fixed in the main branch on 2025-11-27 (commit 000d5b52c19ff3858a6f0cbb405d47713c4267a4) as a side effect of a broader function refactoring. The fix has not been backported to stable/14 or releng/14.4. FreeBSD 14.4-RELEASE remains vulnerable.
> FreeBSD 15.0 still carries the sizeof(*groups) typo and is therefore vulnerable, but the surrounding code differs enough from 14.4 that the chain primitives developed here do not lift the overflow into a working LPE on that branch. On 15.0 the bug remains a kernel panic triggered by any unprivileged user.
[deleted]
I don't understand why you're being so defensive about this.
These complaints aren't about what's better or worse for the user community; they're about people trying to put vulnerability researchers in their place.
Why? This is a better resource in every way: https://cgit.freebsd.org/src/commit/?id=000d5b52c19ff3858a6f...
It details the actual problem instead of showing off tired stack exploit tricks.
Case in point: what's "tired" about the stack exploitation techniques they're using here?
And, while you're not right, even stipulating that you were, what would that matter? How is anyone better off with less explanation of a vulnerability?
I'm more interested in the why than the how.
I suppose people with different overall goals will see that differently.
CVE numbers are for boring professionals.
Is there something in this website that feels unnecessary? It seems like a good format of sharing high quality information.
This looks like a full bug into a complete root escalation of a kernel. That's hard to do and deserving of praise. The fact that we have a writeup organized like this is awesome.
-------
This is sort of the expert level stuff that I thought HackerNews would most enjoy.
[dead]
[deleted]
I hope this is true but as other comments have suggested, Juniper and TrueNAS are moving or no longer on FreeBSD.
I am now wondering if Netflix may one day give up FreeBSD for their cache server as well.
illumos distros might be a good alternative. I have OmniOS[0] as a filer and SmartOS[1] running hypervisor duties on zones and bhyve.
I mean that is the whole point of a NAS OS. It gives you a GUI and you don't have to worry about the rest.
Whilst all are "soft-moddable" via HEN, a large number of the Slim and Superslims are not compatible with full custom firmware. Recently a hardware based exploit 'badWDSD' released which allow CFW, although even still a small number of Superslims are not compatible.
I don't want or need fanfare, marketing or any of that stuff.
It's a bug for fucks sake. There will be people having web pages for Gnome user interface bugs next.
git log -S suggests 4cd93df95e697942adf0ff038fc8f357cbb07cf9, which looks more likely: https://cgit.freebsd.org/src/commit/?id=4cd93df95e697942adf0... - though not to say you don't want the later commit too. I'm sure you do.