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.
