CVE-2026-31469: virtio_net: Fix UAF on dst_ops when IFF_XMIT_DST_RELEASE is cleared and napi_tx is false
In the Linux kernel, the following vulnerability has been resolved:
virtionet: Fix UAF on dstops when IFFXMITDSTRELEASE is cleared and napitx is false
A UAF issue occurs when the virtionet driver is configured with napitx=N and the device's IFFXMITDSTRELEASE flag is cleared (e.g., during the configuration of tc route filter rules).
When IFFXMITDSTRELEASE is removed from the netdevice, the network stack expects the driver to hold the reference to skb->dst until the packet is fully transmitted and freed. In virtionet with napitx=N, skbs may remain in the virtio transmit ring for an extended period.
If the network namespace is destroyed while these skbs are still pending, the corresponding dstops structure has freed. When a subsequent packet is transmitted, freeoldxmit() is triggered to clean up old skbs. It then calls dstrelease() on the skb associated with the stale dstentry. Since the dstops (referenced by the dstentry) has already been freed, a UAF kernel paging request occurs.
fix it by adds skbdstdrop(skb) in startxmit to explicitly release the dst reference before the skb is queued in virtionet.
Call Trace: Unable to handle kernel paging request at virtual address ffff80007e150000 CPU: 2 UID: 0 PID: 6236 Comm: ping Kdump: loaded Not tainted 7.0.0-rc1+ #6 PREEMPT ... percpucounteraddbatch+0x3c/0x158 lib/percpucounter.c:98 (P) dstrelease+0xe0/0x110 net/core/dst.c:177 skbreleaseheadstate+0xe8/0x108 net/core/skbuff.c:1177 skskbreasondrop+0x54/0x2d8 net/core/skbuff.c:1255 devkfreeskbanyreason+0x64/0x78 net/core/dev.c:3469 napiconsumeskb+0x1c4/0x3a0 net/core/skbuff.c:1527 freeoldxmit+0x164/0x230 drivers/net/virtionet.c:611 [virtionet] freeoldxmit drivers/net/virtionet.c:1081 [virtionet] startxmit+0x7c/0x530 drivers/net/virtionet.c:3329 [virtionet] ...
Reproduction Steps: NETDEV="enp3s0"
configqdiscroutefilter() { tc qdisc del dev $NETDEV root tc qdisc add dev $NETDEV root handle 1: prio tc filter add dev $NETDEV parent 1:0 \ protocol ip prio 100 route to 100 flowid 1:1 ip route add 192.168.1.100/32 dev $NETDEV realm 100 }
testns() { ip netns add testns ip link set $NETDEV netns testns ip netns exec testns ifconfig $NETDEV 10.0.32.46/24 ip netns exec testns ping -c 1 10.0.32.1 ip netns del testns }
configqdiscroutefilter
testns sleep 2 testns
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.1.176-1Fixed in 6.1.190-1Fixed in 6.12.107-1Fixed in 6.12.113-1Fixed in 7.2.12-1Fixed in 7.2.13-1
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux virtio_net driver are exposed when napi_tx is disabled and the device does not have the IFF_XMIT_DST_RELEASE flag set. The issue is particularly relevant where tc route filter configuration clears that flag.
What conditions are needed to trigger the use-after-free?
Transmit skbs must remain pending in the virtio transmit ring while the associated network namespace is destroyed. A later transmission can invoke cleanup of the old skbs, causing dst_release() to access dst_ops that has already been freed.
Is this a remotely exploitable issue?
The supplied severity vector identifies the attack vector as local and requires low privileges, with no user interaction. It does not indicate a network-based attack path.
How can administrators determine whether their configuration is at risk?
Check whether virtio_net is operating with napi_tx=N and whether IFF_XMIT_DST_RELEASE has been cleared from the relevant net_device, such as during tc route filter setup. The vulnerable sequence also depends on pending transmit-ring skbs during network namespace teardown.
What does the fix change?
The fix explicitly drops the skb destination reference with skb_dst_drop(skb) in start_xmit before the skb is queued by virtio_net. This prevents a stale dst_entry from later reaching dst_release() after its dst_ops has been freed.