[PATCH] bcache: fix uninitialized closure object

[PATCH] bcache: fix uninitialized closure object

[mingzhe.zou]

From: Mingzhe Zou <zoumingzhe@qq.com>

In the previous patch(bcache: fix cached_dev.sb_bio use-after-free and crash),
we adopted a simple modification suggestion from AI to fix the use-after-free.

But in actual testing, we found an extreme case where the device is stopped
before calling bch_write_bdev_super().

At this point, struct closure sb_write has not been initialized yet.

For this patch, we ensure that sb_bio has been completed via sb_write_mutex.

Signed-off-by: Mingzhe Zou <mingzhe.zou@easystack.cn>
---
 drivers/md/bcache/super.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/md/bcache/super.c b/drivers/md/bcache/super.c
index 6627a381f65a..97d9adb0bf96 100644
--- a/drivers/md/bcache/super.c
+++ b/drivers/md/bcache/super.c
@@ -1378,7 +1378,8 @@ static CLOSURE_CALLBACK(cached_dev_free)
 	 * The sb_bio is embedded in struct cached_dev, so we must
 	 * ensure no I/O is in progress.
 	 */
-	closure_sync(&dc->sb_write);
+	down(&dc->sb_write_mutex);
+	up(&dc->sb_write_mutex);
 
 	if (dc->sb_disk)
 		folio_put(virt_to_folio(dc->sb_disk));
-- 
2.34.1

Re: [PATCH] bcache: fix uninitialized closure object

[Coly Li]

On Thu, Apr 02, 2026 at 09:03:53PM +0800, mingzhe.zou@easystack.cn wrote:
> From: Mingzhe Zou <zoumingzhe@qq.com>
> 
> In the previous patch(bcache: fix cached_dev.sb_bio use-after-free and crash),
> we adopted a simple modification suggestion from AI to fix the use-after-free.
> 
> But in actual testing, we found an extreme case where the device is stopped
> before calling bch_write_bdev_super().
> 
> At this point, struct closure sb_write has not been initialized yet.
> 
> For this patch, we ensure that sb_bio has been completed via sb_write_mutex.
> 
> Signed-off-by: Mingzhe Zou <mingzhe.zou@easystack.cn>

It looks good to me. I will refine the commit log and submit.

Thanks.

Coly Li

> ---
>  drivers/md/bcache/super.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/md/bcache/super.c b/drivers/md/bcache/super.c
> index 6627a381f65a..97d9adb0bf96 100644
> --- a/drivers/md/bcache/super.c
> +++ b/drivers/md/bcache/super.c
> @@ -1378,7 +1378,8 @@ static CLOSURE_CALLBACK(cached_dev_free)
>  	 * The sb_bio is embedded in struct cached_dev, so we must
>  	 * ensure no I/O is in progress.
>  	 */
> -	closure_sync(&dc->sb_write);
> +	down(&dc->sb_write_mutex);
> +	up(&dc->sb_write_mutex);
>  
>  	if (dc->sb_disk)
>  		folio_put(virt_to_folio(dc->sb_disk));
> -- 
> 2.34.1

[PATCH] bcache: fix uninitialized closure object

[colyli]

From: Mingzhe Zou <mingzhe.zou@easystack.cn>

In the previous patch ("bcache: fix cached_dev.sb_bio use-after-free and
crash"), we adopted a simple modification suggestion from AI to fix the
use-after-free.

But in actual testing, we found an extreme case where the device is
stopped before calling bch_write_bdev_super().

At this point, struct closure sb_write has not been initialized yet.
For this patch, we ensure that sb_bio has been completed via
sb_write_mutex.

(Coly Li refines the commit log.)

Signed-off-by: Mingzhe Zou <mingzhe.zou@easystack.cn>
Signed-off-by: Coly Li <colyli@fnnas.com>
---
 drivers/md/bcache/super.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/md/bcache/super.c b/drivers/md/bcache/super.c
index 5005a26af363..5380a44ef721 100644
--- a/drivers/md/bcache/super.c
+++ b/drivers/md/bcache/super.c
@@ -1378,7 +1378,8 @@ static CLOSURE_CALLBACK(cached_dev_free)
 	 * The sb_bio is embedded in struct cached_dev, so we must
 	 * ensure no I/O is in progress.
 	 */
-	closure_sync(&dc->sb_write);
+	down(&dc->sb_write_mutex);
+	up(&dc->sb_write_mutex);
 
 	if (dc->sb_disk)
 		folio_put(virt_to_folio(dc->sb_disk));
-- 
2.47.3

Re: [PATCH] bcache: fix uninitialized closure object

[Jens Axboe]

On 4/2/26 10:21 PM, colyli@fnnas.com wrote:
> From: Mingzhe Zou <mingzhe.zou@easystack.cn>
> 
> In the previous patch ("bcache: fix cached_dev.sb_bio use-after-free and
> crash"), we adopted a simple modification suggestion from AI to fix the
> use-after-free.
> 
> But in actual testing, we found an extreme case where the device is
> stopped before calling bch_write_bdev_super().
> 
> At this point, struct closure sb_write has not been initialized yet.
> For this patch, we ensure that sb_bio has been completed via
> sb_write_mutex.

Presumably this should have a:

Fixes: fec114a98b87 ("bcache: fix cached_dev.sb_bio use-after-free and crash")

but for some reason it does not. I'll add it.

-- 
Jens Axboe

Re: [PATCH] bcache: fix uninitialized closure object

[Jens Axboe]

On Fri, 03 Apr 2026 12:21:35 +0800, colyli@fnnas.com wrote:
> In the previous patch ("bcache: fix cached_dev.sb_bio use-after-free and
> crash"), we adopted a simple modification suggestion from AI to fix the
> use-after-free.
> 
> But in actual testing, we found an extreme case where the device is
> stopped before calling bch_write_bdev_super().
> 
> [...]

Applied, thanks!

[1/1] bcache: fix uninitialized closure object
      commit: 20a8e451ec1c7e99060b1bbaaad03ce88c39ddb8

Best regards,
-- 
Jens Axboe

Re: [PATCH] bcache: fix uninitialized closure object

[Coly Li]

> 2026年4月3日 19:11，Jens Axboe <axboe@kernel.dk> 写道：
> 
> On 4/2/26 10:21 PM, colyli@fnnas.com wrote:
>> From: Mingzhe Zou <mingzhe.zou@easystack.cn>
>> 
>> In the previous patch ("bcache: fix cached_dev.sb_bio use-after-free and
>> crash"), we adopted a simple modification suggestion from AI to fix the
>> use-after-free.
>> 
>> But in actual testing, we found an extreme case where the device is
>> stopped before calling bch_write_bdev_super().
>> 
>> At this point, struct closure sb_write has not been initialized yet.
>> For this patch, we ensure that sb_bio has been completed via
>> sb_write_mutex.
> 
> Presumably this should have a:
> 
> Fixes: fec114a98b87 ("bcache: fix cached_dev.sb_bio use-after-free and crash")
> 
> but for some reason it does not. I'll add it.

I did it on purpose. Because this patch is in Linux-stable and not in mainline,
I am not sure whether it is proper to reference the linux-block tree commit id.

This is why the patch title is mentioned in commit log, but commit id skipped.

Thanks for adding it.

Coly Li

Re: [PATCH] bcache: fix uninitialized closure object

[Jens Axboe]

On 4/7/26 3:28 AM, Coly Li wrote:
>> 2026?4?3? 19:11?Jens Axboe <axboe@kernel.dk> ???
>>
>> On 4/2/26 10:21 PM, colyli@fnnas.com wrote:
>>> From: Mingzhe Zou <mingzhe.zou@easystack.cn>
>>>
>>> In the previous patch ("bcache: fix cached_dev.sb_bio use-after-free and
>>> crash"), we adopted a simple modification suggestion from AI to fix the
>>> use-after-free.
>>>
>>> But in actual testing, we found an extreme case where the device is
>>> stopped before calling bch_write_bdev_super().
>>>
>>> At this point, struct closure sb_write has not been initialized yet.
>>> For this patch, we ensure that sb_bio has been completed via
>>> sb_write_mutex.
>>
>> Presumably this should have a:
>>
>> Fixes: fec114a98b87 ("bcache: fix cached_dev.sb_bio use-after-free and crash")
>>
>> but for some reason it does not. I'll add it.
> 
> I did it on purpose. Because this patch is in Linux-stable and not in mainline,
> I am not sure whether it is proper to reference the linux-block tree commit id.
> 
> This is why the patch title is mentioned in commit log, but commit id skipped.

Why is the patch in stable and not in mainline?! That should generally
never happen.

-- 
Jens Axboe

Re: [PATCH] bcache: fix uninitialized closure object

[Coly Li]

> 2026年4月7日 20:44，Jens Axboe <axboe@kernel.dk> 写道：
> 
> On 4/7/26 3:28 AM, Coly Li wrote:
>>> 2026?4?3? 19:11?Jens Axboe <axboe@kernel.dk> ???
>>> 
>>> On 4/2/26 10:21 PM, colyli@fnnas.com wrote:
>>>> From: Mingzhe Zou <mingzhe.zou@easystack.cn>
>>>> 
>>>> In the previous patch ("bcache: fix cached_dev.sb_bio use-after-free and
>>>> crash"), we adopted a simple modification suggestion from AI to fix the
>>>> use-after-free.
>>>> 
>>>> But in actual testing, we found an extreme case where the device is
>>>> stopped before calling bch_write_bdev_super().
>>>> 
>>>> At this point, struct closure sb_write has not been initialized yet.
>>>> For this patch, we ensure that sb_bio has been completed via
>>>> sb_write_mutex.
>>> 
>>> Presumably this should have a:
>>> 
>>> Fixes: fec114a98b87 ("bcache: fix cached_dev.sb_bio use-after-free and crash")
>>> 
>>> but for some reason it does not. I'll add it.
>> 
>> I did it on purpose. Because this patch is in Linux-stable and not in mainline,
>> I am not sure whether it is proper to reference the linux-block tree commit id.
>> 
>> This is why the patch title is mentioned in commit log, but commit id skipped.
> 
> Why is the patch in stable and not in mainline?! That should generally
> never happen.

Oops, My fingers movement diverged from my brain. I thought linux-block, but typed linux-stable….

I meant, when the patch merged from linux-block to Linus tree, maybe the commit id changes
for some unexpected reason. So I didn’t reference the Fixes tag with linux-block tree commit
id.

Coly Li

Re: [PATCH] bcache: fix uninitialized closure object

[Jens Axboe]

On 4/7/26 7:19 AM, Coly Li wrote:
>> 2026?4?7? 20:44?Jens Axboe <axboe@kernel.dk> ???
>>
>> On 4/7/26 3:28 AM, Coly Li wrote:
>>>> 2026?4?3? 19:11?Jens Axboe <axboe@kernel.dk> ???
>>>>
>>>> On 4/2/26 10:21 PM, colyli@fnnas.com wrote:
>>>>> From: Mingzhe Zou <mingzhe.zou@easystack.cn>
>>>>>
>>>>> In the previous patch ("bcache: fix cached_dev.sb_bio use-after-free and
>>>>> crash"), we adopted a simple modification suggestion from AI to fix the
>>>>> use-after-free.
>>>>>
>>>>> But in actual testing, we found an extreme case where the device is
>>>>> stopped before calling bch_write_bdev_super().
>>>>>
>>>>> At this point, struct closure sb_write has not been initialized yet.
>>>>> For this patch, we ensure that sb_bio has been completed via
>>>>> sb_write_mutex.
>>>>
>>>> Presumably this should have a:
>>>>
>>>> Fixes: fec114a98b87 ("bcache: fix cached_dev.sb_bio use-after-free and crash")
>>>>
>>>> but for some reason it does not. I'll add it.
>>>
>>> I did it on purpose. Because this patch is in Linux-stable and not in mainline,
>>> I am not sure whether it is proper to reference the linux-block tree commit id.
>>>
>>> This is why the patch title is mentioned in commit log, but commit id skipped.
>>
>> Why is the patch in stable and not in mainline?! That should generally
>> never happen.
> 
> Oops, My fingers movement diverged from my brain. I thought
> linux-block, but typed linux-stable?.
> 
> I meant, when the patch merged from linux-block to Linus tree, maybe
> the commit id changes for some unexpected reason. So I didn?t
> reference the Fixes tag with linux-block tree commit id.

It'll never change going into Linus's tree, that's how git works. If I
have a rare rebase for whatever reason, I fixup the Fixes shas. So
always put them in there, there's never a reason NOT to do so.

-- 
Jens Axboe

Re: [PATCH] bcache: fix uninitialized closure object

[Coly Li]

> 2026年4月7日 21:24，Jens Axboe <axboe@kernel.dk> 写道：
> 
> On 4/7/26 7:19 AM, Coly Li wrote:
>>> 2026?4?7? 20:44?Jens Axboe <axboe@kernel.dk> ???
>>> 
>>> On 4/7/26 3:28 AM, Coly Li wrote:
>>>>> 2026?4?3? 19:11?Jens Axboe <axboe@kernel.dk> ???
>>>>> 
>>>>> On 4/2/26 10:21 PM, colyli@fnnas.com wrote:
>>>>>> From: Mingzhe Zou <mingzhe.zou@easystack.cn>
>>>>>> 
>>>>>> In the previous patch ("bcache: fix cached_dev.sb_bio use-after-free and
>>>>>> crash"), we adopted a simple modification suggestion from AI to fix the
>>>>>> use-after-free.
>>>>>> 
>>>>>> But in actual testing, we found an extreme case where the device is
>>>>>> stopped before calling bch_write_bdev_super().
>>>>>> 
>>>>>> At this point, struct closure sb_write has not been initialized yet.
>>>>>> For this patch, we ensure that sb_bio has been completed via
>>>>>> sb_write_mutex.
>>>>> 
>>>>> Presumably this should have a:
>>>>> 
>>>>> Fixes: fec114a98b87 ("bcache: fix cached_dev.sb_bio use-after-free and crash")
>>>>> 
>>>>> but for some reason it does not. I'll add it.
>>>> 
>>>> I did it on purpose. Because this patch is in Linux-stable and not in mainline,
>>>> I am not sure whether it is proper to reference the linux-block tree commit id.
>>>> 
>>>> This is why the patch title is mentioned in commit log, but commit id skipped.
>>> 
>>> Why is the patch in stable and not in mainline?! That should generally
>>> never happen.
>> 
>> Oops, My fingers movement diverged from my brain. I thought
>> linux-block, but typed linux-stable?.
>> 
>> I meant, when the patch merged from linux-block to Linus tree, maybe
>> the commit id changes for some unexpected reason. So I didn?t
>> reference the Fixes tag with linux-block tree commit id.
> 
> It'll never change going into Linus's tree, that's how git works. If I
> have a rare rebase for whatever reason, I fixup the Fixes shas. So
> always put them in there, there's never a reason NOT to do so.

This is a clear hint. Thanks.

Coly Li