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.

block: Fix page refcounts for unaligned buffers in bioreleasepages()

In the Linux kernel, the following vulnerability has been resolved:

nvme: target: rdma: fix ndev refcount leak on queue connect

nvmetrdmaqueueconnect() calls nvmetrdmafindgetdevice() which acquires a reference on the returned ndev via krefget(). On the path where the host queue backlog is exceeded and the function returns NVMESCCONNECTCTRLBUSY, reference of ndev is not released, leaking the kref.

Fix this by adding a goto to the existing putdevice label before the early return.

In the Linux kernel, the following vulnerability has been resolved:

netfs: Fix netfsinvalidatefolio() to clear dirty bit if all changes gone

If a streaming write is made, this will leave the relevant modified folio in a not-uptodate, but dirty state with a netfsfolio struct hung off of folio->private indicating the dirty range. Subsequently truncating the file such that the dirty data in the folio is removed, but the first part of the folio theoretically remains will cause the netfsfolio struct to be discarded... but will leave the dirty flag set.

If the folio is then read via mmap(), netfsreadfolio() will see that the page is dirty and jump to netfsreadgaps() to fill in the missing bits. netfsreadgaps(), however, expects there to be a netfsfolio struct present and can oops because truncate removed it.

Fix this by calling foliocanceldirty() in netfsinvalidatefolio() in the event that all the dirty data in the folio is erased (as nfs does).

Also add some tracepoints to log modifications to a dirty page.

This can be reproduced with something like:

dd if=/dev/zero of=/xfstest.test/foo bs=1M count=1 umount /xfstest.test mount /xfstest.test xfsio -c "w 0xbbbf 0xf96c" \ -c "truncate 0xbbbf" \ -c "mmap -r 0xb000 0x11000" \ -c "mr 0xb000 0x11000" \ /xfstest.test/foo

with fscaching disabled (otherwise streaming writes are suppressed) and a change to netfsperformwrite() to disallow streaming writes if the fd is open ORDWR:

if (//(file->fmode & FMODEREAD) || <--- comment this out netfsiscacheenabled(ctx)) {

It should be reproducible even without this change, but if prevents the above trivial xfsio command from reproducing it.

Note that the initial dd is important: the file must start out sufficiently large that the zero-point logic doesn't just clear the gaps because it knows there's nothing in the file to read yet. Unmounting and mounting is needed to clear the pagecache (there are other ways to do that that may also work).

This was initially reproduced with the generic/522 xfstest on some patches that remove the FMODEREAD restriction.

In the Linux kernel, the following vulnerability has been resolved:

block: bio-integrity: Fix null-ptr-deref in biointegritymapuser()

pinuserpagesfast() can partially succeed and return the number of pages that were actually pinned. However, the biointegritymapuser() does not handle this partial pinning. This leads to a general protection fault since bvecfrompages() dereferences an unpinned page address, which is 0.

To fix this, add a check to verify that all requested memory is pinned. If partial pinning occurs, unpin the memory and return -EFAULT.

Kernel Oops:

Oops: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 0 UID: 0 PID: 1061 Comm: nvme-passthroug Not tainted 7.0.0-11783-g90957f9314e8-dirty #16 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 RIP: 0010:biointegritymapuser.cold+0x1b0/0x9d6

In the Linux kernel, the following vulnerability has been resolved:

PCI/PM: Drain runtime-idle callbacks before driver removal

A race condition between the .runtimeidle() callback and the .remove() callback in the rtsxpcr PCI driver leads to a kernel crash due to an unhandled page fault [1].

The problem is that rtsxpciruntimeidle() is not expected to be running after pmruntimegetsync() has been called, but the latter doesn't really guarantee that. It only guarantees that the suspend and resume callbacks will not be running when it returns.

However, if a .runtimeidle() callback is already running when pmruntimegetsync() is called, the latter will notice that the runtime PM status of the device is RPMACTIVE and it will return right away without waiting for the former to complete. In fact, it cannot wait for .runtimeidle() to complete because it may be called from that callback (it arguably does not make much sense to do that, but it is not strictly prohibited).

Thus in general, whoever is providing a .runtimeidle() callback needs to protect it from running in parallel with whatever code runs after pmruntimegetsync(). [Note that .runtimeidle() will not start after pmruntimegetsync() has returned, but it may continue running then if it has started earlier.]

One way to address that race condition is to call pmruntimebarrier() after pmruntimegetsync() (not before it, because a nonzero value of the runtime PM usage counter is necessary to prevent runtime PM callbacks from being invoked) to wait for the .runtimeidle() callback to complete should it be running at that point. A suitable place for doing that is in pcideviceremove() which calls pmruntimegetsync() before removing the driver, so it may as well call pmruntimebarrier() subsequently, which will prevent the race in question from occurring, not just in the rtsxpcr driver, but in any PCI drivers providing .runtimeidle() callbacks.

In the Linux kernel, the following vulnerability has been resolved:

ext4: fix corruption during on-line resize

The Linux kernel CVE team has assigned CVE-2024-35807 to this issue.

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051740-CVE-2024-35807-2a9e@gregkh/T

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:

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.