[<prev] [next>] [day] [month] [year] [list]
Message-ID: <62de4453-17e8-47f6-a10b-39bf5a49fdee@leemhuis.info>
Date: Sun, 1 Feb 2026 11:19:09 +0100
From: Thorsten Leemhuis <regressions@...mhuis.info>
To: nokangaroo <nokangaroo@....at>
Cc: linux-block@...r.kernel.org,
Linux kernel regressions list <regressions@...ts.linux.dev>,
Raphael Pinsonneault-Thibeault <rpthibeault@...il.com>,
Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
Jens Axboe <axboe@...nel.dk>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: Recent commits break loop device unmounting
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@...il.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@...ove.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
Powered by blists - more mailing lists