Category: FreeBSD

This week saw the third beta of FreeBSD 15.1, a critical execve() privilege escalation vulnerability, the KDE desktop installer option being pushed to 15.2, and two libnv security advisories that remain highly relevant. Here’s your summary.

FreeBSD 15.1 Beta 3 Released

FreeBSD 15.1-BETA3 was released over the weekend as the latest weekly test candidate. The release is entering its final stretch — the Release Candidate (RC) is expected next week, and if all goes well, FreeBSD 15.1-RELEASE is targeted for June 2, 2026.

Key changes in Beta 3:

• OpenZFS 2.4.2 has been integrated — the latest OpenZFS release with various fixes and minor enhancements.
• Cloud images now automatically run pkg upgrade on first boot to apply security updates to the base system. A sensible improvement for cloud deployments that often start from stale images.
• Kerberos has been updated.
• bsdinstall scripted installations now use pkgbase.

The beta cycle has been relatively smooth so far. BETA1 and BETA2 in previous weeks brought Zstd 1.5.7, userland fixes for ifconfig, lockf, stat, tail, and certctl, plus kernel fixes for nullfs, so_splice, and VT.

BETA2 Recap (May 8)

• Updated to Zstd 1.5.7
• bsdinstall now consistently uses pkg.freebsd.org for package bootstrap
• Various userland and kernel bug fixes

Critical execve() Privilege Escalation — CVE-2026-7270

A serious kernel vulnerability disclosed in late April continues to generate discussion. FreeBSD-SA-26:13.execdescribes an operator-precedence error in the execve(2) implementation that leads to a buffer overflow. Attacker-controlled data can spill into adjacent argument buffers, corrupt kernel state, and grant unprivileged users root access.

The flaw affects all supported FreeBSD releases (13.5 through the 15 branch). Patches were published within hours, adding explicit parentheses to enforce the intended evaluation order and tightening size checks.

Community Reaction

• Positive: Rapid response — the advisory went live less than an hour after discovery, with patches available for every supported branch the same day.
• Concerns: There is no workaround. Administrators who can’t immediately reboot (e.g., high-availability systems) remain exposed.
• Source-based installations require kernel recompilation and reboot, which can take hours on older hardware.
• Early adopters on the 15 branch reported a minor regression in custom execve wrapper scripts that relied on the previous (buggy) argument handling.

Two libnv Security Advisories (SA-26:16 and SA-26:17)

Also disclosed on April 29, two libnv vulnerabilities remain relevant for anyone who hasn’t patched yet:

• SA-26:16 (CVE-2026-39457): Stack overflow via select() file descriptor set overflow — when a socket descriptor exceeds FD_SETSIZE (1024), select(2) overflows its file descriptor set. An attacker who can force a program to open many descriptors can trigger stack corruption and potentially escalate privileges via setuid-root programs. Discovered by Joshua Rogers (AISLE Research Team).
• SA-26:17 (CVE-2026-35547): Heap overflow in libnv — message size is not properly validated when processing headers, enabling out-of-bounds writes on the heap. This can cause crashes, panics, or potential privilege escalation by unprivileged users. Discovered by Mariusz Zaborski.

Both affect all supported FreeBSD versions with no workaround. Upgrade and reboot are mandatory.

KDE Desktop Installer Option Delayed to FreeBSD 15.2

The long-awaited KDE desktop installation option in the FreeBSD installer has been delayed again — this time from 15.1 to FreeBSD 15.2 (expected December 2026). Originally planned for 15.0, then moved to 15.1, the installation script needs updates for new NVIDIA drivers and removal of obsolete components. After committing to CURRENT, a testing period in STABLE is required, which no longer fits the 15.1 timeline.

Until then, KDE Plasma can be set up manually via pkg after installation.

Mailing List Discussions

Update Strategy and Timing (freebsd-current)

Bob Prohaska kicked off a discussion about preferred update strategies for self-hosted FreeBSD systems. On stable branches, freebsd-update is straightforward. On current, things get more complex. Warner Losh, Rick Macklem, Mark Millard, and others weighed in on the trade-offs of different approaches — a worthwhile read for anyone running current in production.

PKGBASE: Upgrading 15.0 to 15.1-BETA2

Vermaden asked about the upgrade path from FreeBSD 15.0-RELEASE to 15.1-BETA2 using the PKGBASE model. Colin Percival confirmed this path isn’t fully documented yet. The PKGBASE system remains marked as experimental, and the minor-release upgrade workflow needs more work.

Beach Cleaning Project: Infrastructure Cleanup

The FreeBSD Foundation published a detailed report on the Beach Cleaning Project in late April that continues to draw attention:

• Machine-readable inventory of over 1,000 components in the base system, including 73 third-party imports
• OpenSSL 3.5 LTS was integrated in time for FreeBSD 15.0 (replacing OpenSSL 3.0, which reaches EOL September 2026)
• SBOM generation in SPDX 2 and SPDX 3 formats
• CODEOWNERS-style reports for better maintainability
• Preparation for importing pkg into the base system as part of the pkgbase transition

The project was funded by Alpha-Omega and produced practical tooling, security assessments, and implementation plans that will serve FreeBSD development well beyond the project’s lifespan.

Blog Posts This Week

Vermaden: FreeBSD PKGBASE Minor Upgrades

Vermaden published a practical guide for upgrading FreeBSD 15.0 to 15.1-BETA2 using PKGBASE and ZFS Boot Environments. The walkthrough covers creating a new BE, configuring the pkg repository, upgrading the base system, and rolling back if needed — including an alternative approach using --chroot.

Going Back to BSD

Pete shared a personal blog post about returning to BSD after decades on Linux. He describes moving from Arch Linux to FreeBSD, setting up mail servers with Bastille jails, and appreciating the simplicity of the rc system compared to systemd. A nostalgic and practical read.

Looking Ahead

Next week will see the Release Candidate for FreeBSD 15.1. If no unexpected issues arise, the final release is expected on June 2, 2026. Administrators should patch the three security vulnerabilities (execve, libnv x2) immediately if they haven’t already.

Sources: Phoronix, FreeBSD Mailing Lists, FreeBSD Security Advisories, FreeBSD Foundation, Vermaden Blog, LavX News, peteftw.com

Published May 11, 2026

The past week has been one of the most eventful in the FreeBSD project in quite some time: two beta releases, a massive security advisory bundle, eye-catching AI-driven vulnerability discoveries, and a new blog post on the pkgbase upgrade path. Here’s the rundown.

FreeBSD 15.1: Beta 1 and Beta 2 Released

The release cycle for FreeBSD 15.1 is gaining momentum. After Colin Percival announced 15.1-BETA1 on May 2, 15.1-BETA2 followed on May 8 — the weekly cadence is holding.

Changes in Beta 2 (vs. Beta 1)

• Zstd updated to 1.5.7 — latest upstream compression support
• less updated to v692
• bsdinstall now consistently uses pkg.FreeBSD.org for package bootstrap operations
• nuageinit only parses user_data as YAML when necessary
• rtadvd(8) now honors pltime and vltime in interface declarations
• Various userland bug fixes: ifconfig(8), lockf(1), stat(1), tail(1), certctl(8)
• Kernel bug fixes: nullfs, so_splice, vt(4)
• Miscellaneous manual page and test fixes

Available Architectures

Images are available for amd64, powerpc64, powerpc64le, armv7, aarch64 (including RPI, PINE64, ROCK64 variants), and riscv64. Additionally, VM disk images (QCOW2, VHD, VMDK, Raw), OCI container images (static, dynamic, runtime, notoolchain, toolchain), and Amazon EC2 AMIs are provided.

Schedule

• Beta 3 expected next week
• Release Candidate the week after
• 15.1-RELEASE on June 2, 2026 — if all goes according to plan

Critical Security Vulnerabilities — 8 Advisories on April 29

On April 29, FreeBSD published a large batch of security advisories that were widely discussed this week:

Additionally, EN-26:11 was published on May 1: an errata notice correcting overly strict dhclient lease validation behavior — a side effect of the security fixes.

The 21-Year-Old dhclient RCE (CVE-2026-42511)

Particularly notable: the vulnerability in dhclient (SA-26:12) had existed in the code for over 20 years. The BOOTP file field was written to the lease file without escaping embedded double-quotes, enabling injection of arbitrary dhclient.conf directives — and thus remote code execution after a system restart.

AI-Driven Vulnerability Research: AISLE vs. Anthropic Mythos

On May 7, AISLE published a blog post that made waves: their multi-model system had discovered three critical vulnerabilities in FreeBSD — independently of and in parallel with the findings made by Anthropic’s “Claude Mythos.”

AISLE’s findings:

1. The 21-year-old dhclient RCE (CVE-2026-42511)
2. A remotely triggerable heap buffer overflow in dhclient
3. A stack buffer overflow in ping6 (local privilege escalation)

All three were discovered on April 13, reported on April 14, and patched on April 29.

The debate AISLE’s findings sparked is noteworthy: AI-powered security systems can be very effective even with smaller, cheaper models — a well-designed system beats pure scaling through larger models. AISLE references their research showing that security capability is “jagged”: small models can outperform larger ones at many security-relevant tasks.

FreeBSD Foundation: “Cleaning Up Critical Infrastructure”

On April 20 (still widely discussed this week), the FreeBSD Foundation published a detailed blog post about the Alpha-Omega Beach Cleaning Project. Key points:

• OpenSSL 3.5 LTS was integrated in time for FreeBSD 15.0 — avoiding an unsupported fork of OpenSSL 3.0 (EOL September 2026) for over four years
• A machine-readable inventory of the base system was created: over 1,000 components in a YAML-based database, including 73 third-party imports
• SBOM generation via SPDX 2 and SPDX 3 formats
• CODEOWNERS-style reports for better maintainership tracking
• Preparation for importing pkg into the base system as part of the pkgbase transition

Vermaden: PKGBASE Minor Upgrades with ZFS Boot Environments

On May 10, well-known FreeBSD blogger Vermaden published a practical guide for minor upgrades (e.g., 15.0 to 15.1) using PKGBASE and ZFS Boot Environments. Since PKGBASE is still marked as experimental and freebsd-update(8) is no longer available for minor releases, he demonstrates two methods:

1. Classic method: Create a new ZFS BE, chroot, configure pkg.repo, run pkg upgrade -r FreeBSD-base
2. Alternative method: Use pkg --chroot and ABI/OSVERSION overrides without manual devfs mounting

Both methods allow a safe rollback via ZFS Boot Environments if the upgrade causes issues.

Q1 2026 Status Report: 45 Entries

The FreeBSD Status Report for the first quarter of 2026 was published on April 23 — with a record 45 entries. Highlights:

• Cyber Resilience Act (CRA) Readiness Project — preparing for EU regulation
• amd64 FRED support — new CPU flexibility features
• LinuxKPI 802.11 and Native Wireless Update — WiFi driver progress
• Suspend/Resume and Hibernate improvements
• Sylve — a unified system management platform for FreeBSD
• daemonless — native FreeBSD OCI containers without a daemon
• KDE on FreeBSD — Plasma 6 and Wayland progress
• FreeBSD on EC2 and STACKIT Cloud Integration
• bhyve: Full CPUID Control, Management GUI

Looking Ahead

With Beta 3 coming next week and the Release Candidate after that, FreeBSD 15.1-RELEASE on June 2 is fast approaching. Anyone running supported versions should urgently apply the April 29 security advisories — especially the critical dhclient RCE. And for those testing pkgbase, Vermaden’s guide provides a solid starting point.

Links:

• FreeBSD 15.1-BETA2 Announcement
• FreeBSD Security Advisories
• AISLE: 3 Critical Vulnerabilities in FreeBSD
• AISLE: CVE-2026-42511
• FreeBSD Foundation: Beach Cleaning Project
• Vermaden: PKGBASE Minor Upgrades
• FreeBSD Q1 2026 Status Report
• FreeBSD 15.1 Release Notes (Work in Progress)

This week brought two critical security advisories (both discovered with AI-assisted fuzzing), a bumper Q1 status report with 45 entries, and the official start of the 15.1 release cycle. If you’re still on FreeBSD 13.5, the clock is ticking.

Two Security Advisories, One Day

On April 21, the FreeBSD Security Team released two advisories — both credited to Nicholas Carlini using Claude (Anthropic). AI-assisted fuzzing finding two independent kernel bugs is noteworthy and signals a shift in how vulnerability research is done.

SA-26:10.tty — Use-After-Free in TIOCNOTTY Handler (CVE-2026-5398, CVSS 8.4 HIGH)

The TIOCNOTTY ioctl lets a process detach from its controlling terminal. The implementation failed to clear a back-pointer from the terminal structure to the calling process’s session. When the process subsequently exits, the terminal structure retains a dangling pointer to freed memory — which a malicious process can exploit to escalate to root.

All supported FreeBSD versions are affected (13.5, 14.3, 14.4, 15.0). No workaround exists. Patch and reboot.

SA-26:11.amd64 — Missing Large Page Handling in pmap_pkru_update_range() (CVE-2026-6386)

The pmap_pkru_update_range() function updates page table entries when applying Memory Protection Keys (PKRU) to an address range. It didn’t account for 1GB large page mappings created via shm_create_largepage(). Instead of recognizing a page directory entry as a large page, it treated it as a pointer to another page table page.

The result: an unprivileged user can trick the kernel into treating userspace memory as a page table, overwriting memory they shouldn’t have access to. Affects all supported versions on amd64. No workaround.

Takeaway: If you run amd64 systems, patch immediately. Both bugs are locally exploitable, and SA-26:10 leads directly to root. The AI-assisted discovery method is a clear signal: defenders need to adopt these tools as fast as attackers already have.

Q1 2026 Status Report: 45 Entries

The Q1 2026 Status Report landed on April 22 with 45 entries — the first under a newly enforced editorial schedule. Highlights:

Alpha-Omega Beach Cleaning

The FreeBSD Foundation continues its Beach Cleaning project, funded by the Linux Foundation’s Alpha-Omega initiative. The goal: proactively find and fix security vulnerabilities in third-party base system software. The repository includes build infrastructure and fuzzing setups for components like libxml2, SQLite, and other base system dependencies. The connection to this week’s two SAs is obvious — structured fuzzing pays off.

Cyber Resilience Act (CRA) Readiness

The EU’s Cyber Resilience Act is law, and FreeBSD must prepare. The Foundation launched a dedicated CRA Readiness project with monthly updates. Core questions: Which SBOM requirements apply? How is vulnerability management documented? Anyone deploying FreeBSD in EU-compliant products should follow this closely.

Laptop Testing & Integration

The Laptop Integration Testing Project introduced a Python application that automates FreeBSD compatibility testing on laptops. The Foundation is asking the community to submit hardware probes to build a public compatibility matrix. Other laptop progress:

• S0ix (Modern Standby): Suspend/Resume support for modern laptops
• Hibernate (Suspend-to-Disk): Under active development
• CPPC: AMD CPPC support for Zen 2+ processors (out-of-tree module available)
• Intel FRED: Konstantin Belousov (kib) submitted initial patches for Intel’s Flexible Return and Event Delivery — CPUID, MSR, and CR4 bits are in main, full FRED support is under review

Sylvea v0.2.3

The management tool Sylvea reached v0.2.3 with enhanced jail and VM support. A lightweight GUI for Bhyve, Jails, ZFS, and networking — an interesting alternative to web-based tools like TrueNAS.

HPC Initiative

FreeBSD is getting ports for Slurm, OpenMPI, and UCX — high-performance computing is landing on the platform. Niche, but strategically important.

Cloud

FreeBSD on EC2 with updated AMIs, plus a new STACKIT Cloud integration (a European cloud provider in the IAD group).

Ports Updates

• KDE Plasma 6.6.3
• OpenJDK 21/25
• Wazuh 4.14.3 (Security Monitoring)

FreeBSD 15.1: Code Slush Reached

The 15.1 release cycle hit Code Slush on April 17 — commits to the stable/15 branch no longer require explicit approval, but new features should be avoided. The remaining schedule:

FreeBSD 15.0 reaches end-of-life on September 30, 2026. Stable/15 will be supported through December 2029.

FreeBSD 13.5: EOL on April 30

Anyone still running FreeBSD 13.5 has less than a week to upgrade. Support ends April 30 — no more security patches after that. The Release Engineering Team has already stopped weekly snapshot builds for stable/13.

Migration to 14.4 or 15.0 is now urgent. Especially given SA-26:10 and SA-26:11, running an EOL version would be negligent.

ZFS: Snapshot Automount Deadlock Fixed

Hamza (ixhamza) contributed two significant ZFS fixes:

1. Snapshot automount deadlock during concurrent zfs recv — When a snapshot is automounted while zfs recv is running, the system could deadlock. The fix reorganizes the locking order.
2. AVL tree panic from snapshot automount race — A race condition during parallel snapshot mounts could trigger an AVL tree panic. Solved by switching to AVL lookup instead of linear scan.

Additionally, a memory leak in zfsctl_snapshot_mount was fixed — the options structure wasn’t being properly freed.

For anyone running zfs recv in production (and you should be if you do replication), these fixes matter. The deadlock was hitting real users, as open issue #18073 confirms.

BastilleBSD Hiring Plans

BastilleBSD announced plans to hire a part-time FreeBSD/Bastille sysadmin (~20 hrs/week), targeting EMEA/APAC time zones. The role involves working with Bastille’s creator on a cybersecurity startup, with an expected start in mid-to-late 2026. A sign that the FreeBSD jail management ecosystem is professionalizing.

TopBar: Wayland Desktop Environment

TopBar was featured on DiscoverBSD — a customizable desktop environment built with Quickshell and QML for Wayland compositors like MangoWM and Hyprland. It integrates a status bar, app launcher, lock screen, and wallpaper manager into a single cohesive system. For FreeBSD laptop users exploring Wayland, this is worth watching.

ZFS Performance Without New Hardware

A DiscoverBSD article rounded up ZFS performance tips that don’t require hardware investment:

• Tune recordsize to workload (16K for databases, 1M–4M for storage)
• Enable LZ4 compression — often reduces I/O overhead rather than increasing it
• Pool topology: Replace wide RAIDz configs with mirrored VDEVs for more parallelism
• Disable prefetch for random-access workloads (databases)

Nothing new for ZFS veterans, but a solid reference for newcomers.

What This Week Means

Two critical SAs in one week, both discovered via AI-assisted fuzzing — that’s a wake-up call. The tools are getting better, and attackers will use them too. The Q1 status report shows a healthy project: laptop support is growing, HPC is arriving, CRA preparation is professional. And with the code slush for 15.1, the next release is approaching.

If you’re on 13.5: upgrade now. If you’re on 15.0 or 14.4: patch now. Anything else is negligent.

This week brought two critical security advisories (both discovered with AI-assisted fuzzing), a bumper Q1 status report with 45 entries, and the official start of the 15.1 release cycle. If you’re still on FreeBSD 13.5, the clock is ticking.

Two Security Advisories, One Day

On April 21, the FreeBSD Security Team released two advisories — both credited to Nicholas Carlini using Claude (Anthropic). AI-assisted fuzzing finding two independent kernel bugs is noteworthy and signals a shift in how vulnerability research is done.

SA-26:10.tty — Use-After-Free in TIOCNOTTY Handler (CVE-2026-5398, CVSS 8.4 HIGH)

The TIOCNOTTY ioctl lets a process detach from its controlling terminal. The implementation failed to clear a back-pointer from the terminal structure to the calling process’s session. When the process subsequently exits, the terminal structure retains a dangling pointer to freed memory — which a malicious process can exploit to escalate to root.

All supported FreeBSD versions are affected (13.5, 14.3, 14.4, 15.0). No workaround exists. Patch and reboot.

SA-26:11.amd64 — Missing Large Page Handling in pmap_pkru_update_range() (CVE-2026-6386)

The pmap_pkru_update_range() function updates page table entries when applying Memory Protection Keys (PKRU) to an address range. It didn’t account for 1GB large page mappings created via shm_create_largepage(). Instead of recognizing a page directory entry as a large page, it treated it as a pointer to another page table page.

The result: an unprivileged user can trick the kernel into treating userspace memory as a page table, overwriting memory they shouldn’t have access to. Affects all supported versions on amd64. No workaround.

Takeaway: If you run amd64 systems, patch immediately. Both bugs are locally exploitable, and SA-26:10 leads directly to root. The AI-assisted discovery method is a clear signal: defenders need to adopt these tools as fast as attackers already have.

Q1 2026 Status Report: 45 Entries

The Q1 2026 Status Report landed on April 22 with 45 entries — the first under a newly enforced editorial schedule. Highlights:

Alpha-Omega Beach Cleaning

The FreeBSD Foundation continues its Beach Cleaning project, funded by the Linux Foundation’s Alpha-Omega initiative. The goal: proactively find and fix security vulnerabilities in third-party base system software. The repository includes build infrastructure and fuzzing setups for components like libxml2, SQLite, and other base system dependencies. The connection to this week’s two SAs is obvious — structured fuzzing pays off.

Cyber Resilience Act (CRA) Readiness

The EU’s Cyber Resilience Act is law, and FreeBSD must prepare. The Foundation launched a dedicated CRA Readiness project with monthly updates. Core questions: Which SBOM requirements apply? How is vulnerability management documented? Anyone deploying FreeBSD in EU-compliant products should follow this closely.

Laptop Testing & Integration

The Laptop Integration Testing Project introduced a Python application that automates FreeBSD compatibility testing on laptops. The Foundation is asking the community to submit hardware probes to build a public compatibility matrix. Other laptop progress:

• S0ix (Modern Standby): Suspend/Resume support for modern laptops
• Hibernate (Suspend-to-Disk): Under active development
• CPPC: AMD CPPC support for Zen 2+ processors (out-of-tree module available)
• Intel FRED: Konstantin Belousov (kib) submitted initial patches for Intel’s Flexible Return and Event Delivery — CPUID, MSR, and CR4 bits are in main, full FRED support is under review

Sylvea v0.2.3

The management tool Sylvea reached v0.2.3 with enhanced jail and VM support. A lightweight GUI for Bhyve, Jails, ZFS, and networking — an interesting alternative to web-based tools like TrueNAS.

HPC Initiative

FreeBSD is getting ports for Slurm, OpenMPI, and UCX — high-performance computing is landing on the platform. Niche, but strategically important.

Cloud

FreeBSD on EC2 with updated AMIs, plus a new STACKIT Cloud integration (a European cloud provider in the IAD group).

Ports Updates

• KDE Plasma 6.6.3
• OpenJDK 21/25
• Wazuh 4.14.3 (Security Monitoring)

FreeBSD 15.1: Code Slush Reached

The 15.1 release cycle hit Code Slush on April 17 — commits to the stable/15 branch no longer require explicit approval, but new features should be avoided. The remaining schedule:

FreeBSD 15.0 reaches end-of-life on September 30, 2026. Stable/15 will be supported through December 2029.

FreeBSD 13.5: EOL on April 30

Anyone still running FreeBSD 13.5 has less than a week to upgrade. Support ends April 30 — no more security patches after that. The Release Engineering Team has already stopped weekly snapshot builds for stable/13.

Migration to 14.4 or 15.0 is now urgent. Especially given SA-26:10 and SA-26:11, running an EOL version would be negligent.

ZFS: Snapshot Automount Deadlock Fixed

Hamza (ixhamza) contributed two significant ZFS fixes:

1. Snapshot automount deadlock during concurrent zfs recv — When a snapshot is automounted while zfs recv is running, the system could deadlock. The fix reorganizes the locking order.
2. AVL tree panic from snapshot automount race — A race condition during parallel snapshot mounts could trigger an AVL tree panic. Solved by switching to AVL lookup instead of linear scan.

Additionally, a memory leak in zfsctl_snapshot_mount was fixed — the options structure wasn’t being properly freed.

For anyone running zfs recv in production (and you should be if you do replication), these fixes matter. The deadlock was hitting real users, as open issue #18073 confirms.

BastilleBSD Hiring Plans

BastilleBSD announced plans to hire a part-time FreeBSD/Bastille sysadmin (~20 hrs/week), targeting EMEA/APAC time zones. The role involves working with Bastille’s creator on a cybersecurity startup, with an expected start in mid-to-late 2026. A sign that the FreeBSD jail management ecosystem is professionalizing.

TopBar: Wayland Desktop Environment

TopBar was featured on DiscoverBSD — a customizable desktop environment built with Quickshell and QML for Wayland compositors like MangoWM and Hyprland. It integrates a status bar, app launcher, lock screen, and wallpaper manager into a single cohesive system. For FreeBSD laptop users exploring Wayland, this is worth watching.

ZFS Performance Without New Hardware

A DiscoverBSD article rounded up ZFS performance tips that don’t require hardware investment:

• Tune recordsize to workload (16K for databases, 1M–4M for storage)
• Enable LZ4 compression — often reduces I/O overhead rather than increasing it
• Pool topology: Replace wide RAIDz configs with mirrored VDEVs for more parallelism
• Disable prefetch for random-access workloads (databases)

Nothing new for ZFS veterans, but a solid reference for newcomers.

What This Week Means

Two critical SAs in one week, both discovered via AI-assisted fuzzing — that’s a wake-up call. The tools are getting better, and attackers will use them too. The Q1 status report shows a healthy project: laptop support is growing, HPC is arriving, CRA preparation is professional. And with the code slush for 15.1, the next release is approaching.

If you’re on 13.5: upgrade now. If you’re on 15.0 or 14.4: patch now. Anything else is negligent.

A summary of the most important developments, security advisories, and discussions in the FreeBSD ecosystem over the past week.

Release Engineering: 15.1 Approaches Code Slush

On April 17, the stable/15 code slush began in preparation for FreeBSD 15.1. The full schedule, published by Release Engineering Lead Colin Percival back in January, looks like this:

Percival noted in January that 15.1 might be “a relatively bumpy minor release” given the experience with 15.0, particularly due to additional pkgbase changes. Meanwhile, stable/13 reaches its End-of-Life at the end of April — weekly snapshot builds for that branch will cease.

Security: SA-26:08 — Critical Stack Overflow in rpcsec_gss

Perhaps the most notable security development of recent weeks is FreeBSD Security Advisory SA-26:08, which describes a stack overflow in svc_rpc_gss_validate(). The vulnerability allows remote code execution and affects all supported FreeBSD versions. Patches are available for 15.0-RELEASE-p5 and the 14.x series.

What makes this advisory remarkable: the vulnerability was discovered and exploited by Nicholas Carlini using Claude AI (Anthropic) — an early example of AI-assisted security research uncovering real kernel vulnerabilities. The fix commit by Mark Johnston (143293c) addresses the buffer overflow in the GSS validation routine.

Q1 2026 Status Reports Published

The FreeBSD status reports for the first quarter of 2026 are now online. The Release Engineering Team update documents the successful 14.4-RELEASE publication in March and the ongoing planning for 15.1.

Laptop Project: Community Testing Call

The FreeBSD Foundation published a Call for Testing for the Laptop Integration Testing Project on April 6. Following the Year-One Update in February, the team has been building testing infrastructure since January. Community members can now test their laptops:

pkg install python hw-probe
git clone https://github.com/FreeBSDFoundation/freebsd-laptop-testing
cd freebsd-laptop-testing
make

The testing tool automatically probes laptop hardware and creates anonymized reports that can be submitted via Pull Request. Results feed into a public compatibility matrix at freebsdfoundation.github.io/freebsd-laptop-testing.

OpenZFS: Native relatime Property

On April 1, OpenZFS gained a native relatime property (commit 1685849 by @amotin). Relatime (relative atime) only updates a file’s access time when it is older than its modification or status change time, significantly reducing unnecessary write operations — especially beneficial for SSDs and caches. Previously only configurable via mount options, relatime can now be set natively per dataset.

Ports: GNU ld Checks Removed

Brooks Davis committed a tree-wide cleanup (d87609e) on April 13, removing all checks for whether the base linker is GNU ld. Since FreeBSD adopted lld (the LLVM linker) as default, these checks have been obsolete. The commit affects Makefiles across the entire ports tree.

Mailing Lists

IPv6-Only RA: Proposal to Adopt RFC 8925

Pouria Mousavizadeh Tehrani proposed on freebsd-current to remove the experimental implementation of the IETF draft DRAFT_IETF_6MAN_IPV6ONLY_FLAG and adopt RFC 8925 (IPv6-Only preference via DHCP option) instead. The backstory is interesting: Bjoern Zeeb originally proposed marking networks as IPv6-only via an RA flag. The draft was abandoned because RAs can be trivially forged — an attacker could maliciously disable IPv4 networks. Google later submitted the same idea as a DHCP option, which became RFC 8925. Pouria is seeking feedback on removing the draft-specific code paths from the kernel and userland.

Kqueue Panic: knlist Assertions Added

A kernel panic — “knote was already on knlist” — was reported on freebsd-current after build main-n284826. Kyle Evans (kevans91) responded by adding assertions in knlist_add() and knlist_remove_kq() (commit 306c904) to catch such error states earlier and more reliably. The related bug report (Bug 293382) describes deadlocks and crashes around closefp_impl, suggesting the issue involves file descriptor closure and kqueue registration interaction.

When it comes to server operating systems, most people immediately think of Linux. That makes sense: Linux is widely used, has a large ecosystem, and is the default choice in many companies.

Despite that, I have preferred working with FreeBSD for many years. I first started using it around the time of FreeBSD 4, and since then it has remained my first choice for many of the systems I run.

Why?

The short answer: FreeBSD feels like a coherent operating system, while many Linux installations feel more like a collection of separate components.

The longer answer is a bit more interesting.

A complete operating system

One of the main differences between Linux and FreeBSD lies in how the system is structured.

Most Linux distributions are built from components developed by many independent projects:

• the Linux kernel
• GNU userland tools
• an init system
• a package manager
• additional utilities and frameworks

This works well, but it can sometimes lead to inconsistencies between distributions.

FreeBSD takes a different approach. The base system is developed and maintained as one integrated operating system.

The kernel, system utilities, and core components belong together and are released together. As a result, the system feels very consistent in configuration, behavior, and documentation.

This becomes especially valuable when you run servers for many years.

Predictable behavior

One of the most important qualities of a server operating system is predictability.

Servers should ideally be boring: they should run reliably, behave consistently, and not surprise you after updates. Like an aircraft.

In my experience, FreeBSD systems tend to do exactly that. Once properly configured, they usually run quietly in the background for long periods of time.

Updates are generally straightforward, and the system behaves in ways that are easy to understand and anticipate.

For infrastructure that is meant to run for years, this reliability matters a lot.

ZFS as a first-class citizen

Another major reason I appreciate FreeBSD is its excellent integration with ZFS.

ZFS offers features that are extremely useful in everyday server administration:

• snapshots
• simple backup strategies
• data integrity
• flexible storage layouts

For servers handling large amounts of data or running multiple services, ZFS can significantly simplify storage management.

Many of my systems rely on ZFS as the foundation for both storage and backup strategies.

Jails: lightweight service isolation

FreeBSD provides Jails, a very elegant mechanism for isolating services.

Compared to full virtual machines, Jails are extremely lightweight. They allow services to run in isolated environments without requiring a complete operating system for each instance.

This has several advantages:

• lower resource usage
• clear separation of services
• simpler administration

For many server setups, this approach is both efficient and easy to maintain.

Clear structure and solid tooling

Another aspect I appreciate about FreeBSD is the clarity of its system design.

Examples include:

• the traditional rc system for service management
• a consistent configuration approach
• the pkg package management system
• excellent man pages and documentation

When you return to a system months or years later, this clarity makes it much easier to understand how everything fits together.

Practical experience

My preference for FreeBSD is not theoretical.

Over the years I have run many systems based on FreeBSD, including servers providing services such as:

• web applications
• databases
• DNS, DHCP, and NTP
• NFS and Samba
• various applications running inside Jails
• Bhyve as virtualization platform

Some of these systems also involve more complex storage setups using ZFS or virtualization with bhyve.

This long-term practical experience is the main reason why FreeBSD remains my preferred platform for many server workloads.

Conclusion

Linux is an excellent operating system and a great choice in many situations.

However, for many of my own server deployments I still prefer FreeBSD.

The main reasons are:

• a coherent and well-integrated operating system
• predictable and stable behavior
• excellent ZFS integration
• lightweight isolation with Jails
• a clear and consistent system design

Especially for long-running infrastructure, FreeBSD has repeatedly proven itself to be a robust and dependable platform.