From: sashiko-bot@kernel.org
To: "Adarsh Das" <adarshdas950@gmail.com>, linux-mtd@lists.infradead.org
Cc: joern@lazybastard.org, miquel.raynal@bootlin.com,
vigneshr@ti.com,
syzbot <syzbot+7cab6a19619f1b8efc00@syzkaller.appspotmail.com>,
richard@nod.at
Subject: Re: [PATCH mtd] mtd: block2mtd: defer device open on module param write
Date: Tue, 15 Sep 2026 19:03:53 +0000 [thread overview]
Message-ID: <20260915190354.4F4971F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260915184659.6939-1-adarshdas950@gmail.com>
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] mtd: block2mtd: list corruption due to missing lock in add_device()
- [High] mtd: block2mtd: async device creation breaks userspace ABI expectations
- [High] mtd: block2mtd: UAF on module unload due to unsafe module_put() in workqueue
- [High] mtd: block2mtd: UAF on module load failure due to uncancelled work
--
commit 2dff967915d7f4cb301503696152b0f9b535645f
Author: Adarsh Das <adarshdas950@gmail.com>
mtd: block2mtd: defer device open on module param write
This commit defers the block2mtd device setup to run asynchronously in a
workqueue. This avoids holding the module parameter lock while opening the
block device, which previously led to a circular lock dependency with
overlayfs.
Link: https://syzkaller.appspot.com/bug?id=3e420300f6b231aa906425cbb4bd55dd64f42da4
> diff --git a/drivers/mtd/devices/block2mtd.c b/drivers/mtd/devices/block2mtd.c
> index 349fa07be314c..5ef2c15a6aa1a 100644
> --- a/drivers/mtd/devices/block2mtd.c
> +++ b/drivers/mtd/devices/block2mtd.c
[ ... ]
> @@ -461,11 +463,54 @@ static int block2mtd_setup2(const char *val)
> return 0;
> }
>
> +struct block2mtd_deferred {
> + struct work_struct work;
> + char *val;
> +};
> +
> +static void block2mtd_deferred_workfn(struct work_struct *work)
> +{
> + struct block2mtd_deferred *req =
> + container_of(work, struct block2mtd_deferred, work);
> +
> + block2mtd_setup2(req->val);
> + kfree(req->val);
> + kfree(req);
> + module_put(THIS_MODULE);
[Severity: High]
Can dropping the module reference here create a use-after-free during module
unload?
When the refcount drops to zero, rmmod proceeds and unmaps the module text.
The worker thread is still running inside the module's code space and will
jump to freed memory when returning from the function epilogue.
> +}
> +
> +static int block2mtd_defer_setup2(const char *val)
> +{
> + struct block2mtd_deferred *req;
> +
> + if (strnlen(val, BLOCK2MTD_PARAM_MAXLEN) >= BLOCK2MTD_PARAM_MAXLEN)
> + return -EINVAL;
> +
> + if (!try_module_get(THIS_MODULE))
> + return -ENODEV;
> +
> + req = kmalloc_obj(struct block2mtd_deferred, GFP_KERNEL);
> + if (!req) {
> + module_put(THIS_MODULE);
> + return -ENOMEM;
> + }
> +
> + req->val = kstrdup(val, GFP_KERNEL);
> + if (!req->val) {
> + kfree(req);
> + module_put(THIS_MODULE);
> + return -ENOMEM;
> + }
> +
> + INIT_WORK(&req->work, block2mtd_deferred_workfn);
> + schedule_work(&req->work);
[Severity: High]
If module initialization fails after this point, is there a mechanism to
cancel this scheduled work?
For instance, if an invalid parameter is provided after a valid one during
module load (e.g., modprobe block2mtd block2mtd=/dev/loop0 invalid=1),
the module loader might free the module memory without waiting for the
work item. When the work executes, it would jump into unmapped memory.
[Severity: High]
Does this introduce a race condition with concurrent module parameter writes?
By deferring setup to a concurrent workqueue without adding synchronization,
multiple work items can execute add_device() concurrently on different CPUs
and race to modify the global blkmtd_device_list:
drivers/mtd/devices/block2mtd.c:add_device() {
...
list_add(&dev->list, &blkmtd_device_list);
...
}
[Severity: High]
Does deferring the setup to a workqueue break userspace ABI expectations?
Before this patch, block2mtd_setup2() ran synchronously. Deferring it makes
the sysfs write return before the device is created, which might silently
break backwards compatibility for dependent userspace workflows.
> + return 0;
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260915184659.6939-1-adarshdas950@gmail.com?part=1
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
prev parent reply other threads:[~2026-09-15 19:04 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-15 18:46 [PATCH mtd] mtd: block2mtd: defer device open on module param write Adarsh Das
2026-09-15 19:03 ` sashiko-bot [this message]
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=20260915190354.4F4971F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=adarshdas950@gmail.com \
--cc=joern@lazybastard.org \
--cc=linux-mtd@lists.infradead.org \
--cc=miquel.raynal@bootlin.com \
--cc=richard@nod.at \
--cc=sashiko-reviews@lists.linux.dev \
--cc=syzbot+7cab6a19619f1b8efc00@syzkaller.appspotmail.com \
--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.