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

platform/x86: dell-uart-backlight: fix serdev race

The delluartblserdevprobe() function calls devmserdevdeviceopen() before setting the client ops via serdevdevicesetclientops(). This ordering can trigger a NULL pointer dereference in the serdev controller's receivebuf handler, as it assumes serdev->ops is valid when SERPORTACTIVE is set.

This is similar to the issue fixed in commit 5e700b384ec1 ("platform/chrome: crosecuart: properly fix race condition") where devmserdevdeviceopen() was called before fully initializing the device.

Fix the race by ensuring client ops are set before enabling the port via devmserdevdeviceopen().

Note, serdevdevicesetbaudrate() and serdevdevicesetflowcontrol() calls should be after the devmserdevdeviceopen() call.

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

mm: clear uffd-wp PTE/PMD state on mremap()

When mremap()ing a memory region previously registered with userfaultfd as write-protected but without UFFDFEATUREEVENTREMAP, an inconsistency in flag clearing leads to a mismatch between the vma flags (which have uffd-wp cleared) and the pte/pmd flags (which do not have uffd-wp cleared). This mismatch causes a subsequent mprotect(PROTWRITE) to trigger a warning in pagetablecheckpteflags() due to setting the pte to writable while uffd-wp is still set.

Fix this by always explicitly clearing the uffd-wp pte/pmd flags on any such mremap() so that the values are consistent with the existing clearing of VMUFFDWP. Be careful to clear the logical flag regardless of its physical form; a PTE bit, a swap PTE bit, or a PTE marker. Cover PTE, huge PMD and hugetlb paths.

fs/proc: fix softlockup in readvmcore (part 2)

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

scsi: storvsc: Ratelimit warning logs to prevent VM denial of service

If there's a persistent error in the hypervisor, the SCSI warning for failed I/O can flood the kernel log and max out CPU utilization, preventing troubleshooting from the VM side. Ratelimit the warning so it doesn't DoS the VM.

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

USB: serial: quatech2: fix null-ptr-deref in qt2processreadurb()

This patch addresses a null-ptr-deref in qt2processreadurb() due to an incorrect bounds check in the following:

if (newport > serial->numports) { deverr(&port->dev, "%s - port change to invalid port: %i\n", func, newport); break; }

The condition doesn't account for the valid range of the serial->port buffer, which is from 0 to serial->numports - 1. When newport is equal to serial->numports, the assignment of "port" in the following code is out-of-bounds and NULL:

serialpriv->currentport = newport; port = serial->port[serialpriv->currentport];

The fix checks if newport is greater than or equal to serial->numports indicating it is out-of-bounds.

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

drm/amd/display: Initialize denominator defaults to 1

[WHAT & HOW] Variables, used as denominators and maybe not assigned to other values, should be initialized to non-zero to avoid DIVIDEBYZERO, as reported by Coverity.

(cherry picked from commit e2c4c6c10542ccfe4a0830bb6c9fd5b177b7bbb7)

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

platform/x86: lenovo-yoga-tab2-pro-1380-fastcharger: fix serdev race

The yt21380fcserdevprobe() function calls devmserdevdeviceopen() before setting the client ops via serdevdevicesetclientops(). This ordering can trigger a NULL pointer dereference in the serdev controller's receivebuf handler, as it assumes serdev->ops is valid when SERPORTACTIVE is set.

This is similar to the issue fixed in commit 5e700b384ec1 ("platform/chrome: crosecuart: properly fix race condition") where devmserdevdeviceopen() was called before fully initializing the device.

Fix the race by ensuring client ops are set before enabling the port via devmserdevdeviceopen().

Note, serdevdevicesetbaudrate() and serdevdevicesetflowcontrol() calls should be after the devmserdevdeviceopen() call.

gpio: xilinx: Convert gpiolock to raw spinlock

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

irqchip/gic-v3-its: Don't enable interrupts in itsirqsetvcpuaffinity()

The following call-chain leads to enabling interrupts in a nested interrupt disabled section:

irqsetvcpuaffinity() irqgetdesclock() rawspinlockirqsave() <--- Disable interrupts itsirqsetvcpuaffinity() guard(rawspinlockirq) <--- Enables interrupts when leaving the guard() irqputdescunlock() <--- Warns because interrupts are enabled

This was broken in commit b97e8a2f7130, which replaced the original rawspin[un]lock() pair with guard(rawspinlockirq).

Fix the issue by using guard(rawspinlock).

[ tglx: Massaged change log ]

bpf: Fix bpfskselectreuseport() memory leak

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

openvswitch: fix lockup on tx to unregistering netdev with carrier

Commit in a fixes tag attempted to fix the issue in the following sequence of calls:

dooutput -> ovsvportsend -> devqueuexmit -> devqueuexmit -> netdevcorepicktx -> skbtxhash

When device is unregistering, the 'dev->realnumtxqueues' goes to zero and the 'while (unlikely(hash >= qcount))' loop inside the 'skbtxhash' becomes infinite, locking up the core forever.

But unfortunately, checking just the carrier status is not enough to fix the issue, because some devices may still be in unregistering state while reporting carrier status OK.

One example of such device is a net/dummy. It sets carrier ON on start, but it doesn't implement .ndostop to set the carrier off. And it makes sense, because dummy doesn't really have a carrier. Therefore, while this device is unregistering, it's still easy to hit the infinite loop in the skbtxhash() from the OVS datapath. There might be other drivers that do the same, but dummy by itself is important for the OVS ecosystem, because it is frequently used as a packet sink for tcpdump while debugging OVS deployments. And when the issue is hit, the only way to recover is to reboot.

Fix that by also checking if the device is running. The running state is handled by the net core during unregistering, so it covers unregistering case better, and we don't really need to send packets to devices that are not running anyway.

While only checking the running state might be enough, the carrier check is preserved. The running and the carrier states seem disjoined throughout the code and different drivers. And other core functions like devdirectxmit() check both before attempting to transmit a packet. So, it seems safer to check both flags in OVS as well.

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

btrfs: add the missing error handling inside getcanonicaldevpath

Inside function getcanonicaldevpath(), we call dpath() to get the final device path.

But dpath() can return error, and in that case the next strscpy() call will trigger an invalid memory access.

Add back the missing error handling for dpath().

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

net/mlx5: Clear port select structure when fail to create

Clear the port select structure on error so no stale values left after definers are destroyed. That's because the mlx5lagdestroydefiners() always try to destroy all lag definers in the ttmap, so in the flow below lag definers get double-destroyed and cause kernel crash:

mlx5lagportselcreate() mlx5lagcreatedefiners() mlx5lagcreatedefiner() <- Failed on tt 1 mlx5lagdestroydefiners() <- definers[tt=0] gets destroyed mlx5lagportselcreate() mlx5lagcreatedefiners() mlx5lagcreatedefiner() <- Failed on tt 0 mlx5lagdestroydefiners() <- definers[tt=0] gets double-destroyed

Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault Data abort info: ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 64k pages, 48-bit VAs, pgdp=0000000112ce2e00 [0000000000000008] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP Modules linked in: iptableraw bonding ipgre ip6gre gre ip6tunnel tunnel6 geneve ip6udptunnel udptunnel ipip tunnel4 iptunnel rdmaucm(OE) rdmacm(OE) iwcm(OE) ibipoib(OE) ibcm(OE) ibumad(OE) mlx5ib(OE) ibuverbs(OE) mlx5fwctl(OE) fwctl(OE) mlx5core(OE) mlxdevm(OE) ibcore(OE) mlxfw(OE) memtrack(OE) mlxcompat(OE) openvswitch nsh nfconncount psample xtconntrack xtMASQUERADE nfconntracknetlink nfnetlink xfrmuser xfrmalgo xtaddrtype iptablefilter iptablenat nfnat nfconntrack nfdefragipv6 nfdefragipv4 brnetfilter bridge stp llc netconsole overlay efipstore schfqcodel zram iptables crct10difce qemufwcfg fuse ipv6 crcccitt [last unloaded: mlxcompat(OE)] CPU: 3 UID: 0 PID: 217 Comm: kworker/u53:2 Tainted: G OE 6.11.0+ #2 Tainted: [O]=OOTMODULE, [E]=UNSIGNEDMODULE Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 Workqueue: mlx5lag mlx5dobondwork [mlx5core] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mlx5delflowrules+0x24/0x2c0 [mlx5core] lr : mlx5lagdestroydefiner+0x54/0x100 [mlx5core] sp : ffff800085fafb00 x29: ffff800085fafb00 x28: ffff0000da0c8000 x27: 0000000000000000 x26: ffff0000da0c8000 x25: ffff0000da0c8000 x24: ffff0000da0c8000 x23: ffff0000c31f81a0 x22: 0400000000000000 x21: ffff0000da0c8000 x20: 0000000000000000 x19: 0000000000000001 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000ffff8b0c9350 x14: 0000000000000000 x13: ffff800081390d18 x12: ffff800081dc3cc0 x11: 0000000000000001 x10: 0000000000000b10 x9 : ffff80007ab7304c x8 : ffff0000d00711f0 x7 : 0000000000000004 x6 : 0000000000000190 x5 : ffff00027edb3010 x4 : 0000000000000000 x3 : 0000000000000000 x2 : ffff0000d39b8000 x1 : ffff0000d39b8000 x0 : 0400000000000000 Call trace: mlx5delflowrules+0x24/0x2c0 [mlx5core] mlx5lagdestroydefiner+0x54/0x100 [mlx5core] mlx5lagdestroydefiners+0xa0/0x108 [mlx5core] mlx5lagportselcreate+0x2d4/0x6f8 [mlx5core] mlx5activatelag+0x60c/0x6f8 [mlx5core] mlx5dobondwork+0x284/0x5c8 [mlx5core] processonework+0x170/0x3e0 workerthread+0x2d8/0x3e0 kthread+0x11c/0x128 retfromfork+0x10/0x20 Code: a9025bf5 aa0003f6 a90363f7 f90023f9 (f9400400) ---[ end trace 0000000000000000 ]---

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

net/mlx5e: Fix inversion dependency warning while enabling IPsec tunnel

Attempt to enable IPsec packet offload in tunnel mode in debug kernel generates the following kernel panic, which is happening due to two issues: 1. In SA add section, the should be bh() variant when marking SA mode. 2. There is not needed flushworkqueue in SA delete routine. It is not needed as at this stage as it is removed from SADB and the running work will be canceled later in SA free.

===================================================== WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected 6.12.0+ #4 Not tainted ----------------------------------------------------- charon/1337 [HC0[0]:SC0[4]:HE1:SE0] is trying to acquire: ffff88810f365020 (&xa->xalock#24){+.+.}-{3:3}, at: mlx5exfrmdelstate+0xca/0x1e0 [mlx5core]

and this task is already holding: ffff88813e0f0d48 (&x->lock){+.-.}-{3:3}, at: xfrmstatedelete+0x16/0x30 which would create a new lock dependency: (&x->lock){+.-.}-{3:3} -> (&xa->xalock#24){+.+.}-{3:3}

but this new dependency connects a SOFTIRQ-irq-safe lock: (&x->lock){+.-.}-{3:3}

... which became SOFTIRQ-irq-safe at: lockacquire+0x1be/0x520 rawspinlockbh+0x34/0x40 xfrmtimerhandler+0x91/0xd70 hrtimerrunqueues+0x1dd/0xa60 hrtimerrunsoftirq+0x146/0x2e0 handlesoftirqs+0x266/0x860 irqexitrcu+0x115/0x1a0 sysvecapictimerinterrupt+0x6e/0x90 asmsysvecapictimerinterrupt+0x16/0x20 defaultidle+0x13/0x20 defaultidlecall+0x67/0xa0 doidle+0x2da/0x320 cpustartupentry+0x50/0x60 startsecondary+0x213/0x2a0 commonstartup64+0x129/0x138

to a SOFTIRQ-irq-unsafe lock: (&xa->xalock#24){+.+.}-{3:3}

... which became SOFTIRQ-irq-unsafe at: ... lockacquire+0x1be/0x520 rawspinlock+0x2c/0x40 xasetmark+0x70/0x110 mlx5exfrmaddstate+0xe48/0x2290 [mlx5core] xfrmdevstateadd+0x3bb/0xd70 xfrmaddsa+0x2451/0x4a90 xfrmuserrcvmsg+0x493/0x880 netlinkrcvskb+0x12e/0x380 xfrmnetlinkrcv+0x6d/0x90 netlinkunicast+0x42f/0x740 netlinksendmsg+0x745/0xbe0 socksendmsg+0xc5/0x190 syssendto+0x1fe/0x2c0 x64syssendto+0xdc/0x1b0 dosyscall64+0x6d/0x140 entrySYSCALL64afterhwframe+0x4b/0x53

other info that might help us debug this:

Possible interrupt unsafe locking scenario:

CPU0 CPU1 ---- ---- lock(&xa->xalock#24); localirqdisable(); lock(&x->lock); lock(&xa->xalock#24); <Interrupt> lock(&x->lock);

DEADLOCK

2 locks held by charon/1337: #0: ffffffff87f8f858 (&net->xfrm.xfrmcfgmutex){+.+.}-{4:4}, at: xfrmnetlinkrcv+0x5e/0x90 #1: ffff88813e0f0d48 (&x->lock){+.-.}-{3:3}, at: xfrmstatedelete+0x16/0x30

the dependencies between SOFTIRQ-irq-safe lock and the holding lock: -> (&x->lock){+.-.}-{3:3} ops: 29 { HARDIRQ-ON-W at: lockacquire+0x1be/0x520 rawspinlockbh+0x34/0x40 xfrmallocspi+0xc0/0xe60 xfrmallocuserspi+0x5f6/0xbc0 xfrmuserrcvmsg+0x493/0x880 netlinkrcvskb+0x12e/0x380 xfrmnetlinkrcv+0x6d/0x90 netlinkunicast+0x42f/0x740 netlinksendmsg+0x745/0xbe0 socksendmsg+0xc5/0x190 syssendto+0x1fe/0x2c0 x64syssendto+0xdc/0x1b0 dosyscall64+0x6d/0x140 entrySYSCALL64afterhwframe+0x4b/0x53 IN-SOFTIRQ-W at: lockacquire+0x1be/0x520 rawspinlockbh+0x34/0x40 xfrmtimerhandler+0x91/0xd70 hrtimerrunqueues+0x1dd/0xa60 ---truncated---

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

afs: Fix merge preference rule failure condition

syzbot reported a lock held when returning to userspace[1]. This is because if argc is less than 0 and the function returns directly, the held inode lock is not released.

Fix this by store the error in ret and jump to done to clean up instead of returning directly.

[dh: Modified Lizhi Xu's original patch to make it honour the error code from afssplitstring()]

[1] WARNING: lock held when returning to user space! 6.13.0-rc3-syzkaller-00209-g499551201b5f #0 Not tainted ------------------------------------------------ syz-executor133/5823 is leaving the kernel with locks still held! 1 lock held by syz-executor133/5823: #0: ffff888071cffc00 (&sb->stype->imutexkey#9){++++}-{4:4}, at: inodelock include/linux/fs.h:818 [inline] #0: ffff888071cffc00 (&sb->stype->imutexkey#9){++++}-{4:4}, at: afsprocaddrprefswrite+0x2bb/0x14e0 fs/afs/addrprefs.c:388

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

vsock/bpf: return early if transport is not assigned

Some of the core functions can only be called if the transport has been assigned.

As Michal reported, a socket might have the transport at NULL, for example after a failed connect(), causing the following trace:

BUG: kernel NULL pointer dereference, address: 00000000000000a0 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page PGD 12faf8067 P4D 12faf8067 PUD 113670067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 15 UID: 0 PID: 1198 Comm: a.out Not tainted 6.13.0-rc2+ RIP: 0010:vsockconnectiblehasdata+0x1f/0x40 Call Trace: vsockbpfrecvmsg+0xca/0x5e0 sockrecvmsg+0xb9/0xc0 sysrecvfrom+0xb3/0x130 x64sysrecvfrom+0x20/0x30 dosyscall64+0x93/0x180 entrySYSCALL64afterhwframe+0x76/0x7e

So we need to check the vsk->transport in vsockbpfrecvmsg(), especially for connected sockets (stream/seqpacket) as we already do in vsockconnectiblerecvmsg().

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

pmdomain: imx8mp-blk-ctrl: add missing loop break condition

Currently imx8mpblkctrlremove() will continue the for loop until an out-of-bounds exception occurs.

pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : devpmdomaindetach+0x8/0x48 lr : imx8mpblkctrlshutdown+0x58/0x90 sp : ffffffc084f8bbf0 x29: ffffffc084f8bbf0 x28: ffffff80daf32ac0 x27: 0000000000000000 x26: ffffffc081658d78 x25: 0000000000000001 x24: ffffffc08201b028 x23: ffffff80d0db9490 x22: ffffffc082340a78 x21: 00000000000005b0 x20: ffffff80d19bc180 x19: 000000000000000a x18: ffffffffffffffff x17: ffffffc080a39e08 x16: ffffffc080a39c98 x15: 4f435f464f006c72 x14: 0000000000000004 x13: ffffff80d0172110 x12: 0000000000000000 x11: ffffff80d0537740 x10: ffffff80d05376c0 x9 : ffffffc0808ed2d8 x8 : ffffffc084f8bab0 x7 : 0000000000000000 x6 : 0000000000000000 x5 : ffffff80d19b9420 x4 : fffffffe03466e60 x3 : 0000000080800077 x2 : 0000000000000000 x1 : 0000000000000001 x0 : 0000000000000000 Call trace: devpmdomaindetach+0x8/0x48 platformshutdown+0x2c/0x48 deviceshutdown+0x158/0x268 kernelrestartprepare+0x40/0x58 kernelkexec+0x58/0xe8 dosysreboot+0x198/0x258 arm64sysreboot+0x2c/0x40 invokesyscall+0x5c/0x138 el0svccommon.constprop.0+0x48/0xf0 doel0svc+0x24/0x38 el0svc+0x38/0xc8 el0t64synchandler+0x120/0x130 el0t64sync+0x190/0x198 Code: 8128c2d0 ffffffc0 aa1e03e9 d503201f

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

iomap: avoid avoid truncating 64-bit offset to 32 bits

on 32-bit kernels, iomapwritedelallocscan() was inadvertently using a 32-bit position due to folionextindex() returning an unsigned long. This could lead to an infinite loop when writing to an xfs filesystem.

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

vsock: prevent null-ptr-deref in vsock[hasdata|hasspace]

Recent reports have shown how we sometimes call vsockhasdata() when a vsock socket has been de-assigned from a transport (see attached links), but we shouldn't.

Previous commits should have solved the real problems, but we may have more in the future, so to avoid null-ptr-deref, we can return 0 (no space, no data available) but with a warning.

This way the code should continue to run in a nearly consistent state and have a warning that allows us to debug future problems.

filemap: avoid truncating 64-bit offset to 32 bits

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

mac802154: check local interfaces before deleting sdata list

syzkaller reported a corrupted list in ieee802154ifremove. [1]

Remove an IEEE 802.15.4 network interface after unregister an IEEE 802.15.4 hardware device from the system.

CPU0 CPU1 ==== ==== genlfamilyrcvmsgdoit ieee802154unregisterhw ieee802154deliface ieee802154removeinterfaces rdevdelvirtualintfdeprecated listdel(&sdata->list) ieee802154ifremove listdelrcu

The net device has been unregistered, since the rcu grace period, unregistration must be run before ieee802154ifremove.

To avoid this issue, add a check for local->interfaces before deleting sdata list.

[1] kernel BUG at lib/listdebug.c:58! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 UID: 0 PID: 6277 Comm: syz-executor157 Not tainted 6.12.0-rc6-syzkaller-00005-g557329bcecc2 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:listdelentryvalidorreport+0xf4/0x140 lib/listdebug.c:56 Code: e8 a1 7e 00 07 90 0f 0b 48 c7 c7 e0 37 60 8c 4c 89 fe e8 8f 7e 00 07 90 0f 0b 48 c7 c7 40 38 60 8c 4c 89 fe e8 7d 7e 00 07 90 <0f> 0b 48 c7 c7 a0 38 60 8c 4c 89 fe e8 6b 7e 00 07 90 0f 0b 48 c7 RSP: 0018:ffffc9000490f3d0 EFLAGS: 00010246 RAX: 000000000000004e RBX: dead000000000122 RCX: d211eee56bb28d00 RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000 RBP: ffff88805b278dd8 R08: ffffffff8174a12c R09: 1ffffffff2852f0d R10: dffffc0000000000 R11: fffffbfff2852f0e R12: dffffc0000000000 R13: dffffc0000000000 R14: dead000000000100 R15: ffff88805b278cc0 FS: 0000555572f94380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000056262e4a3000 CR3: 0000000078496000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> listdelentryvalid include/linux/list.h:124 [inline] listdelentry include/linux/list.h:215 [inline] listdelrcu include/linux/rculist.h:157 [inline] ieee802154ifremove+0x86/0x1e0 net/mac802154/iface.c:687 rdevdelvirtualintfdeprecated net/ieee802154/rdev-ops.h:24 [inline] ieee802154deliface+0x2c0/0x5c0 net/ieee802154/nl-phy.c:323 genlfamilyrcvmsgdoit net/netlink/genetlink.c:1115 [inline] genlfamilyrcvmsg net/netlink/genetlink.c:1195 [inline] genlrcvmsg+0xb14/0xec0 net/netlink/genetlink.c:1210 netlinkrcvskb+0x1e3/0x430 net/netlink/afnetlink.c:2551 genlrcv+0x28/0x40 net/netlink/genetlink.c:1219 netlinkunicastkernel net/netlink/afnetlink.c:1331 [inline] netlinkunicast+0x7f6/0x990 net/netlink/afnetlink.c:1357 netlinksendmsg+0x8e4/0xcb0 net/netlink/afnetlink.c:1901 socksendmsgnosec net/socket.c:729 [inline] socksendmsg+0x221/0x270 net/socket.c:744 syssendmsg+0x52a/0x7e0 net/socket.c:2607 syssendmsg net/socket.c:2661 [inline] syssendmsg+0x292/0x380 net/socket.c:2690 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f

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

virtio-blk: don't keep queue frozen during system suspend

Commit 4ce6e2db00de ("virtio-blk: Ensure no requests in virtqueues before deleting vqs.") replaces queue quiesce with queue freeze in virtio-blk's PM callbacks. And the motivation is to drain inflight IOs before suspending.

block layer's queue freeze looks very handy, but it is also easy to cause deadlock, such as, any attempt to call into bioqueueenter() may run into deadlock if the queue is frozen in current context. There are all kinds of ->suspend() called in suspend context, so keeping queue frozen in the whole suspend context isn't one good idea. And Marek reported lockdep warning[1] caused by virtio-blk's freeze queue in virtblkfreeze().

[1] https://lore.kernel.org/linux-block/ca16370e-d646-4eee-b9cc-87277c89c43c@samsung.com/

Given the motivation is to drain in-flight IOs, it can be done by calling freeze & unfreeze, meantime restore to previous behavior by keeping queue quiesced during suspend.

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

net/mlx5: Fix variable not being completed when function returns

When cmdallocindex(), fails cmdworkhandler() needs to complete ent->slotted before returning early. Otherwise the task which issued the command may hang:

mlx5core 0000:01:00.0: cmdworkhandler:877:(pid 3880418): failed to allocate command entry INFO: task kworker/13:2:4055883 blocked for more than 120 seconds. Not tainted 4.19.90-25.44.v2101.ky10.aarch64 #1 "echo 0 > /proc/sys/kernel/hungtasktimeoutsecs" disables this message. kworker/13:2 D 0 4055883 2 0x00000228 Workqueue: events mlx5etxdimwork [mlx5core] Call trace: switchto+0xe8/0x150 schedule+0x2a8/0x9b8 schedule+0x2c/0x88 scheduletimeout+0x204/0x478 waitforcommon+0x154/0x250 waitforcompletion+0x28/0x38 cmdexec+0x7a0/0xa00 [mlx5core] mlx5cmdexec+0x54/0x80 [mlx5core] mlx5coremodifycq+0x6c/0x80 [mlx5core] mlx5coremodifycqmoderation+0xa0/0xb8 [mlx5core] mlx5etxdimwork+0x54/0x68 [mlx5core] processonework+0x1b0/0x448 workerthread+0x54/0x468 kthread+0x134/0x138 retfromfork+0x10/0x18

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

ksmbd: fix unexpectedly changed path in ksmbdvfskernpathlocked

When ksmbdvfskernpathlocked met an error and it is not the last entry, it will exit without restoring changed path buffer. But later this buffer may be used as the filename for creation.

btrfs: avoid NULL pointer dereference if no valid extent tree

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

schedext: Replace rqlock() to rawspinrqlock() in scxopsbypass()

scxopsbypass() iterates all CPUs to re-enqueue all the scx tasks. For each CPU, it acquires a lock using rqlock() regardless of whether a CPU is offline or the CPU is currently running a task in a higher scheduler class (e.g., deadline). The rqlock() is supposed to be used for online CPUs, and the use of rqlock() may trigger an unnecessary warning in rqpinlock(). Therefore, replace rqlock() to rawspinrqlock() in scxopsbypass().

Without this change, we observe the following warning:

===== START ===== [ 6.615205] rq->balancecallback && rq->balancecallback != &balancepushcallback [ 6.615208] WARNING: CPU: 2 PID: 0 at kernel/sched/sched.h:1730 schedule+0x1130/0x1c90 ===== END =====

hwmon: (drivetemp) Fix driver producing garbage data when SCSI errors occur

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

iio: adc: ti-ads1298: Add NULL check in ads1298init

devmkasprintf() can return a NULL pointer on failure. A check on the return value of such a call in ads1298init() is missing. Add it.

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

netfs: Fix ceph copy to cache on write-begin

At the end of netfsunlockreadfolio() in which folios are marked appropriately for copying to the cache (either with by being marked dirty and having their private data set or by having PGprivate2 set) and then unlocked, the folioqueue struct has the entry pointing to the folio cleared. This presents a problem for netfspgpriv2writetothecache(), which is used to write folios marked with PGprivate2 to the cache as it expects to be able to trawl the folioqueue list thereafter to find the relevant folios, leading to a hang.

Fix this by not clearing the folioqueue entry if we're going to do the deprecated copy-to-cache. The clearance will be done instead as the folios are written to the cache.

This can be reproduced by starting cachefiles, mounting a ceph filesystem with "-o fsc" and writing to it.

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

netfs: Fix the (non-)cancellation of copy when cache is temporarily disabled

When the caching for a cookie is temporarily disabled (e.g. due to a DIO write on that file), future copying to the cache for that file is disabled until all fds open on that file are closed. However, if netfslib is using the deprecated PGprivate2 method (such as is currently used by ceph), and decides it wants to copy to the cache, netfsadvancewrite() will just bail at the first check seeing that the cache stream is unavailable, and indicate that it dealt with all the content.

This means that we have no subrequests to provide notifications to drive the state machine or even to pin the request and the request just gets discarded, leaving the folios with PGprivate2 set.

Fix this by jumping directly to cancel the request if the cache is not available. That way, we don't remove mark3 from the folioqueue list and netfspgpriv2cancel() will clean up the folios.

This was found by running the generic/013 xfstest against ceph with an active cache and the "-o fsc" option passed to ceph. That would usually hang