OESA-2026-4436

See a problem?
Please try reporting it to the source first.
Source
https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2026-4436
Import Source
https://repo.openeuler.org/security/data/osv/OESA-2026-4436.json
JSON Data
https://api.osv.dev/v1/vulns/OESA-2026-4436
Upstream
CVE (2)
Published
2026-10-22T14:35:07Z
Modified
2026-10-22T14:45:05Z
Severity
  • 4.7 (Medium) CVSS_V3 - CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H CVSS Calculator
Summary
kernel security update
Details

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)

Database specific 
{
    "severity":  "Medium"
}
References

Affected packages

openEuler:22.03-LTS-SP4 / kernel

Package

Name
kernel
Purl
pkg:rpm/openEuler/kernel&distro=openEuler-22.03-LTS-SP4

Affected ranges

Type
ECOSYSTEM
Events
Introduced
0 Unknown introduced version / All previous versions are affected
Fixed
5.10.0-338.0.0.239.oe2203sp4

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"
    ]
}

Database specific

source 
"https://repo.openeuler.org/security/data/osv/OESA-2026-4436.json"