On Tue, Mar 3, 2026 at 6:05 AM Jeff Layton <[email protected]> wrote: > On Mon, 2026-03-02 at 18:44 -0500, Paul Moore wrote: > > On Mon, Mar 2, 2026 at 3:25 PM Jeff Layton <[email protected]> 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 <[email protected]> > > > --- > > > 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. 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. -- paul-moore.com
