An update for kernel is now available for openEuler-22.03-LTS-SP4 Security Advisory openeuler-security@openeuler.org openEuler security committee openEuler-SA-2026-2993 Final 1.0 1.0 2026-07-19 Initial 2026-07-19 2026-07-19 openEuler SA Tool V1.0 2026-07-19 kernel security update An update for kernel is now available for openEuler-22.03-LTS-SP4 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](CVE-2026-53118) 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) An update for kernel is now available for openEuler-20.03-LTS-SP4/openEuler-22.03-LTS-SP4/openEuler-22.03-LTS-SP3/openEuler-24.03-LTS/openEuler-24.03-LTS-SP2. openEuler Security has rated this update as having a security impact of critical. A Common Vunlnerability Scoring System(CVSS)base score,which gives a detailed severity rating, is available for each vulnerability from the CVElink(s) in the References section. Critical kernel https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2993 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-23089 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-52918 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-53003 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-53016 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-53075 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-53090 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-53118 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-53137 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-53186 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-53330 https://nvd.nist.gov/vuln/detail/CVE-2026-23089 https://nvd.nist.gov/vuln/detail/CVE-2026-52918 https://nvd.nist.gov/vuln/detail/CVE-2026-53003 https://nvd.nist.gov/vuln/detail/CVE-2026-53016 https://nvd.nist.gov/vuln/detail/CVE-2026-53075 https://nvd.nist.gov/vuln/detail/CVE-2026-53090 https://nvd.nist.gov/vuln/detail/CVE-2026-53118 https://nvd.nist.gov/vuln/detail/CVE-2026-53137 https://nvd.nist.gov/vuln/detail/CVE-2026-53186 https://nvd.nist.gov/vuln/detail/CVE-2026-53330 openEuler-22.03-LTS-SP4 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 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 kernel-5.10.0-324.0.0.225.oe2203sp4.src.rpm 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. 2026-07-19 CVE-2026-23089 openEuler-22.03-LTS-SP4 High 7.8 AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H kernel security update 2026-07-19 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2993 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. 2026-07-19 CVE-2026-52918 openEuler-22.03-LTS-SP4 High 8.8 AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H kernel security update 2026-07-19 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2993 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. 2026-07-19 CVE-2026-53003 openEuler-22.03-LTS-SP4 High 7.5 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H kernel security update 2026-07-19 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2993 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. 2026-07-19 CVE-2026-53016 openEuler-22.03-LTS-SP4 High 7.0 AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H kernel security update 2026-07-19 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2993 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. 2026-07-19 CVE-2026-53075 openEuler-22.03-LTS-SP4 High 8.8 AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H kernel security update 2026-07-19 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2993 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. 2026-07-19 CVE-2026-53090 openEuler-22.03-LTS-SP4 Medium 6.4 AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H kernel security update 2026-07-19 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2993 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] 2026-07-19 CVE-2026-53118 openEuler-22.03-LTS-SP4 Medium 5.5 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2026-07-19 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2993 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) 2026-07-19 CVE-2026-53137 openEuler-22.03-LTS-SP4 High 7.8 AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H kernel security update 2026-07-19 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2993 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. 2026-07-19 CVE-2026-53186 openEuler-22.03-LTS-SP4 Critical 9.1 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H kernel security update 2026-07-19 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2993 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) 2026-07-19 CVE-2026-53330 openEuler-22.03-LTS-SP4 Low 3.3 AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N kernel security update 2026-07-19 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2993