On Mon, Jan 27, 2025 at 03:52:16PM -0500, Sasha Levin wrote: > On Mon, Jan 27, 2025 at 05:36:34PM +0000, Al Viro wrote: > > On Mon, Jan 27, 2025 at 12:19:54PM -0500, Sasha Levin wrote: > > > > > The full log is at: https://qa-reports.linaro.org/lkft/sashal-linus-next/build/v6.13-rc7-8584-gd4639f3659ae/testrun/27028572/suite/log-parser-test/test/kfence-bug-kfence-out-of-bounds-read-in-d_same_name/log > > > > > > LMK if I should attempt a bisection. > > > > Could you try your setup on 58cf9c383c5c "dcache: back inline names > > with a struct-wrapped array of unsigned long"? > > It looks like we didn't trigger a warnings on that commit, but I'm not > sure if the issue reproduces easily. > > I'll start a bisection and see where it takes me... Interesting... The thing is, that's the only commit that goes anywhere near ->d_name reassignments. That access smells like access just one byte past struct external_name... wait a minute. Could that be load_unaligned_zeropad() stepping just over the end of external name? If so, then a) it's a false positive (and IIRC, it's not the first time kfence gets confused by that) b) your bisection will probably converge to bdd9951f60f9 "dissolve external_name.u into separate members" which is where we'd ended up with offsetof(struct external_name, name) being 4 modulo 8. As a quick test, try to flip the order of head and count in struct external_name and see if that makes the warning go away. If it does, I'm pretty certain that theory above is correct.
