linux-kernel - [RFC PATCH] vfs: Fix might sleep in load_unaligned

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20251127030316.8396-1-xieyuanbin1@huawei.com>
Date: Thu, 27 Nov 2025 11:03:16 +0800
From: Xie Yuanbin <xieyuanbin1@...wei.com>
To: <viro@...iv.linux.org.uk>, <linux@...linux.org.uk>, <will@...nel.org>,
	<david.laight@...box.com>, <rmk+kernel@...linux.org.uk>
CC: <brauner@...nel.org>, <jack@...e.cz>, <nico@...xnic.net>,
	<akpm@...ux-foundation.org>, <hch@....de>, <jack@...e.com>,
	<wozizhi@...weicloud.com>, <linux-fsdevel@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <linux-arm-kernel@...ts.infradead.org>,
	<linux-mm@...ck.org>, <catalin.marinas@....com>, <rppt@...nel.org>,
	<vbabka@...e.cz>, <pfalcato@...e.de>, <lorenzo.stoakes@...cle.com>,
	<kuninori.morimoto.gx@...esas.com>, <tony@...mide.com>, <arnd@...db.de>,
	<bigeasy@...utronix.de>, <punitagrawal@...il.com>, <rjw@...ysocki.net>,
	<marc.zyngier@....com>, <lilinjie8@...wei.com>, <liaohua4@...wei.com>,
	<wangkefeng.wang@...wei.com>, <pangliyuan1@...wei.com>, Xie Yuanbin
	<xieyuanbin1@...wei.com>
Subject: [RFC PATCH] vfs: Fix might sleep in load_unaligned_zeropad() with rcu read lock held

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