From: xietangxin <xietangxin@yeah.net>
To: Jason Wang <jasowang@redhat.com>
Cc: "Michael S . Tsirkin" <mst@redhat.com>,
"David S . Miller" <davem@davemloft.net>,
"Eric Dumazet" <edumazet@google.com>,
"Jakub Kicinski" <kuba@kernel.org>,
"Paolo Abeni" <pabeni@redhat.com>,
"Andrew Lunn" <andrew+netdev@lunn.ch>,
"Xuan Zhuo" <xuanzhuo@linux.alibaba.com>,
"Eugenio Pérez" <eperezma@redhat.com>,
netdev@vger.kernel.org, virtualization@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] virtio_net: Fix UAF on dst_ops when IFF_XMIT_DST_RELEASE is cleared and napi_tx is false
Date: Mon, 9 Mar 2026 19:35:48 +0800 [thread overview]
Message-ID: <4b8a6182-da50-4edb-a34a-b75ed784f1e2@yeah.net> (raw)
In-Reply-To: <CACGkMEtBS3M6P9xFM-kfPHyjwHgvCrfHM5H1242AQPi54ETqEw@mail.gmail.com>
On 3/9/2026 11:42 AM, Jason Wang wrote:
> On Sat, Mar 7, 2026 at 11:53 AM 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.
>>
>> 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
>>
>> Signed-off-by: xietangxin <xietangxin@yeah.net>
>> ---
>
> This is needed for stable I think.
>
> And do we need to fix tun_net_xmit() as well?
>
> Thanks
Hi Jason,
I have analyzed the tun driver and concluded that it don't suffer from this UAF issue.
The netns containing a tun interface cannot be destroyed until all processes
holding the tun file descriptor have exited. When the file descriptor is closed,
tun_chr_close() is called, which immediately free all skbs in the tx_ring.
This happens before cleanup_net() destroys the dst_ops. Therefore, no skbs referencing freeed dst_ops.
Unlike virtio_net, where skbs can remain in the TX queue even if the ns is deleted.
I believe the fix is only necessary for virtio_net. What do you think?
Best regards,
Tangxin Xie
next prev parent reply other threads:[~2026-03-09 11:36 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-07 3:51 [PATCH] virtio_net: Fix UAF on dst_ops when IFF_XMIT_DST_RELEASE is cleared and napi_tx is false xietangxin
2026-03-07 4:15 ` Eric Dumazet
2026-03-10 6:36 ` xietangxin
2026-03-09 3:42 ` Jason Wang
2026-03-09 11:35 ` xietangxin [this message]
2026-03-10 3:02 ` Jason Wang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4b8a6182-da50-4edb-a34a-b75ed784f1e2@yeah.net \
--to=xietangxin@yeah.net \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=eperezma@redhat.com \
--cc=jasowang@redhat.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=virtualization@lists.linux.dev \
--cc=xuanzhuo@linux.alibaba.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox