CVE-2026-23046 Overview
CVE-2026-23046 is a Linux kernel vulnerability in the virtio_net driver. The flaw involves a device mismatch between the managed resource allocation and deallocation paths. The initial rss_hdr allocation uses virtio_device->device, while virtnet_set_queues() frees the memory using net_device->device. This inconsistency triggers a devres warning from drivers/base/devres.c and reflects incorrect use of the device-managed memory APIs in kernel network probe code paths.
Critical Impact
The mismatch between allocation and free contexts causes kernel warnings during virtnet_probe, signaling improper managed-resource lifecycle handling in the virtio_net driver.
Affected Products
- Linux kernel virtio_net driver
- Systems running virtio-based virtual network devices (including vDPA stacks such as octep_vdpa and virtio_vdpa)
- Kernel build referenced in the report: 6.18.0
Discovery Timeline
- 2026-02-04 - CVE-2026-23046 published to NVD
- 2026-04-15 - Last updated in NVD database
Technical Details for CVE-2026-23046
Vulnerability Analysis
The virtio_net driver uses Linux's device-managed memory allocator (devm_kzalloc) to allocate the receive-side scaling header (rss_hdr). Managed allocations are tied to a specific struct device, and the kernel tracks each allocation against that device for automatic cleanup. The allocation path passes virtio_device->device as the owning device. The matching free path in virtnet_set_queues() calls devm_kfree() with net_device->device instead. The devres subsystem cannot locate the allocation under the supplied device and emits a WARNING from devm_kfree+0x84/0x98.
Root Cause
The root cause is inconsistent device ownership across the allocation and deallocation paths for rss_hdr. devm_kzalloc and devm_kfree must be called with the same struct device pointer. Passing different devices breaks the devres tracking invariant, generating the kernel warning observed during virtnet_probe. The fix uses virtio_device->device consistently for both allocation and free operations.
Attack Vector
This is a kernel correctness defect surfaced through normal driver probe of a virtio network device. No remote attack vector or privilege escalation primitive has been documented. The technical references point to the upstream kernel commits that correct the device argument used in the deallocation path. See the patches at Kernel Git Commit a5e2d902 and Kernel Git Commit acb4bc6e.
Detection Methods for CVE-2026-23046
Indicators of Compromise
- Kernel log warning: WARNING: drivers/base/devres.c:1095 at devm_kfree+0x84/0x98 during virtio_net probe
- Stack trace including virtnet_set_queues, virtnet_probe, and virtio_dev_probe
- Tainted kernel flag [W]=WARN appearing after vDPA device add operations via vdpa netlink commands
Detection Strategies
- Monitor dmesg and /var/log/kern.log for devres warnings referencing devm_kfree within virtio_net call paths
- Audit running kernel versions against the upstream fix commits to identify unpatched hosts
- Correlate vDPA management activity (vdpa dev add) with subsequent kernel warnings on virtualization hosts
Monitoring Recommendations
- Centralize kernel log collection from hypervisors and virtualization endpoints into a security data lake for pattern matching
- Track virtio_net, virtio_vdpa, and octep_vdpa module load events alongside warning traces
- Alert on repeated devres warnings, which may indicate driver instability requiring patch deployment
How to Mitigate CVE-2026-23046
Immediate Actions Required
- Apply the upstream Linux kernel patches that align allocation and deallocation on virtio_device->device
- Inventory kernel versions across virtualization hosts and prioritize systems running virtio_net with vDPA backends
- Rebuild and redeploy custom kernels that include the virtio_net driver after merging the fix
Patch Information
The upstream resolution standardizes the device argument used by both devm_kzalloc and devm_kfree for rss_hdr, using virtio_device->device consistently. Reference the commits at Kernel Git Commit a5e2d902 and Kernel Git Commit acb4bc6e. Distribution kernels should be updated to a release that incorporates these fixes.
Workarounds
- No functional workaround exists; the issue is resolved by applying the kernel patches
- Operators can suppress noise by avoiding repeated unload and reload of virtio_vdpa and octep_vdpa modules until patches are applied
- Limit vdpa device management to administrative users to reduce exposure to driver probe paths on unpatched kernels
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
