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: <20240801081224.1252836-1-lizhi.xu@windriver.com>
Date: Thu, 1 Aug 2024 16:12:24 +0800
From: Lizhi Xu <lizhi.xu@...driver.com>
To: <viro@...iv.linux.org.uk>
CC: <brauner@...nel.org>, <jack@...e.cz>, <linux-fsdevel@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <lizhi.xu@...driver.com>,
        <phillip@...ashfs.org.uk>, <squashfs-devel@...ts.sourceforge.net>,
        <syzbot+24ac24ff58dc5b0d26b9@...kaller.appspotmail.com>,
        <syzkaller-bugs@...glegroups.com>
Subject: Re: [PATCH] filemap: Init the newly allocated folio memory to 0 for the filemap

On Thu, 1 Aug 2024 08:10:16 +0100, Al Viro wrote:
> > > > syzbot report KMSAN: uninit-value in pick_link, this is because the
> > > > corresponding folio was not found from the mapping, and the memory was
> > > > not initialized when allocating a new folio for the filemap.
> > > >
> > > > To avoid the occurrence of kmsan report uninit-value, initialize the
> > > > newly allocated folio memory to 0.
> > >
> > > NAK.
> > >
> > > You are papering over the real bug here.
> > Did you see the splat? I think you didn't see that.
> 
> Sigh...  It is stepping into uninitialized data in pick_link(), and by
> the look of traces it's been created by page_get_link().
> 
> What page_get_link() does is reading from page cache of symlink;
> the contents should have come from ->read_folio() (if it's really
> a symlink on squashfs, that would be squashfs_symlink_read_folio()).
> 
> Uninit might have happened if
> 	* ->read_folio() hadn't been called at all (which is an obvios
> bug - that's what should've read the symlink contents) or
> 	* ->read_folio() had been called, it failed and yet we are
> still trying to use the resulting page.  Again, an obvious bug - if
> trying to read fails, we should _not_ use the results or leave it
> in page cache for subsequent callers.
> 	* ->read_folio() had been called, claimed to have succeeded and
> yet it had left something in range 0..inode->i_size-1 uninitialized.
> Again, a bug, this time in ->read_folio() instance.
read_folio, have you noticed that the file value was passed to read_folio is NULL? 
fs/namei.c
const char *page_get_link(struct dentry *dentry, struct inode *inode
...
5272  read_mapping_page(mapping, 0, NULL);

So, Therefore, no matter what, the value of folio will not be initialized by file
in read_folio. 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ