OESA-2025-1094

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

ASoC: ops: Shift tested values in sndsocput_volsw() by +min

While the $val/$val2 values passed in from userspace are always >= 0 integers, the limits of the control can be signed integers and the $min can be non-zero and less than zero. To correctly validate $val/$val2 against platform_max, add the $min offset to val first.(CVE-2022-48917)

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

tcp: do not accept ACK of bytes we never sent

This patch is based on a detailed report and ideas from Yepeng Pan and Christian Rossow.

ACK seq validation is currently following RFC 5961 5.2 guidelines:

The ACK value is considered acceptable only if it is in the range of ((SND.UNA - MAX.SND.WND) <= SEG.ACK <= SND.NXT). All incoming segments whose ACK value doesn't satisfy the above condition MUST be discarded and an ACK sent back. It needs to be noted that RFC 793 on page 72 (fifth check) says: "If the ACK is a duplicate (SEG.ACK < SND.UNA), it can be ignored. If the ACK acknowledges something not yet sent (SEG.ACK > SND.NXT) then send an ACK, drop the segment, and return". The "ignored" above implies that the processing of the incoming data segment continues, which means the ACK value is treated as acceptable. This mitigation makes the ACK check more stringent since any ACK < SND.UNA wouldn't be accepted, instead only ACKs that are in the range ((SND.UNA - MAX.SND.WND) <= SEG.ACK <= SND.NXT) get through.

This can be refined for new (and possibly spoofed) flows, by not accepting ACK for bytes that were never sent.

This greatly improves TCP security at a little cost.

I added a Fixes: tag to make sure this patch will reach stable trees, even if the 'blamed' patch was adhering to the RFC.

tp->bytes_acked was added in linux-4.2

Following packetdrill test (courtesy of Yepeng Pan) shows the issue at hand:

0 socket(..., SOCKSTREAM, IPPROTOTCP) = 3 +0 setsockopt(3, SOLSOCKET, SOREUSEADDR, [1], 4) = 0 +0 bind(3, ..., ...) = 0 +0 listen(3, 1024) = 0

// ---------------- Handshake ------------------- //

// when window scale is set to 14 the window size can be extended to // 65535 * (2^14) = 1073725440. Linux would accept an ACK packet // with ack number in (ServerISN+1-1073725440. ServerISN+1) // ,though this ack number acknowledges some data never // sent by the server.

+0 < S 0:0(0) win 65535 <mss 1400,nop,wscale 14> +0 > S. 0:0(0) ack 1 <...> +0 < . 1:1(0) ack 1 win 65535 +0 accept(3, ..., ...) = 4

// For the established connection, we send an ACK packet, // the ack packet uses ack number 1 - 1073725300 + 2^32, // where 2^32 is used to wrap around. // Note: we used 1073725300 instead of 1073725440 to avoid possible // edge cases. // 1 - 1073725300 + 2^32 = 3221241997

// Oops, old kernels happily accept this packet. +0 < . 1:1001(1000) ack 3221241997 win 65535

// After the kernel fix the following will be replaced by a challenge ACK, // and prior malicious frame would be dropped. +0 > . 1:1(0) ack 1001(CVE-2023-52881)

A race condition was found in the Linux kernel's net/bluetooth device driver in conninfo{min,max}ageset() function. This can result in integrity overflow issue, possibly leading to bluetooth connection abnormality or denial of service.

(CVE-2024-24857)

A race condition was found in the Linux kernel's net/bluetooth in sniff{min,max}interval_set() function. This can result in a bluetooth sniffing exception issue, possibly leading denial of service.

(CVE-2024-24859)

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

cgroup/cpuset: Prevent UAF in proccpusetshow()

An UAF can happen when /proc/cpuset is read as reported in [1].

This can be reproduced by the following methods: 1.add an mdelay(1000) before acquiring the cgrouplock In the cgrouppath_ns function. 2.$cat /proc/<pid>/cpuset repeatly. 3.$mount -t cgroup -o cpuset cpuset /sys/fs/cgroup/cpuset/ $umount /sys/fs/cgroup/cpuset/ repeatly.

The race that cause this bug can be shown as below:

(umount) | (cat /proc/<pid>/cpuset) cssrelease | proccpusetshow cssreleaseworkfn | css = taskgetcss(tsk, cpusetcgrpid); cssfreerworkfn | cgrouppathns(css->cgroup, ...); cgroupdestroyroot | mutexlock(&cgroupmutex); rebindsubsystems | cgroupfreeroot | | // cgrp was freed, UAF | cgrouppathns_locked(cgrp,..);

When the cpuset is initialized, the root node topcpuset.css.cgrp will point to &cgrpdflroot.cgrp. In cgroup v1, the mount operation will allocate cgrouproot, and topcpuset.css.cgrp will point to the allocated &cgrouproot.cgrp. When the umount operation is executed, topcpuset.css.cgrp will be rebound to &cgrpdfl_root.cgrp.

The problem is that when rebinding to cgrpdflroot, there are cases where the cgrouproot allocated by setting up the root for cgroup v1 is cached. This could lead to a Use-After-Free (UAF) if it is subsequently freed. The descendant cgroups of cgroup v1 can only be freed after the css is released. However, the css of the root will never be released, yet the cgrouproot should be freed when it is unmounted. This means that obtaining a reference to the css of the root does not guarantee that css.cgrp->root will not be freed.

Fix this problem by using rcureadlock in proccpusetshow(). As cgrouproot is kfreercu after commit d23b5c577715 ("cgroup: Make operations on the cgroup rootlist RCU safe"), css->cgroup won't be freed during the critical section. To call cgrouppathnslocked, csssetlock is needed, so it is safe to replace taskgetcss with task_css.

[1] https://syzkaller.appspot.com/bug?extid=9b1ff7be974a403aa4cd(CVE-2024-43853)

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

dm cache: fix out-of-bounds access to the dirty bitset when resizing

dm-cache checks the dirty bits of the cache blocks to be dropped when shrinking the fast device, but an index bug in bitset iteration causes out-of-bounds access.

Reproduce steps:

1. create a cache device of 1024 cache blocks (128 bytes dirty bitset)

dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 131072 linear /dev/sdc 8192" dmsetup create corig --table "0 524288 linear /dev/sdc 262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"

2. shrink the fast device to 512 cache blocks, triggering out-of-bounds access to the dirty bitset (offset 0x80)

dmsetup suspend cache dmsetup reload cdata --table "0 65536 linear /dev/sdc 8192" dmsetup resume cdata dmsetup resume cache

KASAN reports:

BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0 Read of size 8 at addr ffffc900000f3080 by task dmsetup/131

(...snip...) The buggy address belongs to the virtual mapping at [ffffc900000f3000, ffffc900000f5000) created by: cache_ctr+0x176a/0x35f0

(...snip...) Memory state around the buggy address: ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8

Fix by making the index post-incremented.(CVE-2024-50279)

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

scsi: sg: Fix slab-use-after-free read in sg_release()

Fix a use-after-free bug in sg_release(), detected by syzbot with KASAN:

BUG: KASAN: slab-use-after-free in lockrelease+0x151/0xa30 kernel/locking/lockdep.c:5838 _mutexunlockslowpath+0xe2/0x750 kernel/locking/mutex.c:912 sg_release+0x1f4/0x2e0 drivers/scsi/sg.c:407

In sgrelease(), the function krefput(&sfp->fref, sgremovesfp) is called before releasing the openrellock mutex. The krefput() call may decrement the reference count of sfp to zero, triggering its cleanup through sgremovesfp(). This cleanup includes scheduling deferred work via sgremovesfp_usercontext(), which ultimately frees sfp.

After krefput(), sgrelease() continues to unlock openrellock and may reference sfp or sdp. If sfp has already been freed, this results in a slab-use-after-free error.

Move the krefput(&sfp->fref, sgremovesfp) call after unlocking the openrellock mutex. This ensures:

• No references to sfp or sdp occur after the reference count is decremented.

• Cleanup functions such as sgremovesfp() and sgremovesfpusercontext() can safely execute without impacting the mutex handling in sgrelease().

The fix has been tested and validated by syzbot. This patch closes the bug reported at the following syzkaller link and ensures proper sequencing of resource cleanup and mutex operations, eliminating the risk of use-after-free errors in sg_release().(CVE-2024-56631)

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

net: Fix icmp host relookup triggering iprtbug

arp link failure may trigger iprtbug while xfrm enabled, call trace is:

WARNING: CPU: 0 PID: 0 at net/ipv4/route.c:1241 iprtbug+0x14/0x20 Modules linked in: CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-rc6-00077-g2e1b3cc9d7f7 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:iprtbug+0x14/0x20 Call Trace: <IRQ> ipsendskb+0x14/0x40 _icmpsend+0x42d/0x6a0 ipv4linkfailure+0xe2/0x1d0 arperrorreport+0x3c/0x50 neighinvalidate+0x8d/0x100 neightimerhandler+0x2e1/0x330 calltimerfn+0x21/0x120 _runtimerbase.part.0+0x1c9/0x270 runtimersoftirq+0x4c/0x80 handlesoftirqs+0xac/0x280 irqexitrcu+0x62/0x80 sysvecapictimerinterrupt+0x77/0x90

The script below reproduces this scenario: ip xfrm policy add src 0.0.0.0/0 dst 0.0.0.0/0 \ dir out priority 0 ptype main flag localok icmp ip l a veth1 type veth ip a a 192.168.141.111/24 dev veth0 ip l s veth0 up ping 192.168.141.155 -c 1

icmproutelookup() create input routes for locally generated packets while xfrm relookup ICMP traffic.Then it will set input route (dst->out = iprtbug) to skb for DESTUNREACH.

For ICMP err triggered by locally generated packets, dst->dev of output route is loopback. Generally, xfrm relookup verification is not required on loopback interfaces (net.ipv4.conf.lo.disable_xfrm = 1).

Skip icmp relookup for locally generated packets to fix it.(CVE-2024-56647)

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

sunrpc: clear XPRTSOCKUPD_TIMEOUT when reset transport

Since transport->sock has been set to NULL during reset transport, XPRTSOCKUPDTIMEOUT also needs to be cleared. Otherwise, the xstcpsetsockettimeouts() may be triggered in xstcpsendrequest() to dereference the transport->sock that has been set to NULL.(CVE-2024-56688)

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

crypto: pcrypt - Call crypto layer directly when padatadoparallel() return -EBUSY

Since commit 8f4f68e788c3 ("crypto: pcrypt - Fix hungtask for PADATARESET"), the pcrypt encryption and decryption operations return -EAGAIN when the CPU goes online or offline. In algtest(), a WARN is generated when pcryptaeaddecrypt() or pcryptaeadencrypt() returns -EAGAIN, the unnecessary panic will occur when paniconwarn set 1. Fix this issue by calling crypto layer directly without parallelization in that case.(CVE-2024-56690)

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

ocfs2: fix slab-use-after-free due to dangling pointer dqi_priv

When mounting ocfs2 and then remounting it as read-only, a slab-use-after-free occurs after the user uses a syscall to quotagetnextquota. Specifically, sbdqinfo(sb, type)->dqi_priv is the dangling pointer.

During the remounting process, the pointer dqipriv is freed but is never set as null leaving it to be accessed. Additionally, the read-only option for remounting sets the DQUOTSUSPENDED flag instead of setting the DQUOTUSAGEENABLED flags. Moreover, later in the process of getting the next quota, the function ocfs2getnext_id is called and only checks the quota usage flags and not the quota suspended flags.

To fix this, I set dqipriv to null when it is freed after remounting with read-only and put a check for DQUOTSUSPENDED in ocfs2getnext_id.

akpm@linux-foundation.org: coding-style cleanups