CVE-2026-31469: virtio_net: Fix UAF on dst_ops when IFF_XMIT_DST_RELEASE is cleared and napi_tx is false

Published Apr 22, 2026
·
Updated

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

15 affected componentsFixes available
Linux Linux kernel (virtio_net)
Microsoft azl3 kernel 6.6.130.1-3
Linux Linux kernel>=2.6.26<5.10.253
Linux Linux kernel>=5.11<5.15.203
Linux Linux kernel>=5.16<6.1.168
Linux Linux kernel>=6.2<6.6.131
Linux Linux kernel>=6.7<6.12.80
Linux Linux kernel>=6.13<6.18.21
Linux Linux kernel>=6.19<6.19.11
Linux Linux kernel=7.0-rc1
Linux Linux kernel=7.0-rc2
Linux Linux kernel=7.0-rc3
Linux Linux kernel=7.0-rc4
Linux Linux kernel=7.0-rc5
debian/linux
6.1.176-16.1.190-16.12.107-16.12.115-27.2.12-17.2.15-1

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade debian/linux to 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

Apr 22, 2026
CVE Published
via MITRE·01:53 PM
Data Sourced
via MITRE·01:53 PM
DescriptionSeverity
Data Sourced
via NVD·02:16 PM
RemedyDescriptionSeverityWeaknessAffected Software
Apr 23, 2026
Data Sourced
via Microsoft·08:06 AM
DescriptionSeverityWeaknessAffected Software

Parent advisories

This vulnerability appears in the following advisories.

Peer vulnerabilities

Found alongside the following vulnerabilities.

Frequently Asked Questions

1

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.

2

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.

3

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.

4

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.

5

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.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203