OESA-2026-2993 (CVE-2026-23089)

Vulnerability from osv_openeuler – Published: 2026-07-19 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:

ALSA: usb-audio: Fix use-after-free in snd_usb_mixer_free()

When snd_usb_create_mixer() fails, snd_usb_mixer_free() frees mixer->id_elems but the controls already added to the card still reference the freed memory. Later when snd_card_register() runs, the OSS mixer layer calls their callbacks and hits a use-after-free read.

Call trace: get_ctl_value+0x63f/0x820 sound/usb/mixer.c:411 get_min_max_with_quirks.isra.0+0x240/0x1f40 sound/usb/mixer.c:1241 mixer_ctl_feature_info+0x26b/0x490 sound/usb/mixer.c:1381 snd_mixer_oss_build_test+0x174/0x3a0 sound/core/oss/mixer_oss.c:887 ... snd_card_register+0x4ed/0x6d0 sound/core/init.c:923 usb_audio_probe+0x5ef/0x2a90 sound/usb/card.c:1025

Fix by calling snd_ctl_remove() for all mixer controls before freeing id_elems. We save the next pointer first because snd_ctl_remove() frees the current element.(CVE-2026-23089)

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

Bluetooth: serialize accept_q access

bt_sock_poll() walks the accept queue without synchronization, while child teardown can unlink the same socket and drop its last reference. The unsynchronized accept queue walk has existed since the initial Bluetooth import.

Protect accept_q with a dedicated lock for queue updates and polling. Also rework bt_accept_dequeue() to take temporary child references under the queue lock before dropping it and locking the child socket.(CVE-2026-52918)

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

pppoe: drop PFC frames

RFC 2516 Section 7 states that Protocol Field Compression (PFC) is NOT RECOMMENDED for PPPoE. In practice, pppd does not support negotiating PFC for PPPoE sessions, and the current PPPoE driver assumes an uncompressed (2-byte) protocol field. However, the generic PPP layer function ppp_input() is not aware of the negotiation result, and still accepts PFC frames.

If a peer with a broken implementation or an attacker sends a frame with a compressed (1-byte) protocol field, the subsequent PPP payload is shifted by one byte. This causes the network header to be 4-byte misaligned, which may trigger unaligned access exceptions on some architectures.

To reduce the attack surface, drop PPPoE PFC frames. Introduce ppp_skb_is_compressed_proto() helper function to be used in both ppp_generic.c and pppoe.c to avoid open-coding.(CVE-2026-53003)

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

crypto: ccp - copy IV using skcipher ivsize

AF_ALG rfc3686-ctr-aes-ccp requests pass an 8-byte IV to the driver.

ccp_aes_complete() restores AES_BLOCK_SIZE bytes into the caller's IV buffer while RFC3686 skciphers expose an 8-byte IV, so the restore overruns the provided buffer.

Use crypto_skcipher_ivsize() to copy only the algorithm's IV length.(CVE-2026-53016)

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

ppp: require CAP_NET_ADMIN in target netns for unattached ioctls

/dev/ppp open is currently authorized against file->f_cred->user_ns, while unattached administrative ioctls operate on current->nsproxy->net_ns.

As a result, a local unprivileged user can create a new user namespace with CLONE_NEWUSER, gain CAP_NET_ADMIN only in that new user namespace, and still issue PPPIOCNEWUNIT, PPPIOCATTACH, or PPPIOCATTCHAN against an inherited network namespace.

Require CAP_NET_ADMIN in the user namespace that owns the target network namespace before handling unattached PPP administrative ioctls.

This preserves normal pppd operation in the network namespace it is actually privileged in, while rejecting the userns-only inherited-netns case.(CVE-2026-53075)

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

bpf: Fix ld_{abs,ind} failure path analysis in subprogs

Usage of ld_{abs,ind} instructions got extended into subprogs some time ago via commit 09b28d76eac4 ("bpf: Add abnormal return checks."). These are only allowed in subprograms when the latter are BTF annotated and have scalar return types.

The code generator in bpf_gen_ld_abs() has an abnormal exit path (r0=0 + exit) from legacy cBPF times. While the enforcement is on scalar return types, the verifier must also simulate the path of abnormal exit if the packet data load via ld_{abs,ind} failed.

This is currently not the case. Fix it by having the verifier simulate both success and failure paths, and extend it in similar ways as we do for tail calls. The success path (r0=unknown, continue to next insn) is pushed onto stack for later validation and the r0=0 and return to the caller is done on the fall-through side.(CVE-2026-53090)

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

vdpa: use generic driver_override infrastructure

When a driver is probed through __driver_attach(), the bus' match() callback is called without the device lock held, thus accessing the driver_override field without a lock, which can cause a UAF.

Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally.

Note that calling match() from __driver_attach() without the device lock held is intentional. 1

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

drm/amd/display: Clamp HDMI HDCP2 rx_id_list read to buffer size

[Why & How] During HDCP 2.x repeater authentication over HDMI, the driver reads the sink's RxStatus register and extracts a 10-bit message size field (max value 1023). This value is used as the read length for the ReceiverID list without being clamped to the size of the destination buffer rx_id_list[177]. A malicious HDMI repeater could advertise a message size larger than the buffer, causing an out-of-bounds write during the I2C read.

Clamp the read length in mod_hdcp_read_rx_id_list() to the size of the rx_id_list buffer, matching the approach already used in the DP branch.

(cherry picked from commit 229212219e4247d9486f8ba41ef087358490be09)(CVE-2026-53137)

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

RDMA/srp: bound SRP_RSP sense copy by the received length

srp_process_rsp() copies sense data from rsp->data + resp_data_len, where resp_data_len is the full 32-bit value supplied by the SRP target and is never checked against the number of bytes actually received (wc->byte_len). The copy length is bounded to SCSI_SENSE_BUFFERSIZE, so at most 96 bytes are copied, but the source offset is not bounded.

A malicious or compromised SRP target on the InfiniBand/RoCE fabric that the initiator has logged into can return an SRP_RSP with SRP_RSP_FLAG_SNSVALID set and a large resp_data_len. The receive buffer is allocated at the target-chosen max_ti_iu_len, so the source of the sense copy lands past the bytes actually received; with resp_data_len near 0xFFFFFFFF it is gigabytes past the buffer and the read faults.

Copy the sense data only if it has not been truncated, that is, only if the response header, the response data, and the sense region fit within the bytes actually received; otherwise drop the sense and log. The in-tree iSER and NVMe-RDMA receive paths already bound their parse by wc->byte_len; this brings ib_srp into line with them.(CVE-2026-53186)

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

drm/amd/display: Fix out-of-bounds read in dp_get_eq_aux_rd_interval()

[Why & How] The aux_rd_interval array in struct dc_lttpr_caps is declared with MAX_REPEATER_CNT - 1 (7) elements, indexed 0..6. However, the offset parameter passed to dp_get_eq_aux_rd_interval() can be as large as MAX_REPEATER_CNT (8) when a sink reports 8 LTTPR repeaters via DPCD. This leads to an out-of-bounds read of aux_rd_interval[7] when offset is 8.

Fix this by growing aux_rd_interval to MAX_REPEATER_CNT elements to accommodate the full range of valid repeater counts defined by the DP spec.

(cherry picked from commit a55a458a8df37a65ffda5cf721d554a8f74f6b04)(CVE-2026-53330)

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-5.10.0-324.0.0.225.oe2203sp4.aarch64.rpm",
          "bpftool-debuginfo-5.10.0-324.0.0.225.oe2203sp4.aarch64.rpm",
          "kernel-5.10.0-324.0.0.225.oe2203sp4.aarch64.rpm",
          "kernel-debuginfo-5.10.0-324.0.0.225.oe2203sp4.aarch64.rpm",
          "kernel-debugsource-5.10.0-324.0.0.225.oe2203sp4.aarch64.rpm",
          "kernel-devel-5.10.0-324.0.0.225.oe2203sp4.aarch64.rpm",
          "kernel-headers-5.10.0-324.0.0.225.oe2203sp4.aarch64.rpm",
          "kernel-source-5.10.0-324.0.0.225.oe2203sp4.aarch64.rpm",
          "kernel-tools-5.10.0-324.0.0.225.oe2203sp4.aarch64.rpm",
          "kernel-tools-debuginfo-5.10.0-324.0.0.225.oe2203sp4.aarch64.rpm",
          "kernel-tools-devel-5.10.0-324.0.0.225.oe2203sp4.aarch64.rpm",
          "perf-5.10.0-324.0.0.225.oe2203sp4.aarch64.rpm",
          "perf-debuginfo-5.10.0-324.0.0.225.oe2203sp4.aarch64.rpm",
          "python3-perf-5.10.0-324.0.0.225.oe2203sp4.aarch64.rpm",
          "python3-perf-debuginfo-5.10.0-324.0.0.225.oe2203sp4.aarch64.rpm"
        ],
        "src": [
          "kernel-5.10.0-324.0.0.225.oe2203sp4.src.rpm"
        ],
        "x86_64": [
          "bpftool-5.10.0-324.0.0.225.oe2203sp4.x86_64.rpm",
          "bpftool-debuginfo-5.10.0-324.0.0.225.oe2203sp4.x86_64.rpm",
          "kernel-5.10.0-324.0.0.225.oe2203sp4.x86_64.rpm",
          "kernel-debuginfo-5.10.0-324.0.0.225.oe2203sp4.x86_64.rpm",
          "kernel-debugsource-5.10.0-324.0.0.225.oe2203sp4.x86_64.rpm",
          "kernel-devel-5.10.0-324.0.0.225.oe2203sp4.x86_64.rpm",
          "kernel-headers-5.10.0-324.0.0.225.oe2203sp4.x86_64.rpm",
          "kernel-source-5.10.0-324.0.0.225.oe2203sp4.x86_64.rpm",
          "kernel-tools-5.10.0-324.0.0.225.oe2203sp4.x86_64.rpm",
          "kernel-tools-debuginfo-5.10.0-324.0.0.225.oe2203sp4.x86_64.rpm",
          "kernel-tools-devel-5.10.0-324.0.0.225.oe2203sp4.x86_64.rpm",
          "perf-5.10.0-324.0.0.225.oe2203sp4.x86_64.rpm",
          "perf-debuginfo-5.10.0-324.0.0.225.oe2203sp4.x86_64.rpm",
          "python3-perf-5.10.0-324.0.0.225.oe2203sp4.x86_64.rpm",
          "python3-perf-debuginfo-5.10.0-324.0.0.225.oe2203sp4.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:22.03-LTS-SP4",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.10.0-324.0.0.225.oe2203sp4"
            }
          ],
          "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\nALSA: usb-audio: Fix use-after-free in snd_usb_mixer_free()\n\nWhen snd_usb_create_mixer() fails, snd_usb_mixer_free() frees\nmixer-\u0026gt;id_elems but the controls already added to the card still\nreference the freed memory. Later when snd_card_register() runs,\nthe OSS mixer layer calls their callbacks and hits a use-after-free read.\n\nCall trace:\n  get_ctl_value+0x63f/0x820 sound/usb/mixer.c:411\n  get_min_max_with_quirks.isra.0+0x240/0x1f40 sound/usb/mixer.c:1241\n  mixer_ctl_feature_info+0x26b/0x490 sound/usb/mixer.c:1381\n  snd_mixer_oss_build_test+0x174/0x3a0 sound/core/oss/mixer_oss.c:887\n  ...\n  snd_card_register+0x4ed/0x6d0 sound/core/init.c:923\n  usb_audio_probe+0x5ef/0x2a90 sound/usb/card.c:1025\n\nFix by calling snd_ctl_remove() for all mixer controls before freeing\nid_elems. We save the next pointer first because snd_ctl_remove()\nfrees the current element.(CVE-2026-23089)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: serialize accept_q access\n\nbt_sock_poll() walks the accept queue without synchronization, while\nchild teardown can unlink the same socket and drop its last reference.\nThe unsynchronized accept queue walk has existed since the initial\nBluetooth import.\n\nProtect accept_q with a dedicated lock for queue updates and polling.\nAlso rework bt_accept_dequeue() to take temporary child references under\nthe queue lock before dropping it and locking the child socket.(CVE-2026-52918)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npppoe: drop PFC frames\n\nRFC 2516 Section 7 states that Protocol Field Compression (PFC) is NOT\nRECOMMENDED for PPPoE. In practice, pppd does not support negotiating\nPFC for PPPoE sessions, and the current PPPoE driver assumes an\nuncompressed (2-byte) protocol field. However, the generic PPP layer\nfunction ppp_input() is not aware of the negotiation result, and still\naccepts PFC frames.\n\nIf a peer with a broken implementation or an attacker sends a frame with\na compressed (1-byte) protocol field, the subsequent PPP payload is\nshifted by one byte. This causes the network header to be 4-byte\nmisaligned, which may trigger unaligned access exceptions on some\narchitectures.\n\nTo reduce the attack surface, drop PPPoE PFC frames. Introduce\nppp_skb_is_compressed_proto() helper function to be used in both\nppp_generic.c and pppoe.c to avoid open-coding.(CVE-2026-53003)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: ccp - copy IV using skcipher ivsize\n\nAF_ALG rfc3686-ctr-aes-ccp requests pass an 8-byte IV to the driver.\n\nccp_aes_complete() restores AES_BLOCK_SIZE bytes into the caller\u0026apos;s IV\nbuffer while RFC3686 skciphers expose an 8-byte IV, so the restore\noverruns the provided buffer.\n\nUse crypto_skcipher_ivsize() to copy only the algorithm\u0026apos;s IV length.(CVE-2026-53016)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nppp: require CAP_NET_ADMIN in target netns for unattached ioctls\n\n/dev/ppp open is currently authorized against file-\u0026gt;f_cred-\u0026gt;user_ns,\nwhile unattached administrative ioctls operate on current-\u0026gt;nsproxy-\u0026gt;net_ns.\n\nAs a result, a local unprivileged user can create a new user namespace\nwith CLONE_NEWUSER, gain CAP_NET_ADMIN only in that new user namespace,\nand still issue PPPIOCNEWUNIT, PPPIOCATTACH, or PPPIOCATTCHAN against\nan inherited network namespace.\n\nRequire CAP_NET_ADMIN in the user namespace that owns the target network\nnamespace before handling unattached PPP administrative ioctls.\n\nThis preserves normal pppd operation in the network namespace it is\nactually privileged in, while rejecting the userns-only inherited-netns\ncase.(CVE-2026-53075)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix ld_{abs,ind} failure path analysis in subprogs\n\nUsage of ld_{abs,ind} instructions got extended into subprogs some time\nago via commit 09b28d76eac4 (\u0026quot;bpf: Add abnormal return checks.\u0026quot;). These\nare only allowed in subprograms when the latter are BTF annotated and\nhave scalar return types.\n\nThe code generator in bpf_gen_ld_abs() has an abnormal exit path (r0=0 +\nexit) from legacy cBPF times. While the enforcement is on scalar return\ntypes, the verifier must also simulate the path of abnormal exit if the\npacket data load via ld_{abs,ind} failed.\n\nThis is currently not the case. Fix it by having the verifier simulate\nboth success and failure paths, and extend it in similar ways as we do\nfor tail calls. The success path (r0=unknown, continue to next insn) is\npushed onto stack for later validation and the r0=0 and return to the\ncaller is done on the fall-through side.(CVE-2026-53090)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvdpa: use generic driver_override infrastructure\n\nWhen a driver is probed through __driver_attach(), the bus\u0026apos; match()\ncallback is called without the device lock held, thus accessing the\ndriver_override field without a lock, which can cause a UAF.\n\nFix this by using the driver-core driver_override infrastructure taking\ncare of proper locking internally.\n\nNote that calling match() from __driver_attach() without the device lock\nheld is intentional. [1](CVE-2026-53118)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Clamp HDMI HDCP2 rx_id_list read to buffer size\n\n[Why \u0026amp; How]\nDuring HDCP 2.x repeater authentication over HDMI, the driver reads the\nsink\u0026apos;s RxStatus register and extracts a 10-bit message size field (max\nvalue 1023). This value is used as the read length for the ReceiverID\nlist without being clamped to the size of the destination buffer\nrx_id_list[177]. A malicious HDMI repeater could advertise a message\nsize larger than the buffer, causing an out-of-bounds write during the\nI2C read.\n\nClamp the read length in mod_hdcp_read_rx_id_list() to the size of the\nrx_id_list buffer, matching the approach already used in the DP branch.\n\n(cherry picked from commit 229212219e4247d9486f8ba41ef087358490be09)(CVE-2026-53137)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/srp: bound SRP_RSP sense copy by the received length\n\nsrp_process_rsp() copies sense data from rsp-\u0026gt;data + resp_data_len,\nwhere resp_data_len is the full 32-bit value supplied by the SRP target\nand is never checked against the number of bytes actually received\n(wc-\u0026gt;byte_len). The copy length is bounded to SCSI_SENSE_BUFFERSIZE, so\nat most 96 bytes are copied, but the source offset is not bounded.\n\nA malicious or compromised SRP target on the InfiniBand/RoCE fabric that\nthe initiator has logged into can return an SRP_RSP with\nSRP_RSP_FLAG_SNSVALID set and a large resp_data_len. The receive buffer\nis allocated at the target-chosen max_ti_iu_len, so the source of the\nsense copy lands past the bytes actually received; with resp_data_len\nnear 0xFFFFFFFF it is gigabytes past the buffer and the read faults.\n\nCopy the sense data only if it has not been truncated, that is, only if\nthe response header, the response data, and the sense region fit within\nthe bytes actually received; otherwise drop the sense and log. The\nin-tree iSER and NVMe-RDMA receive paths already bound their parse by\nwc-\u0026gt;byte_len; this brings ib_srp into line with them.(CVE-2026-53186)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Fix out-of-bounds read in dp_get_eq_aux_rd_interval()\n\n[Why \u0026amp; How]\nThe aux_rd_interval array in struct dc_lttpr_caps is declared with\nMAX_REPEATER_CNT - 1 (7) elements, indexed 0..6. However, the offset\nparameter passed to dp_get_eq_aux_rd_interval() can be as large as\nMAX_REPEATER_CNT (8) when a sink reports 8 LTTPR repeaters via DPCD.\nThis leads to an out-of-bounds read of aux_rd_interval[7] when offset\nis 8.\n\nFix this by growing aux_rd_interval to MAX_REPEATER_CNT elements to\naccommodate the full range of valid repeater counts defined by the DP\nspec.\n\n(cherry picked from commit a55a458a8df37a65ffda5cf721d554a8f74f6b04)(CVE-2026-53330)",
  "id": "OESA-2026-2993",
  "modified": "2026-08-06T11:11:53Z",
  "published": "2026-07-19T11:11:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2993"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23089"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-52918"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53003"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53016"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53075"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53090"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53118"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53137"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53186"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53330"
    }
  ],
  "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-23089",
    "CVE-2026-52918",
    "CVE-2026-53003",
    "CVE-2026-53016",
    "CVE-2026-53075",
    "CVE-2026-53090",
    "CVE-2026-53118",
    "CVE-2026-53137",
    "CVE-2026-53186",
    "CVE-2026-53330"
  ]
}



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.