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

usb: xhci: Fix memory leak in xhcidisableslot()

xhcialloccommand() allocates a command structure and, when the second argument is true, also allocates a completion structure. Currently, the error handling path in xhcidisableslot() only frees the command structure using kfree(), causing the completion structure to leak.

Use xhcifreecommand() instead of kfree(). xhcifreecommand() correctly frees both the command structure and the associated completion structure. Since the command structure is allocated with zero-initialization, command->inctx is NULL and will not be erroneously freed by xhcifreecommand().

This bug was found using an experimental static analysis tool we are developing. The tool is based on the LLVM framework and is specifically designed to detect memory management issues. It is currently under active development and not yet publicly available, but we plan to open-source it after our research is published.

The bug was originally detected on v6.13-rc1 using our static analysis tool, and we have verified that the issue persists in the latest mainline kernel.

We performed build testing on x8664 with allyesconfig using GCC=11.4.0. Since triggering these error paths in xhcidisableslot() requires specific hardware conditions or abnormal state, we were unable to construct a test case to reliably trigger these specific error paths at runtime.

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

xhci: Fix NULL pointer dereference when reading portli debugfs files

Michal reported and debgged a NULL pointer dereference bug in the recently added portli debugfs files

Oops is caused when there are more port registers counted in xhci->maxports than ports reported by Supported Protocol capabilities. This is possible if maxports is more than maximum port number, or if there are gaps between ports of different speeds the 'Supported Protocol' capabilities.

In such cases port->rhub will be NULL so we can't reach xhci behind it. Add an explicit NULL check for this case, and print portli in hex without dereferencing port->rhub.

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:

USB: core: Limit the length of unkillable synchronous timeouts

The usbcontrolmsg(), usbbulkmsg(), and usbinterruptmsg() APIs in usbcore allow unlimited timeout durations. And since they use uninterruptible waits, this leaves open the possibility of hanging a task for an indefinitely long time, with no way to kill it short of unplugging the target device.

To prevent this sort of problem, enforce a maximum limit on the length of these unkillable timeouts. The limit chosen here, somewhat arbitrarily, is 60 seconds. On many systems (although not all) this is short enough to avoid triggering the kernel's hung-task detector.

In addition, clear up the ambiguity of negative timeout values by treating them the same as 0, i.e., using the maximum allowed timeout.

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

USB: usbtmc: Use usbbulkmsgkillable() with user-specified timeouts

The usbtmc driver accepts timeout values specified by the user in an ioctl command, and uses these timeouts for some usbbulkmsg() calls. Since the user can specify arbitrarily long timeouts and usbbulkmsg() uses unkillable waits, call usbbulkmsgkillable() instead to avoid the possibility of the user hanging a kernel thread indefinitely.

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

usb: image: mdc800: kill download URB on timeout

mdc800deviceread() submits downloadurb and waits for completion. If the timeout fires and the device has not responded, the function returns without killing the URB, leaving it active.

A subsequent read() resubmits the same URB while it is still in-flight, triggering the WARN in usbsubmiturb():

"URB submitted while active"

Check the return value of waiteventtimeout() and kill the URB if it indicates timeout, ensuring the URB is complete before its status is inspected or the URB is resubmitted.

Similar to - commit 372c93131998 ("USB: yurex: fix control-URB timeout handling") - commit b98d5000c505 ("media: rc: iguanair: handle timeouts")

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

usb: gadget: ftcm: Fix NULL pointer dereferences in nexus handling

The tpg->tpgnexus pointer in the USB Target driver is dynamically managed and tied to userspace configuration via ConfigFS. It can be NULL if the USB host sends requests before the nexus is fully established or immediately after it is dropped.

Currently, functions like botsubmitcommand() and the data transfer paths retrieve tvnexus = tpg->tpgnexus and immediately dereference tvnexus->tvnsesess without any validation. If a malicious or misconfigured USB host sends a BOT (Bulk-Only Transport) command during this race window, it triggers a NULL pointer dereference, leading to a kernel panic (local DoS).

This exposes an inconsistent API usage within the module, as peer functions like usbgsubmitcommand() and botsendbadresponse() correctly implement a NULL check for tvnexus before proceeding.

Fix this by bringing consistency to the nexus handling. Add the missing if (!tvnexus) checks to the vulnerable BOT command and request processing paths, aborting the command gracefully with an error instead of crashing the system.

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:

usb: gadget: fsubset: Fix unbalanced refcnt in gethfree

gethalloc() increments the reference count, but gethfree() fails to decrement it. This prevents the configuration of attributes via configfs after unlinking the function.

Decrement the reference count in gethfree() to ensure proper cleanup.

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

usb: gadget: frndis: Protect RNDIS options with mutex

The class/subclass/protocol options are suspectible to race conditions as they can be accessed concurrently through configfs.

Use existing mutex to protect these options. This issue was identified during code inspection.

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:

btrfs: reserve enough transaction items for qgroup ioctls

Currently our qgroup ioctls don't reserve any space, they just do a transaction join, which does not reserve any space, neither for the quota tree updates nor for the delayed refs generated when updating the quota tree. The quota root uses the global block reserve, which is fine most of the time since we don't expect a lot of updates to the quota root, or to be too close to -ENOSPC such that other critical metadata updates need to resort to the global reserve.

However this is not optimal, as not reserving proper space may result in a transaction abort due to not reserving space for delayed refs and then abusing the use of the global block reserve.

For example, the following reproducer (which is unlikely to model any real world use case, but just to illustrate the problem), triggers such a transaction abort due to -ENOSPC when running delayed refs:

$ cat test.sh #!/bin/bash

DEV=/dev/nullb0 MNT=/mnt/nullb0

umount $DEV &> /dev/null # Limit device to 1G so that it's much faster to reproduce the issue. mkfs.btrfs -f -b 1G $DEV mount -o commit=600 $DEV $MNT

fallocate -l 800M $MNT/filler btrfs quota enable $MNT

for ((i = 1; i <= 400000; i++)); do btrfs qgroup create 1/$i $MNT done

umount $MNT

When running this, we can see in dmesg/syslog that a transaction abort happened:

[436.490] BTRFS error (device nullb0): failed to run delayed ref for logical 30408704 numbytes 16384 type 176 action 1 refmod 1: -28 [436.493] ------------[ cut here ]------------ [436.494] BTRFS: Transaction aborted (error -28) [436.495] WARNING: fs/btrfs/extent-tree.c:2247 at btrfsrundelayedrefs+0xd9/0x110 [btrfs], CPU#4: umount/2495372 [436.497] Modules linked in: btrfs loop (...) [436.508] CPU: 4 UID: 0 PID: 2495372 Comm: umount Tainted: G W 6.19.0-rc8-btrfs-next-225+ #1 PREEMPT(full) [436.510] Tainted: [W]=WARN [436.511] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 [436.513] RIP: 0010:btrfsrundelayedrefs+0xdf/0x110 [btrfs] [436.514] Code: 0f 82 ea (...) [436.518] RSP: 0018:ffffd511850b7d78 EFLAGS: 00010292 [436.519] RAX: 00000000ffffffe4 RBX: ffff8f120dad37e0 RCX: 0000000002040001 [436.520] RDX: 0000000000000002 RSI: 00000000ffffffe4 RDI: ffffffffc090fd80 [436.522] RBP: 0000000000000000 R08: 0000000000000001 R09: ffffffffc04d1867 [436.523] R10: ffff8f18dc1fffa8 R11: 0000000000000003 R12: ffff8f173aa89400 [436.524] R13: 0000000000000000 R14: ffff8f173aa89400 R15: 0000000000000000 [436.526] FS: 00007fe59045d840(0000) GS:ffff8f192e22e000(0000) knlGS:0000000000000000 [436.527] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [436.528] CR2: 00007fe5905ff2b0 CR3: 000000060710a002 CR4: 0000000000370ef0 [436.530] Call Trace: [436.530] <TASK> [436.530] btrfscommittransaction+0x73/0xc00 [btrfs] [436.531] ? btrfsattachtransactionbarrier+0x1e/0x70 [btrfs] [436.532] syncfilesystem+0x7a/0x90 [436.533] genericshutdownsuper+0x28/0x180 [436.533] killanonsuper+0x12/0x40 [436.534] btrfskillsuper+0x12/0x20 [btrfs] [436.534] deactivatelockedsuper+0x2f/0xb0 [436.534] cleanupmnt+0xea/0x180 [436.535] taskworkrun+0x58/0xa0 [436.535] exittousermodeloop+0xed/0x480 [436.536] ? x64sysumount+0x68/0x80 [436.536] dosyscall64+0x2a5/0xf20 [436.537] entrySYSCALL64afterhwframe+0x76/0x7e [436.537] RIP: 0033:0x7fe5906b6217 [436.538] Code: 0d 00 f7 (...) [436.540] RSP: 002b:00007ffcd87a61f8 EFLAGS: 00000246 ORIGRAX: 00000000000000a6 [436.541] RAX: 0000000000000000 RBX: 00005618b9ecadc8 RCX: 00007fe5906b6217 [436.541] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00005618b9ecb100 [436.542] RBP: 0000000000000000 R08: 00007ffcd87a4fe0 R09: 00000000ffffffff [436.544] R10: 0000000000000103 R11: ---truncated---

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

drm/amd/display: Fix NULL pointer dereference in dcn401inithw()

dcn401inithw() assumes that updatebwboundingbox() is valid when entering the update path. However, the existing condition:

((!fams2enable && updatebwboundingbox) || freqchanged)

does not guarantee this, as the freqchanged branch can evaluate to true independently of the callback pointer.

This can result in calling updatebwboundingbox() when it is NULL.

Fix this by separating the update condition from the pointer checks and ensuring the callback, dc->clkmgr, and bwparams are validated before use.

Fixes the below: ../dc/hwss/dcn401/dcn401hwseq.c:367 dcn401inithw() error: we previously assumed 'dc->respool->funcs->updatebwboundingbox' could be null (see line 362)

(cherry picked from commit 86117c5ab42f21562fedb0a64bffea3ee5fcd477)

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

interconnect: qcom: sm8450: Fix NULL pointer dereference in icclinknodes()

The change to dynamic IDs for SM8450 platform interconnects left two links unconverted, fix it to avoid the NULL pointer dereference in runtime, when a pointer to a destination interconnect is not valid:

Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 <...> Call trace: icclinknodes+0x3c/0x100 (P) qcomiccrpmhprobe+0x1b4/0x528 platformprobe+0x64/0xc0 reallyprobe+0xc4/0x2a8 driverprobedevice+0x80/0x140 driverprobedevice+0x48/0x170 deviceattachdriver+0xc0/0x148 busforeachdrv+0x88/0xf0 deviceattach+0xb0/0x1c0 deviceinitialprobe+0x58/0x68 busprobedevice+0x40/0xb8 deferredprobeworkfunc+0x90/0xd0 processonework+0x15c/0x3c0 workerthread+0x2e8/0x400 kthread+0x150/0x208 retfromfork+0x10/0x20 Code: 900310f4 911d6294 91008280 94176078 (f94002a0) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Oops: Fatal exception

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

bpf: reject direct access to nullable PTRTOBUF pointers

checkmemaccess() matches PTRTOBUF via basetype() which strips PTRMAYBENULL, allowing direct dereference without a null check.

Map iterator ctx->key and ctx->value are PTRTOBUF | PTRMAYBENULL. On stop callbacks these are NULL, causing a kernel NULL dereference.

Add a typemaybenull() guard to the PTRTOBUF branch, matching the existing PTRTOBTFID pattern.

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

x86/kexec: Disable KCOV instrumentation after loadsegments()

The loadsegments() function changes segment registers, invalidating GS base (which KCOV relies on for per-cpu data). When CONFIGKCOV is enabled, any subsequent instrumented C code call (e.g. nativegdtinvalidate()) begins crashing the kernel in an endless loop.

To reproduce the problem, it's sufficient to do kexec on a KCOV-instrumented kernel:

$ kexec -l /boot/otherKernel $ kexec -e

The real-world context for this problem is enabling crash dump collection in syzkaller. For this, the tool loads a panic kernel before fuzzing and then calls makedumpfile after the panic. This workflow requires both CONFIGKEXEC and CONFIGKCOV to be enabled simultaneously.

Adding safeguards directly to the KCOV fast-path (sanitizercovtracepc()) is also undesirable as it would introduce an extra performance overhead.

Disabling instrumentation for the individual functions would be too fragile, so disable KCOV instrumentation for the entire machinekexec64.c and physaddr.c. If coverage-guided fuzzing ever needs these components in the future, other approaches should be considered.

The problem is not relevant for 32 bit kernels as CONFIGKCOV is not supported there.

[ bp: Space out comment for better readability. ]

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.