Re: [PATCH net v2] virtio_net: Fix UAF on dst_ops when IFF_XMIT_DST_RELEASE is cleared and napi_tx is false

[Xuan Zhuo <xuanzhuo@linux.alibaba.com>]

On Tue, 24 Mar 2026 00:46:27 -0700, Eric Dumazet <edumazet@google.com> wrote:
> On Tue, Mar 24, 2026 at 12:11 AM Xuan Zhuo <xuanzhuo@linux.alibaba.com> wrote:
> >
> > On Thu, 12 Mar 2026 10:54:06 +0800, xietangxin <xietangxin@yeah.net> 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/20260324073750.1500328-1-edumazet@google.com/T/#u

I see.

Thanks.