Re: [PATCH net v3 1/7] net: macb: manage the netdev lifetime with devres

At 2026-10-04 16:45:58, "Théo Lebrun" [off-list ref] wrote:

Hello Jiale,

Those LLM bugs are code churn, that's why you are seeing pushback.
Please don't ignore the pushback. For example on V2 you got asked to
reply to an automated message, which you didn't do.

https://lore.kernel.org/netdev/20260927153020.5311dba6@kernel.org/ (local)

On Sat Oct 3, 2026 at 10:59 AM CEST, Jiale Yao wrote:

quoted

macb_remove() frees the netdev while its managed IRQs are only
released after the remove callback returns. An interrupt in that window
can dereference the freed netdev or queue data.

Please indicate how an interrupt could land in that window.
Thinking about it for a brief instant, I cannot think of one.

I reproduced this on QEMU aarch64 virt + KASAN:
I added a macb node via an extended device tree, with its interrupt
line shared with virtio-rng. Keeping the rng busy triggers a steady
stream of interrupts during unbind/rebind, and macb_interrupt() hits the
window after `free_netdev()` on the first attempt. 

---
[    4.457077] BUG: KASAN: use-after-free in macb_interrupt+0xc40/0x1074
[    4.457569] Read of size 8 at addr ffff00000f8acac8 by task poc/82
[    4.457614] 
[    4.457938] CPU: 0 UID: 0 PID: 82 Comm: poc Not tainted 7.3.0-rc4 #1 PREEMPT 
[    4.458025] Hardware name: linux,dummy-virt (DT)
[    4.458167] Call trace:
[    4.458258]  show_stack+0x18/0x24 (C)
[    4.458321]  dump_stack_lvl+0x78/0x90
[    4.458340]  print_report+0x114/0x5cc
[    4.458353]  kasan_report+0xa4/0xf0
[    4.458363]  __asan_report_load8_noabort+0x20/0x2c
[    4.458374]  macb_interrupt+0xc40/0x1074
[    4.458385]  __handle_irq_event_percpu+0xc8/0x340
[    4.458398]  handle_irq_event+0xb0/0x1d8
[    4.458407]  handle_fasteoi_irq+0x298/0x6a0
[    4.458419]  handle_irq_desc+0xc4/0x104
[    4.458454]  generic_handle_domain_irq+0x18/0x24
[    4.458485]  gic_handle_irq+0x54/0x194
[    4.458498]  call_on_irq_stack+0x30/0x48
[    4.458511]  do_interrupt_handler+0xf0/0x130
[    4.458523]  el1_interrupt+0x3c/0x60
[    4.458538]  el1h_64_irq_handler+0x18/0x24
[    4.458550]  el1h_64_irq+0x6c/0x70
[    4.458619]  get_pfnblock_migratetype+0xd0/0x144 (P)
[    4.458638]  __free_frozen_pages+0x2d8/0xec4
[    4.458650]  free_frozen_pages+0x14/0x20
[    4.458661]  free_large_kmalloc+0xa0/0x120
[    4.458674]  kfree+0x84/0x424
[    4.458684]  kvfree+0x3c/0x4c
[    4.458694]  netdev_release+0x70/0x98
[    4.458707]  device_release+0x104/0x210
[    4.458720]  kobject_put+0x140/0x240
[    4.458731]  put_device+0x14/0x24
[    4.458740]  free_netdev+0x414/0x6c4
[    4.458752]  macb_remove+0x14c/0x19c
[    4.458763]  platform_remove+0x58/0x78
[    4.458774]  device_remove+0xb0/0x14c
[    4.458785]  device_release_driver_internal+0x2fc/0x468
[    4.458795]  device_driver_detach+0x3c/0x54
[    4.458804]  unbind_store+0xec/0x100
[    4.458814]  drv_attr_store+0x60/0x9c
[    4.458824]  sysfs_kf_write+0x170/0x1e8
[    4.458838]  kernfs_fop_write_iter+0x298/0x404
[    4.458848]  vfs_write+0x648/0x8cc
[    4.458859]  ksys_write+0xf0/0x1e0
[    4.458868]  __arm64_sys_write+0x70/0xa0
[    4.458877]  invoke_syscall+0x70/0x24c
[    4.458887]  el0_svc_common.constprop.0+0xa8/0x22c
[    4.458896]  do_el0_svc+0x44/0x5c
[    4.458905]  el0_svc+0x58/0xd0
[    4.458917]  el0t_64_sync_handler+0xa0/0xe4
[    4.458929]  el0t_64_sync+0x198/0x19c
[    4.459007] 
[    4.459053] The buggy address belongs to the physical page:
[    4.459261] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4f8ac
[    4.459384] flags: 0x3fffe0000000000(node=0|zone=0|lastcpupid=0x1ffff)
[    4.459721] raw: 03fffe0000000000 0000000000000000 dead000000000122 0000000000000000
[    4.459737] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
[    4.459781] page dumped because: kasan: bad access detected
[    4.459792] 
[    4.459799] Memory state around the buggy address:
[    4.459912]  ffff00000f8ac980: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[    4.459935]  ffff00000f8aca00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[    4.459951] >ffff00000f8aca80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[    4.459962]                                               ^
[    4.459996]  ffff00000f8acb00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[    4.460002]  ffff00000f8acb80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[    4.460020] ==================================================================
---
With the fix applied, several thousand cycles produce no report at all.

quoted

Allocate the netdev with devres as well. Since the IRQs are registered
later, devres releases them before freeing the netdev and closes the
lifetime gap.

This issue was found by a static analysis method used in our research.

Fixes: 0a4acf08ea62 ("net: macb: Use devm_request_irq()")
Cc: stable@vger.kernel.org
Signed-off-by: Jiale Yao <redacted>
---
 drivers/net/ethernet/cadence/macb_main.c | 17 +++++++----------
 1 file changed, 7 insertions(+), 10 deletions(-)

Reviewed-by: Théo Lebrun <theo.lebrun@bootlin.com>

I still give my Rb because the patch is valid. The wasted time is on net
maintainers though; they'll decide if they want it or not.

For this MACB patch, it could land in net-next as I don't see a
practical bug here (in light of the recent pushback about the # of
fixes in net).

Thanks,

--
Théo Lebrun, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com