Skip to main content

Linux EUVDEUVD-2026-25507

| CVE-2026-31614 HIGH
Out-of-bounds Read (CWE-125)
2026-04-24 Linux GHSA-p37w-xhv5-6c8j
7.1
CVSS 3.1 · NVD
Share

Severity by source

NVD PRIMARY
7.1 HIGH
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
SUSE
HIGH
qualitative
Red Hat
5.7 MEDIUM
qualitative

Primary rating from NVD.

CVSS VectorNVD

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
None
Availability
High

Lifecycle Timeline

5
CVSS changed
Apr 29, 2026 - 18:07 NVD
7.1 (HIGH)
Patch released
Apr 29, 2026 - 18:03 nvd
Patch available
Patch available
Apr 24, 2026 - 16:16 EUVD
EUVD ID Assigned
Apr 24, 2026 - 15:00 euvd
EUVD-2026-25507
CVE Published
Apr 24, 2026 - 14:42 nvd
HIGH 7.1

DescriptionCVE.org

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.

Analysis

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.

Vendor StatusVendor

SUSE

Severity: High
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Fixed
SUSE Linux Enterprise Desktop 15 SP7 Fixed
SUSE Linux Enterprise High Availability Extension 15 SP7 Fixed
SUSE Linux Enterprise High Availability Extension 15 SP7 Fixed
SUSE Linux Enterprise High Performance Computing 15 SP7 Fixed

Share

EUVD-2026-25507 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy