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

ASoC: qcom: qdsp6: Fix q6apm remove ordering during ADSP stop and start

During ADSP stop and start, the kernel crashes due to the order in which ASoC components are removed.

On ADSP stop, the q6apm-audio .remove callback unloads topology and removes PCM runtimes during ASoC teardown. This deletes the RTDs that contain the q6apm DAI components before their removal pass runs, leaving those components still linked to the card and causing crashes on the next rebind.

Fix this by ensuring that all dependent (child) components are removed first, and the q6apm component is removed last.

[ 48.105720] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000d0 [ 48.114763] Mem abort info: [ 48.117650] ESR = 0x0000000096000004 [ 48.121526] EC = 0x25: DABT (current EL), IL = 32 bits [ 48.127010] SET = 0, FnV = 0 [ 48.130172] EA = 0, S1PTW = 0 [ 48.133415] FSC = 0x04: level 0 translation fault [ 48.138446] Data abort info: [ 48.141422] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 48.147079] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 48.152354] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 48.157859] user pgtable: 4k pages, 48-bit VAs, pgdp=00000001173cf000 [ 48.164517] [00000000000000d0] pgd=0000000000000000, p4d=0000000000000000 [ 48.171530] Internal error: Oops: 0000000096000004 [#1] SMP [ 48.177348] Modules linked in: q6prmclocks q6apmlpassdais q6apmdai sndq6dspcommon q6prm sndq6apm 8021q garp mrp stp llc sndsochdmicodec apr pdrinterface phyqcomedp fastrpc qcompdmapper rpmsgctrl qrtrsmd rpmsgchar qcompdrmsg qcomiris v4l2mem2mem videobuf2dmacontig ath11kpci msm ubwcconfig at24 ath11k videobuf2memops mac80211 ocmem videobuf2v4l2 libarc4 drmgpuvm mhi qrtr videodev drmexec sndsocsc8280xp gpusched videobuf2common nvmemqcomspmisdam sndsocqcomsdw drmdpauxbus qcomq6v5pas qcomspmitempalarm sndsocqcomcommon rtcpm8xxx qcompon drmdisplayhelper cec qcompilinfo qcomstats soundwirebus drmclientlib mc dispcc0sa8775p videoccsa8775p qcomq6v5 camccsa8775p sndsocdmic phyqcomsgmiieth sndsocmax98357a i2cqcomgeni sndsoccore dwmacqcomethqos llccqcom iccbwmon qcomsysmon sndcompress qcomrefgenregulator coresightstm stmmacplatform sndpcmdmaengine qcomcommon coresighttmc stmmac coresightreplicator qcomglinksmem coresightcti stmcore [ 48.177444] coresightfunnel sndpcm ufsqcom phyqcomqmpusb gpi phyqcomsnpsfemtov2 coresight phyqcomqmpufs qcomwdt gpuccsa8775p pcsxpcs mdtloader qcomice iccosml3 qmihelpers sndtimer snd soundcore displayconnector qcomrng nvmemrebootmode drmkmshelper phyqcomqmppcie sha256 cfg80211 rfkill socinfo fuse drm backlight ipv6 [ 48.301059] CPU: 2 UID: 0 PID: 293 Comm: kworker/u32:2 Not tainted 6.19.0-rc6-dirty #10 PREEMPT [ 48.310081] Hardware name: Qualcomm Technologies, Inc. Lemans EVK (DT) [ 48.316782] Workqueue: pdrnotifierwq pdrnotifierwork [pdrinterface] [ 48.323672] pstate: 20400005 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 48.330825] pc : mutexlock+0xc/0x54 [ 48.334514] lr : socdapmshutdowndapm+0x44/0x174 [sndsoccore] [ 48.340794] sp : ffff800084ddb7b0 [ 48.344207] x29: ffff800084ddb7b0 x28: ffff00009cd9cf30 x27: ffff00009cd9cc00 [ 48.351544] x26: ffff000099610190 x25: ffffa31d2f19c810 x24: ffffa31d2f185098 [ 48.358869] x23: ffff800084ddb7f8 x22: 0000000000000000 x21: 00000000000000d0 [ 48.366198] x20: ffff00009ba6c338 x19: ffff00009ba6c338 x18: 00000000ffffffff [ 48.373528] x17: 000000040044ffff x16: ffffa31d4ae6dca8 x15: 072007740775076f [ 48.380853] x14: 0765076d07690774 x13: 00313a323a656369 x12: 767265733a637673 [ 48.388182] x11: 00000000000003f9 x10: ffffa31d4c7dea98 x9 : 0000000000000001 [ 48.395519] x8 : ffff00009a2aadc0 x7 : 0000000000000003 x6 : 0000000000000000 [ 48.402854] x5 : 0000000000000 ---truncated---

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

tipc: fix divide-by-zero in tipcskfilterconnect()

A user can set conntimeout to any value via setsockopt(TIPCCONNTIMEOUT), including values less than 4. When a SYN is rejected with TIPCERROVERLOAD and the retry path in tipcskfilterconnect() executes:

delay %= (tsk->conntimeout / 4);

If conntimeout is in the range [0, 3], the integer division yields 0, and the modulo operation triggers a divide-by-zero exception, causing a kernel oops/panic.

Fix this by clamping conntimeout to a minimum of 4 at the point of use in tipcskfilterconnect().

Oops: divide error: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 0 PID: 119 Comm: poc-F144 Not tainted 7.0.0-rc2+ RIP: 0010:tipcskfilterrcv (net/tipc/socket.c:2236 net/tipc/socket.c:2362) Call Trace: tipcskbacklogrcv (include/linux/instrumented.h:82 include/linux/atomic/atomic-instrumented.h:32 include/net/sock.h:2357 net/tipc/socket.c:2406) releasesock (include/net/sock.h:1185 net/core/sock.c:3213) releasesock (net/core/sock.c:3797) tipcconnect (net/tipc/socket.c:2570) sysconnect (include/linux/file.h:62 include/linux/file.h:83 net/socket.c:2098)

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

staging: rtl8723bs: properly validate the data in rtwgetieex()

Just like in commit 154828bf9559 ("staging: rtl8723bs: fix out-of-bounds read in rtwgetie() parser"), we don't trust the data in the frame so we should check the length better before acting on it

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

ceph: fix inlink underrun during async unlink

During async unlink, we drop the inlink counter before we receive the completion (that will eventually update the inlink) because "we assume that the unlink will succeed". That is not a bad idea, but it races against deletions by other clients (or against the completion of our own unlink) and can lead to an underrun which emits a WARNING like this one:

WARNING: CPU: 85 PID: 25093 at fs/inode.c:407 dropnlink+0x50/0x68 Modules linked in: CPU: 85 UID: 3221252029 PID: 25093 Comm: php-cgi8.1 Not tainted 6.14.11-cm4all1-ampere #655 Hardware name: Supermicro ARS-110M-NR/R12SPD-A, BIOS 1.1b 10/17/2023 pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : dropnlink+0x50/0x68 lr : cephunlink+0x6c4/0x720 sp : ffff80012173bc90 x29: ffff80012173bc90 x28: ffff086d0a45aaf8 x27: ffff0871d0eb5680 x26: ffff087f2a64a718 x25: 0000020000000180 x24: 0000000061c88647 x23: 0000000000000002 x22: ffff07ff9236d800 x21: 0000000000001203 x20: ffff07ff9237b000 x19: ffff088b8296afc0 x18: 00000000f3c93365 x17: 0000000000070000 x16: ffff08faffcbdfe8 x15: ffff08faffcbdfec x14: 0000000000000000 x13: 45445f65645f3037 x12: 34385f6369706f74 x11: 0000a2653104bb20 x10: ffffd85f26d73290 x9 : ffffd85f25664f94 x8 : 00000000000000c0 x7 : 0000000000000000 x6 : 0000000000000002 x5 : 0000000000000081 x4 : 0000000000000481 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff08727d3f91e8 Call trace: dropnlink+0x50/0x68 (P) vfsunlink+0xb0/0x2e8 dounlinkat+0x204/0x288 arm64sysunlinkat+0x3c/0x80 invokesyscall.constprop.0+0x54/0xe8 doel0svc+0xa4/0xc8 el0svc+0x18/0x58 el0t64synchandler+0x104/0x130 el0t64sync+0x154/0x158

In cephunlink(), a call to cephmdscsubmitrequest() submits the CEPHMDSOPUNLINK to the MDS, but does not wait for completion.

Meanwhile, between this call and the following dropnlink() call, a worker thread may process a CEPHCAPOPIMPORT, CEPHCAPOPGRANT or just a CEPHMSGCLIENTREPLY (the latter of which could be our own completion). These will lead to a setnlink() call, updating the inlink counter to the value received from the MDS. If that new inlink value happens to be zero, it is illegal to decrement it further. But that is exactly what cephunlink() will do then.

The WARNING can be reproduced this way:

1. Force async unlink; only the async code path is affected. Having no real clue about Ceph internals, I was unable to find out why the MDS wouldn't give me the "Fxr" capabilities, so I patched getcapsforasyncunlink() to always succeed.

(Note that the WARNING dump above was found on an unpatched kernel, without this kludge - this is not a theoretical bug.)

2. Add a sleep call after cephmdscsubmitrequest() so the unlink completion gets handled by a worker thread before dropnlink() is called. This guarantees that the inlink is already zero before dropnlink() runs.

The solution is to skip the counter decrement when it is already zero, but doing so without a lock is still racy (TOCTOU). Since cephfillinode() and handlecapgrant() both hold the cephinodeinfo.icephlock spinlock while setnlink() runs, this seems like the proper lock to protect the inlink updates.

I found prior art in NFS and SMB (using inode.ilock) and AFS (using afsvnode.cblock). All three have the zero check as well.

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

cgroup: fix race between task migration and iteration

When a task is migrated out of a cssset, cgroupmigrateaddtask() first moves it from cset->tasks to cset->mgtasks via:

listmovetail(&task->cglist, &cset->mgtasks);

If a csstaskiter currently has it->taskpos pointing to this task, csssetmovetask() calls csstaskiterskip() to keep the iterator valid. However, since the task has already been moved to ->mgtasks, the iterator is advanced relative to the mgtasks list instead of the original tasks list. As a result, remaining tasks on cset->tasks, as well as tasks queued on cset->mgtasks, can be skipped by iteration.

Fix this by calling csssetskiptaskiters() before unlinking task->cglist from cset->tasks. This advances all active iterators to the next task on cset->tasks, so iteration continues correctly even when a task is concurrently being migrated.

This race is hard to hit in practice without instrumentation, but it can be reproduced by artificially slowing down cgroupprocsshow(). For example, on an Android device a temporary /sys/kernel/cgroup/cgrouptest knob can be added to inject a delay into cgroupprocsshow(), and then:

1) Spawn three long-running tasks (PIDs 101, 102, 103). 2) Create a test cgroup and move the tasks into it. 3) Enable a large delay via /sys/kernel/cgroup/cgrouptest. 4) In one shell, read cgroup.procs from the test cgroup. 5) Within the delay window, in another shell migrate PID 102 by writing it to a different cgroup.procs file.

Under this setup, cgroup.procs can intermittently show only PID 101 while skipping PID 103. Once the migration completes, reading the file again shows all tasks as expected.

Note that this change does not allow removing the existing csssetskiptaskiters() call in csssetmovetask(). The new call in cgroupmigrateaddtask() only handles iterators that are racing with migration while the task is still on cset->tasks. Iterators may also start after the task has been moved to cset->mgtasks. If we dropped csssetskiptaskiters() from csssetmovetask(), such iterators could keep taskpos pointing to a migrating task, causing csstaskiteradvance() to malfunction on the destination cssset, up to and including crashes or infinite loops.

The race window between migration and iteration is very small, and csstaskiter is not on a hot path. In the worst case, when an iterator is positioned on the first thread of the migrating process, cgroupmigrateaddtask() may have to skip multiple tasks via csssetskiptaskiters(). However, this only happens when migration and iteration actually race, so the performance impact is negligible compared to the correctness fix provided here.

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

netfilter: nfnetlinkcthelper: fix OOB read in nfnlcthelperdumptable()

nfnlcthelperdumptable() has a 'goto restart' that jumps to a label inside the for loop body. When the "last" helper saved in cb->args[1] is deleted between dump rounds, every entry fails the (cur != last) check, so cb->args[1] is never cleared. The for loop finishes with cb->args[0] == nfcthelperhsize, and the 'goto restart' jumps back into the loop body bypassing the bounds check, causing an 8-byte out-of-bounds read on nfcthelperhash[nfcthelperhsize].

The 'goto restart' block was meant to re-traverse the current bucket when "last" is no longer found, but it was placed after the for loop instead of inside it. Move the block into the for loop body so that the restart only occurs while cb->args[0] is still within bounds.

BUG: KASAN: slab-out-of-bounds in nfnlcthelperdumptable+0x9f/0x1b0 Read of size 8 at addr ffff888104ca3000 by task poccthelper/131 Call Trace: nfnlcthelperdumptable+0x9f/0x1b0 netlinkdump+0x333/0x880 netlinkrecvmsg+0x3e2/0x4b0 sockrecvmsg+0xde/0xf0 sysrecvfrom+0x150/0x200 x64sysrecvfrom+0x76/0x90 dosyscall64+0xc3/0x6e0

Allocated by task 1: kvmallocnodenoprof+0x21b/0x700 nfctallochashtable+0x65/0xd0 nfconntrackhelperinit+0x21/0x60 nfconntrackinitstart+0x18d/0x300 nfconntrackstandaloneinit+0x12/0xc0

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

drm/amdgpu: Fix use-after-free race in VM acquire

Replace non-atomic vm->processinfo assignment with cmpxchg() to prevent race when parent/child processes sharing a drmfile both try to acquire the same VM after fork().

(cherry picked from commit c7c573275ec20db05be769288a3e3bb2250ec618)

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

net: ncsi: fix skb leak in error paths

Early return paths in NCSI RX and AEN handlers fail to release the received skb, resulting in a memory leak.

Specifically, ncsiaenhandler() returns on invalid AEN packets without consuming the skb. Similarly, ncsircvrsp() exits early when failing to resolve the NCSI device, response handler, or request, leaving the skb unfreed.

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

scsi: storvsc: Fix scheduling while atomic on PREEMPTRT

This resolves the follow splat and lock-up when running with PREEMPTRT enabled on Hyper-V:

[ 415.140818] BUG: scheduling while atomic: stress-ng-iomix/1048/0x00000002 [ 415.140822] INFO: lockdep is turned off. [ 415.140823] Modules linked in: intelraplmsr intelraplcommon inteluncorefrequencycommon intelpmccore pmttelemetry pmtdiscovery pmtclass intelpmcssramtelemetry intelvsec ghashclmulniintel aesniintel rapl binfmtmisc nlsascii nlscp437 vfat fat sndpcm hypervdrm sndtimer drmclientlib drmshmemhelper snd sg soundcore drmkmshelper pcspkr hvballoon hvutils evdev joydev drm configfs efipstore nfnetlink vsockloopback vmwvsockvirtiotransportcommon hvsock vmwvsockvmcitransport vsock vmwvmci efivarfs autofs4 ext4 crc16 mbcache jbd2 srmod sdmod cdrom hvstorvsc serioraw hidgeneric scsitransportfc hidhyperv scsimod hid hvnetvsc hypervkeyboard scsicommon [ 415.140846] Preemption disabled at: [ 415.140847] [<ffffffffc0656171>] storvscqueuecommand+0x2e1/0xbe0 [hvstorvsc] [ 415.140854] CPU: 8 UID: 0 PID: 1048 Comm: stress-ng-iomix Not tainted 6.19.0-rc7 #30 PREEMPT{RT,(full)} [ 415.140856] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/04/2024 [ 415.140857] Call Trace: [ 415.140861] <TASK> [ 415.140861] ? storvscqueuecommand+0x2e1/0xbe0 [hvstorvsc] [ 415.140863] dumpstacklvl+0x91/0xb0 [ 415.140870] schedulebug+0x9c/0xc0 [ 415.140875] schedule+0xdf6/0x1300 [ 415.140877] ? rtlockslowlocklocked+0x56c/0x1980 [ 415.140879] ? rcuiswatching+0x12/0x60 [ 415.140883] schedulertlock+0x21/0x40 [ 415.140885] rtlockslowlocklocked+0x502/0x1980 [ 415.140891] rtspinlock+0x89/0x1e0 [ 415.140893] hvringbufferwrite+0x87/0x2a0 [ 415.140899] vmbussendpacketmpbdesc+0xb6/0xe0 [ 415.140900] ? rcuiswatching+0x12/0x60 [ 415.140902] storvscqueuecommand+0x669/0xbe0 [hvstorvsc] [ 415.140904] ? HARDIRQverbose+0x10/0x10 [ 415.140908] ? rqqosissue+0x28/0x40 [ 415.140911] scsiqueuerq+0x760/0xd80 [scsimod] [ 415.140926] blkmqissuedirectly+0x4a/0xc0 [ 415.140928] blkmqissuedirect+0x87/0x2b0 [ 415.140931] blkmqdispatchqueuerequests+0x120/0x440 [ 415.140933] blkmqflushpluglist+0x7a/0x1a0 [ 415.140935] blkflushplug+0xf4/0x150 [ 415.140940] submitbio+0x2b2/0x5c0 [ 415.140944] ? submitbionoacctnocheck+0x272/0x360 [ 415.140946] submitbionoacctnocheck+0x272/0x360 [ 415.140951] ext4readbhlock+0x3e/0x60 [ext4] [ 415.140995] ext4blockwritebegin+0x396/0x650 [ext4] [ 415.141018] ? pfxext4dagetblockprep+0x10/0x10 [ext4] [ 415.141038] ext4dawritebegin+0x1c4/0x350 [ext4] [ 415.141060] genericperformwrite+0x14e/0x2c0 [ 415.141065] ext4bufferedwriteiter+0x6b/0x120 [ext4] [ 415.141083] vfswrite+0x2ca/0x570 [ 415.141087] ksyswrite+0x76/0xf0 [ 415.141089] dosyscall64+0x99/0x1490 [ 415.141093] ? rcuiswatching+0x12/0x60 [ 415.141095] ? finishtaskswitch.isra.0+0xdf/0x3d0 [ 415.141097] ? rcuiswatching+0x12/0x60 [ 415.141098] ? lockrelease+0x1f0/0x2a0 [ 415.141100] ? rcuiswatching+0x12/0x60 [ 415.141101] ? finishtaskswitch.isra.0+0xe4/0x3d0 [ 415.141103] ? rcuiswatching+0x12/0x60 [ 415.141104] ? schedule+0xb34/0x1300 [ 415.141106] ? hrtimertrytocancel+0x1d/0x170 [ 415.141109] ? donanosleep+0x8b/0x160 [ 415.141111] ? hrtimernanosleep+0x89/0x100 [ 415.141114] ? pfxhrtimerwakeup+0x10/0x10 [ 415.141116] ? xfdvalidatestate+0x26/0x90 [ 415.141118] ? rcuiswatching+0x12/0x60 [ 415.141120] ? dosyscall64+0x1e0/0x1490 [ 415.141121] ? dosyscall64+0x1e0/0x1490 [ 415.141123] ? rcuiswatching+0x12/0x60 [ 415.141124] ? dosyscall64+0x1e0/0x1490 [ 415.141125] ? dosyscall64+0x1e0/0x1490 [ 415.141127] ? irqentryexit+0x140/0 ---truncated---

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

dm: remove fake timeout to avoid leak request

Since commit 15f73f5b3e59 ("blk-mq: move failure injection out of blkmqcompleterequest"), drivers are responsible for calling blkshouldfaketimeout() at appropriate code paths and opportunities.

However, the dm driver does not implement its own timeout handler and relies on the timeout handling of its slave devices.

If an io-timeout-fail error is injected to a dm device, the request will be leaked and never completed, causing tasks to hang indefinitely.

Reproduce: 1. prepare dm which has iscsi slave device 2. inject io-timeout-fail to dm echo 1 >/sys/class/block/dm-0/io-timeout-fail echo 100 >/sys/kernel/debug/failiotimeout/probability echo 10 >/sys/kernel/debug/failiotimeout/times 3. read/write dm 4. iscsiadm -m node -u

Result: hang task like below [ 862.243768] INFO: task kworker/u514:2:151 blocked for more than 122 seconds. [ 862.244133] Tainted: G E 6.19.0-rc1+ #51 [ 862.244337] "echo 0 > /proc/sys/kernel/hungtasktimeoutsecs" disables this message. [ 862.244718] task:kworker/u514:2 state:D stack:0 pid:151 tgid:151 ppid:2 taskflags:0x4288060 flags:0x00080000 [ 862.245024] Workqueue: iscsictrl3:1 iscsiunbindsession [scsitransportiscsi] [ 862.245264] Call Trace: [ 862.245587] <TASK> [ 862.245814] schedule+0x810/0x15c0 [ 862.246557] schedule+0x69/0x180 [ 862.246760] blkmqfreezequeuewait+0xde/0x120 [ 862.247688] elevatorchange+0x16d/0x460 [ 862.247893] elevatorsetnone+0x87/0xf0 [ 862.248798] blkunregisterqueue+0x12e/0x2a0 [ 862.248995] delgendisk+0x231/0x7e0 [ 862.250143] delgendisk+0x12f/0x1d0 [ 862.250339] sdremove+0x85/0x130 [sdmod] [ 862.250650] devicereleasedriverinternal+0x36d/0x530 [ 862.250849] busremovedevice+0x1dd/0x3f0 [ 862.251042] devicedel+0x38a/0x930 [ 862.252095] scsiremovedevice+0x293/0x360 [ 862.252291] scsiremovetarget+0x486/0x760 [ 862.252654] iscsiunbindsession+0x18a/0x3e0 [scsitransportiscsi] [ 862.252886] processonework+0x633/0xe50 [ 862.253101] workerthread+0x6df/0xf10 [ 862.253647] kthread+0x36d/0x720 [ 862.254533] retfromfork+0x2a6/0x470 [ 862.255852] retfromforkasm+0x1a/0x30 [ 862.256037] </TASK>

Remove the blkshouldfaketimeout() check from dm, as dm has no native timeout handling and should not attempt to fake timeouts.

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

mailbox: Prevent out-of-bounds access in fwmboxindexxlate()

Although it is guided that #mbox-cells must be at least 1, there are many instances of #mbox-cells = <0>; in the device tree. If that is the case and the corresponding mailbox controller does not provide fwxlate and ofxlate function pointers, fwmboxindexxlate() will be used by default and out-of-bounds accesses could occur due to lack of bounds check in that function.

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

octeontx2-af: Workaround SQM/PSE stalls by disabling sticky

NIX SQ manager sticky mode is known to cause stalls when multiple SQs share an SMQ and transmit concurrently. Additionally, PSE may deadlock on transitions between sticky and non-sticky transmissions. There is also a credit drop issue observed when certain condition clocks are gated.

work around these hardware errata by: - Disabling SQM sticky operation: - Clear TM6 (bit 15) - Clear TM11 (bit 14) - Disabling sticky → non-sticky transition path that can deadlock PSE: - Clear TM5 (bit 23) - Preventing credit drops by keeping the control-flow clock enabled: - Set TM9 (bit 21)

These changes are applied via NIXAFSQMDBGCTLSTATUS. With this configuration the SQM/PSE maintain forward progress under load without credit loss, at the cost of disabling sticky optimizations.

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

hfsplus: pretend special inodes as regular files

Since commit af153bb63a33 ("vfs: catch invalid modes in mayopen()") requires any inode be one of SIFDIR/SIFLNK/SIFREG/SIFCHR/SIFBLK/ SIFIFO/SIFSOCK type, use SIFREG for special inodes.

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

drm/atmel-hlcdc: fix memory leak from the atomicdestroystate callback

After several commits, the slab memory increases. Some drmcrtccommit objects are not freed. The atomicdestroystate callback only put the framebuffer. Use the drmatomichelperplanedestroystate() function to put all the objects that are no longer needed.

It has been seen after hours of usage of a graphics application or using kmemleak:

unreferenced object 0xc63a6580 (size 64): comm "egtbasic", pid 171, jiffies 4294940784 hex dump (first 32 bytes): 40 50 34 c5 01 00 00 00 ff ff ff ff 8c 65 3a c6 @P4..........e:. 8c 65 3a c6 ff ff ff ff 98 65 3a c6 98 65 3a c6 .e:......e:..e:. backtrace (crc c25aa925): kmemleakalloc+0x34/0x3c kmalloccachenoprof+0x150/0x1a4 drmatomichelpersetupcommit+0x1e8/0x7bc drmatomichelpercommit+0x3c/0x15c drmatomiccommit+0xc0/0xf4 drmatomichelpersetconfig+0x84/0xb8 drmmodesetcrtc+0x32c/0x810 drmioctl+0x20c/0x488 sysioctl+0x14c/0xc20 retfastsyscall+0x0/0x54

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

HID: prodikeys: Check presence of pm->inputep82

Fake USB devices can send their own report descriptors for which the inputmapping() hook does not get called. In this case, pm->inputep82 stays NULL, which leads to a crash later.

This does not happen with the real device, but can be provoked by imposing as one.

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

EFI/CPER: don't go past the ARM processor CPER record buffer

There's a logic inside GHES/CPER to detect if the sectionlength is too small, but it doesn't detect if it is too big.

Currently, if the firmware receives an ARM processor CPER record stating that a section length is big, kernel will blindly trust sectionlength, producing a very long dump. For instance, a 67 bytes record with ERRINFONUM set 46198 and section length set to 854918320 would dump a lot of data going a way past the firmware memory-mapped area.

Fix it by adding a logic to prevent it to go past the buffer if ERRINFONUM is too big, making it report instead:

[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 1 [Hardware Error]: event severity: recoverable [Hardware Error]: Error 0, type: recoverable [Hardware Error]: sectiontype: ARM processor error [Hardware Error]: MIDR: 0xff304b2f8476870a [Hardware Error]: section length: 854918320, CPER size: 67 [Hardware Error]: section length is too big [Hardware Error]: firmware-generated error record is incorrect [Hardware Error]: ERRINFONUM is 46198

[ rjw: Subject and changelog tweaks ]

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

ntb: ntbhwswitchtec: Fix array-index-out-of-bounds access

Number of MW LUTs depends on NTB configuration and can be set to MAXMWS, This patch protects against invalid index out of bounds access to mwsizes When invalid access print message to user that configuration is not valid.

In multiple locations, there is a possible memory corruption due to a logic error in the code. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.

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:

EFI/CPER: don't dump the entire memory region

The current logic at cperprintfwerr() doesn't check if the error record length is big enough to handle offset. On a bad firmware, if the ofset is above the actual record, length -= offset will underflow, making it dump the entire memory.

The end result can be:

- the logic taking a lot of time dumping large regions of memory; - data disclosure due to the memory dumps; - an OOPS, if it tries to dump an unmapped memory region.

Fix it by checking if the section length is too small before doing a hex dump.

[ rjw: Subject tweaks ]

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

drm/atmel-hlcdc: fix use-after-free of drmcrtccommit after release

The atmelhlcdcplaneatomicduplicatestate() callback was copying the atmelhlcdcplane state structure without properly duplicating the drmplanestate. In particular, state->commit remained set to the old state commit, which can lead to a use-after-free in the next drmatomiccommit() call.

Fix this by calling drmatomichelperduplicateplanestate(), which correctly clones the base drmplanestate (including the ->commit pointer).

It has been seen when closing and re-opening the device node while another DRM client (e.g. fbdev) is still attached:

============================================================================= BUG kmalloc-64 (Not tainted): Poison overwritten -----------------------------------------------------------------------------

0xc611b344-0xc611b344 @offset=836. First byte 0x6a instead of 0x6b FIX kmalloc-64: Restoring Poison 0xc611b344-0xc611b344=0x6b Allocated in drmatomichelpersetupcommit+0x1e8/0x7bc age=178 cpu=0 pid=29 drmatomichelpersetupcommit+0x1e8/0x7bc drmatomichelpercommit+0x3c/0x15c drmatomiccommit+0xc0/0xf4 drmframebufferremove+0x4cc/0x5a8 drmmodermfbworkfn+0x6c/0x80 processonework+0x12c/0x2cc workerthread+0x2a8/0x400 kthread+0xc0/0xdc retfromfork+0x14/0x28 Freed in drmatomichelpercommithwdone+0x100/0x150 age=8 cpu=0 pid=169 drmatomichelpercommithwdone+0x100/0x150 drmatomichelpercommittail+0x64/0x8c committail+0x168/0x18c drmatomichelpercommit+0x138/0x15c drmatomiccommit+0xc0/0xf4 drmatomichelpersetconfig+0x84/0xb8 drmmodesetcrtc+0x32c/0x810 drmioctl+0x20c/0x488 sysioctl+0x14c/0xc20 retfastsyscall+0x0/0x54 Slab 0xef8bc360 objects=21 used=16 fp=0xc611b7c0 flags=0x200(workingset|zone=0) Object 0xc611b340 @offset=832 fp=0xc611b7c0

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

net: usb: pegasus: enable basic endpoint checking

pegasusprobe() fills URBs with hardcoded endpoint pipes without verifying the endpoint descriptors:

- usbrcvbulkpipe(dev, 1) for RX data - usbsndbulkpipe(dev, 2) for TX data - usbrcvintpipe(dev, 3) for status interrupts

A malformed USB device can present these endpoints with transfer types that differ from what the driver assumes.

Add a pegasususbep enum for endpoint numbers, replacing magic constants throughout. Add usbcheckbulkendpoints() and usbcheckintendpoints() calls before any resource allocation to verify endpoint types before use, rejecting devices with mismatched descriptors at probe time, and avoid triggering assertion.

Similar fix to - commit 90b7f2961798 ("net: usb: rtl8150: enable basic endpoint checking") - commit 9e7021d2aeae ("net: usb: catc: enable basic endpoint checking")

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

net: wan/fslucchdlc: Fix dmafreecoherent() in uhdlcmemclean()

The priv->rxbuffer and priv->txbuffer are alloc'd together as contiguous buffers in uhdlcinit() but freed as two buffers in uhdlcmemclean().

Change the cleanup to only call dmafreecoherent() once on the whole buffer.

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

xfrm6: fix uninitialized saddr in xfrm6getsaddr()

xfrm6getsaddr() does not check the return value of ipv6devgetsaddr(). When ipv6devgetsaddr() fails to find a suitable source address (returns -EADDRNOTAVAIL), saddr->in6 is left uninitialized, but xfrm6getsaddr() still returns 0 (success).

This causes the caller xfrmtmplresolveone() to use the uninitialized address in xfrmstatefind(), triggering KMSAN warning:

===================================================== BUG: KMSAN: uninit-value in xfrmstatefind+0x2424/0xa940 xfrmstatefind+0x2424/0xa940 xfrmresolveandcreatebundle+0x906/0x5a20 xfrmlookupwithifid+0xcc0/0x3770 xfrmlookuproute+0x63/0x2b0 iprouteoutputflow+0x1ce/0x270 udpsendmsg+0x2ce1/0x3400 inetsendmsg+0x1ef/0x2a0 socksendmsg+0x278/0x3d0 syssendto+0x593/0x720 x64syssendto+0x130/0x200 x64syscall+0x332b/0x3e70 dosyscall64+0xd3/0xf80 entrySYSCALL64afterhwframe+0x77/0x7f

Local variable tmp.i.i created at: xfrmresolveandcreatebundle+0x3e3/0x5a20 xfrmlookupwithifid+0xcc0/0x3770 =====================================================

Fix by checking the return value of ipv6devgetsaddr() and propagating the error.

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

ext4: always drain queued discard work in ext4mbrelease()

While reviewing recent ext4 patch[1], Sashiko raised the following concern[2]:

If the filesystem is initially mounted with the discard option, deleting files will populate sbi->sdiscardlist and queue sdiscardwork. If it is then remounted with nodiscard, the EXT4MOUNTDISCARD flag is cleared, but the pending sdiscardwork is neither cancelled nor flushed.

[1] https://lore.kernel.org/r/20260319094545.19291-1-qiang.zhang@linux.dev/ [2] https://sashiko.dev/#/patchset/20260319094545.19291-1-qiang.zhang%40linux.dev

The concern was valid, but it had nothing to do with the patch[1]. One of the problems with Sashiko in its current (early) form is that it will detect pre-existing issues and report it as a problem with the patch that it is reviewing.

In practice, it would be hard to hit deliberately (unless you are a malicious syzkaller fuzzer), since it would involve mounting the file system with -o discard, and then deleting a large number of files, remounting the file system with -o nodiscard, and then immediately unmounting the file system before the queued discard work has a change to drain on its own.

Fix it because it's a real bug, and to avoid Sashiko from raising this concern when analyzing future patches to mballoc.c.

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

net: qrtr: replace qrtrtxflow radixtree with xarray to fix memory leak

radixtreecreate() allocates and links intermediate nodes into the tree one by one. If a subsequent allocation fails, the already-linked nodes remain in the tree with no corresponding leaf entry. These orphaned internal nodes are never reclaimed because radixtreeforeachslot() only visits slots containing leaf values.

The radixtree API is deprecated in favor of xarray. As suggested by Matthew Wilcox, migrate qrtrtxflow from radixtree to xarray instead of fixing the radixtree itself [1]. xarray properly handles cleanup of internal nodes — xadestroy() frees all internal xarray nodes when the qrtrnode is released, preventing the leak.

[1] https://lore.kernel.org/all/20260225071623.41275-1-jiayuan.chen@linux.dev/T/

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:

nvme-pci: Fix slab-out-of-bounds in nvmedbbufset

dev->onlinequeues is a count incremented in nvmeinitqueue. Thus, valid indices are 0 through dev->onlinequeues − 1.

This patch fixes the loop condition to ensure the index stays within the valid range. Index 0 is excluded because it is the admin queue.

KASAN splat:

================================================================== BUG: KASAN: slab-out-of-bounds in nvmedbbuffree drivers/nvme/host/pci.c:377 [inline] BUG: KASAN: slab-out-of-bounds in nvmedbbufset+0x39c/0x400 drivers/nvme/host/pci.c:404 Read of size 2 at addr ffff88800592a574 by task kworker/u8:5/74

CPU: 0 UID: 0 PID: 74 Comm: kworker/u8:5 Not tainted 6.19.0-dirty #10 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: nvme-reset-wq nvmeresetwork Call Trace: <TASK> dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0xea/0x150 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:378 [inline] printreport+0xce/0x5d0 mm/kasan/report.c:482 kasanreport+0xdc/0x110 mm/kasan/report.c:595 asanreportload2noabort+0x18/0x20 mm/kasan/reportgeneric.c:379 nvmedbbuffree drivers/nvme/host/pci.c:377 [inline] nvmedbbufset+0x39c/0x400 drivers/nvme/host/pci.c:404 nvmeresetwork+0x36b/0x8c0 drivers/nvme/host/pci.c:3252 processonework+0x956/0x1aa0 kernel/workqueue.c:3257 processscheduledworks kernel/workqueue.c:3340 [inline] workerthread+0x65c/0xe60 kernel/workqueue.c:3421 kthread+0x41a/0x930 kernel/kthread.c:463 retfromfork+0x6f8/0x8c0 arch/x86/kernel/process.c:158 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:246 </TASK>

Allocated by task 34 on cpu 1 at 4.241550s: kasansavestack+0x2c/0x60 mm/kasan/common.c:57 kasansavetrack+0x1c/0x70 mm/kasan/common.c:78 kasansaveallocinfo+0x3c/0x50 mm/kasan/generic.c:570 poisonkmallocredzone mm/kasan/common.c:398 [inline] kasankmalloc+0xb5/0xc0 mm/kasan/common.c:415 kasankmalloc include/linux/kasan.h:263 [inline] dokmallocnode mm/slub.c:5657 [inline] kmallocnodenoprof+0x2bf/0x8d0 mm/slub.c:5663 kmallocarraynodenoprof include/linux/slab.h:1075 [inline] nvmepciallocdev drivers/nvme/host/pci.c:3479 [inline] nvmeprobe+0x2f1/0x1820 drivers/nvme/host/pci.c:3534 localpciprobe+0xef/0x1c0 drivers/pci/pci-driver.c:324 pcicallprobe drivers/pci/pci-driver.c:392 [inline] pcideviceprobe drivers/pci/pci-driver.c:417 [inline] pcideviceprobe+0x743/0x920 drivers/pci/pci-driver.c:451 calldriverprobe drivers/base/dd.c:583 [inline] reallyprobe+0x29b/0xb70 drivers/base/dd.c:661 driverprobedevice+0x3b0/0x4a0 drivers/base/dd.c:803 driverprobedevice+0x56/0x1f0 drivers/base/dd.c:833 driverattachasynchelper+0x155/0x340 drivers/base/dd.c:1159 asyncrunentryfn+0xa6/0x4b0 kernel/async.c:129 processonework+0x956/0x1aa0 kernel/workqueue.c:3257 processscheduledworks kernel/workqueue.c:3340 [inline] workerthread+0x65c/0xe60 kernel/workqueue.c:3421 kthread+0x41a/0x930 kernel/kthread.c:463 retfromfork+0x6f8/0x8c0 arch/x86/kernel/process.c:158 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:246

The buggy address belongs to the object at ffff88800592a000 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 244 bytes to the right of allocated 1152-byte region [ffff88800592a000, ffff88800592a480)

The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x5928 head: order:3 mapcount:0 entiremapcount:0 nrpagesmapped:0 pincount:0 anon flags: 0xfffffc0000040(head|node=0|zone=1|lastcpupid=0x1fffff) pagetype: f5(slab) raw: 000fffffc0000040 ffff888001042000 0000000000000000 dead000000000001 raw: 0000000000000000 0000000000080008 00000000f5000000 0000000000000000 head: 000fffffc0000040 ffff888001042000 00000 ---truncated---

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

ALSA: usb-audio: Check endpoint numbers at parsing Scarlett2 mixer interfaces

The Scarlett2 mixer quirk in USB-audio driver may hit a NULL dereference when a malformed USB descriptor is passed, since it assumes the presence of an endpoint in the parsed interface in scarlett2findfcinterface(), as reported by fuzzer.

For avoiding the NULL dereference, just add the sanity check of bNumEndpoints and skip the invalid interface.

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

nvme-pci: Fix race bug in nvmepollirqdisable()

In the following scenario, pdev can be disabled between (1) and (3) by (2). This sets pdev->msixenabled = 0. Then, pciirqvector() will return MSI-X IRQ(>15) for (1) whereas return INTx IRQ(<=15) for (2). This causes IRQ warning because it tries to enable INTx IRQ that has never been disabled before.

To fix this, save IRQ number into a local variable and ensure disableirq() and enableirq() operate on the same IRQ number. Even if pcifreeirqvectors() frees the IRQ concurrently, disableirq() and enableirq() on a stale IRQ number is still valid and safe, and the depth accounting reamins balanced.

task 1: nvmepollirqdisable() disableirq(pciirqvector(pdev, nvmeq->cqvector)) ...(1) enableirq(pciirqvector(pdev, nvmeq->cqvector)) ...(3)

task 2: nvmeresetwork() nvmedevdisable() pdev->msixenable = 0; ...(2)

crash log:

------------[ cut here ]------------ Unbalanced enable for IRQ 10 WARNING: kernel/irq/manage.c:753 at enableirq+0x102/0x190 kernel/irq/manage.c:753, CPU#1: kworker/1:0H/26 Modules linked in: CPU: 1 UID: 0 PID: 26 Comm: kworker/1:0H Not tainted 6.19.0-dirty #9 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: kblockd blkmqtimeoutwork RIP: 0010:enableirq+0x107/0x190 kernel/irq/manage.c:753 Code: ff df 48 89 fa 48 c1 ea 03 0f b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 04 84 d2 75 79 48 8d 3d 2e 7a 3f 05 41 8b 74 24 2c <67> 48 0f b9 3a e8 ef b9 21 00 5b 41 5c 5d e9 46 54 66 03 e8 e1 b9 RSP: 0018:ffffc900001bf550 EFLAGS: 00010046 RAX: 0000000000000007 RBX: 0000000000000000 RCX: ffffffffb20c0e90 RDX: 0000000000000000 RSI: 000000000000000a RDI: ffffffffb74b88f0 RBP: ffffc900001bf560 R08: ffff88800197cf00 R09: 0000000000000001 R10: 0000000000000003 R11: 0000000000000003 R12: ffff8880012a6000 R13: 1ffff92000037eae R14: 000000000000000a R15: 0000000000000293 FS: 0000000000000000(0000) GS:ffff8880b49f7000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000555da4a25fa8 CR3: 00000000208e8000 CR4: 00000000000006f0 Call Trace: <TASK> enableirq+0x121/0x1e0 kernel/irq/manage.c:797 nvmepollirqdisable+0x162/0x1c0 drivers/nvme/host/pci.c:1494 nvmetimeout+0x965/0x14b0 drivers/nvme/host/pci.c:1744 blkmqrqtimedout block/blk-mq.c:1653 [inline] blkmqhandleexpired+0x227/0x2d0 block/blk-mq.c:1721 btiter+0x2fc/0x3a0 block/blk-mq-tag.c:292 sbitmapforeachset include/linux/sbitmap.h:269 [inline] sbitmapforeachset include/linux/sbitmap.h:290 [inline] btforeach block/blk-mq-tag.c:324 [inline] blkmqqueuetagbusyiter+0x969/0x1e80 block/blk-mq-tag.c:536 blkmqtimeoutwork+0x627/0x870 block/blk-mq.c:1763 processonework+0x956/0x1aa0 kernel/workqueue.c:3257 processscheduledworks kernel/workqueue.c:3340 [inline] workerthread+0x65c/0xe60 kernel/workqueue.c:3421 kthread+0x41a/0x930 kernel/kthread.c:463 retfromfork+0x6f8/0x8c0 arch/x86/kernel/process.c:158 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:246 </TASK> irq event stamp: 74478 hardirqs last enabled at (74477): [<ffffffffb5720a9c>] rawspinunlockirq include/linux/spinlockapismp.h:159 [inline] hardirqs last enabled at (74477): [<ffffffffb5720a9c>] rawspinunlockirq+0x2c/0x60 kernel/locking/spinlock.c:202 hardirqs last disabled at (74478): [<ffffffffb57207b5>] rawspinlockirqsave include/linux/spinlockapismp.h:108 [inline] hardirqs last disabled at (74478): [<ffffffffb57207b5>] rawspinlockirqsave+0x85/0xa0 kernel/locking/spinlock.c:162 softirqs last enabled at (74304): [<ffffffffb1e9466c>] dosoftirq kernel/softirq.c:656 [inline] softirqs last enabled at (74304): [<ffffffffb1e9466c>] invokesoftirq kernel/softirq.c:496 [inline] softirqs last enabled at (74304): [<ffffffffb1e9466c>] irqexitrcu+0xdc/0x120 ---truncated---