blk-mq: Fix kmemleak in blkmqinitallocatedqueue
In the Linux kernel, the following vulnerability has been resolved:
ceph: avoid putting the realm twice when decoding snaps fails
When decoding the snaps fails it maybe leaving the 'firstrealm' and 'realm' pointing to the same snaprealm memory. And then it'll put it twice and could cause random use-after-free, BUGON, etc issues.
btrfs: zoned: clone zoned device info when cloning a device
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: fix array index out of bound error in DCN32 DML
[Why&How] LinkCapacitySupport array is indexed with the number of voltage states and not the number of max DPPs. Fix the error by changing the array declaration to use the correct (larger) array size of total number of voltage states.
In the Linux kernel, the following vulnerability has been resolved:
tipc: fix a null-ptr-deref in tipctopsrvaccept
syzbot found a crash in tipctopsrvaccept:
KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] Workqueue: tipcrcv tipctopsrvaccept RIP: 0010:kernelaccept+0x22d/0x350 net/socket.c:3487 Call Trace: <TASK> tipctopsrvaccept+0x197/0x280 net/tipc/topsrv.c:460 processonework+0x991/0x1610 kernel/workqueue.c:2289 workerthread+0x665/0x1080 kernel/workqueue.c:2436 kthread+0x2e4/0x3a0 kernel/kthread.c:376 retfromfork+0x1f/0x30 arch/x86/entry/entry64.S:306
It was caused by srv->listener that might be set to null by tipctopsrvstop() in net .exit whereas it's still used in tipctopsrvaccept() worker.
srv->listener is protected by srv->idrlock in tipctopsrvstop(), so add a check for srv->listener under srv->idrlock in tipctopsrvaccept() to avoid the null-ptr-deref. To ensure the lsock is not released during the tipctopsrvaccept(), move sockrelease() after tipctopsrvworkstop() where it's waiting until the tipctopsrvaccept worker to be done.
Note that skcallbacklock is used to protect sk->skuserdata instead of srv->listener, and it should check srv in tipctopsrvlistenerdataready() instead. This also ensures that no more tipctopsrvaccept worker will be started after tipcconnclose() is called in tipctopsrvstop() where it sets sk->skuserdata to null.
In the Linux kernel, the following vulnerability has been resolved:
mm/hugememory: do not clobber swpentryt during THP split
The following has been observed when running stressng mmap since commit b653db77350c ("mm: Clear page->private when splitting or migrating a page")
watchdog: BUG: soft lockup - CPU#75 stuck for 26s! [stress-ng:9546] CPU: 75 PID: 9546 Comm: stress-ng Tainted: G E 6.0.0-revert-b653db77-fix+ #29 0357d79b60fb09775f678e4f3f64ef0579ad1374 Hardware name: SGI.COM C2112-4GP3/X10DRT-P-Series, BIOS 2.0a 05/09/2016 RIP: 0010:xasdescend+0x28/0x80 Code: cc cc 0f b6 0e 48 8b 57 08 48 d3 ea 83 e2 3f 89 d0 48 83 c0 04 48 8b 44 c6 08 48 89 77 18 48 89 c1 83 e1 03 48 83 f9 02 75 08 <48> 3d fd 00 00 00 76 08 88 57 12 c3 cc cc cc cc 48 c1 e8 02 89 c2 RSP: 0018:ffffbbf02a2236a8 EFLAGS: 00000246 RAX: ffff9cab7d6a0002 RBX: ffffe04b0af88040 RCX: 0000000000000002 RDX: 0000000000000030 RSI: ffff9cab60509b60 RDI: ffffbbf02a2236c0 RBP: 0000000000000000 R08: ffff9cab60509b60 R09: ffffbbf02a2236c0 R10: 0000000000000001 R11: ffffbbf02a223698 R12: 0000000000000000 R13: ffff9cab4e28da80 R14: 0000000000039c01 R15: ffff9cab4e28da88 FS: 00007fab89b85e40(0000) GS:ffff9cea3fcc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fab84e00000 CR3: 00000040b73a4003 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> xasload+0x3a/0x50 filemapgetfolio+0x80/0x370 ? putswappage+0x163/0x360 pagecachegetpage+0x13/0x90 trytoreclaimswap+0x50/0x190 scanswapmapslots+0x31e/0x670 getswappages+0x226/0x3c0 folioallocswap+0x1cc/0x240 addtoswap+0x14/0x70 shrinkpagelist+0x968/0xbc0 reclaimpagelist+0x70/0xf0 reclaimpages+0xdd/0x120 madvisecoldorpageoutpterange+0x814/0xf30 walkpgdrange+0x637/0xa30 walkpagerange+0x142/0x170 walkpagerange+0x146/0x170 madvisepageout+0xb7/0x280 ? asmcommoninterrupt+0x22/0x40 madvisevmabehavior+0x3b7/0xac0 ? findvma+0x4a/0x70 ? findvma+0x64/0x70 ? madvisevmaanonname+0x40/0x40 madvisewalkvmas+0xa6/0x130 domadvise+0x2f4/0x360 x64sysmadvise+0x26/0x30 dosyscall64+0x5b/0x80 ? dosyscall64+0x67/0x80 ? syscallexittousermode+0x17/0x40 ? dosyscall64+0x67/0x80 ? syscallexittousermode+0x17/0x40 ? dosyscall64+0x67/0x80 ? dosyscall64+0x67/0x80 ? commoninterrupt+0x8b/0xa0 entrySYSCALL64afterhwframe+0x63/0xcd
The problem can be reproduced with the mmtests config config-workload-stressng-mmap. It does not always happen and when it triggers is variable but it has happened on multiple machines.
The intent of commit b653db77350c patch was to avoid the case where PGprivate is clear but folio->private is not-NULL. However, THP tail pages uses page->private for "swpentryt if foliotestswapcache()" as stated in the documentation for struct folio. This patch only clobbers page->private for tail pages if the head page was not in swapcache and warns once if page->private had an unexpected value.
In the Linux kernel, the following vulnerability has been resolved:
drm/msm: fix use-after-free on probe deferral
The bridge counter was never reset when tearing down the DRM device so that stale pointers to deallocated structures would be accessed on the next tear down (e.g. after a second late bind deferral).
Given enough bridges and a few probe deferrals this could currently also lead to data beyond the bridge array being corrupted.
Patchwork: https://patchwork.freedesktop.org/patch/502665/
In the Linux kernel, the following vulnerability has been resolved:
drm/msm/hdmi: fix memory corruption with too many bridges
Add the missing sanity check on the bridge counter to avoid corrupting data beyond the fixed-sized bridge array in case there are ever more than eight bridges.
Patchwork: https://patchwork.freedesktop.org/patch/502670/
In the Linux kernel, the following vulnerability has been resolved:
media: atomisp: prevent integer overflow in shcsssetblackframe()
The "height" and "width" values come from the user so the "height width" multiplication can overflow.
In the Linux kernel, the following vulnerability has been resolved:
drm/msm/dsi: fix memory corruption with too many bridges
Add the missing sanity check on the bridge counter to avoid corrupting data beyond the fixed-sized bridge array in case there are ever more than eight bridges.
Patchwork: https://patchwork.freedesktop.org/patch/502668/
In the Linux kernel, the following vulnerability has been resolved:
skmsg: pass gfp argument to allocskmsg()
syzbot found that allocskmsg() could be called from a non sleepable context. skpsockverdictrecv() uses rcureadlock() protection.
We need the callers to pass a gfpt argument to avoid issues.
syzbot report was:
BUG: sleeping function called from invalid context at include/linux/sched/mm.h:274 inatomic(): 0, irqsdisabled(): 0, nonblock: 0, pid: 3613, name: syz-executor414 preemptcount: 0, expected: 0 RCU nest depth: 1, expected: 0 INFO: lockdep is turned off. CPU: 0 PID: 3613 Comm: syz-executor414 Not tainted 6.0.0-syzkaller-09589-g55be6084c8e0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022 Call Trace: <TASK> dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x1e3/0x2cb lib/dumpstack.c:106 mightresched+0x538/0x6a0 kernel/sched/core.c:9877 mightalloc include/linux/sched/mm.h:274 [inline] slabpreallochook mm/slab.h:700 [inline] slaballocnode mm/slub.c:3162 [inline] slaballoc mm/slub.c:3256 [inline] kmemcachealloctrace+0x59/0x310 mm/slub.c:3287 kmalloc include/linux/slab.h:600 [inline] kzalloc include/linux/slab.h:733 [inline] allocskmsg net/core/skmsg.c:507 [inline] skpsockskbingressself+0x5c/0x330 net/core/skmsg.c:600 skpsockverdictapply+0x395/0x440 net/core/skmsg.c:1014 skpsockverdictrecv+0x34d/0x560 net/core/skmsg.c:1201 tcpreadskb+0x4a1/0x790 net/ipv4/tcp.c:1770 tcprcvestablished+0x129d/0x1a10 net/ipv4/tcpinput.c:5971 tcpv4dorcv+0x479/0xac0 net/ipv4/tcpipv4.c:1681 skbacklogrcv include/net/sock.h:1109 [inline] releasesock+0x1d8/0x4c0 net/core/sock.c:2906 releasesock+0x5d/0x1c0 net/core/sock.c:3462 tcpsendmsg+0x36/0x40 net/ipv4/tcp.c:1483 socksendmsgnosec net/socket.c:714 [inline] socksendmsg net/socket.c:734 [inline] syssendto+0x46d/0x5f0 net/socket.c:2117 dosyssendto net/socket.c:2129 [inline] sesyssendto net/socket.c:2125 [inline] x64syssendto+0xda/0xf0 net/socket.c:2125 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x2b/0x70 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x63/0xcd
In the Linux kernel, the following vulnerability has been resolved:
ata: ahci: Match EMMAXSLOTS with SATAPMPMAXPORTS
UBSAN complains about array-index-out-of-bounds: [ 1.980703] kernel: UBSAN: array-index-out-of-bounds in /build/linux-9H675w/linux-5.15.0/drivers/ata/libahci.c:968:41 [ 1.980709] kernel: index 15 is out of range for type 'ahciempriv [8]' [ 1.980713] kernel: CPU: 0 PID: 209 Comm: scsieh8 Not tainted 5.15.0-25-generic #25-Ubuntu [ 1.980716] kernel: Hardware name: System manufacturer System Product Name/P5Q3, BIOS 1102 06/11/2010 [ 1.980718] kernel: Call Trace: [ 1.980721] kernel: <TASK> [ 1.980723] kernel: showstack+0x52/0x58 [ 1.980729] kernel: dumpstacklvl+0x4a/0x5f [ 1.980734] kernel: dumpstack+0x10/0x12 [ 1.980736] kernel: ubsanepilogue+0x9/0x45 [ 1.980739] kernel: ubsanhandleoutofbounds.cold+0x44/0x49 [ 1.980742] kernel: ahciqcissue+0x166/0x170 [libahci] [ 1.980748] kernel: ataqcissue+0x135/0x240 [ 1.980752] kernel: ataexecinternalsg+0x2c4/0x580 [ 1.980754] kernel: ? vprintkdefault+0x1d/0x20 [ 1.980759] kernel: ataexecinternal+0x67/0xa0 [ 1.980762] kernel: satapmpread+0x8d/0xc0 [ 1.980765] kernel: satapmpreadgscr+0x3c/0x90 [ 1.980768] kernel: satapmpattach+0x8b/0x310 [ 1.980771] kernel: ataehrevalidateandattach+0x28c/0x4b0 [ 1.980775] kernel: ataehrecover+0x6b6/0xb30 [ 1.980778] kernel: ? ahcidohardreset+0x180/0x180 [libahci] [ 1.980783] kernel: ? ahcistopengine+0xb0/0xb0 [libahci] [ 1.980787] kernel: ? ahcidosoftreset+0x290/0x290 [libahci] [ 1.980792] kernel: ? traceeventraweventataehlinkautopsyqc+0xe0/0xe0 [ 1.980795] kernel: satapmpehrecover.isra.0+0x214/0x560 [ 1.980799] kernel: satapmperrorhandler+0x23/0x40 [ 1.980802] kernel: ahcierrorhandler+0x43/0x80 [libahci] [ 1.980806] kernel: atascsiporterrorhandler+0x2b1/0x600 [ 1.980810] kernel: atascsierror+0x9c/0xd0 [ 1.980813] kernel: scsierrorhandler+0xa1/0x180 [ 1.980817] kernel: ? scsiunjamhost+0x1c0/0x1c0 [ 1.980820] kernel: kthread+0x12a/0x150 [ 1.980823] kernel: ? setkthreadstruct+0x50/0x50 [ 1.980826] kernel: retfromfork+0x22/0x30 [ 1.980831] kernel: </TASK>
This happens because satapmpinitlinks() initialize link->pmp up to SATAPMPMAXPORTS while empriv is declared as 8 elements array.
I can't find the maximum Enclosure Management ports specified in AHCI spec v1.3.1, but "12.2.1 LED message type" states that "Port Multiplier Information" can utilize 4 bits, which implies it can support up to 16 ports. Hence, use SATAPMPMAXPORTS as EMMAXSLOTS to resolve the issue.
BugLink: https://bugs.launchpad.net/bugs/1970074
In the Linux kernel, the following vulnerability has been resolved:
ip6mr: fix UAF issue in ip6mrskdone() when addrconfinitnet() failed
If the initialization fails in calling addrconfinitnet(), devconfall is the pointer that has been released. Then ip6mrskdone() is called to release the net, accessing devconf->mcforwarding directly causes invalid pointer access.
The process is as follows: setupnet() opsinit() addrconfinitnet() all = kmemdup(...) ---> alloc "all" ... net->ipv6.devconfall = all; addrconfsysctlregister() ---> failed ... kfree(all); ---> ipv6.devconfall invalid ... opsexitlist() ... ip6mrskdone() devconf = net->ipv6.devconfall; //devconf is invalid pointer if (!devconf || !atomicread(&devconf->mcforwarding))
The following is the Call Trace information: BUG: KASAN: use-after-free in ip6mrskdone+0x112/0x3a0 Read of size 4 at addr ffff888075508e88 by task ip/14554 Call Trace: <TASK> dumpstacklvl+0x8e/0xd1 printreport+0x155/0x454 kasanreport+0xba/0x1f0 kasancheckrange+0x35/0x1b0 ip6mrskdone+0x112/0x3a0 rawv6close+0x48/0x70 inetrelease+0x109/0x230 inet6release+0x4c/0x70 sockrelease+0x87/0x1b0 igmp6netexit+0x6b/0x170 opsexitlist+0xb0/0x170 setupnet+0x7ac/0xbd0 copynetns+0x2e6/0x6b0 createnewnamespaces+0x382/0xa50 unsharensproxynamespaces+0xa6/0x1c0 ksysunshare+0x3a4/0x7e0 x64sysunshare+0x2d/0x40 dosyscall64+0x35/0x80 entrySYSCALL64afterhwframe+0x46/0xb0 RIP: 0033:0x7f7963322547
</TASK> Allocated by task 14554: kasansavestack+0x1e/0x40 kasansettrack+0x21/0x30 kasankmalloc+0xa1/0xb0 kmallocnodetrackcaller+0x4a/0xb0 kmemdup+0x28/0x60 addrconfinitnet+0x1be/0x840 opsinit+0xa5/0x410 setupnet+0x5aa/0xbd0 copynetns+0x2e6/0x6b0 createnewnamespaces+0x382/0xa50 unsharensproxynamespaces+0xa6/0x1c0 ksysunshare+0x3a4/0x7e0 x64sysunshare+0x2d/0x40 dosyscall64+0x35/0x80 entrySYSCALL64afterhwframe+0x46/0xb0
Freed by task 14554: kasansavestack+0x1e/0x40 kasansettrack+0x21/0x30 kasansavefreeinfo+0x2a/0x40 kasanslabfree+0x155/0x1b0 slabfreefreelisthook+0x11b/0x220 kmemcachefree+0xa4/0x360 addrconfinitnet+0x623/0x840 opsinit+0xa5/0x410 setupnet+0x5aa/0xbd0 copynetns+0x2e6/0x6b0 createnewnamespaces+0x382/0xa50 unsharensproxynamespaces+0xa6/0x1c0 ksysunshare+0x3a4/0x7e0 x64sysunshare+0x2d/0x40 dosyscall64+0x35/0x80 entrySYSCALL64afterhwframe+0x46/0xb0
In the Linux kernel, the following vulnerability has been resolved:
mtd: core: add missing ofnodeget() in dynamic partitions code
This fixes unbalanced ofnodeput(): [ 1.078910] 6 cmdlinepart partitions found on MTD device gpmi-nand [ 1.085116] Creating 6 MTD partitions on "gpmi-nand": [ 1.090181] 0x000000000000-0x000008000000 : "nandboot" [ 1.096952] 0x000008000000-0x000009000000 : "nandfit" [ 1.103547] 0x000009000000-0x00000b000000 : "nandkernel" [ 1.110317] 0x00000b000000-0x00000c000000 : "nanddtb" [ 1.115525] ------------[ cut here ]------------ [ 1.120141] refcountt: addition on 0; use-after-free. [ 1.125328] WARNING: CPU: 0 PID: 1 at lib/refcount.c:25 refcountwarnsaturate+0xdc/0x148 [ 1.133528] Modules linked in: [ 1.136589] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.0.0-rc7-next-20220930-04543-g8cf3f7 [ 1.146342] Hardware name: Freescale i.MX8DXL DDR3L EVK (DT) [ 1.151999] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1.158965] pc : refcountwarnsaturate+0xdc/0x148 [ 1.163760] lr : refcountwarnsaturate+0xdc/0x148 [ 1.168556] sp : ffff800009ddb080 [ 1.171866] x29: ffff800009ddb080 x28: ffff800009ddb35a x27: 0000000000000002 [ 1.179015] x26: ffff8000098b06ad x25: ffffffffffffffff x24: ffff0a00ffffff05 [ 1.186165] x23: ffff00001fdf6470 x22: ffff800009ddb367 x21: 0000000000000000 [ 1.193314] x20: ffff00001fdfebe8 x19: ffff00001fdfec50 x18: ffffffffffffffff [ 1.200464] x17: 0000000000000000 x16: 0000000000000118 x15: 0000000000000004 [ 1.207614] x14: 0000000000000fff x13: ffff800009bca248 x12: 0000000000000003 [ 1.214764] x11: 00000000ffffefff x10: c0000000ffffefff x9 : 4762cb2ccb52de00 [ 1.221914] x8 : 4762cb2ccb52de00 x7 : 205d313431303231 x6 : 312e31202020205b [ 1.229063] x5 : ffff800009d55c1f x4 : 0000000000000001 x3 : 0000000000000000 [ 1.236213] x2 : 0000000000000000 x1 : ffff800009954be6 x0 : 000000000000002a [ 1.243365] Call trace: [ 1.245806] refcountwarnsaturate+0xdc/0x148 [ 1.250253] kobjectget+0x98/0x9c [ 1.253658] ofnodeget+0x20/0x34 [ 1.257072] offwnodeget+0x3c/0x54 [ 1.260652] fwnodegetnthparent+0xd8/0xf4 [ 1.264926] fwnodefullnamestring+0x3c/0xb4 [ 1.269373] devicenodestring+0x498/0x5b4 [ 1.273561] pointer+0x41c/0x5d0 [ 1.276793] vsnprintf+0x4d8/0x694 [ 1.280198] vprintkstore+0x164/0x528 [ 1.283951] vprintkemit+0x98/0x164 [ 1.287530] vprintkdefault+0x44/0x6c [ 1.291284] vprintk+0xf0/0x134 [ 1.294428] printk+0x54/0x7c [ 1.297486] ofnoderelease+0xe8/0x128 [ 1.301326] kobjectput+0x98/0xfc [ 1.304732] ofnodeput+0x1c/0x28 [ 1.308137] addmtddevice+0x484/0x6d4 [ 1.311977] addmtdpartitions+0xf0/0x1d0 [ 1.316078] parsemtdpartitions+0x45c/0x518 [ 1.320439] mtddeviceparseregister+0xb0/0x274 [ 1.325147] gpminandprobe+0x51c/0x650 [ 1.329074] platformprobe+0xa8/0xd0 [ 1.332740] reallyprobe+0x130/0x334 [ 1.336406] driverprobedevice+0xb4/0xe0 [ 1.340681] driverprobedevice+0x3c/0x1f8 [ 1.344869] driverattach+0xdc/0x1a4 [ 1.348708] busforeachdev+0x80/0xcc [ 1.352548] driverattach+0x24/0x30 [ 1.356127] busadddriver+0x108/0x1f4 [ 1.359967] driverregister+0x78/0x114 [ 1.363807] platformdriverregister+0x24/0x30 [ 1.368515] gpminanddriverinit+0x1c/0x28 [ 1.372798] dooneinitcall+0xbc/0x238 [ 1.376638] doinitcalllevel+0x94/0xb4 [ 1.380565] doinitcalls+0x54/0x94 [ 1.384058] dobasicsetup+0x1c/0x28 [ 1.387724] kernelinitfreeable+0x110/0x188 [ 1.392084] kernelinit+0x20/0x1a0 [ 1.395578] retfromfork+0x10/0x20 [ 1.399157] ---[ end trace 0000000000000000 ]--- [ 1.403782] ------------[ cut here ]------------
In the Linux kernel, the following vulnerability has been resolved:
IB/hfi1: Correctly move list in scdisable()
Commit 13bac861952a ("IB/hfi1: Fix abba locking issue with scdisable()") incorrectly tries to move a list from one list head to another. The result is a kernel crash.
The crash is triggered when a link goes down and there are waiters for a send to complete. The following signature is seen:
BUG: kernel NULL pointer dereference, address: 0000000000000030 [...] Call Trace: scdisable+0x1ba/0x240 [hfi1] piofreeze+0x3d/0x60 [hfi1] handlefreeze+0x27/0x1b0 [hfi1] processonework+0x1b0/0x380 ? processonework+0x380/0x380 workerthread+0x30/0x360 ? processonework+0x380/0x380 kthread+0xd7/0x100 ? kthreadcompleteandexit+0x20/0x20 retfromfork+0x1f/0x30
The fix is to use the correct call to move the list.
In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: Fix null-ptr-deref when xps sysfs alloc failed
There is a null-ptr-deref when xps sysfs alloc failed: BUG: KASAN: null-ptr-deref in sysfsdocreatelinksd+0x40/0xd0 Read of size 8 at addr 0000000000000030 by task gssproxy/457
CPU: 5 PID: 457 Comm: gssproxy Not tainted 6.0.0-09040-g02357b27ee03 #9 Call Trace: <TASK> dumpstacklvl+0x34/0x44 kasanreport+0xa3/0x120 sysfsdocreatelinksd+0x40/0xd0 rpcsysfsclientsetup+0x161/0x1b0 rpcnewclient+0x3fc/0x6e0 rpccreatexprt+0x71/0x220 rpccreate+0x1d4/0x350 gssprpccreate+0xc3/0x160 setgsspclnt+0xbc/0x140 writegssp+0x116/0x1a0 procregwrite+0xd6/0x130 vfswrite+0x177/0x690 ksyswrite+0xb9/0x150 dosyscall64+0x35/0x80 entrySYSCALL64afterhwframe+0x46/0xb0
When the xprtswitch sysfs alloc failed, should not add xprt and switch sysfs to it, otherwise, maybe null-ptr-deref; also initialize the 'xpssysfs' to NULL to avoid oops when destroy it.
In the Linux kernel, the following vulnerability has been resolved:
net: sched: Fix use after free in redenqueue()
We can't use "skb" again after passing it to qdiscenqueue(). This is basically identical to commit 2f09707d0c97 ("schsfb: Also store skb len before calling child enqueue").
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nftables: netlink notifier might race to release objects
commit release path is invoked via callrcu and it runs lockless to release the objects after rcu grace period. The netlink notifier handler might win race to remove objects that the transaction context is still referencing from the commit release path.
Call rcubarrier() to ensure pending rcu callbacks run to completion if the list of transactions to be destroyed is not empty.
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nftables: release flow rule object from commit path
No need to postpone this to the commit release path, since no packets are walking over this object, this is accessed from control plane only. This helped uncovered UAF triggered by races with the netlink notifier.
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix use-after-free caused by l2capreassemblesdu
Fix the race condition between the following two flows that run in parallel:
1. l2capreassemblesdu -> chan->ops->recv (l2capsockrecvcb) -> sockqueuercvskb.
2. btsockrecvmsg -> skbrecvdatagram, skbfreedatagram.
An SKB can be queued by the first flow and immediately dequeued and freed by the second flow, therefore the callers of l2capreassemblesdu can't use the SKB after that function returns. However, some places continue accessing struct l2capctrl that resides in the SKB's CB for a short time after l2capreassemblesdu returns, leading to a use-after-free condition (the stack trace is below, line numbers for kernel 5.19.8).
Fix it by keeping a local copy of struct l2capctrl.
BUG: KASAN: use-after-free in l2caprxstaterecv (net/bluetooth/l2capcore.c:6906) bluetooth Read of size 1 at addr ffff88812025f2f0 by task kworker/u17:3/43169
Workqueue: hci0 hcirxwork [bluetooth] Call Trace: <TASK> dumpstacklvl (lib/dumpstack.c:107 (discriminator 4)) printreport.cold (mm/kasan/report.c:314 mm/kasan/report.c:429) ? l2caprxstaterecv (net/bluetooth/l2capcore.c:6906) bluetooth kasanreport (mm/kasan/report.c:162 mm/kasan/report.c:493) ? l2caprxstaterecv (net/bluetooth/l2capcore.c:6906) bluetooth l2caprxstaterecv (net/bluetooth/l2capcore.c:6906) bluetooth l2caprx (net/bluetooth/l2capcore.c:7236 net/bluetooth/l2capcore.c:7271) bluetooth retfromfork (arch/x86/entry/entry64.S:306) </TASK>
Allocated by task 43169: kasansavestack (mm/kasan/common.c:39) kasanslaballoc (mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:469) kmemcacheallocnode (mm/slab.h:750 mm/slub.c:3243 mm/slub.c:3293) allocskb (net/core/skbuff.c:414) l2caprecvfrag (./include/net/bluetooth/bluetooth.h:425 net/bluetooth/l2capcore.c:8329) bluetooth l2caprecvacldata (net/bluetooth/l2capcore.c:8442) bluetooth hcirxwork (net/bluetooth/hcicore.c:3642 net/bluetooth/hcicore.c:3832) bluetooth processonework (kernel/workqueue.c:2289) workerthread (./include/linux/list.h:292 kernel/workqueue.c:2437) kthread (kernel/kthread.c:376) retfromfork (arch/x86/entry/entry64.S:306)
Freed by task 27920: kasansavestack (mm/kasan/common.c:39) kasansettrack (mm/kasan/common.c:45) kasansetfreeinfo (mm/kasan/generic.c:372) kasanslabfree (mm/kasan/common.c:368 mm/kasan/common.c:328) slabfreefreelisthook (mm/slub.c:1780) kmemcachefree (mm/slub.c:3536 mm/slub.c:3553) skbfreedatagram (./include/net/sock.h:1578 ./include/net/sock.h:1639 net/core/datagram.c:323) btsockrecvmsg (net/bluetooth/afbluetooth.c:295) bluetooth l2capsockrecvmsg (net/bluetooth/l2capsock.c:1212) bluetooth sockreaditer (net/socket.c:1087) newsyncread (./include/linux/fs.h:2052 fs/readwrite.c:401) vfsread (fs/readwrite.c:482) ksysread (fs/readwrite.c:620) dosyscall64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:120)
In the Linux kernel, the following vulnerability has been resolved:
net/smc: Fix possible leaked pernet namespace in smcinit()
In smcinit(), registerpernetsubsys(&smcnetstatops) is called without any error handling. If it fails, registering of &smcnetops won't be reverted. And if smcnlinit() fails, &smcnetstatops itself won't be reverted.
This leaves wild ops in subsystem linkedlist and when another module tries to call registerpernetoperations() it triggers page fault:
BUG: unable to handle page fault for address: fffffbfff81b964c RIP: 0010:registerpernetoperations+0x1b9/0x5f0 Call Trace: <TASK> registerpernetsubsys+0x29/0x40 ebtablesinit+0x58/0x1000 [ebtables] ...
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix tree mod log mishandling of reallocated nodes
We have been seeing the following panic in production
kernel BUG at fs/btrfs/tree-mod-log.c:677! invalid opcode: 0000 [#1] SMP RIP: 0010:treemodlogrewind+0x1b4/0x200 RSP: 0000:ffffc9002c02f890 EFLAGS: 00010293 RAX: 0000000000000003 RBX: ffff8882b448c700 RCX: 0000000000000000 RDX: 0000000000008000 RSI: 00000000000000a7 RDI: ffff88877d831c00 RBP: 0000000000000002 R08: 000000000000009f R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000100c40 R12: 0000000000000001 R13: ffff8886c26d6a00 R14: ffff88829f5424f8 R15: ffff88877d831a00 FS: 00007fee1d80c780(0000) GS:ffff8890400c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fee1963a020 CR3: 0000000434f33002 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: btrfsgetoldroot+0x12b/0x420 btrfssearcholdslot+0x64/0x2f0 ? treemodlogoldestroot+0x3d/0xf0 resolveindirectref+0xfd/0x660 ? ulistalloc+0x31/0x60 ? kmemcachealloctrace+0x114/0x2c0 findparentnodes+0x97a/0x17e0 ? ulistalloc+0x30/0x60 btrfsfindallrootssafe+0x97/0x150 iterateextentinodes+0x154/0x370 ? btrfssearchpathintree+0x240/0x240 iterateinodesfromlogical+0x98/0xd0 ? btrfssearchpathintree+0x240/0x240 btrfsioctllogicaltoino+0xd9/0x180 btrfsioctl+0xe2/0x2ec0 ? modmemcglruvecstate+0x3d/0x280 ? dosysopenat2+0x6d/0x140 ? kretprobedispatcher+0x47/0x70 ? kretproberethookhandler+0x38/0x50 ? rethooktrampolinehandler+0x82/0x140 ? archrethooktrampolinecallback+0x3b/0x50 ? kmemcachefree+0xfb/0x270 ? dosysopenat2+0xd5/0x140 x64sysioctl+0x71/0xb0 dosyscall64+0x2d/0x40
Which is this code in treemodlogrewind()
switch (tm->op) { case BTRFSMODLOGKEYREMOVEWHILEFREEING: BUGON(tm->slot < n);
This occurs because we replay the nodes in order that they happened, and when we do a REPLACE we will log a REMOVEWHILEFREEING for every slot, starting at 0. 'n' here is the number of items in this block, which in this case was 1, but we had 2 REMOVEWHILEFREEING operations.
The actual root cause of this was that we were replaying operations for a block that shouldn't have been replayed. Consider the following sequence of events
1. We have an already modified root, and we do a btrfsgettreemodseq(). 2. We begin removing items from this root, triggering KEYREPLACE for it's child slots. 3. We remove one of the 2 children this root node points to, thus triggering the root node promotion of the remaining child, and freeing this node. 4. We modify a new root, and re-allocate the above node to the root node of this other root.
The tree mod log looks something like this
logical 0 op KEYREPLACE (slot 1) seq 2 logical 0 op KEYREMOVE (slot 1) seq 3 logical 0 op KEYREMOVEWHILEFREEING (slot 0) seq 4 logical 4096 op LOGROOTREPLACE (old logical 0) seq 5 logical 8192 op KEYREMOVEWHILEFREEING (slot 1) seq 6 logical 8192 op KEYREMOVEWHILEFREEING (slot 0) seq 7 logical 0 op LOGROOTREPLACE (old logical 8192) seq 8
From here the bug is triggered by the following steps
1. Call btrfsgetoldroot() on the newroot. 2. We call treemodlogoldestroot(btrfsrootnode(newroot)), which is currently logical 0. 3. treemodlogoldestroot() calls treemodlogsearcholdest(), which gives us the KEYREPLACE seq 2, and since that's not a LOGROOTREPLACE we incorrectly believe that we don't have an old root, because we expect that the most recent change should be a LOGROOTREPLACE. 4. Back in treemodlogoldestroot() we don't have a LOGROOTREPLACE, so we don't set oldroot, we simply use our e ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
ftrace: Fix use-after-free for dynamic ftraceops
KASAN reported a use-after-free with ftrace ops [1]. It was found from vmcore that perf had registered two ops with the same content successively, both dynamic. After unregistering the second ops, a use-after-free occurred.
In ftraceshutdown(), when the second ops is unregistered, the FTRACEUPDATECALLS command is not set because there is another enabled ops with the same content. Also, both ops are dynamic and the ftrace callback function is ftraceopslistfunc, so the FTRACEUPDATETRACEFUNC command will not be set. Eventually the value of 'command' will be 0 and ftraceshutdown() will skip the rcu synchronization.
However, ftrace may be activated. When the ops is released, another CPU may be accessing the ops. Add the missing synchronization to fix this problem.
[1] BUG: KASAN: use-after-free in ftraceopslistfunc kernel/trace/ftrace.c:7020 [inline] BUG: KASAN: use-after-free in ftraceopslistfunc+0x2b0/0x31c kernel/trace/ftrace.c:7049 Read of size 8 at addr ffff56551965bbc8 by task syz-executor.2/14468
CPU: 1 PID: 14468 Comm: syz-executor.2 Not tainted 5.10.0 #7 Hardware name: linux,dummy-virt (DT) Call trace: dumpbacktrace+0x0/0x40c arch/arm64/kernel/stacktrace.c:132 showstack+0x30/0x40 arch/arm64/kernel/stacktrace.c:196 dumpstack lib/dumpstack.c:77 [inline] dumpstack+0x1b4/0x248 lib/dumpstack.c:118 printaddressdescription.constprop.0+0x28/0x48c mm/kasan/report.c:387 kasanreport mm/kasan/report.c:547 [inline] kasanreport+0x118/0x210 mm/kasan/report.c:564 checkmemoryregioninline mm/kasan/generic.c:187 [inline] asanload8+0x98/0xc0 mm/kasan/generic.c:253 ftraceopslistfunc kernel/trace/ftrace.c:7020 [inline] ftraceopslistfunc+0x2b0/0x31c kernel/trace/ftrace.c:7049 ftracegraphcall+0x0/0x4 mightsleep+0x8/0x100 include/linux/perfevent.h:1170 mightfault mm/memory.c:5183 [inline] mightfault+0x58/0x70 mm/memory.c:5171 dostrncpyfromuser lib/strncpyfromuser.c:41 [inline] strncpyfromuser+0x1f4/0x4b0 lib/strncpyfromuser.c:139 getnameflags+0xb0/0x31c fs/namei.c:149 getname+0x2c/0x40 fs/namei.c:209 [...]
Allocated by task 14445: kasansavestack+0x24/0x50 mm/kasan/common.c:48 kasansettrack mm/kasan/common.c:56 [inline] kasankmalloc mm/kasan/common.c:479 [inline] kasankmalloc.constprop.0+0x110/0x13c mm/kasan/common.c:449 kasankmalloc+0xc/0x14 mm/kasan/common.c:493 kmemcachealloctrace+0x440/0x924 mm/slub.c:2950 kmalloc include/linux/slab.h:563 [inline] kzalloc include/linux/slab.h:675 [inline] perfeventalloc.part.0+0xb4/0x1350 kernel/events/core.c:11230 perfeventalloc kernel/events/core.c:11733 [inline] dosysperfeventopen kernel/events/core.c:11831 [inline] sesysperfeventopen+0x550/0x15f4 kernel/events/core.c:11723 arm64sysperfeventopen+0x6c/0x80 kernel/events/core.c:11723 [...]
Freed by task 14445: kasansavestack+0x24/0x50 mm/kasan/common.c:48 kasansettrack+0x24/0x34 mm/kasan/common.c:56 kasansetfreeinfo+0x20/0x40 mm/kasan/generic.c:358 kasanslabfree.part.0+0x11c/0x1b0 mm/kasan/common.c:437 kasanslabfree mm/kasan/common.c:445 [inline] kasanslabfree+0x2c/0x40 mm/kasan/common.c:446 slabfreehook mm/slub.c:1569 [inline] slabfreefreelisthook mm/slub.c:1608 [inline] slabfree mm/slub.c:3179 [inline] kfree+0x12c/0xc10 mm/slub.c:4176 perfeventalloc.part.0+0xa0c/0x1350 kernel/events/core.c:11434 perfeventalloc kernel/events/core.c:11733 [inline] dosysperfeventopen kernel/events/core.c:11831 [inline] sesysperfeventopen+0x550/0x15f4 kernel/events/core.c:11723 [...]
In the Linux kernel, the following vulnerability has been resolved:
x86/tdx: Panic on bad configs that #VE on "private" memory access
All normal kernel memory is "TDX private memory". This includes everything from kernel stacks to kernel text. Handling exceptions on arbitrary accesses to kernel memory is essentially impossible because they can happen in horribly nasty places like kernel entry/exit. But, TDX hardware can theoretically deliver a virtualization exception (#VE) on any access to private memory.
But, it's not as bad as it sounds. TDX can be configured to never deliver these exceptions on private memory with a "TD attribute" called ATTRSEPTVEDISABLE. The guest has no way to set this attribute, but it can check it.
Ensure ATTRSEPTVEDISABLE is set in early boot. panic() if it is unset. There is no sane way for Linux to run with this attribute clear so a panic() is appropriate.
There's small window during boot before the check where kernel has an early #VE handler. But the handler is only for port I/O and will also panic() as soon as it sees any other #VE, such as a one generated by a private memory access.
[ dhansen: Rewrite changelog and rebase on new tdxparsetdinfo(). Add Kirill's tested-by because I made changes since he wrote this. ]
In the Linux kernel, the following vulnerability has been resolved:
KVM: Initialize gfntopfncache locks in dedicated helper
Move the gfntopfncache lock initialization to another helper and call the new helper during VM/vCPU creation. There are race conditions possible due to kvmgfntopfncacheinit()'s ability to re-initialize the cache's locks.
For example: a race between ioctl(KVMXENHVMEVTCHNSEND) and kvmgfntopfncacheinit() leads to a corrupted shinfo gpc lock.
(thread 1) | (thread 2) | kvmxensetevtchnfast | readlockirqsave(&gpc->lock, ...) | | kvmgfntopfncacheinit | rwlockinit(&gpc->lock) readunlockirqrestore(&gpc->lock, ...) |
Rename "cacheinit" and "cachedestroy" to activate+deactivate to avoid implying that the cache really is destroyed/freed.
Note, there more races in the newly named kvmgpcactivate() that will be addressed separately.
[sean: call out that this is a bug fix]
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: smm: number of GPRs in the SMRAM image depends on the image format
On 64 bit host, if the guest doesn't have X86FEATURELM, KVM will access 16 gprs to 32-bit smram image, causing out-ouf-bound ram access.
On 32 bit host, the rsmloadstate64/entersmmsavestate64 is compiled out, thus access overflow can't happen.
In the Linux kernel, the following vulnerability has been resolved:
KVM: Reject attempts to consume or refresh inactive gfntopfncache
Reject kvmgpccheck() and kvmgpcrefresh() if the cache is inactive. Not checking the active flag during refresh is particularly egregious, as KVM can end up with a valid, inactive cache, which can lead to a variety of use-after-free bugs, e.g. consuming a NULL kernel pointer or missing an mmunotifier invalidation due to the cache not being on the list of gfns to invalidate.
Note, "active" needs to be set if and only if the cache is on the list of caches, i.e. is reachable via mmunotifier events. If a relevant mmunotifier event occurs while the cache is "active" but not on the list, KVM will not acquire the cache's lock and so will not serailize the mmunotifier event with active users and/or kvmgpcrefresh().
A race between KVMXENATTRTYPESHAREDINFO and KVMXENHVMEVTCHNSEND can be exploited to trigger the bug.
1. Deactivate shinfo cache:
kvmxenhvmsetattr case KVMXENATTRTYPESHAREDINFO kvmgpcdeactivate kvmgpcunmap gpc->valid = false gpc->khva = NULL gpc->active = false
Result: active = false, valid = false
2. Cause cache refresh:
kvmarchvmioctl case KVMXENHVMEVTCHNSEND kvmxenhvmevtchnsend kvmxensetevtchn kvmxensetevtchnfast kvmgpccheck return -EWOULDBLOCK because !gpc->valid kvmxensetevtchnfast return -EWOULDBLOCK kvmgpcrefresh hvatopfnretry gpc->valid = true gpc->khva = not NULL
Result: active = false, valid = true
3. Race ioctl KVMXENHVMEVTCHNSEND against ioctl KVMXENATTRTYPESHAREDINFO:
kvmarchvmioctl case KVMXENHVMEVTCHNSEND kvmxenhvmevtchnsend kvmxensetevtchn kvmxensetevtchnfast readlock gpc->lock kvmxenhvmsetattr case KVMXENATTRTYPESHAREDINFO mutexlock kvm->lock kvmxensharedinfoinit kvmgpcactivate gpc->khva = NULL kvmgpccheck [ Check passes because gpc->valid is still true, even though gpc->khva is already NULL. ] shinfo = gpc->khva pendingbits = shinfo->evtchnpending CRASH: testandsetbit(..., pendingbits)
In the Linux kernel, the following vulnerability has been resolved:
net: gso: fix panic on fraglist with mixed head alloc types
Since commit 3dcbdb134f32 ("net: gso: Fix skbsegment splat when splitting gsosize mangled skb having linear-headed fraglist"), it is allowed to change gsosize of a GRO packet. However, that commit assumes that "checking the first listskb member suffices; i.e if either of the listskb members have non headfrag head, then the first one has too".
It turns out this assumption does not hold. We've seen BUGON being hit in skbsegment when skbs on the fraglist had differing headfrag with the vmxnet3 driver. This happens because netdevallocskb and napiallocskb can return a skb that is page backed or kmalloced depending on the requested size. As the result, the last small skb in the GRO packet can be kmalloced.
There are three different locations where this can be fixed:
(1) We could check headfrag in GRO and not allow GROing skbs with different headfrag. However, that would lead to performance regression on normal forward paths with unmodified gsosize, where !headfrag in the last packet is not a problem.
(2) Set a flag in bpfskbnetgrow and bpfskbnetshrink indicating that NETIFFSG is undesirable. That would need to eat a bit in skbuff. Furthermore, that flag can be unset when all skbs on the fraglist are page backed. To retain good performance, bpfskbnetgrow/shrink would have to walk the fraglist.
(3) Walk the fraglist in skbsegment when determining whether NETIFFSG should be cleared. This of course slows things down.
This patch implements (3). To limit the performance impact in skbsegment, the list is walked only for skbs with SKBGSODODGY set that have gsosize changed. Normal paths thus will not hit it.
We could check only the last skb but since we need to walk the whole list anyway, let's stay on the safe side.
In the Linux kernel, the following vulnerability has been resolved:
octeontx2-pf: Fix SQE threshold checking
Current way of checking available SQE count which is based on HW updated SQB count could result in driver submitting an SQE even before CQE for the previously transmitted SQE at the same index is processed in NAPI resulting losing SKB pointers, hence a leak. Fix this by checking a consumer index which is updated once CQE is processed.
In the Linux kernel, the following vulnerability has been resolved:
udf: Fix a slab-out-of-bounds write bug in udffindentry()
Syzbot reported a slab-out-of-bounds Write bug:
loop0: detected capacity change from 0 to 2048 ================================================================== BUG: KASAN: slab-out-of-bounds in udffindentry+0x8a5/0x14f0 fs/udf/namei.c:253 Write of size 105 at addr ffff8880123ff896 by task syz-executor323/3610
CPU: 0 PID: 3610 Comm: syz-executor323 Not tainted 6.1.0-rc2-syzkaller-00105-gb229b6ca5abb #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 10/11/2022 Call Trace: <TASK> dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x1b1/0x28e lib/dumpstack.c:106 printaddressdescription+0x74/0x340 mm/kasan/report.c:284 printreport+0x107/0x1f0 mm/kasan/report.c:395 kasanreport+0xcd/0x100 mm/kasan/report.c:495 kasancheckrange+0x2a7/0x2e0 mm/kasan/generic.c:189 memcpy+0x3c/0x60 mm/kasan/shadow.c:66 udffindentry+0x8a5/0x14f0 fs/udf/namei.c:253 udflookup+0xef/0x340 fs/udf/namei.c:309 lookupopen fs/namei.c:3391 [inline] openlastlookups fs/namei.c:3481 [inline] pathopenat+0x10e6/0x2df0 fs/namei.c:3710 dofilpopen+0x264/0x4f0 fs/namei.c:3740 dosysopenat2+0x124/0x4e0 fs/open.c:1310 dosysopen fs/open.c:1326 [inline] dosyscreat fs/open.c:1402 [inline] sesyscreat fs/open.c:1396 [inline] x64syscreat+0x11f/0x160 fs/open.c:1396 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x3d/0xb0 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x63/0xcd RIP: 0033:0x7ffab0d164d9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffe1a7e6bb8 EFLAGS: 00000246 ORIGRAX: 0000000000000055 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ffab0d164d9 RDX: 00007ffab0d164d9 RSI: 0000000000000000 RDI: 0000000020000180 RBP: 00007ffab0cd5a10 R08: 0000000000000000 R09: 0000000000000000 R10: 00005555573552c0 R11: 0000000000000246 R12: 00007ffab0cd5aa0 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 </TASK>
Allocated by task 3610: kasansavestack mm/kasan/common.c:45 [inline] kasansettrack+0x3d/0x60 mm/kasan/common.c:52 kasankmalloc mm/kasan/common.c:371 [inline] kasankmalloc+0x97/0xb0 mm/kasan/common.c:380 kmalloc include/linux/slab.h:576 [inline] udffindentry+0x7b6/0x14f0 fs/udf/namei.c:243 udflookup+0xef/0x340 fs/udf/namei.c:309 lookupopen fs/namei.c:3391 [inline] openlastlookups fs/namei.c:3481 [inline] pathopenat+0x10e6/0x2df0 fs/namei.c:3710 dofilpopen+0x264/0x4f0 fs/namei.c:3740 dosysopenat2+0x124/0x4e0 fs/open.c:1310 dosysopen fs/open.c:1326 [inline] dosyscreat fs/open.c:1402 [inline] sesyscreat fs/open.c:1396 [inline] x64syscreat+0x11f/0x160 fs/open.c:1396 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x3d/0xb0 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x63/0xcd
The buggy address belongs to the object at ffff8880123ff800 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 150 bytes inside of 256-byte region [ffff8880123ff800, ffff8880123ff900)
The buggy address belongs to the physical page: page:ffffea000048ff80 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x123fe head:ffffea000048ff80 order:1 compoundmapcount:0 compoundpincount:0 flags: 0xfff00000010200(slab|head|node=0|zone=1|lastcpupid=0x7ff) raw: 00fff00000010200 ffffea00004b8500 dead000000000003 ffff888012041b40 raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected pageowner tracks the page as allocated page last allocated via order 0, migratetype Unmovable, gfpmask 0x0(), pid 1, tgid 1 (swapper/0), ts 1841222404, freets 0 createdummystack mm/pageowner.c: ---truncated---