CVE-2026-74671: ima: fix out-of-bounds read in xattr_verify()

Q: What input is required to trigger the out-of-bounds read?

The vulnerable path requires a truncated security.ima extended attribute, specifically an IMA_XATTR_DIGEST_NG value whose length is too short for the subsequent digest comparison. The described example is a one-byte xattr, where the length calculation underflows and allows memcmp() to read beyond the allocated xattr buffer.

Q: Does the absence of an EVM HMAC key prevent exposure?

No. When no HMAC key is loaded, evm_verifyxattr() returns INTEGRITY_UNKNOWN rather than rejecting the xattr, allowing a truncated security.ima value to reach xattr_verify() unchanged.

Q: How can this issue be mitigated if the fix cannot be applied immediately?

The provided data identifies malformed or truncated security.ima xattrs as the triggering condition. Avoiding or rejecting such xattr values prevents the described out-of-bounds read path, although no specific configuration-only mitigation is provided.

Published Aug 22, 2026

Updated

In the Linux kernel, the following vulnerability has been resolved:

ima: fix out-of-bounds read in xattrverify()

The digest-length check in xattrverify() mixes int and sizet:

if (xattrlen - sizeof(xattrvalue->type) - hashstart >= iint->imahash->length)

sizeof() yields sizet, 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 IMAXATTRDIGESTNG xattr (xattrlen == 1, hashstart == 1) turns "1 - 1 - 1" into SIZEMAX, which is trivially >= imahash->length. The check then passes and the following memcmp() reads iint->imahash->length bytes starting past the end of the buffer vfsgetxattralloc() allocated for it.

Nothing upstream clamps xattrlen back into a safe range first: imagethashalgo() only special-cases xattrlen < 2 to pick a default algorithm, and evmverifyxattr() returns INTEGRITYUNKNOWN 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 sizet can occur.

Event History

Aug 22, 2026

CVE Published

via MITRE·03:32 PM

Data Sourced

via MITRE·03:32 PM

Description

Frequently Asked Questions

What input is required to trigger the out-of-bounds read?

The vulnerable path requires a truncated security.ima extended attribute, specifically an IMA_XATTR_DIGEST_NG value whose length is too short for the subsequent digest comparison. The described example is a one-byte xattr, where the length calculation underflows and allows memcmp() to read beyond the allocated xattr buffer.

Does the absence of an EVM HMAC key prevent exposure?

No. When no HMAC key is loaded, evm_verifyxattr() returns INTEGRITY_UNKNOWN rather than rejecting the xattr, allowing a truncated security.ima value to reach xattr_verify() unchanged.

How can this issue be mitigated if the fix cannot be applied immediately?

The provided data identifies malformed or truncated security.ima xattrs as the triggering condition. Avoiding or rejecting such xattr values prevents the described out-of-bounds read path, although no specific configuration-only mitigation is provided.

CVE-2026-74671: ima: fix out-of-bounds read in xattr_verify()

Event History

Frequently Asked Questions

What input is required to trigger the out-of-bounds read?

Does the absence of an EVM HMAC key prevent exposure?

How can this issue be mitigated if the fix cannot be applied immediately?

Company

Resources

Contact

Frequently Asked Questions

What input is required to trigger the out-of-bounds read?

Does the absence of an EVM HMAC key prevent exposure?

How can this issue be mitigated if the fix cannot be applied immediately?