An update for kernel is now available for openEuler-20.03-LTS-SP4 Security Advisory openeuler-security@openeuler.org openEuler security committee openEuler-SA-2024-2570 Final 1.0 1.0 2024-12-20 Initial 2024-12-20 2024-12-20 openEuler SA Tool V1.0 2024-12-20 kernel security update An update for kernel is now available for openEuler-20.03-LTS-SP4 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 sco_sock_timeout conn->sk maybe have been unlinked/freed while waiting for sco_conn_lock so this checks if the conn->sk is still valid by checking if it part of sco_sk_list.(CVE-2024-50125) In 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) In 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->len being too long, add dev_kfree_skb() to fix it.(CVE-2024-50168) In 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) In 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'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) In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix null-ptr-deref in block_touch_buffer 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:block_touch_buffer" 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->b_bdev->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) 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 cpio_file := ALGN(4) + cpio_header + filename + "\0" + 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'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'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 >> /myinitramfs It's easiest to observe non-zero uninitialized memory when the output is gzipped, as it'll overflow the heap allocated @out_buf in __gunzip(), rather than the initrd_start+initrd_size 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="initramfs_test_fname_overrun" 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 do_symlink() 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) An update for kernel is now available for openEuler-20.03-LTS-SP4. openEuler Security has rated this update as having a security impact of high. A Common Vunlnerability Scoring System(CVSS)base score,which gives a detailed severity rating, is available for each vulnerability from the CVElink(s) in the References section. High kernel https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2570 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-50125 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-50167 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-50168 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-50251 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-53057 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-53131 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-53142 https://nvd.nist.gov/vuln/detail/CVE-2024-50125 https://nvd.nist.gov/vuln/detail/CVE-2024-50167 https://nvd.nist.gov/vuln/detail/CVE-2024-50168 https://nvd.nist.gov/vuln/detail/CVE-2024-50251 https://nvd.nist.gov/vuln/detail/CVE-2024-53057 https://nvd.nist.gov/vuln/detail/CVE-2024-53131 https://nvd.nist.gov/vuln/detail/CVE-2024-53142 openEuler-20.03-LTS-SP4 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 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 kernel-4.19.90-2412.3.0.0308.oe2003sp4.src.rpm In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SCO: Fix UAF on sco_sock_timeout conn->sk maybe have been unlinked/freed while waiting for sco_conn_lock so this checks if the conn->sk is still valid by checking if it part of sco_sk_list. 2024-12-20 CVE-2024-50125 openEuler-20.03-LTS-SP4 High 7.8 AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H kernel security update 2024-12-20 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2570 In 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. 2024-12-20 CVE-2024-50167 openEuler-20.03-LTS-SP4 Medium 5.5 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2024-12-20 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2570 In 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->len being too long, add dev_kfree_skb() to fix it. 2024-12-20 CVE-2024-50168 openEuler-20.03-LTS-SP4 Medium 5.5 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2024-12-20 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2570 In 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. 2024-12-20 CVE-2024-50251 openEuler-20.03-LTS-SP4 Medium 6.2 AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H kernel security update 2024-12-20 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2570 In 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'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(-) 2024-12-20 CVE-2024-53057 openEuler-20.03-LTS-SP4 High 7.8 AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H kernel security update 2024-12-20 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2570 In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix null-ptr-deref in block_touch_buffer 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:block_touch_buffer" 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->b_bdev->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. 2024-12-20 CVE-2024-53131 openEuler-20.03-LTS-SP4 Medium 5.5 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2024-12-20 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2570 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 cpio_file := ALGN(4) + cpio_header + filename + "\0" + 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'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'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 >> /myinitramfs It's easiest to observe non-zero uninitialized memory when the output is gzipped, as it'll overflow the heap allocated @out_buf in __gunzip(), rather than the initrd_start+initrd_size 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="initramfs_test_fname_overrun" 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 do_symlink() 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. 2024-12-20 CVE-2024-53142 openEuler-20.03-LTS-SP4 High 7.8 AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H kernel security update 2024-12-20 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2570