Intel

CVE-2026-64459

Linux kernel (GCP) vulnerabilities

criticalEPSS 0.5 %

Beschreibung

Im Linux-Kernel wurde folgende Schwachstelle behoben: tcp: Wiederherstellung des RCU-Grace-Period in tcp_ao_destroy_sock Der Commit 51e547e8c89c ("tcp: Freigabe von TCP-AO/TCP-MD5-Info/Schlüsseln ohne RCU") entfernte den call_rcu()-Callback aus tcp_ao_destroy_sock(), indem argumentiert wurde, dass "die Zerstörung von Info/Schlüsseln bis zum Socket-Destruktor verzögert wird" und daher "niemand sie mehr entdecken kann". Dieses Argument hält jedoch nicht für die Aufrufstelle in tcp_connect() (net/ipv4/tcp_output.c:4327-4332). Zu diesem Zeitpunkt befindet sich der Socket im Zustand TCP_SYN_SENT, wurde bereits durch inet_hash_connect() in tcp_v4_connect() in die inet ehash eingefügt und ist daher sehr entdeckbar: Jede Softirq auf einem anderen CPU kann den Socket aus der ehash entfernen, in tcp_inbound_hash() gehen und tp->ao_info über implizite RCU laden, bevor bh_lock_sock_nested() auf dem zerstörenden CPU aufgenommen wird. Der Leserpfad tritt dann in __tcp_ao_do_lookup() (net/ipv4/tcp_ao.c:208) ein, das tp->ao_info erneut über rcu_dereference_check(); lädt. Die erneute Ladung kann den (bald freizugebenden) Zeiger immer noch beobachten, da es kein synchronize_rcu() zwischen rcu_assign_pointer(tp->ao_info, NULL) und tcp_ao_info_free() in tcp_ao_destroy_sock() gibt. Der gefangene Zeiger wird dann an der Zeile 223 durchlaufen: hlist_for_each_entry_rcu(key, &ao->head, node, ...) Die synchronen kfree()-Freigabe des Schreibers kann zwischen der erneuten Abfrage in Zeile 218 und der hlist-Iteration in Zeile 223 abgeschlossen werden. Der Slab wird wiederverwendet (oder einfach mit LIST_POISON1 gestempelt, wenn er noch nicht wiederverwendet wurde) und die Iteration durchläuft im Softirq-Kontext von Angreifern kontrollierte oder vergiftete Speicherbereiche. Reproduktor (kein Debug-Shim, Standard x86_64 v7.1-rc2 SMP+KASAN, QEMU+KVM): Ein unprivilegierter Prozess mit uid=1000 innerhalb von CLONE_NEWUSER|CLONE_NEWNET installiert TCP_MD5SIG + TCP_AO_ADD_KEY auf einem TCP-Socket, versprüht gefälschte TCP-AO-Segmente in Richtung seines zukünftigen 4-Tupels über Raw-Sockets und ruft dann connect() auf. Die md5-gewinnende Rekonstruktion in tcp_connect() löst tcp_ao_destroy_sock() aus; der Softirq-Backlog-Leser im Loopback-NAPI-Pfad stürzt beim Durchlaufen von ao->head.first ab: Oops: allgemeiner Schutzfehler, wahrscheinlich für nicht-kanonische Adresse 0xfbd59c000000002f KASAN: möglicher Wildzugriff im Bereich [0xdead000000000178-0xdead00000000017f] CPU: 0 UID: 1000 PID: 100 Comm: repro_userns RIP: 0010:__tcp_ao_do_lookup+0x107/0x1c0 Aufrufverfolgung: <IRQ> __tcp_ao_do_lookup+0x107/0x1c0 tcp_ao_inbound_lookup.constprop.0+0x12a/0x200 tcp_inbound_ao_hash+0x5ea/0x1520 tcp_inbound_hash+0x7ce/0x1240 tcp_v4_rcv+0x1e7a/0x3e10 ... Wiederherstellung der RCU-Grace-Period: Wiedereinfügen von struct rcu_head in tcp_ao_info und Ersetzen der synchronen tcp_ao_info_free() durch einen call_rcu()-Callback. Leser, die tp->ao_info vor dem NULLen durch rcu_assign_pointer erfasst haben, sehen nun das Objekt bis zu rcu_read_unlock() als gültig an. Mit dem Patch angewendet läuft der Reproduktor sauber für 2000 Iterationen auf derselben Kernel-Build.

Quelle: UBUNTU_USNUBUNTU_USNUBUNTU_USNBSIBSI_CSAFNVDCVELISTV5

Metriken

Severity
critical
Priority-Score
231.31
KEV-Status
—
Exploit-Reife
kein öffentlicher PoC bekannt
XIEM Effective CVSS
9.8
Quelle: nvd-v3
CVSS v3
9.8
CVSS v4
—
EPSS-Perzentil
39.6 %
Hoch — CVE rangiert über dem Median aller heute bewerteten CVEs (Rang ≥ 36 %).
EPSS-Score
0.5 %
Niedrig — Modell schätzt < 1 % Ausnutzungs-Wahrscheinlichkeit.
Veröffentlicht
2026-09-07 09:05 UTC
CWE
—

Re-Analyse & Statuswechsel

Chronologie der NVD-Audit-Events für diese CVE — Reanalyses, CVSS-Updates, CPE-Diffs.

  1. CVE Modified2026-08-17 05:17 UTC· 416baaa9-dc9f-4396-8d5f-8c081fb06d67
    • Affected: Linux, Linux → Linux, Linux
  2. New CVE Received2026-07-25 10:17 UTC· 416baaa9-dc9f-4396-8d5f-8c081fb06d67
    • Affected: Linux, Linux
    • Description: In the Linux kernel, the following vulnerability has been resolved: tcp: restore RCU grace period in tcp_ao_destroy_sock Commit 51e547e8c89c ("tcp: Free TCP-AO/TCP-MD5 info/keys without RCU") removed the call_rcu() callback from tcp_ao_destroy_sock(), arguing that "the destruction of info/keys is delayed until the socket destructor" and therefore "no one can discover it anymore". That argument does not hold for the call site in tcp_connect() (net/ipv4/tcp_output.c:4327-4332). At that point the socket is in TCP_SYN_SENT, has already been inserted into the inet ehash by inet_hash_connect() in tcp_v4_connect(), and is therefore very much discoverable: any softirq running tcp_v4_rcv() on another CPU can take the socket out of the ehash, walk into tcp_inbound_hash(), and load tp->ao_info via implicit RCU before bh_lock_sock_nested() is taken on the destroying CPU. The reader path then enters __tcp_ao_do_lookup() (net/ipv4/tcp_ao.c:208) which re-loads tp->ao_info via rcu_dereference_check(); the re-load can still observe the (about-to-be-freed) pointer because there is no synchronize_rcu() between rcu_assign_pointer(tp->ao_info, NULL) and tcp_ao_info_free() in tcp_ao_destroy_sock(). The captured pointer is then walked at line 223: hlist_for_each_entry_rcu(key, &ao->head, node, ...) The writer's synchronous kfree() is free to complete between the line 218 re-fetch and the line 223 hlist iteration. The slab is reused (or simply LIST_POISON1-stamped if not yet reused) and the iteration walks attacker-controlled or poison memory in softirq context. Reproducer (no debug shim, stock x86_64 v7.1-rc2 SMP+KASAN, QEMU+KVM): an unprivileged uid=1000 process inside CLONE_NEWUSER|CLONE_NEWNET installs TCP_MD5SIG + TCP_AO_ADD_KEY on a TCP socket, sprays forged TCP-AO segments toward its eventual 4-tuple via raw sockets, then calls connect(). The md5-wins reconciliation in tcp_connect() fires tcp_ao_destroy_sock(); the softirq backlog reader on the loopback NAPI path crashes on the freed ao->head.first walk: Oops: general protection fault, probably for non-canonical address 0xfbd59c000000002f KASAN: maybe wild-memory-access in range [0xdead000000000178-0xdead00000000017f] CPU: 0 UID: 1000 PID: 100 Comm: repro_userns RIP: 0010:__tcp_ao_do_lookup+0x107/0x1c0 Call Trace: <IRQ> __tcp_ao_do_lookup+0x107/0x1c0 tcp_ao_inbound_lookup.constprop.0+0x12a/0x200 tcp_inbound_ao_hash+0x5ea/0x1520 tcp_inbound_hash+0x7ce/0x1240 tcp_v4_rcv+0x1e7a/0x3e10 ... Restore the RCU grace period: re-add struct rcu_head to tcp_ao_info and replace the synchronous tcp_ao_info_free() with a call_rcu() callback. Readers that captured tp->ao_info before rcu_assign_pointer NULLed it now see the object remain valid until rcu_read_unlock(). With the patch applied the reproducer runs cleanly for 2000 iterations on the same kernel build.
    • Reference: https://git.kernel.org/stable/c/4caf12c778fed3dc3824cf36263be5e2c491fbd0
    • Reference: https://git.kernel.org/stable/c/657646c08c94ef7b9dbe468fe7828032216f9841

Betroffene Betriebssysteme

  • linux

    redhat / enterprise_linux10.0

  • linux

    redhat / enterprise_linux7.0

  • linux

    redhat / enterprise_linux8.0

  • linux

    redhat / enterprise_linux9.0

  • linux

    ubuntu / linux-aws-6.8jammy

  • linux

    ubuntu / linux-azureresolute

  • linux

    ubuntu / linux-azuretrusty

  • linux

    ubuntu / linux-azurexenial

  • linux

    ubuntu / linux-azure-4.15bionic

  • linux

    ubuntu / linux-azure-5.4bionic

  • linux

    ubuntu / linux-azure-fdenoble

  • linux

    ubuntu / linux-azure-fderesolute

  • linux

    ubuntu / linux-azure-fde-6.8jammy

  • linux

    ubuntu / linux-azure-fipsbionic

  • linux

    ubuntu / linux-azure-fipsfocal

  • linux

    ubuntu / linux-azure-fipsnoble

  • linux

    ubuntu / linux-fipsjammy

  • linux

    ubuntu / linux-gcp-7.0noble

  • linux

    ubuntu / linux-gkejammy

  • linux

    ubuntu / linux-nvidia-tegranoble

  • linux

    ubuntu / linux-raspinoble

  • linux

    ubuntu / linux-raspi-realtimenoble

  • linux

    linux / linux_kernel2.6.12

  • linux

    linux / linux_kernel2.6.15

Quellen & Referenzen

Verknüpfte CVEs

1392 weitere CVEs anzeigen
IDCVE-2026-64459
Linux kernel (GCP) vulnerabilities — CVE-2026-64459 | NEOSEC Intel