CVE-2026-74671 in Linux
Summary
by MITRE • 08/22/2026
In the Linux kernel, the following vulnerability has been resolved:
ima: fix out-of-bounds read in xattr_verify()
The digest-length check in xattr_verify() mixes int and size_t:
if (xattr_len - sizeof(xattr_value->type) - hash_start >= iint->ima_hash->length)
sizeof() yields size_t, so the usual arithmetic conversions promote the whole left-hand side to unsigned 64-bit before the subtraction runs. For a truncated xattr this underflows instead of going negative: a 1-byte IMA_XATTR_DIGEST_NG xattr (xattr_len == 1, hash_start == 1) turns "1 - 1 - 1" into SIZE_MAX, which is trivially >= ima_hash->length. The check then passes and the following memcmp() reads iint->ima_hash->length bytes starting past the end of the buffer vfs_getxattr_alloc() allocated for it.
Nothing upstream clamps xattr_len back into a safe range first: ima_get_hash_algo() only special-cases xattr_len < 2 to pick a default algorithm, and evm_verifyxattr() returns INTEGRITY_UNKNOWN rather than failing when no HMAC key is loaded, so a truncated security.ima value reaches the length check as-is.
Rewrite the comparison so every operand stays a signed int and no implicit conversion to size_t can occur.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/22/2026
The Linux kernel integrity measurement architecture contains a critical out-of-bounds read vulnerability within the xattr_verify function, stemming from improper type handling during arithmetic operations on attribute lengths. This flaw arises when comparing the length of an extended attribute against the expected hash digest length. Specifically, the code performs subtraction involving sizeof results and other integer values without ensuring consistent signedness across all operands. Because sizeof returns a size_t value, which is unsigned, standard C arithmetic promotion rules dictate that the entire expression on the left side of the comparison is promoted to an unsigned type before evaluation occurs. This behavior creates a dangerous scenario where underflow can occur if the attribute length is smaller than expected due to truncation or corruption.
When a truncated security extended attribute reaches this verification logic, particularly in cases involving IMA_XATTR_DIGEST_NG formats with minimal byte counts such as one-byte attributes, the arithmetic operation results in an unsigned integer overflow rather than a negative number. For instance, if xattr_len is one and hash_start is also one, the calculation of remaining length effectively becomes SIZE_MAX after promotion to size_t. This massive positive value trivially satisfies the condition that it must be greater than or equal to the expected hash length. Consequently, the validation check incorrectly passes, allowing execution to proceed to a memcmp operation that attempts to read memory beyond the bounds of the allocated buffer provided by vfs_getxattr_alloc.
The operational impact of this vulnerability is significant as it allows for out-of-bounds reads within kernel space. An attacker who can manipulate or supply truncated extended attributes associated with files protected by Integrity Measurement Architecture may trigger this code path during integrity verification processes. While an out-of-bounds read primarily poses a risk of information disclosure, depending on the specific memory layout and subsequent usage patterns, it could potentially lead to further exploitation vectors including denial of service through kernel panics or crashes if invalid pointers are dereferenced later in the execution flow. The vulnerability exists because upstream code does not clamp xattr_len into a safe range prior to these checks, relying instead on downstream logic that fails to adequately protect against malformed inputs under all conditions.
This issue aligns with CWE-190 Integer Overflow or Wraparound and CWE-787 Out-of-bounds Read within the Common Weakness Enumeration framework. From an adversarial perspective, this vulnerability facilitates unauthorized data access during integrity checks, which relates to ATT&CK techniques involving system information discovery through memory scraping if sensitive kernel structures are exposed via the leaked bytes. The root cause is a classic type confusion error where signed and unsigned types are mixed in arithmetic expressions without explicit casting or careful boundary checking beforehand.
To mitigate this vulnerability, developers have rewritten the comparison logic to ensure that every operand remains a signed integer throughout the evaluation process. By preventing implicit conversion to size_t during subtraction operations, the code now correctly handles cases where attribute lengths are insufficient by resulting in negative values rather than large unsigned positives. This ensures that truncated or malformed extended attributes fail validation checks appropriately before any memory access occurs. System administrators should apply kernel updates containing this fix immediately to prevent potential exploitation of this out-of-bounds read condition during file integrity verification operations.