Re: [PATCH v7 5/9] block: implement NVMEM provider

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Unhandled error pointer leads to kernel crash during device teardown.
--

Note: The format of this review is altered to provide a free-form summary of
the findings rather than inline patch quotes, due to code recitation
restrictions.

commit 14d86ba6622184a8e17868cd135ba0bd9e1e05b2
Author: Daniel Golle <daniel@makrotopia.org>
Subject: block: implement NVMEM provider

This patch allows block devices or partitions to act as NVMEM providers.
It registers an NVMEM device based on the block device's OF node layout.
It hooks into the disk addition and deletion paths to register and
unregister the NVMEM device.

[Severity: High]
In block/blk-nvmem.c:blk_nvmem_add(), if nvmem_register() fails, it returns an
error pointer which is directly assigned to bdev->bd_nvmem. The function
then returns the error code via dev_err_probe() but leaves bdev->bd_nvmem
holding the error pointer instead of resetting it to NULL.

Since add_disk_final() in block/genhd.c calls blk_nvmem_add() without
checking its return value, the disk is successfully added even if the NVMEM
registration fails.

Later, when the disk is removed, __del_gendisk() calls blk_nvmem_del(),
which passes bdev->bd_nvmem to nvmem_unregister(). Because
nvmem_unregister() only checks if the pointer is NULL and not if it is an
error pointer, won't this result in a kernel panic when it attempts to
dereference the invalid error pointer?

Could this be avoided by explicitly setting bdev->bd_nvmem to NULL on the
failure path inside blk_nvmem_add() before returning?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260701-block-as-nvmem-v7-0-3fe8205ef0a8@oss.qualcomm.com?part=5