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.)
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 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.
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.
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.
> 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
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..
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.
...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.
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.
Nice to randomly encounter our own work here.
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...
Calif is just killing it these past couple months. Reminder that Calif is Thai Duong's new firm.
You're always super kind to me :)
This is from April 28th, it was patched in 15.0R-p7.
-p8 is the current patch level for 15.0-RELEASE so if people have been keeping on top of patching this is already two reboots in the past.
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.)
Or in other words, the response is well-coordinated so cperciva's bragging is justified, isn't it?
Indeed, I was thinking about this precise issue when I made the point that corresponding issues get handled much better in FreeBSD than in Linux.
Its like rain on your wedding day - not actually ironic, just unfortunate.
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 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!
Hah I'm your mirror version -- my linux machines are all VMs running on FreeBSD hosts!
Oh you use bhyve?
I've tried to use it but I dound it pretty difficult for systems that need a GUI. Maybe I should revisit.
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.
0: https://sylve.io
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.
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.
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.
He was talking about managing disclosure and patch flow, and you're just taking it as an opportunity to dunk on him.
Oof that's a pretty big one, I didn't realise but I had already updated anyway.
> IV. Workaround
> No workaround is available.
Oh dear.
> V. Solution
> 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
I think good system should be prepared to do a reboot in a short notice. Even some long running jobs can have a pause mechanism.
Yep.
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?
Stability of ecosystem. No systemd. Native ZFS. Jails over Docker. Been using it for 20+ years and it’s my preferred server OS.
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..
Same. I've been using it since 1996. Initially, we used it at an early ISP for DNS, SMTP, and POP3 for roughly 8K users, and it stuck with me.
>> monolith kernel written in C
> Who is really running anything like this in 2026 and for what purpose?
Am I parsing your question correctly?
No, I worded it badly. See below.
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.
...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.
What prevents it?
Does this vulnerability not rely on SUID binaries?
I don't think so? It's a buffer overflow in the system call.
I just read that it was spilling into argv or something and assumed the vector was somehow injecting arguments or something.
Why? Just update.
Linux is on their second and FreeBSD is on their first. How many is Windows on?
Plenty, Microsoft has security teams whose job is to attack Windows.
Naturally they don't do blog posts about what they find.
You talk as if Windows is the only OS that has red teams attacking the system when clearly that isn’t even remotely true.
No, they're saying security work happens in the Windows world but not as much in the open, due to the closed source nature.
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.
If you think Linux is on their first or second, I'm not sure how or what you're counting.
> I'm not sure how or what you're counting.
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.
Your question was "how many high profile privilege escalations Windows has had recently" then? I can't think of any, 0?
https://nvd.nist.gov/vuln/detail/CVE-2026-21250
It was a sarcastic joke, never mind.