Re: [PATCH net 1/1] net: fix linkwatch UAF on uninitialized netdev

On Fri,  4 Sep 2026 06:46:44 +0000 Zihan Xi wrote:

linkwatch_fire_event() queues a net_device onto lweventlist and takes a
netdev_hold() even when the device has never been registered.

netif_carrier_on(), netif_carrier_off() and netif_carrier_event() already
skip NETREG_UNINITIALIZED. netif_dormant_*() and netif_testing_*() do
not. Pre-registration operstate changes are meant to stay local and be
consumed later by linkwatch_init_dev() in register_netdevice().

If a driver fires a dormant or testing event before register_netdevice()
and registration then fails, rtnl_newlink_create() calls free_netdev().
For NETREG_UNINITIALIZED devices, free_netdev() immediately kvfree()s
the object without draining linkwatch. The later linkwatch worker
dereferences the stale list entry and use-after-frees the device.

The same path is reachable from an unprivileged user who can unshare
user and net namespaces, because only netns-local CAP_NET_ADMIN is
required.

linkwatch_fire_event() has never rejected NETREG_UNINITIALIZED devices.
That goes back to commit 1da177e4c3f4 ("Linux-2.6.12-rc2"), the root of
this tree. Later changes only altered callers or were reverted.

commit b47300168e77 ("net: Do not fire linkwatch events
until the device is registered.")
skipped uninitialized devices in the carrier helpers only.

commit 22604c866889 ("net: Fix for initial link state in 2.6.28")
briefly added a NETREG_UNINITIALIZED return in the helper after calling
rfc2863_policy().

commit c276e098d3ee ("Revert "net: Fix for initial link state in 2.6.28"")
removed it again because that rfc2863_policy() call could take
dev_base_lock in software-interrupt context.

Fix this in linkwatch_fire_event() by ignoring NETREG_UNINITIALIZED
devices so they cannot be queued, without calling rfc2863_policy().
Pre-registration flags remain on the device and are still applied by
linkwatch_init_dev() if registration succeeds.

This commit message seems to be quite low quality.
It reads like the LLM was following some check box list rather than
allowed to think. From the bug report in cover letter the problem
seems to be that one caller (wifi test harness device) fires a
linkwatch even too early. And you think that the fix is to change 
the core helper to silently ignore this event? Just fix the buggy
driver?? Or if you think there's more than one such driver please
provide more info.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")

Since your trigger didn't exist in 2.6.12 I'm not sure why you're
pointing at that commit.

FTR, the quality of the repro is also looking like a year+ old model
following a checklist:

  This is an rtnetlink RTM_NEWLINK creation path, not a packet-sequence
  or protocol-state trigger. packetdrill cannot express creating a dummy
  lower device...

Please get a better model.