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: <20260205192550.2124130-1-clm@meta.com>
Date: Thu, 5 Feb 2026 11:22:44 -0800
From: Chris Mason <clm@...a.com>
To: "Darrick J. Wong" <djwong@...nel.org>
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

"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.

> +	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 */
> +}