OESA-2026-2419 (CVE-2026-31393)

Vulnerability from osv_openeuler – Published: 2026-05-22 11:11 – Updated: 2026-08-06 11:11 – 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: L2CAP: Validate L2CAP_INFO_RSP payload length before access

l2cap_information_rsp() checks that cmd_len covers the fixed l2cap_info_rsp header (type + result, 4 bytes) but then reads rsp->data without verifying that the payload is present:

  • L2CAP_IT_FEAT_MASK calls get_unaligned_le32(rsp->data), which reads 4 bytes past the header (needs cmd_len >= 8).

  • L2CAP_IT_FIXED_CHAN reads rsp->data[0], 1 byte past the header (needs cmd_len >= 5).

A truncated L2CAP_INFO_RSP with result == L2CAP_IR_SUCCESS triggers an out-of-bounds read of adjacent skb data.

Guard each data access with the required payload length check. If the payload is too short, skip the read and let the state machine complete with safe defaults (feat_mask and remote_fixed_chan remain zero from kzalloc), so the info timer cleanup and l2cap_conn_start() still run and the connection is not stalled.(CVE-2026-31393)

In the Linux kernel, the following vulnerability has been resolved:

ext4: reject mount if bigalloc with s_first_data_block != 0

bigalloc with s_first_data_block != 0 is not supported, reject mounting it.(CVE-2026-31447)

In the Linux kernel, the following vulnerability has been resolved:

HID: multitouch: Check to ensure report responses match the request

It is possible for a malicious (or clumsy) device to respond to a specific report's feature request using a completely different report ID. This can cause confusion in the HID core resulting in nasty side-effects such as OOB writes.

Add a check to ensure that the report ID in the response, matches the one that was requested. If it doesn't, omit reporting the raw event and return early.(CVE-2026-43047)

In the Linux kernel, the following vulnerability has been resolved:

HID: core: Mitigate potential OOB by removing bogus memset()

The memset() in hid_report_raw_event() has the good intention of clearing out bogus data by zeroing the area from the end of the incoming data string to the assumed end of the buffer. However, as we have previously seen, doing so can easily result in OOB reads and writes in the subsequent thread of execution.

The current suggestion from one of the HID maintainers is to remove the memset() and simply return if the incoming event buffer size is not large enough to fill the associated report.

Suggested-by Benjamin Tissoires <(CVE-2026-43048)

In the Linux kernel, there is a potential out-of-bounds access vulnerability in the ceph_handle_auth_reply() function of the libceph component. When processing messages of type CEPH_MSG_AUTH_REPLY, the value of the payload_len field is stored in a variable of type int. A value greater than INT_MAX leads to integer overflow and is interpreted as a negative value, which causes the pointer address to be decremented and subsequently accessed because ceph_decode_need() only checks that the memory access does not exceed the end address of the allocation. The vulnerability is fixed by changing the data type of payload_len to u32 and introducing additional sanity checks.(CVE-2026-43407)

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

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-6.6.0-145.3.12.142.oe2403sp3.aarch64.rpm",
          "bpftool-debuginfo-6.6.0-145.3.12.142.oe2403sp3.aarch64.rpm",
          "kernel-6.6.0-145.3.12.142.oe2403sp3.aarch64.rpm",
          "kernel-debuginfo-6.6.0-145.3.12.142.oe2403sp3.aarch64.rpm",
          "kernel-debugsource-6.6.0-145.3.12.142.oe2403sp3.aarch64.rpm",
          "kernel-devel-6.6.0-145.3.12.142.oe2403sp3.aarch64.rpm",
          "kernel-extra-modules-6.6.0-145.3.12.142.oe2403sp3.aarch64.rpm",
          "kernel-headers-6.6.0-145.3.12.142.oe2403sp3.aarch64.rpm",
          "kernel-source-6.6.0-145.3.12.142.oe2403sp3.aarch64.rpm",
          "kernel-tools-6.6.0-145.3.12.142.oe2403sp3.aarch64.rpm",
          "kernel-tools-debuginfo-6.6.0-145.3.12.142.oe2403sp3.aarch64.rpm",
          "kernel-tools-devel-6.6.0-145.3.12.142.oe2403sp3.aarch64.rpm",
          "perf-6.6.0-145.3.12.142.oe2403sp3.aarch64.rpm",
          "perf-debuginfo-6.6.0-145.3.12.142.oe2403sp3.aarch64.rpm",
          "python3-perf-6.6.0-145.3.12.142.oe2403sp3.aarch64.rpm",
          "python3-perf-debuginfo-6.6.0-145.3.12.142.oe2403sp3.aarch64.rpm"
        ],
        "src": [
          "kernel-6.6.0-145.3.12.142.oe2403sp3.src.rpm"
        ],
        "x86_64": [
          "bpftool-6.6.0-145.3.12.142.oe2403sp3.x86_64.rpm",
          "bpftool-debuginfo-6.6.0-145.3.12.142.oe2403sp3.x86_64.rpm",
          "kernel-6.6.0-145.3.12.142.oe2403sp3.x86_64.rpm",
          "kernel-debuginfo-6.6.0-145.3.12.142.oe2403sp3.x86_64.rpm",
          "kernel-debugsource-6.6.0-145.3.12.142.oe2403sp3.x86_64.rpm",
          "kernel-devel-6.6.0-145.3.12.142.oe2403sp3.x86_64.rpm",
          "kernel-extra-modules-6.6.0-145.3.12.142.oe2403sp3.x86_64.rpm",
          "kernel-headers-6.6.0-145.3.12.142.oe2403sp3.x86_64.rpm",
          "kernel-source-6.6.0-145.3.12.142.oe2403sp3.x86_64.rpm",
          "kernel-tools-6.6.0-145.3.12.142.oe2403sp3.x86_64.rpm",
          "kernel-tools-debuginfo-6.6.0-145.3.12.142.oe2403sp3.x86_64.rpm",
          "kernel-tools-devel-6.6.0-145.3.12.142.oe2403sp3.x86_64.rpm",
          "perf-6.6.0-145.3.12.142.oe2403sp3.x86_64.rpm",
          "perf-debuginfo-6.6.0-145.3.12.142.oe2403sp3.x86_64.rpm",
          "python3-perf-6.6.0-145.3.12.142.oe2403sp3.x86_64.rpm",
          "python3-perf-debuginfo-6.6.0-145.3.12.142.oe2403sp3.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:24.03-LTS-SP3",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS-SP3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.6.0-145.3.12.142.oe2403sp3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "Critical"
  },
  "details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: Validate L2CAP_INFO_RSP payload length before access\n\nl2cap_information_rsp() checks that cmd_len covers the fixed\nl2cap_info_rsp header (type + result, 4 bytes) but then reads\nrsp-\u0026gt;data without verifying that the payload is present:\n\n - L2CAP_IT_FEAT_MASK calls get_unaligned_le32(rsp-\u0026gt;data), which reads\n   4 bytes past the header (needs cmd_len \u0026gt;= 8).\n\n - L2CAP_IT_FIXED_CHAN reads rsp-\u0026gt;data[0], 1 byte past the header\n   (needs cmd_len \u0026gt;= 5).\n\nA truncated L2CAP_INFO_RSP with result == L2CAP_IR_SUCCESS triggers an\nout-of-bounds read of adjacent skb data.\n\nGuard each data access with the required payload length check.  If the\npayload is too short, skip the read and let the state machine complete\nwith safe defaults (feat_mask and remote_fixed_chan remain zero from\nkzalloc), so the info timer cleanup and l2cap_conn_start() still run\nand the connection is not stalled.(CVE-2026-31393)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: reject mount if bigalloc with s_first_data_block != 0\n\nbigalloc with s_first_data_block != 0 is not supported, reject mounting\nit.(CVE-2026-31447)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: multitouch: Check to ensure report responses match the request\n\nIt is possible for a malicious (or clumsy) device to respond to a\nspecific report\u0026apos;s feature request using a completely different report\nID.  This can cause confusion in the HID core resulting in nasty\nside-effects such as OOB writes.\n\nAdd a check to ensure that the report ID in the response, matches the\none that was requested.  If it doesn\u0026apos;t, omit reporting the raw event and\nreturn early.(CVE-2026-43047)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: core: Mitigate potential OOB by removing bogus memset()\n\nThe memset() in hid_report_raw_event() has the good intention of\nclearing out bogus data by zeroing the area from the end of the incoming\ndata string to the assumed end of the buffer.  However, as we have\npreviously seen, doing so can easily result in OOB reads and writes in\nthe subsequent thread of execution.\n\nThe current suggestion from one of the HID maintainers is to remove the\nmemset() and simply return if the incoming event buffer size is not\nlarge enough to fill the associated report.\n\nSuggested-by Benjamin Tissoires \u0026lt;(CVE-2026-43048)\n\nIn the Linux kernel, there is a potential out-of-bounds access vulnerability in the ceph_handle_auth_reply() function of the libceph component. When processing messages of type CEPH_MSG_AUTH_REPLY, the value of the payload_len field is stored in a variable of type int. A value greater than INT_MAX leads to integer overflow and is interpreted as a negative value, which causes the pointer address to be decremented and subsequently accessed because ceph_decode_need() only checks that the memory access does not exceed the end address of the allocation. The vulnerability is fixed by changing the data type of payload_len to u32 and introducing additional sanity checks.(CVE-2026-43407)",
  "id": "OESA-2026-2419",
  "modified": "2026-08-06T11:11:22Z",
  "published": "2026-05-22T11:11:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2419"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31393"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31447"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43047"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43048"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43407"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2026-31393",
    "CVE-2026-31447",
    "CVE-2026-43047",
    "CVE-2026-43048",
    "CVE-2026-43407"
  ]
}



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.



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.