All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.