[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241116023241.GZ3387508@ZenIV>
Date: Sat, 16 Nov 2024 02:32:41 +0000
From: Al Viro <viro@...iv.linux.org.uk>
To: Lizhi Xu <lizhi.xu@...driver.com>
Cc: almaz.alexandrovich@...agon-software.com, brauner@...nel.org,
jack@...e.cz, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org, ntfs3@...ts.linux.dev,
syzbot+73d8fc29ec7cba8286fa@...kaller.appspotmail.com,
syzkaller-bugs@...glegroups.com
Subject: Re: [PATCH] fs: add check for symlink corrupted
On Sat, Nov 16, 2024 at 09:39:50AM +0800, Lizhi Xu wrote:
> On Fri, 15 Nov 2024 13:24:55 +0000, Al Viro wrote:
> > On Fri, Nov 15, 2024 at 01:06:15PM +0000, Al Viro wrote:
> > > On Fri, Nov 15, 2024 at 05:49:08PM +0800, Lizhi Xu wrote:
> > > > syzbot reported a null-ptr-deref in pick_link. [1]
> > > > When symlink's inode is corrupted, the value of the i_link is 2 in this case,
> > > > it will trigger null pointer deref when accessing *res in pick_link().
> > > >
> > > > To avoid this issue, add a check for inode mode, return -EINVAL when it's
> > > > not symlink.
> > >
> > > NAK. Don't paper over filesystem bugs at pathwalk time - it's the wrong
> > > place for that. Fix it at in-core inode creation time.
> >
> > BTW, seeing that ntfs doesn't even touch ->i_link, you are dealing
> Yes, ntfs3 does not handle the relevant code of i_link.
> > with aftermath of memory corruption, so it's definitely papering over
> > the actual bug here.
> I see that finding out how the value of i_link becomes 2 is the key.
How about 'how the memory currently pointed to by inode had come to be
available for use by something that stored 2 at that particular offset'?
Powered by blists - more mailing lists