On Tue, 24 Mar 2026 00:46:27 -0700, Eric Dumazet <[email protected]> wrote: > On Tue, Mar 24, 2026 at 12:11 AM Xuan Zhuo <[email protected]> wrote: > > > > On Thu, 12 Mar 2026 10:54:06 +0800, xietangxin <[email protected]> wrote: > > > A UAF issue occurs when the virtio_net driver is configured with napi_tx=N > > > and the device's IFF_XMIT_DST_RELEASE flag is cleared > > > (e.g., during the configuration of tc route filter rules). > > > > > > When IFF_XMIT_DST_RELEASE is removed from the net_device, the network > > > stack > > > expects the driver to hold the reference to skb->dst until the packet > > > is fully transmitted and freed. In virtio_net with napi_tx=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 dst_ops structure has freed. When a subsequent packet > > > is transmitted, free_old_xmit() is triggered to clean up old skbs. > > > It then calls dst_release() on the skb associated with the stale > > > dst_entry. > > > Since the dst_ops (referenced by the dst_entry) has already been freed, > > > a UAF kernel paging request occurs. > > > > Sorry, this sounds a bit off to me. We know that napi_tx=N merely prolongs > > the > > presence of the skb on the device side. However, even without napi_tx=N, > > there > > is no guarantee that the skb will be freed within any specific timeframe. > > Therefore, napi_tx=N just makes the issue more reproducible; it is not the > > root > > cause. Also, I'm surprised that the dst could be freed while it is still > > referenced/held. I have a feeling that something is being overlooked here. > > > > Thanks. > > > > > > > > fix it by adds skb_dst_drop(skb) in start_xmit to explicitly release > > > the dst reference before the skb is queued in virtio_net. > > > > > > 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 > > > ... > > > percpu_counter_add_batch+0x3c/0x158 lib/percpu_counter.c:98 (P) > > > dst_release+0xe0/0x110 net/core/dst.c:177 > > > skb_release_head_state+0xe8/0x108 net/core/skbuff.c:1177 > > > sk_skb_reason_drop+0x54/0x2d8 net/core/skbuff.c:1255 > > > dev_kfree_skb_any_reason+0x64/0x78 net/core/dev.c:3469 > > > napi_consume_skb+0x1c4/0x3a0 net/core/skbuff.c:1527 > > > __free_old_xmit+0x164/0x230 drivers/net/virtio_net.c:611 [virtio_net] > > > free_old_xmit drivers/net/virtio_net.c:1081 [virtio_net] > > > start_xmit+0x7c/0x530 drivers/net/virtio_net.c:3329 [virtio_net] > > > ... > > > > > > Reproduction Steps: > > > NETDEV="enp3s0" > > > > > > config_qdisc_route_filter() { > > > 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 > > > } > > > > > > test_ns() { > > > 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 > > > } > > > > > > config_qdisc_route_filter > > > > > > test_ns > > > sleep 2 > > > test_ns > > I took a stab at this, please look at > > https://lore.kernel.org/netdev/[email protected]/T/#u
I see. Thanks.
