Re: [PATCH] mtd: virt_concat: fix use-after-free in mtd_virt_concat_destroy_joins()

[Luca Ceresoli]

Hello Harshit, Miquel/Richard/Vignesh,

On Sun Jun 14, 2026 at 10:10 AM CEST, Harshit Mogalapalli wrote:
> mtd_concat_destroy() frees item->concat so calling
> mtd_virt_concat_put_mtd_devices(item->concat) leads to a use after free.
>
> Fix this by moving mtd_virt_concat_put_mtd_devices() before
> mtd_concat_destroy()
>
> Fixes: 43db6366fc2d ("mtd: Add driver for concatenating devices")
> Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@xxxxxxxxxx>
> ---
> This is static analysis finding by Smatch, only compile tested.
> ---
>  drivers/mtd/mtd_virt_concat.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/mtd_virt_concat.c b/drivers/mtd/mtd_virt_concat.c
> index 37075ead0f33..a3fb96788e9d 100644
> --- a/drivers/mtd/mtd_virt_concat.c
> +++ b/drivers/mtd/mtd_virt_concat.c
> @@ -75,8 +75,8 @@ void mtd_virt_concat_destroy_joins(void)
>  		if (item->concat) {
>  			mtd_device_unregister(mtd);
>  			kfree(mtd->name);
> -			mtd_concat_destroy(mtd);
>  			mtd_virt_concat_put_mtd_devices(item->concat);
> +			mtd_concat_destroy(mtd);
>  		}
>  	}
>  }

This patch looks OK:

Reviewed-by: Luca Ceresoli <luca.ceresoli@xxxxxxxxxxx>

@Miquel/Richard/Vignesh:
However while looking at the code to understand it I noticed two possible
issues in the existing code.


Issue 1: the CONCAT() macro implementation looks hacky:

  /*
   * Given a pointer to the MTD object in the mtd_concat structure,
   * we can retrieve the pointer to that structure with this macro.
   */
  #define CONCAT(x)  ((struct mtd_concat *)(x))

Shouldn't it be implemented as a container_of() instead? The current
implementation works just "by chance", i.e. because the struct mtd_info is
the first field in struct mtd_concat.


Issue 2: in mtd_virt_concat_destroy_joins():

	list_for_each_entry_safe(item, tmp, &concat_node_list, head) {
		mtd = &item->concat->mtd; [0]
		if (item->concat) { [1]

At line [0] we dereference item->concat, but at line [1] we apparently
handle the case where item->concat can be NULL. Either [1] is always true
and we can remove the if(), or [1] can be false, so [0] is a bug and should
probably be moved to inside the if().


Do these look like correct findings?


Luca

--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com