All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pratyush Yadav <pratyush@kernel.org>
To: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: "He, Guocai (CN)" <Guocai.He.CN@windriver.com>,
	 "richard@nod.at" <richard@nod.at>,
	 "vigneshr@ti.com" <vigneshr@ti.com>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	 Tudor Ambarus <tudor.ambarus@linaro.org>,
	 Michael Walle <michael@walle.cc>,
	Pratyush Yadav <pratyush@kernel.org>
Subject: Re: [BUG] MTD: refcount underflow/use-after-free during rapid SPI NOR unbind/bind cycles
Date: Fri, 05 Dec 2025 18:43:39 +0100	[thread overview]
Message-ID: <86h5u4rfhw.fsf@kernel.org> (raw)
In-Reply-To: <87bjkd8hl8.fsf@bootlin.com> (Miquel Raynal's message of "Fri, 05 Dec 2025 09:21:07 +0100")

On Fri, Dec 05 2025, Miquel Raynal wrote:

> Hello,
>
> On 28/11/2025 at 02:24:11 GMT, "He, Guocai (CN)" <Guocai.He.CN@windriver.com> wrote:
>
>> Hi MTD maintainers,
>>
>> I'm reporting a kernel bug in the MTD subsystem that causes a refcount
>> underflow and use-after-free warning during rapid SPI NOR driver
>> unbind/bind operations.
>
> Adding all SPI NOR gurus in the Cc list.

Sounds a bit similar to something we got reports for earlier as well [0]
(though this one could be a similar but different bug). IIRC there was
another patch/thread for it but I can't seem to find it.

I think we should do some sort of locking or ref counting to make sure
no operations are in progress during the driver bind or unbind. I never
got around to poking into it too deeply, and I am not sure I can find
time for it in the near future either.

This is something we should fix, but I am not too worried about it since
I don't think anyone should be rapidly binding and unbinding the driver
in any real workload.

[0] https://lore.kernel.org/linux-mtd/20250325133954.3699535-1-liwei.song.lsong@gmail.com/T/#u

>
> Thanks,
> Miquèl
>
>> ## Environment
>> - Kernel version: 6.6.116-yocto-standard #1  (6.12 have the same issue)
>> - Architecture: SoCFPGA Stratix 10 SoCDK (ARM64  have the same issue)
>> - Device: SPI NOR flash (mt25qu02g, 262144 Kbytes)
>> - SPI controller: ff8d2000.spi.0
>>
>> ## Reproduction Steps
>> 1. In one SSH session, run continuous unbind/bind:
>>    ```bash
>>    while :; do
>>        echo spi0.0 >/sys/bus/spi/devices/spi0.0/driver/unbind
>>        echo spi0.0 >/sys/bus/spi/drivers/spi-nor/bind
>>    done
>>    ```
>>
>> 2. In another SSH session, continuously read MTD info:
>>    ```bash
>>    while :; do cat /proc/mtd; done
>>    ```
>>
>> 3. After running for some time, the following call trace appears:
>>
>> ## Call Trace
>> ```
>> Deleting MTD partitions on "ff8d2000.spi.0":
>> Deleting u-boot MTD partition
>> ------------[ cut here ]------------
>> refcount_t: underflow; use-after-free.
>> WARNING: CPU: 2 PID: 921 at /lib/refcount.c:28 refcount_warn_saturate+0xf4/0x148
>> Modules linked in: sch_fq_codel openvswitch nsh nf_conncount nf_nat fuse nfnetlink
>> CPU: 2 PID: 921 Comm: sh Not tainted 6.6.116-yocto-standard #1
>> Hardware name: SoCFPGA Stratix 10 SoCDK (DT)
>> pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
>> pc : refcount_warn_saturate+0xf4/0x148
>> lr : refcount_warn_saturate+0xf4/0x148
>> sp : ffff8000829abaf0
>>
>> Call trace:
>>  refcount_warn_saturate+0xf4/0x148
>>  del_mtd_device+0x118/0x140
>>  __del_mtd_partitions+0x94/0xf8
>>  del_mtd_partitions+0x50/0x80
>>  mtd_device_unregister+0x50/0x90
>>  spi_nor_remove+0x2c/0x48
>>  spi_mem_remove+0x28/0x40
>>  spi_remove+0x38/0x60
>>  device_remove+0x54/0x90
>>  device_release_driver_internal+0x1d4/0x238
>>  device_driver_detach+0x20/0x38
>>  unbind_store+0xbc/0xc8
>>  drv_attr_store+0x2c/0x48
>>  sysfs_kf_write+0x4c/0x68
>>  kernfs_fop_write_iter+0x138/0x1f0
>>  vfs_write+0x1b8/0x2e0
>>  ksys_write+0x7c/0x120
>>  __arm64_sys_write+0x24/0x38
>>  invoke_syscall+0x5c/0x138
>>  el0_svc_common.constprop.0+0x48/0xf0
>>  do_el0_svc+0x24/0x38
>> do_el0_svc+0x24/0x38
>>  el0_svc+0x38/0x108
>>  el0t_64_sync_handler+0x120/0x130
>>  el0t_64_sync+0x190/0x198
>> ```
>>
>> ## Analysis
>> This appears to be a race condition? :
>> 1. The unbind operation triggers MTD partition deletion via del_mtd_device()
>> 2. Simultaneously, another process reading /proc/mtd holds references to the MTD device
>> 3. The reference count goes negative, indicating the device was freed while still being accessed
>>
>> ## Additional Information
>> - The issue is reproducible with the above test case
>>
>> Please let me know if you need any additional information or testing.
>>
>> Best regards,
>> Guocai He

-- 
Regards,
Pratyush Yadav

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  reply	other threads:[~2025-12-05 17:43 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-28  2:24 [BUG] MTD: refcount underflow/use-after-free during rapid SPI NOR unbind/bind cycles He, Guocai (CN)
2025-12-05  8:21 ` Miquel Raynal
2025-12-05 17:43   ` Pratyush Yadav [this message]
2025-12-08  7:52     ` He, Guocai (CN)

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=86h5u4rfhw.fsf@kernel.org \
    --to=pratyush@kernel.org \
    --cc=Guocai.He.CN@windriver.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=michael@walle.cc \
    --cc=miquel.raynal@bootlin.com \
    --cc=richard@nod.at \
    --cc=tudor.ambarus@linaro.org \
    --cc=vigneshr@ti.com \
    /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.