GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration

OESA-2024-2570 (CVE-2024-50125)

Vulnerability from osv_openeuler – Published: 2024-12-20 11:08 – Updated: 2026-08-06 11:08 – Source website
VLAI
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)

Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
To clipboard 

{
  "affected": [
    {
      "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"
        ]
      },
      "package": {
        "ecosystem": "openEuler:20.03-LTS-SP4",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-20.03-LTS-SP4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.19.90-2412.3.0.0308.oe2003sp4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "High"
  },
  "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)",
  "id": "OESA-2024-2570",
  "modified": "2026-08-06T11:08:03Z",
  "published": "2024-12-20T11:08:03Z",
  "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"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2024-50125",
    "CVE-2024-50167",
    "CVE-2024-50168",
    "CVE-2024-50251",
    "CVE-2024-53057",
    "CVE-2024-53131",
    "CVE-2024-53142"
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Detection rules are retrieved from Rulezet.


Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.