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.
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?
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..
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).
Hordes of this (in Linux world).
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.
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.
Does not convey what your clarification attemps to state.
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.
> Who is really running anything like this in 2026 and for what purpose?
Am I parsing your question correctly?
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.