In the Linux kernel, the following vulnerability has been resolved:
net: macb: Use devconsumeskbany() to free TX SKBs
The napiconsumeskb() function is not intended to be called in an IRQ disabled context. However, after commit 6bc8a5098bf4 ("net: macb: Fix txptrlock locking"), the freeing of TX SKBs is performed with IRQs disabled. To resolve the following call trace, use devconsumeskbany() for freeing TX SKBs: WARNING: kernel/softirq.c:430 at localbhenableip+0x174/0x188, CPU#0: ksoftirqd/0/15 Modules linked in: CPU: 0 UID: 0 PID: 15 Comm: ksoftirqd/0 Not tainted 7.0.0-rc4-next-20260319-yocto-standard-dirty #37 PREEMPT Hardware name: ZynqMP ZCU102 Rev1.1 (DT) pstate: 200000c5 (nzCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : localbhenableip+0x174/0x188 lr : localbhenable+0x24/0x38 sp : ffff800082b3bb10 x29: ffff800082b3bb10 x28: ffff0008031f3c00 x27: 000000000011ede0 x26: ffff000800a7ff00 x25: ffff800083937ce8 x24: 0000000000017a80 x23: ffff000803243a78 x22: 0000000000000040 x21: 0000000000000000 x20: ffff000800394c80 x19: 0000000000000200 x18: 0000000000000001 x17: 0000000000000001 x16: ffff000803240000 x15: 0000000000000000 x14: ffffffffffffffff x13: 0000000000000028 x12: ffff000800395650 x11: ffff8000821d1528 x10: ffff800081c2bc08 x9 : ffff800081c1e258 x8 : 0000000100000301 x7 : ffff8000810426ec x6 : 0000000000000000 x5 : 0000000000000001 x4 : 0000000000000001 x3 : 0000000000000000 x2 : 0000000000000008 x1 : 0000000000000200 x0 : ffff8000810428dc Call trace: localbhenableip+0x174/0x188 (P) localbhenable+0x24/0x38 skbattemptdeferfree+0x190/0x1d8 napiconsumeskb+0x58/0x108 macbtxpoll+0x1a4/0x558 napipoll+0x50/0x198 netrxaction+0x1f4/0x3d8 handlesoftirqs+0x16c/0x560 runksoftirqd+0x44/0x80 smpbootthreadfn+0x1d8/0x338 kthread+0x120/0x150 retfromfork+0x10/0x20 irq event stamp: 29751 hardirqs last enabled at (29750): [<ffff8000813be184>] rawspinunlockirqrestore+0x44/0x88 hardirqs last disabled at (29751): [<ffff8000813bdf60>] rawspinlockirqsave+0x38/0x98 softirqs last enabled at (29150): [<ffff8000800f1aec>] handlesoftirqs+0x504/0x560 softirqs last disabled at (29153): [<ffff8000800f2fec>] runksoftirqd+0x44/0x80
In the Linux kernel, the following vulnerability has been resolved:
net: macb: use the current queue number for stats
There's a potential mismatch between the memory reserved for statistics and the amount of memory written.
gemgetssetcount() correctly computes the number of stats based on the active queues, whereas gemgetethtoolstats() indiscriminately copies data using the maximum number of queues, and in the case the number of active queues is less than MACBMAXQUEUES, this results in a OOB write as observed in the KASAN splat.
================================================================== BUG: KASAN: vmalloc-out-of-bounds in gemgetethtoolstats+0x54/0x78 [macb] Write of size 760 at addr ffff80008080b000 by task ethtool/1027
CPU: [...] Tainted: [E]=UNSIGNEDMODULE Hardware name: raspberrypi rpi/rpi, BIOS 2025.10 10/01/2025 Call trace: showstack+0x20/0x38 (C) dumpstacklvl+0x80/0xf8 printreport+0x384/0x5e0 kasanreport+0xa0/0xf0 kasancheckrange+0xe8/0x190 asanmemcpy+0x54/0x98 gemgetethtoolstats+0x54/0x78 [macb 926c13f3af83b0c6fe64badb21ec87d5e93fcf65] devethtool+0x1220/0x38c0 devioctl+0x4ac/0xca8 sockdoioctl+0x170/0x1d8 sockioctl+0x484/0x5d8 arm64sysioctl+0x12c/0x1b8 invokesyscall+0xd4/0x258 el0svccommon.constprop.0+0xb4/0x240 doel0svc+0x48/0x68 el0svc+0x40/0xf8 el0t64synchandler+0xa0/0xe8 el0t64sync+0x1b0/0x1b8
The buggy address belongs to a 1-page vmalloc region starting at 0xffff80008080b000 allocated at devethtool+0x11f0/0x38c0 The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff00000a333000 pfn:0xa333 flags: 0x7fffc000000000(node=0|zone=0|lastcpupid=0x1ffff) raw: 007fffc000000000 0000000000000000 dead000000000122 0000000000000000 raw: ffff00000a333000 0000000000000000 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected
Memory state around the buggy address: ffff80008080b080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff80008080b100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff80008080b180: 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffff80008080b200: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffff80008080b280: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ==================================================================
Fix it by making sure the copied size only considers the active number of queues.