linux-kernel - Re: [PATCH v2] fs: add NULL check in drop

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251208201333.528909-1-dkarn@redhat.com>
Date: Tue,  9 Dec 2025 01:43:33 +0530
From: Deepakkumar Karn <dkarn@...hat.com>
To: djwong@...nel.org
Cc: brauner@...nel.org,
	dkarn@...hat.com,
	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
Subject: Re: [PATCH v2] fs: add NULL check in drop_buffers() to prevent null-ptr-deref

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.