CVE-2026-31695 · Linux kernel virt_wifi SET_NETDEV_DEV use-after-free in ethtool…

01 · The Real Story

A lost badge that still opens the door after the owner is gone

The Linux kernel's virt_wifi driver is a software-only wireless interface used mostly for testing Wi-Fi management behavior. The bug: it sets the network device's parent pointer (dev->dev.parent) to the lowerdev device with SET_NETDEV_DEV(). When that lower device is unregistered, the parent pointer dangles. If an ethtool netlink request such as ETHTOOL_MSG_FEATURES_SET runs in the same unregistration window, ethnl_ops_begin() calls pm_runtime_get_sync(dev->dev.parent) on freed memory — a slab use-after-free. The kernel patch simply removes the SET_NETDEV_DEV() call.

The vendor's HIGH/7.8 score encodes the worst-case kernel UAF: local access, low complexity, low privileges, high impact. Real-world conditions cut against that. virt_wifi is a niche test module that most production Linux hosts never load. Triggers require CAP_NET_ADMIN in a network namespace and a precise race, and there is no public exploit or in-the-wild activity. A local UAF is not pleasant, but this is not a fleet-wide emergency; it's a backport and module-exposure issue.

"Local race in a rarely loaded kernel test driver; treat as backport hygiene, not an emergency."

02 · The Attack Path

4 steps from start to impact.

STEP 01

Get local access with CAP_NET_ADMIN

The attacker needs a shell on a Linux host that has the virt_wifi module loaded or available, plus CAP_NET_ADMIN in the network namespace where the device lives. On typical multi-tenant container hosts, CAP_NET_ADMIN may be present in privileged containers or user namespaces.

Conditions required:

Local shell access
CAP_NET_ADMIN in the target network namespace
Linux kernel with virt_wifi module (not blacklisted)

Where this breaks in practice:

Most production Linux images do not include or load virt_wifi
Unprivileged user namespaces often lack the ability to create virt_wifi devices without already having CAP_NET_ADMIN in the initial namespace
Administrators can blacklist the module

Detection/coverage: lsmod | grep virt_wifi and modinfo virt_wifi; auditd can log module loads.

STEP 02

Create or locate a virt_wifi interface with a lowerdev

The attacker uses ip link add link <lowerdev> name wlan0 type virt_wifi if the module supports it, or locates an existing virt_wifi netdev. The vulnerable assignment SET_NETDEV_DEV(dev, &priv->lowerdev->dev) links the fake wireless device to the lowerdev's struct device.

Conditions required:

An existing or creatable virt_wifi netdev with a usable lowerdev
Lowerdev present (e.g., veth, dummy, or real interface)

Where this breaks in practice:

Creating virt_wifi devices is not a standard admin action; most systems have none configured
Requires CAP_NET_ADMIN or root-level network control

Detection/coverage: ip -d link show output includes virt_wifi; network device inventory can flag it.

STEP 03

Race lowerdev unregistration with an ethtool netlink request

The attacker deletes or hot-unplugs the lowerdev while simultaneously sending an ethtool netlink message (e.g., ETHTOOL_MSG_FEATURES_SET) targeting the virt_wifi interface. The netdev_run_todo() unregister path for virt_wifi can interleave with the lowerdev's device release, leaving dev.parent dangling.

Conditions required:

Ability to trigger lowerdev unregistration
Timing window before virt_wifi netdev is fully released

Where this breaks in practice:

Race window is narrow and non-deterministic
Needs repeated attempts; useful exploits must groom slab state
Hot-unplug events may not be attacker-controllable

Detection/coverage: eBPF/KASAN would catch UAF; typical production EDR does not inspect ethtool netlink races.

STEP 04

Trigger UAF and exploit for info leak or local privilege escalation

The ethtool path calls pm_runtime_get_sync(dev->dev.parent) on the freed lowerdev struct device. The KASAN trace shows a read use-after-free; an attacker with memory grooming can aim for a controlled kernel read or denial-of-service, potentially elevating privileges or escaping a weak container boundary if further primitives exist.

Conditions required:

Kernel slab layout that allows a useful adjacent object to allocate into freed chunk
Successful race hit
Exploit primitive to follow the UAF read

Where this breaks in practice:

No public exploit chain; turning this UAF into privilege escalation is non-trivial
Read UAF of size 2 is often only a crash or limited info leak
Kernel hardening (KASLR/SLAB_FREELIST_RANDOM/panic_on_warn) may block exploitation

Detection/coverage: KASAN/panic logs if enabled; ethtool netlink audit may show unusual feature-set requests during device deletion.

03 · Compensating Control

LOW 3.4→IGNORE 0.0

SEVERITY REDUCED

Blacklist the virt_wifi module on all production hosts — Most fleets never use virt_wifi; add blacklist virt_wifi or install virt_wifi /bin/false in /etc/modprobe.d/. No noisgate mitigation SLA for LOW — apply via normal hardening workflow. This removes the vulnerable code path entirely.

LOW 3.4→LOW 2.0

Restrict CAP_NET_ADMIN and namespace creation to trusted users — Limit CAP_NET_ADMIN to controlled service accounts; disable unprivileged user namespaces where feasible (kernel.unprivileged_userns_clone=0). That removes the local low-privileged trigger without affecting standard server networking. If this is the only control, module may still be loadable by true admins, so residual is LOW.

LOW 3.4→IGNORE 0.0

SEVERITY REDUCED

Apply the upstream kernel patch when your distro backports it — The patch removes SET_NETDEV_DEV(dev, &priv->lowerdev->dev); update to the fixed kernel within the noisgate remediation SLA — 365 days for LOW. This eliminates the use-after-free at the source.

LOW 3.4→LOW 3.0

Inventory and alert on virt_wifi module loads on production — Use auditd/eBPF to log init_module for virt_wifi and any ip link add ... type virt_wifi commands; investigate unexpected loads within hours. This does not patch the bug but narrows the exposure window.

What doesn't work

Network perimeter controls (firewall/WAF/IDS) don't help because the trigger is a local netlink API call.
EDR alone often misses the ethtool/unregister race unless it has eBPF-based kernel memory-safety telemetry.

04 · Intelligence Metadata

The supporting signals.

In-the-wild status	No known active exploitation; not listed in CISA KEV.
Proof of concept	None public at assessment time; no GitHub repos named after CVE-2026-31695 and no entries on pocindex.io.
EPSS score	0.00126 (0.126% probability) — very low estimated near-term exploitation.
EPSS percentile	Not published in the record; score indicates bottom-of-range exploit expectation.
KEV status	Not listed in CISA KEV as of 2026-05.
CVSS vector	`CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H` — local, low complexity, low privileges, no user interaction; high impact all axes.
Affected component	`drivers/net/wireless/virt_wifi.c` in the Linux kernel; module name `virt_wifi`.
Trigger path	Ethtool netlink operations on a `virt_wifi` netdev while its `lowerdev` is unregistering.
Fixed versions	Upstream patch removes `SET_NETDEV_DEV()`; stable distro backports not yet catalogued in the CVE record.
Scanning/exposure	Network scanners cannot see this local module; exposure is measurable only via internal module/device inventory.

Sources.

05 · The Call

Final Verdict

↓ DOWNGRADED to LOW (3.4/10)

Why this verdict

Friction audit: The path is local-only and requires CAP_NET_ADMIN + the optional virt_wifi module; both conditions are absent on the overwhelming majority of enterprise Linux fleets. The exploit is a narrow race with no public PoC or in-the-wild activity.
Role multiplier: virt_wifi is a software test shim, not a hypervisor, IdP, PAM, backup, CA, or edge role. On the rare systems that load it (test VMs, driver-development boxes), the worst plausible outcome is a local root/info-leak on that host, not domain/fleet/supply-chain. Its high-value-role installed base is far below 1%, so the HIGH/CRITICAL floor does not apply.
Baseline adjustment: Starting from the vendor 7.8 local vector, subtract for module rarity, the CAP_NET_ADMIN bar, the non-deterministic race, and zero exploit maturity; this lands at LOW (3.4).

Why not higher?

Requires a seldom-loaded test driver and local CAP_NET_ADMIN; this is not remotely reachable, not a default config, and no public exploit or KEV entry exists. Even in the vulnerable window, the observed primitive is a small read UAF that often manifests as a crash rather than reliable privilege escalation.

Why not lower?

The code bug is real and reachable through the standard ethtool netlink API; any environment that does load virt_wifi with lowerdev assignments should treat it as a genuine local kernel memory-safety defect. It isn't IGNORE because a successful exploit on a test VM could still yield root or break container isolation if an attacker already holds CAP_NET_ADMIN.

06 · Verification

Crowdsourced verification payload.

Run on each Linux target as root. Invoke: sudo bash ./check_virt_wifi_cve-2026-31695.sh. It checks module load/availability; output is VULNERABLE if loaded, UNKNOWN if available but not loaded, PATCHED if absent. Exit code is 0 for all states; parse stdout.

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/bin/bash
# CVE-2026-31695 check: virt_wifi SET_NETDEV_DEV UAF
set -euo pipefail

MODULE="virt_wifi"
STATUS="UNKNOWN"

if lsmod | awk '{print $1}' | grep -qx "$MODULE"; then
    STATUS="VULNERABLE"
    echo "VULNERABLE: $MODULE module is loaded"
elif modinfo "$MODULE" >/dev/null 2>&1; then
    echo "UNKNOWN: $MODULE is available but not loaded; loading it exposes the vulnerable path"
else
    echo "PATCHED/NOT PRESENT: $MODULE is not available"
    STATUS="PATCHED"
fi

# Optionally also check whether an existing virt_wifi interface references a lowerdev:
if ip -d link show 2>/dev/null | grep -q 'virt_wifi'; then
    echo "INFO: a virt_wifi interface is present; inspect lowerdev attachment"
fi

exit 0