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

[jiale yao]

At 2026-10-04 16:45:58, "Théo Lebrun" <theo.lebrun@xxxxxxxxxxx> 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@xxxxxxxxxx/
>
>On Sat Oct 3, 2026 at 10:59 AM CEST, Jiale Yao wrote:
>> 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.
>
>> 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@xxxxxxxxxxxxxxx
>> Signed-off-by: Jiale Yao <yaojiale02@xxxxxxx>
>> ---
>>  drivers/net/ethernet/cadence/macb_main.c | 17 +++++++----------
>>  1 file changed, 7 insertions(+), 10 deletions(-)
>
>Reviewed-by: Théo Lebrun <theo.lebrun@xxxxxxxxxxx>
>
>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