OESA-2026-4436 (CVE-2026-68278)
Vulnerability from osv_openeuler – Published: 2026-10-22 14:35 – Updated: 2026-10-22 14:35 – Source websiteThe 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:
-
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.
-
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[].
-
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)
| URL | Type | |
|---|---|---|
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"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"
],
"src": [
"kernel-5.10.0-338.0.0.239.oe2203sp4.src.rpm"
],
"x86_64": [
"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"
]
},
"package": {
"ecosystem": "openEuler:22.03-LTS-SP4",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.10.0-338.0.0.239.oe2203sp4"
}
],
"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\ndrm/dp/mst: fix buffer overflows in sideband chunk accumulation\n\ndrm_dp_sideband_append_payload() has three related bugs when processing\ndevice-provided sideband reply data:\n\n1. Zero-length curchunk_len underflow: msg_len is a 6-bit field taken\n directly from the DP sideband header. If a device sends msg_len=0,\n curchunk_len is set to zero. The condition (curchunk_idx \u0026gt;= curchunk_len)\n is immediately true, and curchunk_len-1 wraps to 255 (u8 underflow).\n drm_dp_msg_data_crc4() reads 255 bytes from chunk[48], then memcpy()\n writes 255 bytes into msg[], both far out of bounds.\n\n2. chunk[48] overflow: curchunk_len can reach 63 (6-bit field). chunk[] is\n only 48 bytes. Multi-iteration payload assembly appends 16-byte blocks\n until curchunk_idx reaches curchunk_len, writing up to 15 bytes past\n the end of chunk[] into msg[].\n\n3. msg[256] overflow: each chunk contributes (curchunk_len-1) bytes to\n msg[]. No check ensures curlen + (curchunk_len-1) stays within msg[256],\n so the memcpy can spill into adjacent struct fields.\n\nAll three are reachable from any DP MST device that can forge sideband\nreply messages on a physical connection.(CVE-2026-68278)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfuse: fix invalidate lock leak on open O_TRUNC DAX failure\n\nfuse_open() takes filemap_invalidate_lock() for a DAX truncate\n(dax_truncate = true) and releases it before the out_inode_unlock\nlabel. But when fuse_dax_break_layouts() fails, the goto\nout_inode_unlock skips the unlock and leaks the rwsem, so any later\nfault or truncate on the file stalls on the stale lock.\n\nfuse_dax_break_layouts() can fail with -ERESTARTSYS when a signal\ninterrupts the wait for busy DAX pages to drain:\n\n open(\u0026quot;file\u0026quot;, O_RDWR | O_TRUNC)\n \u2514\u2500 fuse_open()\n \u251c\u2500 filemap_invalidate_lock() # dax_truncate\n \u2514\u2500 fuse_dax_break_layouts()\n \u2514\u2500 dax_break_layout()\n \u2514\u2500 wait_page_idle() # TASK_INTERRUPTIBLE\n \u2514\u2500 fuse_wait_dax_page() # unlock, schedule, re-lock\n \u2514\u2500 signal \u2192 -ERESTARTSYS\n goto out_inode_unlock # \u0026lt;- lock leaked\n\nFix this by moving filemap_invalidate_unlock() below the label so\nthat all error paths release the lock, and rename the label to\nout_unlock as it now covers more than just the inode lock.(CVE-2026-80855)",
"id": "OESA-2026-4436",
"modified": "2026-10-22T14:35:07Z",
"published": "2026-10-22T14:35:07Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-4436"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-68278"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-80855"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2026-68278",
"CVE-2026-80855"
]
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
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.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
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.