linux-kernel - Re: [PATCH v2] hfsplus: fix s_fs_info leak on mount setup failure

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20260204175257.GN3183987@ZenIV>
Date: Wed, 4 Feb 2026 17:52:57 +0000
From: Al Viro <viro@...iv.linux.org.uk>
To: Viacheslav Dubeyko <Slava.Dubeyko@....com>
Cc: "shardulsb08@...il.com" <shardulsb08@...il.com>,
	"jack@...e.cz" <jack@...e.cz>,
	"frank.li@...o.com" <frank.li@...o.com>,
	"brauner@...nel.org" <brauner@...nel.org>,
	"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
	"slava@...eyko.com" <slava@...eyko.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"shardul.b@...ricsoftware.com" <shardul.b@...ricsoftware.com>,
	"glaubitz@...sik.fu-berlin.de" <glaubitz@...sik.fu-berlin.de>,
	"janak@...ricsoftware.com" <janak@...ricsoftware.com>,
	"syzbot+99f6ed51479b86ac4c41@...kaller.appspotmail.com" <syzbot+99f6ed51479b86ac4c41@...kaller.appspotmail.com>
Subject: Re: [PATCH v2] hfsplus: fix s_fs_info leak on mount setup failure

On Wed, Feb 04, 2026 at 05:40:47PM +0000, Al Viro wrote:
> On Wed, Feb 04, 2026 at 05:30:29PM +0000, Al Viro wrote:
> 
> > While we are at it, this
> >         kfree(sbi->s_vhdr_buf);
> > 	kfree(sbi->s_backup_vhdr_buf);
> > might as well go into ->kill_sb().  That would result in the (untested)
> > delta below and IMO it's easier to follow that way...
> 
> AFAICS once you've got ->s_root set, you can just return an error and
> be done with that - regular cleanup should take care of those parts
> (note that iput(NULL) is explicitly a no-op and the same goes for
> cancel_delayed_work_sync() on something that has never been through
> queue_delayed_work()).

Scratch the last one - you'd get nls leak that way, thanks to the
trickery in there...  Depending on how much do you dislike cleanup.h
stuff, there might be a way to deal with that, though...