In the Linux kernel, the following vulnerability has been resolved:
sched/mmcid: Prevent CID stalls due to concurrent forks
A newly forked task is accounted as MMCID user before the task is visible in the process' thread list and the global task list. This creates the following problem:
CPU1 CPU2 fork() schedmmcidfork(tnew1) tnew1->mm.mmcidusers++; tnew1->mmcid.cid = getcid() -> preemption fork() schedmmcidfork(tnew2) tnew2->mm.mmcidusers++; // Reaches the per CPU threshold mmcidfixuptaskstocpus() foreachother(current, p) ....
As tnew1 is not visible yet, this fails to fix up the already allocated CID of tnew1. As a consequence a subsequent schedule in might fail to acquire a (transitional) CID and the machine stalls.
Move the invocation of schedmmcidfork() after the new task becomes visible in the thread and the task list to prevent this.
This also makes it symmetrical vs. exit() where the task is removed as CID user before the task is removed from the thread and task lists.
In the Linux kernel, the following vulnerability has been resolved:
libceph: Fix potential out-of-bounds access in cephhandleauthreply()
This patch fixes an out-of-bounds access in cephhandleauthreply() that can be triggered by a message of type CEPHMSGAUTHREPLY. In cephhandleauthreply(), the value of the payloadlen field of such a message is stored in a variable of type int. A value greater than INTMAX leads to an integer overflow and is interpreted as a negative value. This leads to decrementing the pointer address by this value and subsequently accessing it because cephdecodeneed() only checks that the memory access does not exceed the end address of the allocation.
This patch fixes the issue by changing the data type of payloadlen to u32. Additionally, the data type of resultmsglen is changed to u32, as it is also a variable holding a non-negative length.
Also, an additional layer of sanity checks is introduced, ensuring that directly after reading it from the message, payloadlen and resultmsglen are not greater than the overall segment length.
BUG: KASAN: slab-out-of-bounds in cephhandleauthreply+0x642/0x7a0 [libceph] Read of size 4 at addr ffff88811404df14 by task kworker/20:1/262
CPU: 20 UID: 0 PID: 262 Comm: kworker/20:1 Not tainted 6.19.2 #5 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: ceph-msgr cephconworkfn [libceph] Call Trace: <TASK> dumpstacklvl+0x76/0xa0 printreport+0xd1/0x620 ? pfxrawspinlockirqsave+0x10/0x10 ? kasancompletemodereportinfo+0x72/0x210 kasanreport+0xe7/0x130 ? cephhandleauthreply+0x642/0x7a0 [libceph] ? cephhandleauthreply+0x642/0x7a0 [libceph] asanreportloadnnoabort+0xf/0x20 cephhandleauthreply+0x642/0x7a0 [libceph] mondispatch+0x973/0x23d0 [libceph] ? apparmorsocketrecvmsg+0x6b/0xa0 ? pfxmondispatch+0x10/0x10 [libceph] ? kasancheckwrite+0x14/0x30i ? mutexunlock+0x7f/0xd0 ? pfxmutexunlock+0x10/0x10 ? pfxdorecvmsg+0x10/0x10 [libceph] cephconprocessmessage+0x1f1/0x650 [libceph] processmessage+0x1e/0x450 [libceph] cephconv2tryread+0x2e48/0x6c80 [libceph] ? pfxcephconv2tryread+0x10/0x10 [libceph] ? savefpregstofpstate+0xb0/0x230 ? rawspinrqunlock+0x17/0xa0 ? finishtaskswitch.isra.0+0x13b/0x760 ? switchto+0x385/0xda0 ? kasancheckwrite+0x14/0x30 ? mutexlock+0x8d/0xe0 ? pfxmutexlock+0x10/0x10 cephconworkfn+0x248/0x10c0 [libceph] processonework+0x629/0xf80 ? kasancheckwrite+0x14/0x30 workerthread+0x87f/0x1570 ? pfxrawspinlockirqsave+0x10/0x10 ? pfxtrytowakeup+0x10/0x10 ? kasanprintaddressstackframe+0x1f7/0x280 ? pfxworkerthread+0x10/0x10 kthread+0x396/0x830 ? pfxrawspinlockirq+0x10/0x10 ? pfxkthread+0x10/0x10 ? kasancheckwrite+0x14/0x30 ? recalcsigpending+0x180/0x210 ? pfxkthread+0x10/0x10 retfromfork+0x3f7/0x610 ? pfxretfromfork+0x10/0x10 ? switchto+0x385/0xda0 ? pfxkthread+0x10/0x10 retfromforkasm+0x1a/0x30 </TASK>
[ idryomov: replace if statements with cephdecodeneed() for payloadlen and resultmsglen ]
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:
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:
rustbinder: avoid reading the written value in offsets array
When sending a transaction, its offsets array is first copied into the target proc's vma, and then the values are read back from there. This is normally fine because the vma is a read-only mapping, so the target process cannot change the value under us.
However, if the target process somehow gains the ability to write to its own vma, it could change the offset before it's read back, causing the kernel to misinterpret what the sender meant. If the sender happens to send a payload with a specific shape, this could in the worst case lead to the receiver being able to privilege escalate into the sender.
The intent is that gaining the ability to change the read-only vma of your own process should not be exploitable, so remove this TOCTOU read even though it's unexploitable without another Binder bug.
In the Linux kernel, the following vulnerability has been resolved:
rustbinder: check ownership before using vma
When installing missing pages (or zapping them), Rust Binder will look up the vma in the mm by address, and then call vminsertpage (or zappagerangesingle). However, if the vma is closed and replaced with a different vma at the same address, this can lead to Rust Binder installing pages into the wrong vma.
By installing the page into a writable vma, it becomes possible to write to your own binder pages, which are normally read-only. Although you're not supposed to be able to write to those pages, the intent behind the design of Rust Binder is that even if you get that ability, it should not lead to anything bad. Unfortunately, due to another bug, that is not the case.
To fix this, store a pointer in vmprivatedata and check that the vma returned by vmalookup() has the right vmops and vmprivatedata before trying to use the vma. This should ensure that Rust Binder will refuse to interact with any other VMA. The plan is to introduce more vma abstractions to avoid this unsafe access to vmops and vmprivatedata, but for now let's start with the simplest possible fix.
C Binder performs the same check in a slightly different way: it provides a vmops->close that sets a boolean to true, then checks that boolean after calling vmalookup(), but this is more fragile than the solution in this patch. (We probably still want to do both, but the vmops->close callback will be added later as part of the follow-up vma API changes.)
It's still possible to remap the vma so that pages appear in the right vma, but at the wrong offset, but this is a separate issue and will be fixed when Rust Binder gets a vmops->close callback.
In the Linux kernel, the following vulnerability has been resolved:
firmware: stratix10-rsu: Fix NULL pointer dereference when RSU is disabled
When the Remote System Update (RSU) isn't enabled in the First Stage Boot Loader (FSBL), the driver encounters a NULL pointer dereference when excute svcnormaltosecurethread() thread, resulting in a kernel panic:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 Mem abort info: ... Data abort info: ... [0000000000000008] user address but activemm is swapper Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: CPU: 0 UID: 0 PID: 79 Comm: svcsmchvcthr Not tainted 6.19.0-rc8-yocto-standard+ #59 PREEMPT Hardware name: SoCFPGA Stratix 10 SoCDK (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : svcnormaltosecurethread+0x38c/0x990 lr : svcnormaltosecurethread+0x144/0x990 ... Call trace: svcnormaltosecurethread+0x38c/0x990 (P) kthread+0x150/0x210 retfromfork+0x10/0x20 Code: 97cfc113 f9400260 aa1403e1 f9400400 (f9400402) ---[ end trace 0000000000000000 ]---
The issue occurs because rsusendasyncmsg() fails when RSU is not enabled in firmware, causing the channel to be freed via stratix10svcfreechannel(). However, the probe function continues execution and registers svcnormaltosecurethread(), which subsequently attempts to access the already-freed channel, triggering the NULL pointer dereference.
Fix this by properly cleaning up the async client and returning early on failure, preventing the thread from being used with an invalid channel.
In the Linux kernel, the following vulnerability has been resolved:
powerpc, perf: Check that current->mm is alive before getting user callchain
It may happen that mm is already released, which leads to kernel panic. This adds the NULL check for current->mm, similarly to commit 20afc60f892d ("x86, perf: Check that current->mm is alive before getting user callchain").
I was getting this panic when running a profiling BPF program (profile.py from bcc-tools):
[26215.051935] Kernel attempted to read user page (588) - exploit attempt? (uid: 0) [26215.051950] BUG: Kernel NULL pointer dereference on read at 0x00000588 [26215.051952] Faulting instruction address: 0xc00000000020fac0 [26215.051957] Oops: Kernel access of bad area, sig: 11 [#1] [...] [26215.052049] Call Trace: [26215.052050] [c000000061da6d30] [c00000000020fc10] perfcallchainuser64+0x2d0/0x490 (unreliable) [26215.052054] [c000000061da6dc0] [c00000000020f92c] perfcallchainuser+0x1c/0x30 [26215.052057] [c000000061da6de0] [c0000000005ab2a0] getperfcallchain+0x100/0x360 [26215.052063] [c000000061da6e70] [c000000000573bc8] bpfgetstackid+0x88/0xf0 [26215.052067] [c000000061da6ea0] [c008000000042258] bpfprog16d4ab9ab662f669doperfevent+0xf8/0x274 [...]
In addition, move storing the top-level stack entry to generic perfcallchainuser to make sure the top-evel entry is always captured, even if current->mm is NULL.
[Maddy: fixed message to avoid checkpatch format style error]
In the Linux kernel, the following vulnerability has been resolved:
scsi: ufs: core: Fix SError in ufshcdrtcwork() during UFS suspend
In ufshcdwlsuspend(), canceldelayedworksync() is called to cancel the UFS RTC work, but it is placed after ufshcdvopssuspend(hba, pmop, POSTCHANGE). This creates a race condition where ufshcdrtcwork() can still be running while ufshcdvopssuspend() is executing. When UFSHCDCAPCLKGATING is not supported, the condition !hba->clkgating.activereqs is always true, causing ufshcdupdatertc() to be executed. Since ufshcdvopssuspend() typically performs clock gating operations, executing ufshcdupdatertc() at that moment triggers an SError. The kernel panic trace is as follows:
Kernel panic - not syncing: Asynchronous SError Interrupt Call trace: dumpbacktrace+0xec/0x128 showstack+0x18/0x28 dumpstacklvl+0x40/0xa0 dumpstack+0x18/0x24 panic+0x148/0x374 nmipanic+0x3c/0x8c arm64serrorpanic+0x64/0x8c doserror+0xc4/0xc8 el1h64errorhandler+0x34/0x4c el1h64error+0x68/0x6c el1interrupt+0x20/0x58 el1h64irqhandler+0x18/0x24 el1h64irq+0x68/0x6c ktimeget+0xc4/0x12c ufshcdmcqsqstop+0x4c/0xec ufshcdmcqsqcleanup+0x64/0x1dc ufshcdclearcmd+0x38/0x134 ufshcdissuedevcmd+0x298/0x4d0 ufshcdexecdevcmd+0x1a4/0x1c4 ufshcdqueryattr+0xbc/0x19c ufshcdrtcwork+0x10c/0x1c8 processscheduledworks+0x1c4/0x45c workerthread+0x32c/0x3e8 kthread+0x120/0x1d8 retfromfork+0x10/0x20
Fix this by moving canceldelayedworksync() before the call to ufshcdvopssuspend(hba, pmop, PRECHANGE), ensuring the UFS RTC work is fully completed or cancelled at that point.
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:
net: mctp: fix device leak on probe failure
Driver core holds a reference to the USB interface and its parent USB device while the interface is bound to a driver and there is no need to take additional references unless the structures are needed after disconnect.
This driver takes a reference to the USB device during probe but does not to release it on probe failures.
Drop the redundant device reference to fix the leak, reduce cargo culting, make it easier to spot drivers where an extra reference is needed, and reduce the risk of further memory leaks.
In the Linux kernel, the following vulnerability has been resolved:
sched/mmcid: Handle vfork()/CLONEVM correctly
Matthieu and Jiri reported stalls where a task endlessly loops in mmgetcid() when scheduling in.
It turned out that the logic which handles vfork()'ed tasks is broken. It is invoked when the number of tasks associated to a process is smaller than the number of MMCID users. It then walks the task list to find the vfork()'ed task, but accounts all the already processed tasks as well.
If that double processing brings the number of to be handled tasks to 0, the walk stops and the vfork()'ed task's CID is not fixed up. As a consequence a subsequent schedule in fails to acquire a (transitional) CID and the machine stalls.
Cure this by removing the accounting condition and make the fixup always walk the full task list if it could not find the exact number of users in the process' thread list.
In the Linux kernel, the following vulnerability has been resolved:
kprobes: avoid crash when rmmod/insmod after ftrace killed
After we hit ftrace is killed by some errors, the kernel crash if we remove modules in which kprobe probes.
BUG: unable to handle page fault for address: fffffbfff805000d PGD 817fcc067 P4D 817fcc067 PUD 817fc8067 PMD 101555067 PTE 0 Oops: Oops: 0000 [#1] SMP KASAN PTI CPU: 4 UID: 0 PID: 2012 Comm: rmmod Tainted: G W OE Tainted: [W]=WARN, [O]=OOTMODULE, [E]=UNSIGNEDMODULE RIP: 0010:kprobesmodulecallback+0x89/0x790 RSP: 0018:ffff88812e157d30 EFLAGS: 00010a02 RAX: 1ffffffff805000d RBX: dffffc0000000000 RCX: ffffffff86a8de90 RDX: ffffed1025c2af9b RSI: 0000000000000008 RDI: ffffffffc0280068 RBP: 0000000000000000 R08: 0000000000000001 R09: ffffed1025c2af9a R10: ffff88812e157cd7 R11: 205d323130325420 R12: 0000000000000002 R13: ffffffffc0290488 R14: 0000000000000002 R15: ffffffffc0280040 FS: 00007fbc450dd740(0000) GS:ffff888420331000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: fffffbfff805000d CR3: 000000010f624000 CR4: 00000000000006f0 Call Trace: <TASK> notifiercallchain+0xc6/0x280 blockingnotifiercallchain+0x60/0x90 dosysdeletemodule.constprop.0+0x32a/0x4e0 dosyscall64+0x5d/0xfa0 entrySYSCALL64afterhwframe+0x76/0x7e
This is because the kprobe on ftrace does not correctly handles the kprobeftracedisabled flag set by ftracekill().
To prevent this error, check kprobeftracedisabled in disarmkprobeftrace() and skip all ftrace related operations.
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:
ceph: fix memory leaks in cephmdscbuildpath()
Add putname() calls to error code paths that did not free the "path" pointer obtained by getname(). If ownership of this pointer is not passed to the caller via pathinfo.path, the function must free it before returning.
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: RX, Fix XDP multi-buf frag counting for legacy RQ
XDP multi-buf programs can modify the layout of the XDP buffer when the program calls bpfxdppulldata() or bpfxdpadjusttail(). The referenced commit in the fixes tag corrected the assumption in the mlx5 driver that the XDP buffer layout doesn't change during a program execution. However, this fix introduced another issue: the dropped fragments still need to be counted on the driver side to avoid page fragment reference counting issues.
Such issue can be observed with the testxdpnativeadjsttailshrnkdata selftest when using a payload of 3600 and shrinking by 256 bytes (an upcoming selftest patch): the last fragment gets released by the XDP code but doesn't get tracked by the driver. This results in a negative pprefcount during page release and the following splat:
WARNING: include/net/pagepool/helpers.h:297 at mlx5epagereleasefragmented.isra.0+0x4a/0x50 [mlx5core], CPU#12: ip/3137 Modules linked in: [...] CPU: 12 UID: 0 PID: 3137 Comm: ip Not tainted 6.19.0-rc3+ #12 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:mlx5epagereleasefragmented.isra.0+0x4a/0x50 [mlx5core] [...] Call Trace: <TASK> mlx5edeallocrxwqe+0xcb/0x1a0 [mlx5core] mlx5efreerxdescs+0x7f/0x110 [mlx5core] mlx5ecloserq+0x50/0x60 [mlx5core] mlx5eclosequeues+0x36/0x2c0 [mlx5core] mlx5eclosechannel+0x1c/0x50 [mlx5core] mlx5eclosechannels+0x45/0x80 [mlx5core] mlx5esafeswitchparams+0x1a5/0x230 [mlx5core] mlx5echangemtu+0xf3/0x2f0 [mlx5core] netifsetmtuext+0xf1/0x230 dosetlink.isra.0+0x219/0x1180 rtnlnewlink+0x79f/0xb60 rtnetlinkrcvmsg+0x213/0x3a0 netlinkrcvskb+0x48/0xf0 netlinkunicast+0x24a/0x350 netlinksendmsg+0x1ee/0x410 socksendmsg+0x38/0x60 syssendmsg+0x232/0x280 syssendmsg+0x78/0xb0 syssendmsg+0x5f/0xb0 [...] dosyscall64+0x57/0xc50
This patch fixes the issue by doing page frag counting on all the original XDP buffer fragments for all relevant XDP actions (XDPTX , XDPREDIRECT and XDPPASS). This is basically reverting to the original counting before the commit in the fixes tag.
As fragpage is still pointing to the original tail, the nrfrags parameter to xdpupdateskbfragsinfo() needs to be calculated in a different way to reflect the new nrfrags.
In the Linux kernel, the following vulnerability has been resolved:
net: spacemit: Fix error handling in emactxmemmap()
The DMA mappings were leaked on mapping error. Free them with the existing emacfreetxbuf() function.
In the Linux kernel, the following vulnerability has been resolved:
spi: amlogic: spifc-a4: Fix DMA mapping error handling
Fix three bugs in amlsfcdmabuffersetup() error paths: 1. Unnecessary goto: When the first DMA mapping (sfc->daddr) fails, nothing needs cleanup. Use direct return instead of goto. 2. Double-unmap bug: When info DMA mapping failed, the code would unmap sfc->daddr inline, then fall through to outmapdata which would unmap it again, causing a double-unmap. 3. Wrong unmap size: The outmapinfo label used datalen instead of infolen when unmapping sfc->iaddr, which could lead to incorrect DMA sync behavior.
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:
btrfs: add missing RCU unlock in error path in tryreleasesubpageextentbuffer()
Call rcureadlock() before exiting the loop in tryreleasesubpageextentbuffer() because there is a rcureadunlock() call past the loop.
This has been detected by the Clang thread-safety analyzer.
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix transaction abort when snapshotting received subvolumes
Currently a user can trigger a transaction abort by snapshotting a previously received snapshot a bunch of times until we reach a BTRFSUUIDKEYRECEIVEDSUBVOL item overflow (the maximum item size we can store in a leaf). This is very likely not common in practice, but if it happens, it turns the filesystem into RO mode. The snapshot, send and setreceivedsubvol and subvolsetflags (used by receive) don't require CAPSYSADMIN, just inodeownerorcapable(). A malicious user could use this to turn a filesystem into RO mode and disrupt a system.
Reproducer script:
$ cat test.sh #!/bin/bash
DEV=/dev/sdi MNT=/mnt/sdi
# Use smallest node size to make the test faster. mkfs.btrfs -f --nodesize 4K $DEV mount $DEV $MNT
# Create a subvolume and set it to RO so that it can be used for send. btrfs subvolume create $MNT/sv touch $MNT/sv/foo btrfs property set $MNT/sv ro true
# Send and receive the subvolume into snaps/sv. mkdir $MNT/snaps btrfs send $MNT/sv | btrfs receive $MNT/snaps
# Now snapshot the received subvolume, which has a receiveduuid, a # lot of times to trigger the leaf overflow. total=500 for ((i = 1; i <= $total; i++)); do echo -ne "\rCreating snapshot $i/$total" btrfs subvolume snapshot -r $MNT/snaps/sv $MNT/snaps/sv$i > /dev/null done echo
umount $MNT
When running the test:
$ ./test.sh (...) Create subvolume '/mnt/sdi/sv' At subvol /mnt/sdi/sv At subvol sv Creating snapshot 496/500ERROR: Could not create subvolume: Value too large for defined data type Creating snapshot 497/500ERROR: Could not create subvolume: Read-only file system Creating snapshot 498/500ERROR: Could not create subvolume: Read-only file system Creating snapshot 499/500ERROR: Could not create subvolume: Read-only file system Creating snapshot 500/500ERROR: Could not create subvolume: Read-only file system
And in dmesg/syslog:
$ dmesg (...) [251067.627338] BTRFS warning (device sdi): insert uuid item failed -75 (0x4628b21c4ac8d898, 0x2598bee2b1515c91) type 252! [251067.629212] ------------[ cut here ]------------ [251067.630033] BTRFS: Transaction aborted (error -75) [251067.630871] WARNING: fs/btrfs/transaction.c:1907 at creatependingsnapshot.cold+0x52/0x465 [btrfs], CPU#10: btrfs/615235 [251067.632851] Modules linked in: btrfs dmzero (...) [251067.644071] CPU: 10 UID: 0 PID: 615235 Comm: btrfs Tainted: G W 6.19.0-rc8-btrfs-next-225+ #1 PREEMPT(full) [251067.646165] Tainted: [W]=WARN [251067.646733] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 [251067.648735] RIP: 0010:creatependingsnapshot.cold+0x55/0x465 [btrfs] [251067.649984] Code: f0 48 0f (...) [251067.653313] RSP: 0018:ffffce644908fae8 EFLAGS: 00010292 [251067.653987] RAX: 00000000ffffff01 RBX: ffff8e5639e63a80 RCX: 00000000ffffffd3 [251067.655042] RDX: ffff8e53faa76b00 RSI: 00000000ffffffb5 RDI: ffffffffc0919750 [251067.656077] RBP: ffffce644908fbd8 R08: 0000000000000000 R09: ffffce644908f820 [251067.657068] R10: ffff8e5adc1fffa8 R11: 0000000000000003 R12: ffff8e53c0431bd0 [251067.658050] R13: ffff8e5414593600 R14: ffff8e55efafd000 R15: 00000000ffffffb5 [251067.659019] FS: 00007f2a4944b3c0(0000) GS:ffff8e5b27dae000(0000) knlGS:0000000000000000 [251067.660115] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [251067.660943] CR2: 00007ffc5aa57898 CR3: 00000005813a2003 CR4: 0000000000370ef0 [251067.661972] Call Trace: [251067.662292] <TASK> [251067.662653] creatependingsnapshots+0x97/0xc0 [btrfs] [251067.663413] btrfscommittransaction+0x26e/0xc00 [btrfs] [251067.664257] ? btrfsqgroupconvertreservedmeta+0x35/0x390 [btrfs] [251067.665238] ? rawspinunlock+0x15/0x30 [251067.665837] ? recordroot ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
net: dsa: microchip: Fix error path in PTP IRQ setup
If requestthreadedirq() fails during the PTP message IRQ setup, the newly created IRQ mapping is never disposed. Indeed, the kszptpirqsetup()'s error path only frees the mappings that were successfully set up.
Dispose the newly created mapping if the associated requestthreadedirq() fails at setup.
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:
spi: rockchip-sfc: Fix double-free in remove() callback
The driver uses devmspiregistercontroller() for registration, which automatically unregisters the controller via devm cleanup when the device is removed. The manual call to spiunregistercontroller() in the remove() callback can lead to a double-free.
And to make sure controller is unregistered before DMA buffer is unmapped, switch to use spiregistercontroller() in probe().
In the Linux kernel, the following vulnerability has been resolved:
i3c: mipi-i3c-hci: Fix race in DMA ring dequeue
The HCI DMA dequeue path (hcidmadequeuexfer()) may be invoked for multiple transfers that timeout around the same time. However, the function is not serialized and can race with itself.
When a timeout occurs, hcidmadequeuexfer() stops the ring, processes incomplete transfers, and then restarts the ring. If another timeout triggers a parallel call into the same function, the two instances may interfere with each other - stopping or restarting the ring at unexpected times.
Add a mutex so that hcidmadequeuexfer() is serialized with respect to itself.
In the Linux kernel, the following vulnerability has been resolved:
net: ipa: fix event ring index not programmed for IPA v5.0+
For IPA v5.0+, the event ring index field moved from CHCCNTXT0 to CHCCNTXT1. The v5.0 register definition intended to define this field in the CHCCNTXT1 fmask array but used the old identifier of ERINDEX instead of CHERINDEX.
Without a valid event ring, GSI channels could never signal transfer completions. This caused gsichanneltransquiesce() to block forever in waitforcompletion().
At least for IPA v5.2 this resolves an issue seen where runtime suspend, system suspend, and remoteproc stop all hanged forever. It also meant the IPA data path was completely non functional.
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:
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:
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.