linux-kernel - Re: [PATCH] arm64: Don't call NULL in do_compat_alignment

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 for Android: free password hash cracker in your pocket

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

Message-Id: <D8UAHZY0DJ19.18319MPVM5SPC@igalia.com>
Date: Mon, 31 Mar 2025 09:57:17 +0200
From: "Angelos Oikonomopoulos" <angelos@...lia.com>
To: "Catalin Marinas" <catalin.marinas@....com>
Cc: <linux-arm-kernel@...ts.infradead.org>, <will@...nel.org>,
 <linux-kernel@...r.kernel.org>, <kernel-dev@...lia.com>
Subject: Re: [PATCH] arm64: Don't call NULL in do_compat_alignment_fixup

On Fri Mar 28, 2025 at 8:06 PM CET, Catalin Marinas wrote:
> On Wed, Mar 26, 2025 at 02:35:21PM +0100, Angelos Oikonomopoulos wrote:
>> do_alignment_t32_to_handler only fixes up alignment faults for specific
>> instructions; it returns NULL otherwise. When that's the case, signal to
>> the caller that it needs to proceed with the regular alignment fault
>> handling (i.e. SIGBUS).
>
> Did you hit this in practice? Which instruction triggered the alignment
> fault that was not handled by do_alignment_t32_to_handler()? Standard
> LDR/STR should not trigger unaligned accesses unless you have some
> device memory mapped in user space.

Yah, I've hit this in practice. The offending instruction was an ldrex
to an unaligned address, while running 32-bit code on an "Ampere(R)
Altra(R) Processor Q80-30 CPU @ 3.0GHz". Fixing the unaligned access in
the program is one thing, but this resulted in multiple oopses in CI.

>>  #define REGMASK_BITS(i)	(i & 0xffff)
>>  
>> -#define BAD_INSTR 	0xdeadc0de
>> +#define BAD_INSTR	0xdeadc0de
>
> Unrelated change (white space I guess), please drop it, not worth
> fixing.

That snuck past me in an amend, will send a v2.

Thanks,
Angelos