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

gpio: shared: fix deadlock on shared proxy's parent removal

Commit 710abda58055 ("gpio: shared: call gpiochip::ofxlate() if set") used the mutex embedded in struct gpiosharedentry to protect the offset field which now can be modified after assignment. The critical section however is too wide and introduced a potential deadlock on the removal of the shared GPIO proxy's parent.

Make the critical section shorter - only protect the offset when it's being read.

While at it: mention the fact that the entry lock is now also used to protect against concurrent access to the offset field in the structure's documentation.

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

srcu: Don't queue workqueue handlers to never-online CPUs

While an srcustruct structure is in the midst of switching from CPU-0 to all-CPUs state, it can attempt to invoke callbacks for CPUs that have never been online. Worse yet, it can attempt in invoke callbacks for CPUs that never will be online, even including imaginary CPUs not in cpupossiblemask. This can cause hangs on s390, which is not set up to deal with workqueue handlers being scheduled on such CPUs. This commit therefore causes Tree SRCU to refrain from queueing workqueue handlers on CPUs that have not yet (and might never) come online.

Because callbacks are not invoked on CPUs that have not been online, it is an error to invoke callsrcu(), synchronizesrcu(), or synchronizesrcuexpedited() on a CPU that is not yet fully online. However, it turns out to be less code to redirect the callbacks from too-early invocations of callsrcu() than to warn about such invocations. This commit therefore also redirects callbacks queued on not-yet-fully-online CPUs to the boot CPU.

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

btrfs: tracepoints: fix sleep while in atomic context in btrfssyncfile()

The trace event btrfssyncfile() is called in an atomic context (all trace events are) and its call to dput(), which is needed due to the call to dgetparent(), can sleep, triggering a kernel splat.

This can be reproduced by enabling the trace event and running btrfs/056 from fstests for example. The splat shown in dmesg is the following:

[53.919] BUG: sleeping function called from invalid context at fs/dcache.c:970 [53.947] inatomic(): 1, irqsdisabled(): 0, nonblock: 0, pid: 32773, name: xfsio [53.988] preemptcount: 2, expected: 0 [53.967] RCU nest depth: 0, expected: 0 [53.943] Preemption disabled at: [53.944] [<0000000000000000>] 0x0 [54.078] CPU: 0 UID: 0 PID: 32773 Comm: xfsio Tainted: G W 7.1.0-rc1-btrfs-next-232+ #1 PREEMPT(full) [54.070] Tainted: [W]=WARN [54.071] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 [54.072] Call Trace: [54.074] <TASK> [54.076] dumpstacklvl+0x56/0x80 [54.079] mightresched.cold+0xd6/0x10f [54.072] dput.part.0+0x24/0x110 [54.078] traceeventraweventbtrfssyncfile+0x75/0x140 [btrfs] [54.089] btrfssyncfile+0x1ed/0x530 [btrfs] [54.087] ? handlemmfault+0x8ae/0xed0 [54.089] btrfsdowriteiter+0x172/0x210 [btrfs] [54.091] vfswrite+0x21f/0x450 [54.094] x64syspwrite64+0x8d/0xc0 [54.096] ? douseraddrfault+0x20c/0x670 [54.099] dosyscall64+0x60/0xf20 [54.092] ? clearbhbloop+0x60/0xb0 [54.094] entrySYSCALL64afterhwframe+0x76/0x7e

So stop using dgetparent() and dput() and access the parent dentry directly as dentry->dparent. This is also what ext4 is doing in its equivalent trace event ext4syncfileenter().

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

cgroup: Defer css percpuref kill on rmdir until cgroup is depopulated

A chain of commits going back to v7.0 reworked rmdir to satisfy the controller invariant that a subsystem's ->cssoffline() must not run while tasks are still doing kernel-side work in the cgroup.

[1] d245698d727a ("cgroup: Defer task cgroup unlink until after the task is done switching out") [2] a72f73c4dd9b ("cgroup: Don't expose dead tasks in cgroup") [3] 1b164b876c36 ("cgroup: Wait for dying tasks to leave on rmdir") [4] 4c56a8ac6869 ("cgroup: Fix cgroupdraindying() testing the wrong condition") [5] 13e786b64bd3 ("cgroup: Increment nrdyingsubsys from rmdir context")

[1] moved task cset unlink from doexit() to finishtaskswitch() so a task's cset link drops only after the task has fully stopped scheduling. That made tasks past exitsignals() linger on cset->tasks until their final context switch, which led to a series of problems as what userspace expected to see after rmdir diverged from what the kernel needs to wait for. [2]-[5] tried to bridge that divergence: [2] filtered the exiting tasks from cgroup.procs; [3] had rmdir(2) sleep in TASKUNINTERRUPTIBLE for them; [4] fixed the wait's condition; [5] made nrdyingsubsys visible synchronously.

The cgroupdraindying() wait in [3] turned out to be a dead end. When the rmdir caller is also the reaper of a zombie that pins a pidns teardown (e.g. host PID 1 systemd reaping orphan pids that were re-parented to it during the same teardown), rmdir blocks in TASKUNINTERRUPTIBLE waiting for those pids to free, the pids can't free because PID 1 is the reaper and it's stuck in rmdir, and the system A-A deadlocks. No internal lock ordering breaks this; the wait itself is the bug.

The css killing side that drove the original reorder, however, can be made cleanly asynchronous: ->cssoffline() is already async, run from csskilledworkfn() driven by percpurefkillandconfirm(). The fix is to make that chain start only after all tasks have left the cgroup. rmdir's user-visible side then returns as soon as cgroup.procs and friends are empty, while ->cssoffline() still runs only after the cgroup is fully drained.

Verified by the original reproducer (pidns teardown + zombie reaper, runs under vng) which hangs vanilla and succeeds here, and by per-commit deterministic repros for [2], [3], [4], [5] with a boot parameter that widens the post-exitsignals() window so each state is reliably reachable. Some stress tests on top of that.

cgroupapplycontroldisable() has the same shape of pre-existing race: when a controller is disabled via subtreecontrol, killcss() ran synchronously while tasks past exitsignals() could still be linked to the cgroup's csets, and ->cssoffline() could fire before they drained. This patch preserves the existing synchronous behavior at that call site (killcsssync() + killcssfinish() back-to-back) and a follow-up patch will defer killcssfinish() there using a per-css trigger.

This seems like the right approach and I don't see problems with it. The changes are somewhat invasive but not excessively so, so backporting to -stable should be okay. If something does turn out to be wrong, the fallback is to revert the entire chain ([1]-[5]) and rework in the development branch instead.

v2: Pin cgrp across the deferred destroy work with explicit cgroupget()/cgroupput() around queuework() and the workfn. v1 wasn't actually broken (ordered cgroupofflinewq + queuework order in cgrouptaskdead() saved it) but the explicit ref removes the dependency on those non-obvious invariants. Also note the pre-existing cgroupapplycontroldisable() race in the description; a follow-up will defer killcssfinish() there.

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

openvswitch: vport: fix self-deadlock on release of tunnel ports

vports are used concurrently and protected by RCU, so netdevput() must happen after the RCU grace period. So, either in an RCU call or after the synchronizenet(). The rtnldeletelink() must happen under RTNL and so can't be executed in RCU context. Calling synchronizenet() while holding RTNL is not a good idea for performance and system stability under load in general, so calling netdevput() in RCU call is the right solution here.

However, when the device is deleted, rtnlunlock() will call netdevruntodo() and block until all the references are gone. In the current code this means that we never reach the callrcu() and the vport is never freed and the reference is never released, causing a self-deadlock on device removal.

Fix that by moving the rcucall() before the rtnlunlock(), so the scheduled RCU callback will be executed when synchronizenet() is called from the rtnlunlock()->netdevruntodo() while the RTNL itself is already released.

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

LoongArch: Fix potential ADE in loongsongpufixupdmahang()

The switch case in loongsongpufixupdmahang() may not DC2 or DC3, and readl(crtcreg) will access with random address, because the "device" is from "base+PCIDEVICEID", "base" is from "pdev->devfn+1". This is wrong when my platform inserts a discrete GPU:

lspci -tv -[0000:00]-+-00.0 Loongson Technology LLC Hyper Transport Bridge Controller ... +-06.0 Loongson Technology LLC LG100 GPU +-06.2 Loongson Technology LLC Device 7a37 ...

Add a default switch case to fix the panic as below:

Kernel ade access[#1]: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.6.136-loong64-desktop-hwe+ #4 pc 90000000017e5534 ra 90000000017e54c0 tp 90000001002f8000 sp 90000001002fb6c0 a0 80000efe00003100 a1 0000000000003100 a2 0000000000000000 a3 0000000000000002 a4 90000001002fb6b4 a5 900000087cdb58fd a6 90000000027af000 a7 0000000000000001 t0 00000000000085b9 t1 000000000000ffff t2 0000000000000000 t3 0000000000000000 t4 fffffffffffffffd t5 00000000fffb6d9c t6 0000000000083b00 t7 00000000000070c0 t8 900000087cdb4d94 u0 900000087cdb58fd s9 90000001002fb826 s0 90000000031c12c8 s1 7fffffffffffff00 s2 90000000031c12d0 s3 0000000000002710 s4 0000000000000000 s5 0000000000000000 s6 9000000100053000 s7 7fffffffffffff00 s8 90000000030d4000 ra: 90000000017e54c0 loongsongpufixupdmahang+0x40/0x210 ERA: 90000000017e5534 loongsongpufixupdmahang+0xb4/0x210 CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) PRMD: 00000004 (PPLV0 +PIE -PWE) EUEN: 00000000 (-FPE -SXE -ASXE -BTE) ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7) ESTAT: 00480000 [ADEM] (IS= ECode=8 EsubCode=1) BADV: 7fffffffffffff00 PRID: 0014d000 (Loongson-64bit, Loongson-3A6000-HV) Modules linked in: Process swapper/0 (pid: 1, threadinfo=(ptrval), task=(ptrval)) Stack : 0000000000000006 90000001002fb778 90000001002fb704 0000000000000007 0000000016a65700 90000000017e5690 000000000000ffff ffffffffffffffff 900000000209f7c0 9000000100053000 900000000209f7a8 9000000000eebc08 0000000000000000 0000000000000000 0000000000000006 90000001002fb778 90000001000530b8 90000000027af000 0000000000000000 9000000100054000 9000000100053000 9000000000ebb70c 9000000100004c00 9000000004000001 90000001002fb7e4 bae765461f31cb12 0000000000000000 0000000000000000 0000000000000006 90000000027af000 0000000000000030 90000000027af000 900000087cd6f800 9000000100053000 0000000000000000 9000000000ebc560 7a2500147cdaf720 bae765461f31cb12 0000000000000001 0000000000000030 ... Call Trace: [<90000000017e5534>] loongsongpufixupdmahang+0xb4/0x210 [<9000000000eebc08>] pcifixupdevice+0x108/0x280 [<9000000000ebb70c>] pcisetupdevice+0x24c/0x690 [<9000000000ebc560>] pciscansingledevice+0xe0/0x140 [<9000000000ebc684>] pciscanslot+0xc4/0x280 [<9000000000ebdd00>] pciscanchildbusextend+0x60/0x3f0 [<9000000000f5bc94>] acpipcirootcreate+0x2b4/0x420 [<90000000017e5e74>] pciacpiscanroot+0x2d4/0x440 [<9000000000f5b02c>] acpipcirootadd+0x21c/0x3a0 [<9000000000f4ee54>] acpibusattach+0x1a4/0x3c0 [<90000000010e200c>] deviceforeachchild+0x6c/0xe0 [<9000000000f4bbf4>] acpidevforeachchild+0x44/0x70 [<9000000000f4ef40>] acpibusattach+0x290/0x3c0 [<90000000010e200c>] deviceforeachchild+0x6c/0xe0 [<9000000000f4bbf4>] acpidevforeachchild+0x44/0x70 [<9000000000f4ef40>] acpibusattach+0x290/0x3c0 [<9000000000f5211c>] acpibusscan+0x6c/0x280 [<900000000189c028>] acpiscaninit+0x194/0x310 [<900000000189bc6c>] acpiinit+0xcc/0x140 [<9000000000220cdc>] dooneinitcall+0x4c/0x310 [<90000000018618fc>] kernelinitfreeable+0x258/0x2d4 [<900000000184326c>] kernelinit+0x28/0x13c [<9000000000222008>] retfromkernelthread+0xc/0xa4

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

usb: ulpi: fix memory leak on ulpiregister() error paths

Commit 01af542392b5 ("usb: ulpi: fix double free in ulpiregisterinterface() error path") removed kfree(ulpi) from ulpiregisterinterface() to fix a double-free when deviceregister() fails.

But when ulpiofregister() or ulpireadid() fail before deviceregister() is called, the ulpi allocation is leaked.

Add kfree(ulpi) on both error paths to properly clean up the allocation.

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

usb: yurex: fix race in probe

The bbu member of the descriptor must be set to the value standing for uninitialized values before the URB whose completion handler sets bbu is submitted. Otherwise there is a window during which probing can overwrite already retrieved data.

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

ice: ptp: don't WARN when controlling PF is unavailable

In VFIO passthrough setups, it is possible to pass through only a PF which doesn't own the source timer. In that case the PTP controlling PF (adapter->ctrlpf) is never initialized in the VM, so icegetctrlptp() returns NULL and triggers WARNON() in iceptpsetuppf().

Since this is an expected behavior in that configuration, replace WARNON() with an informational message and return -EOPNOTSUPP.

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

perf/x86/intel/uncore: Fix die ID init and look up bugs

In snbeppci2phymapinit(), in the nrnodeids > 8 path, uncoredevicetodie() may return -1 when all CPUs associated with the UBOX device are offline.

Remove the WARNONONCE(dieid == -1) check for two reasons:

- The current code breaks out of the loop. This is incorrect because pcigetdevice() does not guarantee iteration in domain or bus order, so additional UBOX devices may be skipped during the scan.

- Returning -EINVAL is incorrect, since marking offline buses with dieid == -1 is expected and should not be treated as an error.

Separately, when NUMA is disabled on a NUMA-capable platform, pcibustonode() returns NUMANONODE, causing uncoredevicetodie() to return -1 for all PCI devices. As a result, sprupdatedevicelocation(), used on Intel SPR and EMR, ignores the corresponding PMON units and does not add them to the RB tree.

Fix this by using uncorepcibustodieid(), which retrieves topology from the UBOX GIDNIDMAP register and works regardless of whether NUMA is enabled in Linux. This requires snbeppci2phymapinit() to be added in spruncorepciinit().

Keep uncoredevicetodie() only for the nrnodeids > 8 case, where NUMA is expected to be enabled.

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

comedi: Reinit dev->spinlock between attachments to low-level drivers

struct comedidevice is the main controlling structure for a COMEDI device created by the COMEDI subsystem. It contains a member spinlock containing a spin-lock that is initialized by the COMEDI subsystem, but is reserved for use by a low-level driver attached to the COMEDI device (at least since commit 25436dc9d84f ("Staging: comedi: remove RT code")).

Some COMEDI devices (those created on initialization of the COMEDI subsystem when the "comedi.comedinumlegacyminors" parameter is non-zero) can be attached to different low-level drivers over their lifetime using the COMEDIDEVCONFIG ioctl command. This can result in inconsistent lock states being reported when there is a mismatch in the spin-lock locking levels used by each low-level driver to which the COMEDI device has been attached. Fix it by reinitializing dev->spinlock before calling the low-level driver's attach function pointer if CONFIGLOCKDEP is enabled.

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

USB: dummy-hcd: Fix locking/synchronization error

Syzbot testing was able to provoke an addressing exception and crash in the usbgadgetudcreset() routine in drivers/usb/gadgets/udc/core.c, resulting from the fact that the routine was called with a second ("driver") argument of NULL. The bad caller was setlinkstate() in dummyhcd.c, and the problem arose because of a race between a USB reset and driver unbind.

These sorts of races were not supposed to be possible; commit 7dbd8f4cabd9 ("USB: dummy-hcd: Fix erroneous synchronization change"), along with a few followup commits, was written specifically to prevent them. As it turns out, there are (at least) two errors remaining in the code. Another patch will address the second error; this one is concerned with the first.

The error responsible for the syzbot crash occurred because the stopactivity() routine will sometimes drop and then re-acquire the dum->lock spinlock. A call to stopactivity() occurs in setlinkstate() when handling an emulated USB reset, after the test of dum->intsenabled and before the increment of dum->callbackusage. This allowed another thread (doing a driver unbind) to sneak in and grab the spinlock, and then clear dum->intsenabled and dum->driver. Normally this other thread would have to wait for dum->callbackusage to go down to 0 before it would clear dum->driver, but in this case it didn't have to wait since dum->callbackusage had not yet been incremented.

The fix is to increment dum->callbackusage before calling stopactivity() instead of after. Then the thread doing the unbind will not clear dum->driver until after the call to usbgadgetudcreset() safely returns and dum->callbackusage has been decremented again.

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

schedext: Fix SCXKICKWAIT deadlock by deferring wait to balance callback

SCXKICKWAIT busy-waits in kickcpusirqworkfn() using smpcondloadacquire() until the target CPU's kicksync advances. Because the irqwork runs in hardirq context, the waiting CPU cannot reschedule and its own kicksync never advances. If multiple CPUs form a wait cycle, all CPUs deadlock.

Replace the busy-wait in kickcpusirqworkfn() with reschedcurr() to force the CPU through dopicktaskscx(), which queues a balance callback to perform the wait. The balance callback drops the rq lock and enables IRQs following the schedcorebalance() pattern, so the CPU can process IPIs while waiting. The local CPU's kicksync is advanced on entry to dopicktaskscx() and continuously during the wait, ensuring any CPU that starts waiting for us sees the advancement and cannot form cyclic dependencies.

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

wifi: iwlwifi: mvm: don't send a 6E related command when not supported

MCCALLOWEDAPTYPECMD is related to 6E support. Do not send it if the device doesn't support 6E. Apparently, the firmware is mistakenly advertising support for this command even on AX201 which does not support 6E and then the firmware crashes.

drm/amd/display: Fix dsc eDP issue

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

spi: spidev: fix lock inversion between spilock and buflock

The spidev driver previously used two mutexes, spilock and buflock, but acquired them in different orders depending on the code path:

write()/read(): buflock -> spilock ioctl(): spilock -> buflock

This AB-BA locking pattern triggers lockdep warnings and can cause real deadlocks:

WARNING: possible circular locking dependency detected spidevioctl() -> mutexlock(&spidev->buflock) spidevsyncwrite() -> mutexlock(&spidev->spilock) DEADLOCK

The issue is reproducible with a simple userspace program that performs write() and SPIIOCWRMAXSPEEDHZ ioctl() calls from separate threads on the same spidev file descriptor.

Fix this by simplifying the locking model and removing the lock inversion entirely. spidevsync() no longer performs any locking, and all callers serialize access using spilock.

buflock is removed since its functionality is fully covered by spilock, eliminating the possibility of lock ordering issues.

This removes the lock inversion and prevents deadlocks without changing userspace ABI or behaviour.

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

drm/amdgpu: fix sync handling in amdgpudmabufmovenotify

Invalidating a dmabuf will impact other users of the shared BO. In the scenario where process A moves the BO, it needs to inform process B about the move and process B will need to update its page table.

The commit fixes a synchronisation bug caused by the use of the ticket: it made amdgpuvmhandlemoved behave as if updating the page table immediately was correct but in this case it's not.

An example is the following scenario, with 2 GPUs and glxgears running on GPU0 and Xorg running on GPU1, on a system where P2P PCI isn't supported:

glxgears: export linear buffer from GPU0 and import using GPU1 submit frame rendering to GPU0 submit tiled->linear blit Xorg: copy of linear buffer

The sequence of jobs would be: drmschedjobrun # GPU0, frame rendering drmschedjobqueue # GPU0, blit drmschedjobdone # GPU0, frame rendering drmschedjobrun # GPU0, blit move linear buffer for GPU1 access # amdgpudmabufmovenotify -> update pt # GPU0

It this point the blit job on GPU0 is still running and would likely produce a page fault.

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

most: core: fix leak on early registration failure

A recent commit fixed a resource leak on early registration failures but for some reason left out the first error path which still leaks the resources associated with the interface.

Fix up also the first error path so that the interface is always released on errors.

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

media: solo6x10: Check for out of bounds chipid

Clang with CONFIGUBSANSHIFT=y noticed a condition where a signed type (literal "1" is an "int") could end up being shifted beyond 32 bits, so instrumentation was added (and due to the double istw286x() call seen via inlining), Clang decides the second one must now be undefined behavior and elides the rest of the function[1]. This is a known problem with Clang (that is still being worked on), but we can avoid the entire problem by actually checking the existing max chip ID, and now there is no runtime instrumentation added at all since everything is known to be within bounds.

Additionally use an unsigned value for the shift to remove the instrumentation even without the explicit bounds checking.

[hverkuil: fix checkpatch warning for istw286x]

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

kexec: derive purgatory entry from symbol

kexecloadpurgatory() derives image->start by locating eentry inside an SHFEXECINSTR section. If the purgatory object contains multiple executable sections with overlapping shaddr, the entrypoint check can match more than once and trigger a WARN.

Derive the entry section from the purgatorystart symbol when present and compute image->start from its final placement. Keep the existing eentry fallback for purgatories that do not expose the symbol.

WARNING: kernel/kexecfile.c:1009 at kexecloadpurgatory+0x395/0x3c0, CPU#10: kexec/1784 Call Trace: <TASK> bzImage64load+0x133/0xa00 dosyskexecfileload+0x2b3/0x5c0 dosyscall64+0x81/0x610 entrySYSCALL64afterhwframe+0x76/0x7e

[me@linux.beauty: move helper to avoid forward declaration, per Baoquan]

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

ext4: move ext4percpuparaminit() before ext4mbinit()

When running kvm-xfstests -c ext4/1k -C 1 generic/383 with the DOUBLECHECK macro defined, the following panic is triggered:

================================================================== EXT4-fs error (device vdc): ext4validateblockbitmap:423: comm mount: bg 0: bad block bitmap checksum BUG: unable to handle page fault for address: ff110000fa2cc000 PGD 3e01067 P4D 3e02067 PUD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 2386 Comm: mount Tainted: G W 6.18.0-gba65a4e7120a-dirty #1152 PREEMPT(none) RIP: 0010:percpucounteraddbatch+0x13/0xa0 Call Trace: <TASK> ext4markgroupbitmapcorrupted+0xcb/0xe0 ext4validateblockbitmap+0x2a1/0x2f0 ext4readblockbitmap+0x33/0x50 mbgroupbbbitmapalloc+0x33/0x80 ext4mbaddgroupinfo+0x190/0x250 ext4mbinitbackend+0x87/0x290 ext4mbinit+0x456/0x640 ext4fillsuper+0x1072/0x1680 ext4fillsuper+0xd3/0x280 gettreebdevflags+0x132/0x1d0 vfsgettree+0x29/0xd0 vfscmdcreate+0x59/0xe0 dosysfsconfig+0x4f6/0x6b0 dosyscall64+0x50/0x1f0 entrySYSCALL64afterhwframe+0x76/0x7e ==================================================================

This issue can be reproduced using the following commands: mkfs.ext4 -F -q -b 1024 /dev/sda 5G tune2fs -O quota,project /dev/sda mount /dev/sda /tmp/test

With DOUBLECHECK defined, mbgroupbbbitmapalloc() reads and validates the block bitmap. When the validation fails, ext4markgroupbitmapcorrupted() attempts to update sbi->sfreeclusterscounter. However, this percpucounter has not been initialized yet at this point, which leads to the panic described above.

Fix this by moving the execution of ext4percpuparaminit() to occur before ext4mbinit(), ensuring the per-CPU counters are initialized before they are used.

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

drm: Account property blob allocations to memcg

DRMIOCTLMODECREATEPROPBLOB allows userspace to allocate arbitrary-sized property blobs backed by kernel memory.

Currently, the blob data allocation is not accounted to the allocating process's memory cgroup, allowing unprivileged users to trigger unbounded kernel memory consumption and potentially cause system-wide OOM.

Mark the property blob data allocation with GFPKERNELACCOUNT so that the memory is properly charged to the caller's memcg. This ensures existing cgroup memory limits apply and prevents uncontrolled kernel memory growth without introducing additional policy or per-file limits.

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

mm/hugetlb: restore failed global reservations to subpool

Commit a833a693a490 ("mm: hugetlb: fix incorrect fallback for subpool") fixed an underflow error for hstate->resvhugepages caused by incorrectly attributing globally requested pages to the subpool's reservation.

Unfortunately, this fix also introduced the opposite problem, which would leave spool->usedhpages elevated if the globally requested pages could not be acquired. This is because while a subpool's reserve pages only accounts for what is requested and allocated from the subpool, its "used" counter keeps track of what is consumed in total, both from the subpool and globally. Thus, we need to adjust spool->usedhpages in the other direction, and make sure that globally requested pages are uncharged from the subpool's used counter.

Each failed allocation attempt increments the usedhpages counter by how many pages were requested from the global pool. Ultimately, this renders the subpool unusable, as usedhpages approaches the max limit.

The issue can be reproduced as follows: 1. Allocate 4 hugetlb pages 2. Create a hugetlb mount with max=4, min=2 3. Consume 2 pages globally 4. Request 3 pages from the subpool (2 from subpool + 1 from global) 4.1 hugepagesubpoolgetpages(spool, 3) succeeds. usedhpages += 3 4.2 hugetlbacctmemory(h, 1) fails: no global pages left usedhpages -= 2 5. Subpool now has usedhpages = 1, despite not being able to successfully allocate any hugepages. It believes it can now only allocate 3 more hugepages, not 4.

With each failed allocation attempt incrementing the used counter, the subpool eventually reaches a point where its used counter equals its max counter. At that point, any future allocations that try to allocate hugeTLB pages from the subpool will fail, despite the subpool not having any of its hugeTLB pages consumed by any user.

Once this happens, there is no way to make the subpool usable again, since there is no way to decrement the used counter as no process is really consuming the hugeTLB pages.

The underflow issue that the original commit fixes still remains fixed as well.

Without this fix, usedhpages would keep on leaking if hugetlbacctmemory() fails.

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

mm/slab: do not access current->memsallowedseq if !allowspin

Lockdep complains when getfromanypartial() is called in an NMI context, because current->memsallowedseq is seqcountspinlockt and not NMI-safe:

================================ WARNING: inconsistent lock state 6.19.0-rc5-kfree-rcu+ #315 Tainted: G N -------------------------------- inconsistent {INITIAL USE} -> {IN-NMI} usage. kunittrycatch/9989 [HC1[1]:SC0[0]:HE0:SE1] takes: ffff889085799820 (&s->seqcount#3){.-.-}-{0:0}, at: slaballoc+0x58f/0xc00 {INITIAL USE} state was registered at: lockacquire+0x185/0x320 kernelinitfreeable+0x391/0x1150 kernelinit+0x1f/0x220 retfromfork+0x736/0x8f0 retfromforkasm+0x1a/0x30 irq event stamp: 56 hardirqs last enabled at (55): [<ffffffff850a68d7>] rawspinunlockirq+0x27/0x70 hardirqs last disabled at (56): [<ffffffff850858ca>] schedule+0x2a8a/0x6630 softirqs last enabled at (0): [<ffffffff81536711>] copyprocess+0x1dc1/0x6a10 softirqs last disabled at (0): [<0000000000000000>] 0x0

other info that might help us debug this: Possible unsafe locking scenario:

CPU0 ---- lock(&s->seqcount#3); <Interrupt> lock(&s->seqcount#3);

DEADLOCK

According to Documentation/locking/seqlock.rst, seqcountt is not NMI-safe and seqcountlatcht should be used when read path can interrupt the write-side critical section. In this case, do not access current->memsallowedseq and avoid retry.

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

x86: shadow stacks: proper error handling for mmap lock

김영민 reports that shstkpopsigframe() doesn't check for errors from mmapreadlockkillable(), which is a silly oversight, and also shows that we haven't marked those functions with "mustcheck", which would have immediately caught it.

So let's fix both issues.

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

soc: qcom: pd-mapper: Fix element length in servreglocpfrreqei

It looks element length declared in servreglocpfrreqei for reason not matching servreglocpfrreq's reason field due which we could observe decoding error on PD crash.

qmidecodestringelem: String len 81 >= Max Len 65

Fix this by matching with servreglocpfrreq's reason field.

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

xfrm: account XFRMAIFID in aevent size calculation

xfrmgetae() allocates the reply skb with xfrmaeventmsgsize(), then buildaevent() appends attributes including XFRMAIFID when x->ifid is set.

xfrmaeventmsgsize() does not include space for XFRMAIFID. For states with ifid, buildaevent() can fail with -EMSGSIZE and hit BUGON(err < 0) in xfrmgetae(), turning a malformed netlink interaction into a kernel panic.

Account XFRMAIFID in the size calculation unconditionally and replace the BUGON with normal error unwinding.

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

drm/vc4: Fix memory leak of BO array in hang state

The hang state's BO array is allocated separately with kzalloc() in vc4savehangstate() but never freed in vc4freehangstate(). Add the missing kfree() for the BO array before freeing the hang state struct.

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

drm/vc4: Fix a memory leak in hang state error path

When vc4savehangstate() encounters an early return condition, it returns without freeing the previously allocated kernelstate, leaking memory.

Add the missing kfree() calls by consolidating the early return paths into a single place.

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

net: lapbether: handle NETDEVPRETYPECHANGE

lapbethdatatransmit() expects the underlying device type to be ARPHRDETHER.

Returning NOTIFYBAD from lapbethdeviceevent() makes sure bonding driver can not break this expectation.