Re: [PATCH v9 06/10] block: implement NVMEM provider

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Information Leak and TOCTOU race via dev_t reuse in NVMEM reads.
- [Medium] API Contract Violation: NVMEM reads use BLK_OPEN_EXCL, causing legitimate reads to fail with -EBUSY.
--

--- Patch [6]: [PATCH v9 06/10] block: implement NVMEM provider ---
commit 0a2168c8881ee78cc2df1f1e3f11c57aff14d1fd
Author: Loic Poulain <loic.poulain@oss.qualcomm.com>

block: implement NVMEM provider

Allow referencing a partition in device tree for the kernel and Wi-Fi
drivers to access it via the NVMEM layer. The NVMEM device is registered
for a block device whose OF node describes an NVMEM layout.

> The NVMEM device is a read-only side channel: the block device stays
> fully usable, reads are performed with a non-exclusive BLK_OPEN_READ
> open, and no synchronization is done against concurrent writes to the
> same region. This is acceptable for the intended use case of write-once,
> factory-provisioned data.

[Severity: Medium]
The commit message states that reads are performed with a non-exclusive
BLK_OPEN_READ open, but the implementation uses BLK_OPEN_EXCL. Will this
cause legitimate NVMEM reads to fail with -EBUSY if the underlying block
device or any of its partitions are already claimed by a filesystem?

> diff --git a/block/blk-nvmem.c b/block/blk-nvmem.c
> new file mode 100644
> index 0000000000000..05bc35b9b8f37
> --- /dev/null
> +++ b/block/blk-nvmem.c

[ ... ]

> +static int blk_nvmem_reg_read(void *priv, unsigned int from,
> +			      void *val, size_t bytes)
> +{
> +	struct block_device *bdev = priv;
> +	struct file *bdev_file;
> +	loff_t pos = from;
> +	ssize_t ret;
> +
> +	/* open and prevent other exclusive openers */
> +	bdev_file = bdev_file_open_by_dev(bdev->bd_dev,
> +					  BLK_OPEN_READ | BLK_OPEN_EXCL,
> +					  blk_nvmem_reg_read, NULL);

[Severity: High]
Is there a risk of a TOCTOU race and information leak here via dev_t reuse?

If the original partition is logically deleted, making its dev_t available,
and a new partition is created with the same dev_t, bdev_file_open_by_dev()
could look up and read from the newly created partition instead of the
original NVMEM partition.

Could we verify that file_bdev(bdev_file) == bdev after opening to ensure
the dev_t has not been reassigned to a different block device?

> +	if (IS_ERR(bdev_file))
> +		return PTR_ERR(bdev_file);
> +
> +	ret = kernel_read(bdev_file, val, bytes, &pos);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260730-block-as-nvmem-v9-0-f72935817dbf@oss.qualcomm.com?part=6