[RFC PATCH] vfs: Fix might sleep in load_unaligned_zeropad() with rcu read lock held
Xie Yuanbin
xieyuanbin1 at huawei.com
Wed Nov 26 19:03:16 PST 2025
On, Wed, 26 Nov 2025 19:26:40 +0000, Al Viro wrote:
> For quick and dirty variant (on current tree), how about
> adding
> if (unlikely(addr > TASK_SIZE) && !user_mode(regs))
> goto no_context;
>
> right after
>
> if (!ttbr0_usermode_access_allowed(regs))
> goto no_context;
>
> in do_page_fault() there?
On, Wed, 26 Nov 2025 23:31:00 +0000, Russell King (Oracle) wrote:
> Now, for 32-bit ARM, I think I am coming to the conclusion that Al's
> suggestion is probably the easiest solution. However, whether it has
> side effects, I couldn't say - the 32-bit ARM fault code has been
> modified by quite a few people in ways I don't yet understand, so I
> can't be certain at the moment whether it would cause problems.
I think I've already submitted a very similar patch, to fix another bug:
On Thu, 16 Oct 2025 20:16:21 +0800, Xie Yuanbin wrote:
> +#ifdef CONFIG_HARDEN_BRANCH_PREDICTOR
> + if (unlikely(addr > TASK_SIZE) && user_mode(regs)) {
> + fault = 0;
> + code = SEGV_MAPERR;
> + goto bad_area;
> + }
> +#endif
Link: https://lore.kernel.org/20250925025744.6807-1-xieyuanbin1@huawei.com
However, the patch seems to have received no response for a very long
time.
On Wed, 26 Nov 2025 23:31:00 +0000, Russell King wrote:
> I think the only thing to do is to try the solution and see what
> breaks. I'm not in a position to be able to do that as, having not
> had reason to touch 32-bit ARM for years, I don't have a hackable
> platform nearby. Maybe Xie Yuanbin can test it?
With pleasure.
By the way, for the config and test case shown in this patch:
vfs: Fix might sleep in load_unaligned_zeropad() with rcu read lock held
Link: https://lore.kernel.org/20251126101952.174467-1-xieyuanbin1@huawei.com
the warning can be reproduced directly on QEMU.
Xie Yuanbin
More information about the linux-arm-kernel
mailing list