All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Miklos Szeredi" <mszeredi@redhat.com>
Cc: linux-cxl@vger.kernel.org, nvdimm@lists.linux.dev
Subject: Re: [PATCH v2 4/8] fuse: support opening 64 bit backing ID
Date: Thu, 01 Oct 2026 15:22:32 +0000	[thread overview]
Message-ID: <20261001152233.128201F00898@smtp.kernel.org> (raw)
In-Reply-To: <20261001150935.655979-5-mszeredi@redhat.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] fuse: negative backing ID validation bypass due to unsigned conversion
--

commit 38737a0048b9ea224c699e27954c4cb00bdfc596
Author: Miklos Szeredi <mszeredi@redhat.com>

fuse: support opening 64 bit backing ID

This commit adds a backing_id_64 field to fuse_open_out to allow opening
files with 64-bit server-allocated backing IDs. When the server sets
FUSE_BACKING_ID_64, the kernel reads the backing ID from backing_id_64
instead of backing_id.

> diff --git a/fs/fuse/iomode.c b/fs/fuse/iomode.c
> index 1a10bc65fb310..811ea603b7767 100644
> --- a/fs/fuse/iomode.c
> +++ b/fs/fuse/iomode.c
> @@ -160,7 +160,9 @@ static int fuse_file_passthrough_open(struct inode *inode, struct file *file)
>  {
>  	struct fuse_file *ff = file->private_data;
>  	struct fuse_conn *fc = get_fuse_conn(inode);
> +	struct fuse_open_out *outarg = &ff->args->open_outarg;
>  	struct fuse_backing *fb;
> +	u64 backing_id;
>  	int err;
>  
>  	/* Check allowed conditions for file open in passthrough mode */
> @@ -170,18 +172,38 @@ static int fuse_file_passthrough_open(struct inode *inode, struct file *file)
>  	if (ff->open_flags & ~FOPEN_PASSTHROUGH_MASK)
>  		return fuse_EIO("conflicting open flags");
>  
> -	fb = fuse_passthrough_open(file, ff->args->open_outarg.backing_id);
> -	if (IS_ERR(fb))
> -		return PTR_ERR(fb);
> +	if (!fc->backing_id_64) {
> +		if (outarg->backing_id_64 != 0)
> +			return fuse_EIO("64 bit backing ID set");
> +
> +		backing_id = outarg->backing_id;
> +		if (backing_id <= 0)

[Severity: Low]
Since outarg->backing_id is a signed 32-bit integer and backing_id is an
unsigned 64-bit integer, will negative IDs bypass this explicit error check
due to sign-extension during the assignment?

If outarg->backing_id is negative, it gets sign-extended into a large
positive value when assigned to the u64 backing_id. This causes the <= 0
check to evaluate to false, skipping the intended "invalid backing ID"
validation.

The code will then proceed and fail in fuse_backing_lookup(), logging
"backing not found" instead of the expected "invalid backing ID" error.

> +			return fuse_EIO("invalid backing ID");
> +	} else {
> +		if (outarg->backing_id != 0)
> +			return fuse_EIO("32 bit backing ID set");
> +
> +		backing_id = outarg->backing_id_64;
> +	}
> +	fb = fuse_backing_lookup(fc, backing_id);
> +	if (!fb)
> +		return fuse_EIO("backing not found");

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261001150935.655979-1-mszeredi@redhat.com?part=4

  reply	other threads:[~2026-10-01 15:22 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-01 15:07 [PATCH v2 0/8] fuse: DAX device based extent maps (famfs) Miklos Szeredi
2026-10-01 15:07 ` [PATCH v2 1/8] dax: replace exported dax_dev_get() with non-allocating dax_dev_find() Miklos Szeredi
2026-10-01 15:07 ` [PATCH v2 2/8] fuse: add helpers for EIO return value with kernel message Miklos Szeredi
2026-10-01 15:18   ` sashiko-bot
2026-10-01 16:32   ` Amir Goldstein
2026-10-05  9:46     ` Miklos Szeredi
2026-10-01 15:07 ` [PATCH v2 3/8] fuse: support 64 bit, server allocated backing ID Miklos Szeredi
2026-10-01 15:26   ` sashiko-bot
2026-10-01 17:07   ` Amir Goldstein
2026-10-01 18:58     ` Amir Goldstein
2026-10-05 13:33       ` Miklos Szeredi
2026-10-06 21:24         ` Amir Goldstein
2026-10-07 12:46           ` Miklos Szeredi
2026-10-01 15:07 ` [PATCH v2 4/8] fuse: support opening 64 bit " Miklos Szeredi
2026-10-01 15:22   ` sashiko-bot [this message]
2026-10-01 17:09   ` Amir Goldstein
2026-10-01 15:07 ` [PATCH v2 5/8] fuse: add support for opening dax device as backing Miklos Szeredi
2026-10-01 15:30   ` sashiko-bot
2026-10-01 16:07   ` Amir Goldstein
2026-10-01 15:07 ` [PATCH v2 6/8] fuse: add extent map data structure Miklos Szeredi
2026-10-01 15:24   ` sashiko-bot
2026-10-01 15:07 ` [PATCH v2 7/8] fuse: add extent map I/O support Miklos Szeredi
2026-10-01 15:27   ` sashiko-bot
2026-10-01 16:11   ` Amir Goldstein
2026-10-01 15:07 ` [PATCH v2 8/8] fuse: add support for striped backing Miklos Szeredi
2026-10-05 23:27 ` [PATCH v2 0/8] fuse: DAX device based extent maps (famfs) John Groves
2026-10-06  9:48   ` Miklos Szeredi
2026-10-08 23:00     ` John Groves
2026-10-09 10:39       ` Miklos Szeredi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261001152233.128201F00898@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-cxl@vger.kernel.org \
    --cc=mszeredi@redhat.com \
    --cc=nvdimm@lists.linux.dev \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.