[PATCH] ima: fix out-of-bounds read in xattr_verify()

[Lincoln Wallace <locnnil0@gmail.com>]

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.

Fixes: 3ea7a56067e6 ("ima: provide hash algo info in the xattr")
Cc: stable@vger.kernel.org
Signed-off-by: Lincoln Wallace <locnnil0@gmail.com>
---
Verified with a differential KASAN boot test: two kernels built from
this tree differing only in ima_appraise.c (this commit vs. its parent),
each booted under QEMU. Config: CONFIG_IMA_APPRAISE=y, CONFIG_KASAN=y,
CONFIG_EVM not set (so evm_verifyxattr() returns INTEGRITY_UNKNOWN and
appraisal reaches xattr_verify()); booted with
"ima_policy=appraise_tcb ima_appraise=log".

The victim file must be on a real filesystem (ext4 here), not the
initramfs, since the default policy carries DONT_APPRAISE rules for
tmpfs/ramfs. As root:

    unsigned char v = 0x04;              /* IMA_XATTR_DIGEST_NG */
    setxattr(path, "security.ima", &v, 1, 0);
    open(path, O_RDONLY);                /* appraisal -> OOB read */

A 1-byte value passes every gate on the way in: ima_inode_setxattr()
only rejects zero length and type >= IMA_XATTR_LAST, and
ima_get_hash_algo() short-circuits xattr_len < 2 to the default
algorithm (SHA1, length 20) rather than rejecting.

Before the fix:

    BUG: KASAN: slab-out-of-bounds in memcmp+0x226/0x250
    Read of size 8 at addr ffff8880087a1342 by task ima_poc/74
    allocated 2-byte region [ffff8880087a1340, ffff8880087a1342)
    ima_appraise_measurement+0xf49/0x2310

The allocation is 2 bytes for a 1-byte xattr: vfs_getxattr_alloc()
does krealloc(..., error + 1, ...) followed by
memset(value, 0, error + 1), so the buffer is {0x04, 0x00}. The
xattr therefore contains nothing but the type byte: no algorithm
byte, no digest.

xattr_verify() nonetheless sets hash_start = 1 for
IMA_XATTR_DIGEST_NG to step over the algorithm byte, so the memcmp()
starts at &xattr_value->data[hash_start] = offset 2 of the
allocation, past the one byte the xattr actually holds, and exactly
at the end of the allocation. That is the address in the report
above, and why KASAN records it as 0 bytes to the right of a 2-byte
region.

After the fix, no KASAN report. Program output:

    ima_poc: setxattr OK (1-byte {0x04})
    ima_poc: read() returned 10 (ok)

dmesg:

    audit: type=1800 audit(1785342238.773:2):
      pid=74 uid=0 auid=4294967295 ses=4294967295 subj=kernel 
      op=appraise_data cause=invalid-hash comm="ima_poc" 
      name="/mnt/ext4/victim" dev="vda" ino=13 res=0 errno=0

The audit outcome is unchanged: the truncated xattr is rejected
either way, and with ima_appraise=log the open is still permitted.
What changes is that before the fix the rejection happens only after
memcmp() has read past the end of the allocation.

Found by applying the Squeeze Loop strategy ("The Squeeze
Loop Strategy: Catching Coherent-and-Wrong Artifacts with an
Author-Independent Executable Oracle," Fabrice Derepas, Zenodo, DOI
10.5281/zenodo.21098476, 2026) to this code path with Frama-C/WP
deductive verification.
---
 security/integrity/ima/ima_appraise.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/security/integrity/ima/ima_appraise.c b/security/integrity/ima/ima_appraise.c
index 18d0d9154317..e39627f9c46c 100644
--- a/security/integrity/ima/ima_appraise.c
+++ b/security/integrity/ima/ima_appraise.c
@@ -274,8 +274,12 @@ static int xattr_verify(enum ima_hooks func, struct ima_iint_cache *iint,
 		} else {
 			set_bit(IMA_DIGSIG, &iint->atomic_flags);
 		}
-		if (xattr_len - sizeof(xattr_value->type) - hash_start >=
-				iint->ima_hash->length)
+		/*
+		 * Keep every operand int: sizeof() is size_t and would hide
+		 * a signed underflow as SIZE_MAX. Do not rewrite as subtraction.
+		 */
+		if (xattr_len >= (int)sizeof(xattr_value->type) + hash_start +
+				(int)iint->ima_hash->length)
 			/*
 			 * xattr length may be longer. md5 hash in previous
 			 * version occupied 20 bytes in xattr, instead of 16

---
base-commit: fc02acf6ac0ccde0c805c2daa9148683cdd01ba8
change-id: 20260729-fix-ima-underflow-40bd249a9afa

Best regards,
-- 
Lincoln Wallace <locnnil0@gmail.com>