CVE-2026-31709
Linux Kernel 5.12 – 7.0.2
Raw vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:HSummary
CVE-2026-31709 is a high-severity Improper Validation of Consistency within Input (CWE-1288) vulnerability in Linux Linux Kernel. Its CVSS base score is 8.8 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Exploit Public-Facing Application (T1190); ranked at the 18th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to SI-10 (Information Input Validation) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2026-31709 is a vulnerability in the Linux kernel's SMB client implementation, specifically affecting the cifsacl handling in functions like build_sec_desc() and id_mode_to_cifs_acl(). These functions derive a DACL pointer from a server-supplied dacloffset and use the incoming ACL to rebuild security descriptors during chmod or chown operations. While a prior fix validated the SMB ACL header to prevent immediate out-of-bounds (OOB) reads, it did not structurally validate the DACL body. A malicious server could supply a truncated DACL with a valid header claiming one or more ACEs, allowing the rewrite helpers—such as replace_sids_and_copy_aces() or set_chmod_dacl()—to process attacker-controlled data beyond the validated extent during ACE comparison or copying.
The vulnerability can be exploited by an unauthenticated attacker (PR:N) over the network (AV:N) who controls an SMB server that a victim Linux system mounts or accesses. Exploitation requires user interaction (UI:R), such as a user-initiated chmod or chown operation on a file or directory within the SMB share, which triggers the insecure DACL rewriting. Successful exploitation leads to high-impact confidentiality, integrity, and availability violations (C:H/I:H/A:H), with a CVSS v3.1 base score of 8.8, potentially enabling memory corruption, arbitrary code execution, or system crashes due to OOB reads or writes.
The provided patch references detail the mitigation via kernel commits that factor DACL structural validation into a new validate_dacl() function. This extends checks to ensure each ACE fits within DACL bounds, applied consistently before both read-side parsing (parse_dacl()) and write-side rebuild paths for chmod/chown operations. The commits are available at https://git.kernel.org/stable/c/0a8cf165566ba55a39fd0f4de172119dd646d39a and https://git.kernel.org/stable/c/b78db9bddc84136f6a0bb49e8883cf200dfb87a8, resolving the issue by enforcing agreement on well-formed DACL criteria across parser and rewriter paths.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-26518
Vulnerability Data
In the Linux kernel, the following vulnerability has been resolved: smb: client: validate the whole DACL before rewriting it in cifsacl build_sec_desc() and id_mode_to_cifs_acl() derive a DACL pointer from a server-supplied dacloffset and then use the incoming ACL to rebuild…
more
the chmod/chown security descriptor. The original fix only checked that the struct smb_acl header fits before reading dacl_ptr->size or dacl_ptr->num_aces. That avoids the immediate header-field OOB read, but the rewrite helpers still walk ACEs based on pdacl->num_aces with no structural validation of the incoming DACL body. A malicious server can return a truncated DACL that still contains a header, claims one or more ACEs, and then drive replace_sids_and_copy_aces() or set_chmod_dacl() past the validated extent while they compare or copy attacker-controlled ACEs. Factor the DACL structural checks into validate_dacl(), extend them to validate each ACE against the DACL bounds, and use the shared validator before the chmod/chown rebuild paths. parse_dacl() reuses the same validator so the read-side parser and write-side rewrite paths agree on what constitutes a well-formed incoming DACL.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
—
—
—
V2.2.2V4.2.3V12.3.2
Mitigating Controls (NIST 800-53 r5) AI
SI-10 requires validity checks on supplied inputs, directly stopping acceptance of internally inconsistent complex data.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Secure SDLC practices directly require consistency validation for complex inputs.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Security testing can detect consistency flaws but does not prevent them at design time.
Secure development lifecycle requires input validation and consistency checks that directly address CWE-1288.
Application security requirements include validation of complex inputs and cross-field consistency.
Secure architecture principles encourage robust input handling but do not specifically mandate consistency validation.
Secure coding standards explicitly require validation of interrelated input fields to prevent CWE-1288.