{"schema_version":"1.7.2","id":"OESA-2026-2993","modified":"2026-07-19T03:47:17Z","published":"2026-07-19T03:47:17Z","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"],"summary":"kernel security update","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->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'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'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->f_cred->user_ns,\nwhile unattached administrative ioctls operate on current->nsproxy->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 ("bpf: Add abnormal return checks."). 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' 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 & How]\nDuring HDCP 2.x repeater authentication over HDMI, the driver reads the\nsink'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->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->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->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 & 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)","affected":[{"package":{"ecosystem":"openEuler:22.03-LTS-SP4","name":"kernel","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-22.03-LTS-SP4"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.10.0-324.0.0.225.oe2203sp4"}]}],"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"]}}],"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"}],"database_specific":{"severity":"Critical"}}