An update for kernel is now available for openEuler-20.03-LTS-SP4 Security Advisory openeuler-security@openeuler.org openEuler security committee openEuler-SA-2026-3452 Final 1.0 1.0 2026-08-20 Initial 2026-08-20 2026-08-20 openEuler SA Tool V1.0 2026-08-20 kernel security update An update for kernel is now available for openEuler-20.03-LTS-SP4 The Linux Kernel, the operating system core itself. Security Fix(es): In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Prefer NLA_NUL_STRING These attributes are evaluated as c-string (passed to strcmp), but NLA_STRING doesn't check for the presence of a \0 terminator. Either this needs to switch to nla_strcmp() and needs to adjust printf fmt specifier to not use plain %s, or this needs to use NLA_NUL_STRING. As the code has been this way for long time, it seems to me that userspace does include the terminating nul, even tough its not enforced so far, and thus NLA_NUL_STRING use is the simpler solution.(CVE-2026-63860) In the Linux kernel, the following vulnerability has been resolved: drm/edid: fix OOB read in drm_parse_tiled_block() drm_parse_tiled_block() casts the DisplayID block to a struct displayid_tiled_block and reads the full fixed layout up to tile->topology_id[7] without checking block->num_bytes. The DisplayID iterator only validates the declared payload length, so a crafted EDID can advertise a tiled-display block (tag DATA_BLOCK_TILED_DISPLAY, or DATA_BLOCK_2_TILED_DISPLAY_TOPOLOGY for v2.0) with a small num_bytes at the end of a DisplayID extension. The read then runs past the end of the exact-sized kmemdup()'d EDID allocation, a heap out-of-bounds read. Reject blocks shorter than the spec's 22-byte tiled payload before reading the fixed struct, as drm_parse_vesa_mso_data() already does. BUG: KASAN: slab-out-of-bounds in drm_edid_connector_update Read of size 2 at addr ffff888010077700 by task exploit/147 dump_stack_lvl (lib/dump_stack.c:94 ...) print_report (mm/kasan/report.c:378 ...) kasan_report (mm/kasan/report.c:595) drm_edid_connector_update (drivers/gpu/drm/drm_edid.c:7581) bochs_connector_helper_get_modes (drivers/gpu/drm/tiny/bochs.c:574) drm_helper_probe_single_connector_modes (drivers/gpu/drm/drm_probe_helper.c:426) status_store (drivers/gpu/drm/drm_sysfs.c:219) ... vfs_write (fs/read_write.c:595 fs/read_write.c:688) ksys_write (fs/read_write.c:740)(CVE-2026-64546) An update for kernel is now available for openEuler-20.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 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-3452 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-63860 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-64546 https://nvd.nist.gov/vuln/detail/CVE-2026-63860 https://nvd.nist.gov/vuln/detail/CVE-2026-64546 openEuler-20.03-LTS-SP4 bpftool-4.19.90-2608.4.0.0386.oe2003sp4.aarch64.rpm bpftool-debuginfo-4.19.90-2608.4.0.0386.oe2003sp4.aarch64.rpm kernel-4.19.90-2608.4.0.0386.oe2003sp4.aarch64.rpm kernel-debuginfo-4.19.90-2608.4.0.0386.oe2003sp4.aarch64.rpm kernel-debugsource-4.19.90-2608.4.0.0386.oe2003sp4.aarch64.rpm kernel-devel-4.19.90-2608.4.0.0386.oe2003sp4.aarch64.rpm kernel-source-4.19.90-2608.4.0.0386.oe2003sp4.aarch64.rpm kernel-tools-4.19.90-2608.4.0.0386.oe2003sp4.aarch64.rpm kernel-tools-debuginfo-4.19.90-2608.4.0.0386.oe2003sp4.aarch64.rpm kernel-tools-devel-4.19.90-2608.4.0.0386.oe2003sp4.aarch64.rpm perf-4.19.90-2608.4.0.0386.oe2003sp4.aarch64.rpm perf-debuginfo-4.19.90-2608.4.0.0386.oe2003sp4.aarch64.rpm python2-perf-4.19.90-2608.4.0.0386.oe2003sp4.aarch64.rpm python2-perf-debuginfo-4.19.90-2608.4.0.0386.oe2003sp4.aarch64.rpm python3-perf-4.19.90-2608.4.0.0386.oe2003sp4.aarch64.rpm python3-perf-debuginfo-4.19.90-2608.4.0.0386.oe2003sp4.aarch64.rpm bpftool-4.19.90-2608.4.0.0386.oe2003sp4.x86_64.rpm bpftool-debuginfo-4.19.90-2608.4.0.0386.oe2003sp4.x86_64.rpm kernel-4.19.90-2608.4.0.0386.oe2003sp4.x86_64.rpm kernel-debuginfo-4.19.90-2608.4.0.0386.oe2003sp4.x86_64.rpm kernel-debugsource-4.19.90-2608.4.0.0386.oe2003sp4.x86_64.rpm kernel-devel-4.19.90-2608.4.0.0386.oe2003sp4.x86_64.rpm kernel-source-4.19.90-2608.4.0.0386.oe2003sp4.x86_64.rpm kernel-tools-4.19.90-2608.4.0.0386.oe2003sp4.x86_64.rpm kernel-tools-debuginfo-4.19.90-2608.4.0.0386.oe2003sp4.x86_64.rpm kernel-tools-devel-4.19.90-2608.4.0.0386.oe2003sp4.x86_64.rpm perf-4.19.90-2608.4.0.0386.oe2003sp4.x86_64.rpm perf-debuginfo-4.19.90-2608.4.0.0386.oe2003sp4.x86_64.rpm python2-perf-4.19.90-2608.4.0.0386.oe2003sp4.x86_64.rpm python2-perf-debuginfo-4.19.90-2608.4.0.0386.oe2003sp4.x86_64.rpm python3-perf-4.19.90-2608.4.0.0386.oe2003sp4.x86_64.rpm python3-perf-debuginfo-4.19.90-2608.4.0.0386.oe2003sp4.x86_64.rpm kernel-4.19.90-2608.4.0.0386.oe2003sp4.src.rpm In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Prefer NLA_NUL_STRING These attributes are evaluated as c-string (passed to strcmp), but NLA_STRING doesn't check for the presence of a \0 terminator. Either this needs to switch to nla_strcmp() and needs to adjust printf fmt specifier to not use plain %s, or this needs to use NLA_NUL_STRING. As the code has been this way for long time, it seems to me that userspace does include the terminating nul, even tough its not enforced so far, and thus NLA_NUL_STRING use is the simpler solution. 2026-08-20 CVE-2026-63860 openEuler-20.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-08-20 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-3452 In the Linux kernel, the following vulnerability has been resolved: drm/edid: fix OOB read in drm_parse_tiled_block() drm_parse_tiled_block() casts the DisplayID block to a struct displayid_tiled_block and reads the full fixed layout up to tile->topology_id[7] without checking block->num_bytes. The DisplayID iterator only validates the declared payload length, so a crafted EDID can advertise a tiled-display block (tag DATA_BLOCK_TILED_DISPLAY, or DATA_BLOCK_2_TILED_DISPLAY_TOPOLOGY for v2.0) with a small num_bytes at the end of a DisplayID extension. The read then runs past the end of the exact-sized kmemdup()'d EDID allocation, a heap out-of-bounds read. Reject blocks shorter than the spec's 22-byte tiled payload before reading the fixed struct, as drm_parse_vesa_mso_data() already does. BUG: KASAN: slab-out-of-bounds in drm_edid_connector_update Read of size 2 at addr ffff888010077700 by task exploit/147 dump_stack_lvl (lib/dump_stack.c:94 ...) print_report (mm/kasan/report.c:378 ...) kasan_report (mm/kasan/report.c:595) drm_edid_connector_update (drivers/gpu/drm/drm_edid.c:7581) bochs_connector_helper_get_modes (drivers/gpu/drm/tiny/bochs.c:574) drm_helper_probe_single_connector_modes (drivers/gpu/drm/drm_probe_helper.c:426) status_store (drivers/gpu/drm/drm_sysfs.c:219) ... vfs_write (fs/read_write.c:595 fs/read_write.c:688) ksys_write (fs/read_write.c:740) 2026-08-20 CVE-2026-64546 openEuler-20.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-08-20 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-3452