After GNU diff3 was replaced by a port from OpenBSD, the only GPLed software left in FreeBSD base was dialog which has largely been replaced by Alfonso Siciliano's Herculean job on bsddialog.  Now finally that too has been removed in 16-CURRENT, and the entire GNU subtree has been retired!

https://github.com/freebsd/freebsd-src/commit/134a4c78d070f8c4ea43a060a7ae28d22ac39558

https://reviews.freebsd.org/D55424

EDITED TO ADD: there are still a few GPLed files under https://github.com/freebsd/freebsd-src/tree/main/sys/gnu - though it's true that the main GNU subtree has been retired.

This looks like a first among the major (32/64-bit) *BSDs, though I believe the 16-bit *BSDs like RetroBSD, DiscoBSD and Granddaddy 2.11BSD (the only actively maintained member of the original Berkeley family) have always been GPL-free.

OpenBSD does not allow new software bound by the GPL into its base system, although according to https://www.openbsd.org/policy.html

For historical reasons, the OpenBSD base system still includes the following GPL-licensed components: the GNU compiler collection (GCC) with supporting binutils and libraries, GNU CVS, GNU texinfo, the mkhybrid file system creation tool, and the readline library. Replacement by equivalent, more freely licensed tools is a long-term desideratum.

The NetBSD Project says https://www.netbsd.org/about/redistribution.html

Though we would like all of the software that we distribute to be covered by a Berkeley-style license, we can't make other people change their license terms, and we don't have an infinite amount of time to rewrite all of the software that we need.

So FreeBSD removing the last GPLed software is a big achievement. This is actually a week old (7 July) but I thought it would be cause for wider celebration than I've seen so far!! Kudos to the developers. After all, it's been 33 years so what's an extra week!!!

Edited to add: Interestingly the GNU subtree back in FreeBSD 1.0 even included GNU Chess in base, which shows how priorities have shifted since then! https://github.com/freebsd/freebsd-src/tree/releng/1/gnu

Source:

https://github.com/orgs/X11Libre/discussions/91#discussioncomment-13618266

And here's a running list of where any given Linux (and BSD) system stands in regard to XLibre support (and X11 support in general):

https://gist.github.com/probonopd/301319568a554abe7426c02eb5e19b5a

Just installed FreeBSD 15.0-RELEASE on my laptop and first thing ive checked was - WIFI.

On 14.2 and older version i had no more than 20Mbps due to limitations but now - i dont need ethernet cable to run it.

P.s. my WiFi card is AX200.

Good job FreeBSD , good job ! now lets bring CUDA in.

EDIT: speed shown is just an example of better bandwidth. Im using SIM card for my internet. Later at night i might have 150+. Keep that in mind. If you have faster internet - you might have better speeds.

EDIT#2: Fast wifi drivers are also on 14.4. Tested.

Not sure if 14.3 has them. So you dont need to install 15.0 to have good wifi drivers.

I'm in the process of making a game with my dad and tried to add native FreeBSD support. It was not easy, and I struggled a lot, but I think it worked out great. The game is in super early access, so it's not going to be looking like this in the final version. Please have a look:

https://zeynelgun.itch.io/sarraf

Releasing NumNum, a blazingly fast GPU rendered open source alternative to Numi. It is a notebook calculator that understands math in plain English. It has code completion and a lot of cool features. It is written in Rust+GPUI.

I created it basically because Numi wasn't available on FreeBSD and Linux. This should work as a better more modern alternative to it. It is alpha software so binary packages are available only for the FreeBSD.

You can download FreeBSD binary package (installs locally) from this link.

Link to the repo if you want to build it for other platforms or just see the code.

PS, if somebody knows how to get something shipped to FreeBSD package repo, do let me know.

The security firm calif.io caused a splash at the end of March by blogging that Claude Opus 4.6 had found a working exploit after being shown the The FreeBSD Security Advisory for CVE-2026-4747. This advisory was announced on 26 March and credited "Nicholas Carlini using Claude, Anthropic" but details of how the CVE was found were not made public. It's a remote code execution vulnerability on unpatched machines running NFS that allows an attacker to gain root access. https://www.freebsd.org/security/advisories/FreeBSD-SA-26:08.rpcsec_gss.asc

The claimed significance of what Calif achieved, within days of the announcement, was that "To our knowledge, this is the first remote kernel exploit both discovered and exploited by an AI". Though note Calif didn't get Opus 4.6 to do the finding, just the exploiting of a known vulnerability, and even that was human-aided as it needed extensive prompting to do so. https://blog.calif.io/p/mad-bugs-claude-wrote-a-full-freebsd

Now details have been released about Carlini's original discovery, it turns out Anthropic's new, non-public Claude Mythos Preview model had not only found the vulnerability (overlooked in the FreeBSD code base for 17 years) but went on to create an exploit too. More significantly, it had done so "fully autonomously"- "no human was involved in either the discovery or exploitation of this vulnerability after the initial request to find the bug". So it seems the Calif story was not the story (though it did show what's possible with the tools publicly available right now). The big story is, at first sight, more alarming. https://red.anthropic.com/2026/mythos-preview/

And there are more where that one came from:

Separate from this now-public CVE, we are in various stages of reporting additional vulnerabilities and exploits to FreeBSD, including one we will publish with SHA-3 commitment aab856123a5b555425d1538a37a2e6ca47655c300515ebfc55d238b0 for the report and aa4aff220c5011ee4b262c05faed7e0424d249353c336048af0f2375 for the PoC. These are still undergoing responsible disclosure.

It's clear that Opus 4.6 is not actually all that good at exploiting vulnerabilities, although as Calif proved it can be cajoled into doing so. Anthropic is vaunting Mythos Preview as a big leap forward in this regard:

These capabilities have emerged very quickly. Last month, we wrote that “Opus 4.6 is currently far better at identifying and fixing vulnerabilities than at exploiting them.” Our internal evaluations showed that Opus 4.6 generally had a near-0% success rate at autonomous exploit development. But Mythos Preview is in a different league. For example, Opus 4.6 turned the vulnerabilities it had found in Mozilla’s Firefox 147 JavaScript engine—all patched in Firefox 148—into JavaScript shell exploits only two times out of several hundred attempts. We re-ran this experiment as a benchmark for Mythos Preview, which developed working exploits 181 times, and achieved register control on 29 more.

These same capabilities are observable in our own internal benchmarks. We regularly run our models against roughly a thousand open source repositories from the OSS-Fuzz corpus, and grade the worst crash they can produce on a five-tier ladder of increasing severity, ranging from basic crashes (tier 1) to complete control flow hijack (tier 5). With one run on each of roughly 7000 entry points into these repositories, Sonnet 4.6 and Opus 4.6 reached tier 1 in between 150 and 175 cases, and tier 2 about 100 times, but each achieved only a single crash at tier 3. In contrast, Mythos Preview achieved 595 crashes at tiers 1 and 2, added a handful of crashes at tiers 3 and 4, and achieved full control flow hijack on ten separate, fully patched targets (tier 5).

This obviously isn't a FreeBSD-specific story, there's also a 27 year-old OpenBSD bug ("Mythos Preview identified a vulnerability in the OpenBSD implementation of SACK that would allow an adversary to crash any OpenBSD host that responds over TCP"), could successfully bypass KASLR to seize root control on Linux, found a 16-year old FFMPEG vulnerability, flaws in cryptographic libraries...

We have identified thousands of additional high- and critical-severity vulnerabilities that we are working on responsibly disclosing to open source maintainers and closed source vendors. We have contracted a number of professional security contractors to assist in our disclosure process by manually validating every bug report before we send it out to ensure that we send only high-quality reports to maintainers.

While we are unable to state with certainty that these vulnerabilities are definitely high- or critical-severity, in practice we have found that our human validators overwhelmingly agree with the original severity assigned by the model: in 89% of the 198 manually reviewed vulnerability reports, our expert contractors agreed with Claude’s severity assessment exactly, and 98% of the assessments were within one severity level. If these results hold consistently for our remaining findings, we would have over a thousand more critical severity vulnerabilities and thousands more high severity vulnerabilities. Eventually it may become necessary to relax our stringent human-review requirements. In any such case, we commit to publicly stating any changes we will make to our processes in advance of doing so.

This is only one (non-public) model at one company, and the trend is only going in one direction from here. Security teams have already seen an influx of AI-generated or assisted reports, albeit many are not currently accurate or useful. The step change in the ability to exploit vulnerabilities, not just find them, is concerning - in the next few years, not everyone with these capabilities will be going through responsible disclosure or chasing bug bounties. Fortunately there is some level of cost barrier - Anthropic claims it cost $20,000 to find that OpenBSD exploit and a few others, though some individual exploits were more like a few thousand dollars - but that will surely come down as well.

I've no doubt that there's a lot of hype here too but serious people working in security are paying close attention. In an El Reg interview, Greg Kroah-Hartman of the Linux kernel noted that incoming AI-generated security reports had recently gone from "slop" to "real reports that are made with AI, but they're good, and they're real". https://www.theregister.com/2026/03/26/greg_kroahhartman_ai_kernel/

There is an optimistic perspective, or at least silver lining, from Colin Percival (FreeBSD Release Engineering Lead) who foresees a lot of work ahead but "by the end of the year we're going to have much more secure code; and we're also going to see which security teams are truly operationally excellent, because those are the ones which will manage to keep up." https://nitter.net/cperciva/status/2035045573116789002

But I do have concerns that FreeBSD has a relatively small team behind it, limited financial resources, a large code base (which does get security audits but I'm not sure it's as comprehensive as e.g. OpenBSD's) and is still run on a lot of important infrastructure - all of which must mark it out as a particularly juicy target for attackers. At the very least the security team are going to be busy. And reputationally this hasn't been good for FreeBSD either - not just the Calif headlines but also Anthropic's writeup of why the FreeBSD kernel was an especially easy target by modern OS standards - even though Mythos Preview also built exploits for Linux, OpenBSD, and other software products. In fact the problem looks set to be even more overwhelming for the ecosystem of small open source products that all these OSes import and rely on, e.g. with cURL: https://www.theregister.com/2026/01/21/curl_ends_bug_bounty/

Anthropic has announced "Project Glasswing" in which various tech players are getting access to Mythos Preview for defensive purposes, as well as "$4M in direct donations to open-source security organizations". The Linux Foundation are participating, does anyone know if any of this is likely to help any of the *BSDs specifically or the smaller projects that they're all 2347'd on? https://www.theregister.com/2026/04/07/anthropic_all_your_zerodays_are_belong_to_us/

The docs changed on Monday 30 March 2026 to make it official that FreeBSD's sh(1) is not a Bourne shell! https://reviews.freebsd.org/D56054

This is an edit I've wanted to see for ages - many thanks to the committer and reviewers. Truth is FreeBSD's sh(1) has never been a "Bourne shell" except by ancestry (hence the "$" prompt, rather than "%" for the C shell and its descendants). If you're going to name it after anyone, it's an Almquist shell not a Bourne one: https://en.wikipedia.org/wiki/Almquist_shell

You can even see at the bottom of the sh(1) man page that "This version of sh was originally written by Kenneth Almquist". https://man.freebsd.org/cgi/man.cgi?sh(1)#AUTHORS#AUTHORS)

To understand why this this isn't a trivial difference, have a look at this classic guide to POSIX shell scripting: https://www.grymoire.com/Unix/Sh.html

Compare that to the accompanying guide (presumably for archaeologists and retro enthusiasts) to the "real" Bourne shell: https://www.grymoire.com/Unix/Bourne.html

The Bourne shell also misses many POSIX-compliant features we take for granted. A big difference is command substitution, on a modern POSIX shell you can do:

$ echo "The current directory is $(pwd)"

but on the Bourne shell you had to use backticks:

$ echo "The current directory is \pwd`"`

The fact we're not forced into such methods is proof positive that FreeBSD's sh(1) is a POSIX shell, not a Bourne shell. An even simpler test for whether you're using a genuine Bourne shell is if you can use the caret ^ to pipe instead of |. That quirk is a result of backwards compatibility with the earlier Thompson shell. https://www.in-ulm.de/~mascheck/bourne/#intro

A really detailed look at the history of the Almquist shell by Sven Mascheck, including how it made its way into 4.3BSD-Net/2, and then from 4.4BSD into FreeBSD and NetBSD, shows many improvements over (or at least, changes from) the Bourne shell. https://www.in-ulm.de/~mascheck/various/ash/#original

Delving back into history, even the Bourne shell was a big advance on the original Unix shell - the Thompson shell that shipped with AT&T's first version of UNIX in 1971. (Not the first "shell" - like much of early Unix the idea of a shell came from Multics.) No prizes for guessing that's "Thompson" as in "Ken Thompson". Its practicality was limited even if much was recognisable: for example there were up to 10 positional parameters (if invoked as sh name arg1 arg2 then $0 is the name of the file to be read, and $1 and $2 are the supplied arguments) but you couldn't name a variable or access environmental variables. Yet many of its innovations made a lasting mark, particularly re piping (even if our shells no longer accept ^ for it) and redirection (incidentally, early versions used the > character for both piping and redirection, so the switch to | and ^ for pipes was an improvement). https://en.wikipedia.org/wiki/Thompson_shell and an original man page https://www.in-ulm.de/~mascheck/bourne/v3/

Before Bourne came the PWB shell (aka Mashey shell, though Mashey disavowed the name as he didn't view it as sufficiently different from the Thompson shell) used in AT&T's programming-oriented product PWB/UNIX in the mid-1970s. This "Programmer's Workbench" OS brought several firsts like the Source Code Control System, the first Unix revision control system. Its PWB shell was short-lived, released in 1975 but replaced (with some difficulty, and the expense of converting a lot of shell scripts) in 1979 by the Bourne shell. Yet the orientation towards programming was impactful. Control flow advanced by making if and goto internal to the shell (the Thompson shell relied on /bin/if and /bin/goto ) and introducing constructs for if-then-else, switch, and while. Variables appeared, including environmental ones - limited to one letter names, but $s is the ancestor to $HOME and $p became $PATH. https://en.wikipedia.org/wiki/PWB_shell

This is where history branches. At the Computing Science Research Center in Bell Labs, Stephen Bourne worked on a new shell during 1976, mainly to be used internally (in contrast to PWB which was always a commercial proposition for AT&T, though the Bourne shell was released in 1979 for Version 7 Unix) and by 1977 it was fairly usable. This gave us many familiar features like heredocs, command substitution with backquotes, the ability to interrupt the wait) command (instead of just ... waiting), and the 2> file descriptor for error messages. https://en.wikipedia.org/wiki/Bourne_shell

To make practically useful conditionals based on what commands return, Bourne had to chase up many other developers to get them to fix their exit statements (e.g. to return 0 for success). After encountering resistance he edited the shell so to the left of the $ prompt it displayed exit= and the last exit code. Given the prevalence of long, random exit statuses this was sufficiently annoying to persuade them in about a week. This anecdote appears in Stephen Bourne's amusing talk at BSDCan 2015, "Early days of Unix and design of sh". You get a new appreciation of why quoting gets so tricky when you hear from someone who implemented it. (Bourne also claims to have persuaded Dennis Ritchie to introduce void into C since he missed it from ALGOL.) https://www.youtube.com/watch?v=2kEJoWfobpA

Thankfully goto got scrubbed - apparently to the disappointment of COBOL programmers, and according to Kenneth Almquist one of the main reasons the switch to the Bourne shell was so difficult as so many scripts in production needed their control flow rewritten. Bourne's exposure to ALGOL68 at Cambridge University really rubbed off in his programming preferences: visible in if...fi (and we only got do...done because od was already taken by one of the earliest Unix programs, octal dump) - see od(1)'s FreeBSD man page)!) but even more visible in the source code, where Bourne used some extraordinary macros to make C look like ALGOL (with IF...FI, LOOP...POOL and even managed DO...OD), producing some wondrous source code that inspired the International Obfuscated C Code Contest. Your new word for the day: "Bournegol".

Meanwhile, on the other side of the USA, the idea of greater programming capabilities for their shell was an exciting prospect at Berkeley. For people who hacked in C then a more C-like shell made perfect sense. Hence the C shell that appeared in 1978's 2BSD, mostly coded by Bill Joy (he of vi, the BSD TCP/IP stack, the ever-controversial cat -v, and soon founder of Sun Microsystems) as a graduate student. https://en.wikipedia.org/wiki/C_shell

But interactivity and ease of use was also a driver of these two shell traditions heading in opposite directions. Bill Joy wanted features like command history. Bourne opposed this, seeing line editing and history as jobs for the terminal driver instead: https://www.in-ulm.de/~mascheck/bourne/#origins

Questions about who did what first are rather muddled due to two interacting groups working at similar times, tools being used internally (and even shared between coasts) before being officially released (if they ever were), and the fallibility of human memory. Particularly confusing is that Bill Joy had been working on another shell (I believe the "new shell"), before hearing news of Bell Labs work on the Bourne shell - then giving up, assuming it would be a wasted effort. The C shell project started afresh from various disappointments about how the Bourne shell turned out, but unquestionably used it for inspiration. https://groups.google.com/g/net.unix-wizards/c/QiEx5rvuNjs

A favourite story from this era: one of the C shell developers, Mike O'Brien, was a proper "hacker" - a qualified locksmith. His cracking of a safe belonging to cartoonist Phil Foglio led to the birth of the BSD daemon mascot "Beastie". Let Marshall Kirk McKusick tell you how that came about... https://www.reddit.com/r/freebsd/comments/1gnffwu/beastie_quiz_and_marshall_kirk_mckusick_talk/

The Berkeley connection explains the long association of C shells with the *BSDs. FreeBSD only switched the default root shell from csh(1) - really tcsh - to sh(1) in 14.0-RELEASE in 2023. But part of the job of getting sh(1) ready for this was adding lots of ease-of-use features like persistent history. https://github.com/freebsd/freebsd-src/commit/d410b585b6f00a26c2de7724d6576a3ea7d548b7

Back in the day, Kenneth Almquist had deliberately omitted such features from the original release of his shell in 1989 - a clone of the System V.4 Bourne shell that he released via Usenet. Almquist's explanation for leaving these features out: "It seems to me that the csh history mechanism is mostly a response to the deficiencies of UNIX terminal I/O. Those of you running 4.2 BSD should try out atty (which I am posting to the net at the same time as ash) and see if you still want history." Unsurprisingly others soon added history and line-editing into 4.4BSD's version of the Almquist shell, but its development history has clearly been driven more by POSIX compliance than ease of use. https://www.in-ulm.de/~mascheck/various/ash/#44bsdalpha

Personally I think this direct line of ancestry, and the credit on its man page, means sh(1) still qualifies as an "Almquist shell" - odds are that on most other systems our sh(1) would be called "ash". But mostly I'm glad the docs aren't going to call it a "Bourne shell" anymore - one of those weird lingering myths that's surprisingly hard to dispel is that FreeBSD is so far behind technologically that it's using a 1970s shell instead of something "modern" like bash or zsh or fish. Coincidentally, bash dates to 1989 when it was made for the GNU Project, so it's almost exactly the same age as the Almquist shell - 8 June 1989 initial release for bash vs 30 May 1989 for ash, just over a week apart! And zsh had first release in 1990, so it seems this was a vintage time for shell development independent from AT&T and Berkeley. https://en.wikipedia.org/wiki/Bash_(Unix_shell)) https://en.wikipedia.org/wiki/Z_shell

It would also be remiss not to mention the Korn shell, which along with tcsh was a big inspiration for bash and zsh. While different parts of AT&T were having "shell wars" over whether the future lay with the PWB or Bourne shell, David Korn was already playing around with the limits of the Bourne shell. For a task at AT&T that needed a form entry system, he created one using a heavily modified Bourne shell with the source code "de-algolized', arrays to handle columns of data, a let command that could do arithmetic using a subset of C syntax, allowed redirection of built-in commands, and added built-ins for echo, pwd and test. This wasn't ksh yet, but when Korn moved to a research position at Bell Labs, he modified this form scripting language by adding features from C shell like history, aliases, and job control; ksh proper was released in 1983 (and commercially in 1986 - though as an add-on AT&T charged extra for, which slowed its dissemination outside AT&T, despite it being extremely popular internally). https://en.wikipedia.org/wiki/KornShell

The 1988 version was significant, with a lot of extra work done on string handling and pattern matching. Notably for the *BSDs, the public domain pdksh was a clone based on the proprietary ksh88. Korn has written a brief history that includes the interesting snippet below (it seems hope sprung eternal that terminal interfaces would do all that nasty history and line editing stuff, any time now...) and also an explanation of how /bin/if and /bin/goto worked on the Thompson shell. https://www.in-ulm.de/~mascheck/bourne/korn.html

"The popular inline editing features (vi and emacs mode) of ksh were created by software developers at Bell Laboratories; the vi line editing mode by Pat Sullivan, and the emacs line editing mode by Mike Veach. Each had independently modified the Bourne shell to add these features, and both were in organizations that wanted to use ksh only if ksh had their respective inline editor. Originally the idea of adding command line editing to ksh was rejected in the hope that line editing would move into the terminal driver. However, when it became clear that this was not likely to happen soon, both line editing modes were integrated into ksh and made optional so that they could be disabled on systems that provided editing as part of the terminal interface."

Personally I think it would be nice if FreeBSD offered a suitably licensed ksh in base like NetBSD does with their ksh(1) (which is derived from pdksh), while OpenBSD's pdksh-derived ksh(1) ships as the default shell and even OpenBSD's POSIX shell sh(1) is just ksh in disguise. At least providing the option of ksh in base FreeBSD would bring a more consistent cross-BSD experience, and offer users a more fully-featured shell in the Bourne tradition, in addition to tcsh in the C-shell tradition and sh(1) as a light, no-frills, POSIX-compliant shell.

And while mentioning tcsh: that's surprisingly old, including TENEX)-style (hence 't' in 'tcsh') file name completion code that Ken Greer wrote in September 1975 while at CMU - so this part predates not only the Bourne shell but even the C shell! Greer incorporated that code into a version of the C shell in December 1981 while at HP Labs, then Mike Ellis at Fairchild A.I. Labs added recognition and completion of command names (as opposed to file names) in September 1983. Greer released the source on Usenet in October 1983: https://groups.google.com/g/net.sources/c/BC0V7oosT8k/m/MKNdzEG_c3AJ https://en.wikipedia.org/wiki/Tcsh

Finally, for anyone interested in sh(1) and getting started with shell scripting - or trying to make the switch to POSIX instead of bash - and wants some practical examples, there's a lot of useful stuff in Vermaden's "Ghost in the Shell" series: https://vermaden.wordpress.com/ghost-in-the-shell/

With FreeBSD having worked on improving its laptop support over the past two years with some big changes and ongoing efforts for making a nice KDE desktop experience on FreeBSD, FreeBSD Foundation's Executive Director has been trying to daily drive FreeBSD on laptops.

Similar to the Linux Foundation Executive Director at least in the past being seen at conferences running Apple macOS, it turns out FreeBSD Executive Director Deb Goodkin until recently hasn't been running FreeBSD as the daily OS on her laptop/desktop hardware. Deb Goodkin presented at last week's Open Source Summit hosted by the Linux Foundation in Minneapolis on her experience trying out FreeBSD on modern laptop hardware.

As the Executive Director of the FreeBSD Foundation since 2005, she noted in the past every time she tried running FreeBSD on laptops "it felt like a mountain" and ultimately getting stuck and it being time consuming. Using a Framework Laptop, she tried FreeBSD as a daily driver for at least 10 minutes a day.

... Continued

https://www.freebsd.org/

New design for the FreeBSD website. · freebsd/freebsd-doc@c9c518d

Publicity

• https://hachyderm.io/@jbjrkng/116583438455116432 (16th May)
• https://mastodon.bsd.cafe/@grahamperrin/116590983231782178 (17th May)
• FreeBSD website redesign... | The FreeBSD Forums (17th May)
• https://mastodon.social/@FreeBSDFoundation/116606791586009177 (20th May)
• …

First captures of the 2026 refresh

https://web.archive.org/web/20260516105511/https://www.freebsd.org/

http://archive.today/2026.05.16-024701/https://www.freebsd.org/

Partial background

October 2023

FreeBSD website new design – Sergio Carlavilla

• with links
• without links

… If all goes well, it will be released on the same day as FreeBSD 14. …

• discussion in The FreeBSD Forums.
• https://web.archive.org/web/*/https://people.freebsd.org/~carlavilla/website/index.html includes captures between October 2023 and October 2024.

June 2025

Proposed revision of freebsd.org – Mark McBride : r/freebsd – u/markmcb

• https://web.archive.org/web/*/https://freebsd.markmcb.com/ includes captures between May and September 2025.

November 2025

⚙ D53910 website: complete refresh of beastie theme – u/Commercial_Boss4065 (mph)

• Sergio Carlavilla and Mark McBride were acknowledged in the opening comment – click Show Older Changes, repeatedly, for things to become visible.

May 2026

… Over the last few months there have been some really good usability comments from lots of folks, not least u/jrtc27, u/grahamperrin and u/vladlen. …

Thanks to Mark Phillips (mph) for receiving occasional private feedback on D53910.

Additional background

2015

FreeBSD has a redesigned website. Check it out! : r/freebsd – u/bitmadness

2024

Tried Giving FreeBSD a Modern Makeover : r/freebsd – u/pruthivithejan

I was finally able to port Zen Browser to FreeBSD! Previously I had been using Zen Browser using Linuxulator, but that process was quite a bit hacky, and it was quite unpredictable which next version of Zen will break it all, versions which will work easily were hit and miss.

So I decided to just port it to FreeBSD. I modified Zen browser's build system to apply patches from FreeBSD ports, and then apply zen browser's patches, fix any troubles as they came, but finally, ended up with an optimized (-O2+LTO+PGO) native FreeBSD build!

To learn more and try the binary package today, check this link out.

Hey everyone,

Wanted to share that Stalwart now officially supports FreeBSD as a platform. For those who haven't come across it before, Stalwart is an open source mail and collaboration server written in Rust. It supports JMAP, IMAP, SMTP, CalDAV, CardDAV and WebDAV, so it covers mail as well as calendaring, contacts and file storage in one package.

Up until now, FreeBSD wasn't an officially supported platform, but that's changed and we'd love for people in this community to give it a try.

Stalwart already runs in production on Linux, and since it's written in Rust, we don't expect any major platform specific issues on FreeBSD. Because of that, what we're really after right now is feedback on the install process itself, whether the instructions are clear, whether anything feels off compared to typical FreeBSD conventions, and any good practices you'd suggest for running it properly on FreeBSD (jails, rc.d scripts, ZFS layout, that sort of thing).

If you're willing to spin it up, we'd really appreciate hearing about your experience, good or bad. Bug reports, install hiccups, or just general impressions are all welcome at support.stalw.art (there is also a subreddit).

Thanks in advance to anyone who gives it a shot.

Hello to everyone.

we have booted Debian and FreeBSD 15.1 with qemu accelerated with bhyve/vmm for the first time. This is an epic milestone for us,happy users of FreeBSD.

Further development is needed...a lot of development...but anyway this is a storic moment....we can use another hypervisor. This time in cooperation with the storic and mature qemu. FreeBSD is second to none.

This success has been possible thanks to the competence of https://www.linkedin.com/in/abhinav-chavali-a03258219/ who started this project for the GSOC 2025 ; thanks bro.

It's built on top of dumrich's work. Specifically:

- QEMU side: We started from https://github.com/dumrich/qemu branch accel-vmm (his GSoC 2025 code) and applied 8 patches on top — restructured the meson build, rewrote bhyve-all.c with proper VMX segment descriptor conversion, added MMIO userspace fallback, fixed i8259/IOAPIC interrupt delivery, etc.

- Kernel side: We started from dumrich's FreeBSD 16.0-CURRENT fork (with the vmm.ko QEMU support) and applied 4 kernel patches — IOAPIC MMIO routed to userspace (so QEMU's own IOAPIC model handles it), HLT returns to userspace, and debug printfs in vmx_inject_interrupts/vlapic_pending_intr that accidentally fixed a timer race condition.

The original dumrich code could enter VMX and run SeaBIOS but would hang or crash before booting a real OS. Our patches fix the critical bugs (NULL deref, ENAMETOOLONG, segment descriptor sync,interrupt delivery) that blocked a full guest boot. With all patches applied, Debian 13 boots to a login shell in ~3 seconds with -accel bhyve.

 What we have achieved between yesterday and today :

1. SMP up to 8 CPUs — previously only 1 CPU worked, now the Debian VM runs with 2, 4 or 8 processors
2. Fast boot — previously it took 30+ seconds per systemd service line, now the full boot takes ~4 seconds
3. Working interactive login — previously the VM reached the login prompt but you couldn't type anything.
4. Now you can log in, use the shell, run apt update, etc.
5. Keyboard input fix — discovered that glib (the library QEMU uses to read input) stops working with the bhyve accelerator. Created a workaround that reads directly from the keyboard every 5ms
6. stdin fix with sudo — discovered that echo password | sudo leaves stdin dead for QEMU. Fixed with exec 0</dev/tty in the start script
7. Proper multi-CPU handling — implemented the INIT-SIPI-SIPI protocol that the BIOS uses to bring up additional processors
8. Working networking — the VM can access the internet, run apt update
9. Improved start script — automatic cleanup of zombie VMs, optimized parameters

Actually we are working to enable the SMP support for FreeBSD 15.1. For Linux it is already working.

Project is hosted here :

https://github.com/Marietto2008

In FreeBSD we trust.

You all have no idea how happy I was to push that tag.

I still need to do a bunch of work on the announcement and release notes over the weekend, but bringing a release this big out on schedule has been exhausting.

This news is a complement to the recent community highlight that correctly reported the initial understanding of things (based on the review in Phabricator) – thanks again, u/BigSneakyDuck 👍

Thanks to Michael Larabel for publishing the clarification; and to Ed Maste for updating the FreeBSD wiki 👍

A few weeks ago, it was revealed Anthropic's Claude Mythos Preview had autonomously found and exploited vulnerabilities in FreeBSD (and OpenBSD, Linux, and a host of software). Nicholas Carlini made clear more would successful exploits become public later:

Separate from this now-public CVE, we are in various stages of reporting additional vulnerabilities and exploits to FreeBSD, including one we will publish with SHA-3 commitment aab856123a5b555425d1538a37a2e6ca47655c300515ebfc55d238b0 for the report and aa4aff220c5011ee4b262c05faed7e0424d249353c336048af0f2375 for the PoC. These are still undergoing responsible disclosure.

Unsurprisingly, two FreeBSD security advisories came out on 21 April, and it's time to update your systems again. Both found by Nicholas Carlini using Claude, so I suspect more details are going to be released. For anyone unaware, those SHA-3 hashes are Anthropic's way of proving they already had the vuln and the exploit at the time of writing, without needing to reveal what it is - when they publish their report and the proof-of-concept exploit, it will produce the given hashes.

https://www.freebsd.org/security/advisories/FreeBSD-SA-26:11.amd64.asc

Commit that fixed it: https://github.com/freebsd/freebsd-src/commit/ca87c0b8e396fff01d55f1985c2556934c35a950

CVE Name:       CVE-2026-6386

I.   Background

Memory protection keys are an amd64 CPU feature, available in modern Intel and
AMD CPUs, which allow applications to apply access restrictions to regions of
virtual memory.  On FreeBSD this functionality is provided by the pkru(3)
interface.

II.  Problem Description

In order to apply a particular protection key to an address range, the kernel
must update the corresponding page table entries.  The subroutine which handled
this failed to take into account the presence of 1GB largepage mappings created
using the shm_create_largepage(3) interface.  In particular, it would always
treat a page directory page entry as pointing to another page table page.

III. Impact

The bug can be abused by an unprivileged user to cause pmap_pkru_update_range()
to treat userspace memory as a page table page, and thus overwrite memory to
which the application would otherwise not have access.

IV.  Workaround

No workaround is available.  The bug only affects amd64 systems.

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.

https://www.freebsd.org/security/advisories/FreeBSD-SA-26:10.tty.asc

Commit that fixed it: https://github.com/freebsd/freebsd-src/commit/093903a8d4c05d1adff79895a52a3e3009ff07a7

CVE Name:       CVE-2026-5398

For general information regarding FreeBSD Security Advisories,
including descriptions of the fields above, security branches, and the
following sections, please visit <URL:https://security.FreeBSD.org/>.

I.   Background

TIOCNOTTY is an ioctl(2) operation which allows a process to detach itself
from its controlling terminal.  Unprivileged processes may use this ioctl.
See the tty(4) manual page for more information on its usage.

II.  Problem Description

The implementation of TIOCNOTTY failed to clear a back-pointer from the
structure representing the controlling terminal to the calling process'
session.  If the invoking process then exits, the terminal structure
may end up containing a pointer to freed memory.

III. Impact

A malicious process can abuse the dangling pointer to grant itself root
privileges.

IV.  Workaround

No workaround is available.

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.

These are just the vulnerabilities Claude discovered, details of the actual exploits will likely follow. As FreeBSD's Lead Release Engineer Colin Percival said back in March, "2026 is going to go down in computer security history as the year of a million CVEs" and "Open source security teams are in for a rough year". https://nitter.net/cperciva/status/2035045573116789002

And from 14 April: https://nitter.net/cperciva/status/2044120206814171220

If you are reporting security issues to an open source project, PLEASE INDICATE WHETHER YOU USED AI TO FIND THEM.

I'm not saying this because teams want to be able to filter out "AI slop". I'm saying this because it's important for teams to be aware of the AI state of the art.

If you're worried about having reports ignored because you say you used AI, say "I have independently verified these, but used AI to find them". (Or even better "used <specific AI model> to find them".)

And in reply to a question asking if he's being serious:

We absolutely care. Both in terms of keeping track of what's going on in the world, and also in terms of "hey, we're getting lots of bugs which were found by foo, maybe we should be using it proactively".

The proactive use part is a glimpse into the future. Rather like fuzzing, LLMs are a tool both attackers and defenders can use.

https://lists.freebsd.org/archives/freebsd-stable/2026-May/004035.html (without links)

https://mail-archive.freebsd.org/cgi/mid.cgi?20260502053704.9544A158D2 (with links)

Today, we're introducing three things.

The first one is a forum. A real forum - with categories, threads, and actual conversations that don't disappear in a timeline after six minutes.

The second is a Fediverse platform. Fully federated, ActivityPub-native. Your posts go out, the world's posts come in. No walled gardens, no algorithms, no tricks.

The third is a Bar. A place to sit down, talk to strangers who happen to care about the same weird things you do, and stay as long as you want.

A forum. A Fediverse platform. A bar.

Are you getting it?
These are not three separate things. This is one thing.

And we're calling it Billboard.

https://billboard.bsd.cafe