[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250127213456.GH1977892@ZenIV>
Date: Mon, 27 Jan 2025 21:34:56 +0000
From: Al Viro <viro@...iv.linux.org.uk>
To: Sasha Levin <sashal@...nel.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [git pull] d_revalidate pile
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.
Powered by blists - more mailing lists