Recent commits break loop device unmounting

Recent commits break loop device unmounting

[nokangaroo]

	commit 08e136ebd193eae7d5eff4c66d576c4a2dabdc3f
	Author: Raphael Pinsonneault-Thibeault <rpthibeault@gmail.com>
	Date:   Wed Dec 17 14:00:40 2025 -0500

	loop: don't change loop device under exclusive opener in loop_set_status

	loop_set_status() is allowed to change the loop device while there
	are other openers of the device, even exclusive ones.

	In this case, it causes a KASAN: slab-out-of-bounds Read in
	ext4_search_dir(), since when looking for an entry in an inlined
	directory, e_value_offs is changed underneath the filesystem by
	loop_set_status().

	Fix the problem by forbidding loop_set_status() from modifying the loop
	device while there are exclusive openers of the device. This is similar
	to the fix in loop_configure() by commit 33ec3e53e7b1 ("loop: Don't
	change loop device under exclusive opener") alongside commit
	ecbe6bc0003b ("block: use bd_prepare_to_claim directly in the loop
	driver").

and the follow-up
	commit 2704024d83fa9eb8e5f16925aae340fd9d246694
	Author: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
	Date:   Wed Jan 7 19:41:43 2026 +0900

	loop: add missing bd_abort_claiming in loop_set_status

break unmounting a loop device by a normal user
(udisksctl unmount -b /dev/loop0).
The device seems to be unmounted, but the path still appears in the file
manager, and if the device is on an external harddisk I cannot unmount the
disk.

Bisecting: 0 revisions left to test after this (roughly 0 steps)
[08e136ebd193eae7d5eff4c66d576c4a2dabdc3f] loop: don't change loop device under
exclusive opener in loop_set_status

As a workaround I reverted this commit (and the follow-up before it).

  git revert -n 2704024d83fa9eb8e5f16925aae340fd9d246694
  git revert -n 08e136ebd193eae7d5eff4c66d576c4a2dabdc3f

If they solve an actual problem it needs to be fixed differently.
Commits 33ec3e53e7b1 and ecbe6bc0003b seem to be correct.

I will supply more information if needed

Re: Recent commits break loop device unmounting

[Thorsten Leemhuis]

Lo! Top-posting to facilitate processing. And Ccing a few people and lists.

Thx for the report. Does the problem still happen with latest mainline
(e.g. 6.19-rc7 or later)? Asking, as a fix for the culprit went into -rc5

Ciao, Thorsten

On 1/29/26 13:14, nokangaroo wrote:
> 	commit 08e136ebd193eae7d5eff4c66d576c4a2dabdc3f
> 	Author: Raphael Pinsonneault-Thibeault <rpthibeault@gmail.com>
> 	Date:   Wed Dec 17 14:00:40 2025 -0500
> 
> 	loop: don't change loop device under exclusive opener in loop_set_status
> 
> 	loop_set_status() is allowed to change the loop device while there
> 	are other openers of the device, even exclusive ones.
> 
> 	In this case, it causes a KASAN: slab-out-of-bounds Read in
> 	ext4_search_dir(), since when looking for an entry in an inlined
> 	directory, e_value_offs is changed underneath the filesystem by
> 	loop_set_status().
> 
> 	Fix the problem by forbidding loop_set_status() from modifying the loop
> 	device while there are exclusive openers of the device. This is similar
> 	to the fix in loop_configure() by commit 33ec3e53e7b1 ("loop: Don't
> 	change loop device under exclusive opener") alongside commit
> 	ecbe6bc0003b ("block: use bd_prepare_to_claim directly in the loop
> 	driver").
> 
> and the follow-up
> 	commit 2704024d83fa9eb8e5f16925aae340fd9d246694
> 	Author: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> 	Date:   Wed Jan 7 19:41:43 2026 +0900
> 
> 	loop: add missing bd_abort_claiming in loop_set_status
> 
> break unmounting a loop device by a normal user
> (udisksctl unmount -b /dev/loop0).
> The device seems to be unmounted, but the path still appears in the file
> manager, and if the device is on an external harddisk I cannot unmount the
> disk.
> 
> Bisecting: 0 revisions left to test after this (roughly 0 steps)
> [08e136ebd193eae7d5eff4c66d576c4a2dabdc3f] loop: don't change loop device under
> exclusive opener in loop_set_status
> 
> As a workaround I reverted this commit (and the follow-up before it).
> 
>   git revert -n 2704024d83fa9eb8e5f16925aae340fd9d246694
>   git revert -n 08e136ebd193eae7d5eff4c66d576c4a2dabdc3f
> 
> If they solve an actual problem it needs to be fixed differently.
> Commits 33ec3e53e7b1 and ecbe6bc0003b seem to be correct.
> 
> I will supply more information if needed

Re: Recent commits break loop device unmounting

[nokangaroo]

[-- Attachment #1: Type: text/plain, Size: 694 bytes --]

Still broken. The disk image in question has a UDF filesystem (DVD image)

uname -r:
6.19.0-rc8-2-mainline-00045-gf14faaf3a1fb-dirty

The fix is still the same:

  git revert -n 2704024d83fa9eb8e5f16925aae340fd9d246694
  git revert -n 08e136ebd193eae7d5eff4c66d576c4a2dabdc3f

I attach a script to create a sample DVD image for reproducing the error.

> On Sun, 1 Feb 2026 11:19:09 +0100
> Thorsten Leemhuis <regressions@leemhuis.info> wrote:

> Lo! Top-posting to facilitate processing. And Ccing a few people and lists.
> 
> Thx for the report. Does the problem still happen with latest mainline
> (e.g. 6.19-rc7 or later)? Asking, as a fix for the culprit went into -rc5
> 
> Ciao, Thorsten

[-- Attachment #2: create-dvd-sample.sh --]
[-- Type: application/x-shellscript, Size: 1233 bytes --]

Re: Recent commits break loop device unmounting

[Jens Axboe]

On 2/5/26 9:16 AM, nokangaroo wrote:
> Still broken. The disk image in question has a UDF filesystem (DVD image)
> 
> uname -r:
> 6.19.0-rc8-2-mainline-00045-gf14faaf3a1fb-dirty
> 
> The fix is still the same:
> 
>   git revert -n 2704024d83fa9eb8e5f16925aae340fd9d246694
>   git revert -n 08e136ebd193eae7d5eff4c66d576c4a2dabdc3f
> 
> I attach a script to create a sample DVD image for reproducing the error.

I'll go ahead and revert these for the 6.19 release.

-- 
Jens Axboe