Tag: FreeBSD
-
“The FreeBSD Foundation has launched its AI-assisted Vulnerability Discovery Project with the key goal of reducing the number of exploitable vulnerabilities in the FreeBSD source code.”
-
-
The official release announcement will be on June 16th.
-
Happy to see my ZFS commits get upstream to FreeBSD 🙂


-
That means the official 15.1 announcement will be delayed for one week.


-
Happy testing fellow geeks.

-
Many of the security fixes got investigated by AI. Security researchers found with help of AI a remote code execution vulnerability via the FreeBSD installer WiFi access point scans.
“FreeBSD 15.1-RC1 ships with security mitigations for security advisories FreeBSD-SA-26:19 through FreeBSD-SA-26:24. AI-driven security research firm Calif.io along with other parties discovered a kernel use-after-free via file descriptor system calls.”

-
FreeBSD’s website got a new design and it looks beautiful !!!

-
If you’re running FreeBSD on an AM5 board with a recent BIOS update and your system freezes during boot — right after the EFI framebuffer line — you’re probably hitting a firmware bug in AGESA 1.3.0.0a.
The Problem
After updating my Gigabyte B650 GAMING X AX V2 to BIOS F41a (AGESA 1.3.0.0a, released March 2026), FreeBSD stopped booting entirely. All versions — 14.2, 14.4, and 16.0-CURRENT — freeze hard after printing EFI framebuffer information. No panic, no output, complete CPU lockup (caps lock LED goes dead). The same issue has been reported on ASRock X870 boards with Ryzen 9600X on the FreeBSD forums.
Investigation
I built a diagnostic FreeBSD loader with printf calls at every stage of the EFI boot handoff. The results were clear: the hang occurs inside the UEFI firmware’s
ExitBootServices()call. The loader calls into firmware, and firmware never returns.An interesting secondary finding: adding printf (which calls the UEFI
OutputStringboot service) betweenGetMemoryMapandExitBootServicesinvalidates the memory map key. The firmware then hangs on the stale key instead of returning an error — which is itself a firmware bug. Well-behaved firmware should returnEFI_INVALID_PARAMETERand let the caller retry.Attempted Loader Fix
Knowing that stale memory map keys were part of the picture, I wrote a patch for the FreeBSD EFI loader (
stand/efi/loader/bootinfo.c) that:- Pre-allocates the memory map buffer with slack before the retry loop — no more
AllocatePagesinside the loop - Disables the UEFI watchdog timer before calling
ExitBootServices - Keeps the retry loop tight — only
GetMemoryMapfollowed immediately byExitBootServices, with zero intervening boot service calls
This matches the strategy used by the Linux EFI stub, which has had these hardening measures for years.
Unfortunately, the patched loader still hangs on BIOS F41a. The firmware bug in AGESA 1.3.0.0a is not just about stale keys —
ExitBootServicesis fundamentally broken, even with a fresh memory map key.The Fix: Downgrade Your BIOS
The only workaround is to downgrade your BIOS. I flashed back to F37 (AGESA 1.2.0.3g) using Q-Flash, and FreeBSD boots perfectly again. Here’s the full test matrix:
FreeBSD Version Loader BIOS F37 (AGESA 1.2.0.3g) BIOS F41a (AGESA 1.3.0.0a) 14.4-RELEASE Stock Boots Hangs 16.0-CURRENT Stock Boots Hangs 16.0-CURRENT Patched Boots Hangs I avoided BIOS versions F38–F40 (AGESA 1.2.8.0) as there are reports of boot failures on some AM5 boards with that AGESA version as well.
Affected Hardware
- My system: Gigabyte B650 GAMING X AX V2, Ryzen 9 9900X
- Also reported: ASRock X870 + Ryzen 9600X (FreeBSD Forums)
- Likely affected: Any AM5 board shipping AGESA 1.3.0.0a
Next Steps
The loader hardening patch didn’t fix the AGESA bug, but it’s still valid as defensive improvement — it eliminates a class of firmware interaction bugs by keeping the
ExitBootServicesretry loop free of boot service calls. I’ll be submitting it upstream to FreeBSD as a hardening measure.If you’re hitting this issue: downgrade your BIOS to any version before AGESA 1.3.0.0a. For Gigabyte B650 boards, F37 is a safe choice.
- Pre-allocates the memory map buffer with slack before the retry loop — no more
-
Officially an OpenZFS contributor 🙂

https://github.com/openzfs/zfs/commit/a7157221db1d3a7c3517dee98f5124c13a515053









