On 3/15/2026 9:12 AM, Jakub Kicinski wrote:
> On Sat, 14 Mar 2026 21:11:33 +0100 Eric Dumazet wrote:
>>> On Thu, 12 Mar 2026 10:54:06 +0800 xietangxin wrote:
>>>> Fixes: f2fc6a54585a ("[NETNS][IPV6] route6 - move ip6_dst_ops inside the
>>>> network namespace")
>>>> Cc: [email protected]
>>>> Signed-off-by: xietangxin <[email protected]>
>>>
>>> The Fixes tag should be:
>>>
>>> Fixes: 0287587884b1 ("net: better IFF_XMIT_DST_RELEASE support")
>>
>> I disagree
>>
>> What was the situation before this patch ?
>
> My thinking process was that it's fairly unusual that the dst is kept
> because the stack decided so. Normally its the device driver that asks
> for dst to be kept when its xmit is called. I thought 0287587884b1 was
> the first time when stack could make the dst decision behind device
> driver's back. But my analysis was very shallow, could well be wrong.
Hi Jakub and Eric,
Thank you both for this deep dive.
As Eric noted, the root cause is architectural (the per-netns dst_ops),
but virtio_net with napi_tx=N seems to be a particularly vulnerable trigger.
I have verified that the TUN driver is not affected (discussed in v1 [1])
because its lifecycle management of skbs is different.
However, I haven't check other drivers that might also defer skb freeing.
Should I wait for a consensus on a more generic fix in the network core,
or would it be acceptable to land this targeted fix for virtio_net first
to address the immediate UAF?
[1] https://lore.kernel.org/all/[email protected]/
Best regards,
Tangxin Xie
