| 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
| ||
|
Message-ID: <CAMuHMdWRCGYLRK_WBmbB0cRP7PHiGPSi3U1jdWSVKaTSweruUw@mail.gmail.com>
Date: Thu, 6 Nov 2025 17:54:31 +0100
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@...esas.com>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Jiri Slaby <jirislaby@...nel.org>,
Claudiu Beznea <claudiu.beznea.uj@...renesas.com>,
Thierry Bultel <thierry.bultel.yh@...renesas.com>,
Wolfram Sang <wsa+renesas@...g-engineering.com>, Nam Cao <namcao@...utronix.de>,
Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>, linux-kernel@...r.kernel.org,
linux-serial@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH] tty: serial: sh-sci: fix RSCI FIFO overrun handling
Hi Cosmin,
On Tue, 23 Sept 2025 at 17:47, Cosmin Tanislav
<cosmin-gabriel.tanislav.xa@...esas.com> wrote:
> The receive error handling code is shared between RSCI and all other
> SCIF port types, but the RSCI overrun_reg is specified as a memory
> offset, while for other SCIF types it is an enum value used to index
> into the sci_port_params->regs array, as mentioned above the
> sci_serial_in() function.
>
> For RSCI, the overrun_reg is CSR (0x48), causing the sci_getreg() call
> inside the sci_handle_fifo_overrun() function to index outside the
> bounds of the regs array, which currently has a size of 20, as specified
> by SCI_NR_REGS.
>
> Because of this, we end up accessing memory outside of RSCI's
> rsci_port_params structure, which, when interpreted as a plat_sci_reg,
> happens to have a non-zero size, causing the following WARN when
> sci_serial_in() is called, as the accidental size does not match the
> supported register sizes.
>
> The existence of the overrun_reg needs to be checked because
> SCIx_SH3_SCIF_REGTYPE has overrun_reg set to SCLSR, but SCLSR is not
> present in the regs array.
>
> Avoid calling sci_getreg() for port types which don't use standard
> register handling.
>
> Use the ops->read_reg() and ops->write_reg() functions to properly read
> and write registers for RSCI, and change the type of the status variable
> to accommodate the 32-bit CSR register.
>
> sci_getreg() and sci_serial_in() are also called with overrun_reg in the
> sci_mpxed_interrupt() interrupt handler, but that code path is not used
> for RSCI, as it does not have a muxed interrupt.
>
> ------------[ cut here ]------------
> Invalid register access
> WARNING: CPU: 0 PID: 0 at drivers/tty/serial/sh-sci.c:522 sci_serial_in+0x38/0xac
> Modules linked in: renesas_usbhs at24 rzt2h_adc industrialio_adc sha256 cfg80211 bluetooth ecdh_generic ecc rfkill fuse drm backlight ipv6
> CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.17.0-rc1+ #30 PREEMPT
> Hardware name: Renesas RZ/T2H EVK Board based on r9a09g077m44 (DT)
> pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> pc : sci_serial_in+0x38/0xac
> lr : sci_serial_in+0x38/0xac
> sp : ffff800080003e80
> x29: ffff800080003e80 x28: ffff800082195b80 x27: 000000000000000d
> x26: ffff8000821956d0 x25: 0000000000000000 x24: ffff800082195b80
> x23: ffff000180e0d800 x22: 0000000000000010 x21: 0000000000000000
> x20: 0000000000000010 x19: ffff000180e72000 x18: 000000000000000a
> x17: ffff8002bcee7000 x16: ffff800080000000 x15: 0720072007200720
> x14: 0720072007200720 x13: 0720072007200720 x12: 0720072007200720
> x11: 0000000000000058 x10: 0000000000000018 x9 : ffff8000821a6a48
> x8 : 0000000000057fa8 x7 : 0000000000000406 x6 : ffff8000821fea48
> x5 : ffff00033ef88408 x4 : ffff8002bcee7000 x3 : ffff800082195b80
> x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff800082195b80
> Call trace:
> sci_serial_in+0x38/0xac (P)
> sci_handle_fifo_overrun.isra.0+0x70/0x134
> sci_er_interrupt+0x50/0x39c
> __handle_irq_event_percpu+0x48/0x140
> handle_irq_event+0x44/0xb0
> handle_fasteoi_irq+0xf4/0x1a0
> handle_irq_desc+0x34/0x58
> generic_handle_domain_irq+0x1c/0x28
> gic_handle_irq+0x4c/0x140
> call_on_irq_stack+0x30/0x48
> do_interrupt_handler+0x80/0x84
> el1_interrupt+0x34/0x68
> el1h_64_irq_handler+0x18/0x24
> el1h_64_irq+0x6c/0x70
> default_idle_call+0x28/0x58 (P)
> do_idle+0x1f8/0x250
> cpu_startup_entry+0x34/0x3c
> rest_init+0xd8/0xe0
> console_on_rootfs+0x0/0x6c
> __primary_switched+0x88/0x90
> ---[ end trace 0000000000000000 ]---
>
> Cc: stable@...r.kernel.org
> Fixes: 0666e3fe95ab ("serial: sh-sci: Add support for RZ/T2H SCI")
> Signed-off-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@...esas.com>
Thanks for your patch, which is now commit ef8fef45c74b5a00 ("tty:
serial: sh-sci: fix RSCI FIFO overrun handling") in v6.18-rc3.
> --- a/drivers/tty/serial/sh-sci.c
> +++ b/drivers/tty/serial/sh-sci.c
> @@ -1014,16 +1014,18 @@ static int sci_handle_fifo_overrun(struct uart_port *port)
> struct sci_port *s = to_sci_port(port);
> const struct plat_sci_reg *reg;
> int copied = 0;
> - u16 status;
> + u32 status;
>
> - reg = sci_getreg(port, s->params->overrun_reg);
> - if (!reg->size)
> - return 0;
> + if (s->type != SCI_PORT_RSCI) {
> + reg = sci_getreg(port, s->params->overrun_reg);
> + if (!reg->size)
> + return 0;
> + }
>
> - status = sci_serial_in(port, s->params->overrun_reg);
> + status = s->ops->read_reg(port, s->params->overrun_reg);
> if (status & s->params->overrun_mask) {
> status &= ~s->params->overrun_mask;
> - sci_serial_out(port, s->params->overrun_reg, status);
> + s->ops->write_reg(port, s->params->overrun_reg, status);
>
> port->icount.overrun++;
>
Ouch, this is really becoming fragile, and thus hard to maintain.
See also "[PATCH v2 2/2] serial: sh-sci: Fix deadlock during RSCI FIFO
overrun error".
Are you sure this is the only place where that can happen?
sci_getreg() and sci_serial_{in,out}() are used all over the place.
[1] https://lore.kernel.org/20251029082101.92156-3-biju.das.jz@bp.renesas.com/
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Powered by blists - more mailing lists