CVE przypisane do Linux kernel, a podatny kod siedzi w userspace perf: CVE-2026-80671 i granularność produktu w Vulnerability Management

CVE-2026-80671 opisano w klasycznym stylu linuxowego CVE: „In the Linux kernel, the following vulnerability has been resolved”. GitHub pokazuje Critical 9.3, rekord prowadzony jest w ramach produktu Linux kernel. Administrator albo system VM może odczytać to jako Linux kernel + CVSS 9.3 = Critical kernel vulnerability. Tylko że podatny plik nie znajduje się w jądrze wykonywanym w kernel space. Oficjalne ogłoszenie Linux CVE Team podaje tools/perf/builtin-sched.c — problem występuje w perf sched, userspace'owym narzędziu z drzewa źródłowego Linuksa, podczas przetwarzania niezaufanego pliku perf.data.

To nadal realna podatność. Ale jej attack surface jest zupełnie inny niż sugeruje intuicyjne odczytanie etykiety „Linux kernel Critical”. Dlatego CVE-2026-80671 to bardzo dobre case study jakości danych w VM.

Co dokładnie jest podatne?

Funkcja register_pid() w tools/perf/builtin-sched.c miała kilka problemów podczas przetwarzania danych z perf.data:

Integer overflow: (pid + 1) * sizeof(struct task_desc *) mogło się przepełnić na 32-bit przy dużym PID → za mały bufor z realloc() → zapis poza końcem.

Heap buffer overflow: strcpy(task->comm, comm) dla niezaufanego perf.data, gdy task->comm ma stały bufor COMM_LEN.

Allocation failure: BUG_ON() tam, gdzie dla niezaufanego wejścia powinien być zwykły błąd, plus niebezpieczne przypisanie wyniku realloc().

Poprawka ogranicza PID do PID_MAX_LIMIT, zastępuje strcpy() bezpieczniejszym kopiowaniem, poprawia obsługę błędów alokacji i dodaje kontrole NULL. To prawdziwy memory-safety problem — ale nie w kodzie wykonywanym jako część działającego kernela.

Gdzie właściwie jest granica produktu?

Linux CVE Team przypisuje problem do Linux kernel, bo perf jest rozwijany i wersjonowany w drzewie kernela. To ma sens dla procesu upstream. VM potrzebuje jednak drugiej odpowiedzi: jaki konkretnie komponent musi zostać uruchomiony, aby attack path zaistniał?

attacker-controlled perf.data → userspace perf sched → vulnerable parser → memory corruption

A nie: remote packet → kernel networking stack → kernel RCE. To fundamentalna różnica operacyjna. CVE product mapping nie jest attack-surface mappingiem — VM musi odpowiedzieć także: gdzie ten kod jest wdrożony, czy jest wykonywalny, kto może go uruchomić i jak trafia do niego niezaufane wejście.

Czy `perf` jest w ogóle zainstalowany?

W zależności od dystrybucji perf bywa w osobnym pakiecie, nieinstalowany na minimalnych serwerach albo obecny tylko na hostach administracyjnych. Dwa hosty z tym samym kernelem mogą mieć różny stan: Host A — affected kernel lineage, perf zainstalowany, użytkownicy mogą wywołać perf sched, niezaufany perf.data może być przetwarzany; Host B — affected kernel lineage, perf nieinstalowany. Z perspektywy CVE oba mogą należeć do affected source range; z perspektywy exploitable deployment nie są równoważne.

To nie musi być false positive

Jeżeli scanner poprawnie wykrywa affected Linux version zgodnie z feedem, to niekoniecznie false positive. Lepsze określenie: correct product match but insufficient component granularity albo affected by source/package lineage but vulnerable executable absent. To ważne, bo status „False Positive” sugeruje błąd detekcji — a tutaj problem tkwi w modelu danych.

„Critical kernel CVE” tworzy false urgency

Organizacja z 20 000 serwerów Linux dostaje do VM CVE-2026-80671 / Linux kernel / CVSS 9.3. Automatyzacja może wygenerować tysiące Critical findings, P1 ticketów, alertów dla zespołów kernel/platform i czerwony dashboard dla managementu. Jeżeli jednak tylko niewielka część hostów ma używany perf i możliwość przetwarzania obcego perf.data, priorytet operacyjny wygląda inaczej. To nie znaczy „nie patchować” — znaczy: nie mylić liczby affected hostów z liczbą realnie istotnych attack paths.

CVSS 9.3 i EPSS też wymagają interpretacji

Wektor CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H to bardzo wysoki score, ale AV:L nie mówi, jak niezaufany perf.data trafia do perf sched. Analiza trace'ów od klientów, CI przetwarzający perf artifacts albo support portal analizujący przesłane pliki mogą zwiększyć znaczenie; na serwerze, gdzie perf nigdy nie otwiera obcych danych, likelihood jest inny. EPSS (~0,183%, 8. percentyl na 30 sierpnia) też nie rozstrzyga — przewiduje prawdopodobieństwo obserwowanej eksploatacji CVE, nie to, czy nasz workflow przetwarza nieufne perf.data. Dla firmy budującej narzędzie do automatycznej analizy profili perf kontekst całkowicie zmienia priorytet.

Jak powinien zadziałać Vulnerability Engineer?

Nie zatrzymywać się na product = Linux kernel.
Przeczytać opis i znaleźć affected file: tools/perf/builtin-sched.c.
Ustalić runtime component: perf sched.
Sprawdzić, czy perf jest faktycznie zainstalowany.
Ustalić, czy system przetwarza niezaufane perf.data.
Dopiero wtedy ustalić priorytet środowiskowy.

Zamiast Linux X.Y affected → Critical scanner może mieć warstwy: product_match.linux_source, component.path/executable, runtime_presence.perf_installed, reachability.untrusted_perf_data — status przechodzi od AFFECTED_COMPONENT_PRESENT do EXPLOITABLE_PATH_PRESENT dopiero po potwierdzeniu workflow.

Problem packagingu w dystrybucjach

Linux upstream może powiedzieć „fixed in stable kernel release”, ale dystrybucja dostarcza perf w osobnym pakiecie. VE powinien sprawdzić vendor package mapping, backport status, czy linux-tools/perf jest osobno wersjonowane, czy kernel zaktualizowano, a userspace tool nie (lub odwrotnie). To pokazuje, dlaczego CPE/CVE mapping nie zawsze odpowiada temu, co administrator faktycznie instaluje. Remediation nadal jest aktualizacją — Linux CVE Team zaleca upgrade do najnowszej stabilnej wersji i nie rekomenduje cherry-pickowania pojedynczych commitów; do czasu aktualizacji można ograniczyć użycie perf i nie przetwarzać nieufnych perf.data.

Wniosek

CVE-2026-80671 nie pokazuje, że CVE zostało źle przypisane — pokazuje coś subtelniejszego: granularność CVE jest wystarczająca dla upstream security process, ale może być niewystarczająca dla enterprise prioritization. System VM potrzebuje kilku poziomów: Product → Package → Component → Runtime → Attack Path. Jeżeli zatrzymamy się na pierwszym — „Linux kernel” — stworzymy tysiące technicznie uzasadnionych, ale operacyjnie źle opisanych Critical findings. Najważniejsze pytanie nie brzmi „czy mamy podatny Linux kernel?”, tylko: czy mamy podatny perf, czy jest używany i czy może przetwarzać niezaufane perf.data?

Powiązane na blogu

Pięć podatności, różne architektury — topology-aware VM i affected ≠ exploitable
Critical RCE z gotowego szablonu — kiedy precondition realnie istnieje w środowisku

Źródła

Linux CVE Announce — CVE-2026-80671: perf sched fix register_pid() overflow, strcpy, BUG_ON (28.08.2026) — lists.openwall.net
GitHub Advisory Database — CVE-2026-80671 / GHSA-98vx-8r93-84hf — github.com/advisories
Linux kernel source — tools/perf/builtin-sched.c — github.com
Linux stable fix commit — git.kernel.org

Nota redakcyjna: stan informacji 30 sierpnia 2026, 10:21 CEST. Oficjalny Linux CVE announcement wskazuje jako affected file tools/perf/builtin-sched.c. Artykuł nie kwestionuje prawidłowości CVE; analizuje problem granularności produktu i komponentu w systemach Vulnerability Management.