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

On Thu, Aug 01, 2024 at 01:28:37PM +0800, Lizhi Xu 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.

Your patch is basically "fill the page with zeroes before reading anything
into it".  It makes KMSAM warning STFU, but it does not fix anything
in any of those cases.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ