On Tue, 2026-03-03 at 11:03 -0500, Paul Moore wrote:
On Tue, Mar 3, 2026 at 6:05 AM Jeff Layton jlayton@kernel.org wrote:
On Mon, 2026-03-02 at 18:44 -0500, Paul Moore wrote:
On Mon, Mar 2, 2026 at 3:25 PM Jeff Layton jlayton@kernel.org wrote:
inode->i_ino is being widened from unsigned long to u64. The audit subsystem uses unsigned long ino in struct fields, function parameters, and local variables that store inode numbers from arbitrary filesystems. On 32-bit platforms this truncates inode numbers that exceed 32 bits, which will cause incorrect audit log entries and broken watch/mark comparisons.
Widen all audit ino fields, parameters, and locals to u64, and update the inode format string from %lu to %llu to match.
Signed-off-by: Jeff Layton jlayton@kernel.org
include/linux/audit.h | 2 +- kernel/audit.h | 9 ++++----- kernel/audit_fsnotify.c | 4 ++-- kernel/audit_watch.c | 8 ++++---- kernel/auditsc.c | 2 +- 5 files changed, 12 insertions(+), 13 deletions(-)
We should also update audit_hash_ino() in kernel/audit.h. It is a *very* basic hash function, so I think leaving the function as-is and just changing the inode parameter from u32 to u64 should be fine.
...
It doesn't look like changing the argument type will make any material difference. Given that it should still work without that change, can we leave this cleanup for you to do in a follow-on patchset?
I would prefer if you made the change as part of the patch, mainly to keep a patch record of this being related.
Ok, I'll see about factoring that in.
Ideally I'd really like to see kino_t used in the audit code instead of u64, but perhaps that is done in a later patch that I didn't see.
I think I didn't make this clear enough in the cover letter, but kino_t is removed at the end of the series. It's just there to support the change during the interim.
If HCH gets his way to do the changes as one big patch, it'll go away entirely.