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-4436 Final 1.0 1.0 2026-10-22 Initial 2026-10-22 2026-10-22 openEuler SA Tool V1.0 2026-10-22 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: drm/dp/mst: fix buffer overflows in sideband chunk accumulation drm_dp_sideband_append_payload() has three related bugs when processing device-provided sideband reply data: 1. Zero-length curchunk_len underflow: msg_len is a 6-bit field taken directly from the DP sideband header. If a device sends msg_len=0, curchunk_len is set to zero. The condition (curchunk_idx >= curchunk_len) is immediately true, and curchunk_len-1 wraps to 255 (u8 underflow). drm_dp_msg_data_crc4() reads 255 bytes from chunk[48], then memcpy() writes 255 bytes into msg[], both far out of bounds. 2. chunk[48] overflow: curchunk_len can reach 63 (6-bit field). chunk[] is only 48 bytes. Multi-iteration payload assembly appends 16-byte blocks until curchunk_idx reaches curchunk_len, writing up to 15 bytes past the end of chunk[] into msg[]. 3. msg[256] overflow: each chunk contributes (curchunk_len-1) bytes to msg[]. No check ensures curlen + (curchunk_len-1) stays within msg[256], so the memcpy can spill into adjacent struct fields. All three are reachable from any DP MST device that can forge sideband reply messages on a physical connection.(CVE-2026-68278) In the Linux kernel, the following vulnerability has been resolved: fuse: fix invalidate lock leak on open O_TRUNC DAX failure fuse_open() takes filemap_invalidate_lock() for a DAX truncate (dax_truncate = true) and releases it before the out_inode_unlock label. But when fuse_dax_break_layouts() fails, the goto out_inode_unlock skips the unlock and leaks the rwsem, so any later fault or truncate on the file stalls on the stale lock. fuse_dax_break_layouts() can fail with -ERESTARTSYS when a signal interrupts the wait for busy DAX pages to drain: open("file", O_RDWR | O_TRUNC) └─ fuse_open() ├─ filemap_invalidate_lock() # dax_truncate └─ fuse_dax_break_layouts() └─ dax_break_layout() └─ wait_page_idle() # TASK_INTERRUPTIBLE └─ fuse_wait_dax_page() # unlock, schedule, re-lock └─ signal → -ERESTARTSYS goto out_inode_unlock # <- lock leaked Fix this by moving filemap_invalidate_unlock() below the label so that all error paths release the lock, and rename the label to out_unlock as it now covers more than just the inode lock.(CVE-2026-80855) An update for kernel is now available for openEuler-22.03-LTS-SP4/openEuler-22.03-LTS-SP3/openEuler-24.03-LTS-SP2/openEuler-24.03-LTS. openEuler Security has rated this update as having a security impact of medium. 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. Medium kernel https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-4436 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-68278 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-80855 https://nvd.nist.gov/vuln/detail/CVE-2026-68278 https://nvd.nist.gov/vuln/detail/CVE-2026-80855 openEuler-22.03-LTS-SP4 bpftool-5.10.0-338.0.0.239.oe2203sp4.x86_64.rpm bpftool-debuginfo-5.10.0-338.0.0.239.oe2203sp4.x86_64.rpm kernel-5.10.0-338.0.0.239.oe2203sp4.x86_64.rpm kernel-debuginfo-5.10.0-338.0.0.239.oe2203sp4.x86_64.rpm kernel-debugsource-5.10.0-338.0.0.239.oe2203sp4.x86_64.rpm kernel-devel-5.10.0-338.0.0.239.oe2203sp4.x86_64.rpm kernel-headers-5.10.0-338.0.0.239.oe2203sp4.x86_64.rpm kernel-source-5.10.0-338.0.0.239.oe2203sp4.x86_64.rpm kernel-tools-5.10.0-338.0.0.239.oe2203sp4.x86_64.rpm kernel-tools-debuginfo-5.10.0-338.0.0.239.oe2203sp4.x86_64.rpm kernel-tools-devel-5.10.0-338.0.0.239.oe2203sp4.x86_64.rpm perf-5.10.0-338.0.0.239.oe2203sp4.x86_64.rpm perf-debuginfo-5.10.0-338.0.0.239.oe2203sp4.x86_64.rpm python3-perf-5.10.0-338.0.0.239.oe2203sp4.x86_64.rpm python3-perf-debuginfo-5.10.0-338.0.0.239.oe2203sp4.x86_64.rpm kernel-5.10.0-338.0.0.239.oe2203sp4.src.rpm bpftool-5.10.0-338.0.0.239.oe2203sp4.aarch64.rpm bpftool-debuginfo-5.10.0-338.0.0.239.oe2203sp4.aarch64.rpm kernel-5.10.0-338.0.0.239.oe2203sp4.aarch64.rpm kernel-debuginfo-5.10.0-338.0.0.239.oe2203sp4.aarch64.rpm kernel-debugsource-5.10.0-338.0.0.239.oe2203sp4.aarch64.rpm kernel-devel-5.10.0-338.0.0.239.oe2203sp4.aarch64.rpm kernel-headers-5.10.0-338.0.0.239.oe2203sp4.aarch64.rpm kernel-source-5.10.0-338.0.0.239.oe2203sp4.aarch64.rpm kernel-tools-5.10.0-338.0.0.239.oe2203sp4.aarch64.rpm kernel-tools-debuginfo-5.10.0-338.0.0.239.oe2203sp4.aarch64.rpm kernel-tools-devel-5.10.0-338.0.0.239.oe2203sp4.aarch64.rpm perf-5.10.0-338.0.0.239.oe2203sp4.aarch64.rpm perf-debuginfo-5.10.0-338.0.0.239.oe2203sp4.aarch64.rpm python3-perf-5.10.0-338.0.0.239.oe2203sp4.aarch64.rpm python3-perf-debuginfo-5.10.0-338.0.0.239.oe2203sp4.aarch64.rpm In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix buffer overflows in sideband chunk accumulation drm_dp_sideband_append_payload() has three related bugs when processing device-provided sideband reply data: 1. Zero-length curchunk_len underflow: msg_len is a 6-bit field taken directly from the DP sideband header. If a device sends msg_len=0, curchunk_len is set to zero. The condition (curchunk_idx >= curchunk_len) is immediately true, and curchunk_len-1 wraps to 255 (u8 underflow). drm_dp_msg_data_crc4() reads 255 bytes from chunk[48], then memcpy() writes 255 bytes into msg[], both far out of bounds. 2. chunk[48] overflow: curchunk_len can reach 63 (6-bit field). chunk[] is only 48 bytes. Multi-iteration payload assembly appends 16-byte blocks until curchunk_idx reaches curchunk_len, writing up to 15 bytes past the end of chunk[] into msg[]. 3. msg[256] overflow: each chunk contributes (curchunk_len-1) bytes to msg[]. No check ensures curlen + (curchunk_len-1) stays within msg[256], so the memcpy can spill into adjacent struct fields. All three are reachable from any DP MST device that can forge sideband reply messages on a physical connection. 2026-10-22 CVE-2026-68278 openEuler-22.03-LTS-SP4 Medium 4.6 AV:P/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H kernel security update 2026-10-22 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-4436 In the Linux kernel, the following vulnerability has been resolved: fuse: fix invalidate lock leak on open O_TRUNC DAX failure fuse_open() takes filemap_invalidate_lock() for a DAX truncate (dax_truncate = true) and releases it before the out_inode_unlock label. But when fuse_dax_break_layouts() fails, the goto out_inode_unlock skips the unlock and leaks the rwsem, so any later fault or truncate on the file stalls on the stale lock. fuse_dax_break_layouts() can fail with -ERESTARTSYS when a signal interrupts the wait for busy DAX pages to drain: open("file", O_RDWR | O_TRUNC) └─ fuse_open() ├─ filemap_invalidate_lock() # dax_truncate └─ fuse_dax_break_layouts() └─ dax_break_layout() └─ wait_page_idle() # TASK_INTERRUPTIBLE └─ fuse_wait_dax_page() # unlock, schedule, re-lock └─ signal → -ERESTARTSYS goto out_inode_unlock # <- lock leaked Fix this by moving filemap_invalidate_unlock() below the label so that all error paths release the lock, and rename the label to out_unlock as it now covers more than just the inode lock. 2026-10-22 CVE-2026-80855 openEuler-22.03-LTS-SP4 Medium 4.7 AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2026-10-22 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-4436