OESA-2026-3452 (CVE-2026-63860)
Vulnerability from osv_openeuler – Published: 2026-08-20 09:58 – Updated: 2026-08-20 09:58 – Source websiteThe 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)
| URL | Type | |
|---|---|---|
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"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"
],
"src": [
"kernel-4.19.90-2608.4.0.0386.oe2003sp4.src.rpm"
],
"x86_64": [
"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"
]
},
"package": {
"ecosystem": "openEuler:20.03-LTS-SP4",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-20.03-LTS-SP4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.19.90-2608.4.0.0386.oe2003sp4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "Medium"
},
"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\nRDMA/core: Prefer NLA_NUL_STRING\n\nThese attributes are evaluated as c-string (passed to strcmp), but\nNLA_STRING doesn\u0026apos;t check for the presence of a \\0 terminator.\n\nEither this needs to switch to nla_strcmp() and needs to adjust printf fmt\nspecifier to not use plain %s, or this needs to use NLA_NUL_STRING.\n\nAs the code has been this way for long time, it seems to me that userspace\ndoes include the terminating nul, even tough its not enforced so far, and\nthus NLA_NUL_STRING use is the simpler solution.(CVE-2026-63860)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/edid: fix OOB read in drm_parse_tiled_block()\n\ndrm_parse_tiled_block() casts the DisplayID block to a\nstruct displayid_tiled_block and reads the full fixed layout up to\ntile-\u0026gt;topology_id[7] without checking block-\u0026gt;num_bytes. The DisplayID\niterator only validates the declared payload length, so a crafted EDID\ncan advertise a tiled-display block (tag DATA_BLOCK_TILED_DISPLAY, or\nDATA_BLOCK_2_TILED_DISPLAY_TOPOLOGY for v2.0) with a small num_bytes at\nthe end of a DisplayID extension. The read then runs past the end of the\nexact-sized kmemdup()\u0026apos;d EDID allocation, a heap out-of-bounds read.\n\nReject blocks shorter than the spec\u0026apos;s 22-byte tiled payload before\nreading the fixed struct, as drm_parse_vesa_mso_data() already does.\n\n BUG: KASAN: slab-out-of-bounds in drm_edid_connector_update\n Read of size 2 at addr ffff888010077700 by task exploit/147\n dump_stack_lvl (lib/dump_stack.c:94 ...)\n print_report (mm/kasan/report.c:378 ...)\n kasan_report (mm/kasan/report.c:595)\n drm_edid_connector_update (drivers/gpu/drm/drm_edid.c:7581)\n bochs_connector_helper_get_modes (drivers/gpu/drm/tiny/bochs.c:574)\n drm_helper_probe_single_connector_modes (drivers/gpu/drm/drm_probe_helper.c:426)\n status_store (drivers/gpu/drm/drm_sysfs.c:219)\n ...\n vfs_write (fs/read_write.c:595 fs/read_write.c:688)\n ksys_write (fs/read_write.c:740)(CVE-2026-64546)",
"id": "OESA-2026-3452",
"modified": "2026-08-20T09:58:33Z",
"published": "2026-08-20T09:58:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-3452"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63860"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64546"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2026-63860",
"CVE-2026-64546"
]
}
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.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
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.