FreeBSD Wochenrückblick – KW 25 (16.–22. Juni 2026)

Die vergangene Woche gehörte FreeBSD: Mit dem Release von 15.1, einem massiven Security-Advisory-Batch, einem neuen AI-gestützten Schwachstellen-Projekt und dem End-of-Life für 14.3 gab es reichlich zu verarbeiten.

FreeBSD 15.1-RELEASE erschienen

Das wichtigste Ereignis der Woche: Am 16. Juni hat das Release Engineering Team FreeBSD 15.1-RELEASE veröffentlicht. Nachdem ein kritischer Bootloader-Bug auf x86-Systemen das Release um zwei Wochen verschoben hatte, ist die zweite Version des stable/15-Zweigs nun verfügbar.

Wichtigste Neuerungen in 15.1

WiFi-Treiber auf Linux-Kernel-7.0-Stand: Die LinuxKPI-basierten WLAN-Treiber (iwlwifi u.a.) wurden auf den Stand des Linux-Kernels 7.0 aktualisiert. Das bringt deutlich bessere Kompatibilität mit moderner WLAN-Hardware, insbesondere für Intel- und einige MediaTek/Realtek-Chipsätze.

C23-Unterstützung vorangeschritten: Der Compiler und die Standardbibliothek machen weitere Fortschritte bei der Umsetzung des C23-Standards.

Graphics-Treiber auf Linux 6.12 (LTS): Die FreeBSD Foundation hat zeitgleich zum Release bekanntgegeben, dass der drm-kmod-Port nun die Linux-6.12-Grafiktreiber enthält – ein LTS-Kernel, der bis 2036 gepflegt wird (CIP-Programm). Das verbessert die Kompatibilität mit aktuellen AMD-Radeon- und Intel-GPUs und bringt bessere Wayland-Unterstützung. Verfügbar ab FreeBSD 15.1.

Weitere Änderungen in 15.1:

  • OpenPAM in ein separates FreeBSD-pam-Paket ausgelagert (pkgbase)
  • Zstandard/zstd(1) in ein separates FreeBSD-zstd-Paket ausgelagert
  • installworld/installkernel werden auf pkgbase-Systemen blockiert, um Inkonsistenzen vorzubeugen
  • Standard-Shell für root und den freebsd-User in Release-Images ist nun sh(1) statt csh(1)
  • find(1) unterstützt neue Primaries -xattr und -xattrname zur Suche nach Extended Attributes (gesponsert von Klara Systems)
  • newfs(8) verbietet nun die gleichzeitige Nutzung von GEOM-Journaling und Soft Updates; neuer -u-Flag zum Deaktivieren von Soft Updates
  • bectl(8) hat neuen -E-Flag für leere Boot Environments ohne Klonen
  • zfs clone unterstützt -u zum Verhindern des automatischen Mounts
  • ipfs(8) standardmäßig deaktiviert, Kernel-Support nun optional
  • Neue Tastaturlayouts: us.intl.acc.kbd und Lenovo-Laptop-Keymap für vt(4)
  • diff3(1) im Merge-Modus nun kompatibel zu GNU diff3
  • pwd(1) folgt nun standardmäßig -L (logisch), POSIX-konform

Release-Informationen: freebsd.org/releases/15.1R

Neun Security Advisories auf einmal

Am 9. Juni – noch vor dem Release – hat das Security Team neun Advisories gleichzeitig veröffentlicht, darunter mehrere mit kritischen Auswirkungen:

AdvisoryKomponenteKategorieThema
SA-26:25.thrkernel (thr)coreFehlende Berechtigungsprüfung in thr_kill2(2)
SA-26:26.ktlskernel (ktls)coreBeliebiger Datei-Overwrite über KTLS-Receive-Pfad
SA-26:27.soundkernel (sound)coreMehrere Schwachstellen im sound(4) mmap-Pfad
SA-26:29.ip6_multicastkernel (ip6_multi)coreUse-after-free in IPV6_MSFILTER
SA-26:30.linuxkernel (linux)coreFehler in Linuxulator-Ausführung von setugid-Binaries
SA-26:31.arm64kernel (arm64)coreARM-CPU-Errata umgeht Page-Table-Berechtigungsänderungen
SA-26:32.elfkernel (elf)coreASLR-Bypass über procctl(2) bei setuid-Executables
SA-26:34.vtkernel (vt)coreInteger-Overflow in vt(4) CONS_HISTORY-ioctl
SA-26:35.opensslopensslcontribMehrere OpenSSL-Schwachstellen
SA-26:36.ldnsldnscontribUnzureichende Response-Validierung im ldns-Stub-Resolver

Alle Advisories sind in 15.1-RELEASE gepatcht. Nutzer älterer Versionen sollten dringend aktualisieren.

AI-gestütztes Schwachstellen-Projekt gestartet

Die FreeBSD Foundation hat am 15. Juni das AI-assisted Vulnerability Discovery Project angekündigt. Finanziert mit 250.000 USD von der Alpha-Omega-Initiative der Linux Foundation (mit Mitteln von Anthropic, AWS, GitHub, Google, Microsoft und OpenAI) werden Mitglieder des FreeBSD Security Teams unter Zeitverträgen arbeiten, um mit Hilfe von KI-Modellen Schwachstellen proaktiv zu finden und zu beheben.

Kernpunkte:

  • Fokus zunächst auf den Kernel, danach Userland und Ports
  • KI wird nur zur Discovery und Analyse eingesetzt; Patches werden manuell erstellt
  • Netflix, NetApp und Verisign unterstützen bei Testing und Validierung
  • Das Projekt reagiert auf die stark gestiegene Zahl an KI-generierten Vulnerability-Reports

Zeitgleich veröffentlichte Praetorian (Sicherheitsfirma) einen ausführlichen Blogpost über ihre eigene Arbeit: Mit Claude Code (Opus 4.6) fanden sie innerhalb weniger Tage acht FreeBSD-Kernel-Schwachstellen, darunter CVE-2026-3038 (Stack-Overflow in route, bereits in SA-26:05.route gepatcht). Die anderen sieben werden noch bearbeitet. Der Blogpost beschreibt detailliert die Methodik – von der Quellcode-Analyse über Crash-Reproduktion bis hin zur Exploit-Entwicklung mit Jail-Escape.

FreeBSD 14.3 erreicht End-of-Life

Am 20. Juni hat das Security Team angekündigt, dass FreeBSD 14.3 am 30. Juni 2026 End-of-Life erreicht. Danach gibt es keine Sicherheitspatches mehr. Nutzer sollten auf 14.4 oder 15.1 aktualisieren. Der Zweig stable/14 wird noch bis November 2028 gepflegt.

Blog-Beiträge und Community

pkgbasify – Wie man elegant zu pkgbase wechselt: Dag-Erling Smørgrav (blog.des.no) beschreibt seinen eigenen Ansatz, FreeBSD-15.1-Systeme von Distribution-Sets auf pkgbase umzustellen – mit einem einzigen pkg install-Kommando. Er kritisiert dabei das offizielle pkgbasify-Skript der Foundation und bietet eine direktere Alternative. Wer schon immer mal pkgbase ausprobieren wollte, findet hier eine pragmatische Anleitung.

Native inotify in FreeBSD: Klara Systems veröffentlichte einen tiefgehenden Artikel über die Grenzen von EVFILT_VNODE/kqueue für Dateimonitoring und warum FreeBSD eine native inotify-Implementierung braucht. Das bestehende libinotify-Userspace-Wrapper leidet unter Race Conditions und Skalierbarkeitsproblemen – der Artikel erklärt die technischen Details und zeigt Lösungsvorschläge.

ZFS Vendor Import: Chris Longros berichtet, dass seine ZFS-Commits in den FreeBSD-Tree importiert wurden – ein kleiner, aber wichtiger Meilenstein für die kontinuierliche ZFS-Pflege.

Im Quellcode

Ausgewählte Commits der letzten Tage:

  • FORTIFY_SOURCE-Overrides: Kevans implementiert per-File-Overrides für FORTIFY_SOURCE im Build-System – ein Schritt zu robusteren Buffer-Checks im Basissystem
  • rename(2): Kostik Belousov verhindert, dass der Root-VNode eines gemounteten Filesystems umbenannt werden kann (Sicherheitsfix)
  • renameat(2): Signal-Check bei Retry-Schleifen hinzugefügt
  • NFS va_flags Fix: Korrektur für den Fall, dass va_flags gelöscht werden
  • lsof: Fix für den Build auf 16-CURRENT (malloc.h-Konflikt)
  • APEI: Mehr Informationen bei fatalen Hardware-Fehlern

Zusammenfassung

Die Woche war geprägt von FreeBSD 15.1 – einem Release, das spürbar an Laptop- und Desktop-Tauglichkeit gewinnt (WLAN, Grafik, besseres Suspend/Resume). Gleichzeitig zeigt die Flut an Security-Advisories und das neue AI-Vulnerability-Projekt, wie sehr sich die Bedrohungslage verändert: KI-Tools senken die Hemmschwelle für Schwachstellen-Findung drastisch, und FreeBSD rüstet auf. Wer noch auf 14.3 läuft, muss spätestens am 30. Juni handeln.

Meine Nerven heute und in den letzten Jahren oder: Ich habe keinen Bock mehr

Ich muss mal Frust ablassen. Irgendwie geht mir meine „Berufung“ seit jetzt gut fünf Jahren nur noch auf den Senkel. Ach, hätte ich doch was Sinnvolles gelernt.

Alles begann bei der ersten Firma nach Phoenix (dessen Pleite man hätte meiner Meinung nach verhindern können … aber was weiß ich schon). Ich kam in eine Firma, die an einem neuen Datenbankmanagementsystem (DBMS) gearbeitet hat. Weil es davon ja schon etliche gibt, viele kostenlos und super gut, musste sich das Ding natürlich anders nennen. Oder besser: wir mussten es anders nennen, nämlich „Engine“. Letztendlich war das das schlechteste DBMS, das ich je in meinem Leben sah. Völlige Beschränkungen, keine Fehlerabfänge, Code … lass uns nicht darüber reden und benutzen konnte man das Ding meiner Meinung nach überhaupt nicht, es war viel zu kompliziert.

Mir war recht schnell klar, dass die Firma den Bach runter geht, vor allem, da die Expertise von Profis überhaupt nicht beachtet wurde (in dieser Firma begann es auch, dass ich „nur noch“ als Programmieräffchen arbeitete). Man hätte daraus so viel machen können, man machte sich aber lieber daran, Prozesse einzuführen, Meetings zu führen, über Dinge zu reden und nicht am Produkt zu arbeiten (bzw. es wegzuwerfen und vernünftig zu beginnen). Ende Gelände.

Dann kam ich in die nächste Firma als Programmieräffchen (ich habe darüber hier auch geschrieben). Auch hier wurden die Profis nicht nach Expertise gefragt und auch das Projekt konnte nichts werden. Stattdessen musste man laufend irgendeinen alten Mist irgendwie versuchen zu fixen oder im Support Tickets bearbeiten für ein desolates System. Doch nach meinem Weggang stellte man jemanden ein, der das Projekt retten sollte. Ob er noch da ist und wie der Stand ist – keine Ahnung, aber sie hatten letztlich ja schon solche Leute da.

Besser wurde es nach der Kündigung und dem Wechsel in meinen neuen Job auch nicht. Jetzt bin ich ein Turnschuhadminäffchen. Eingestellt eigentlich für Produktentwicklung, allerdings doch niedrigster Rang nach 25 Jahren Expertise und dem Durchführen zahlreicher erfolgreicher Projekte. Ich mache jetzt das, was auch ein Praktikant machen könnte, nur zu höherem Lohn. Versteht mich nicht falsch, die Leute sind nett, aber das Projekt, an dem ich arbeiten sollte und soll (mehr oder weniger, ich mache nur Turnschuadmindinge und völlig sinnlose Tests), ist meiner Meinung nach durch erhebliche Fehlplanung dem Untergang nahe. Man hätte viel früher interagieren müssen, hat niemand getan. Ich habe es jetzt etlichen Leuten geschrieben, dass ich das, was getan wird, absolut kritisch sehe und auch warum. Wird aber abgeschmettert oder es werden auch die Hände überm Kopf zusammengeschlagen, aber getan wird nichts. Bin halt nur das Turnschuhadminäffchen.

Tatsächlich bin ich das erste Mal in meinem Leben an einem Punkt, an dem ich keinen Bock mehr auf die ganze IT-Scheiße habe. Das stimmt nicht ganz, denn auf ein cooles Projekt hätte ich schon richtig Lust. Aber auf das alles, was ich in den letzten Jahren erlebt habe, irgendwie nicht mehr. Es geht, meiner Meinung nach, völlig den Bach runter.

Sorry, ich wollte mich nur einmal auskotzen.

FreeBSD-Wochenrückblick – KW 24 (9.–15. Juni 2026)

Die große Security-Woche: Neun Advisories auf einmal

Die wahrscheinlich wichtigste Entwicklung dieser Woche war der Security-Advisory-Batch vom 9. Juni 2026, der nicht weniger als neun Advisories gleichzeitig brachte – darunter mehrere mit der Kategorie core und teilweise kritischer Auswirkung:

Die schwerwiegendsten Lücken

  • SA-26:25.thr – Fehlende Berechtigungsprüfung in thr_kill2(2). Ein unprivilegierter lokaler Nutzer konnte Signale an beliebige Prozesse senden, auch über Jail-Grenzen hinweg. Entdeckt von Forschern der Tsinghua-Universität mit Hilfe von GLM-5.1 (Z.ai) – ein bemerkenswerter Fall von KI-unterstützter Sicherheitsforschung. CVE-2026-45256
  • SA-26:26.ktls – Beliebiges Datei-Überschreiben über den KTLS-Empfangspfad. Durch KTLS-Entschlüsselung auf nicht-anonymen mbufs (via sendfile(2) + Loopback) konnte ein lokaler Nutzer Dateiinhalte überschreiben, inklusive setuid-Binaries – und damit volle Privilegieneskalation erreichen. Kein Workaround verfügbar. CVE-2026-45257, Kategorie: core.
  • SA-26:27.sound – Zwei mmap-Schwachstellen im sound(4)-Treiber (CVE-2026-45258CVE-2026-49417), die unprivilegierten lokalen Nutzern Lese-/Schreibzugriff auf Kernel-Speicher über /dev/dsp ermöglichten – ebenfalls Privilegieneskalation.
  • SA-26:28.capsicum – sigqueue(2) fehlte eine Capsicum-Modus-Prüfung, wodurch Sandbox-Prozesse Signale an andere Prozesse senden und Capsicum-Einschränkungen umgehen konnten.
  • SA-26:30.linux – Der Linuxulator setzte AT_SECUREfälschlicherweise auf Null für setuid/setgid-Linux-Binaries. Dadurch konnten unprivilegierte Nutzer über LD_PRELOADShared Libraries injizieren und Privilegien eskalieren.
  • SA-26:29.ip6_multicast – Schwachstelle in IPv6-Multicast-Verarbeitung.
  • SA-26:31.arm64 – Arm-CPU-Errata umgehen SeitenTabellen-Änderungen. Betroffen sind zahlreiche Cortex-A/Neoverse-Modelle (A76, A77, A78, A710, X1, X2, X3, X4, N1, N2, V1 u.v.m.). Kein Workaround. CVE-2025-10263
  • SA-26:32.elf – ELF-Verarbeitungsschwachstelle.
  • SA-26:35.openssl – Mehrere OpenSSL-Schwachstellen.

Fazit: Wer FreeBSD im produktiven Einsatz hat, sollte sofort patchen und rebooten – insbesondere die ktls- und thr-Lücken sind kritisch.

FreeBSD 15.1-RELEASE: Morgen geht’s los (endlich!)

Nach zwei ungeplanten Release Candidates wurde FreeBSD 15.1-RC3 am 6. Juni veröffentlicht. Der einzige aber kritische Fix betraf den x86-Bootloader/Kernel-Handover: Das System konnte beim Booten hängen bleiben, insbesondere wenn Intel-Microcode-Updates geladen wurden.

Der RELEASE-Termin steht nun auf 16. Juni 2026 – also morgen, falls nichts dazwischenkommt.

Was 15.1 bringt

Aus den Release Notes geht unter anderem hervor:

  • OpenPAM und Zstandard (zstd) sind in eigene pkgbase-Pakete gewandert
  • installworld/installkernel sind auf pkgbase-Systemen blockiert, um Inkonsistenzen vorzubeugen
  • Default-Shell für root und freebsd-User: jetzt sh(1) statt csh(1)
  • find(1) unterstützt -xattr und -xattrname für Extended-Attribute-Suche
  • bectl(8) hat -E für leere Boot-Umgebungen
  • zfs clone hat -u zum Verhindern automatischer Mounts
  • newfs(8) hat -u zum Deaktivieren von Soft Updates
  • daemon(8) unterstützt konfigurierbare Dateimodi für Log-Ausgabe
  • diff3(1) ist nun GNU-kompatibel im Merge-Modus
  • setaudit(8) als neues Utility für Audit-Richtlinien
  • ipfs(8) ist standardmäßig deaktiviert, Kernel-Unterstützung optional
  • DTrace jetzt mit Probes auf PowerPC
  • sched_ule als Scheduler-Instanz implementiert
  • Aktualisierter OpenZFS-Support
  • Oracle Cloud Infrastructure-Build-Targets entfernt

Grafiktreiber: drm-kmod aktualisiert

Am 10. Juni hat Jean-Sébastien Pédron (dumbbell) die DRM-Treiber im Ports-Tree aktualisiert – die Commit-Nachrichten deuten auf einen Versionswechsel zu Linux 6.12.85 hin (entspricht dem kürzlich releaseden drm_v6.12.85_2). Wer aktuelle Intel/AMD-Grafik braucht, sollte die drm-*-kmod-Pakete aktualisieren.

Blog-Beiträge der Woche

„Native inotify in FreeBSD“ (Klara Systems)

Klara Systems veröffentlichte einen ausführlichen Artikel über die Probleme der Userspace-inotify-Implementierung (libinotify.so) auf FreeBSD. Die Bibliothek übersetzt inotify-Aufrufe in kqueue/EVFILT_VNODE, was zu sporadisch fehlenden CLOSE-Events führt. Der Artikel vergleicht die inotify- und kqueue-APIs und diskutiert, wie eine native Kernel-inotify-Implementierung diese Zuverlässigkeitsprobleme lösen könnte.

„FreeBSD Jails“ (Tom’s IT Cafe, 5. Juni)

Ein weiterer Beitrag, der sich mit FreeBSD Jails als Container-Isolationstechnik befasst – ein Klassiker, der immer wieder aktualisiert wird.

Ports & Packages

  • lang/libobjc2 auf Version 2.3 aktualisiert
  • kf6-*: Portlint-Fixes in der KDE-Framework-6-Reihe
  • Ports-Q2-Branch (2026Q2) wurde Anfang April erstellt und läuft; nächste Aktualisierung auf dem 2026Q2-Branch ist in Vorbereitung

Ausblick

  • 16. Juni: Geplanter RELEASE-Termin für FreeBSD 15.1
  • Q2-Statusbericht: Die Einreichungsfrist für den FreeBSD-Quartalsstatusbericht (April–Juni) war der 14. Juni – der Bericht dürfte in den nächsten Wochen erscheinen
  • Die große Security-Woche zeigt, dass KI-gestützte Sicherheitsforschung zunehmend reale Auswirkungen hat (GLM-5.1 fand die thr_kill2-Lücke)

Das FreeBSD Laptop-Projekt: Wie FreeBSD auf dem Laptop ankommt

FreeBSD auf einem Laptop — für viele war das lange Zeit ein Witz. WLAN? Vielleicht. Grafiktreiber? Hoffentlich. Ruhezustand? Nein. Wer FreeBSD auf einem Laptop betreiben wollte, brauchte Geduld, Leidensfähigkeit und idealerweise Hardware, die zufällig kompatibel war.

Das FreeBSD Laptop-Projekt ändert das. Seit seinem Start im vierten Quartal 2024 arbeitet die FreeBSD Foundation systematisch daran, die Lücken zu schließen, die FreeBSD auf moderner Laptop-Hardware von einer frustrierenden Erfahrung zu einem produktiven Erlebnis machen. Mit einem Budget von über 750.000 USD allein für das erste volle Jahr und einem ähnlichen Investment für 2026 ist das kein Nebenprojekt mehr — es ist eine der größten gezielten Investitionen in die Desktop-Relevanz von FreeBSD.

Was 2025 erreicht wurde

Das erste volle Jahr des Projekts brachte messbare Fortschritte in allen Kernbereichen:

WLAN

FreeBSD 15.0 liefert WiFi 4 und WiFi 5 für Intel- und Realtek-Hardware. Der neue iwx(4)-Treiber bietet eine native Alternative zu iwlwifi(4) für neuere Intel-Chipsätze, und rtwn(4) unterstützt jetzt 802.11ac (VHT) für RTL8812A und RTL8821A. Die Arbeit an WiFi 6 läuft.

Grafik

Die Grafiktreiber wurden auf Linux 6.9 aktualisiert und sind in FreeBSD 15.0 verfügbar (über den drm-latest-kmod-Port). Linux 6.10 ist in Arbeit — und das ist die Mindestversion, die für das Framework Laptop 16″ mit AMD Ryzen AI 300 Serie benötigt wird.

Audio

Zwei neue Werkzeuge — sndctl(8) und mididump(1) — sowie Bugfixes und eine verbesserte automatische Sound-Umleitung für HDA-Soundkarten machen die Audioerfahrung auf Laptops spürbar besser.

Installer

FreeBSD 15.0 kann nun Firmware-Pakete direkt nach der Basisinstallation herunterladen. Und für FreeBSD 15.1 steht ein Meilenstein an: KDE Plasma als Installationsoption direkt im Installer. Statt nach der Installation mühsam einen Desktop aufzusetzen, wird man künftig beim Installieren einfach „KDE Desktop“ ankreuzen können.

Ruhezustand

Modern Standby (S0i3) soll in FreeBSD 15.1 verfügbar werden, Hibernate (S4) möglicherweise in 15.2. Für Laptop-Nutzer ist das entscheidend — ohne funktionierenden Schlafmodus ist ein Laptop nicht praktikabel.

Der Fahrplan für 2026

Die Roadmap für das laufende Jahr ist ambitioniert. Laut dem Phoronix-Bericht vom April 2026 arbeiten die Entwickler daran, die Linux-Grafiktreiber von Version 6.13 bis 6.18 LTS zu portieren. Wenn alles nach Plan läuft, könnte FreeBSD Ende 2026 auf dem Stand des aktuellen Linux-Kernels ~6.19 sein.

Besonders wichtig: Intel Xe-Treiber-Unterstützung. Intels neue Grafikarchitektur für Lunar Lake und Battlemage benötigt den Xe-Treiber, der auf FreeBSD noch nicht verfügbar ist. Ohne ihn sind aktuelle Intel-Laptops mit FreeBSD nicht nutzbar.

Weitere Ziele für 2026:

  • S4 Hibernate — Vollständiger Ruhezustand mit Festplattenverschlüsselung
  • WiFi 6 — Unterstützung für neuere Realtek- und Mediatek-Adapter
  • USB4 und Thunderbolt — Für Docking-Stationen und externe GPUs
  • HDMI-Verbesserungen — Zuverlässige externe Displays
  • UVC-Webcam-Unterstützung — Videokonferenzen auf FreeBSD
  • Bluetooth-Verbesserungen — Kopfhörer, Mäuse, Tastaturen

FreeBSD 15.1 und der KDE-Installer

Der KDE-Desktop-Installer ist der sichtbarste Meilenstein des Laptop-Projekts. Wenn ein neues FreeBSD-System installiert wird, kann man künftig direkt eine grafische Oberfläche mit auswählen — ähnlich wie bei Ubuntu oder Fedora.

Das Test-Setup umfasst bereits Intel- und AMD-Grafik sowie den generischen VESA-Treiber. Ein NVIDIA-Treiber-Auswahlmenü wurde kürzlich zum Installer hinzugefügt, was Desktop-Tests mit NVIDIA-Hardware ermöglicht. VirtualBox- und VMware-Kompatibilität sind als nächste Schritte geplant.

Das ist mehr als eine Bequemlichkeit. Es ist ein Signal: FreeBSD ist nicht mehr nur für Server und Nerd-Laptops. Es will ein Desktop-Betriebssystem sein, das man installieren und nutzen kann, ohne die Kommandozeile zu fürchten.

Unterstützte Hardware

Das Projekt veröffentlicht eine Liste unterstützter Laptops auf GitHub. Sie wächst kontinuierlich, und die Foundation bittet die Community aktiv um Testberichte und Feedback.

Warum das wichtig ist

Man könnte argumentieren, dass FreeBSD ein Server-Betriebssystem ist und Laptop-Unterstützung unnötig. Aber das ignoriert die Realität: Entwickler arbeiten auf Laptops. Administratoren brauchen portable Diagnose-Werkzeuge. Und jedes Betriebssystem, das auf dem Desktop nicht nutzbar ist, verliert Entwickler an die Konkurrenz.

Das Laptop-Projekt ist keine Spielerei. Es ist eine Investition in die Zukunft von FreeBSD als Plattform. Je mehr Menschen FreeBSD auf ihrem Laptop nutzen, desto mehr Entwickler werden es verbessern. Es ist ein positiver Kreislauf, der jetzt in Gang gekommen ist.

Quellen: – FreeBSD Foundation: FreeBSD Closes the Laptop Gap: Year One Project Update – Phoronix: FreeBSD Laptop Project Hopes To Port Newer Linux Graphics Drivers This Year – Phoronix: FreeBSD 15.1 Aims To Have KDE Desktop Installer Option – GitHub: FreeBSDFoundation/proj-laptop

Die Agilitätsfalle: Wenn Prozesse wichtiger werden als das Produkt

In den letzten Jahren habe ich in verschiedenen Unternehmen gearbeitet, die unterschiedlich waren, aber ein gemeinsames Problem hatten: Sie hatten sich in Prozessen verloren. Agilität, Scrum, CI/CD — alles gute Ideen, die in der Praxis zu Selbstzwecken geworden waren. Das Produkt blieb auf der Strecke.

Das ist keine Kritik an agilen Methoden. Es ist eine Beobachtung darüber, was passiert, wenn Methoden von ihren Zielen entkoppelt werden.

Die Verheißung

Agilität verspricht schnelle Anpassung, kurze Feedback-Zyklen, bessere Zusammenarbeit. Scrum verspricht Transparenz, Fokus, kontinuierliche Verbesserung. CI/CD verspricht Qualitätssicherung, automatisierte Tests, zuverlässige Auslieferung. Alles sinnvoll. Alles wünschenswert.

Aber in der Praxis habe ich Folgendes beobachtet: Unternehmen, die von technischen Schulden geplagt waren, konzentrierten sich ausschließlich auf die Einhaltung agiler Prinzipien, anstatt die eigentlichen Probleme anzugehen. Statt die Architektur zu verbessern, Bugs zu fixen oder Features zu entwickeln, führten sie Tools ein und machten Schulungen. Das Team war beschäftigt — aber nicht produktiv.

Die Transformation zum Prozess-Unternehmen

Was passiert, wenn Agilität zum Selbstzweck wird? Ein typisches Szenario:

Die Rollenverschiebung. Plötzlich will niemand mehr Entwickler sein. Alle wollen Product Owner, Scrum Master oder Agilitätcoach sein. Die Titel sind attraktiver, die Meetings sind bequemer als Programmierung, und das Gehalt ist oft besser. Die Zahl der Menschen, die Tickets schieben, wächst. Die Zahl der Menschen, die Code schreiben, schrumpft.

Die Retrospektive als Therapiestunde. Statt über technische Probleme zu sprechen — Bugs, Architektur, Refactoring — wird über Gefühle gesprochen. Jeder muss offenbaren, wie er sich fühlt. Es gibt Spiele. Man muss sich gegenseitig loben. Das Produkt, das eigentlich im Zentrum stehen sollte, kommt nicht mehr vor.

Die Metriken-Dominanz. Velocity, Burndown-Charts, Sprint-Ziele — die Metriken werden zum Ziel. Statt den Kundenwert zu maximieren, wird die Story-Point-Zahl maximiert. Statt Qualität zu liefern, wird Durchsatz geliefert.

Die Abschaffung der Expertise. In einem agilen Team gibt es theoretisch keine Spezialisten. Jeder kann alles. In der Praxis bedeutet das: Niemand ist wirklich gut in etwas. Der Architekt, der die Codebase kennt, ist im Meeting. Der Entwickler, der das Feature bauen könnte, schreibt Tests für eine Software, die ohnehin ersetzt wird.

Das CI/CD-Dilemma

Ein konkretes Beispiel: Ich entwickelte ein Frontend, das zwei Kommandozeilenprozesse startete und überwachte. Eine einfache Software — schnell geschrieben, funktionsfähig, bereit für die Auslieferung. Etwa 4.000 Zeilen C++.

Nach der Fertigstellung hatte ich — wegen schlechtem Management — nichts mehr zu tun. Man schlug vor, dass ich mich mit Testing befassen sollte, da das Produkt in CI/CD integriert werden musste. Drei Aspekte:

  1. Unit- und Integrations-Tests mit Google Test
  2. Statische Codeanalyse mit SonarQube
  3. Automatische GUI-Tests

Ich habe mich über ein halbes Jahr ausschließlich mit Testing beschäftigt. Das Problem: Die Software war fertig. Sie sollte nicht weiterentwickelt werden. Sie war nicht fehleranfällig. Und sie sollte in naher Zukunft durch eine andere Software ersetzt werden.

Trotzdem: Das agile Testmanagement verlangte 70% Code Coverage. Für eine Software mit 4.000 Zeilen, von denen der Großteil GUI-bezogen war. SonarQube fand in den gesamten 4.000 Zeilen genau einen einzigen Bug — einen gelöschten Pointer, der in einem anderen Codesegment erneut aufgerufen wurde. Die restlichen Hinweise betrafen unbedeutende Aspekte wie die Anzahl der Member-Variablen.

Die automatischen GUI-Tests für zwei klickbare Buttons in einer wxWidgets-Anwendung ließen sich implementieren — mit erheblichem Aufwand. Das Ergebnis: Das GUI war vollautomatisch testbar. Die Software selbst war aber keinen Millimeter weitergekommen.

Das ist kein Einzelfall. In einem anderen Projekt wurden Tests für eine Software nachimplementiert, die drei Probleme hatte: mangelhafte Code-Qualität, komplexe Fachverfahren und die bevorstehende Ablösung durch eine komplette Neuimplementierung. Statt die Architektur zu verbessern oder die Ablösung vorzubereiten, wurden Tests geschrieben, die beim nächsten Release obsolet sein würden.

Wenn Testen zur ABM wird

Testing ist wichtig. Aber Testing ist nicht wichtiger als das Produkt. Wenn die Wahl zwischen einem funktionsfähigen Feature und 70% Code Coverage besteht, sollte das Feature gewinnen — besonders wenn die Software ohnehin ersetzt wird.

Das Problem ist nicht CI/CD. Das Problem ist, dass CI/CD zum Ziel wird statt zum Werkzeug. Die Pipeline ist nicht das Produkt. Die Testabdeckung ist nicht das Produkt. Das Produkt ist das Produkt.

In einem gesunden Entwicklungsprozess gibt es ein Gleichgewicht: Man entwickelt Features und sichert sie gleichzeitig durch angemessenes Testing ab. „Angemessen“ ist der Schlüsselbegriff. 70% Coverage für eine stabile, kleine Software, die ersetzt wird, ist nicht angemessen — es ist Verschwendung.

Was eigentlich wichtig ist

Die wichtigste Erkenntnis aus diesen Erfahrungen: Prozesse sind Mittel zum Zweck, nicht der Zweck selbst. Agilität ist ein Werkzeug, um schneller auf Veränderungen zu reagieren. Scrum ist ein Rahmenwerk, um komplexe Projekte zu managen. CI/CD ist eine Methode, um Qualität zu sichern.

Wenn diese Werkzeuge den eigentlichen Zweck verdrängen — die Lieferung eines guten Produkts —, dann haben sie ihre Funktion verfehlt.

Was wirklich zählt:

  1. Das Produkt. Es muss funktionieren. Es muss nützlich sein. Es muss gepflegt werden. Alles andere ist nachrangig.
  2. Die Architektur. Eine gute Architektur macht Entwicklung schneller, nicht langsamer. Technische Schulden abzubauen ist wichtiger als neue Tools einzuführen.
  3. Die Experten. Menschen, die den Code kennen, die Fachverfahren verstehen, die Architektur-Entscheidungen treffen können — sie sind wertvoller als noch so viele Prozess-Beauftragte.
  4. Angemessenes Testing. So viel wie nötig, so wenig wie möglich. Tests sollten das Produkt voranbringen, nicht die Pipeline füllen.

Der Ausweg

Der Ausweg aus der Agilitätsfalle ist einfach, aber nicht leicht: Rückbesinnung auf das Wesentliche.

Hinterfragen. Jeder Prozess, jedes Meeting, jede Metrik sollte die Frage beantworten: Hilft das dem Produkt? Wenn nicht: Weg damit.

Mut zur Einfachheit. Nicht jedes Team braucht Scrum. Nicht jedes Projekt braucht CI/CD. Nicht jede Software braucht 70% Code Coverage. Die Methodik muss zum Projekt passen, nicht umgekehrt.

Technische Exzellenz priorisieren. Bevor man agil wird, sollte man kompetent sein. Eine gute Codebase, eine klare Architektur, eine verständliche Dokumentation — das sind die Grundlagen, auf denen agile Methoden funktionieren können.

Entwickler entwickeln lassen. Die Rolle des Entwicklers ist nicht, Tickets abzuarbeiten. Sie ist, Lösungen zu bauen. Wenn Entwickler die meiste Zeit in Meetings verbringen statt zu programmieren, ist etwas falsch.

Agilität ist eine gute Idee, die schlecht umgesetzt werden kann. Der Test ist einfach: Zählt das, was das Team gerade tut, für den Kunden? Wenn ja — weiter so. Wenn nein —_STOP und nachdenken.

Das ist nicht radikal. Das ist gesunder Menschenverstand. Und der ist in vielen Unternehmen dringender nötig als noch eine Retrospektive.

FreeBSD Wochenrückblick – Kw23/2026 (2.–8. Juni 2026)

Die dritte Release Candidate für FreeBSD 15.1, Kritische x86-Bootloader-Bugs, eine Flut von KI-entdeckten Sicherheitslücken und der Rückblick auf den Frankfurter Hackathon – diese Woche war bei FreeBSD wieder viel geboten.

FreeBSD 15.1-RC3 veröffentlicht – Release verschiebt sich auf Mitte Juni

Das wohl wichtigste Ereignis der Woche: Colin Percival kündigte am 6. Juni FreeBSD 15.1-RC3 an. Der dritte Release Candidate war nötig geworden, weil ein kritischer Bug im x86-Bootloader entdeckt wurde, der das System beim Booten zum Hängen bringen konnte – insbesondere, aber nicht ausschließlich, wenn Intel-Microcode-Updates geladen werden.

Die offizielle Ankündigung warnt ausdrücklich: Beim Upgrade auf RC3 muss der aktualisierte EFI-Bootloader installiert werden. Der ursprünglich für Anfang Juni geplante Release-Termin verschiebt sich damit auf Mitte Juni.

RC2 (vom 31. Mai) hatte bereits PadLock-RNG-Unterstützung für VIA/Zhaoxin-Prozessoren wieder aufgenommen und die Sicherheitsfixes aus SA-26:19 bis SA-26:24 integriert. RC3 baut darauf auf und fügt den kritischen Bootloader-Fix hinzu.

Verfügbar sind Images für amd64, powerpc64(le), armv7, aarch64 (inkl. RPI, PINE64, ROCK64) und riscv64, sowie VM-Images (QCOW2, VHD, VMDK, raw), OCI-Container-Images und Amazon-EC2-AMI-Images.

Sicherheitsadvisories – KI-gestützte Schwachstellenjagd zeigt Wirkung

Die Welle von Sicherheitsadvisories, die Ende Mai veröffentlicht wurde (SA-26:18 bis SA-26:24), dominiert weiterhin die Diskussionen. Bemerkenswert ist, dass ein Großteil dieser Schwachstellen durch KI-gestützte Sicherheitsforschung entdeckt wurde:

SA-26:18.setcred – Stack-Buffer-Overflow via setcred(2)

Eine Schwachstelle im neuen setcred(2)-Systemaufruf ermöglichte einen Stack-Buffer-Overflow, der zur lokalen Privilegieneskalation führen konnte (CVE-2026-45250).

SA-26:19.file – Kernel Use-After-Free über File-Descriptor-Syscalls

Entdeckt von der Firma Calif.io. Ein Use-After-Free im Kernel über Dateideskriptor-Systemaufrufe.

SA-26:20.fusefs – Heap-Overflow in FUSE_LISTXATTR

Entdeckt vom AISLE Research Team. Ein Heap-Overflow im FUSE-Dateisystem-Code.

SA-26:21.ptrace – Fehlende Validierung in ptrace(PTSCREMOTE)

Gefunden von Forschern mit GLM-5.1 von Z.ai. Unprivilegierte lokale Nutzer konnten Berechtigungen auf Root eskalieren.

SA-26:22.libcasper – select(2)-FD-Set-Overflow → Stack-Overflow

Ebenfalls vom AISLE Research Team. Ein Überlauf des Dateideskriptor-Sets in select(2) führte zu einem Stack-Overflow. CVE-2026-39457 und CVE-2026-39461 wurden zugewiesen.

SA-26:23.bsdinstall – RCE über WLAN-Scan beim Installer

Ein sorgfältig gestalteter Netzwerkname (SSID) konnte während des WLAN-Scans in bsdinstall/bsdconfig zur Befehlsausführung führen.

SA-26:24.capnet – Falsche libcapnet-Berechtigungsmanipulation

Unkorrekte Manipulation von Berechtigungslisten in libcap_net konnte die Berechtigungen eines Prozesses erweitern.

Älteres Advisory aus April: SA-26:14.pf – pf-Stack-Overflow über SCTP

Bereits am 29. April veröffentlicht, aber für das Verständnis der aktuellen Welle relevant: Ungültige SCTP-Pakete konnten durch ungebundene Rekursion in pf zu einem Stack-Overflow und Kernel-Panic führen (CVE-2026-7164).

AISLE: Drei setuid-root-Stack-Buffer-Overflows aufgedeckt

Das AISLE Research Team veröffentlichte am 25. Mai einen detaillierten Blogpost über die Entdeckung von drei separaten Stack-Buffer-Overflows in FreeBSD, die alle über denselben grundlegenden Angriffspfad erreichbar waren:

  1. ping6: Der setuid-root-Befehl verlor einen Sicherheitscheck, den das eng verwandte ping-Programm behalten hatte. Ein lokaler Nutzer konnte durch Öffnen vieler Dateideskriptoren und anschließendes Ausführen von /sbin/ping6 Deskriptoren über 1023 erzwingen und damit FD_SET()-Aufrufe ohne Bounds-Check erreichen.
  2. libnv: Derselbe FD_SET-Überlauf in der NV-Code-Bibliothek.
  3. libcasper: Ironischerweise traf der Fehler auch die Capsicum/Casper-Infrastruktur, die eigentlich zur Sandbox-Isolation gedacht ist.

Besonders interessant: Der ping6-Bug war bereits 2002 in ähnlichem Code behoben worden, der entsprechende Guard wurde aber bei einem späteren Refactoring entfernt und nie wiederhergestellt.

Blogposts und Artikel

„An AI audit of FreeBSD“ (blog.calif.io, 28. Mai)

Calif.io veröffentlichte einen umfassenden Rückblick auf ihre KI-gestützte Audit-Kampagne gegen FreeBSD. Ergebnis: 15 Kernel-Bugs, darunter 3 Remote Code Execution (RCE), 5 Local Privilege Escalation (LPE) und 1 bhyve-Escape. Der Blogpost dokumentiert den Prozess und die Ergebnisse im Detail.

„CVE-2026-7270: How I Get Root on FreeBSD with a Shell Script“ (blog.calif.io, 7. Mai)

Ein weiterer Calif.io-Artikel, der demonstriert, wie ein einzelnes Shell-Skript ausreichte, um Root-Zugriff auf einem FreeBSD-System zu erlangen.

AISLE: „AISLE matches Anthropic Mythos on FreeBSD zero-days“ (6. Mai)

AISLE berichtet, dass sie drei der acht FreeBSD-Sicherheitsadvisories aus April 2026 unabhängig reproduzieren konnten, die auch von Nicholas Carlini bei Anthropic (Claude Mythos) gefunden wurden.

AISLE: „AISLE Finds 21-Year-Old FreeBSD RCE Hidden in dhclient“ (7. Mai)

CVE-2026-42511: Eine 21 Jahre alte Remote-Code-Execution-Schwachstelle in dhclient, bei der das BOOTP-Dateifeld nicht korrekt escaped wurde und so beliebige dhclient.conf-Direktiven injiziert werden konnten.

Frankfurt Area FreeBSD Hackathon Recap (FreeBSD Foundation, 2. Juni)

Die FreeBSD Foundation veröffentlichte den Rückblick auf das erste regionale Hackathon im Frankfurter Raum (24.–26. April). Ergebnisse: 120 geschlossene Bug-Reports, erfolgreiche Implementierung von SBOM-Funktionalität (Software Bill of Materials) und eine deutsche Übersetzung von Sylve.

„FreeBSD May 2026 Security Batch – An Operator’s Triage Guide“ (maxiujun.com)

Eine praktische Triage-Anleitung für Admins: Von den sieben gleichzeitig veröffentlichten Advisories sind zwei kernel-seitig und trivial durch lokale Nutzer ausnutzbar – diese sollten zuerst gepatcht werden.

Mailinglisten-Diskussionen

mtree(1) POLA-Verletzung

Gleb Smirnoff wies auf der freebsd-current-Liste darauf hin, dass der aktuelle Import von mtree(1) aus NetBSD eine POLA-Verletzung (Principle of Least Astonishment) darstellt: Das Verhalten bei Prüfsummen hat sich geändert. Jose Luis Duran und Xin LI diskutierten mögliche Korrekturen; ein Differential (D56013) wurde eingereicht, um fehlende Einträge nachzuziehen.

15.1-Release-Planung

Die Mailinglisten zeigen die typische Endphase-Aktivität: RC1, RC2 und RC3 wurden jeweils mit Ankündigungen auf freebsd-stable veröffentlicht. Die Verzögerung durch die zusätzlichen Release-Kandidaten wird auf den Listen gemischt aufgenommen – Verständnis für die Sicherheitslücken, aber auch Ungeduld beim Warten auf den finalen Release.

Ausblick

  • BSDCan 2026 und das FreeBSD Developer Summit finden am 17.–18. Juni in Ottawa, Kanada, statt.
  • FreeBSD 15.1-RELEASE wird voraussichtlich Mitte Juni erscheinen, sofern keine weiteren kritischen Probleme auftauchen.
  • Die KI-gestützte Sicherheitsforschung (Calif.io, AISLE, Anthropic Mythos) hat sich als ernstzunehmende Kraft etabliert – weitere Funde sind zu erwarten.

FreeBSD-Wochenrückblick: 25. Mai – 1. Juni 2026

Diese Woche war eine der security-intensivsten Wochen in der jüngeren FreeBSD-Geschichte. Zwischen KI-entdeckten Schwachstellen, einem neuen Release-Kandidaten und der Executive Directorin, die FreeBSD auf einem Laptop daily-drived, gab es viel zu besprechen.

FreeBSD 15.1-RC1 veröffentlicht

Am 29. Mai veröffentlichte Colin Percival den ersten Release-Kandidaten für FreeBSD 15.1. Der RC1 enthält eine Reihe von Security-Fixes (dazu unten mehr), Verbesserungen am fwget-Firmware-Tool sowie kleinere Kernel-Bugfixes und Manpage-Updates.

Die 15.1-RELEASE ist für Juni geplant, vorausgesetzt, es tauchen keine weiteren Überraschungen auf. Bisher lief der Release-Zyklus relativ glatt: BETA1 kam am 2. Mai, und der RC1 ist der bisher letzte Meilenstein.

Download: https://download.freebsd.org/releases/ISO-IMAGES/15.1/

Sicherheitsadvisories: Der Mai 2026 Batch

Am 20. Mai veröffentlichte FreeBSD sieben Security-Advisories auf einen Schlag — genug, um selbst erfahrene Operatoren ins Schwitzen zu bringen. Xiujun Ma hat eine hervorragende Triage-Anleitung veröffentlicht, die ich jedem Administrator empfehle.

Die beiden kritischsten:

SA-26:18.setcred — Kernel-Level RCE

Die setcred(2)-Systemfunktion kopiert eine benutzerdefinierte Liste ergänzender Gruppen in einen Kernel-Stack-Buffer fester Größe — ohne die Länge zu prüfen. Das Ergebnis: Ein Stack-Overflow im Kernel, der beliebige Codeausführung auf Kernelebene ermöglicht. Jeder lokale Nutzer kann das ausnutzen, keine spezielle Konfiguration nötig, alle unterstützten FreeBSD-Versionen betroffen. Sofort patchen.

SA-26:21.ptrace — Lokale Privilegieneskalation (CVE-2026-45253)

Fehlende Parametervalidierung in der PT_SC_REMOTE-ptrace-Operation ermöglicht es unprivilegierten lokalen Nutzern, beliebige Systemaufrufe innerhalb eines Zielprozesses auszuführen. Lokal → Root. Auf Multi-User-Systemen und Jail-Hosts ebenfalls sofort patchen.

Die weiteren fünf Advisories:

AdvisoryProblemDringlichkeit
SA-26:24.cap_netCapsicum-Berechtigungslimit kann umgangen werdenDiese Woche
SA-26:22.libcasperStack-Overflow via select(2) bei >1024 Filedeskriptoren (CVE-2026-45252)Diese Woche
SA-26:23.bsdinstallRoot-RCE über böswillige WLAN-SSIDs beim Scannen (CVE-2026-45255)Vor nächster Installation
SA-26:20.fusefsKernel-Heap-Disclosure/Injection über bösartigen FUSE-DaemonNur wenn fusefs.kogeladen
SA-26:19.filefile(1) / libmagic-ProblemDiese Woche

KI-entdeckte Schwachstellen: Calif.io und AISLE

Das ist die große Geschichte dieser Woche: KI-Systeme finden jetzt aktiv FreeBSD-Kernel-Bugs.

Calif.io — „An AI Audit of FreeBSD“

Das Sicherheitsforschungsunternehmen Calif.io hat einen ausführlichen Blogpost veröffentlicht, der ihre KI-gestützte Audit des FreeBSD-Kernels beschreibt. In wenigen Wochen fand die KI:

  • 5 lokale Privilegieneskalationen
  • 1 bhyve Guest-to-Host-Escape
  • Eine Handvoll Memory Disclosures und DoS-Bugs

Insgesamt 15 Kernel-Bugs, alle an das FreeBSD-Security-Team gemeldet. Bemerkenswert ist der Ansatz: Calif.io hat sich mit dem FreeBSD-Team abgestimmt, sich auf deren Prioritäten fokussiert und nur High/Critical-Bugs gemeldet — keine CVE-Jagd, sondern gezielte Hilfe.

Zu den veröffentlichten Exploits gehört setcred (CVE-2026-45250): Ein Ein-Zeichen-sizeof-Fehler in kern_setcred_copyin_supp_groups wird zu einem Stack-Overflow, der zu einer lokalen Root-Shell führt. Nur FreeBSD 14.4 ist ausnutzbar, obwohl der gleiche Bug in 14.3 und 15.0 vorhanden ist.

AISLE — Autonome Schwachstellenforschung

Das AISLE Research Team hat ebenfalls zugeschlagen. Am 25. Mai veröffentlichten sie einen Bericht über drei Stack-Buffer-Overflows in ping6libnv und libcasper — alle über denselben grundlegenden Mechanismus erreichbar: FD_SET()mit Filedeskriptoren >1023.

Der ping6-Bug ist besonders pikant: Das Binary läuft setuid-root, also kann jeder lokale Nutzer den Schwachstellenpfad in einem Prozess mit effektiver UID 0 triggern. Ironischerweise hatte FreeBSD genau diese Fehlerklasse 2002 schon einmal in verwandtem Code behoben — die Schutzmaßnahme in ping6 verschwand aber bei einem späteren Refactoring und kam nie zurück.

AISLE hat außerdem einen 21 Jahre alten RCE in dhclient (CVE-2026-42511) entdeckt und berichtet, dass ihr autonomes System drei der acht April-Security-Advisories unabhängig gefunden hat — auf Augenhöhe mit Anthropics „Claude Mythos“.

Deb Goodkin daily-drived FreeBSD auf einem Framework-Laptop

Deb Goodkin, Executive Director der FreeBSD Foundation seit 2005, hat auf der Open Source Summit + ELC NA 2026 in Minneapolis über ihre Erfahrungen mit FreeBSD als Daily-Driver auf einem Framework-Laptop gesprochen. Bisher lief bei ihr — wie bei vielen — ein anderes OS auf dem Laptop, weil FreeBSD „wie ein Berg“ wirkte.

Ihre Erkenntnisse:

  • Touchscreen funktionierte sofort
  • KDE-Desktop lief stabil
  • Peripherie wie WLAN-Maus klappte problemlos
  • Zoom funktionierte nach einigem Suchen
  • Webcam brauchte manuelle Einrichtung
  • Microsoft Teams funktionierte nur teilweise

Das passt zum laufenden Laptop Integration Testing Project der Foundation, das 2026 die Grafik- und WLAN-Treiberlücke zu Linux schließen will.

NVIDIA-Treiber-Update

Der NVIDIA-Grafiktreiber in den FreeBSD-Ports wurde auf Version 595.71.05 aktualisiert. Wer NVIDIA-Hardware unter FreeBSD betreibt, sollte die Port-Aktualisierung einplanen.

Mailinglisten-Diskussionen

  • Boot-Probleme: Es gab mehrere Berichte über Boot-Zeit-Probleme und Hänger bei 15.1-Installationen, insbesondere im diskless-Betrieb. Die Diskussionen auf freebsd-stableund freebsd-current sind noch im Gange.
  • 15.1-BETA1-Pkgbase-Fingerprint-Problem: Graham Perrin meldete ein Problem mit den Fingerabdrücken der Basispakete in 15.1-BETA1, das Colin Percival zur Kenntnis genommen hat.

OpenBSD 7.9 (Nachbar-Notiz)

Am 30. Mai wurde OpenBSD 7.9 veröffentlicht — mit Unterstützung für bis zu 255 CPU-Kerne und WiFi 6. Nicht direkt FreeBSD, aber für alle BSD-Interessierten erwähnenswert.

Fazit der Woche

Die große Erkenntnis: KI-gestützte Sicherheitsforschung ist kein theoretisches Konzept mehr, sondern findet aktiv Kernel-Bugs in FreeBSD. Gleichzeitig zeigt die Kooperation zwischen Calif.io/AISLE und dem FreeBSD-Team, wie das konstruktiv aussehen kann — kurze Reports, vorgeschlagene Patches, direkte Kommunikation statt CVE-Zahlen-Jagd.

Die 15.1-RELEASE rückt näher und bringt alle diese Fixes mit. Wer Multi-User-Systeme betreibt, sollte SA-26:18.setcred und SA-26:21.ptrace sofort patchen — die restlichen Advisories diese Woche.

FreeBSD-Wochenrückblick: 19.–25. Mai 2026

Die vergangene Woche war eine der ereignisreichsten für FreeBSD seit Langem: Sechs Sicherheitslücken wurden gleichzeitig veröffentlicht, FreeBSD 15.1 erreichte den Release-Candidate-Status, und die FreeBSD Foundation zeigt sich von der eigenen Desktop-Nutzung überrascht.

FreeBSD 15.1-RC1 veröffentlicht

Am 22. Mai gab Colin Percival die Veröffentlichung von FreeBSD 15.1-RC1 bekannt — der erste und voraussichtlich letzte Release Candidate vor dem geplanten Final Release Anfang Juni. RC1 steht für amd64, powerpc64, powerpc64le, armv7, aarch64 (inkl. RPI, PINE64, PINEBOOK, ROCK64, ROCKPRO64) und riscv64 zur Verfügung.

Die Änderungen seit Beta 3 umfassen:

  • Die sechs neuen Security Advisories SA-26:18 bis SA-26:24 (siehe unten)
  • Verbesserungen an fwget(8) zur automatischen Erkennung benötigter Firmware für weitere WLAN-Karten
  • EC2 „small“-Instanzen führen firstboot_pkgs nicht mehr standardmäßig aus
  • freebsd-update fragt nicht mehr nach dem Merge von /etc/ssl/cert.pem
  • Diverse Kernel-Bugfixes und Manpage-Updates

Der gesamte Satz an Installations-Images, VM-Images (QCOW2, VHD, VMDK, Raw), OCI-Container-Images und EC2-AMI-Images steht auf den üblichen Download-Mirrors bereit.

Schwere Sicherheitswoche: Sechs Advisories gleichzeitig

Am 20. Mai veröffentlichte das FreeBSD Security Team gleich sechs Security Advisories — und gleich mehrere davon wurden durch KI-gestützte Schwachstellensuche entdeckt.

SA-26:18.setcred — Stack-Buffer-Overflow (CVE-2026-45250, kritisch)

Die schwerwiegendste Schwachstelle der Woche. Ein sizeof-Typfehler in kern_setcred_copyin_supp_groups()(sys/kern/kern_prot.c) führt zu einem Kernel-Stack-Buffer-Overflow im setcred(2)-Systemaufruf. Die Fehlerkette: sizeof(*groups) ergibt 8 Bytes (Zeigergröße) statt der erwarteten 4 Bytes (sizeof(gid_t)). Ein unprivilegierter lokaler Nutzer kann damit Root-Rechte erlangen — sogar auf Systemen mit SMAP/SMEP. Die Schwachstelle wurde von Przemyslaw Frasunek unter dem Namen „FatGid“ veröffentlicht und betrifft FreeBSD 14.3, 14.4 und 15.0.

Betroffen: 14.3 (behoben in p14), 14.4 (behoben in p5), 15.0 (behoben in p9). FreeBSD 13.x und früher sind nicht betroffen, da setcred(2) dort nicht existiert.

SA-26:19.file — Kernel Use-After-Free

Fehlerhafter Dateideskriptor-Systemaufruf kann zu Use-After-Free im Kernel führen. Entdeckt von Calif.io (KI-gestützte Schwachstellensuche).

SA-26:20.fusefs — Heap-Overflow in FUSE_LISTXATTR

Der Kernel verarbeitet erweiterte Attributlisten von Userspace-FUSE-Daemons ohne korrekte NUL-Terminierungsprüfung. Entdeckt vom AISLE Research Team (autonome Schwachstellensuche).

SA-26:21.ptrace — Fehlende Validierung in ptrace(PTSCREMOTE)

Fehlende Eingabevalidierung ermöglicht unprivilegierten lokalen Nutzern die Eskalation zu Root. Entdeckt mit GLM-5.1 von Z.ai.

SA-26:22.libcasper — Stack-Overflow über select(2)

Überlauf des Dateideskriptor-Sets in select(2) innerhalb von libcasper führt zu Stack-Overflow. Entdeckt vom AISLE Research Team.

SA-26:23.bsdinstall — Remote Code Execution über WLAN-Scan

Ein speziell gestalteter Netzwerkname (SSID) kann während des WiFi-Scans in bsdinstall und bsdconfig zur Ausführung beliebiger Befehle führen. Praktisch relevant bei der Installation in WLAN-Umgebungen.

SA-26:24.cap_net — Falsche Berechtigungsmanipulation

Fehlerhafte Manipulation von Limitierungslisten in libcap_net kann die Berechtigungen eines Prozesses erweitern. Entdeckt vom AISLE Research Team.

Fazit: Bemerkenswert ist, dass mehrere dieser Schwachstellen durch KI-basierte Werkzeuge entdeckt wurden (Calif.io, GLM-5.1, AISLE Research Team). Dies markiert einen Wendepunkt im Sicherheitsaudit von Betriebssystemen.

FreeBSD 15.1 Beta 3 (17. Mai)

Die dritte Beta von FreeBSD 15.1 brachte am vergangenen Wochenende ebenfalls wichtige Neuerungen:

  • OpenZFS 2.4.2 wurde integriert (Bugfixes und Verbesserungen)
  • Cloud-Images führen nun automatisch pkg upgrade beim ersten Boot durch, um Sicherheitsupdates anzuwenden
  • Kerberos wurde aktualisiert
  • Scripted bsdinstall-Installationen nutzen nun pkgbase
  • Geplantes KDE-Desktop-Installationsprofil wurde auf FreeBSD 15.2 verschoben, da das Skript noch an neue NVIDIA-Treiber und veraltete Teile angepasst werden muss

FreeBSD Foundation Executive Director täglich FreeBSD auf Laptop

Deb Goodkin, Executive Director der FreeBSD Foundation seit 2005, berichtete auf der Open Source Summit North America (OSS 2026) in Minneapolis über ihre Erfahrungen, FreeBSD erstmals als tägliches Betriebssystem auf einem Framework-Laptop zu nutzen. Bisher hatte sie FreeBSD jedes Mal als „Berg“ empfunden, wenn sie es auf Laptops probierte. Mit der KDE-Desktop-Umgebung funktionierte der Touchscreen sofort, ebenso Peripheriegeräte. Probleme blieben jedoch: Zoom funktionierte nur nach Aufwand, die Webcam benötigte manuelle Schritte, und Microsoft Teams funktionierte nur teilweise. Ein ermutigendes Zeichen, aber auch ein ehrlicher Blick auf den noch bestehenden Nachholbedarf im Desktop-Bereich.

Community und Blogbeiträge

Per-Jail Package Repository Selection (Ian Wagner)

Ian Wagner veröffentlichte einen hilfreichen Blogbeitrag über die Konfiguration unterschiedlicher Package-Repositorien pro Jail unter FreeBSD. Mit AppJail lassen sich Jails deklarativ verwalten, und der Beitrag zeigt, wie man spezifische Jails auf den latest-Zweig der Ports umstellt, wenn man aktuellere Pakete benötigt, während andere beim quarterly-Zweig bleiben.

FreeBSD Resource Monitoring, Accounting, and Troubleshooting (Larvitz Blog)

Ein ausführlicher Beitrag über Ressourcenüberwachung und Fehlerbehebung auf FreeBSD-Systemen — von „der Server fühlt sich langsam an“ bis hin zu konkreten Diagnosewerkzeugen.

Migration von Ubuntu 16.04 zu FreeBSD

Ein Blog, der 10 Jahre auf Ubuntu 16.04 lief, berichtete über die Migration zu FreeBSD — motiviert durch das Ende des Lebenszyklus von Ubuntu 16.04 und die Aussicht auf langfristige Stabilität.

Valuable News — 18. Mai (vermaden)

Die wöchentliche Linksammlung von vermaden bietet wie immer einen guten Überblick über BSD- und UNIX-relevante Artikel der Woche.

Mailinglisten-Diskussionen

pkgbase-Upgrade von 15.0 auf 15.1

Die Diskussionen um den pkgbase-Upgrade-Pfad von 15.0-RELEASE auf 15.1-BETA2 zeigen, dass der Übergang zur neuen Standard-Installationsmethode noch nicht ganz reibungslos verläuft. Probleme mit Kernel-Modulen (kmods) und der pkgbase-quarterly-Repos wurden ausführlich diskutiert.

Boot-Time Bugs auf freebsd-stable

Garrett Wollman berichtete über Probleme beim Booten seiner Server-Flotte und löste eine Diskussion über Boot-Time-Verhalten und Fehlerbehandlung aus.

Diskless-Systeme mit 15.1

Daniel Braniss und Bjoern Zeeb diskutierten Probleme mit diskless-Setups unter FreeBSD 15.1, die zum Hängen führen können.

Ausblick

Wenn alles nach Plan verläuft, erscheint FreeBSD 15.1-RELEASE voraussichtlich am 2. Juni 2026. Das KDE-Desktop-Installationsprofil wird auf 15.2 (erwartet im Dezember) verschoben. Bis dahin bleibt die manuelle Installation über pkg der empfohlene Weg.

FreeBSD-Wochenrückblick: 11.–17. Mai 2026

Die Woche war geprägt von der dritten Beta von FreeBSD 15.1, einer wichtigen Sicherheitslücke in execve(), Diskussionen über die KDE-Desktop-Installation und der Verschiebung dieses Features auf 15.2, sowie zwei libnv-Sicherheitslücken, die Ende April offengelegt wurden und nach wie vor Aufmerksamkeit verdienen. Hier ist der Überblick.

FreeBSD 15.1 Beta 3 veröffentlicht

Am Wochenende wurde FreeBSD 15.1-BETA3 als neuester Testkandidat veröffentlicht. Das Release rückt damit in die heiße Phase — nächste Woche wird der Release Candidate (RC) erwartet, und wenn alles glatt läuft, soll FreeBSD 15.1-RELEASE am 2. Juni 2026erscheinen.

Die wichtigsten Änderungen in Beta 3:

  • OpenZFS 2.4.2 wurde integriert — die neueste OpenZFS-Version mit diversen Fehlerkorrekturen und kleinen Verbesserungen.
  • Cloud-Images führen nun beim ersten Boot automatisch pkg upgrade durch, um Sicherheitsupdates des Basissystems anzuwenden. Das ist ein sinnvoller Schritt für Cloud-Deployments, die oft aus veralteten Images starten.
  • Kerberos wurde aktualisiert.
  • bsdinstall nutzt bei skriptgesteuerten Installationen jetzt pkgbase.

Die Beta-Phase lief bisher relativ ruhig — BETA1 und BETA2 in den Wochen davor brachten vor allem Zstd 1.5.7, Fehlerkorrekturen in ifconfig, lockf, stat, tail, certctl sowie Kernel-Fixes für nullfs, so_splice und VT.

Rückblick BETA2 (8. Mai)

  • Update auf Zstd 1.5.7
  • bsdinstall nutzt nun konsistent pkg.freebsd.org für Package-Bootstrap
  • Diverse Userland- und Kernel-Fixes

Kritische Sicherheitslücke in execve() — CVE-2026-7270

Eine ernste Sicherheitslücke im Kernel wurde Ende April veröffentlicht und hat diese Woche weiterhin Diskussionsstoff geliefert. FreeBSD-SA-26:13.exec beschreibt einen Operator-Vorrang-Fehler (operator precedence) in der Implementierung von execve(2), der zu einem Pufferüberlauf führt. Angreiferkontrollierte Daten können in angrenzende Argument-Puffer überschreiben und Kernel-Zustand korrumpieren, was zur Erlangung von Root-Rechten durch unprivilegierte Nutzer führen kann.

Die Lücke betrifft alle unterstützten FreeBSD-Versionen (13.5 bis 15-Branch). Patches wurden innerhalb von Stunden veröffentlicht, und die Behebung besteht im Hinzufügen expliziter Klammern zur Durchsetzung der beabsichtigten Auswertungsreihenfolge sowie einer Verschärfung der Größenprüfungen.

Reaktionen der Community

  • Positiv: Rasche Reaktion — das Advisory erschien weniger als eine Stunde nach Entdeckung des Fehlers, Patches für alle Zweige waren am selben Tag verfügbar.
  • Kritisch: Es gibt keinen Workaround. Administratoren, die keinen sofortigen Reboot durchführen können (z. B. bei High-Availability-Systemen), bleiben verwundbar.
  • Quellcode-basierte Installationen erfordern Kernel-Rekompilierung und Reboot, was auf älterer Hardware Stunden dauern kann.

Zwei libnv-Sicherheitslücken (SA-26:16 und SA-26:17)

Ebenfalls am 29. April wurden zwei Sicherheitslücken in libnv veröffentlicht, die weiterhin relevant sind:

  • SA-26:16 (CVE-2026-39457): Stack-Overflow über select() — wenn ein Socket-Deskriptor größer als FD_SETSIZE (1024) ist, wird der Dateideskriptor-Satz von select(2) überlaufen. Ein Angreifer, der ein Programm dazu bringen kann, viele Dateideskriptoren zu öffnen, kann einen Stack-Overflow auslösen und bei setuid-Root-Programmen lokale Privilegien eskalieren. Entdeckt von Joshua Rogers (AISLE Research Team).
  • SA-26:17 (CVE-2026-35547): Heap-Overflow in libnv — die Nachrichtengröße wird beim Verarbeiten des Headers nicht korrekt validiert, was Schreiben außerhalb der Heap-Allokation ermöglicht. Dies kann Abstürze, Panics oder mögliche Privilegieneskalation durch unprivilegierte Nutzer verursachen. Entdeckt von Mariusz Zaborski.

Beide Lücken betreffen alle unterstützten FreeBSD-Versionen und haben keinen Workaround. Ein Upgrade und Reboot ist zwingend erforderlich.

KDE-Desktop-Installation verschoben auf FreeBSD 15.2

Die lang erwartete KDE-Desktop-Option im FreeBSD-Installer wurde erneut verschoben — diesmal von 15.1 auf 15.2 (voraussichtlich Dezember 2026). Ursprünglich für 15.0 geplant, dann auf 15.1 verschoben, muss das Skript wegen neuer NVIDIA-Treiber aktualisiert und veraltete Teile entfernt werden. Nach dem Commit in CURRENT wird eine Testphase in STABLE benötigt, was den Zeitrahmen für 15.1 nicht mehr einhält.

Bis dahin bleibt der manuelle Weg: KDE Plasma nach der Installation via pkg aufsetzen.

Mailinglisten-Diskussionen

Update-Strategie und Timing (freebsd-current)

Bob Prohaska startete eine Diskussion über bevorzugte Update-Strategien für selbst gehostete FreeBSD-Systeme. Auf stable-Zweigen ist die Sache einfach: freebsd-update nutzen. Auf current wird es komplexer. Warner Losh, Rick Macklem, Mark Millard und andere diskutierten die Vor- und Nachteile verschiedener Ansätze — eine nützliche Lektüre für jeden, der current im Produktivbetrieb nutzt.

PKGBASE: Upgrade von 15.0 auf 15.1-BETA2

Vermaden fragte nach dem Upgrade-Pfad von FreeBSD 15.0-RELEASE auf 15.1-BETA2 im PKGBASE-Modell. Colin Percival bestätigte, dass dieser Pfad noch nicht vollständig dokumentiert ist. Das PKGBASE-System ist weiterhin als experimentell markiert, und der Minor-Upgrade-Pfad benötigt noch Arbeit.

Beach Cleaning Project: Infrastruktur-Aufräumung

Die FreeBSD Foundation veröffentlichte Ende April einen ausführlichen Bericht zum Beach Cleaning Project, der auch diese Woche noch Aufmerksamkeit erhält. Das Projekt zielt darauf ab, die Sicherheitsresilienz des FreeBSD-Basissystems zu verbessern:

  • Maschinenlesbares Inventar von über 1.000 Komponenten im Basissystem, darunter 73 Third-Party-Komponenten
  • OpenSSL 3.5 LTS wurde rechtzeitig für FreeBSD 15.0 integriert (statt OpenSSL 3.0, das im September 2026 EOL erreicht)
  • SBOM-Generierung (Software Bill of Materials) im SPDX 2/3-Format
  • CODEOWNERS-ähnliche Berichte für bessere Wartbarkeit
  • Vorbereitung auf den Import von pkg ins Basissystem als Teil des pkgbase-Übergangs

Gefördert wurde das Projekt von Alpha-Omega.

Blogbeiträge der Woche

Vermaden: FreeBSD PKGBASE Minor Upgrades

Vermaden veröffentlichte einen praktischen Leitfaden zum Upgrade von FreeBSD 15.0 auf 15.1-BETA2 mit PKGBASE und ZFS Boot Environments. Der Artikel zeigt Schritt für Schritt, wie man eine neue BE erstellt, pkg-Repository konfiguriert, das Basissystem aktualisiert und bei Problemen zurückkehren kann — inklusive eines alternativen Wegs mit --chroot.

Going Back to BSD

Pete veröffentlichte einen persönlichen Blogbeitrag über seine Rückkehr zu BSD nach Jahrzehnten mit Linux. Er beschreibt den Wechsel von Linux (Arch) zu FreeBSD, die Einrichtung von Mailservern mit Bastille-Jails und die erfrischende Einfachheit des rc-Systems im Vergleich zu systemd. Ein nostalgischer und praktischer Bericht.

Ausblick

Die nächste Woche steht im Zeichen des Release Candidates für FreeBSD 15.1. Wenn keine unerwarteten Probleme auftreten, wird das finale Release am 2. Juni 2026 erwartet. Administratoren sollten dringend die drei Sicherheitslücken (execve, libnv x2) patchen, falls noch nicht geschehen.

Quellen: PhoronixFreeBSD MailinglistenFreeBSD Security AdvisoriesFreeBSD FoundationVermaden BlogLavX Newspeteftw.com