public inbox for linux-block@vger.kernel.org
 help / color / mirror / Atom feed
From: nokangaroo <nokangaroo@aon.at>
To: linux-block@vger.kernel.org
Subject: Recent commits break loop device unmounting
Date: Thu, 29 Jan 2026 13:14:41 +0100	[thread overview]
Message-ID: <20260129131441.7c574b58@golem> (raw)

	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

             reply	other threads:[~2026-01-29 12:33 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-29 12:14 nokangaroo [this message]
2026-02-01 10:19 ` Recent commits break loop device unmounting Thorsten Leemhuis
2026-02-05 16:16   ` nokangaroo
2026-02-05 16:26     ` Jens Axboe

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=20260129131441.7c574b58@golem \
    --to=nokangaroo@aon.at \
    --cc=linux-block@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox