fs/erofs/data.c | 10 +++++++--- fs/erofs/internal.h | 6 +++++- 2 files changed, 12 insertions(+), 4 deletions(-)
syzbot reported a null-ptr-deref in fuse_read_args_fill:
fuse_read_folio+0xb0/0x100 fs/fuse/file.c:905
filemap_read_folio+0xc6/0x2a0 mm/filemap.c:2367
do_read_cache_folio+0x263/0x5c0 mm/filemap.c:3825
read_mapping_folio include/linux/pagemap.h:1011 [inline]
erofs_bread+0x34d/0x7e0 fs/erofs/data.c:41
erofs_read_superblock fs/erofs/super.c:281 [inline]
erofs_fc_fill_super+0x2b9/0x2500 fs/erofs/super.c:625
Unlike most filesystems, some network filesystems and FUSE need
unavoidable valid `file` pointers for their read I/Os [1].
Anyway, those use cases need to be supported too.
[1] https://docs.kernel.org/filesystems/vfs.html
Reported-by: syzbot+0b1279812c46e48bb0c1@syzkaller.appspotmail.com
Fixes: fb176750266a ("erofs: add file-backed mount support")
Closes: https://lore.kernel.org/r/6727bbdf.050a0220.3c8d68.0a7e.GAE@google.com
Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
---
fs/erofs/data.c | 10 +++++++---
fs/erofs/internal.h | 6 +++++-
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/fs/erofs/data.c b/fs/erofs/data.c
index 6355866220ff..43c89194d348 100644
--- a/fs/erofs/data.c
+++ b/fs/erofs/data.c
@@ -38,7 +38,10 @@ void *erofs_bread(struct erofs_buf *buf, erofs_off_t offset,
}
if (!folio || !folio_contains(folio, index)) {
erofs_put_metabuf(buf);
- folio = read_mapping_folio(buf->mapping, index, NULL);
+ folio = buf->use_fp ?
+ read_mapping_folio(file_inode(buf->filp)->i_mapping,
+ index, buf->filp) :
+ read_mapping_folio(buf->mapping, index, NULL);
if (IS_ERR(folio))
return folio;
}
@@ -61,8 +64,9 @@ void erofs_init_metabuf(struct erofs_buf *buf, struct super_block *sb)
{
struct erofs_sb_info *sbi = EROFS_SB(sb);
- if (erofs_is_fileio_mode(sbi))
- buf->mapping = file_inode(sbi->fdev)->i_mapping;
+ buf->use_fp = erofs_is_fileio_mode(sbi);
+ if (buf->use_fp) /* some fs like FUSE needs it */
+ buf->filp = sbi->fdev;
else if (erofs_is_fscache_mode(sb))
buf->mapping = sbi->s_fscache->inode->i_mapping;
else
diff --git a/fs/erofs/internal.h b/fs/erofs/internal.h
index 5459d0b39415..df67a1980ada 100644
--- a/fs/erofs/internal.h
+++ b/fs/erofs/internal.h
@@ -208,10 +208,14 @@ enum erofs_kmap_type {
};
struct erofs_buf {
- struct address_space *mapping;
+ union {
+ struct address_space *mapping;
+ struct file *filp;
+ };
struct page *page;
void *base;
enum erofs_kmap_type kmap_type;
+ bool use_fp;
};
#define __EROFS_BUF_INITIALIZER ((struct erofs_buf){ .page = NULL })
--
2.43.5
On Thu, Nov 14, 2024 at 01:19:57PM +0800, Gao Xiang wrote: > diff --git a/fs/erofs/data.c b/fs/erofs/data.c > index 6355866220ff..43c89194d348 100644 > --- a/fs/erofs/data.c > +++ b/fs/erofs/data.c > @@ -38,7 +38,10 @@ void *erofs_bread(struct erofs_buf *buf, erofs_off_t offset, > } > if (!folio || !folio_contains(folio, index)) { > erofs_put_metabuf(buf); > - folio = read_mapping_folio(buf->mapping, index, NULL); > + folio = buf->use_fp ? > + read_mapping_folio(file_inode(buf->filp)->i_mapping, > + index, buf->filp) : > + read_mapping_folio(buf->mapping, index, NULL); UGH... 1) 'filp' is an atrocious identifier. Please, don't perpetuate the piss-poor taste of AST - if you want to say 'file', say so. 2) there's ->f_mapping; no need to go through the file_inode(). 3) AFAICS, (buf->kmap_type == EROFS_KMAP) == (buf->base != NULL). What's the point of having that as a separate field? 4) Why bother with union? Just have buf->file serve as your buf->use_fp and be done with that...
Hi Al, On 2024/11/14 14:04, Al Viro wrote: > On Thu, Nov 14, 2024 at 01:19:57PM +0800, Gao Xiang wrote: > >> diff --git a/fs/erofs/data.c b/fs/erofs/data.c >> index 6355866220ff..43c89194d348 100644 >> --- a/fs/erofs/data.c >> +++ b/fs/erofs/data.c >> @@ -38,7 +38,10 @@ void *erofs_bread(struct erofs_buf *buf, erofs_off_t offset, >> } >> if (!folio || !folio_contains(folio, index)) { >> erofs_put_metabuf(buf); >> - folio = read_mapping_folio(buf->mapping, index, NULL); >> + folio = buf->use_fp ? >> + read_mapping_folio(file_inode(buf->filp)->i_mapping, >> + index, buf->filp) : >> + read_mapping_folio(buf->mapping, index, NULL); > > UGH... > > 1) 'filp' is an atrocious identifier. Please, don't perpetuate > the piss-poor taste of AST - if you want to say 'file', say so. ok. > > 2) there's ->f_mapping; no need to go through the file_inode(). Yeah, thanks for the suggestion. > > 3) AFAICS, (buf->kmap_type == EROFS_KMAP) == (buf->base != NULL). What's > the point of having that as a separate field? Once buf->kmap_type has EROFS_KMAP and EROFS_KMAP_ATOMIC, but it seems that it can be cleaned up now. I will clean up later but it's a seperate story. > > 4) Why bother with union? Just have buf->file serve as your buf->use_fp > and be done with that... I'd like to leave `struct erofs_buf` as small as possible since it's on stack. Leave two fields for this are also ok for me anyway. Thanks, Gao Xiang
On Thu, Nov 14, 2024 at 02:23:27PM +0800, Gao Xiang wrote: > > 3) AFAICS, (buf->kmap_type == EROFS_KMAP) == (buf->base != NULL). What's > > the point of having that as a separate field? > > Once buf->kmap_type has EROFS_KMAP and EROFS_KMAP_ATOMIC, but it > seems that it can be cleaned up now. > > I will clean up later but it's a seperate story. > > > > > 4) Why bother with union? Just have buf->file serve as your buf->use_fp > > and be done with that... > > I'd like to leave `struct erofs_buf` as small as possible since > it's on stack. enum + bool eats at least as much as a pointer, and if it's on stack... an extra word is really noise - it's not as if you had a plenty of those in the current call chain at any given point.
On 2024/11/14 14:34, Al Viro wrote: > On Thu, Nov 14, 2024 at 02:23:27PM +0800, Gao Xiang wrote: > >>> 3) AFAICS, (buf->kmap_type == EROFS_KMAP) == (buf->base != NULL). What's >>> the point of having that as a separate field? >> >> Once buf->kmap_type has EROFS_KMAP and EROFS_KMAP_ATOMIC, but it >> seems that it can be cleaned up now. >> >> I will clean up later but it's a seperate story. >> >>> >>> 4) Why bother with union? Just have buf->file serve as your buf->use_fp >>> and be done with that... >> >> I'd like to leave `struct erofs_buf` as small as possible since >> it's on stack. > > enum + bool eats at least as much as a pointer, and if it's on stack... > an extra word is really noise - it's not as if you had a plenty of > those in the current call chain at any given point. Yeah, enum can be avoided now, I will clean up this enum as a seperate effort. Thanks, Gao Xiang
© 2016 - 2024 Red Hat, Inc.