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 require EVM resigning 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 <[email protected]> Signed-off-by: Jeff Layton <[email protected]> --- 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..1c41af2f91a60a714878ff93b554c90e45546503 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 HMAC and signatures from + * 32-bit hosts to continue working when i_ino hasn't changed + * and fits in a u32. + */ unsigned long ino; __u32 generation; uid_t uid; -- 2.53.0
