linux-kernel - RE: [f2fs-dev] [PATCH 1/3 V2] f2fs: check filename length in recover

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] [day] [month] [year] [list]

Message-id: <000001cf01e5$c9e8a7c0$5db9f740$@samsung.com>
Date:	Thu, 26 Dec 2013 10:53:39 +0800
From:	Chao Yu <chao2.yu@...sung.com>
To:	jaegeuk.kim@...sung.com
Cc:	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-f2fs-devel@...ts.sourceforge.net
Subject: RE: [f2fs-dev] [PATCH 1/3 V2] f2fs: check filename length in
 recover_dentry

Hi,

> -----Original Message-----
> From: Jaegeuk Kim [mailto:jaegeuk.kim@...sung.com]
> Sent: Thursday, December 26, 2013 6:55 AM
> To: Chao Yu
> Cc: linux-fsdevel@...r.kernel.org; linux-kernel@...r.kernel.org; linux-f2fs-devel@...ts.sourceforge.net
> Subject: Re: [f2fs-dev] [PATCH 1/3 V2] f2fs: check filename length in recover_dentry
> 
> Hi,
> 
> 2013-12-23 (월), 11:12 +0800, Chao Yu:
> > In current flow, we will get Null return value of f2fs_find_entry in
> > recover_dentry when name.len is bigger than F2FS_NAME_LEN, and then we
> > still add this inode into its dir entry.
> > To avoid this situation, we must check filename length before we use it.
> >
> > Another point is that we could remove the code of checking filename length
> > In f2fs_find_entry, because f2fs_lookup will be called previously to ensure of
> > validity of filename length.
> 
> The f2fs_find_entry is called by f2fs_unlink and f2fs_rename too.

As I check code and test, f2fs_unlink and f2fs_rename is protected by
f2fs_lookup well.
Oldfile/newfile/deletedfile name length is check previously in f2fs_lookup.

> So, you can't remove this, instead it'd be better remove it from
> f2fs_lookup.

I think verification of filename length could not be removed from lookup.
Ever you remove it, we could create file in f2fs device with filename length
that vfs not supported.
In my test, kernel seems not be stable after that kind of file created in f2fs.

> Thanks,
> 
> >
> > V2:
> >  o add WARN_ON() as Jaegeuk Kim suggested.
> >
> > Signed-off-by: Chao Yu <chao2.yu@...sung.com>
> > ---
> >  fs/f2fs/dir.c      |    3 ---
> >  fs/f2fs/recovery.c |    6 ++++++
> >  2 files changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
> > index 07ad850..f0b4630 100644
> > --- a/fs/f2fs/dir.c
> > +++ b/fs/f2fs/dir.c
> > @@ -190,9 +190,6 @@ struct f2fs_dir_entry *f2fs_find_entry(struct inode *dir,
> >  	unsigned int max_depth;
> >  	unsigned int level;
> >
> > -	if (unlikely(namelen > F2FS_NAME_LEN))
> > -		return NULL;
> > -
> >  	if (npages == 0)
> >  		return NULL;
> >
> > diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c
> > index a3f4542..4d411a2 100644
> > --- a/fs/f2fs/recovery.c
> > +++ b/fs/f2fs/recovery.c
> > @@ -62,6 +62,12 @@ static int recover_dentry(struct page *ipage, struct inode *inode)
> >
> >  	name.len = le32_to_cpu(raw_inode->i_namelen);
> >  	name.name = raw_inode->i_name;
> > +
> > +	if (unlikely(name.len > F2FS_NAME_LEN)) {
> > +		WARN_ON(1);
> > +		err = -ENAMETOOLONG;
> > +		goto out;
> > +	}
> >  retry:
> >  	de = f2fs_find_entry(dir, &name, &page);
> >  	if (de && inode->i_ino == le32_to_cpu(de->ino))
> 
> --
> Jaegeuk Kim
> Samsung

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/