CVE-2026-63825 in Linux
Zusammenfassung
von VulDB • 19.07.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
gcov: Atomare Zähleraktualisierungen verwenden, um Abstürze durch gleichzeitigen Zugriff zu beheben
Die GCOV-Instrumentierung von GCC kann globale Branch-Zähler mit Schleifen-Induktionsvariablen als Optimierung zusammenführen. In `inflate_fast()` werden die inneren Kopierschleifen so transformiert, dass der Wert des GCOV-Zählers mehrfach geladen wird, um die Basisadresse, den Startindex und die Obergrenze der Schleife zu berechnen. Da GCOV-Zähler global sind (nicht pro-CPU), führt eine parallele Ausführung auf verschiedenen CPUs dazu, dass sich der Zähler zwischen den Ladevorgängen ändert, was inkonsistente Werte und Speicherzugriffe außerhalb des gültigen Bereichs (out-of-bounds) zur Folge hat.
Der Absturz tritt während der IPComp-Verarbeitung (IP Payload Compression) auf, wenn `inflate_fast()` parallel auf mehreren CPUs ausgeführt wird:
BUG: unable to handle page fault for address: ffffd0a3c0902ffa RIP: inflate_fast+1431 Call Trace: zlib_inflate __deflate_decompress crypto_comp_decompress ipcomp_decompress [xfrm_ipcomp]
ipcomp_input [xfrm_ipcomp]
xfrm_input
An der Absturzstelle generierte der Compiler drei Ladevorgänge aus demselben globalen GCOV-Zähler (`__gcov0.inflate_fast+216`), um Basis, Start und Ende für eine indizierte Schleife zu berechnen. Eine andere CPU änderte den Zähler zwischen den Ladevorgängen, wodurch die Werte inkonsistent wurden – der Schreibzugriff erfolgte 3,4 MB hinter einem 65 KB großen Puffer.
Fügen Sie `-fprofile-update=prefer-atomic` auf globaler Ebene in der Makefile im obersten Verzeichnis zu `CFLAGS_GCOV` hinzu, geschützt durch einen Kompilierungstest mit Try-Run. Der Test kompiliert ein minimales Programm mit und ohne `-fprofile-update=prefer-atomic` unter Verwendung von `KBUILD_CFLAGS` vollständig und vergleicht dann undefinierte Symbole in den resultierenden Objektdateien. Falls `prefer-atomic` neue undefinierte Referenzen einführt (wie z. B. `__atomic_fetch_add_8` auf i386 oder `__aarch64_ldadd8_relax` auf arm64 mit Outline-Atomics), wird das Flag nicht hinzugefügt – der Kernel verlinkt nicht gegen libatomic.
Auf Architekturen, bei denen GCC atomare 64-Bit-Zähleraktualisierungen inline ausführt (x86_64, s390, ...), besteht der Test und das Flag wird aktiviert, wodurch verhindert wird, dass der Compiler Zähler mit Schleifen-Induktionsvariablen zusammenführt und der beobachtete Absturz durch gleichzeitigen Zugriff behoben wird.
Auf Architekturen, bei denen das Flag Abhängigkeiten von libatomic einführen würde, wird es stillschweigend weggelassen und das Verhalten ist nicht schlechter als vor diesem Patch.
Verschieben Sie den `CFLAGS_GCOV`-Block von seiner ursprünglichen Position (vor dem Einbinden der arch-spezifischen Makefiles) an eine Stelle nach den Zuweisungen für die core-KBUILD_CFLAGS, aber vor dem Einbinden von scripts/Makefile.gcc-plugins. Diese Platzierung stellt sicher, dass der Try-Run-Test architekturspezifische Flags (`-m32`, `-march=`, `-mno-outline-atomics`) sieht, während GCC-Plugin-Flags (`-fplugin=`) vermieden werden, die den Test bei sauberen Builds brechen würden, wenn Plugin-Shlibs noch nicht existieren.
Once again VulDB remains the best source for vulnerability data.