Re: [PATCH v3 1/7] dt-bindings: mmc: Document support for nvmem-layout

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Adding `nvmem-layout` as a child of a `fixed-partitions` node triggers a preexisting uninitialized memory bug and potential kernel panic in the block partition parser.
--

commit c354fbea36b7189e3294f56d353e1ba1075bff4d
Author: Loic Poulain <loic.poulain@oss.qualcomm.com>

dt-bindings: mmc: Document support for nvmem-layout

Add support for an nvmem-layout subnode under an eMMC hardware partition.
This allows the partition to be exposed as an NVMEM provider and its
internal layout to be described.

> diff --git a/Documentation/devicetree/bindings/mmc/mmc-card.yaml b/Documentation/devicetree/bindings/mmc/mmc-card.yaml
> index a61d6c96df759..ca907ad730959 100644
> --- a/Documentation/devicetree/bindings/mmc/mmc-card.yaml
> +++ b/Documentation/devicetree/bindings/mmc/mmc-card.yaml
> @@ -40,6 +40,9 @@ patternProperties:
>          contains:
>            const: fixed-partitions
>  
> +      nvmem-layout:
> +        $ref: /schemas/nvmem/layouts/nvmem-layout.yaml
> +

[Severity: High]
This isn't a bug introduced by this patch, but does adding this node trigger
an uninitialized memory bug during block partition parsing?

When the block layer parses subpartitions, it iterates over all child nodes
of the fixed-partitions node. Since the nvmem-layout child node lacks a reg
property, the block partition parser encounters an issue here in
block/partitions/of.c:validate_of_partition():

	int len;

	const __be32 *reg = of_get_property(np, "reg", &len);
	int a_cells = of_n_addr_cells(np);
	int s_cells = of_n_size_cells(np);

	/* Make sure reg len match the expected addr and size cells */
	if (len / sizeof(*reg) != a_cells + s_cells)
		return -EINVAL;

	/* Validate offset conversion from bytes to sectors */
	offset = of_read_number(reg, a_cells);

Because of_get_property() returns NULL for nodes without a reg property,
len remains uninitialized stack garbage.

If the garbage value happens to satisfy the length check, it will call
of_read_number() with a NULL reg pointer, leading to a kernel panic.

Otherwise, it returns -EINVAL, causing of_partition() to abort and fail to
register any of the device tree partitions for the disk.

Should this block parser bug be addressed before or alongside encouraging
this topology in the device tree bindings?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260608-block-as-nvmem-v3-0-82681f50aa35@oss.qualcomm.com?part=1