CVE-2026-80676

What it actually does

Race condition during vmbus driver probe allows unlocked access to the driver_override field in __driver_attach(), resulting in a use-after-free in the Linux kernel hypervisor bus code.

Why it matters to the business

May cause kernel crashes, memory corruption, or potential privilege escalation on Linux guests running under Hyper-V, leading to service disruption in virtualized environments; low EPSS indicates limited real-world risk but still requires timely patching.

How an attack unfolds

An attacker with local access triggers driver attachment scenarios on the vmbus bus, racing the match() callback to read the driver_override field without the device lock, turning the UAF into memory corruption for denial of service or code execution.

How to fix it

Update the Linux kernel to a version containing the commit that replaces custom driver_override handling with the generic driver-core infrastructure providing internal locking.

How to confirm the fix worked

Confirm the vmbus driver source uses the driver-core override helpers; perform stress testing of driver attach/detach under concurrent load to verify absence of unlocked accesses.

Typical attack path

1. Obtain local access on a Hyper-V Linux guest
2. Influence or trigger vmbus device probe events
3. Race the unlocked match() callback during __driver_attach()
4. Leverage resulting UAF for memory corruption or escalation

How to detect it

Inspect kernel logs for oops/panic messages referencing vmbus or driver_override; audit driver probe sequences for timing anomalies around device attachment.

What your security team should do

• Prioritize kernel updates for all Hyper-V Linux workloads
• Review and restrict vmbus device exposure where feasible
• Monitor EPSS and KEV status for any change in exploit availability