[PATCH 2/2] EVM: add comment describing why ino field is still unsigned long
Jeff Layton
jlayton at kernel.org
Tue Mar 10 11:43:45 UTC 2026
Mimi pointed out that we didn't widen the inode number field in struct
h_misc alongside the inode->i_ino widening. While we could make an
equivalent change there, that would force EVM remeasurement on all
32-bit hosts.
Instead, leave the field as an unsigned long. This should have no effect
on 64-bit hosts, and allow things to continue working on 32-bit hosts in
the cases where the i_ino fits in 32-bits.
Add a comment explaining why it's being left as unsigned long.
Cc: Mimi Zohar <zohar at linux.ibm.com>
Signed-off-by: Jeff Layton <jlayton at kernel.org>
---
security/integrity/evm/evm_crypto.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/security/integrity/evm/evm_crypto.c b/security/integrity/evm/evm_crypto.c
index c0ca4eedb0fe5d5c30f45f515a4bc90248ec64ea..3445f4c2097f7e8af61de6299b721fc4a1d8afb4 100644
--- a/security/integrity/evm/evm_crypto.c
+++ b/security/integrity/evm/evm_crypto.c
@@ -144,6 +144,12 @@ static void hmac_add_misc(struct shash_desc *desc, struct inode *inode,
char type, char *digest)
{
struct h_misc {
+ /*
+ * Although inode->i_ino is now u64, this field remains
+ * unsigned long to allow existing hashes from 32-bit hosts
+ * to continue working when i_ino hasn't changed and fitsxi
+ * in a u32.
+ */
unsigned long ino;
__u32 generation;
uid_t uid;
--
2.53.0
More information about the Linux-security-module-archive
mailing list