{"schema_version":"1.7.2","id":"OESA-2024-2570","modified":"2024-12-20T13:07:46Z","published":"2024-12-20T13:07:46Z","upstream":["CVE-2024-50125","CVE-2024-50167","CVE-2024-50168","CVE-2024-50251","CVE-2024-53057","CVE-2024-53131","CVE-2024-53142"],"summary":"kernel security update","details":"The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  Bluetooth: SCO: Fix UAF on sco_sock_timeout  conn-\u0026gt;sk maybe have been unlinked/freed while waiting for sco_conn_lock so this checks if the conn-\u0026gt;sk is still valid by checking if it part of sco_sk_list.(CVE-2024-50125)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  be2net: fix potential memory leak in be_xmit()  The be_xmit() returns NETDEV_TX_OK without freeing skb in case of be_xmit_enqueue() fails, add dev_kfree_skb_any() to fix it.(CVE-2024-50167)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  net/sun3_82586: fix potential memory leak in sun3_82586_send_packet()  The sun3_82586_send_packet() returns NETDEV_TX_OK without freeing skb in case of skb-\u0026gt;len being too long, add dev_kfree_skb() to fix it.(CVE-2024-50168)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  netfilter: nft_payload: sanitize offset and length before calling skb_checksum()  If access to offset + length is larger than the skbuff length, then skb_checksum() triggers BUG_ON().  skb_checksum() internally subtracts the length parameter while iterating over skbuff, BUG_ON(len) at the end of it checks that the expected length to be included in the checksum calculation is fully consumed.(CVE-2024-50251)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  net/sched: stop qdisc_tree_reduce_backlog on TC_H_ROOT  In qdisc_tree_reduce_backlog, Qdiscs with major handle ffff: are assumed to be either root or ingress. This assumption is bogus since it\u0026apos;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 TC_H_ROOT is reached because the only way to retrieve ingress is when a hierarchy which does not contain a ffff: major handle call into qdisc_lookup with TC_H_MAJ(TC_H_ROOT).  In the scenario where major ffff: is an egress qdisc in any of the tree levels, the updates will also propagate to TC_H_ROOT, which then the iteration must stop.    net/sched/sch_api.c | 2 +-  1 file changed, 1 insertion(+), 1 deletion(-)(CVE-2024-53057)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  nilfs2: fix null-ptr-deref in block_touch_buffer tracepoint  Patch series \u0026quot;nilfs2: fix null-ptr-deref bugs on block tracepoints\u0026quot;.  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 \u0026quot;block:block_touch_buffer\u0026quot; tracepoint, touch_buffer() called from __nilfs_get_folio_block() causes a NULL pointer dereference, or a general protection fault when KASAN is enabled.  This happens because since the tracepoint was added in touch_buffer(), it references the dev_t member bh-\u0026gt;b_bdev-\u0026gt;bd_dev regardless of whether the buffer head has a pointer to a block_device structure.  In the current implementation, the block_device structure is set after the function returns to the caller.  Here, touch_buffer() 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 touch_buffer() here in the first place.  So this solves the issue by eliminating the touch_buffer() call itself.(CVE-2024-53131)\r\n\r\nIn 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 cpio_file := ALGN(4) + cpio_header + filename + \u0026quot;\\0\u0026quot; + ALGN(4) + data ...  55 ============= ================== =========================  56 Field name    Field size         Meaning  57 ============= ================== ========================= ...  70 c_namesize    8 bytes            Length of filename, including final \\0  When extracting an initramfs cpio archive, the kernel\u0026apos;s do_name() path handler assumes a zero-terminated path at @collected, passing it directly to filp_open() / init_mkdir() / init_mknod().  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\u0026apos;t be considered a security vulnerability.  Append the output of the following bash script to an existing initramfs and observe any created /initramfs_test_fname_overrunAA* path. E.g.   ./reproducer.sh | gzip \u0026gt;\u0026gt; /myinitramfs  It\u0026apos;s easiest to observe non-zero uninitialized memory when the output is gzipped, as it\u0026apos;ll overflow the heap allocated @out_buf in __gunzip(), rather than the initrd_start+initrd_size block.  ---- reproducer.sh ---- nilchar=\u0026quot;A\u0026quot; # change to \u0026quot;\\0\u0026quot; to properly zero terminate / pad magic=\u0026quot;070701\u0026quot; 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=\u0026quot;initramfs_test_fname_overrun\u0026quot; namelen=$(( ${#fname} + 1 )) # plus one to account for terminator  printf \u0026quot;%s%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%s\u0026quot; \\  $magic $ino $mode $uid $gid $nlink $mtime $filesize \\  $devmajor $devminor $rdevmajor $rdevminor $namelen $csum $fname  termpadlen=$(( 1 + ((4 - ((110 + $namelen) \u0026amp; 3)) % 4) )) printf \u0026quot;%.s${nilchar}\u0026quot; $(seq 1 $termpadlen) ---- reproducer.sh ----  Symlink filename fields handled in do_symlink() won\u0026apos;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\u0026apos;t carry a zero-terminator at the expected (name_len - 1) offset.(CVE-2024-53142)","affected":[{"package":{"ecosystem":"openEuler:20.03-LTS-SP4","name":"kernel","purl":"pkg:rpm/openEuler/kernel\u0026distro=openEuler-20.03-LTS-SP4"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.19.90-2412.3.0.0308.oe2003sp4"}]}],"ecosystem_specific":{"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"],"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"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2570"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50125"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50167"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50168"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50251"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53057"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53131"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53142"}],"database_specific":{"severity":"High"}}