The Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SCO: Fix UAF on scosocktimeout conn->sk maybe have been unlinked/freed while waiting for scoconnlock so this checks if the conn->sk is still valid by checking if it part of scosklist.(CVE-2024-50125)
In the Linux kernel, the following vulnerability has been resolved: be2net: fix potential memory leak in bexmit() The bexmit() returns NETDEVTXOK without freeing skb in case of bexmitenqueue() fails, add devkfreeskb_any() to fix it.(CVE-2024-50167)
In the Linux kernel, the following vulnerability has been resolved: net/sun382586: fix potential memory leak in sun382586sendpacket() The sun382586sendpacket() returns NETDEVTXOK without freeing skb in case of skb->len being too long, add devkfree_skb() to fix it.(CVE-2024-50168)
In the Linux kernel, the following vulnerability has been resolved: netfilter: nftpayload: sanitize offset and length before calling skbchecksum() If access to offset + length is larger than the skbuff length, then skbchecksum() triggers BUGON(). skbchecksum() internally subtracts the length parameter while iterating over skbuff, BUGON(len) at the end of it checks that the expected length to be included in the checksum calculation is fully consumed.(CVE-2024-50251)
In the Linux kernel, the following vulnerability has been resolved: net/sched: stop qdisctreereducebacklog on TCHROOT In qdisctreereducebacklog, Qdiscs with major handle ffff: are assumed to be either root or ingress. This assumption is bogus since it's valid to create egress qdiscs with major handle ffff: Budimir Markovic found that for qdiscs like DRR that maintain an active class list, it will cause a UAF with a dangling class pointer. In 066a3b5b2346, the concern was to avoid iterating over the ingress qdisc since its parent is itself. The proper fix is to stop when parent TCHROOT is reached because the only way to retrieve ingress is when a hierarchy which does not contain a ffff: major handle call into qdisclookup with TCHMAJ(TCHROOT). In the scenario where major ffff: is an egress qdisc in any of the tree levels, the updates will also propagate to TCHROOT, which then the iteration must stop. net/sched/schapi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)(CVE-2024-53057)
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix null-ptr-deref in blocktouchbuffer tracepoint Patch series "nilfs2: fix null-ptr-deref bugs on block tracepoints". This series fixes null pointer dereference bugs that occur when using nilfs2 and two block-related tracepoints. This patch (of 2): It has been reported that when using "block:blocktouchbuffer" tracepoint, touchbuffer() called from _nilfsgetfolioblock() causes a NULL pointer dereference, or a general protection fault when KASAN is enabled. This happens because since the tracepoint was added in touchbuffer(), it references the devt member bh->bbdev->bddev regardless of whether the buffer head has a pointer to a blockdevice structure. In the current implementation, the blockdevice structure is set after the function returns to the caller. Here, touchbuffer() is used to mark the folio/page that owns the buffer head as accessed, but the common search helper for folio/page used by the caller function was optimized to mark the folio/page as accessed when it was reimplemented a long time ago, eliminating the need to call touchbuffer() here in the first place. So this solves the issue by eliminating the touchbuffer() call itself.(CVE-2024-53131)
In the Linux kernel, the following vulnerability has been resolved: initramfs: avoid filename buffer overrun The initramfs filename field is defined in Documentation/driver-api/early-userspace/buffer-format.rst as: 37 cpiofile := ALGN(4) + cpioheader + filename + "\0" + ALGN(4) + data ... 55 ============= ================== ========================= 56 Field name Field size Meaning 57 ============= ================== ========================= ... 70 cnamesize 8 bytes Length of filename, including final \0 When extracting an initramfs cpio archive, the kernel's doname() path handler assumes a zero-terminated path at @collected, passing it directly to filpopen() / initmkdir() / initmknod(). If a specially crafted cpio entry carries a non-zero-terminated filename and is followed by uninitialized memory, then a file may be created with trailing characters that represent the uninitialized memory. The ability to create an initramfs entry would imply already having full control of the system, so the buffer overrun shouldn't be considered a security vulnerability. Append the output of the following bash script to an existing initramfs and observe any created /initramfstestfnameoverrunAA* path. E.g. ./reproducer.sh | gzip >> /myinitramfs It's easiest to observe non-zero uninitialized memory when the output is gzipped, as it'll overflow the heap allocated @outbuf in _gunzip(), rather than the initrdstart+initrdsize block. ---- reproducer.sh ---- nilchar="A" # change to "\0" to properly zero terminate / pad magic="070701" ino=1 mode=$(( 0100777 )) uid=0 gid=0 nlink=1 mtime=1 filesize=0 devmajor=0 devminor=1 rdevmajor=0 rdevminor=0 csum=0 fname="initramfstestfnameoverrun" namelen=$(( ${#fname} + 1 )) # plus one to account for terminator printf "%s%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%s" \ $magic $ino $mode $uid $gid $nlink $mtime $filesize \ $devmajor $devminor $rdevmajor $rdevminor $namelen $csum $fname termpadlen=$(( 1 + ((4 - ((110 + $namelen) & 3)) % 4) )) printf "%.s${nilchar}" $(seq 1 $termpadlen) ---- reproducer.sh ---- Symlink filename fields handled in dosymlink() won't overrun past the data segment, due to the explicit zero-termination of the symlink target. Fix filename buffer overrun by aborting the initramfs FSM if any cpio entry doesn't carry a zero-terminator at the expected (name_len - 1) offset.(CVE-2024-53142)
{ "severity": "High" }
{ "x86_64": [ "bpftool-4.19.90-2412.3.0.0308.oe2003sp4.x86_64.rpm", "bpftool-debuginfo-4.19.90-2412.3.0.0308.oe2003sp4.x86_64.rpm", "kernel-4.19.90-2412.3.0.0308.oe2003sp4.x86_64.rpm", "kernel-debuginfo-4.19.90-2412.3.0.0308.oe2003sp4.x86_64.rpm", "kernel-debugsource-4.19.90-2412.3.0.0308.oe2003sp4.x86_64.rpm", "kernel-devel-4.19.90-2412.3.0.0308.oe2003sp4.x86_64.rpm", "kernel-source-4.19.90-2412.3.0.0308.oe2003sp4.x86_64.rpm", "kernel-tools-4.19.90-2412.3.0.0308.oe2003sp4.x86_64.rpm", "kernel-tools-debuginfo-4.19.90-2412.3.0.0308.oe2003sp4.x86_64.rpm", "kernel-tools-devel-4.19.90-2412.3.0.0308.oe2003sp4.x86_64.rpm", "perf-4.19.90-2412.3.0.0308.oe2003sp4.x86_64.rpm", "perf-debuginfo-4.19.90-2412.3.0.0308.oe2003sp4.x86_64.rpm", "python2-perf-4.19.90-2412.3.0.0308.oe2003sp4.x86_64.rpm", "python2-perf-debuginfo-4.19.90-2412.3.0.0308.oe2003sp4.x86_64.rpm", "python3-perf-4.19.90-2412.3.0.0308.oe2003sp4.x86_64.rpm", "python3-perf-debuginfo-4.19.90-2412.3.0.0308.oe2003sp4.x86_64.rpm" ], "aarch64": [ "bpftool-4.19.90-2412.3.0.0308.oe2003sp4.aarch64.rpm", "bpftool-debuginfo-4.19.90-2412.3.0.0308.oe2003sp4.aarch64.rpm", "kernel-4.19.90-2412.3.0.0308.oe2003sp4.aarch64.rpm", "kernel-debuginfo-4.19.90-2412.3.0.0308.oe2003sp4.aarch64.rpm", "kernel-debugsource-4.19.90-2412.3.0.0308.oe2003sp4.aarch64.rpm", "kernel-devel-4.19.90-2412.3.0.0308.oe2003sp4.aarch64.rpm", "kernel-source-4.19.90-2412.3.0.0308.oe2003sp4.aarch64.rpm", "kernel-tools-4.19.90-2412.3.0.0308.oe2003sp4.aarch64.rpm", "kernel-tools-debuginfo-4.19.90-2412.3.0.0308.oe2003sp4.aarch64.rpm", "kernel-tools-devel-4.19.90-2412.3.0.0308.oe2003sp4.aarch64.rpm", "perf-4.19.90-2412.3.0.0308.oe2003sp4.aarch64.rpm", "perf-debuginfo-4.19.90-2412.3.0.0308.oe2003sp4.aarch64.rpm", "python2-perf-4.19.90-2412.3.0.0308.oe2003sp4.aarch64.rpm", "python2-perf-debuginfo-4.19.90-2412.3.0.0308.oe2003sp4.aarch64.rpm", "python3-perf-4.19.90-2412.3.0.0308.oe2003sp4.aarch64.rpm", "python3-perf-debuginfo-4.19.90-2412.3.0.0308.oe2003sp4.aarch64.rpm" ], "src": [ "kernel-4.19.90-2412.3.0.0308.oe2003sp4.src.rpm" ] }