The NVD entry, sourced from kernel.org and published on August 5, 2026, describes a specific race in
net/ipv4/fib_trie.c:
fib_table_insert()adds a new
fib_aliasroute record to the IPv4 Forwarding Information Base, or FIB, before it notifies registered route consumers. If one of those consumers rejects the route, the old cleanup path removed the record from an RCU-protected list and freed it immediately. A concurrent route lookup that had already acquired the pointer could then continue reading freed memory.
This is a real memory-safety bug confirmed by a KASAN report, not a theoretical code-style concern. But the trigger conditions substantially narrow the exposure: the failure path requires
CAP_NET_ADMINplus a FIB notifier capable of rejecting a route. The kernel report specifically names an exhausted IPv4 FIB resource on a
netdevsimdevice as one way to make that happen.
The bug is in route-programming failure, not ordinary packet handling
Linux’s IPv4 FIB is the kernel’s route-selection data structure. It is accessed constantly: outbound connections, forwarded packets, policy-routing decisions, and other operations can cause route lookups. Those lookups need to run cheaply and concurrently, so the FIB trie uses RCU—read-copy-update—to let readers traverse structures without taking a conventional lock.
The vulnerable sequence was a mismatch between that reader model and an error-path free. The kernel inserts
new_fa, the newly allocated route alias, into a leaf’s list. It then calls FIB entry notifiers. Those notifiers are commonly relevant to networking hardware offload, virtual devices, and other subsystems that need to learn whether routes were added, replaced, or removed.
If a notifier returned an error, the kernel called
fib_remove_alias(), which unlinks the object with
hlist_del_rcu(). That operation makes the object unavailable to new traversals but deliberately does not make it safe to reclaim immediately. Readers that began before the unlink may still hold and dereference the pointer while inside their RCU read-side critical section.
The error path then used
kmem_cache_free()on the
fib_aliasobject. That was the mistake. The allocator could recycle the 56-byte
ip_fib_aliasslab object while an in-flight lookup still examined its fields. The KASAN trace supplied in the kernel.org CVE record shows the read occurring in
fib_table_lookup(), reached through the IPv4 route-output path during a UDP
connect()call.
In practical terms, a failed administrative route operation could race with routine traffic generation or route selection on the same kernel. The failed route itself does not need to succeed; the problem occurs precisely because the kernel has to unwind the partially published insertion.
The fix aligns the insert path with the kernel’s existing deletion rule
The patch is small but important. Rather than immediately returning
new_fato its slab cache after
fib_remove_alias(), the fixed code defers reclamation through
alias_free_mem_rcu(), which uses
kfree_rcu().
That tells the kernel to wait for an RCU grace period before freeing the detached route alias. Once that period has elapsed, all readers that could have entered the protected list walk before the removal have finished. The stale pointer can no longer be in legitimate use, and the allocator can safely reuse the memory.
The repair does not introduce a new lifetime mechanism or change route selection behavior. It applies the same deferred-free treatment that the IPv4 FIB code already uses when deleting aliases elsewhere in the trie. That is a useful sign for maintainers reviewing backports: the correction is narrow, follows an established local pattern, and does not depend on a broad routing-stack redesign.
The Linux kernel source also shows why RCU was the relevant mechanism.
fib_table_lookup()walks leaf aliases using RCU-aware list traversal, while
fib_remove_alias()unlinks aliases using the corresponding RCU deletion primitive. An immediate ordinary free after that unlink breaks the pairing. The corrected cleanup path restores it.
The CVE record’s version data needs careful reading
NVD lists Linux kernel versions from 5.6 onward as affected, with releases before 5.6 marked unaffected. It separately identifies fixed points in five maintained lines: Linux 6.6.148, 6.12.101, 6.18.42, 7.1.6, and 7.2-rc4.
That distinction matters because it is easy to read the fixed-version list as though every kernel between 5.6 and 7.1.5 now has a corresponding stable update. It does not say that. The listed releases represent the branches that received the fix; older non-LTS series may be out of maintenance, may have reached end of life, or may rely on distribution backports rather than a new upstream point release.
The record also supplies five stable-tree commit references. Those references are the stronger evidence for custom kernels, appliance builds, and distribution kernels whose version strings do not map cleanly to upstream releases. A system running a vendor kernel labeled, for example,
6.1.xcannot be cleared or condemned solely by comparing that number with the NVD list. Its package changelog, vendor advisory, or source configuration must show whether the relevant patch was backported.
This is especially important for enterprise distributions, cloud images, firewall appliances, Kubernetes nodes, and embedded Linux products. Many carry a long-lived base version while selectively importing security and stability fixes. Conversely, a self-built 6.1, 6.5, or early 6.6 kernel without the patch remains in the affected range even if it has accumulated unrelated updates.
As of August 9, NVD has not assigned CVSS v3, CVSS v4, or CWE metadata to CVE-2026-64572. Administrators should resist treating the absence of a score as a risk rating. It means the enrichment process has not yet produced one.
Privileged networking is the meaningful exposure boundary
This is not described as an unauthenticated, packet-only Internet attack against an otherwise ordinary Linux host. The kernel.org report says reproducing the bad cleanup path requires
CAP_NET_ADMINand a registered FIB notifier that rejects the route operation. Those requirements make systems that program routes and use hardware or simulated offload the first places to investigate.
The report’s
netdevsimexample is instructive.
netdevsimis a kernel test and simulation driver; exhausting its IPv4 FIB resource can force the notifier rejection needed to reach the vulnerable error path. That confirms the race is reproducible without a physical NIC driver, but it does not establish public exploitation or prove that a default desktop, workstation, or unprivileged container can trigger it.
The more relevant operational question is whether
CAP_NET_ADMINis delegated to workloads. Network appliances, CI systems that run kernel networking tests, hosts with privileged containers, and tenants allowed to manipulate routes or create network namespaces deserve closer scrutiny than a conventional endpoint where only the host administrator can alter routing state. In the latter case, the vulnerability is still a kernel defect worth patching, but the attacker model is much less favorable.
No public exploit, exploitation-in-the-wild claim, or vendor severity assessment appears in the NVD record. The KASAN crash establishes a use-after-free and the patch removes it; it does not by itself demonstrate privilege escalation or code execution. Treating it as proven remote compromise would go beyond the published evidence.
What administrators should verify now
The first check is the running kernel, using
uname -r, followed by the package provenance rather than the version string alone. Upstream users should update to the applicable fixed stable release or later. Users on distributions should look for a vendor kernel update that references CVE-2026-64572 or the IPv4 FIB
kfree_rcu()fix.
A concise triage path is:
- Systems running an upstream kernel earlier than 6.6.148 in the 6.6 line, 6.12.101 in the 6.12 line, 6.18.42 in the 6.18 line, or 7.1.6 in the 7.1 line should be updated.
- Systems using custom, appliance, or distribution kernels should be checked against the stable-tree patch rather than dismissed based on a familiar long-term-support base version.
- Hosts that grant
CAP_NET_ADMINto containers, virtual network functions, CI jobs, or local users should be prioritized because they are closer to the route-programming precondition. - Environments using route offload, switchdev-style setups, simulated network devices, or aggressive automated route changes should treat this as a near-term maintenance item.
For Windows users, the immediate concern is limited to Linux environments: Windows Subsystem for Linux installations using their own kernel, Linux virtual machines, Hyper-V-hosted network appliances, and development systems that compile or boot custom Linux kernels. A standard Windows networking stack is outside the scope of this CVE.
The central lesson from CVE-2026-64572 is less dramatic than the word use-after-free often suggests, but more actionable than an unscored NVD record may imply: a rarely used route-insertion failure path violated the lifetime contract of an RCU-protected routing structure. The upstream fix is already identified across active stable lines. The remaining work is making sure the kernel actually running on each system contains it.
References
- Primary source: NVD / Linux Kernel
Published: August 9, 2026 at 8:42 AM UTC
Loading…
nvd.nist.gov - Security advisory: MSRC
Published: August 9, 2026 at 8:42 AM UTC
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: nvd.nist.gov
Loading…
nvd.nist.gov - Related coverage: codebrowser.dev
fib_trie.c source code [linux/net/ipv4/fib_trie.c] - Codebrowser
Source code of linux/net/ipv4/fib_trie.c linux v6.19-r on KDAB Codebrowsercodebrowser.dev