linux-ext4 - Re: [PATCH 01/31] fuse: implement the basic iomap mechanisms

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: <20260205233121.GD7686@frogsfrogsfrogs>
Date: Thu, 5 Feb 2026 15:31:21 -0800
From: "Darrick J. Wong" <djwong@...nel.org>
To: Chris Mason <clm@...a.com>
Cc: miklos@...redi.hu, joannelkoong@...il.com, bernd@...ernd.com,
	neal@...pa.dev, linux-ext4@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH 01/31] fuse: implement the basic iomap mechanisms

On Thu, Feb 05, 2026 at 11:22:44AM -0800, Chris Mason wrote:
> "Darrick J. Wong" <djwong@...nel.org> wrote:
> > From: Darrick J. Wong <djwong@...nel.org>
> > 
> > Implement functions to enable upcalling of iomap_begin and iomap_end to
> > userspace fuse servers.
> > 
> 
> Hi everyone,
> 
> I'm trying out my AI review prompts on a few more trees, and I ran it
> on the fuse-iomap-cache branch:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=fuse-iomap-cache
> 
> This was the latest email lore could find, apologies if I grabbed the wrong one.
> 
> Hopefully the review below is useful, please let me know if there are places it
> has gone wildly wrong.  I kept the header to make it obvious exactly which
> commit I'd run through:
> 
> (I don't fully understand why it calls out commit b3f5bd5243, looks like
> it's probably just the last place that changes nearby code)
> 
> commit 99dffae5966f9647a430fa4c9198e2d2dacae172
> Author: Darrick J. Wong <djwong@...nel.org>
> 
> fuse: implement the basic iomap mechanisms
> 
> Implement functions to enable upcalling of iomap_begin and iomap_end to
> userspace fuse servers.
> 
> > diff --git a/fs/fuse/fuse_iomap.c b/fs/fuse/fuse_iomap.c
> > new file mode 100644
> > index 0000000000000..d1c2c2e1e68b8
> > --- /dev/null
> > +++ b/fs/fuse/fuse_iomap.c
> 
> [ ... ]
> 
> > @@ -0,0 +1,430 @@
> 
> [ ... ]
> 
> > +/* Convert a mapping from the server into something the kernel can use */
> > +static inline void fuse_iomap_from_server(struct iomap *iomap,
> > +					  const struct fuse_iomap_io *fmap)
> > +{
> > +	iomap->addr = fmap->addr;
> > +	iomap->offset = fmap->offset;
> > +	iomap->length = fmap->length;
> > +	iomap->type = fuse_iomap_type_from_server(fmap->type);
> > +	iomap->flags = fuse_iomap_flags_from_server(fmap->flags);
> > +	iomap->bdev = NULL; /* XXX */
> > +}
> > +
> > +/* Convert a mapping from the kernel into something the server can use */
> > +static inline void fuse_iomap_to_server(struct fuse_iomap_io *fmap,
> > +					const struct iomap *iomap)
> > +{
> > +	fmap->addr = fmap->addr;
>                      ^^^^
> 
> Does fmap->addr get the wrong value here? Looking at
> fuse_iomap_from_server() just above, it correctly does iomap->addr =
> fmap->addr. This function appears to have the reverse bug, assigning
> fmap->addr to itself instead of fmap->addr = iomap->addr. The other
> fields (offset, length, type, flags) all correctly copy from iomap.
> 
> This would cause fuse_iomap_end() to send uninitialized or garbage data
> in the addr field when calling fuse_iomap_to_server(&inarg.map, iomap).
> 
> This bug persists unfixed through commit b3f5bd524315 later in the
> series.

Yep, that's a copy-paste error from above; good catch!

--D

> > +	fmap->offset = iomap->offset;
> > +	fmap->length = iomap->length;
> > +	fmap->type = fuse_iomap_type_to_server(iomap->type);
> > +	fmap->flags = fuse_iomap_flags_to_server(iomap->flags);
> > +	fmap->dev = FUSE_IOMAP_DEV_NULL; /* XXX */
> > +}
> 
>