All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Loic Poulain" <loic.poulain@oss.qualcomm.com>
Cc: devicetree@vger.kernel.org, robh@kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH v8 5/9] block: implement NVMEM provider
Date: Sat, 04 Jul 2026 13:45:54 +0000	[thread overview]
Message-ID: <20260704134554.D6C411F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260703-block-as-nvmem-v8-5-98ae32bfc49a@oss.qualcomm.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The NVMEM provider incorrectly sets `config.owner = THIS_MODULE`, failing to pin the underlying block device driver module and causing a Use-After-Free if the driver module is unloaded while a consumer holds an NVMEM cell.
--

commit 658c388a96462e54e252d777f2fc96dcf4f36d59
Author: Daniel Golle <daniel@makrotopia.org>

block: implement NVMEM provider

This patch allows block devices or partitions to act as NVMEM providers,
exposing factory-provisioned data such as MAC addresses or Wi-Fi calibration
blobs. It introduces blk_nvmem_add to register the block device with the
NVMEM framework when the appropriate device tree nodes are present.

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

[ ... ]

> +int blk_nvmem_add(struct block_device *bdev)
> +{
> +	struct device *dev = &bdev->bd_device;
> +	struct nvmem_config config = {};
> +	struct nvmem_device *nvmem;

[ ... ]

> +	config.id = NVMEM_DEVID_NONE;
> +	config.dev = dev;
> +	config.name = dev_name(dev);
> +	config.owner = THIS_MODULE;

[Severity: High]
Should this owner be set to the block device driver's module, such as
bdev->bd_disk->fops->owner, instead of THIS_MODULE?

By setting config.owner to THIS_MODULE, it seems we pin the block core
module but fail to protect the actual block device driver (like mmc_block)
from being unloaded while a consumer still holds a reference to the NVMEM
cell. 

If the driver module is unloaded, its module memory is freed. When the
consumer later releases the cell and the bd_device refcount drops to zero,
could disk_release() end up calling disk->fops->free_disk on a now-unmapped
driver module pointer and cause a crash?

> +	config.priv = (void *)(uintptr_t)dev->devt;
> +	config.reg_read = blk_nvmem_reg_read;
> +	config.size = bdev_nr_bytes(bdev);

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260703-block-as-nvmem-v8-0-98ae32bfc49a@oss.qualcomm.com?part=5

  reply	other threads:[~2026-07-04 13:45 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-03 13:45 [PATCH v8 0/9] Support for block device NVMEM providers Loic Poulain
2026-07-03 13:45 ` [PATCH v8 1/9] dt-bindings: mmc: Document fixed-layout NVMEM provider support Loic Poulain
2026-07-03 16:12   ` Support for block device NVMEM providers bluez.test.bot
2026-07-03 13:45 ` [PATCH v8 2/9] dt-bindings: net: wireless: qcom,ath10k: Document NVMEM cells Loic Poulain
2026-07-03 13:45 ` [PATCH v8 3/9] dt-bindings: bluetooth: qcom: Add NVMEM BD address cell Loic Poulain
2026-07-03 13:45 ` [PATCH v8 4/9] nvmem: layouts: Support fixed-layout as the nvmem device node itself Loic Poulain
2026-07-04 13:45   ` sashiko-bot
2026-07-03 13:45 ` [PATCH v8 5/9] block: implement NVMEM provider Loic Poulain
2026-07-04 13:45   ` sashiko-bot [this message]
2026-07-03 13:45 ` [PATCH v8 6/9] net: of_net: Add of_get_nvmem_eui48() helper for EUI-48 lookup Loic Poulain
2026-07-03 13:45 ` [PATCH v8 7/9] Bluetooth: hci_sync: Add NVMEM-backed BD address retrieval Loic Poulain
2026-07-03 13:45 ` [PATCH v8 8/9] Bluetooth: qca: Set NVMEM BD address quirks when address is invalid Loic Poulain
2026-07-03 13:45 ` [PATCH v8 9/9] arm64: dts: qcom: arduino-imola: Describe NVMEM layout for WiFi/BT addresses Loic Poulain

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=20260704134554.D6C411F00A3A@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=loic.poulain@oss.qualcomm.com \
    --cc=robh@kernel.org \
    --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.