Re: [PATCH net] vxlan: do not arm the ageing timer on a device that is down

On Sun, Aug 09, 2026 at 08:18:29PM +0900, Baul Lee wrote:
> vxlan_changelink() arms vxlan->age_timer whenever the requested ageing
> interval differs from the configured one:
> 
> 	if (conf.age_interval != vxlan->cfg.age_interval)
> 		mod_timer(&vxlan->age_timer, jiffies);
> 
> There is no netif_running() test, so the timer is armed even on a device
> that was never brought up.  The only synchronous cancel in the driver is
> the timer_delete_sync() in vxlan_stop(), which is .ndo_stop.
> netif_close_many() drops devices without IFF_UP before
> __dev_close_many() runs, so that cancel is skipped for such a device.
> 
> vxlan_setup() sets dev->needs_free_netdev = true and age_timer is a
> member of struct vxlan_dev, so free_netdev() releases the allocation the
> timer lives in while it is still queued on a timer_base.
> expire_timers() unlinks the entry before it loads timer->function, so
> the timer core writes through the freed object's list pointers:
> 
>   BUG: KASAN: slab-use-after-free in __run_timers+0x208/0x654
>   Write of size 8 at addr ffff00001adace68 by task true/192
>    __asan_store8+0x84/0xac
>    __run_timers+0x208/0x654
>    run_timer_softirq+0x154/0x18c
>   Allocated by task 189:
>    alloc_netdev_mqs+0x64/0x720
>    rtnl_create_link+0x4ac/0x520
>    rtnl_newlink+0x758/0xd00
>   Freed by task 191:
>    netdev_release+0x40/0x58
>    netdev_run_todo+0x4a4/0x8c0
>    rtnl_dellink+0x200/0x4e8
> 
> The rtnl operations involved are netns-scoped, so an unprivileged user
> can perform them in a new user and network namespace.
> 
> Arming the timer on a down device never had an effect: vxlan_cleanup()
> returns early on !netif_running(), and vxlan_open() arms the timer for
> any non-zero interval once the device is brought up.  Add the missing
> test.
> 
> Discovered by XBOW, triaged by Baul Lee <[email protected]>
> 
> Fixes: 40051c4dcad5 ("vxlan: Allow changing ageing time")
> Cc: [email protected]
> Signed-off-by: Baul Lee <[email protected]>

Reviewed-by: Ido Schimmel <[email protected]>