Just yesterday, cperciva was bragging about the FreeBSD approach to security: https://news.ycombinator.com/item?id=48056853 You can certainly argue the response here was well-coordinated, but having an LPE in a nearly 50-year old core syscall like execve() isn't ideal from a security perspective. (That is: security response isn't the entire picture; culture and bug surface matter too.)
I think cperciva may have been a touch overenthusiastic, but surely this is in fact proving his point? His claim was, as you note before trying to ignore it, about coordination. When one of the recent Linux LPEs broke, the fix wasn't in distro packages yet; there was a vulnerability that users couldn't practically do anything about. This is an LPE that is fixed in the binaries that have already shipped. If I was playing cheerleader, this is exactly the case I'd use to argue that FreeBSD being a single unified system is a win and that its approach to handing security problems is very on top of things.
A not-insignificant chunk of the userbase of the various BSDs is there because they were turned off of Linux after controversial things like Gnome 3, systemd being shoved down users' throats despite being a broken mess, wayland (though nobody was as arrogant about wayland as Poettering was about systemd), etc.
All that to say, the BSD userbase as a sizeable subset that are there for countercultural reasons, rather than technical. These are the people who buy into, say, OpenBSD's vaunted security reputation, or believe that "linux bad because reasons", so you're always going to get people in here bragging, because "not using linux" has become part of their identity.
I run a mix of FreeBSD and Linux on my personal devices. The ground truth is that FreeBSD is yet another unix-like OS written in C, and thus not immune from the types of bugs that stem from that lineage. None of the BSD distros are materially more secure or better than a properly-configured and patched Linux.
The person 'bragging' was not a countercultural user, but rather the FreeBSD engineering lead. They were, however, talking about FreeBSD's response to security vulnerabilities, in contrast to Linux's response.
> thus not immune from the types of bugs that stem from that lineage
They never claimed that FreeBSD didn't have vulnerabilities. I honestly have no idea why grandparent decided to bring up their comment when it exactly validates what the person they were criticising says. GP admits the response to the vulnerability was well-coordinated. The response to security vulnerabilities was the exact, and only, subject of the post they're calling out.
I wouldn't call it countercultural. And Wayland actually runs on freebsd these days.
I use Linux as well but I really like FreeBSD for a number of technical reasons. Like the ports collection, the jails, the first-class citizen ZFS.
And Gnome 3 doesn't really have anything to do with Linux. It is also available for FreeBSD if you want it (I don't, I hate the minimalist opinionated design style so I use KDE, also on Linux).
But I use Linux on servers where I run docker for example. It's not about "not using linux".
> And Gnome 3 doesn't really have anything to do with Linux.
There's a very hard push on getting Gnome 3 aligned to systemd. Gnome is actually my preferred DE on Linux when I choose to use one. But compatibility with Unix systems is becoming harder every day.
Yes even KDE recently introduced a new display manager that is completely tied to systemd. For that reason it's not supported on FreeBSD. But sddm still works of course. But it is a worrying precedent.
From the gnome team this was to be expected because they are beholden to RedHat/IBM and the other big distros who push systemd heavily. But from the KDE team I didn't.
I've stopped my monthly KDE donations for this reason. Just to send a message that this isn't ok.
I also use a mix. I moved to FreeBSD initially after a rough period w/Linux in the late 90's. Today, my FreeBSD machines are all VMs running on Linux hosts!
Yep, most of my linuxes are headless -- but I do have a VM which I pass a graphics card through to for games and ai stuff though -- works really well (as long as you don't reboot the VM, it has a hard time attaching to the gfx card the second time for some reason, not looked into it much)
sysutils/vm-bhyve makes it quite friendly.
I wouldn't use it for work, though, just personal. Work is all enterprisey kubernetes stuff.
Edit: there is a 'proxmox-like' for FreeBSD out [0] -- I did try it on a couple machines and couldn't get the network working, but consoles seemed to work.. Kinda.
Ah I don't really have a second GPU to dedicate to it though. A virtual console like in VMware or QEMU/KVM would be great. Thanks for the heads-up about sylve! I'll check it out.
For me it's all personal too. For work we still use VMWare a lot.
> Upgrade your vulnerable system to a supported FreeBSD stable or
release / security branch (releng) dated after the correction date,
and reboot the system.
Not everyone can just freebsd-update and reboot, so yes, "Oh dear." is a good response to this.
Anyone relying on a 30+ year old monolith kernel written in C to not have some exploitable LPEs lurking should stay in basket weaving and out of sysadmin.
Not sure why the snark but if people are running FreeBSD then they should be...basket weaving instead of using it? Yes, the correct solution is to patch and reboot but not everyone is in a place to jump and do that which is why a temp workaround, if possible, would be welcome
Not necessarily FreeBSD, but for Linux this applies to most universities with a CS program, I think.
The systems should be cut off from sensitive administrative data, but a malicious student would at the very least have access to the other students' data with an LPE.
No, I mean do you run FreeBSD boxes where users who should not ever assume root access actually login to do tasks?
My point is that if you do, you probably shouldn't run, for e.g applications which need production db credential, or hold sensitive data on these boxes, or .. whatever.
Edit: I use FreeBSD extensively, for various things -- but shell access to them is restricted to the sysadmins..
...as opposed to what, exactly? Linux is a 34 y.o. monolithic kernel in C, the BSDs are all forked from the same base (386BSD) of around the same age, XNU is 29 years old (and also heavily based on BSD code while also throwing in mach code) in C and other languages,...
Why can't they? Upgrading and rebooting is kinda the standard response for most security issues. So I would expect something like Ansible's playbooks for this exact scenario. You might also have it setup as a staggered rollout.
The exploit is injecting environment variables, but yes, close enough. You need someone to call execve as root in order to become root, but you don't need a setuid binary.
Local privilege escalation is largely irrelevant on Windows because basically no one uses it in a multi-user system, and application sandboxing is effectively nonexistent.
I get that multiple human users on a same machine is rare nowadays, and that per-app users were never a thing.
But windows still has a root and a lower privilege user. You typically need to click on "run as admin" to elevate privileges to, for example, alter system binaries.
I know that Chrome on Windows tries to lower its privileges to mitigate exploits, and although it's not very popular, the MS Store app platform does try to do full isolation of apps. So actually, per-app separation of users kinda does happen, or is attempted on Windows.
Check out our blog post for a fun walkthrough: https://blog.calif.io/p/cve-2026-7270-how-i-get-root-on-free...
AI-generated working exploit, write-up and prompts: https://github.com/califio/publications/tree/main/MADBugs/fr...
All that to say, the BSD userbase as a sizeable subset that are there for countercultural reasons, rather than technical. These are the people who buy into, say, OpenBSD's vaunted security reputation, or believe that "linux bad because reasons", so you're always going to get people in here bragging, because "not using linux" has become part of their identity.
I run a mix of FreeBSD and Linux on my personal devices. The ground truth is that FreeBSD is yet another unix-like OS written in C, and thus not immune from the types of bugs that stem from that lineage. None of the BSD distros are materially more secure or better than a properly-configured and patched Linux.
> thus not immune from the types of bugs that stem from that lineage
They never claimed that FreeBSD didn't have vulnerabilities. I honestly have no idea why grandparent decided to bring up their comment when it exactly validates what the person they were criticising says. GP admits the response to the vulnerability was well-coordinated. The response to security vulnerabilities was the exact, and only, subject of the post they're calling out.
I use Linux as well but I really like FreeBSD for a number of technical reasons. Like the ports collection, the jails, the first-class citizen ZFS.
And Gnome 3 doesn't really have anything to do with Linux. It is also available for FreeBSD if you want it (I don't, I hate the minimalist opinionated design style so I use KDE, also on Linux).
But I use Linux on servers where I run docker for example. It's not about "not using linux".
There's a very hard push on getting Gnome 3 aligned to systemd. Gnome is actually my preferred DE on Linux when I choose to use one. But compatibility with Unix systems is becoming harder every day.
From the gnome team this was to be expected because they are beholden to RedHat/IBM and the other big distros who push systemd heavily. But from the KDE team I didn't.
I've stopped my monthly KDE donations for this reason. Just to send a message that this isn't ok.
I've tried to use it but I dound it pretty difficult for systems that need a GUI. Maybe I should revisit.
sysutils/vm-bhyve makes it quite friendly.
I wouldn't use it for work, though, just personal. Work is all enterprisey kubernetes stuff.
Edit: there is a 'proxmox-like' for FreeBSD out [0] -- I did try it on a couple machines and couldn't get the network working, but consoles seemed to work.. Kinda.
0: https://sylve.io
For me it's all personal too. For work we still use VMWare a lot.
Yeah.
> No workaround is available.
Oh dear.
> Upgrade your vulnerable system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date, and reboot the system.
Not everyone can just freebsd-update and reboot, so yes, "Oh dear." is a good response to this.
You should treat any system where non-admins regularly login as basically insecure/owned and rig your architecture appropriately.
TBH -- I don't have any of these kinds of boxes anymore. Who is really running anything like this in 2026 and for what purpose?
The systems should be cut off from sensitive administrative data, but a malicious student would at the very least have access to the other students' data with an LPE.
My point is that if you do, you probably shouldn't run, for e.g applications which need production db credential, or hold sensitive data on these boxes, or .. whatever.
Edit: I use FreeBSD extensively, for various things -- but shell access to them is restricted to the sysadmins..
> Who is really running anything like this in 2026 and for what purpose?
Am I parsing your question correctly?
The recent two. FailCopy and DirtyFrag and FreeBSD with Execve.
2 - Linux 1 - FreeBSD.
Of course, all OS have had past-time exploits. Three now have made the news.
Naturally they don't do blog posts about what they find.
But windows still has a root and a lower privilege user. You typically need to click on "run as admin" to elevate privileges to, for example, alter system binaries.