Linux Kernel up to 6.12.82/6.18.23/6.19.13/7.0.0 smb check_wsl_eas heap-based overflow

Summaryinfo

A vulnerability was found in Linux Kernel up to 6.12.82/6.18.23/6.19.13/7.0.0. It has been rated as critical. The impacted element is the function check_wsl_eas of the component smb. This manipulation causes heap-based overflow. This vulnerability appears as CVE-2026-31614. There is no available exploit. Upgrading the affected component is advised.

Detailsinfo

A vulnerability classified as critical was found in Linux Kernel up to 6.12.82/6.18.23/6.19.13/7.0.0. Affected by this vulnerability is the function check_wsl_eas of the component smb. The manipulation with an unknown input leads to a heap-based overflow vulnerability. The CWE definition for the vulnerability is CWE-122. A heap overflow condition is a buffer overflow, where the buffer that can be overwritten is allocated in the heap portion of memory, generally meaning that the buffer was allocated using a routine such as malloc(). As an impact it is known to affect confidentiality, integrity, and availability. The summary by CVE is:

In the Linux kernel, the following vulnerability has been resolved: smb: client: fix off-by-8 bounds check in check_wsl_eas() The bounds check uses (u8 *)ea + nlen + 1 + vlen as the end of the EA name and value, but ea_data sits at offset sizeof(struct smb2_file_full_ea_info) = 8 from ea, not at offset 0. The strncmp() later reads ea->ea_data[0..nlen-1] and the value bytes follow at ea_data[nlen+1..nlen+vlen], so the actual end is ea->ea_data + nlen + 1 + vlen. Isn't pointer math fun? The earlier check (u8 *)ea > end - sizeof(*ea) only guarantees the 8-byte header is in bounds, but since the last EA is placed within 8 bytes of the end of the response, the name and value bytes are read past the end of iov. Fix this mess all up by using ea->ea_data as the base for the bounds check. An "untrusted" server can use this to leak up to 8 bytes of kernel heap into the EA name comparison and influence which WSL xattr the data is interpreted as.

It is possible to read the advisory at git.kernel.org. This vulnerability is known as CVE-2026-31614 since 03/09/2026. The exploitation appears to be easy. Technical details of the vulnerability are known, but there is no available exploit. The pricing for an exploit might be around USD $0-$5k at the moment (estimation calculated on 06/14/2026).

The vulnerability scanner Nessus provides a plugin with the ID 321065 (SUSE SLES15 Security Update : kernel (SUSE-SU-2026:2310-1)), which helps to determine the existence of the flaw in a target environment.

Upgrading to version 6.12.83, 6.18.24, 6.19.14 or 7.0.1 eliminates this vulnerability. Applying the patch 5cc0574c84aa73946ade587c41e81757b8b01cb5/b2b76d09a64c538c57006180103fc1841e8cfa66/ba3ad159aa61810bbe0acaf39578b1ebfb6f1a18/a893f1757d9a4009e4a8d7ceb2312142fe29cea4 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.

The vulnerability is also documented in the databases at Tenable (321065) and CERT Bund (WID-SEC-2026-1279). Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Affected

• Google Container-Optimized OS
• Debian Linux
• Red Hat Enterprise Linux
• Oracle Linux
• Open Source Linux Kernel

Productinfo

Type

• Operating System

Vendor

• Linux

Name

• Kernel

Version

• 6.12.0
• 6.12.1
• 6.12.2
• 6.12.3
• 6.12.4
• 6.12.5
• 6.12.6
• 6.12.7
• 6.12.8
• 6.12.9
• 6.12.10
• 6.12.11
• 6.12.12
• 6.12.13
• 6.12.14
• 6.12.15
• 6.12.16
• 6.12.17
• 6.12.18
• 6.12.19
• 6.12.20
• 6.12.21
• 6.12.22
• 6.12.23
• 6.12.24
• 6.12.25
• 6.12.26
• 6.12.27
• 6.12.28
• 6.12.29
• 6.12.30
• 6.12.31
• 6.12.32
• 6.12.33
• 6.12.34
• 6.12.35
• 6.12.36
• 6.12.37
• 6.12.38
• 6.12.39
• 6.12.40
• 6.12.41
• 6.12.42
• 6.12.43
• 6.12.44
• 6.12.45
• 6.12.46
• 6.12.47
• 6.12.48
• 6.12.49
• 6.12.50
• 6.12.51
• 6.12.52
• 6.12.53
• 6.12.54
• 6.12.55
• 6.12.56
• 6.12.57
• 6.12.58
• 6.12.59
• 6.12.60
• 6.12.61
• 6.12.62
• 6.12.63
• 6.12.64
• 6.12.65
• 6.12.66
• 6.12.67
• 6.12.68
• 6.12.69
• 6.12.70
• 6.12.71
• 6.12.72
• 6.12.73
• 6.12.74
• 6.12.75
• 6.12.76
• 6.12.77
• 6.12.78
• 6.12.79
• 6.12.80
• 6.12.81
• 6.12.82
• 6.18.0
• 6.18.1
• 6.18.2
• 6.18.3
• 6.18.4
• 6.18.5
• 6.18.6
• 6.18.7
• 6.18.8
• 6.18.9
• 6.18.10
• 6.18.11
• 6.18.12
• 6.18.13
• 6.18.14
• 6.18.15
• 6.18.16
• 6.18.17
• 6.18.18
• 6.18.19
• 6.18.20
• 6.18.21
• 6.18.22
• 6.18.23
• 6.19.0
• 6.19.1
• 6.19.2
• 6.19.3
• 6.19.4
• 6.19.5
• 6.19.6
• 6.19.7
• 6.19.8
• 6.19.9
• 6.19.10
• 6.19.11
• 6.19.12
• 6.19.13
• 7.0

License

• open-source

Website

• Vendor: https://www.kernel.org/

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Discussion