[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <enzq67rnekrh7gycgvgjc4g5ryt7qvuamaqj3ndpmns5svosa4@ozcepp4lpyls>
Date: Tue, 9 Dec 2025 12:18:05 +0100
From: Jan Kara <jack@...e.cz>
To: Deepakkumar Karn <dkarn@...hat.com>
Cc: djwong@...nel.org, brauner@...nel.org, jack@...e.cz,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
syzbot+e07658f51ca22ab65b4e@...kaller.appspotmail.com, syzkaller-bugs@...glegroups.com, viro@...iv.linux.org.uk,
David Howells <dhowells@...hat.com>, linux-afs@...ts.infradead.org
Subject: Re: [PATCH v2] fs: add NULL check in drop_buffers() to prevent
null-ptr-deref
On Tue 09-12-25 01:43:33, Deepakkumar Karn wrote:
> On Mon, 8 Dec 2025 11:30:24 -0800, Darrick J. Wong wrote:
> > > drop_buffers() dereferences the buffer_head pointer returned by
> > > folio_buffers() without checking for NULL. This leads to a null pointer
> > > dereference when called from try_to_free_buffers() on a folio with no
> > > buffers attached. This happens when filemap_release_folio() is called on
> > > a folio belonging to a mapping with AS_RELEASE_ALWAYS set but without
> > > release_folio address_space operation defined. In such case,
>
> > What user is that? All the users of AS_RELEASE_ALWAYS in 6.18 appear to
> > supply a ->release_folio. Is this some new thing in 6.19?
>
> AFS directories SET AS_RELEASE_ALWAYS but have not .release_folio.
AFAICS AFS sets AS_RELEASE_ALWAYS only for symlinks but not for
directories? Anyway I agree AFS symlinks will have AS_RELEASE_ALWAYS but no
.release_folio callback. And this looks like a bug in AFS because AFAICT
there's no point in setting AS_RELEASE_ALWAYS when you don't have
.release_folio callback. Added relevant people to CC.
Honza
--
Jan Kara <jack@...e.com>
SUSE Labs, CR
Powered by blists - more mailing lists