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

riscv: Fix sleeping in invalid context in die()

die() can be called in exception handler, and therefore cannot sleep. However, die() takes spinlockt which can sleep with PREEMPTRT enabled. That causes the following warning:

BUG: sleeping function called from invalid context at kernel/locking/spinlockrt.c:48 inatomic(): 1, irqsdisabled(): 1, nonblock: 0, pid: 285, name: mutex preemptcount: 110001, expected: 0 RCU nest depth: 0, expected: 0 CPU: 0 UID: 0 PID: 285 Comm: mutex Not tainted 6.12.0-rc7-00022-ge19049cf7d56-dirty #234 Hardware name: riscv-virtio,qemu (DT) Call Trace: dumpbacktrace+0x1c/0x24 showstack+0x2c/0x38 dumpstacklvl+0x5a/0x72 dumpstack+0x14/0x1c mightresched+0x130/0x13a rtspinlock+0x2a/0x5c die+0x24/0x112 dotrapinsnillegal+0xa0/0xea newvmallocrestorecontexta0+0xcc/0xd8 Oops - illegal instruction [#1]

Switch to use rawspinlockt, which does not sleep even with PREEMPTRT enabled.

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.

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

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

net/sched: netem: account for backlog updates from child qdisc

In general, 'qlen' of any classful qdisc should keep track of the number of packets that the qdisc itself and all of its children holds. In case of netem, 'qlen' only accounts for the packets in its internal tfifo. When netem is used with a child qdisc, the child qdisc can use 'qdisctreereducebacklog' to inform its parent, netem, about created or dropped SKBs. This function updates 'qlen' and the backlog statistics of netem, but netem does not account for changes made by a child qdisc. 'qlen' then indicates the wrong number of packets in the tfifo. If a child qdisc creates new SKBs during enqueue and informs its parent about this, netem's 'qlen' value is increased. When netem dequeues the newly created SKBs from the child, the 'qlen' in netem is not updated. If 'qlen' reaches the configured sch->limit, the enqueue function stops working, even though the tfifo is not full.

Reproduce the bug: Ensure that the sender machine has GSO enabled. Configure netem as root qdisc and tbf as its child on the outgoing interface of the machine as follows: $ tc qdisc add dev <oif> root handle 1: netem delay 100ms limit 100 $ tc qdisc add dev <oif> parent 1:0 tbf rate 50Mbit burst 1542 latency 50ms

Send bulk TCP traffic out via this interface, e.g., by running an iPerf3 client on the machine. Check the qdisc statistics: $ tc -s qdisc show dev <oif>

Statistics after 10s of iPerf3 TCP test before the fix (note that netem's backlog > limit, netem stopped accepting packets): qdisc netem 1: root refcnt 2 limit 1000 delay 100ms Sent 2767766 bytes 1848 pkt (dropped 652, overlimits 0 requeues 0) backlog 4294528236b 1155p requeues 0 qdisc tbf 10: parent 1:1 rate 50Mbit burst 1537b lat 50ms Sent 2767766 bytes 1848 pkt (dropped 327, overlimits 7601 requeues 0) backlog 0b 0p requeues 0

Statistics after the fix: qdisc netem 1: root refcnt 2 limit 1000 delay 100ms Sent 37766372 bytes 24974 pkt (dropped 9, overlimits 0 requeues 0) backlog 0b 0p requeues 0 qdisc tbf 10: parent 1:1 rate 50Mbit burst 1537b lat 50ms Sent 37766372 bytes 24974 pkt (dropped 327, overlimits 96017 requeues 0) backlog 0b 0p requeues 0

tbf segments the GSO SKBs (tbfsegment) and updates the netem's 'qlen'. The interface fully stops transferring packets and "locks". In this case, the child qdisc and tfifo are empty, but 'qlen' indicates the tfifo is at its limit and no more packets are accepted.

This patch adds a counter for the entries in the tfifo. Netem's 'qlen' is only decreased when a packet is returned by its dequeue function, and not during enqueuing into the child qdisc. External updates to 'qlen' are thus accounted for and only the behavior of the backlog statistics changes. As in other qdiscs, 'qlen' then keeps track of how many packets are held in netem and all of its children. As before, sch->limit remains as the maximum number of packets in the tfifo. The same applies to netem's backlog statistics.

btrfs: avoid NULL pointer dereference if no valid extent tree

exfat: fix the infinite loop in exfatreaddir()

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

net/sctp: Prevent autoclose integer overflow in sctpassociationinit()

While by default maxautoclose equals to INTMAX / HZ, one may set net.sctp.maxautoclose to UINTMAX. There is code in sctpassociationinit() that can consequently trigger overflow.

drm/amd/display: Add check for granularity in dml ceil/floor helpers

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

net: fix memory leak in tcpconnrequest()

If inetcskreqskqueuehashadd() return false, tcpconnrequest() will return without free the dst memory, which allocated in afops->routereq.

Here is the kmemleak stack:

unreferenced object 0xffff8881198631c0 (size 240): comm "softirq", pid 0, jiffies 4299266571 (age 1802.392s) hex dump (first 32 bytes): 00 10 9b 03 81 88 ff ff 80 98 da bc ff ff ff ff ................ 81 55 18 bb ff ff ff ff 00 00 00 00 00 00 00 00 .U.............. backtrace: [<ffffffffb93e8d4c>] kmemcachealloc+0x60c/0xa80 [<ffffffffba11b4c5>] dstalloc+0x55/0x250 [<ffffffffba227bf6>] rtdstalloc+0x46/0x1d0 [<ffffffffba23050a>] mkrouteoutput+0x29a/0xa50 [<ffffffffba23456b>] iprouteoutputkeyhash+0x10b/0x240 [<ffffffffba2346bd>] iprouteoutputflow+0x1d/0x90 [<ffffffffba254855>] inetcskroutereq+0x2c5/0x500 [<ffffffffba26b331>] tcpconnrequest+0x691/0x12c0 [<ffffffffba27bd08>] tcprcvstateprocess+0x3c8/0x11b0 [<ffffffffba2965c6>] tcpv4dorcv+0x156/0x3b0 [<ffffffffba299c98>] tcpv4rcv+0x1cf8/0x1d80 [<ffffffffba239656>] ipprotocoldeliverrcu+0xf6/0x360 [<ffffffffba2399a6>] iplocaldeliverfinish+0xe6/0x1e0 [<ffffffffba239b8e>] iplocaldeliver+0xee/0x360 [<ffffffffba239ead>] iprcv+0xad/0x2f0 [<ffffffffba110943>] netifreceiveskbonecore+0x123/0x140

Call dstrelease() to free the dst memory when inetcskreqskqueuehashadd() return false in tcpconnrequest().

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

usb: gadget: ffs: Remove WARNON in functionfsbind

This commit addresses an issue related to below kernel panic where paniconwarn is enabled. It is caused by the unnecessary use of WARNON in functionsfsbind, which easily leads to the following scenarios.

1.adbwrite in adbd 2. UDC write via configfs ================= =====================

->usbffsopenthread() ->UDC write ->openfunctionfs() ->configfswriteiter() ->adbopen() ->gadgetdevdescUDCstore() ->adbwrite() ->usbgadgetregisterdriverowner ->driverregister() ->StartMonitor() ->busadddriver() ->adbread() ->gadgetbinddriver() <times-out without BIND event> ->configfscompositebind() ->usbaddfunction() ->openfunctionfs() ->ffsfuncbind() ->adbopen() ->functionfsbind() <ffs->state !=FFSACTIVE>

The adbopen, adbread, and adbwrite operations are invoked from the daemon, but trying to bind the function is a process that is invoked by UDC write through configfs, which opens up the possibility of a race condition between the two paths. In this race scenario, the kernel panic occurs due to the WARNON from functionfsbind when paniconwarn is enabled. This commit fixes the kernel panic by removing the unnecessary WARNON.

Kernel panic - not syncing: kernel: paniconwarn set ... [ 14.542395] Call trace: [ 14.542464] ffsfuncbind+0x1c8/0x14a8 [ 14.542468] usbaddfunction+0xcc/0x1f0 [ 14.542473] configfscompositebind+0x468/0x588 [ 14.542478] gadgetbinddriver+0x108/0x27c [ 14.542483] reallyprobe+0x190/0x374 [ 14.542488] driverprobedevice+0xa0/0x12c [ 14.542492] driverprobedevice+0x3c/0x220 [ 14.542498] driverattach+0x11c/0x1fc [ 14.542502] busforeachdev+0x104/0x160 [ 14.542506] driverattach+0x24/0x34 [ 14.542510] busadddriver+0x154/0x270 [ 14.542514] driverregister+0x68/0x104 [ 14.542518] usbgadgetregisterdriverowner+0x48/0xf4 [ 14.542523] gadgetdevdescUDCstore+0xf8/0x144 [ 14.542526] configfswriteiter+0xf0/0x138

gpio: xilinx: Convert gpiolock to raw spinlock

btrfs: add a sanity check for btrfs root in btrfssearchslot()

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

quota: flush quotareleasework upon quota writeback

One of the paths quota writeback is called from is:

freezesuper() syncfilesystem() ext4syncfs() dquotwritebackdquots()

Since we currently don't always flush the quotareleasework queue in this path, we can end up with the following race:

1. dquot are added to releasingdquots list during regular operations. 2. FS Freeze starts, however, this does not flush the quotareleasework queue. 3. Freeze completes. 4. Kernel eventually tries to flush the workqueue while FS is frozen which hits a WARNON since transaction gets started during frozen state:

ext4journalcheckstart+0x28/0x110 [ext4] (unreliable) ext4journalstartsb+0x64/0x1c0 [ext4] ext4releasedquot+0x90/0x1d0 [ext4] quotareleaseworkfn+0x43c/0x4d0

Which is the following line:

WARNON(sb->swriters.frozen == SBFREEZECOMPLETE);

Which ultimately results in generic/390 failing due to dmesg noise. This was detected on powerpc machine 15 cores.

To avoid this, make sure to flush the workqueue during dquotwritebackdquots() so we dont have any pending workitems after freeze.

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

sctp: sysctl: rtomin/max: avoid using current->nsproxy

As mentioned in a previous commit of this series, using the 'net' structure via 'current' is not recommended for different reasons:

- Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns.

- current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2).

The 'net' structure can be obtained from the table->data using containerof().

Note that table->data could also be used directly, as this is the only member needed from the 'net' structure, but that would increase the size of this fix, to use 'data' everywhere 'net->sctp.rtomin/max' is used.

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

sctp: sysctl: plpmtudprobeinterval: avoid using current->nsproxy

As mentioned in a previous commit of this series, using the 'net' structure via 'current' is not recommended for different reasons:

- Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns.

- current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2).

The 'net' structure can be obtained from the table->data using containerof().

Note that table->data could also be used directly, as this is the only member needed from the 'net' structure, but that would increase the size of this fix, to use 'data' everywhere 'net->sctp.probeinterval' is used.

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

RDMA/uverbs: Prevent integer overflow issue

In the expression "cmd.wqesize cmd.wrcount", both variables are u32 values that come from the user so the multiplication can lead to integer wrapping. Then we pass the result to uverbsrequestnextptr() which also could potentially wrap. The "cmd.sgecount sizeof(struct ibuverbssge)" multiplication can also overflow on 32bit systems although it's fine on 64bit systems.

This patch does two things. First, I've re-arranged the condition in uverbsrequestnextptr() so that the use controlled variable "len" is on one side of the comparison by itself without any math. Then I've modified all the callers to use sizemul() for the multiplications.

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

netfilter: IDLETIMER: Fix for possible ABBA deadlock

Deletion of the last rule referencing a given idletimer may happen at the same time as a read of its file in sysfs:

| ====================================================== | WARNING: possible circular locking dependency detected | 6.12.0-rc7-01692-g5e9a28f41134-dirty #594 Not tainted | ------------------------------------------------------ | iptables/3303 is trying to acquire lock: | ffff8881057e04b8 (kn->active#48){++++}-{0:0}, at: kernfsremove+0x20 | | but task is already holding lock: | ffffffffa0249068 (listmutex){+.+.}-{3:3}, at: idletimertgdestroyv] | | which lock already depends on the new lock.

A simple reproducer is:

| #!/bin/bash | | while true; do | iptables -A INPUT -i foo -j IDLETIMER --timeout 10 --label "testme" | iptables -D INPUT -i foo -j IDLETIMER --timeout 10 --label "testme" | done & | while true; do | cat /sys/class/xtidletimer/timers/testme >/dev/null | done

Avoid this by freeing listmutex right after deleting the element from the list, then continuing with the teardown.

Drivers: hv: util: Avoid accessing a ringbuffer not initialized yet

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

scsi: megaraidsas: Fix for a potential deadlock

This fixes a 'possible circular locking dependency detected' warning CPU0 CPU1 ---- ---- lock(&instance->resetmutex); lock(&shost->scanmutex); lock(&instance->resetmutex); lock(&shost->scanmutex);

Fix this by temporarily releasing the resetmutex.

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.

bpf,perf: Fix invalid progarray access in perfeventdetachbpfprog

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

netfilter: conntrack: clamp maximum hashtable size to INTMAX

Use INTMAX as maximum size for the conntrack hashtable. Otherwise, it is possible to hit WARNONONCE in kvmallocnodenoprof() when resizing hashtable because GFPNOWARN is unset. See:

0708a0afe291 ("mm: Consider GFPNOWARN flag for oversized kvmalloc() calls")

Note: hashtable resize is only possible from initnetns.

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

ipvs: fix UB due to uninitialized stack access in ipvsprotocolinit()

Under certain kernel configurations when building with Clang/LLVM, the compiler does not generate a return or jump as the terminator instruction for ipvsprotocolinit(), triggering the following objtool warning during build time:

vmlinux.o: warning: objtool: ipvsprotocolinit() falls through to next function initstubkmodipvsrr935123ipvsrrinit6()

At runtime, this either causes an oops when trying to load the ipvs module or a boot-time panic if ipvs is built-in. This same issue has been reported by the Intel kernel test robot previously.

Digging deeper into both LLVM and the kernel code reveals this to be a undefined behavior problem. ipvsprotocolinit() uses a on-stack buffer of 64 chars to store the registered protocol names and leaves it uninitialized after definition. The function calls strnlen() when concatenating protocol names into the buffer. With CONFIGFORTIFYSOURCE strnlen() performs an extra step to check whether the last byte of the input char buffer is a null character (commit 3009f891bb9f ("fortify: Allow strlen() and strnlen() to pass compile-time known lengths")). This, together with possibly other configurations, cause the following IR to be generated:

define hidden i32 @ipvsprotocolinit() localunnamedaddr #5 section ".init.text" align 16 !kcfitype !29 { %1 = alloca [64 x i8], align 16 ...

14: ; preds = %11 %15 = getelementptr inbounds i8, ptr %1, i64 63 %16 = load i8, ptr %15, align 1 %17 = tail call i1 @llvm.is.constant.i8(i8 %16) %18 = icmp eq i8 %16, 0 %19 = select i1 %17, i1 %18, i1 false br i1 %19, label %20, label %23

20: ; preds = %14 %21 = call i64 @strlen(ptr noundef nonnull dereferenceable(1) %1) #23 ...

23: ; preds = %14, %11, %20 %24 = call i64 @strnlen(ptr noundef nonnull dereferenceable(1) %1, i64 noundef 64) #24 ... }

The above code calculates the address of the last char in the buffer (value %15) and then loads from it (value %16). Because the buffer is never initialized, the LLVM GVN pass marks value %16 as undefined:

%13 = getelementptr inbounds i8, ptr %1, i64 63 br i1 undef, label %14, label %17

This gives later passes (SCCP, in particular) more DCE opportunities by propagating the undef value further, and eventually removes everything after the load on the uninitialized stack location:

define hidden i32 @ipvsprotocolinit() localunnamedaddr #0 section ".init.text" align 16 !kcfitype !11 { %1 = alloca [64 x i8], align 16 ...

12: ; preds = %11 %13 = getelementptr inbounds i8, ptr %1, i64 63 unreachable }

In this way, the generated native code will just fall through to the next function, as LLVM does not generate any code for the unreachable IR instruction and leaves the function without a terminator.

Zero the on-stack buffer to avoid this possible UB.

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

x86/xen: don't do PV iret hypercall through hypercall page

Instead of jumping to the Xen hypercall page for doing the iret hypercall, directly code the required sequence in xen-asm.S.

This is done in preparation of no longer using hypercall page at all, as it has shown to cause problems with speculation mitigations.

This is part of XSA-466 / CVE-2024-53241.

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

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

platform/x86/amd/pmc: Only disable IRQ1 wakeup where i8042 actually enabled it

Wakeup for IRQ1 should be disabled only in cases where i8042 had actually enabled it, otherwise "wakedepth" for this IRQ will try to drop below zero and there will be an unpleasant WARN() logged:

kernel: atkbd serio0: Disabling IRQ1 wakeup source to avoid platform firmware bug kernel: ------------[ cut here ]------------ kernel: Unbalanced IRQ 1 wake disable kernel: WARNING: CPU: 10 PID: 6431 at kernel/irq/manage.c:920 irqsetirqwake+0x147/0x1a0

The PMC driver uses DEFINESIMPLEDEVPMOPS() to define its devpmops which sets amdpmcsuspendhandler() to the .suspend, .freeze, and .poweroff handlers. i8042pmsuspend(), however, is only set as the .suspend handler.

Fix the issue by call PMC suspend handler only from the same set of devpmops handlers as i8042pmsuspend(), which currently means just the .suspend handler.

To reproduce this issue try hibernating (S4) the machine after a fresh boot without putting it into s2idle first.

[ij: edited the commit message.]

fs: relax assertions on failure to encode file handles

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:

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:

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.