OESA-2024-2570

Source
https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-2570
Import Source
https://repo.openeuler.org/security/data/osv/OESA-2024-2570.json
JSON Data
https://api.osv.dev/v1/vulns/OESA-2024-2570
Upstream
Published
2024-12-20T11:08:03Z
Modified
2026-08-18T01:18:40Z
Severity
  • 7.8 (High) CVSS_V3 - CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H CVSS Calculator
Summary
kernel security update
Details

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)

Database specific
{
    "severity": "High"
}
References

Affected packages

openEuler:20.03-LTS-SP4 / kernel

Package

Name
kernel
Purl
pkg:rpm/openEuler/kernel&distro=openEuler-20.03-LTS-SP4

Affected ranges

Type
ECOSYSTEM
Events
Introduced
0 Unknown introduced version / All previous versions are affected
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"
    ]
}

Database specific

source
"https://repo.openeuler.org/security/data/osv/OESA-2024-2570.json"