drivers/base/memory: set mem->altmap after successful device registration

drm/amdgpu: csa unmap use uninterruptible lock

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

iommufd: Fix protection fault in iommufdtestsyzconviova

Syzkaller reported the following bug:

general protection fault, probably for non-canonical address 0xdffffc0000000038: 0000 [#1] SMP KASAN KASAN: null-ptr-deref in range [0x00000000000001c0-0x00000000000001c7] Call Trace: lockacquire lockacquire+0x1ce/0x4f0 downread+0x93/0x4a0 iommufdtestsyzconviova+0x56/0x1f0 iommufdtestaccessrw.isra.0+0x2ec/0x390 iommufdtest+0x1058/0x1e30 iommufdfopsioctl+0x381/0x510 vfsioctl dosysioctl sesysioctl x64sysioctl+0x170/0x1e0 dosyscallx64 dosyscall64+0x71/0x140

This is because the new iommufdaccesschangeioas() sets access->ioas to NULL during its process, so the lock might be gone in a concurrent racing context.

Fix this by doing the same access->ioas sanity as iommufdaccessrw() and iommufdaccesspinpages() functions do.

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

RDMA/bnxtre: Avoid CPU lockups due fifo occupancy check loop

Driver waits indefinitely for the fifo occupancy to go below a threshold as soon as the pacing interrupt is received. This can cause soft lockup on one of the processors, if the rate of DB is very high.

Add a loop count for FPGA and exit the waitforfifooccupancybelowth if the loop is taking more time. Pacing will be continuing until the occupancy is below the threshold. This is ensured by the checks in bnxtrepacingtimerexp and further scheduling the work for pacing based on the fifo occupancy.

gpiolib: Fix crash on error in gpiochipgetngpios()

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

efi: Allocate runtime workqueue before ACPI init

Since commit

5894cf571e14 ("acpi/prmt: Use EFI runtime sandbox to invoke PRM handlers")

ACPI PRM calls are delegated to a workqueue which runs in a kernel thread, making it easier to detect and mitigate faulting memory accesses performed by the firmware.

Rafael reports that such PRM accesses may occur before efisubsysinit() executes, which is where the workqueue is allocated, leading to NULL pointer dereferences. Since acpiinit() [which triggers the early PRM accesses] executes as a subsysinitcall() as well, and has its own dependencies that may be sensitive to initcall ordering, deferring acpiinit() is not an option.

So instead, split off the workqueue allocation into its own postcore initcall, as this is the only missing piece to allow EFI runtime calls to be made. This ensures that EFI runtime call (including PRM calls) are accessible to all code running at subsysinitcall() level.

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

net: txgbe: fix RTNL assertion warning when remove module

For the copper NIC with external PHY, the driver called phylinkconnectphy() during probe and phylinkdisconnectphy() during remove. It caused an RTNL assertion warning in phylinkdisconnectphy() upon module remove.

To fix this, add rtnllock() and rtnlunlock() around the phylinkdisconnectphy() in remove function.

------------[ cut here ]------------ RTNL: assertion failed at drivers/net/phy/phylink.c (2351) WARNING: drivers/net/phy/phylink.c:2351 at phylinkdisconnectphy+0xd8/0xf0 [phylink], CPU#0: rmmod/4464 Modules linked in: ... CPU: 0 UID: 0 PID: 4464 Comm: rmmod Kdump: loaded Not tainted 7.0.0-rc4+ Hardware name: Micro-Star International Co., Ltd. MS-7E16/X670E GAMING PLUS WIFI (MS-7E16), BIOS 1.90 12/31/2024 RIP: 0010:phylinkdisconnectphy+0xe4/0xf0 [phylink] Code: 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 31 d2 31 f6 31 ff e9 3a 38 8f e7 48 8d 3d 48 87 e2 ff ba 2f 09 00 00 48 c7 c6 c1 22 24 c0 <67> 48 0f b9 3a e9 34 ff ff ff 66 90 90 90 90 90 90 90 90 90 90 90 RSP: 0018:ffffce7288363ac0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff89654b2a1a00 RCX: 0000000000000000 RDX: 000000000000092f RSI: ffffffffc02422c1 RDI: ffffffffc0239020 RBP: ffffce7288363ae8 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8964c4022000 R13: ffff89654fce3028 R14: ffff89654ebb4000 R15: ffffffffc0226348 FS: 0000795e80d93780(0000) GS:ffff896c52857000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005b528b592000 CR3: 0000000170d0f000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: <TASK> txgberemovephy+0xbb/0xd0 [txgbe] txgberemove+0x4c/0xb0 [txgbe] pcideviceremove+0x41/0xb0 deviceremove+0x43/0x80 devicereleasedriverinternal+0x206/0x270 driverdetach+0x4a/0xa0 busremovedriver+0x83/0x120 driverunregister+0x2f/0x60 pciunregisterdriver+0x40/0x90 txgbedriverexit+0x10/0x850 [txgbe] dosysdeletemodule.isra.0+0x1c3/0x2f0 x64sysdeletemodule+0x12/0x20 x64syscall+0x20c3/0x2390 dosyscall64+0x11c/0x1500 ? srsoaliasreturnthunk+0x5/0xfbef5 ? dosyscall64+0x15a/0x1500 ? srsoaliasreturnthunk+0x5/0xfbef5 ? dofault+0x312/0x580 ? srsoaliasreturnthunk+0x5/0xfbef5 ? handlemmfault+0x9d5/0x1040 ? srsoaliasreturnthunk+0x5/0xfbef5 ? countmemcgevents+0x101/0x1d0 ? srsoaliasreturnthunk+0x5/0xfbef5 ? handlemmfault+0x1e8/0x2f0 ? srsoaliasreturnthunk+0x5/0xfbef5 ? douseraddrfault+0x2f8/0x820 ? srsoaliasreturnthunk+0x5/0xfbef5 ? irqentryexit+0xb2/0x600 ? srsoaliasreturnthunk+0x5/0xfbef5 ? excpagefault+0x92/0x1c0 entrySYSCALL64afterhwframe+0x76/0x7e

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

dmaengine: fsl-edma: don't explicitly disable clocks in .remove()

The clocks in fsledmaengine::muxclk are allocated and enabled with devmclkgetenabled(), which automatically cleans these resources up, but these clocks are also manually disabled in fsledmaremove(). This causes warnings on driver removal for each clock:

edmamodule already disabled WARNING: CPU: 0 PID: 418 at drivers/clk/clk.c:1200 clkcoredisable+0x198/0x1c8 [...] Call trace: clkcoredisable+0x198/0x1c8 (P) clkdisable+0x34/0x58 fsledmaremove+0x74/0xe8 [fsledma] [...] ---[ end trace 0000000000000000 ]--- edmamodule already unprepared WARNING: CPU: 0 PID: 418 at drivers/clk/clk.c:1059 clkcoreunprepare+0x1f8/0x220 [...] Call trace: clkcoreunprepare+0x1f8/0x220 (P) clkunprepare+0x34/0x58 fsledmaremove+0x7c/0xe8 [fsledma] [...] ---[ end trace 0000000000000000 ]---

Fix these warnings by removing the unnecessary fsldisableclocks() call in fsledmaremove().

drm/bridge: cadence: cdns-mhdp8546-core: Set the mhdp connector earlier in atomicenable()

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

iouring: check if we need to reschedule during overflow flush

In terms of normal application usage, this list will always be empty. And if an application does overflow a bit, it'll have a few entries. However, nothing obviously prevents syzbot from running a test case that generates a ton of overflow entries, and then flushing them can take quite a while.

Check for needing to reschedule while flushing, and drop our locks and do so if necessary. There's no state to maintain here as overflows always prune from head-of-list, hence it's fine to drop and reacquire the locks at the end of the loop.

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

net/sched: taprio: fix NULL pointer dereference in class dump

When a TAPRIO child qdisc is deleted via RTMDELQDISC, tapriograft() is called with new == NULL and stores NULL into q->qdiscs[cl - 1]. Subsequent RTMGETTCLASS dump operations walk all classes via tapriowalk() and call tapriodumpclass(), which calls taprioleaf() returning the NULL pointer, then dereferences it to read child->handle, causing a kernel NULL pointer dereference.

The bug is reachable with namespace-scoped CAPNETADMIN on any kernel with CONFIGNETSCHTAPRIO enabled. On systems with unprivileged user namespaces enabled, an unprivileged local user can trigger a kernel panic by creating a taprio qdisc inside a new network namespace, grafting an explicit child qdisc, deleting it, and requesting a class dump. The RTMGETTCLASS dump itself requires no capability.

Oops: general protection fault, probably for non-canonical address 0xdffffc0000000007: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f] RIP: 0010:tapriodumpclass (net/sched/schtaprio.c:2478) Call Trace: <TASK> tcfilltclass (net/sched/schapi.c:1966) qdiscclassdump (net/sched/schapi.c:2326) tapriowalk (net/sched/schtaprio.c:2514) tcdumptclassqdisc (net/sched/schapi.c:2352) tcdumptclassroot (net/sched/schapi.c:2370) tcdumptclass (net/sched/schapi.c:2431) rtnldumpit (net/core/rtnetlink.c:6864) netlinkdump (net/netlink/afnetlink.c:2325) rtnetlinkrcvmsg (net/core/rtnetlink.c:6959) netlinkrcvskb (net/netlink/afnetlink.c:2550) </TASK>

Fix this by substituting &noopqdisc when new is NULL in tapriograft(), a common pattern used by other qdiscs (e.g., multiqgraft()) to ensure the q->qdiscs[] slots are never NULL. This makes control-plane dump paths safe without requiring individual NULL checks.

Since the data-plane paths (taprioenqueue and tapriodequeuefromtxq) previously had explicit NULL guards that would drop/skip the packet cleanly, update those checks to test for &noopqdisc instead. Without this, packets would reach taprioenqueueone() which increments the root qdisc's qlen and backlog before calling the child's enqueue; noopqdisc drops the packet but those counters are never rolled back, permanently inflating the root qdisc's statistics.

After this change old can be a valid qdisc, NULL, or &noopqdisc. Only call qdiscput(old) in the first case to avoid decreasing noopqdisc's refcount, which was never increased.

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

ceph: fix numops off-by-one when crypto allocation fails

movedirtyfolioinpagearray() may fail if the file is encrypted, the dirty folio is not the first in the batch, and it fails to allocate a bounce buffer to hold the ciphertext. When that happens, cephprocessfoliobatch() simply redirties the folio and flushes the current batch -- it can retry that folio in a future batch.

However, if this failed folio is not contiguous with the last folio that did make it into the batch, then cephprocessfoliobatch() has already incremented cephwbc->numops; because it doesn't follow through and add the discontiguous folio to the array, cephsubmitwrite() -- which expects that cephwbc->numops accurately reflects the number of contiguous ranges (and therefore the required number of "write extent" ops) in the writeback -- will panic the kernel:

BUGON(cephwbc->opidx + 1 != req->rnumops);

This issue can be reproduced on affected kernels by writing to fscrypt-enabled CephFS file(s) with a 4KiB-written/4KiB-skipped/repeat pattern (total filesize should not matter) and gradually increasing the system's memory pressure until a bounce buffer allocation fails.

Fix this crash by decrementing cephwbc->numops back to the correct value when movedirtyfolioinpagearray() fails, but the folio already started counting a new (i.e. still-empty) extent.

The defect corrected by this patch has existed since 2022 (see first Fixes:), but another bug blocked multi-folio encrypted writeback until recently (see second Fixes:). The second commit made it into 6.18.16, 6.19.6, and 7.0-rc1, unmasking the panic in those versions. This patch therefore fixes a regression (panic) introduced by cac190c7674f.

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

x86/kexec: Disable KCOV instrumentation after loadsegments()

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

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

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

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

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

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

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

[ bp: Space out comment for better readability. ]

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

x86/shstk: Prevent deadlock during shstk sigreturn

During sigreturn the shadow stack signal frame is popped. The kernel does this by reading the shadow stack using normal read accesses. When it can't assume the memory is shadow stack, it takes extra steps to makes sure it is reading actual shadow stack memory and not other normal readable memory. It does this by holding the mmap read lock while doing the access and checking the flags of the VMA.

Unfortunately that is not safe. If the read of the shadow stack sigframe hits a page fault, the fault handler will try to recursively grab another mmap read lock. This normally works ok, but if a writer on another CPU is also waiting, the second read lock could fail and cause a deadlock.

Fix this by not holding mmap lock during the read access to userspace.

Instead use mmaplockspeculate...() to watch for changes between dropping mmap lock and the userspace access. Retry if anything grabbed an mmap write lock in between and could have changed the VMA.

These mmaplockspeculate...() helpers use mm::mmlockseq, which is only available when PERVMALOCK is configured. So make X86USERSHADOWSTACK depend on it. On x86, PERVMALOCK is a default configuration for SMP kernels. So drop support for the other configs under the assumption that the !SMP shadow stack user base does not exist.

Currently there is a check that skips the lookup work when the SSP can be assumed to be on a shadow stack. While reorganizing the function, remove the optimization to make the tricky code flows more common, such that issues like this cannot escape detection for so long.

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

ksmbd: fix infinite loop caused by nextsmb2rcvhdroff reset in error paths

The problem occurs when a signed request fails smb2 signature verification check. In processrequest(), if checksignreq() returns an error, setsmb2rspstatus(work, STATUSACCESSDENIED) is called. setsmb2rspstatus() set work->nextsmb2rcvhdroff as zero. By resetting nextsmb2rcvhdroff to zero, the pointer to the next command in the chain is lost. Consequently, ischainedsmb2message() continues to point to the same request header instead of advancing. If the header's NextCommand field is non-zero, the function returns true, causing handleksmbdwork() to repeatedly process the same failed request in an infinite loop. This results in the kernel log being flooded with "bad smb2 signature" messages and high CPU usage.

This patch fixes the issue by changing the return value from SERVERHANDLERCONTINUE to SERVERHANDLERABORT. This ensures that the processing loop terminates immediately rather than attempting to continue from an invalidated offset.

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:

powerpc/kexec: Enable SMT before waking offline CPUs

If SMT is disabled or a partial SMT state is enabled, when a new kernel image is loaded for kexec, on reboot the following warning is observed:

kexec: Waking offline cpu 228. WARNING: CPU: 0 PID: 9062 at arch/powerpc/kexec/core64.c:223 kexecpreparecpus+0x1b0/0x1bc [snip] NIP kexecpreparecpus+0x1b0/0x1bc LR kexecpreparecpus+0x1a0/0x1bc Call Trace: kexecpreparecpus+0x1a0/0x1bc (unreliable) defaultmachinekexec+0x160/0x19c machinekexec+0x80/0x88 kernelkexec+0xd0/0x118 dosysreboot+0x210/0x2c4 systemcallexception+0x124/0x320 systemcallvectoredcommon+0x15c/0x2ec

This occurs as addcpu() fails due to cpubootable() returning false for CPUs that fail the cpusmtthreadallowed() check or non primary threads if SMT is disabled.

Fix the issue by enabling SMT and resetting the number of SMT threads to the number of threads per core, before attempting to wake up all present CPUs.

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:

net/mlx5: Unregister notifier on eswitch init failure

It otherwise remains registered and a subsequent attempt at eswitch enabling might trigger warnings of the sort:

[ 682.589148] ------------[ cut here ]------------ [ 682.590204] notifier callback eswitchvportevent [mlx5core] already registered [ 682.590256] WARNING: CPU: 13 PID: 2660 at kernel/notifier.c:31 notifierchainregister+0x3e/0x90 [...snipped] [ 682.610052] Call Trace: [ 682.610369] <TASK> [ 682.610663] ? warn+0x7c/0x110 [ 682.611050] ? notifierchainregister+0x3e/0x90 [ 682.611556] ? reportbug+0x148/0x170 [ 682.611977] ? handlebug+0x36/0x70 [ 682.612384] ? excinvalidop+0x13/0x60 [ 682.612817] ? asmexcinvalidop+0x16/0x20 [ 682.613284] ? notifierchainregister+0x3e/0x90 [ 682.613789] atomicnotifierchainregister+0x25/0x40 [ 682.614322] mlx5eswitchenablelocked+0x1d4/0x3b0 [mlx5core] [ 682.614965] mlx5eswitchenable+0xc9/0x100 [mlx5core] [ 682.615551] mlx5deviceenablesriov+0x25/0x340 [mlx5core] [ 682.616170] mlx5coresriovconfigure+0x50/0x170 [mlx5core] [ 682.616789] sriovnumvfsstore+0xb0/0x1b0 [ 682.617248] kernfsfopwriteiter+0x117/0x1a0 [ 682.617734] vfswrite+0x231/0x3f0 [ 682.618138] ksyswrite+0x63/0xe0 [ 682.618536] dosyscall64+0x4c/0x100 [ 682.618958] entrySYSCALL64afterhwframe+0x4b/0x53

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

Bluetooth: ISO: Check socket flag instead of hcon

This fixes the following Smatch static checker warning:

net/bluetooth/iso.c:1364 isosockrecvmsg() error: we previously assumed 'pi->conn->hcon' could be null (line 1359)

net/bluetooth/iso.c 1347 static int isosockrecvmsg(struct socket sock, struct msghdr msg, 1348 sizet len, int flags) 1349 { 1350 struct sock sk = sock->sk; 1351 struct isopinfo pi = isopi(sk); 1352 1353 BTDBG("sk %p", sk); 1354 1355 if (testandclearbit(BTSKDEFERSETUP, &btsk(sk)->flags)) { 1356 locksock(sk); 1357 switch (sk->skstate) { 1358 case BTCONNECT2: 1359 if (pi->conn->hcon && ^^^^^^^^^^^^^^ If ->hcon is NULL

1360 testbit(HCICONNPASYNC, &pi->conn->hcon->flags)) { 1361 isoconnbigsync(sk); 1362 sk->skstate = BTLISTEN; 1363 } else { --> 1364 isoconndeferaccept(pi->conn->hcon); ^^^^^^^^^^^^^^ then we're toast

1365 sk->skstate = BTCONFIG; 1366 } 1367 releasesock(sk); 1368 return 0; 1369 case BTCONNECTED: 1370 if (testbit(BTSKPASYNC,

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

HID: logitech-dj: Fix memory leak in logidjrecvswitchtodjmode()

Fix a memory leak on logidjrecvsendreport() error path.

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

md/raid5: fix deadlock that raid5d() wait for itself to clear MDSBCHANGEPENDING

Xiao reported that lvm2 test lvconvert-raid-takeover.sh can hang with small possibility, the root cause is exactly the same as commit bed9e27baf52 ("Revert "md/raid5: Wait for MDSBCHANGEPENDING in raid5d"")

However, Dan reported another hang after that, and junxiao investigated the problem and found out that this is caused by plugged bio can't issue from raid5d().

Current implementation in raid5d() has a weird dependence:

1) mdcheckrecovery() from raid5d() must hold 'reconfigmutex' to clear MDSBCHANGEPENDING; 2) raid5d() handles IO in a deadloop, until all IO are issued; 3) IO from raid5d() must wait for MDSBCHANGEPENDING to be cleared;

This behaviour is introduce before v2.6, and for consequence, if other context hold 'reconfigmutex', and mdcheckrecovery() can't update superblock, then raid5d() will waste one cpu 100% by the deadloop, until 'reconfigmutex' is released.

Refer to the implementation from raid1 and raid10, fix this problem by skipping issue IO if MDSBCHANGEPENDING is still set after mdcheckrecovery(), daemon thread will be woken up when 'reconfigmutex' is released. Meanwhile, the hang problem will be fixed as well.

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

fbdev: savage: Handle err return when savagefbcheckvar failed

The commit 04e5eac8f3ab("fbdev: savage: Error out if pixclock equals zero") checks the value of pixclock to avoid divide-by-zero error. However the function savagefbprobe doesn't handle the error return of savagefbcheckvar. When pixclock is 0, it will cause divide-by-zero error.

dma-buf/sw-sync: don't enable IRQ from syncprintobj()

bpf: Allow delete from sockmap/sockhash only if update is allowed

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

efi/unaccepted: touch soft lockup during memory accept

Commit 50e782a86c98 ("efi/unaccepted: Fix soft lockups caused by parallel memory acceptance") has released the spinlock so other CPUs can do memory acceptance in parallel and not triggers softlockup on other CPUs.

However the softlock up was intermittent shown up if the memory of the TD guest is large, and the timeout of softlockup is set to 1 second:

RIP: 0010:rawspinunlockirqrestore Call Trace: ? hrtimerrunqueues <IRQ> ? hrtimerinterrupt ? watchdogtimerfn ? sysvecapictimerinterrupt ? pfxwatchdogtimerfn ? sysvecapictimerinterrupt </IRQ> ? hrtimerrunqueues <TASK> ? hrtimerinterrupt ? asmsysvecapictimerinterrupt ? rawspinunlockirqrestore ? sysvecapictimerinterrupt ? sysvecapictimerinterrupt acceptmemory trytoacceptmemory dohugepmdanonymouspage getpagefromfreelist handlemmfault allocpages folioalloc ? tdxhypercall handlemmfault vmaallocfolio douseraddrfault dohugepmdanonymouspage excpagefault ? dohugepmdanonymouspage asmexcpagefault handlemmfault

When the local irq is enabled at the end of acceptmemory(), the softlockup detects that the watchdog on single CPU has not been fed for a while. That is to say, even other CPUs will not be blocked by spinlock, the current CPU might be stunk with local irq disabled for a while, which hurts not only nmi watchdog but also softlockup.

Chao Gao pointed out that the memory accept could be time costly and there was similar report before. Thus to avoid any softlocup detection during this stage, give the softlockup a flag to skip the timeout check at the end of acceptmemory(), by invoking touchsoftlockupwatchdog().

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

iouring: Fix release of pinned pages when iouaddrmap fails

Looking at the error path of iouaddrmap, if we fail after pinning the pages for any reasons, ret will be set to -EINVAL and the error handler won't properly release the pinned pages.

I didn't manage to trigger it without forcing a failure, but it can happen in real life when memory is heavily fragmented.

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

usb: gadget: ncm: Fix handling of zero block length packets

While connecting to a Linux host with CDCNCMNTBDEFSIZETX set to 65536, it has been observed that we receive short packets, which come at interval of 5-10 seconds sometimes and have block length zero but still contain 1-2 valid datagrams present.

According to the NCM spec:

"If wBlockLength = 0x0000, the block is terminated by a short packet. In this case, the USB transfer must still be shorter than dwNtbInMaxSize or dwNtbOutMaxSize. If exactly dwNtbInMaxSize or dwNtbOutMaxSize bytes are sent, and the size is a multiple of wMaxPacketSize for the given pipe, then no ZLP shall be sent.

wBlockLength= 0x0000 must be used with extreme care, because of the possibility that the host and device may get out of sync, and because of test issues.

wBlockLength = 0x0000 allows the sender to reduce latency by starting to send a very large NTB, and then shortening it when the sender discovers that there’s not sufficient data to justify sending a large NTB"

However, there is a potential issue with the current implementation, as it checks for the occurrence of multiple NTBs in a single giveback by verifying if the leftover bytes to be processed is zero or not. If the block length reads zero, we would process the same NTB infintely because the leftover bytes is never zero and it leads to a crash. Fix this by bailing out if block length reads zero.

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

net/handshake: Fix handshakereqdestroytest1

Recently, handshakereqdestroytest1 started failing:

Expected handshakereqdestroytest == req, but handshakereqdestroytest == 0000000000000000 req == 0000000060f99b40 not ok 11 reqdestroy works

This is because "sockrelease(sock)" was replaced with "fput(filp)" to address a memory leak. Note that sockrelease() is synchronous but fput() usually delays the final close and clean-up.

The delay is not consequential in the other cases that were changed but handshakereqdestroytest1 is testing that handshakereqcancel() followed by closing the file actually does call the ->hpdestroy method. Thus the PTREQ test at the end has to be sure that the final close is complete before it checks the pointer.

We cannot use a completion here because if ->hpdestroy is never called (ie, there is an API bug) then the test will hang.

Reported by: Guenter Roeck <linux@roeck-us.net>

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

l2tp: pass correct message length to ip6appenddata

l2tpip6sendmsg needs to avoid accounting for the transport header twice when splicing more data into an already partially-occupied skbuff.

To manage this, we check whether the skbuff contains data using skbqueueempty when deciding how much data to append using ip6appenddata.

However, the code which performed the calculation was incorrect:

ulen = len + skbqueueempty(&sk->skwritequeue) ? transhdrlen : 0;

...due to C operator precedence, this ends up setting ulen to transhdrlen for messages with a non-zero length, which results in corrupted packets on the wire.

Add parentheses to correct the calculation in line with the original intent.