In the Linux kernel, the following vulnerability has been resolved:
powerpc/pseries: Fix potential memleak in paprgetattr()
buf is allocated in paprgetattr(), and krealloc() of buf could fail. We need to free the original buf in the case of failure.
In the Linux kernel, the following vulnerability has been resolved:
pdscore: fix debugfslookup dentry leak and error handling
debugfslookup() returns a dentry with an elevated reference count that must be released with dput(). The current code discards the returned dentry without calling dput(), causing a reference leak on every firmware reset recovery.
Additionally, when CONFIGDEBUGFS is disabled, debugfslookup() returns ERRPTR(-ENODEV), not NULL. The current check passes for error pointers and would call dput() on an invalid pointer, causing a crash.
In the Linux kernel, the following vulnerability has been resolved:
iommufd: Set upper bounds on cache invalidation entrynum and entrylen
iommufdhwptinvalidate() takes a user-controlled entrynum and entrylen, each bounded only by U32MAX. An entrylen beyond the kernel's struct size makes the copy helper verify the extra bytes are zero, scanning that excess in one uninterruptible pass; a multi-gigabyte value over zeroed user memory trips the soft-lockup watchdog.
A large entrynum is the other half, driving the backend invalidation loop with no reschedule. The VT-d nested handler, for one, copies each entry and flushes caches per iteration, pinning the CPU on a non-preemptible kernel.
Cap both in the ioctl. entrylen is held under PAGESIZE, above any request struct, and entrynum under 1 << 19, the order of a hardware invalidation queue and well beyond any real batch, bounding the per-call loop length.
In the Linux kernel, the following vulnerability has been resolved:
xfs: don't wrap around quota ids in dqiterate
LOLLM noticed that qid is an unsigned 32-bit variable. If it happens to be set to XFSDQIDMAX due to a filesystem that actually has a dquot for IDMAX, then this addition will truncate to zero and the iteration starts over. Fix this by casting to u64.
In the Linux kernel, the following vulnerability has been resolved:
mm: thp: deny THP for files on anonymous inodes
filethpenabled() incorrectly allows THP for files on anonymous inodes (e.g. guestmemfd and secretmem). These files are created via allocfilepseudo(), which does not call getwriteaccess() and leaves inode->iwritecount at 0. Combined with SISREG(inode->imode) being true, they appear as read-only regular files when CONFIGREADONLYTHPFORFS is enabled, making them eligible for THP collapse.
Anonymous inodes can never pass the inodeisopenforwrite() check since their iwritecount is never incremented through the normal VFS open path. The right thing to do is to exclude them from THP eligibility altogether, since CONFIGREADONLYTHPFORFS was designed for real filesystem files (e.g. shared libraries), not for pseudo-filesystem inodes.
For guestmemfd, this allows khugepaged and MADVCOLLAPSE to create large folios in the page cache via the collapse path, but the guestmemfd fault handler does not support large folios. This triggers WARNONONCE(foliotestlarge(folio)) in kvmgmemfaultusermapping().
For secretmem, collapsefile() tries to copy page contents through the direct map, but secretmem pages are removed from the direct map. This can result in a kernel crash:
BUG: unable to handle page fault for address: ffff88810284d000 RIP: 0010:memcpyorig+0x16/0x130 Call Trace: collapsefile hpagecollapsescanfile madvisecollapse
Secretmem is not affected by the crash on upstream as the memory failure recovery handles the failed copy gracefully, but it still triggers confusing false memory failure reports:
Memory failure: 0x106d96f: recovery action for clean unevictable LRU page: Recovered
Check ISANONFILE(inode) in filethpenabled() to deny THP for all anonymous inode files.
In the Linux kernel, the following vulnerability has been resolved:
mm: prevent derefencing NULL ptr in pfnsectionvalid()
Commit 5ec8e8ea8b77 ("mm/sparsemem: fix race in accessing memorysection->usage") changed pfnsectionvalid() to add a READONCE() call around "ms->usage" to fix a race with sectiondeactivate() where ms->usage can be cleared. The READONCE() call, by itself, is not enough to prevent NULL pointer dereference. We need to check its value before dereferencing it.
In the Linux kernel, the following vulnerability has been resolved:
md: fix kmemleak of rdev->serial
If kobjectadd() is fail in bindrdevtoarray(), 'rdev->serial' will be alloc not be freed, and kmemleak occurs.
unreferenced object 0xffff88815a350000 (size 49152): comm "mdadm", pid 789, jiffies 4294716910 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc f773277a): [<0000000058b0a453>] kmemleakalloc+0x61/0xe0 [<00000000366adf14>] kmalloclargenode+0x15e/0x270 [<000000002e82961b>] kmallocnode.cold+0x11/0x7f [<00000000f206d60a>] kvmallocnode+0x74/0x150 [<0000000034bf3363>] rdevinitserial+0x67/0x170 [<0000000010e08fe9>] mddevcreateserialpool+0x62/0x220 [<00000000c3837bf0>] bindrdevtoarray+0x2af/0x630 [<0000000073c28560>] mdaddnewdisk+0x400/0x9f0 [<00000000770e30ff>] mdioctl+0x15bf/0x1c10 [<000000006cfab718>] blkdevioctl+0x191/0x3f0 [<0000000085086a11>] vfsioctl+0x22/0x60 [<0000000018b656fe>] x64sysioctl+0xba/0xe0 [<00000000e54e675e>] dosyscall64+0x71/0x150 [<000000008b0ad622>] entrySYSCALL64afterhwframe+0x6c/0x74
In the Linux kernel, the following vulnerability has been resolved:
vfio/fsl-mc: Block calling interrupt handler without trigger
The eventfdctx trigger pointer of the vfiofslmcirq object is initially NULL and may become NULL if the user sets the trigger eventfd to -1. The interrupt handler itself is guaranteed that trigger is always valid between requestirq() and freeirq(), but the loopback testing mechanisms to invoke the handler function need to test the trigger. The triggering and setting ioctl paths both make use of igate and are therefore mutually exclusive.
The vfio-fsl-mc driver does not make use of irqfds, nor does it support any sort of masking operations, therefore unlike vfio-pci and vfio-platform, the flow can remain essentially unchanged.
In the Linux kernel, the following vulnerability has been resolved:
vfio/pci: Disable auto-enable of exclusive INTx IRQ
Currently for devices requiring masking at the irqchip for INTx, ie. devices without DisINTx support, the IRQ is enabled in requestirq() and subsequently disabled as necessary to align with the masked status flag. This presents a window where the interrupt could fire between these events, resulting in the IRQ incrementing the disable depth twice. This would be unrecoverable for a user since the masked flag prevents nested enables through vfio.
Instead, invert the logic using IRQFNOAUTOEN such that exclusive INTx is never auto-enabled, then unmask as required.
In the Linux kernel, the following vulnerability has been resolved:
media: pvrusb2: fix uaf in pvr2contextsetnotify
[Syzbot reported] BUG: KASAN: slab-use-after-free in pvr2contextsetnotify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35 Read of size 4 at addr ffff888113aeb0d8 by task kworker/1:1/26
CPU: 1 PID: 26 Comm: kworker/1:1 Not tainted 6.8.0-rc1-syzkaller-00046-gf1a27f081c1f #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 Workqueue: usbhubwq hubevent Call Trace: <TASK> dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0xd9/0x1b0 lib/dumpstack.c:106 printaddressdescription mm/kasan/report.c:377 [inline] printreport+0xc4/0x620 mm/kasan/report.c:488 kasanreport+0xda/0x110 mm/kasan/report.c:601 pvr2contextsetnotify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35 pvr2contextnotify drivers/media/usb/pvrusb2/pvrusb2-context.c:95 [inline] pvr2contextdisconnect+0x94/0xb0 drivers/media/usb/pvrusb2/pvrusb2-context.c:272
Freed by task 906: kasansavestack+0x33/0x50 mm/kasan/common.c:47 kasansavetrack+0x14/0x30 mm/kasan/common.c:68 kasansavefreeinfo+0x3f/0x60 mm/kasan/generic.c:640 poisonslabobject mm/kasan/common.c:241 [inline] kasanslabfree+0x106/0x1b0 mm/kasan/common.c:257 kasanslabfree include/linux/kasan.h:184 [inline] slabfreehook mm/slub.c:2121 [inline] slabfree mm/slub.c:4299 [inline] kfree+0x105/0x340 mm/slub.c:4409 pvr2contextcheck drivers/media/usb/pvrusb2/pvrusb2-context.c:137 [inline] pvr2contextthreadfunc+0x69d/0x960 drivers/media/usb/pvrusb2/pvrusb2-context.c:158
[Analyze] Task A set disconnectflag = !0, which resulted in Task B's condition being met and releasing mp, leading to this issue.
[Fix] Place the disconnectflag assignment operation after all code in pvr2contextdisconnect() to avoid this issue.
In the Linux kernel, the following vulnerability has been resolved:
mm/memoryhotplug: fix memory block reference leak on remove
Patch series "mm: Fix memory block leaks and locking", v2.
This series fixes two memory block device reference leaks and one locking issue around the per-memoryblock hwpoison counter.
This patch (of 2):
removememoryblocksandaltmaps() looks up each memory block with findmemoryblock(), which acquires a reference to the memory block device.
That reference is never dropped on this path, resulting in a leaked device reference when removing memory blocks and their altmaps. Drop the reference after retrieving mem->altmap and clearing mem->altmap, before removing the memory block device.
dm-raid: really frozen syncthread during suspend
A flaw in the Linux Kernel found in the Open vSwitch Kernel module.
The Netlink copy code in the ovs kernel module attempts to make an in-kernel copy of the actions required. That means that when recursive operations, like sample(), clone(), decttl(), etc include additional actions, the code pushes a new stack frame and recursively calls into the code block.
Unfortunately, OVS module doesn't validate the stack depth, and will push too many frames causing a stack overflow which can lead to crash.
Reference: https://lore.kernel.org/all/20240207132416.1488485-1-aconole@redhat.com/
In the Linux kernel, the following vulnerability has been resolved:
ASoC: mediatek: mt8195: Set ETDM1/2 IN/OUT to COMPDUMMY()
ETDM2INBE and ETDM1OUTBE are defined as COMPEMPTY(), in the case the codec dainame will be null.
Avoid a crash if the device tree is not assigning a codec to these links.
[ 1.179936] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 1.181065] Mem abort info: [ 1.181420] ESR = 0x0000000096000004 [ 1.181892] EC = 0x25: DABT (current EL), IL = 32 bits [ 1.182576] SET = 0, FnV = 0 [ 1.182964] EA = 0, S1PTW = 0 [ 1.183367] FSC = 0x04: level 0 translation fault [ 1.183983] Data abort info: [ 1.184406] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 1.185097] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 1.185766] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 1.186439] [0000000000000000] user address but activemm is swapper [ 1.187239] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 1.188029] Modules linked in: [ 1.188420] CPU: 7 UID: 0 PID: 70 Comm: kworker/u32:1 Not tainted 6.14.0-rc4-next-20250226+ #85 [ 1.189515] Hardware name: Radxa NIO 12L (DT) [ 1.190065] Workqueue: eventsunbound deferredprobeworkfunc [ 1.190808] pstate: 40400009 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1.191683] pc : pistrcmp+0x24/0x140 [ 1.192170] lr : mt8195mt6359soccardprobe+0x224/0x7b0 [ 1.192854] sp : ffff800083473970 [ 1.193271] x29: ffff800083473a10 x28: 0000000000001008 x27: 0000000000000002 [ 1.194168] x26: ffff800082408960 x25: ffff800082417db0 x24: ffff800082417d88 [ 1.195065] x23: 000000000000001e x22: ffff800082dbf480 x21: ffff800082dc07b8 [ 1.195961] x20: 0000000000000000 x19: 0000000000000013 x18: 00000000ffffffff [ 1.196858] x17: 000000040044ffff x16: 005000f2b5503510 x15: 0000000000000006 [ 1.197755] x14: ffff800082407af0 x13: 6e6f69737265766e x12: 692d6b636f6c6374 [ 1.198651] x11: 0000000000000002 x10: ffff80008240b920 x9 : 0000000000000018 [ 1.199547] x8 : 0101010101010101 x7 : 0000000000000000 x6 : 0000000000000000 [ 1.200443] x5 : 0000000000000000 x4 : 8080808080000000 x3 : 303933383978616d [ 1.201339] x2 : 0000000000000000 x1 : ffff80008240b920 x0 : 0000000000000000 [ 1.202236] Call trace: [ 1.202545] pistrcmp+0x24/0x140 (P) [ 1.203029] mtksoundcardcommonprobe+0x3bc/0x5b8 [ 1.203644] platformprobe+0x70/0xe8 [ 1.204106] reallyprobe+0xc8/0x3a0 [ 1.204556] driverprobedevice+0x84/0x160 [ 1.205104] driverprobedevice+0x44/0x130 [ 1.205630] deviceattachdriver+0xc4/0x170 [ 1.206189] busforeachdrv+0x8c/0xf8 [ 1.206672] deviceattach+0xa8/0x1c8 [ 1.207155] deviceinitialprobe+0x1c/0x30 [ 1.207681] busprobedevice+0xb0/0xc0 [ 1.208165] deferredprobeworkfunc+0xa4/0x100 [ 1.208747] processonework+0x158/0x3e0 [ 1.209254] workerthread+0x2c4/0x3e8 [ 1.209727] kthread+0x134/0x1f0 [ 1.210136] retfromfork+0x10/0x20 [ 1.210589] Code: 54000401 b50002c6 d503201f f86a6803 (f8408402) [ 1.211355] ---[ end trace 0000000000000000 ]---
In the Linux kernel, the following vulnerability has been resolved:
drm/imagination: Synchronize interrupts before suspending the GPU
The runtime PM suspend callback doesn't know whether the IRQ handler is in progress on a different CPU core and doesn't wait for it to finish.
Depending on timing, the IRQ handler could be running while the GPU is suspended, leading to kernel crashes when trying to access GPU registers. See example signature below.
In a power off sequence initiated by the runtime PM suspend callback, wait for any IRQ handlers in progress on other CPU cores to finish, by calling synchronizeirq().
At the same time, remove the runtime PM resume/put calls in the threaded IRQ handler. On top of not being the right approach to begin with, and being at the wrong place as they should have wrapped all GPU register accesses, the driver would hit a deadlock between synchronizeirq() being called from a runtime PM suspend callback, holding the device power lock, and the resume callback requiring the same.
Example crash signature on a TI AM68 SK platform:
[ 337.241218] SError Interrupt on CPU0, code 0x00000000bf000000 -- SError [ 337.241239] CPU: 0 UID: 0 PID: 112 Comm: irq/234-gpu Tainted: G M 6.17.7-B2C-00005-g9c7bbe4ea16c #2 PREEMPT [ 337.241246] Tainted: [M]=MACHINECHECK [ 337.241249] Hardware name: Texas Instruments AM68 SK (DT) [ 337.241252] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 337.241256] pc : pvrriscvirqpending+0xc/0x24 [ 337.241277] lr : pvrdeviceirqthreadhandler+0x64/0x310 [ 337.241282] sp : ffff800085b0bd30 [ 337.241284] x29: ffff800085b0bd50 x28: ffff0008070d9eab x27: ffff800083a5ce10 [ 337.241291] x26: ffff000806e48f80 x25: ffff0008070d9eac x24: 0000000000000000 [ 337.241296] x23: ffff0008068e9bf0 x22: ffff0008068e9bd0 x21: ffff800085b0bd30 [ 337.241301] x20: ffff0008070d9e00 x19: ffff0008068e9000 x18: 0000000000000001 [ 337.241305] x17: 637365645f656c70 x16: 0000000000000000 x15: ffff000b7df9ff40 [ 337.241310] x14: 0000a585fe3c0d0e x13: 000000999704f060 x12: 000000000002771a [ 337.241314] x11: 00000000000000c0 x10: 0000000000000af0 x9 : ffff800085b0bd00 [ 337.241318] x8 : ffff0008071175d0 x7 : 000000000000b955 x6 : 0000000000000003 [ 337.241323] x5 : 0000000000000000 x4 : 0000000000000002 x3 : 0000000000000000 [ 337.241327] x2 : ffff800080e39d20 x1 : ffff800080e3fc48 x0 : 0000000000000000 [ 337.241333] Kernel panic - not syncing: Asynchronous SError Interrupt [ 337.241337] CPU: 0 UID: 0 PID: 112 Comm: irq/234-gpu Tainted: G M 6.17.7-B2C-00005-g9c7bbe4ea16c #2 PREEMPT [ 337.241342] Tainted: [M]=MACHINECHECK [ 337.241343] Hardware name: Texas Instruments AM68 SK (DT) [ 337.241345] Call trace: [ 337.241348] showstack+0x18/0x24 (C) [ 337.241357] dumpstacklvl+0x60/0x80 [ 337.241364] dumpstack+0x18/0x24 [ 337.241368] vpanic+0x124/0x2ec [ 337.241373] abort+0x0/0x4 [ 337.241377] addtaint+0x0/0xbc [ 337.241384] arm64serrorpanic+0x70/0x80 [ 337.241389] doserror+0x3c/0x74 [ 337.241392] el1h64errorhandler+0x30/0x48 [ 337.241400] el1h64error+0x6c/0x70 [ 337.241404] pvrriscvirqpending+0xc/0x24 (P) [ 337.241410] irqthreadfn+0x2c/0xb0 [ 337.241416] irqthread+0x170/0x334 [ 337.241421] kthread+0x12c/0x210 [ 337.241428] retfromfork+0x10/0x20 [ 337.241434] SMP: stopping secondary CPUs [ 337.241451] Kernel Offset: disabled [ 337.241453] CPU features: 0x040000,02002800,20002001,0400421b [ 337.241456] Memory Limit: none [ 337.457921] ---[ end Kernel panic - not syncing: Asynchronous SError Interrupt ]---
In the Linux kernel, the following vulnerability has been resolved:
soc: microchip: mpfs: Fix memory leak in mpfssyscontrollerprobe()
In mpfssyscontrollerprobe(), if ofgetmtddevicebynode() fails, the function returns immediately without freeing the allocated memory for syscontroller, leading to a memory leak.
Fix this by jumping to the outfree label to ensure the memory is properly freed.
Also, consolidate the error handling for the mboxrequestchannel() failure case to use the same label.
In the Linux kernel, the following vulnerability has been resolved:
drm/imagination: Fix deadlock in soft reset sequence
The soft reset sequence is currently executed from the threaded IRQ handler, hence it cannot call disableirq() which internally waits for IRQ handlers, i.e. itself, to complete.
Use disableirqnosync() during a soft reset instead.
In the Linux kernel, the following vulnerability has been resolved:
ipv6: mcast: remove one synchronizenet() barrier in ipv6mcdown()
As discussed in the past (commit 2d3916f31891 ("ipv6: fix skb drops in igmp6eventquery() and igmp6eventreport()")) I think the synchronizenet() call in ipv6mcdown() is not needed.
Under load, synchronizenet() can last between 200 usec and 5 ms.
KASAN seems to agree as well.
In the Linux kernel, the following vulnerability has been resolved:
net/sched: actmirred: fix wrong device for macheaderxmit check in tcfblockcastredir
In tcfblockcastredir(), when iterating block ports to redirect packets to multiple devices, the macheaderxmit flag is queried from the wrong device. The loop sends to devprev but queries devismacheaderxmit(dev) — which is the NEXT device in the iteration, not the one being sent to.
This causes tcfmirredtodev() to make incorrect decisions about whether to push or pull the MAC header. When the block contains mixed device types (e.g., an ethernet veth and a tunnel device), intermediate devices get the wrong macheaderxmit flag, leading to skb header corruption. In the worst case, skbpushrcsum with an incorrect maclen can exhaust headroom and panic.
The last device in the loop is handled correctly (line 365-366 uses devismacheaderxmit(devprev)), confirming this is a copy-paste oversight for the intermediate devices.
Fix by using devprev instead of dev for the macheaderxmit query, consistent with the device actually being sent to.
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nftables: reject immediate NFQUEUE verdict
nftqueue is always used from userspace nftables to deliver the NFQUEUE verdict. Immediately emitting an NFQUEUE verdict is never used by the userspace nft tools, so reject immediate NFQUEUE verdicts.
The arp family does not provide queue support, but such an immediate verdict is still reachable. Globally reject NFQUEUE immediate verdicts to address this issue.
In the Linux kernel, the following vulnerability has been resolved:
drm/xe/display: fix oops in suspend/shutdown without display
The xe driver keeps track of whether to probe display, and whether display hardware is there, using xe->info.probedisplay. It gets set to false if there's no display after inteldisplaydeviceprobe(). However, the display may also be disabled via fuses, detected at a later time in inteldisplaydeviceinforuntimeinit().
In this case, the xe driver does foreachintelcrtc() on uninitialized mode config in xedisplayflushcleanupwork(), leading to a NULL pointer dereference, and generally calls display code with display info cleared.
Check for inteldisplaydevicepresent() after inteldisplaydeviceinforuntimeinit(), and reset xe->info.probedisplay as necessary. Also do unsetdisplayfeatures() for completeness, although display runtime init has already done that. This will need to be unified across all cases later.
Move inteldisplaydeviceinforuntimeinit() call slightly earlier, similar to i915, to avoid a bunch of unnecessary setup for no display cases.
Note #1: The xe driver has no business doing low level display plumbing like foreachintelcrtc() to begin with. It all needs to happen in display code.
Note #2: The actual bug is present already in commit 44e694958b95 ("drm/xe/display: Implement display support"), but the oops was likely introduced later at commit ddf6492e0e50 ("drm/xe/display: Make display suspend/resume work on discrete").
(cherry picked from commit 7c3eb9f47533220888a67266448185fd0775d4da)
In the Linux kernel, the following vulnerability has been resolved:
drm/v3d: Fix vaddr leak when indirect CSD has zeroed workgroups
v3drewritecsdjobwgcountsfromindirect() maps both the indirect buffer and the workgroup buffer and is expected to release them before returning. When any of the workgroup counts read from the buffer is zero, the function bailed out early and skipped the cleanup, leaking the vaddr mappings of both BOs.
Jump to the cleanup path instead of returning directly, so the mappings are always dropped.
In the Linux kernel, the following vulnerability has been resolved:
tee: shm: fix shm leak in registershmhelper()
registershmhelper() allocates shm before calling ioviternpages(). If ioviternpages() returns 0, the function jumps to errctxput and leaks shm.
This can be triggered by TEEIOCSHMREGISTER with struct teeioctlshmregisterdata where length is 0.
Jump to errfreeshm instead.
In the Linux kernel, the following vulnerability has been resolved:
media: chips-media: wave5: Fix memory leak on codecinfo allocation failure
In wave5vpuopenenc() and wave5vpuopendec(), a vpu instance is allocated via kzalloc(). If the subsequent allocation for inst->codecinfo fails, the functions return -ENOMEM without freeing the previously allocated instance, causing a memory leak.
Fix this by calling kfree() on the instance in this error path to ensure it is properly released.
In the Linux kernel, the following vulnerability has been resolved:
RDMA/mana: Fix manadestroywqobj() cleanup in manaibcreateqprss()
Sashiko points out there are two bugs here in the error unwind flow, both related to how the WQ table is unwound.
First there is a double i-- on the first failure path due to the while loop having a i--, remove it.
Second if manaibinstallcqcb() fails then manacreatewqobj() is not undone due to the above i--.
In the Linux kernel, the following vulnerability has been resolved:
block: fix deadlock between bdlinkdiskholder and partition scan
'openmutex' of gendisk is used to protect open/close block devices. But in bdlinkdiskholder(), it is used to protect the creation of symlink between holding disk and slave bdev, which introduces some issues.
When bdlinkdiskholder() is called, the driver is usually in the process of initialization/modification and may suspend submitting io. At this time, any io hold 'openmutex', such as scanning partitions, can cause deadlocks. For example, in raid:
T1 T2 bdevopenbydev lock openmutex [1] ... efipartition ... mdsubmitbio mdioctl mddevsyspend -> suspend all io mdaddnewdisk bindrdevtoarray bdlinkdiskholder try lock openmutex [2] mdhandlerequest -> wait mddevresume
T1 scan partition, T2 add a new device to raid. T1 waits for T2 to resume mddev, but T2 waits for openmutex held by T1. Deadlock occurs.
Fix it by introducing a local mutex 'blkholdermutex' to replace 'openmutex'.
In the Linux kernel, the following vulnerability has been resolved:
drm/msm/gem: fix error handling in msmioctlgeminfogetmetadata()
msmioctlgeminfogetmetadata() always returns 0 regardless of errors. When copytouser() fails or the user buffer is too small, the error code stored in ret is ignored because the function unconditionally returns 0. This causes userspace to believe the ioctl succeeded when it did not.
Additionally, kmemdup() can return NULL on allocation failure, but the return value is not checked. This leads to a NULL pointer dereference in the subsequent copytouser() call.
Add the missing NULL check for kmemdup() and return ret instead of 0.
Note that the SET counterpart (msmioctlgeminfosetmetadata) correctly returns ret.
Patchwork: https://patchwork.freedesktop.org/patch/714478/
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: afbluetooth: Fix deadlock
Attemting to do socklock on .recvmsg may cause a deadlock as shown bellow, so instead of using socksock this uses skreceivequeue.lock on btsockioctl to avoid the UAF:
INFO: task kworker/u9:1:121 blocked for more than 30 seconds. Not tainted 6.7.6-lemon #183 Workqueue: hci0 hcirxwork Call Trace: <TASK> schedule+0x37d/0xa00 schedule+0x32/0xe0 locksock+0x68/0xa0 ? pfxautoremovewakefunction+0x10/0x10 locksocknested+0x43/0x50 l2capsockrecvcb+0x21/0xa0 l2caprecvframe+0x55b/0x30a0 ? psitaskswitch+0xeb/0x270 ? finishtaskswitch.isra.0+0x93/0x2a0 hcirxwork+0x33a/0x3f0 processonework+0x13a/0x2f0 workerthread+0x2f0/0x410 ? pfxworkerthread+0x10/0x10 kthread+0xe0/0x110 ? pfxkthread+0x10/0x10 retfromfork+0x2c/0x50 ? pfxkthread+0x10/0x10 retfromforkasm+0x1b/0x30 </TASK>
In the Linux kernel, the following vulnerability has been resolved:
rxrpc, afs: Fix missing error pointer check after rxrpckernellookuppeer()
rxrpckernellookuppeer() can also return error pointers in addition to NULL, so just checking for NULL is not sufficient.
Fix this by:
(1) Changing rxrpckernellookuppeer() to return -ENOMEM rather than NULL on allocation failure.
(2) Making the callers in afs use ISERR() and PTRERR() to pass on the error code returned.
In the Linux kernel, the following vulnerability has been resolved:
scsi: ufs: core: Fix SError in ufshcdrtcwork() during UFS suspend
In ufshcdwlsuspend(), canceldelayedworksync() is called to cancel the UFS RTC work, but it is placed after ufshcdvopssuspend(hba, pmop, POSTCHANGE). This creates a race condition where ufshcdrtcwork() can still be running while ufshcdvopssuspend() is executing. When UFSHCDCAPCLKGATING is not supported, the condition !hba->clkgating.activereqs is always true, causing ufshcdupdatertc() to be executed. Since ufshcdvopssuspend() typically performs clock gating operations, executing ufshcdupdatertc() at that moment triggers an SError. The kernel panic trace is as follows:
Kernel panic - not syncing: Asynchronous SError Interrupt Call trace: dumpbacktrace+0xec/0x128 showstack+0x18/0x28 dumpstacklvl+0x40/0xa0 dumpstack+0x18/0x24 panic+0x148/0x374 nmipanic+0x3c/0x8c arm64serrorpanic+0x64/0x8c doserror+0xc4/0xc8 el1h64errorhandler+0x34/0x4c el1h64error+0x68/0x6c el1interrupt+0x20/0x58 el1h64irqhandler+0x18/0x24 el1h64irq+0x68/0x6c ktimeget+0xc4/0x12c ufshcdmcqsqstop+0x4c/0xec ufshcdmcqsqcleanup+0x64/0x1dc ufshcdclearcmd+0x38/0x134 ufshcdissuedevcmd+0x298/0x4d0 ufshcdexecdevcmd+0x1a4/0x1c4 ufshcdqueryattr+0xbc/0x19c ufshcdrtcwork+0x10c/0x1c8 processscheduledworks+0x1c4/0x45c workerthread+0x32c/0x3e8 kthread+0x120/0x1d8 retfromfork+0x10/0x20
Fix this by moving canceldelayedworksync() before the call to ufshcdvopssuspend(hba, pmop, PRECHANGE), ensuring the UFS RTC work is fully completed or cancelled at that point.