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
next 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.