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

fwctl: Fix class init ordering to avoid NULL pointer dereference on device removal

CXL is linked before fwctl in drivers/Makefile. Both use moduleinit, so cxlpcidriverinit() runs first. When cxlpciprobe() calls fwctlregister() and then deviceadd(), fwctlclass is not yet registered because fwctlinit() hasn't run, causing classtosubsys() to return NULL and skip knodeclass initialization.

On device removal, classtosubsys() returns non-NULL, and devicedel() calls klistdel() on the uninitialized knode, triggering a NULL pointer dereference.

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

wifi: rsi: fix kthread lifetime race between self-exit and external-stop

RSI driver use both self-exit(kthreadcompleteandexit) and external-stop (kthreadstop) when killing a kthread. Generally, kthreadstop() is called first, and in this case, no particular issues occur.

However, in rare instances where kthreadcompleteandexit() is called first and then kthreadstop() is called, a UAF occurs because the kthread object, which has already exited and been freed, is accessed again.

Therefore, to prevent this with minimal modification, you must remove kthreadstop() and change the code to wait until the self-exit operation is completed.

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

usb: cdns3: fix role switching during resume

If the role change while we are suspended, the cdns3 driver switches to the new mode during resume. However, switching to host mode in this context causes a NULL pointer dereference.

The host role's start() operation registers a xhci-hcd device, but its probe is deferred while we are in the resume path. The host role's resume() operation assumes the xhci-hcd device is already probed, which is not the case, leading to the dereference. Since the start() operation of the new role is already called, the resume operation can be skipped.

So skip the resume operation for the new role if a role switch occurs during resume. Once the resume sequence is complete, the xhci-hcd device can be probed in case of host mode.

Unable to handle kernel NULL pointer dereference at virtual address 0000000000000208 Mem abort info: ... Data abort info: ... [0000000000000208] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: CPU: 0 UID: 0 PID: 146 Comm: sh Not tainted 6.19.0-rc7-00013-g6e64f4aabfae-dirty #135 PREEMPT Hardware name: Texas Instruments J7200 EVM (DT) pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usbhcdisprimaryhcd+0x0/0x1c lr : cdnshostresume+0x24/0x5c ... Call trace: usbhcdisprimaryhcd+0x0/0x1c (P) cdnsresume+0x6c/0xbc cdns3controllerresume.isra.0+0xe8/0x17c cdns3platresume+0x18/0x24 platformpmresume+0x2c/0x68 dpmruncallback+0x90/0x248 deviceresume+0x100/0x24c dpmresume+0x190/0x2ec dpmresumeend+0x18/0x34 suspenddevicesandenter+0x2b0/0xa44 pmsuspend+0x16c/0x5fc statestore+0x80/0xec kobjattrstore+0x18/0x2c sysfskfwrite+0x7c/0x94 kernfsfopwriteiter+0x130/0x1dc vfswrite+0x240/0x370 ksyswrite+0x70/0x108 arm64syswrite+0x1c/0x28 invokesyscall+0x48/0x10c el0svccommon.constprop.0+0x40/0xe0 doel0svc+0x1c/0x28 el0svc+0x34/0x108 el0t64synchandler+0xa0/0xe4 el0t64sync+0x198/0x19c Code: 52800003 f9407ca5 d63f00a0 17ffffe4 (f9410401) ---[ end trace 0000000000000000 ]---

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

net: remove WARNONONCE when accessing forward path array

Although unlikely, recent support for IPIP tunnels increases chances of reaching this WARNONONCE if userspace manages to build a sufficiently long forward path.

Remove it.

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---

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:

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:

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:

serial: 8250: Fix TX deadlock when using DMA

dmaengineterminateasync does not guarantee that the dmatxcomplete callback will run. The callback is currently the only place where dma->txrunning gets cleared. If the transaction is canceled and the callback never runs, then dma->txrunning will never get cleared and we will never schedule new TX DMA transactions again.

This change makes it so we clear dma->txrunning after we terminate the DMA transaction. This is "safe" because serial8250txdmaflush is holding the UART port lock. The first thing the callback does is also grab the UART port lock, so access to dma->txrunning is serialized.

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

bpf: Fix constant blinding for PROBEMEM32 stores

BPFST | BPFPROBEMEM32 immediate stores are not handled by bpfjitblindinsn(), allowing user-controlled 32-bit immediates to survive unblinded into JIT-compiled native code when bpfjitharden >= 1.

The root cause is that convertctxaccesses() rewrites BPFST|BPFMEM to BPFST|BPFPROBEMEM32 for arena pointer stores during verification, before bpfjitblindconstants() runs during JIT compilation. The blinding switch only matches BPFST|BPFMEM (mode 0x60), not BPFST|BPFPROBEMEM32 (mode 0xa0). The instruction falls through unblinded.

Add BPFST|BPFPROBEMEM32 cases to bpfjitblindinsn() alongside the existing BPFST|BPFMEM cases. The blinding transformation is identical: load the blinded immediate into BPFREGAX via mov+xor, then convert the immediate store to a register store (BPFSTX).

The rewritten STX instruction must preserve the BPFPROBEMEM32 mode so the architecture JIT emits the correct arena addressing (R12-based on x86-64). Cannot use the BPFSTXMEM() macro here because it hardcodes BPFMEM mode; construct the instruction directly instead.

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

ice: Fix NULL pointer dereference in icevsisetnapiqueues

Add NULL pointer checks in icevsisetnapiqueues() to prevent crashes during resume from suspend when rings[qidx]->qvector is NULL.

Tested adaptor: 60:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller E810-XXV for SFP [8086:159b] (rev 02) Subsystem: Intel Corporation Ethernet Network Adapter E810-XXV-2 [8086:4003]

SR-IOV state: both disabled and enabled can reproduce this issue.

kernel version: v6.18

Reproduce steps: Boot up and execute suspend like systemctl suspend or rtcwake.

Log: <1>[ 231.443607] BUG: kernel NULL pointer dereference, address: 0000000000000040 <1>[ 231.444052] #PF: supervisor read access in kernel mode <1>[ 231.444484] #PF: errorcode(0x0000) - not-present page <6>[ 231.444913] PGD 0 P4D 0 <4>[ 231.445342] Oops: Oops: 0000 [#1] SMP NOPTI <4>[ 231.446635] RIP: 0010:netifqueuesetnapi+0xa/0x170 <4>[ 231.447067] Code: 31 f6 31 ff c3 cc cc cc cc 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 48 85 c9 74 0b <48> 83 79 30 00 0f 84 39 01 00 00 55 41 89 d1 49 89 f8 89 f2 48 89 <4>[ 231.447513] RSP: 0018:ffffcc780fc078c0 EFLAGS: 00010202 <4>[ 231.447961] RAX: ffff8b848ca30400 RBX: ffff8b848caf2028 RCX: 0000000000000010 <4>[ 231.448443] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8b848dbd4000 <4>[ 231.448896] RBP: ffffcc780fc078e8 R08: 0000000000000000 R09: 0000000000000000 <4>[ 231.449345] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 <4>[ 231.449817] R13: ffff8b848dbd4000 R14: ffff8b84833390c8 R15: 0000000000000000 <4>[ 231.450265] FS: 00007c7b29e9d740(0000) GS:ffff8b8c068e2000(0000) knlGS:0000000000000000 <4>[ 231.450715] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4>[ 231.451179] CR2: 0000000000000040 CR3: 000000030626f004 CR4: 0000000000f72ef0 <4>[ 231.451629] PKRU: 55555554 <4>[ 231.452076] Call Trace: <4>[ 231.452549] <TASK> <4>[ 231.452996] ? icevsisetnapiqueues+0x4d/0x110 [ice] <4>[ 231.453482] iceresume+0xfd/0x220 [ice] <4>[ 231.453977] ? pfxpcipmresume+0x10/0x10 <4>[ 231.454425] pcipmresume+0x8c/0x140 <4>[ 231.454872] ? pfxpcipmresume+0x10/0x10 <4>[ 231.455347] dpmruncallback+0x5f/0x160 <4>[ 231.455796] ? dpmwaitforsuperior+0x107/0x170 <4>[ 231.456244] deviceresume+0x177/0x270 <4>[ 231.456708] dpmresume+0x209/0x2f0 <4>[ 231.457151] dpmresumeend+0x15/0x30 <4>[ 231.457596] suspenddevicesandenter+0x1da/0x2b0 <4>[ 231.458054] enterstate+0x10e/0x570

Add defensive checks for both the ring pointer and its qvector before dereferencing, allowing the system to resume successfully even when qvectors are unmapped.

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

net: 3com: 3c59x: fix possible null dereference in vortexprobe1()

pdev can be null and freering: can be called in 1297 with a null pdev.

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

mptcp: Use skdstget() and dstdevrcu() in mptcpactiveenable().

mptcpactiveenable() is called from subflowfinishconnect(), which is icsk->icskafops->skrxdstset() and it's not always under RCU.

Using skdstget(sk)->dev could trigger UAF.

Let's use skdstget() and dstdevrcu().

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

KVM: nSVM: Check instead of asserting on nested TSC scaling support

Check for nested TSC scaling support on nested SVM VMRUN instead of asserting that TSC scaling is exposed to L1 if L1's MSRAMD64TSCRATIO has diverged from KVM's default. Userspace can trigger the WARN at will by writing the MSR and then updating guest CPUID to hide the feature (modifying guest CPUID is allowed anytime before KVMRUN). E.g. hacking KVM's statetest selftest to do

vcpusetmsr(vcpu, MSRAMD64TSCRATIO, 0); vcpuclearcpuidfeature(vcpu, X86FEATURETSCRATEMSR);

after restoring state in a new VM+vCPU yields an endless supply of:

------------[ cut here ]------------ WARNING: CPU: 164 PID: 62565 at arch/x86/kvm/svm/nested.c:699 nestedvmcb02preparecontrol+0x3d6/0x3f0 [kvmamd] Call Trace: <TASK> entersvmguestmode+0x114/0x560 [kvmamd] nestedsvmvmrun+0x260/0x330 [kvmamd] vmruninterception+0x29/0x30 [kvmamd] svminvokeexithandler+0x35/0x100 [kvmamd] svmhandleexit+0xe7/0x180 [kvmamd] kvmarchvcpuioctlrun+0x1eab/0x2570 [kvm] kvmvcpuioctl+0x4c9/0x5b0 [kvm] sesysioctl+0x7a/0xc0 x64sysioctl+0x21/0x30 dosyscall64+0x41/0x90 entrySYSCALL64afterhwframe+0x63/0xcd RIP: 0033:0x45ca1b

Note, the nested #VMEXIT path has the same flaw, but needs a different fix and will be handled separately.

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

bpf, arm64: Fixed a BTI error on returning to patched function

When BPFTRAMPFCALLORIG is set, BPF trampoline uses BLR to jump back to the instruction next to call site to call the patched function. For BTI-enabled kernel, the instruction next to call site is usually PACIASP, in this case, it's safe to jump back with BLR. But when the call site is not followed by a PACIASP or bti, a BTI exception is triggered.

Here is a fault log:

Unhandled 64-bit el1h sync exception on CPU0, ESR 0x0000000034000002 -- BTI CPU: 0 PID: 263 Comm: testprogs Tainted: GF Hardware name: linux,dummy-virt (DT) pstate: 40400805 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=-c) pc : bpffentrytest1+0xc/0x30 lr : bpftrampoline64425738920+0x48/0x1000 sp : ffff80000c0c3a50 x29: ffff80000c0c3a90 x28: ffff0000c2e6c080 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000050 x23: 0000000000000000 x22: 0000ffffcfd2a7f0 x21: 000000000000000a x20: 0000ffffcfd2a7f0 x19: 0000000000000000 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000ffffcfd2a7f0 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: ffff80000914f5e4 x9 : ffff8000082a1528 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0101010101010101 x5 : 0000000000000000 x4 : 00000000fffffff2 x3 : 0000000000000001 x2 : ffff8001f4b82000 x1 : 0000000000000000 x0 : 0000000000000001 Kernel panic - not syncing: Unhandled exception CPU: 0 PID: 263 Comm: testprogs Tainted: GF Hardware name: linux,dummy-virt (DT) Call trace: dumpbacktrace+0xec/0x144 showstack+0x24/0x7c dumpstacklvl+0x8c/0xb8 dumpstack+0x18/0x34 panic+0x1cc/0x3ec el0errorhandlercommon+0x0/0x130 el1h64synchandler+0x60/0xd0 el1h64sync+0x78/0x7c bpffentrytest1+0xc/0x30 bpffentrytest1+0xc/0x30 bpfprogtestruntracing+0xdc/0x2a0 sysbpf+0x438/0x22a0 arm64sysbpf+0x30/0x54 invokesyscall+0x78/0x110 el0svccommon.constprop.0+0x6c/0x1d0 doel0svc+0x38/0xe0 el0svc+0x30/0xd0 el0t64synchandler+0x1ac/0x1b0 el0t64sync+0x1a0/0x1a4 Kernel Offset: disabled CPU features: 0x0000,00034c24,f994fdab Memory Limit: none

And the instruction next to call site of bpffentrytest1 is ADD, not PACIASP:

<bpffentrytest1>: bti c nop nop add w0, w0, #0x1 paciasp

For BPF prog, JIT always puts a PACIASP after call site for BTI-enabled kernel, so there is no problem. To fix it, replace BLR with RET to bypass the branch target check.

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

ipmisi: fix a memleak in trysmiinit()

Kmemleak reported the following leak info in trysmiinit():

unreferenced object 0xffff00018ecf9400 (size 1024): comm "modprobe", pid 2707763, jiffies 4300851415 (age 773.308s) backtrace: [<000000004ca5b312>] kmalloc+0x4b8/0x7b0 [<00000000953b1072>] trysmiinit+0x148/0x5dc [ipmisi] [<000000006460d325>] 0xffff800081b10148 [<0000000039206ea5>] dooneinitcall+0x64/0x2a4 [<00000000601399ce>] doinitmodule+0x50/0x300 [<000000003c12ba3c>] loadmodule+0x7a8/0x9e0 [<00000000c246fffe>] sesysinitmodule+0x104/0x180 [<00000000eea99093>] arm64sysinitmodule+0x24/0x30 [<0000000021b1ef87>] el0svccommon.constprop.0+0x94/0x250 [<0000000070f4f8b7>] doel0svc+0x48/0xe0 [<000000005a05337f>] el0svc+0x24/0x3c [<000000005eb248d6>] el0synchandler+0x160/0x164 [<0000000030a59039>] el0sync+0x160/0x180

The problem was that when an error occurred before handlers registration and after allocating newsmi->sism, the variable wouldn't be freed in the error handling afterwards since shutdownsmi() hadn't been registered yet. Fix it by adding a kfree() in the error handling path in trysmiinit().

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

sctp: add a refcnt in sctpstreampriorities to avoid a nested loop

With this refcnt added in sctpstreampriorities, we don't need to traverse all streams to check if the prio is used by other streams when freeing one stream's prio in sctpschedpriofreesid(). This can avoid a nested loop (up to 65535 65535), which may cause a stuck as Ying reported:

watchdog: BUG: soft lockup - CPU#23 stuck for 26s! [ksoftirqd/23:136] Call Trace: <TASK> sctpschedpriofreesid+0xab/0x100 [sctp] sctpstreamfreeext+0x64/0xa0 [sctp] sctpstreamfree+0x31/0x50 [sctp] sctpassociationfree+0xa5/0x200 [sctp]

Note that it doesn't need to use refcountt type for this counter, as its accessing is always protected under the sock lock.

v1->v2: - add a check in sctpschedprioset to avoid the possible priohead refcnt overflow.

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

xen/gntdev: Accommodate VMA splitting

Prior to this commit, the gntdev driver code did not handle the following scenario correctly with paravirtualized (PV) Xen domains:

User process sets up a gntdev mapping composed of two grant mappings (i.e., two pages shared by another Xen domain). User process munmap()s one of the pages. User process munmap()s the remaining page. User process exits.

In the scenario above, the user process would cause the kernel to log the following messages in dmesg for the first munmap(), and the second munmap() call would result in similar log messages:

BUG: Bad page map in process doublemap.test pte:... pmd:... page:0000000057c97bff refcount:1 mapcount:-1 \ mapping:0000000000000000 index:0x0 pfn:... ... page dumped because: bad pte ... file:gntdev fault:0x0 mmap:gntdevmmap [xengntdev] readpage:0x0 ... Call Trace: <TASK> dumpstacklvl+0x46/0x5e printbadpte.cold+0x66/0xb6 unmappagerange+0x7e5/0xdc0 unmapvmas+0x78/0xf0 unmapregion+0xa8/0x110 domunmap+0x1ea/0x4e0 vmmunmap+0x75/0x120 x64sysmunmap+0x28/0x40 dosyscall64+0x38/0x90 entrySYSCALL64afterhwframe+0x61/0xcb ...

For each munmap() call, the Xen hypervisor (if built with CONFIGDEBUG) would print out the following and trigger a general protection fault in the affected Xen PV domain:

(XEN) d0v... Attempt to implicitly unmap d0's grant PTE ... (XEN) d0v... Attempt to implicitly unmap d0's grant PTE ...

As of this writing, gntdevgrantmap structure's vma field (referred to as map->vma below) is mainly used for checking the start and end addresses of mappings. However, with split VMAs, these may change, and there could be more than one VMA associated with a gntdev mapping. Hence, remove the use of map->vma and rely on map->pagesvmstart for the original start address and on (map->count << PAGESHIFT) for the original mapping size. Let the invalidate() and findspecialpage() hooks use these.

Also, given that there can be multiple VMAs associated with a gntdev mapping, move the "mmuintervalnotifierremove(&map->notifier)" call to the end of gntdevputmap, so that the MMU notifier is only removed after the closing of the last remaining VMA.

Finally, use an atomic to prevent inadvertent gntdev mapping re-use, instead of using the map->livegrants atomic counter and/or the map->vma pointer (the latter of which is now removed). This prevents the userspace from mmap()'ing (with MAPFIXED) a gntdev mapping over the same address range as a previously set up gntdev mapping. This scenario can be summarized with the following call-trace, which was valid prior to this commit:

mmap gntdevmmap mmap (repeat mmap with MAPFIXED over the same address range) gntdevinvalidate unmapgrantpages (sets 'beingremoved' entries to true) gnttabunmaprefsasync unmapsinglevma gntdevmmap (maps the shared pages again) munmap gntdevinvalidate unmapgrantpages (no-op because 'beingremoved' entries are true) unmapsinglevma (For PV domains, Xen reports that a granted page is being unmapped and triggers a general protection fault in the affected domain, if Xen was built with CONFIGDEBUG)

The fix for this last scenario could be worth its own commit, but we opted for a single commit, because removing the gntdevgrantmap structure's vma field requires guarding the entry to gntdevmmap(), and the livegrants atomic counter is not sufficient on its own to prevent the mmap() over a pre-existing mapping.

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

eth: mlx4: Fix ISERR() vs NULL check bug in mlx4encreaterxring

Replace NULL check with ISERR() check after calling pagepoolcreate() since this function returns error pointers (ERRPTR). Using NULL check could lead to invalid pointer dereference.

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

btrfs: fix BUGON condition in btrfscancelbalance

Pausing and canceling balance can race to interrupt balance lead to BUGON panic in btrfscancelbalance. The BUGON condition in btrfscancelbalance does not take this race scenario into account.

However, the race condition has no other side effects. We can fix that.

Reproducing it with panic trace like this:

kernel BUG at fs/btrfs/volumes.c:4618! RIP: 0010:btrfscancelbalance+0x5cf/0x6a0 Call Trace: <TASK> ? donanosleep+0x60/0x120 ? hrtimernanosleep+0xb7/0x1a0 ? schedcoreclonecookie+0x70/0x70 btrfsioctlbalancectl+0x55/0x70 btrfsioctl+0xa46/0xd20 x64sysioctl+0x7d/0xa0 dosyscall64+0x38/0x80 entrySYSCALL64afterhwframe+0x63/0xcd

Race scenario as follows: > mutexunlock(&fsinfo->balancemutex); > -------------------- > .......issue pause and cancel req in another thread > -------------------- > ret = btrfsbalance(fsinfo); > > mutexlock(&fsinfo->balancemutex); > if (ret == -ECANCELED && atomicread(&fsinfo->balancepausereq)) { > btrfsinfo(fsinfo, "balance: paused"); > btrfsexclopbalance(fsinfo, BTRFSEXCLOPBALANCEPAUSED); > }

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

net: sched: sfb: fix null pointer access issue when sfbinit() fails

When the default qdisc is sfb, if the qdisc of devqueue fails to be inited during mqprioinit(), sfbreset() is invoked to clear resources. In this case, the q->qdisc is NULL, and it will cause gpf issue.

The process is as follows: qdisccreatedflt() sfbinit() tcfblockget() --->failed, q->qdisc is NULL ... qdiscput() ... sfbreset() qdiscreset(q->qdisc) --->q->qdisc is NULL ops = qdisc->ops

The following is the Call Trace information: general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] RIP: 0010:qdiscreset+0x2b/0x6f0 Call Trace: <TASK> sfbreset+0x37/0xd0 qdiscreset+0xed/0x6f0 qdiscdestroy+0x82/0x4c0 qdiscput+0x9e/0xb0 qdisccreatedflt+0x2c3/0x4a0 mqprioinit+0xa71/0x1760 qdisccreate+0x3eb/0x1000 tcmodifyqdisc+0x408/0x1720 rtnetlinkrcvmsg+0x38e/0xac0 netlinkrcvskb+0x12d/0x3a0 netlinkunicast+0x4a2/0x740 netlinksendmsg+0x826/0xcc0 socksendmsg+0xc5/0x100 syssendmsg+0x583/0x690 syssendmsg+0xe8/0x160 syssendmsg+0xbf/0x160 dosyscall64+0x35/0x80 entrySYSCALL64afterhwframe+0x46/0xb0 RIP: 0033:0x7f2164122d04 </TASK>

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

netfilter: nftsetrbtree: fix overlap expiration walk

The lazy gc on insert that should remove timed-out entries fails to release the other half of the interval, if any.

Can be reproduced with tests/shell/testcases/sets/0044intervaloverlap0 in nftables.git and kmemleak enabled kernel.

Second bug is the use of rbeprev vs. prev pointer. If rbeprev() returns NULL after at least one iteration, rbeprev points to element that is not an end interval, hence it should not be removed.

Lastly, check the genmask of the end interval if this is active in the current generation.

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

drm/msm/dpu: check for null return of devmkzalloc() in dpuwritebackinit()

Because of the possilble failure of devmkzalloc(), dpuwbconn might be NULL and will cause null pointer dereference later.

Therefore, it might be better to check it and directly return -ENOMEM.

Patchwork: https://patchwork.freedesktop.org/patch/512277/ [DB: fixed typo in commit message]

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

net: do not sense pfmemalloc status in skbappendpagefrags()

skbappendpagefrags() is used by afunix and udp sendpage() implementation so far.

In commit 326140063946 ("tcp: TX zerocopy should not sense pfmemalloc status") we explained why we should not sense pfmemalloc status for pages owned by user space.

We should also use skbfillpagedescnoacc() in skbappendpagefrags() to avoid following KCSAN report:

BUG: KCSAN: data-race in lruaddfn / skbappendpagefrags

write to 0xffffea00058fc1c8 of 8 bytes by task 17319 on cpu 0: listadd include/linux/list.h:73 [inline] listadd include/linux/list.h:88 [inline] lruvecaddfolio include/linux/mminline.h:323 [inline] lruaddfn+0x327/0x410 mm/swap.c:228 foliobatchmovelru+0x1e1/0x2a0 mm/swap.c:246 lruadddraincpu+0x73/0x250 mm/swap.c:669 lruadddrain+0x21/0x60 mm/swap.c:773 freepagesandswapcache+0x16/0x70 mm/swapstate.c:311 tlbbatchpagesflush mm/mmugather.c:59 [inline] tlbflushmmufree mm/mmugather.c:256 [inline] tlbflushmmu+0x5b2/0x640 mm/mmugather.c:263 tlbfinishmmu+0x86/0x100 mm/mmugather.c:363 exitmmap+0x190/0x4d0 mm/mmap.c:3098 mmput+0x27/0x1b0 kernel/fork.c:1185 mmput+0x3d/0x50 kernel/fork.c:1207 copyprocess+0x19fc/0x2100 kernel/fork.c:2518 kernelclone+0x166/0x550 kernel/fork.c:2671 dosysclone kernel/fork.c:2812 [inline] sesysclone kernel/fork.c:2796 [inline] x64sysclone+0xc3/0xf0 kernel/fork.c:2796 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x2b/0x70 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x63/0xcd

read to 0xffffea00058fc1c8 of 8 bytes by task 17325 on cpu 1: pageispfmemalloc include/linux/mm.h:1817 [inline] skbfillpagedesc include/linux/skbuff.h:2432 [inline] skbfillpagedesc include/linux/skbuff.h:2453 [inline] skbappendpagefrags+0x210/0x600 net/core/skbuff.c:3974 unixstreamsendpage+0x45e/0x990 net/unix/afunix.c:2338 kernelsendpage+0x184/0x300 net/socket.c:3561 socksendpage+0x5a/0x70 net/socket.c:1054 pipetosendpage+0x128/0x160 fs/splice.c:361 splicefrompipefeed fs/splice.c:415 [inline] splicefrompipe+0x222/0x4d0 fs/splice.c:559 splicefrompipe fs/splice.c:594 [inline] genericsplicesendpage+0x89/0xc0 fs/splice.c:743 dosplicefrom fs/splice.c:764 [inline] directspliceactor+0x80/0xa0 fs/splice.c:931 splicedirecttoactor+0x305/0x620 fs/splice.c:886 dosplicedirect+0xfb/0x180 fs/splice.c:974 dosendfile+0x3bf/0x910 fs/readwrite.c:1255 dosyssendfile64 fs/readwrite.c:1323 [inline] sesyssendfile64 fs/readwrite.c:1309 [inline] x64syssendfile64+0x10c/0x150 fs/readwrite.c:1309 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x2b/0x70 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x63/0xcd

value changed: 0x0000000000000000 -> 0xffffea00058fc188

Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 17325 Comm: syz-executor.0 Not tainted 6.1.0-rc1-syzkaller-00158-g440b7895c990-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/11/2022

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

mtd: core: fix possible resource leak in initmtd()

I got the error report while inject fault in initmtd():

sysfs: cannot create duplicate filename '/devices/virtual/bdi/mtd-0' Call Trace: <TASK> dumpstacklvl+0x67/0x83 sysfswarndup+0x60/0x70 sysfscreatedirns+0x109/0x120 kobjectaddinternal+0xce/0x2f0 kobjectadd+0x98/0x110 deviceadd+0x179/0xc00 devicecreategroupsvargs+0xf4/0x100 devicecreate+0x7b/0xb0 bdiregisterva.part.13+0x58/0x2d0 bdiregister+0x9b/0xb0 initmtd+0x62/0x171 [mtd] dooneinitcall+0x6c/0x3c0 doinitmodule+0x58/0x222 loadmodule+0x268e/0x27d0 dosysfinitmodule+0xd5/0x140 dosyscall64+0x37/0x90 entrySYSCALL64afterhwframe+0x63/0xcd </TASK> kobjectaddinternal failed for mtd-0 with -EEXIST, don't try to register things with the same name in the same directory. Error registering mtd class or bdi: -17

If initmtdchar() fails in initmtd(), mtdbdi will not be unregistered, as a result, we can't load the mtd module again, to fix this by calling bdiunregister(mtdbdi) after outprocfs label.

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

drm/amdgpu: drop redundant sched job cleanup when cs is aborted

Once command submission failed due to userptr invalidation in amdgpucssubmit, legacy code will perform cleanup of scheduler job. However, it's not needed at all, as former commit has integrated job cleanup stuff into amdgpujobfree. Otherwise, because of double free, a NULL pointer dereference will occur in such scenario.

Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2457

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

vhost/vsock: Use kvmalloc/kvfree for larger packets.

When copying a large file over sftp over vsock, data size is usually 32kB, and kmalloc seems to fail to try to allocate 32 32kB regions.

vhost-5837: page allocation failure: order:4, mode:0x24040c0 Call Trace: [<ffffffffb6a0df64>] dumpstack+0x97/0xdb [<ffffffffb68d6aed>] warnallocfailed+0x10f/0x138 [<ffffffffb68d868a>] ? allocpagesdirectcompact+0x38/0xc8 [<ffffffffb664619f>] allocpagesnodemask+0x84c/0x90d [<ffffffffb6646e56>] allockmempages+0x17/0x19 [<ffffffffb6653a26>] kmallocordertrace+0x2b/0xdb [<ffffffffb66682f3>] kmalloc+0x177/0x1f7 [<ffffffffb66e0d94>] ? copyfromiter+0x8d/0x31d [<ffffffffc0689ab7>] vhostvsockhandletxkick+0x1fa/0x301 [vhostvsock] [<ffffffffc06828d9>] vhostworker+0xf7/0x157 [vhost] [<ffffffffb683ddce>] kthread+0xfd/0x105 [<ffffffffc06827e2>] ? vhostdevsetowner+0x22e/0x22e [vhost] [<ffffffffb683dcd1>] ? flushkthreadworker+0xf3/0xf3 [<ffffffffb6eb332e>] retfromfork+0x4e/0x80 [<ffffffffb683dcd1>] ? flushkthreadworker+0xf3/0xf3

Work around by doing kvmalloc instead.

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

USB: uhci: fix memory leak with using debugfslookup()

When calling debugfslookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfslookupandremove() instead which handles all of the logic at once.

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

scsi: core: Fix possible memory leak if deviceadd() fails

If deviceadd() returns error, the name allocated by devsetname() needs be freed. As the comment of deviceadd() says, putdevice() should be used to decrease the reference count in the error path. So fix this by calling putdevice(), then the name can be freed in kobjectcleanp().

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

tty: pcnuart: fix memory leak with using debugfslookup()

When calling debugfslookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfslookupandremove() instead which handles all of the logic at once.