mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Vineet Gupta <vgupta@kernel.org>
To: "Jérémy Jean" <Jeremy.Jean@oss.cyber.gouv.fr>,
	"Vineet Gupta" <vgupta@kernel.org>
Cc: linux-snps-arc@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ARC: check user addresses in unaligned access emulation
Date: Mon, 24 Aug 2026 20:00:29 -0700	[thread overview]
Message-ID: <0b3af924-6e87-484c-be0e-11279e28d77b@kernel.org> (raw)
In-Reply-To: <20260824203740.3689400-2-Jeremy.Jean@oss.cyber.gouv.fr>

On 8/24/26 13:37, Jérémy Jean wrote:
> ARC700 raises an alignment exception before checking access permissions.
> Consequently, a userspace load or store using a misaligned kernel address
> reaches misaligned_fixup() before the processor rejects it.

How do you know this for sure. Did you run into this issue yourself and 
were able to prove this ordering.

And even if you found some documentation can you confirm this to be 
happening on real ARC700 hardware.
I've been maintaining ARC forever and even do I don't have access to 
working ARC700 silicon.

I can sympathize with your need to send a fix and it might actually be 
correct.
But I can't take a fix that theoretically fixes something w/o 
demonstrating what real life case it caters so.

So Nack, unless you have one of the valid reasons above.

-Vineet

> misaligned_fixup() decodes the instruction and repeats the access using
> byte loads or stores. These accesses run in kernel mode, and exception
> tables only handle accesses that fault. A mapped kernel address is
> therefore read or written with supervisor permissions.
>
> Use access_ok() to reject addresses outside the user range before calling
> the helpers. Check the whole 2- or 4-byte range and use the checked address
> for the emulated operation.
>
> Fixes: 2e651ea1596b ("ARC: Unaligned access emulation")
> Assisted-by: Codex:gpt-daybreak-blue
> Signed-off-by: Jérémy Jean <Jeremy.Jean@oss.cyber.gouv.fr>
> ---
>   arch/arc/kernel/unaligned.c | 23 +++++++++++++++++++----
>   1 file changed, 19 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arc/kernel/unaligned.c b/arch/arc/kernel/unaligned.c
> index 3b2d8b1bd271..f6079dc89a6d 100644
> --- a/arch/arc/kernel/unaligned.c
> +++ b/arch/arc/kernel/unaligned.c
> @@ -133,6 +133,8 @@ int no_unaligned_warning __read_mostly = 1;	/* Only 1 warning by default */
>   static void fixup_load(struct disasm_state *state, struct pt_regs *regs,
>   			struct callee_regs *cregs)
>   {
> +	unsigned long address;
> +	unsigned int size;
>   	int val;
>   
>   	/* register write back */
> @@ -143,10 +145,15 @@ static void fixup_load(struct disasm_state *state, struct pt_regs *regs,
>   			state->src2 = 0;
>   	}
>   
> +	address = state->src1 + state->src2;
> +	size = state->zz ? 2 : 4;
> +	if (!access_ok((void __user *)address, size))
> +		goto fault;
> +
>   	if (state->zz == 0) {
> -		get32_unaligned_check(val, state->src1 + state->src2);
> +		get32_unaligned_check(val, address);
>   	} else {
> -		get16_unaligned_check(val, state->src1 + state->src2);
> +		get16_unaligned_check(val, address);
>   
>   		if (state->x)
>   			val = (val << 16) >> 16;
> @@ -163,6 +170,9 @@ fault:	state->fault = 1;
>   static void fixup_store(struct disasm_state *state, struct pt_regs *regs,
>   			struct callee_regs *cregs)
>   {
> +	unsigned long address;
> +	unsigned int size;
> +
>   	/* register write back */
>   	if ((state->aa == 1) || (state->aa == 2)) {
>   		set_reg(state->wb_reg, state->src2 + state->src3, regs, cregs);
> @@ -181,11 +191,16 @@ static void fixup_store(struct disasm_state *state, struct pt_regs *regs,
>   		}
>   	}
>   
> +	address = state->src2 + state->src3;
> +	size = state->zz ? 2 : 4;
> +	if (!access_ok((void __user *)address, size))
> +		goto fault;
> +
>   	/* write fix-up */
>   	if (!state->zz)
> -		put32_unaligned_check(state->src1, state->src2 + state->src3);
> +		put32_unaligned_check(state->src1, address);
>   	else
> -		put16_unaligned_check(state->src1, state->src2 + state->src3);
> +		put16_unaligned_check(state->src1, address);
>   
>   	return;
>   


  reply	other threads:[~2026-08-25  3:00 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-24 20:37 Jérémy Jean
2026-08-25  3:00 ` Vineet Gupta [this message]
2026-08-25 12:04   ` Jérémy Jean

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=0b3af924-6e87-484c-be0e-11279e28d77b@kernel.org \
    --to=vgupta@kernel.org \
    --cc=Jeremy.Jean@oss.cyber.gouv.fr \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-snps-arc@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®