> 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.
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.
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 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..
No. And hosting providers I have used usually use VM isolation (QEMU/etc) for the VPS type instances they allocate to users. The VM is vulnerable if it happens to have a kernel compiled such that allows this vuln.
Also statements like this one - 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?
Does not convey what your clarification attemps to state.
I mean, where I work we offer machines to external users where they have shell access to be able to do their science, but I don't want them to have root access. Other institutes we work with (like supercomputer networks, etc) give us/users non-root access.
When things like CVE-2026-31431 or the bug that this thread is about affect our systems it causes a big headache. Yeah, we firewall off what we _can_ by having different machines doing critical things versus the ones where science users have code execution, but we don't have the resources to give every user their own machine.
Hard to tell about FreeBSD, it's basically extincted, but think of webhosting servers, wordpress, cPanel/Plesk and alike.
often it's ssh'able with things like rbash and other restrictions and almost always you, well, can run something there (as you can edit php/other files right from web management ui).
Extinct? Far from, just doesn’t draw the crowd/press Linux does. An OS used as a stable server OS workhorse with exceptional ZFS support and doesn’t have to push for the desktop market doesn’t mean it’s extinct.
I’ve run FreeBSD on stinkpads back in the early 2000s fine. I prefer MacOS these days as a daily driver - hardware quality.
But server OS is FreeBSD. Void when I need Cuda/docker/etc. (Yes, FreeBSD has docker support, but just use Linux if needing that.
Try to search vacancies for FreeBSD or candidates with FreeBSD knowledge/background, you will be surprised, its desert.
Even TrueNAS realized it's a dead end for reaching wide audience needs and migrated to Linux (as you mentioned zfs, your probably heard a thing or two on TrueNAS).
I have not tried in the last 10 years, so don't have numbers, my ballpark figure about having small infra team say of 5 persons and try to hire for FreeBSD would be longer and more expensive.
I see somewhat tolerable Linux Corp fleet of laptops (still meh, but somewhat works), what you will reply to your users when they complain on WiFi or Zoom not working and how will procurement work for you interesting questions for me.
Red Book for FreeBSD animal, can meet somewhere deep in tundra, but not a widespread species- extinction form my POV.
The bug appears to have been introduced in some FreeBSD 13 version.
I run FreeBSD servers that do not have this bug. In my "kern_exec.c" there is no "consume" anywhere. There is also no "memmove" at all.
That file was last patched in 2024, but whatever changes had introduced that bug, they were not back-ported to older FreeBSD versions, so those are not affected.
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
There was no snark. If you have something of importance running and the inevitable discovery of an LPE is something you don’t have defense for or can quickly mitigate you’re doing a bad job as a sysadmin.
For all general purpose OS in common use today that usually means patch and reboot should be an NBD workaround.
...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,...
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.
"When the timing aligns, the trigger's buggy memmove causes K+1 to self-overwrite, replacing sshd-session's real environment with the preseed payload. sshd-session's exec_copyout_strings copies LD_PRELOAD=/tmp/evil.so to the new process's stack, the runtime linker loads evil.so, and its constructor copies /bin/sh to /tmp/rootsh and sets it suid root. My human's unprivileged user runs /tmp/rootsh -p and gets a root shell."
... so at the very end of the exploit chain, is /tmp/rootsh required to be suid root before it is finally run to get the root shell ?
... or is the exploit already achieved and /tmp/rootsh is just an arbitrary indicator ?
I really am starting to think that the level of technical understanding on HN is so low that when readers see an exploit like this, they imagine basically the cult classic movie "Hackers" in their heads where some guy hacks into any machine of their choosing.
> No workaround is available.
Oh dear.