The underlying change is identifiable, however. Linux 7.2-rc5, announced by Linus Torvalds on July 26, includes a patch titled “nexthop: initialize extack in nh_res_bucket_migrate().” LWN’s release listing attributes that patch to Xiang Mei of Microsoft. The practical conclusion for Windows administrators is straightforward: this is not evidence of a Windows Update requirement. For Linux administrators, especially those operating hardware-offloaded routing, it is a kernel patch worth tracking through their distribution’s own update channel.
Microsoft’s CVE listing does not currently provide the facts an operations team would need to act confidently: no CVSS score, no affected product list, no fixed kernel versions, no package names, no exploit assessment, and no indication of whether Microsoft plans to ship a remediation in Azure Linux or another Linux-based product. Neither the supplied listing nor the available public record establishes a Windows component affected by this code.
The bug sits in resilient next-hop bucket migration
The fault is in
net/ipv4/nexthop.c, specifically the
nh_res_bucket_migrate()function. Linux uses that code to rebalance resilient next-hop groups: advanced multipath routing objects intended to minimize disruption to existing flows when a route member is removed or its weighting changes.
Kernel documentation describes resilient groups as a bucket-based alternative to conventional ECMP hash-threshold routing. Rather than recalculating the full hash space after a next-hop change, the kernel moves only the affected buckets to another next hop. This helps preserve flow affinity — an important property for load balancers, routers, virtual routing environments, and hosts using multipath forwarding.
The migration code notifies registered nexthop listeners before moving a bucket. Those listeners are commonly relevant where the kernel’s forwarding state is being offloaded to network hardware. A driver can report that a proposed bucket migration should not proceed because the hardware has observed traffic on that bucket, or because the hardware cannot accept the update.
The error-reporting object passed into that notification path is
struct netlink_ext_ack, known as extack. Extended acknowledgements are the kernel’s mechanism for carrying a human-readable explanation alongside a Netlink error. Linux’s Netlink documentation recommends enabling them because they turn a generic error number into a more useful diagnostic message.
In the vulnerable code, the local
extackvariable is declared but not initialized before being passed to the notifier chain. If that chain returns an error,
nh_res_bucket_migrate()then tries to print
extack._msgthrough the kernel log’s
%sformatter.
That is the defect: the error path assumes the message pointer contains a valid string, but no initial state was established for it.
A one-line fix closes an error path with a potentially bad pointer
The expected upstream correction is small: initialize the local extack structure to zero before it is used. In C terms, that changes a stack object with indeterminate contents into an object whose message pointer begins as null.
Small patches can mask consequential bugs. A notifier that returns an error after setting an extack message leaves a valid string for the logging path. But an error generated before a message is set — for example, a failure while preparing notifier information or a driver callback that returns an error without supplying a message — can leave
_msgcontaining stale stack data. The subsequent log attempt may then treat an arbitrary value as a character pointer.
The supplied Microsoft title says only “initialize extack,” which accurately describes the code correction but omits the operational issue. The code path is not merely cleaning up a warning or improving diagnostics. It removes an unsafe assumption in kernel error logging, at the point where a failed bucket migration is handled.
The record does not state whether the observed consequence is a kernel warning, a crash, an information exposure through logs, or some combination of those outcomes. It would be irresponsible to assign a severity or claim reliable remote exploitation without that evidence. What can be stated from the code is that an uninitialized pointer is read as a string in a privileged kernel context after a notifier error.
The affected configuration is much narrower than “Linux networking”
Most Linux systems do not configure resilient next-hop groups at all. The feature is managed with
ip nexthopand requires an explicit resilient group configuration with a bucket count, an idle timer, and optionally an unbalanced timer. Ordinary default-route installations, typical desktop networking, and basic server NIC configuration do not naturally exercise this mechanism.
The more meaningful exposure group is specialized routing infrastructure. Kernel documentation specifically calls out single-bucket notifications and driver feedback as part of the resilient-group offload model. That places the highest relevance on systems that combine all of the following:
- They use resilient next-hop groups rather than conventional multipath routes.
- They rebalance group membership or next-hop weights while forwarding traffic.
- They have a registered nexthop notifier, most plausibly through a network driver participating in hardware offload.
- They encounter a notifier failure while a bucket migration is being processed.
The distinction matters for incident triage. A system running a Linux kernel with the vulnerable function is not necessarily exposed to the bad path in routine operation. Conversely, a router, switch, hypervisor host, or appliance using advanced route offload may encounter exactly the error-handling conditions that ordinary servers never reach.
The kernel’s own resilient-next-hop documentation explains why errors are plausible in this path. For non-forced migrations, a driver can reject a bucket move if it discovers the bucket is still active in hardware. For forced migrations, the kernel must proceed when route membership requires it, then clears offload-related flags to indicate that the bucket is not correctly populated in hardware. That is a deliberately complex control plane, and CVE-2026-64576 sits in its failure reporting rather than in ordinary packet forwarding.
Linux 7.2-rc5 contains the patch, but that is not a production remediation map
The patch is present in the Linux 7.2-rc5 change list published July 26. That confirms the fix had reached the upstream release-candidate tree before Microsoft’s August 9 CVE timestamp. It does not establish that the patch is in a released stable kernel, a long-term-support branch, a cloud image, or a vendor-maintained enterprise kernel.
This is where Microsoft’s incomplete record creates avoidable ambiguity. The company has assigned and published a CVE identifier for an upstream Linux change, but it has not supplied the usual mapping from vulnerability to supported products and corrected builds. Administrators cannot derive patch status from the CVE number alone.
The public Linux source snapshot indexed by Codebrowser still shows the pre-fix pattern: an uninitialized
struct netlink_ext_ack extackfollowed by logging of
extack._msgwhen the notification call fails. That confirms the title is tied to a real code condition, while also illustrating why version-based exposure cannot be inferred from a single public source snapshot. Kernel trees, vendor backports, Android common kernels, cloud kernels, and enterprise distributions do not all advance on the same schedule.
What Linux operators should do now
Operators should first establish whether resilient next-hop groups are actually in use.
ip nexthop showand
ip nexthop bucket showcan identify configured nexthop objects and bucket tables; a resilient group will be explicitly represented as such. Administrators should also identify whether the host relies on NIC or switch-driver route offload, because the notifier path is central to the vulnerable function.
For systems using the feature, the appropriate remediation is a vendor kernel update containing the upstream extack initialization patch, not a switch to an unreleased upstream release candidate. Distribution security trackers and kernel package changelogs should be checked for the exact backport title, the CVE identifier, or the associated
net/ipv4/nexthop.cchange.
For Windows-only fleets, CVE-2026-64576 does not currently call for action. Microsoft’s involvement appears in the CVE publication channel and the attribution of the upstream patch author, not in evidence that Windows networking code is affected.
The immediate unresolved issue is Microsoft’s advisory itself. Its timestamp is later than the current UTC time, and it lacks every product-and-build detail needed for patch management. Until Microsoft publishes a completed record or a Linux vendor ties the CVE to shipped kernel packages, the defensible action is to treat CVE-2026-64576 as a narrowly scoped Linux routing-offload issue and verify whether the relevant resilient-next-hop configuration exists before escalating it across an entire estate.
References
- Primary source: MSRC
Published: August 9, 2026 at 8:42 AM UTC
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: android.googlesource.com
- Related coverage: kernel.googlesource.com
- Related coverage: android.googlesource.com
- Related coverage: codebrowser.dev
nexthop.c source code [linux/net/ipv4/nexthop.c] - Codebrowser
Source code of linux/net/ipv4/nexthop.c linux v6.19-r on KDAB Codebrowser
codebrowser.dev
- Related coverage: kernel.googlesource.com
Loading…
kernel.googlesource.com - Related coverage: git.shady.money
Loading…
www.git.shady.money - Related coverage: git.zx2c4.com
Loading…
git.zx2c4.com - Related coverage: docs.kernel.org
- Related coverage: man7.org
- Related coverage: man7.org