* [PATCH v2] md/raid1: prevent a race between write and stop request
2026-08-28 10:39 ` [PATCH] md/raid1: prevent a race between write and stop request Edward Adam Davis
@ 2026-08-28 10:49 ` Edward Adam Davis
2026-08-28 11:04 ` sashiko-bot
2026-08-28 10:55 ` [PATCH] " sashiko-bot
2026-08-28 14:27 ` Abd-Alrhman Masalkhi
2 siblings, 1 reply; 5+ messages in thread
From: Edward Adam Davis @ 2026-08-28 10:49 UTC (permalink / raw)
To: eadavis
Cc: linux-kernel, linux-raid, magiclinan, song,
syzbot+3fe892ea5fc292e1353f, syzkaller-bugs, xiao, yukuai
A race condition exists between write and stop requests, leading to a
null-ptr-deref in [1].
CPU0 CPU1
==== ====
md_submit_bio()
md_handle_request() do_md_stop()
raid1_make_request() __md_stop()
raid1_write_request() mddev->private = NULL
wait_barrier()
conf->nr_pending //trigger [1]
The intervention of a stop request causes inconsistencies in the state
of mddev members (such as private and pers) while a write request is
executing; the mddev lock is used to synchronize write and stop requests,
thereby ensuring consistent mddev state throughout the execution of the
write request.
Additionally, when a write operation reaches the RAID1 layer, if a stop
request acquires the mddev lock first and releases mddev->private, the
bio is terminated and the write request exits.
[1]
KASAN: null-ptr-deref in range [0x0000000000000120-0x0000000000000127]
RIP: 0010:_wait_barrier+0x8d/0x700 drivers/md/raid1.c:1066
Call Trace:
wait_barrier drivers/md/raid1.c:1154 [inline]
raid1_write_request drivers/md/raid1.c:1506 [inline]
raid1_make_request+0x484/0x31a0 drivers/md/raid1.c:1696
md_handle_request+0x824/0x1230 drivers/md/md.c:417
md_submit_bio+0x1e9/0x350 drivers/md/md.c:458
__submit_bio block/blk-core.c:681 [inline]
__submit_bio+0x20e/0x3d0 block/blk-core.c:670
__submit_bio_noacct block/blk-core.c:724 [inline]
submit_bio_noacct_nocheck+0x736/0xc00 block/blk-core.c:792
submit_bio_noacct+0xc93/0x2130 block/blk-core.c:925
bio_await+0x1fa/0x240 block/bio.c:1580
submit_bio_wait+0x19/0x60 block/bio.c:1598
__blkdev_direct_IO_simple+0x4cb/0x8c0 block/fops.c:98
blkdev_direct_IO+0xbee/0x2030 block/fops.c:429
blkdev_direct_write block/fops.c:699 [inline]
blkdev_write_iter+0x703/0xd30 block/fops.c:767
new_sync_write fs/read_write.c:595 [inline]
vfs_write+0x6af/0x1050 fs/read_write.c:687
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reported-by: syzbot+3fe892ea5fc292e1353f@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=3fe892ea5fc292e1353f
Tested-by: syzbot+3fe892ea5fc292e1353f@syzkaller.appspotmail.com
Signed-off-by: Edward Adam Davis <eadavis@sina.com>
---
v1 -> v2: typo in comments
drivers/md/raid1.c | 28 +++++++++++++++++++++++++++-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
index f0646fb24371..3b9f1fa65e65 100644
--- a/drivers/md/raid1.c
+++ b/drivers/md/raid1.c
@@ -1674,6 +1674,7 @@ static bool raid1_write_request(struct mddev *mddev, struct bio *bio,
static bool raid1_make_request(struct mddev *mddev, struct bio *bio)
{
sector_t sectors;
+ blk_status_t status;
if (unlikely(bio->bi_opf & REQ_PREFLUSH)
&& md_flush_request(mddev, bio))
@@ -1692,11 +1693,36 @@ static bool raid1_make_request(struct mddev *mddev, struct bio *bio)
if (bio_data_dir(bio) == READ)
raid1_read_request(mddev, bio, sectors, NULL);
else {
+ int err;
+
md_write_start(mddev, bio);
- if (!raid1_write_request(mddev, bio, sectors))
+ err = mddev_lock(mddev);
+
+ if (err < 0) {
+ md_write_end(mddev);
+ status = BLK_STS_IOERR;
+ goto done;
+ }
+
+ if (!mddev->private) {
+ mddev_unlock(mddev);
+ md_write_end(mddev);
+ status = BLK_STS_OFFLINE;
+ goto done;
+ }
+
+ err = raid1_write_request(mddev, bio, sectors);
+ mddev_unlock(mddev);
+
+ if (!err)
md_write_end(mddev);
}
+out:
return true;
+done:
+ bio->bi_status = status;
+ bio_endio(bio);
+ goto out;
}
static void raid1_status(struct seq_file *seq, struct mddev *mddev)
--
2.43.0
^ permalink raw reply related [flat|nested] 5+ messages in thread* Re: [PATCH v2] md/raid1: prevent a race between write and stop request
2026-08-28 10:49 ` [PATCH v2] " Edward Adam Davis
@ 2026-08-28 11:04 ` sashiko-bot
0 siblings, 0 replies; 5+ messages in thread
From: sashiko-bot @ 2026-08-28 11:04 UTC (permalink / raw)
To: Edward Adam Davis; +Cc: linux-raid, yukuai
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
New issues:
- [High] Acquiring a global configuration mutex (`reconfig_mutex`) in the I/O fast path serializes all RAID1 writes and violates non-blocking semantics.
- [High] Using an interruptible lock (`mutex_lock_interruptible`) in the block I/O submission path causes spurious block I/O errors (`BLK_STS_IOERR`) if the submitting process receives a signal.
- [High] Acquiring `reconfig_mutex` in the block I/O submission path (`raid1_make_request`) introduces a classic memory reclaim deadlock between in-flight IOs, `kswapd`, and array management.
Pre-existing issues:
- [Critical] The patch leaves the READ path completely unprotected against the concurrent `do_md_stop` Use-After-Free race that it was intended to fix for writes.
--
commit d721c8b809d2e452fb1806262577569049151fb3
Author: Edward Adam Davis <eadavis@sina.com>
md/raid1: prevent a race between write and stop request
The commit aims to resolve a use-after-free triggered by a race condition
between write requests and array stop requests. It does this by taking the
array's reconfig_mutex inside the write I/O submission path.
Closes: https://syzkaller.appspot.com/bug?extid=3fe892ea5fc292e1353f
> diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
> index f0646fb24371f..3b9f1fa65e654 100644
> --- a/drivers/md/raid1.c
> +++ b/drivers/md/raid1.c
> @@ -1692,11 +1693,36 @@ static bool raid1_make_request(struct mddev *mddev, struct bio *bio)
> if (bio_data_dir(bio) == READ)
> raid1_read_request(mddev, bio, sectors, NULL);
[Severity: Critical]
This is a pre-existing issue, but does this bypass leave the read path
completely unprotected against the exact same race condition?
If an array stop operation clears mddev->private concurrently, wouldn't
raid1_read_request() still dereference a freed or NULL conf pointer at:
wait_read_barrier(conf, bio->bi_iter.bi_sector);
> else {
> + int err;
> +
> md_write_start(mddev, bio);
> - if (!raid1_write_request(mddev, bio, sectors))
> + err = mddev_lock(mddev);
[Severity: High]
Does acquiring a global configuration mutex (reconfig_mutex) in the I/O
fast path forcibly serialize all concurrent RAID1 writes and severely degrade
block I/O performance?
Will taking a sleeping lock here also violate non-blocking semantics for
asynchronous I/O if REQ_NOWAIT is set?
[Severity: High]
Can acquiring reconfig_mutex in the block I/O submission path introduce a
memory reclaim deadlock?
If memory pressure forces kswapd to write out dirty pages to the RAID1 array,
will those memory-reclaim writes attempt to acquire reconfig_mutex in
raid1_make_request()?
Since configuration pathways like do_md_stop() hold reconfig_mutex while
waiting for in-flight IOs to drain or performing memory allocations, wouldn't
this create an ABBA deadlock that hangs the I/O subsystem?
> +
> + if (err < 0) {
> + md_write_end(mddev);
> + status = BLK_STS_IOERR;
[Severity: High]
Does this incorrectly convert a signal interruption into a hard I/O error?
Since mddev_lock() uses mutex_lock_interruptible() to acquire the lock, it
returns -EINTR if the submitting process receives a signal.
Will converting this directly to BLK_STS_IOERR cause spurious block I/O
errors for user space applications and potentially abort filesystem journals?
> + goto done;
> + }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260828104944.246837-1-eadavis@sina.com?part=1
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] md/raid1: prevent a race between write and stop request
2026-08-28 10:39 ` [PATCH] md/raid1: prevent a race between write and stop request Edward Adam Davis
2026-08-28 10:49 ` [PATCH v2] " Edward Adam Davis
@ 2026-08-28 10:55 ` sashiko-bot
2026-08-28 14:27 ` Abd-Alrhman Masalkhi
2 siblings, 0 replies; 5+ messages in thread
From: sashiko-bot @ 2026-08-28 10:55 UTC (permalink / raw)
To: Edward Adam Davis; +Cc: linux-raid, yukuai
Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
New issues:
- [Critical] Using an interruptible mutex in the I/O path causes normal user-space signals to spuriously fail legitimate writes with I/O errors.
- [High] Global lock acquisition in the high-frequency block I/O fast path completely serializes all RAID1 write requests.
- [High] Acquiring `reconfig_mutex` in the block I/O submission path causes a fatal lock-inversion deadlock during memory reclaim.
- [High] Holding `reconfig_mutex` while sleeping in `wait_blocked_rdev()` indefinitely blocks the MD management thread from clearing the blocked state.
Pre-existing issues:
- [High] The patch only protects WRITE requests, leaving the READ path entirely unpatched and vulnerable to the original race condition causing a NULL pointer dereference.
--
commit 75f3c8447cce610e8b9e2c583ca2b414877078df
Author: Edward Adam Davis <eadavis@sina.com>
md/raid1: prevent a race between write and stop request
This commit attempts to fix a race condition between write and stop requests
that leads to a null pointer dereference. It introduces synchronization in
the write path using the mddev lock to ensure the consistent state of mddev
members during a write request.
Closes: https://syzkaller.appspot.com/bug?extid=3fe892ea5fc292e1353f
> diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
> index f0646fb24371f..3b9f1fa65e654 100644
> --- a/drivers/md/raid1.c
> +++ b/drivers/md/raid1.c
> @@ -1692,11 +1693,36 @@ static bool raid1_make_request(struct mddev *mddev, struct bio *bio)
> if (bio_data_dir(bio) == READ)
> raid1_read_request(mddev, bio, sectors, NULL);
[Severity: High]
This is a pre-existing issue, but it appears the read path is still
unprotected and vulnerable to the same race condition.
Since the patch only wraps the write path, if a concurrent do_md_stop() runs
while a READ request is processed, raid1_read_request() will fetch
mddev->private without protection. Could this result in the exact same null
pointer dereference crash on reads when wait_read_barrier() is called?
> else {
> + int err;
> +
> md_write_start(mddev, bio);
> - if (!raid1_write_request(mddev, bio, sectors))
> + err = mddev_lock(mddev);
[Severity: High]
By acquiring mddev_lock() (which takes the global reconfig_mutex) in the
hot I/O submission path, are all RAID1 write requests completely serialized?
Taking a global reconfiguration mutex on every single write request could
degrade array scalability and I/O concurrency.
[Severity: High]
Could acquiring reconfig_mutex in the block I/O submission path also cause
a lock-inversion deadlock during memory reclaim?
If a thread holds reconfig_mutex (for example, during md_import_device())
and performs a GFP_KERNEL allocation, direct reclaim could write dirty pages
to the RAID array. Since raid1_make_request() attempts to acquire
reconfig_mutex via mddev_lock(), this might cause a direct self-deadlock.
> +
> + if (err < 0) {
> + md_write_end(mddev);
> + status = BLK_STS_IOERR;
> + goto done;
> + }
[Severity: Critical]
By translating a failed interruptible mutex lock into BLK_STS_IOERR, could
normal user-space signals spuriously fail legitimate writes?
mddev_lock() uses mutex_lock_interruptible(), which returns -EINTR if a
signal is pending. If a userspace process performing I/O receives a benign
signal (like SIGALRM) while submitting a write, this path seems to fail the
write with an I/O error instead of transparently retrying or blocking.
> +
> + if (!mddev->private) {
> + mddev_unlock(mddev);
> + md_write_end(mddev);
> + status = BLK_STS_OFFLINE;
> + goto done;
> + }
> +
> + err = raid1_write_request(mddev, bio, sectors);
> + mddev_unlock(mddev);
[Severity: High]
Since reconfig_mutex is held across the entirety of raid1_write_request(),
could this block the MD management thread indefinitely?
If a write request encounters a blocked device and sleeps in
wait_blocked_rdev() inside raid1_write_request(), the I/O thread will be
holding reconfig_mutex. The MD management thread (md_check_recovery()) needs
to clear the blocked state, but it uses mddev_trylock() to acquire
reconfig_mutex. Since the I/O thread holds the lock, the management thread
will fail to acquire it, potentially leaving the I/O thread blocked forever.
> +
> + if (!err)
> md_write_end(mddev);
> }
> +out:
> return true;
> +done:
> + bio->bi_status = status;
> + bio_endio(bio);
> + goto out;
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260828103957.245658-1-eadavis@sina.com?part=1
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [PATCH] md/raid1: prevent a race between write and stop request
2026-08-28 10:39 ` [PATCH] md/raid1: prevent a race between write and stop request Edward Adam Davis
2026-08-28 10:49 ` [PATCH v2] " Edward Adam Davis
2026-08-28 10:55 ` [PATCH] " sashiko-bot
@ 2026-08-28 14:27 ` Abd-Alrhman Masalkhi
2 siblings, 0 replies; 5+ messages in thread
From: Abd-Alrhman Masalkhi @ 2026-08-28 14:27 UTC (permalink / raw)
To: Edward Adam Davis, syzbot+3fe892ea5fc292e1353f
Cc: song, yukuai, magiclinan, xiao, linux-raid, linux-kernel,
syzkaller-bugs
Hi Edward,
On Fri, Aug 28, 2026 at 18:39 +0800, Edward Adam Davis wrote:
> A race condition exists between write and stop requests, leading to a
> null-ptr-deref in [1].
>
> CPU0 CPU1
> ==== ====
> md_submit_bio()
> md_handle_request() do_md_stop()__md_stop()
do_md_stop() must never execute while the array device file is open.
take a look if this rule is not meet.
> raid1_make_request() __md_stop()
> raid1_write_request() mddev->private = NULL
> wait_barrier()
> conf->nr_pending //trigger [1]
>
> The intervention of a stop request causes inconsistencies in the state
> of mddev members (such as private and pers) while a write request is
> executing; the mddev lock is used to synchronize write and stop requests,
> thereby ensuring consistent mddev state throughout the execution of the
> write request.
>
> Additionally, when a write operation reaches the RAID1 layer, if a stop
> request acquires the mddev lock first and releases mddev->private, the
> bio is terminated and the write request exits.
>
> [1]
> KASAN: null-ptr-deref in range [0x0000000000000120-0x0000000000000127]
> RIP: 0010:_wait_barrier+0x8d/0x700 drivers/md/raid1.c:1066
> Call Trace:
> wait_barrier drivers/md/raid1.c:1154 [inline]
> raid1_write_request drivers/md/raid1.c:1506 [inline]
> raid1_make_request+0x484/0x31a0 drivers/md/raid1.c:1696
> md_handle_request+0x824/0x1230 drivers/md/md.c:417
> md_submit_bio+0x1e9/0x350 drivers/md/md.c:458
> __submit_bio block/blk-core.c:681 [inline]
> __submit_bio+0x20e/0x3d0 block/blk-core.c:670
> __submit_bio_noacct block/blk-core.c:724 [inline]
> submit_bio_noacct_nocheck+0x736/0xc00 block/blk-core.c:792
> submit_bio_noacct+0xc93/0x2130 block/blk-core.c:925
> bio_await+0x1fa/0x240 block/bio.c:1580
> submit_bio_wait+0x19/0x60 block/bio.c:1598
> __blkdev_direct_IO_simple+0x4cb/0x8c0 block/fops.c:98
> blkdev_direct_IO+0xbee/0x2030 block/fops.c:429
> blkdev_direct_write block/fops.c:699 [inline]
> blkdev_write_iter+0x703/0xd30 block/fops.c:767
> new_sync_write fs/read_write.c:595 [inline]
> vfs_write+0x6af/0x1050 fs/read_write.c:687
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Reported-by: syzbot+3fe892ea5fc292e1353f@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=3fe892ea5fc292e1353f
> Tested-by: syzbot+3fe892ea5fc292e1353f@syzkaller.appspotmail.com
> Signed-off-by: Edward Adam Davis <eadavis@sina.com>
> ---
> drivers/md/raid1.c | 28 +++++++++++++++++++++++++++-
> 1 file changed, 27 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
> index f0646fb24371..3b9f1fa65e65 100644
> --- a/drivers/md/raid1.c
> +++ b/drivers/md/raid1.c
> @@ -1674,6 +1674,7 @@ static bool raid1_write_request(struct mddev *mddev, struct bio *bio,
> static bool raid1_make_request(struct mddev *mddev, struct bio *bio)
> {
> sector_t sectors;
> + blk_status_t status;
>
> if (unlikely(bio->bi_opf & REQ_PREFLUSH)
> && md_flush_request(mddev, bio))
> @@ -1692,11 +1693,36 @@ static bool raid1_make_request(struct mddev *mddev, struct bio *bio)
> if (bio_data_dir(bio) == READ)
> raid1_read_request(mddev, bio, sectors, NULL);
> else {
> + int err;
> +
> md_write_start(mddev, bio);
> - if (!raid1_write_request(mddev, bio, sectors))
> + err = mddev_lock(mddev);
> +
> + if (err < 0) {
> + md_write_end(mddev);
> + status = BLK_STS_IOERR;
> + goto done;
> + }
> +
> + if (!mddev->private) {
> + mddev_unlock(mddev);
> + md_write_end(mddev);
> + status = BLK_STS_OFFLINE;
> + goto done;
> + }
> +
> + err = raid1_write_request(mddev, bio, sectors);
> + mddev_unlock(mddev);
> +
> + if (!err)
> md_write_end(mddev);
> }
> +out:
> return true;
> +done:
> + bio->bi_status = status;
> + bio_endio(bio);
> + goto out;
> }
>
> static void raid1_status(struct seq_file *seq, struct mddev *mddev)
> --
> 2.43.0
>
>
--
Best Regards,
Abd-Alrhman
^ permalink raw reply [flat|nested] 5+ messages in thread