linux-kernel - RE: [PATCH v4 1/3] hfsplus: fix to update ctime after rename

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: <cce1a29f2f55baf679c3fe83269d9bceb3c4fd6c.camel@ibm.com>
Date: Wed, 23 Jul 2025 17:58:01 +0000
From: Viacheslav Dubeyko <Slava.Dubeyko@....com>
To: "frank.li@...o.com" <frank.li@...o.com>,
        "viro@...iv.linux.org.uk"
	<viro@...iv.linux.org.uk>
CC: "glaubitz@...sik.fu-berlin.de" <glaubitz@...sik.fu-berlin.de>,
        "slava@...eyko.com" <slava@...eyko.com>,
        "linux-fsdevel@...r.kernel.org"
	<linux-fsdevel@...r.kernel.org>,
        "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v4 1/3] hfsplus: fix to update ctime after rename

On Wed, 2025-07-23 at 03:32 +0100, Al Viro wrote:
> On Tue, Jul 22, 2025 at 01:13:45AM -0600, Yangtao Li wrote:
> 
> > @@ -552,9 +553,13 @@ static int hfsplus_rename(struct mnt_idmap *idmap,
> >  	res = hfsplus_rename_cat((u32)(unsigned long)old_dentry->d_fsdata,
> >  				 old_dir, &old_dentry->d_name,
> >  				 new_dir, &new_dentry->d_name);
> > -	if (!res)
> > -		new_dentry->d_fsdata = old_dentry->d_fsdata;
> > -	return res;
> > +	if (res)
> > +		return res;
> > +
> > +	new_dentry->d_fsdata = old_dentry->d_fsdata;
> 
> 	Umm...  Is that assignment (either before or after that patch)
> actually correct?
> 
> 	Note that new_dentry essentially got unlinked here; old_dentry
> is about to have its parent/name changed by the caller of ->rename(),
> so...  that looks very odd.
> 
> 	What is that line about?

So, as far as I can see, the dentry structure [1] has:

void *d_fsdata;			/* fs-specific data */

And HFS+ is using this field to store Catalog File's ID (CNID) of
the file or folder, for example [2]:

static inline void hfsplus_instantiate(struct dentry *dentry,
				       struct inode *inode, u32 cnid)
{
	dentry->d_fsdata = (void *)(unsigned long)cnid;
	d_instantiate(dentry, inode);
}

So, this line simply copies CNID from old_dentry->d_fsdata to
new_dentry->d_fsdata during the rename operation. I assume that
->fs_data should be untouched by generic logic of dentries processing.

Thanks,
Slava.

[1]
https://elixir.bootlin.com/linux/v6.16-rc6/source/include/linux/dcache.h#L108
[2] 
https://elixir.bootlin.com/linux/v6.16-rc7/source/fs/hfsplus/dir.c#L25