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

schedext: Fix starvation of scxenable() under fair-class saturation

During scxenable(), the READY -> ENABLED task switching loop changes the calling thread's schedclass from fair to ext. Since fair has higher priority than ext, saturating fair-class workloads can indefinitely starve the enable thread, hanging the system. This was introduced when the enable path switched from preemptdisable() to scxbypass() which doesn't protect against fair-class starvation. Note that the original preemptdisable() protection wasn't complete either - in partial switch modes, the calling thread could still be starved after preemptenable() as it may have been switched to ext class.

Fix it by offloading the enable body to a dedicated system-wide RT (SCHEDFIFO) kthread which cannot be starved by either fair or ext class tasks. scxenable() lazily creates the kthread on first use and passes the ops pointer through a struct scxenablecmd containing the kthreadwork, then synchronously waits for completion.

The workfn runs on a different kthread from sch->helper (which runs disablework), so it can safely flush disablework on the error path without deadlock.

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

ARM: fix cacheflush with PAN

It seems that the cacheflush syscall got broken when PAN for LPAE was implemented. User access was not enabled around the cache maintenance instructions, causing them to fault.

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

pmdomain: imx93-blk-ctrl: correct remove path

The check condition should be 'i < bc->onecelldata.numdomains', not 'bc->onecelldata.numdomains' which will make the look never finish and cause kernel panic.

Also disable runtime to address "imx93-blk-ctrl 4ac10000.system-controller: Unbalanced pmruntimeenable!"

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

drm/xe/oa: Fix "Missing outer runtime PM protection" warning

Fix the following drmWARN:

[953.586396] xe 0000:00:02.0: [drm] Missing outer runtime PM protection ... <4> [953.587090] ? xepmruntimegetnoresume+0x8d/0xa0 [xe] <4> [953.587208] gucexecqueueaddmsg+0x28/0x130 [xe] <4> [953.587319] gucexecqueuefini+0x3a/0x40 [xe] <4> [953.587425] xeexecqueuedestroy+0xb3/0xf0 [xe] <4> [953.587515] xeoarelease+0x9c/0xc0 [xe]

(cherry picked from commit b107c63d2953907908fd0cafb0e543b3c3167b75)

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

mptcp: error out earlier on disconnect

Eric reported a division by zero splat in the MPTCP protocol:

Oops: divide error: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 UID: 0 PID: 6094 Comm: syz-executor317 Not tainted 6.12.0-rc5-syzkaller-00291-g05b92660cdfe #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:tcpselectwindow+0x5b4/0x1310 net/ipv4/tcpoutput.c:3163 Code: f6 44 01 e3 89 df e8 9b 75 09 f8 44 39 f3 0f 8d 11 ff ff ff e8 0d 74 09 f8 45 89 f4 e9 04 ff ff ff e8 00 74 09 f8 44 89 f0 99 &lt;f7&gt; 7c 24 14 41 29 d6 45 89 f4 e9 ec fe ff ff e8 e8 73 09 f8 48 89 RSP: 0018:ffffc900041f7930 EFLAGS: 00010293 RAX: 0000000000017e67 RBX: 0000000000017e67 RCX: ffffffff8983314b RDX: 0000000000000000 RSI: ffffffff898331b0 RDI: 0000000000000004 RBP: 00000000005d6000 R08: 0000000000000004 R09: 0000000000017e67 R10: 0000000000003e80 R11: 0000000000000000 R12: 0000000000003e80 R13: ffff888031d9b440 R14: 0000000000017e67 R15: 00000000002eb000 FS: 00007feb5d7f16c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007feb5d8adbb8 CR3: 0000000074e4c000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: &lt;TASK&gt; tcpcleanuprbuf+0x3e7/0x4b0 net/ipv4/tcp.c:1493 mptcprcvspaceadjust net/mptcp/protocol.c:2085 [inline] mptcprecvmsg+0x2156/0x2600 net/mptcp/protocol.c:2289 inetrecvmsg+0x469/0x6a0 net/ipv4/afinet.c:885 sockrecvmsgnosec net/socket.c:1051 [inline] sockrecvmsg+0x1b2/0x250 net/socket.c:1073 sysrecvfrom+0x1a5/0x2e0 net/socket.c:2265 dosysrecvfrom net/socket.c:2283 [inline] sesysrecvfrom net/socket.c:2279 [inline] x64sysrecvfrom+0xe0/0x1c0 net/socket.c:2279 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcd/0x250 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7feb5d857559 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007feb5d7f1208 EFLAGS: 00000246 ORIGRAX: 000000000000002d RAX: ffffffffffffffda RBX: 00007feb5d8e1318 RCX: 00007feb5d857559 RDX: 000000800000000e RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007feb5d8e1310 R08: 0000000000000000 R09: ffffffff81000000 R10: 0000000000000100 R11: 0000000000000246 R12: 00007feb5d8e131c R13: 00007feb5d8ae074 R14: 000000800000000e R15: 00000000fffffdef

and provided a nice reproducer.

The root cause is the current bad handling of racing disconnect. After the blamed commit below, skwaitdata() can return (with error) with the underlying socket disconnected and a zero rcvmss.

Catch the error and return without performing any additional operations on the current socket.

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

virtio/vsock: Fix acceptqueue memory leak

As the final stages of socket destruction may be delayed, it is possible that virtiotransportrecvlisten() will be called after the acceptqueue has been flushed, but before the SOCKDONE flag has been set. As a result, sockets enqueued after the flush would remain unremoved, leading to a memory leak.

vsockrelease vsockrelease lock virtiotransportrelease virtiotransportclose scheduledelayedwork(closework) skshutdown = SHUTDOWNMASK (!) flush acceptqueue release virtiotransportrecvpkt vsockfindboundsocket lock if flag(SOCKDONE) return virtiotransportrecvlisten child = vsockcreateconnected (!) vsockenqueueaccept(child) release closework lock virtiotransportdoclose setflag(SOCKDONE) virtiotransportremovesock vsockremovesock vsockremovebound release

Introduce a skshutdown check to disallow vsockenqueueaccept() during socket destruction.

unreferenced object 0xffff888109e3f800 (size 2040): comm "kworker/5:2", pid 371, jiffies 4294940105 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 28 00 0b 40 00 00 00 00 00 00 00 00 00 00 00 00 (..@............ backtrace (crc 9e5f4e84): [<ffffffff81418ff1>] kmemcacheallocnoprof+0x2c1/0x360 [<ffffffff81d27aa0>] skprotalloc+0x30/0x120 [<ffffffff81d2b54c>] skalloc+0x2c/0x4b0 [<ffffffff81fe049a>] vsockcreate.constprop.0+0x2a/0x310 [<ffffffff81fe6d6c>] virtiotransportrecvpkt+0x4dc/0x9a0 [<ffffffff81fe745d>] vsockloopbackwork+0xfd/0x140 [<ffffffff810fc6ac>] processonework+0x20c/0x570 [<ffffffff810fce3f>] workerthread+0x1bf/0x3a0 [<ffffffff811070dd>] kthread+0xdd/0x110 [<ffffffff81044fdd>] retfromfork+0x2d/0x50 [<ffffffff8100785a>] retfromforkasm+0x1a/0x30

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

vsock: Fix skerrorqueue memory leak

Kernel queues MSGZEROCOPY completion notifications on the error queue. Where they remain, until explicitly recv()ed. To prevent memory leaks, clean up the queue when the socket is destroyed.

unreferenced object 0xffff8881028beb00 (size 224): comm "vsocktest", pid 1218, jiffies 4294694897 hex dump (first 32 bytes): 90 b0 21 17 81 88 ff ff 90 b0 21 17 81 88 ff ff ..!.......!..... 00 00 00 00 00 00 00 00 00 b0 21 17 81 88 ff ff ..........!..... backtrace (crc 6c7031ca): [&lt;ffffffff81418ef7&gt;] kmemcacheallocnodenoprof+0x2f7/0x370 [&lt;ffffffff81d35882&gt;] allocskb+0x132/0x180 [&lt;ffffffff81d2d32b&gt;] sockomalloc+0x4b/0x80 [&lt;ffffffff81d3a8ae&gt;] msgzerocopyrealloc+0x9e/0x240 [&lt;ffffffff81fe5cb2&gt;] virtiotransportsendpktinfo+0x412/0x4c0 [&lt;ffffffff81fe6183&gt;] virtiotransportstreamenqueue+0x43/0x50 [&lt;ffffffff81fe0813&gt;] vsockconnectiblesendmsg+0x373/0x450 [&lt;ffffffff81d233d5&gt;] syssendmsg+0x365/0x3a0 [&lt;ffffffff81d246f4&gt;] syssendmsg+0x84/0xd0 [&lt;ffffffff81d26f47&gt;] syssendmsg+0x47/0x80 [&lt;ffffffff820d3df3&gt;] dosyscall64+0x93/0x180 [&lt;ffffffff8220012b&gt;] entrySYSCALL64afterhwframe+0x76/0x7e

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

virtio/vsock: Improve MSGZEROCOPY error handling

Add a missing kfreeskb() to prevent memory leaks.

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

drm/vmwgfx: avoid nullptrderef in vmwframebuffersurfacecreatehandle

The 'vmwuserobjectbuffer' function may return NULL with incorrect inputs. To avoid possible null pointer dereference, add a check whether the 'bo' is NULL in the vmwframebuffersurfacecreatehandle.

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

drm/panthor: Fix handling of partial GPU mapping of BOs

This commit fixes the bug in the handling of partial mapping of the buffer objects to the GPU, which caused kernel warnings.

Panthor didn't correctly handle the case where the partial mapping spanned multiple scatterlists and the mapping offset didn't point to the 1st page of starting scatterlist. The offset variable was not cleared after reaching the starting scatterlist.

Following warning messages were seen. WARNING: CPU: 1 PID: 650 at drivers/iommu/io-pgtable-arm.c:659 armlpaeunmap+0x254/0x5a0 <snip> pc : armlpaeunmap+0x254/0x5a0 lr : armlpaeunmap+0x2cc/0x5a0 <snip> Call trace: armlpaeunmap+0x254/0x5a0 armlpaeunmap+0x108/0x5a0 armlpaeunmap+0x108/0x5a0 armlpaeunmap+0x108/0x5a0 armlpaeunmappages+0x80/0xa0 panthorvmunmappages+0xac/0x1c8 [panthor] panthorgpuvasmstepunmap+0x4c/0xc8 [panthor] opunmapcb.isra.23.constprop.30+0x54/0x80 drmgpuvmsmunmap+0x184/0x1c8 drmgpuvmsmunmap+0x40/0x60 panthorvmexecop+0xa8/0x120 [panthor] panthorvmbindexecsyncop+0xc4/0xe8 [panthor] panthorioctlvmbind+0x10c/0x170 [panthor] drmioctlkernel+0xbc/0x138 drmioctl+0x210/0x4b0 arm64sysioctl+0xb0/0xf8 invokesyscall+0x4c/0x110 el0svccommon.constprop.1+0x98/0xf8 doel0svc+0x24/0x38 el0svc+0x34/0xc8 el0t64synchandler+0xa0/0xc8 el0t64sync+0x174/0x178 <snip> panthor : [drm] drmWARNON(unmappedsz != pgsize pgcount) WARNING: CPU: 1 PID: 650 at drivers/gpu/drm/panthor/panthormmu.c:922 panthorvmunmappages+0x124/0x1c8 [panthor] <snip> pc : panthorvmunmappages+0x124/0x1c8 [panthor] lr : panthorvmunmappages+0x124/0x1c8 [panthor] <snip> panthor : [drm] ERROR failed to unmap range ffffa388f000-ffffa3890000 (requested range ffffa388c000-ffffa3890000)

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

x86/CPU/AMD: Clear virtualized VMLOAD/VMSAVE on Zen4 client

A number of Zen4 client SoCs advertise the ability to use virtualized VMLOAD/VMSAVE, but using these instructions is reported to be a cause of a random host reboot.

These instructions aren't intended to be advertised on Zen4 client so clear the capability.

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

mm: fix NULL pointer dereference in allocpagesbulknoprof

We triggered a NULL pointer dereference for ac.preferredzoneref->zone in allocpagesbulknoprof() when the task is migrated between cpusets.

When cpuset is enabled, in prepareallocpages(), ac->nodemask may be &current->memsallowed. when firstzoneszonelist() is called to find preferredzoneref, the ac->nodemask may be modified concurrently if the task is migrated between different cpusets. Assuming we have 2 NUMA Node, when traversing Node1 in ac->zonelist, the nodemask is 2, and when traversing Node2 in ac->zonelist, the nodemask is 1. As a result, the ac->preferredzoneref points to NULL zone.

In allocpagesbulknoprof(), foreachzonezonelistnodemask() finds a allowable zone and calls zonelistnodeidx(ac.preferredzoneref), leading to NULL pointer dereference.

allocpagesnoprof() fixes this issue by checking NULL pointer in commit ea57485af8f4 ("mm, pagealloc: fix check for NULL preferredzone") and commit df76cee6bbeb ("mm, pagealloc: remove redundant checks from alloc fastpath").

To fix it, check NULL pointer for preferredzoneref->zone.

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

ocfs2: uncache inode which has failed entering the group

Syzbot has reported the following BUG:

kernel BUG at fs/ocfs2/uptodate.c:509! ... Call Trace: <TASK> ? diebody+0x5f/0xb0 ? die+0x9e/0xc0 ? dotrap+0x15a/0x3a0 ? ocfs2setnewbufferuptodate+0x145/0x160 ? doerrortrap+0x1dc/0x2c0 ? ocfs2setnewbufferuptodate+0x145/0x160 ? pfxdoerrortrap+0x10/0x10 ? handleinvalidop+0x34/0x40 ? ocfs2setnewbufferuptodate+0x145/0x160 ? excinvalidop+0x38/0x50 ? asmexcinvalidop+0x1a/0x20 ? ocfs2setnewbufferuptodate+0x2e/0x160 ? ocfs2setnewbufferuptodate+0x144/0x160 ? ocfs2setnewbufferuptodate+0x145/0x160 ocfs2groupadd+0x39f/0x15a0 ? pfxocfs2groupadd+0x10/0x10 ? pfxlockacquire+0x10/0x10 ? mntgetwriteaccess+0x68/0x2b0 ? pfxlockrelease+0x10/0x10 ? rcureadlockanyheld+0xb7/0x160 ? pfxrcureadlockanyheld+0x10/0x10 ? smacklog+0x123/0x540 ? mntgetwriteaccess+0x68/0x2b0 ? mntgetwriteaccess+0x68/0x2b0 ? mntgetwriteaccess+0x226/0x2b0 ocfs2ioctl+0x65e/0x7d0 ? pfxocfs2ioctl+0x10/0x10 ? smackfileioctl+0x29e/0x3a0 ? pfxsmackfileioctl+0x10/0x10 ? lockdephardirqsonprepare+0x43d/0x780 ? pfxlockdephardirqsonprepare+0x10/0x10 ? pfxocfs2ioctl+0x10/0x10 sesysioctl+0xfb/0x170 dosyscall64+0xf3/0x230 entrySYSCALL64afterhwframe+0x77/0x7f ... </TASK>

When 'ioctl(OCFS2IOCGROUPADD, ...)' has failed for the particular inode in 'ocfs2verifygroupandinput()', corresponding buffer head remains cached and subsequent call to the same 'ioctl()' for the same inode issues the BUG() in 'ocfs2setnewbufferuptodate()' (trying to cache the same buffer head of that inode). Fix this by uncaching the buffer head with 'ocfs2removefromcache()' on error path in 'ocfs2groupadd()'.

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

mm: pagealloc: move mlocked flag clearance into freepagesprepare()

Syzbot reported a bad page state problem caused by a page being freed using freepage() still having a mlocked flag at freepagesprepare() stage:

BUG: Bad page state in process syz.5.504 pfn:61f45 page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x61f45 flags: 0xfff00000080204(referenced|workingset|mlocked|node=0|zone=1|lastcpupid=0x7ff) raw: 00fff00000080204 0000000000000000 dead000000000122 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: PAGEFLAGSCHECKATFREE flag(s) set pageowner tracks the page as allocated page last allocated via order 0, migratetype Unmovable, gfpmask 0x400dc0(GFPKERNELACCOUNT|GFPZERO), pid 8443, tgid 8442 (syz.5.504), ts 201884660643, freets 201499827394 setpageowner include/linux/pageowner.h:32 [inline] postallochook+0x1f3/0x230 mm/pagealloc.c:1537 prepnewpage mm/pagealloc.c:1545 [inline] getpagefromfreelist+0x303f/0x3190 mm/pagealloc.c:3457 allocpagesnoprof+0x292/0x710 mm/pagealloc.c:4733 allocpagesmpolnoprof+0x3e8/0x680 mm/mempolicy.c:2265 kvmcoalescedmmioinit+0x1f/0xf0 virt/kvm/coalescedmmio.c:99 kvmcreatevm virt/kvm/kvmmain.c:1235 [inline] kvmdevioctlcreatevm virt/kvm/kvmmain.c:5488 [inline] kvmdevioctl+0x12dc/0x2240 virt/kvm/kvmmain.c:5530 docompatsysioctl fs/ioctl.c:1007 [inline] secompatsysioctl+0x510/0xc90 fs/ioctl.c:950 dosyscall32irqson arch/x86/entry/common.c:165 [inline] dofastsyscall32+0xb4/0x110 arch/x86/entry/common.c:386 dofastsyscall32+0x34/0x80 arch/x86/entry/common.c:411 entrySYSENTERcompatafterhwframe+0x84/0x8e page last free pid 8399 tgid 8399 stack trace: resetpageowner include/linux/pageowner.h:25 [inline] freepagesprepare mm/pagealloc.c:1108 [inline] freeunreffolios+0xf12/0x18d0 mm/pagealloc.c:2686 foliosputrefs+0x76c/0x860 mm/swap.c:1007 freepagesandswapcache+0x5c8/0x690 mm/swapstate.c:335 tlbbatchfreeencodedpages mm/mmugather.c:136 [inline] tlbbatchpagesflush mm/mmugather.c:149 [inline] tlbflushmmufree mm/mmugather.c:366 [inline] tlbflushmmu+0x3a3/0x680 mm/mmugather.c:373 tlbfinishmmu+0xd4/0x200 mm/mmugather.c:465 exitmmap+0x496/0xc40 mm/mmap.c:1926 mmput+0x115/0x390 kernel/fork.c:1348 exitmm+0x220/0x310 kernel/exit.c:571 doexit+0x9b2/0x28e0 kernel/exit.c:926 dogroupexit+0x207/0x2c0 kernel/exit.c:1088 dosysexitgroup kernel/exit.c:1099 [inline] sesysexitgroup kernel/exit.c:1097 [inline] x64sysexitgroup+0x3f/0x40 kernel/exit.c:1097 x64syscall+0x2634/0x2640 arch/x86/include/generated/asm/syscalls64.h:232 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f Modules linked in: CPU: 0 UID: 0 PID: 8442 Comm: syz.5.504 Not tainted 6.12.0-rc6-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: &lt;TASK&gt; dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x241/0x360 lib/dumpstack.c:120 badpage+0x176/0x1d0 mm/pagealloc.c:501 freepageisbad mm/pagealloc.c:918 [inline] freepagesprepare mm/pagealloc.c:1100 [inline] freeunrefpage+0xed0/0xf20 mm/pagealloc.c:2638 kvmdestroyvm virt/kvm/kvmmain.c:1327 [inline] kvmputkvm+0xc75/0x1350 virt/kvm/kvmmain.c:1386 kvmvcpurelease+0x54/0x60 virt/kvm/kvmmain.c:4143 fput+0x23f/0x880 fs/filetable.c:431 taskworkrun+0x24f/0x310 kernel/taskwork.c:239 exittaskwork include/linux/taskwork.h:43 [inline] doexit+0xa2f/0x28e0 kernel/exit.c:939 dogroupexit+0x207/0x2c0 kernel/exit.c:1088 dosysexitgroup kernel/exit.c:1099 [in ---truncated---

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

fs: Fix uninitialized value issue in fromkuid and fromkgid

ocfs2setattr() uses attr->iamode, attr->iauid and attr->iagid in a trace point even though ATTRMODE, ATTRUID and ATTRGID aren't set.

Initialize all fields of newattrs to avoid uninitialized variables, by checking if ATTRMODE, ATTRUID, ATTRGID are initialized, otherwise 0.

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

LoongArch: KVM: Mark hrtimer to expire in hard interrupt context

Like commit 2c0d278f3293f ("KVM: LAPIC: Mark hrtimer to expire in hard interrupt context") and commit 9090825fa9974 ("KVM: arm/arm64: Let the timer expire in hardirq context on RT"), On PREEMPTRT enabled kernels unmarked hrtimers are moved into soft interrupt expiry mode by default. Then the timers are canceled from an preempt-notifier which is invoked with disabled preemption which is not allowed on PREEMPTRT.

The timer callback is short so in could be invoked in hard-IRQ context. So let the timer expire on hard-IRQ context even on -RT.

This fix a "scheduling while atomic" bug for PREEMPTRT enabled kernels:

BUG: scheduling while atomic: qemu-system-loo/1011/0x00000002 Modules linked in: amdgpu rfkill nftfibinet nftfibipv4 nftfibipv6 nftfib nftrejectinet nfrejectipv4 nfrejectipv6 nftreject nftct nftchainnat ns CPU: 1 UID: 0 PID: 1011 Comm: qemu-system-loo Tainted: G W 6.12.0-rc2+ #1774 Tainted: [W]=WARN Hardware name: Loongson Loongson-3A5000-7A1000-1w-CRB/Loongson-LS3A5000-7A1000-1w-CRB, BIOS vUDK2018-LoongArch-V2.0.0-prebeta9 10/21/2022 Stack : ffffffffffffffff 0000000000000000 9000000004e3ea38 9000000116744000 90000001167475a0 0000000000000000 90000001167475a8 9000000005644830 90000000058dc000 90000000058dbff8 9000000116747420 0000000000000001 0000000000000001 6a613fc938313980 000000000790c000 90000001001c1140 00000000000003fe 0000000000000001 000000000000000d 0000000000000003 0000000000000030 00000000000003f3 000000000790c000 9000000116747830 90000000057ef000 0000000000000000 9000000005644830 0000000000000004 0000000000000000 90000000057f4b58 0000000000000001 9000000116747868 900000000451b600 9000000005644830 9000000003a13998 0000000010000020 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1d ... Call Trace: [<9000000003a13998>] showstack+0x38/0x180 [<9000000004e3ea34>] dumpstacklvl+0x84/0xc0 [<9000000003a71708>] schedulebug+0x48/0x60 [<9000000004e45734>] schedule+0x1114/0x1660 [<9000000004e46040>] schedulertlock+0x20/0x60 [<9000000004e4e330>] rtlockslowlocklocked+0x3f0/0x10a0 [<9000000004e4f038>] rtspinlock+0x58/0x80 [<9000000003b02d68>] hrtimercancelwaitrunning+0x68/0xc0 [<9000000003b02e30>] hrtimercancel+0x70/0x80 [<ffff80000235eb70>] kvmrestoretimer+0x50/0x1a0 [kvm] [<ffff8000023616c8>] kvmarchvcpuload+0x68/0x2a0 [kvm] [<ffff80000234c2d4>] kvmschedin+0x34/0x60 [kvm] [<9000000003a749a0>] finishtaskswitch.isra.0+0x140/0x2e0 [<9000000004e44a70>] schedule+0x450/0x1660 [<9000000004e45cb0>] schedule+0x30/0x180 [<ffff800002354c70>] kvmvcpublock+0x70/0x120 [kvm] [<ffff800002354d80>] kvmvcpuhalt+0x60/0x3e0 [kvm] [<ffff80000235b194>] kvmhandlegspr+0x3f4/0x4e0 [kvm] [<ffff80000235f548>] kvmhandleexit+0x1c8/0x260 [kvm]

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

drm/xe: Fix possible exec queue leak in exec IOCTL

In a couple of places after an exec queue is looked up the exec IOCTL returns on input errors without dropping the exec queue ref. Fix this ensuring the exec queue ref is dropped on input error.

(cherry picked from commit 07064a200b40ac2195cb6b7b779897d9377e5e6f)

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

drm/xe: Drop VM dma-resv lock on xesyncinfenceget failure in exec IOCTL

Upon failure all locks need to be dropped before returning to the user.

(cherry picked from commit 7d1a4258e602ffdce529f56686925034c1b3b095)

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

tpm: Lock TPM chip in tpmpmsuspend() first

Setting TPMCHIPFLAGSUSPENDED in the end of tpmpmsuspend() can be racy according, as this leaves window for tpmhwrngread() to be called while the operation is in progress. The recent bug report gives also evidence of this behaviour.

Aadress this by locking the TPM chip before checking any chip-&gt;flags both in tpmpmsuspend() and tpmhwrngread(). Move TPMCHIPFLAGSUSPENDED check inside tpmgetrandom() so that it will be always checked only when the lock is reserved.

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

drm/imagination: Break an object reference loop

When remaining resources are being cleaned up on driver close, outstanding VM mappings may result in resources being leaked, due to an object reference loop, as shown below, with each object (or set of objects) referencing the object below it:

PVR GEM Object GPU scheduler "finished" fence GPU scheduler “scheduled” fence PVR driver “done” fence PVR Context PVR VM Context PVR VM Mappings PVR GEM Object

The reference that the PVR VM Context has on the VM mappings is a soft one, in the sense that the freeing of outstanding VM mappings is done as part of VM context destruction; no reference counts are involved, as is the case for all the other references in the loop.

To break the reference loop during cleanup, free the outstanding VM mappings before destroying the PVR Context associated with the VM context.

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

usb: typec: qcom-pmic: init value of hdrlen/txbuflen earlier

If the read of USBPDPHYRXACKNOWLEDGEREG failed, then hdrlen and txbuflen are uninitialized. This commit stops to print uninitialized value and misleading/false data.

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

media: ar0521: don't overflow when checking PLL values

The PLL checks are comparing 64 bit integers with 32 bit ones, as reported by Coverity. Depending on the values of the variables, this may underflow.

Fix it ensuring that both sides of the expression are u64.

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

drm/tegra: Fix NULL vs ISERR() check in probe()

The iommupagingdomainalloc() function doesn't return NULL pointers, it returns error pointers. Update the check to match.

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

rpcrdma: Always release the rpcrdmadevice's xaarray

Dai pointed out that the xainitflags() in rpcrdmaaddone() needs to have a matching xadestroy() in rpcrdmaremoveone() to release underlying memory that the xarray might have accrued during operation.

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

riscv: Prevent a bad reference count on CPU nodes

When populating cache leaves we previously fetched the CPU device node at the very beginning. But when ACPI is enabled we go through a specific branch which returns early and does not call 'ofnodeput' for the node that was acquired.

Since we are not using a CPU device node for the ACPI code anyways, we can simply move the initialization of it just passed the ACPI block, and we are guaranteed to have an 'ofnodeput' call for the acquired node. This prevents a bad reference count of the CPU device node.

Moreover, the previous function did not check for errors when acquiring the device node, so a return -ENOENT has been added for that case.

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

wifi: iwlwifi: mvm: don't leak a link on AP removal

Release the link mapping resource in AP removal. This impacted devices that do not support the MLD API (9260 and down). On those devices, we couldn't start the AP again after the AP has been already started and stopped.

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

drm/panthor: Be stricter about IO mapping flags

The current panthordevicemmapio() implementation has two issues:

1. For mapping DRMPANTHORUSERFLUSHIDMMIOOFFSET, panthordevicemmapio() bails if VMWRITE is set, but does not clear VMMAYWRITE. That means userspace can use mprotect() to make the mapping writable later on. This is a classic Linux driver gotcha. I don't think this actually has any impact in practice: When the GPU is powered, writes to the FLUSHID seem to be ignored; and when the GPU is not powered, the dummylatestflush page provided by the driver is deliberately designed to not do any flushes, so the only thing writing to the dummylatestflush could achieve would be to make more flushes happen.

2. panthordevicemmapio() does not block MAPPRIVATE mappings (which are mappings without the VMSHARED flag). MAPPRIVATE in combination with VMMAYWRITE indicates that the VMA has copy-on-write semantics, which for VMPFNMAP are semi-supported but fairly cursed. In particular, in such a mapping, the driver can only install PTEs during mmap() by calling remappfnrange() (because remappfnrange() wants to store the physical address of the mapped physical memory into the vmpgoff of the VMA); installing PTEs later on with a fault handler (as panthor does) is not supported in private mappings, and so if you try to fault in such a mapping, vmfinsertpfnprot() splats when it hits a BUG() check.

Fix it by clearing the VMMAYWRITE flag (userspace writing to the FLUSHID doesn't make sense) and requiring VMSHARED (copy-on-write semantics for the FLUSHID don't make sense).

Reproducers for both scenarios are in the notes of my patch on the mailing list; I tested that these bugs exist on a Rock 5B machine.

Note that I only compile-tested the patch, I haven't tested it; I don't have a working kernel build setup for the test machine yet. Please test it before applying it.

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

platform/x86/amd/pmc: Detect when STB is not available

Loading the amdpmc module as:

amdpmc enablestb=1

...can result in the following messages in the kernel ring buffer:

amdpmc AMDI0009:00: SMU cmd failed. err: 0xff ioremap on RAM at 0x0000000000000000 - 0x0000000000ffffff WARNING: CPU: 10 PID: 2151 at arch/x86/mm/ioremap.c:217 ioremapcaller+0x2cd/0x340

Further debugging reveals that this occurs when the requests for S2DPHYSADDRLOW and S2DPHYSADDRHIGH return a value of 0, indicating that the STB is inaccessible. To prevent the ioremap warning and provide clarity to the user, handle the invalid address and display an error message.

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

firmware: qcom: scm: fix a NULL-pointer dereference

Some SCM calls can be invoked with scm being NULL (the driver may not have been and will not be probed as there's no SCM entry in device-tree). Make sure we don't dereference a NULL pointer.

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

scsi: ufs: core: Start the RTC update work later

The RTC update work involves runtime resuming the UFS controller. Hence, only start the RTC update work after runtime power management in the UFS driver has been fully initialized. This patch fixes the following kernel crash:

Internal error: Oops: 0000000096000006 [#1] PREEMPT SMP Workqueue: events ufshcdrtcwork Call trace: rawspinlockirqsave+0x34/0x8c (P) pmruntimegetifactive+0x24/0x9c (L) pmruntimegetifactive+0x24/0x9c ufshcdrtcwork+0x138/0x1b4 processonework+0x148/0x288 workerthread+0x2cc/0x3d4 kthread+0x110/0x114 retfromfork+0x10/0x20