Re: [PATCH net v3] linkwatch: use __dev_put() in callers to prevent UAF
From: Eric Dumazet
Date: Mon Feb 02 2026 - 07:36:02 EST
On Sun, Feb 1, 2026 at 3:00 PM Jiayuan Chen <jiayuan.chen@xxxxxxxxx> wrote:
>
> From: Jiayuan Chen <jiayuan.chen@xxxxxxxxxx>
>
> After linkwatch_do_dev() calls __dev_put() to release the linkwatch
> reference, the device refcount may drop to 1. At this point,
> netdev_run_todo() can proceed (since linkwatch_sync_dev() sees an
> empty list and returns without blocking), wait for the refcount to
> become 1 via netdev_wait_allrefs_any(), and then free the device
> via kobject_put().
>
> This creates a use-after-free when __linkwatch_run_queue() tries to
> call netdev_unlock_ops() on the already-freed device.
>
> Note that adding netdev_lock_ops()/netdev_unlock_ops() pair in
> netdev_run_todo() before kobject_put() would not work, because
> netdev_lock_ops() is conditional - it only locks when
> netdev_need_ops_lock() returns true. If the device doesn't require
> ops_lock, linkwatch won't hold any lock, and netdev_run_todo()
> acquiring the lock won't provide synchronization.
>
> Fix this by moving __dev_put() from linkwatch_do_dev() to its
> callers. The device reference logically pairs with de-listing the
> device, so it's reasonable for the caller that did the de-listing
> to release it. This allows placing __dev_put() after all device
> accesses are complete, preventing UAF.
>
> The bug can be reproduced by adding mdelay(2000) after
> linkwatch_do_dev() in __linkwatch_run_queue(), then running:
>
> ip tuntap add mode tun name tun_test
> ip link set tun_test up
> ip link set tun_test carrier off
> ip link set tun_test carrier on
> sleep 0.5
> ip tuntap del mode tun name tun_test
>
> Fixes: 04efcee6ef8d ("net: hold instance lock during NETDEV_CHANGE")
> Reported-by: syzbot+1ec2f6a450f0b54af8c8@xxxxxxxxxxxxxxxxxxxxxxxxx
> Closes: https://lore.kernel.org/all/6824d064.a70a0220.3e9d8.001a.GAE@xxxxxxxxxx/T/
> Signed-off-by: Jiayuan Chen <jiayuan.chen@xxxxxxxxxx>
> Signed-off-by: Jiayuan Chen <jiayuan.chen@xxxxxxxxx>
Thanks a lot for this fix.
Reviewed-by: Eric Dumazet <edumazet@xxxxxxxxxx>