[PATCH] md/raid1: prevent a race between write and stop request

[PATCH] md/raid1: prevent a race between write and stop request

[Edward Adam Davis]

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()
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

[PATCH v2] md/raid1: prevent a race between write and stop request

[Edward Adam Davis]

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

Re: [PATCH] md/raid1: prevent a race between write and stop request

[sashiko-bot]

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

Re: [PATCH v2] md/raid1: prevent a race between write and stop request

[sashiko-bot]

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

Re: [PATCH] md/raid1: prevent a race between write and stop request

[Abd-Alrhman Masalkhi]

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