CVE-2025-22106

What it actually does

vmxnet3 driver omits XDP RX queue info unregistration in vmxnet3_reset_work because vmxnet3_rq_destroy is bypassed, triggering __xdp_rxq_info_reg warnings on re-registration.

Why it matters to the business

Systems using vmxnet3 NICs with XDP may log repeated warnings and backtraces during device resets, increasing noise in monitoring and indicating incomplete driver cleanup without direct service disruption.

How an attack unfolds

An attacker or workload triggers repeated vmxnet3 resets (via link flaps, configuration changes, or power events); the missing unregister leaves stale XDP state so subsequent re-registration hits the warning path, but no privilege escalation or code execution results.

How to fix it

Apply the upstream fix that relocates XDP unregister logic into vmxnet3_rq_cleanup (commit a6157484bee3385a425d288a69e1eaf03232f5fc) and rebuild or install the patched kernel; no configuration changes required.

How to confirm the fix worked

After patching, induce a vmxnet3 reset while XDP is active and confirm absence of the 'Missing unregister, handled but fix driver' warning and backtrace in dmesg or kernel logs.

Typical attack path

1. Trigger vmxnet3 device reset through link state change or administrative action
2. vmxnet3_reset_work executes without calling vmxnet3_rq_destroy
3. XDP RX queue info remains registered
4. Next __xdp_rxq_info_reg call emits WARNING backtrace

How to detect it

Search kernel logs and dmesg for the exact warning string from net/core/xdp.c during periods of vmxnet3 activity or device resets; correlate with vmxnet3 driver load/unload events.

What your security team should do

• Prioritize kernel updates on hosts using vmxnet3 with XDP enabled
• Monitor kernel logs for the specific XDP unregister warning as a health indicator
• Test patched kernels in staging before broad deployment due to driver reset path changes