From: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
To: "Maciej W. Rozycki" <macro@orcam.me.uk>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jiri Slaby <jirislaby@kernel.org>,
linux-mips@vger.kernel.org, linux-serial@vger.kernel.org
Subject: Re: [PATCH v3 02/10] MIPS: DEC: Prevent initial console buffer from landing in XKPHYS
Date: Tue, 26 May 2026 16:46:12 +0200 [thread overview]
Message-ID: <ahWyNMag6EZNyykS@alpha.franken.de> (raw)
In-Reply-To: <alpine.DEB.2.21.2605062253010.46195@angie.orcam.me.uk>
On Wed, May 06, 2026 at 11:42:27PM +0100, Maciej W. Rozycki wrote:
> In 64-bit configurations calling the initial console output handler from
> a kernel thread other than the initial one will result in a situation
> where the stack has been placed in the XKPHYS 64-bit memory segment and
> consequently so has been the buffer allocated there that is used as the
> argument corresponding to the `%s' output conversion specifier for the
> firmware's printf() entry point.
>
> This 64-bit address will then be truncated by 32-bit firmware, resulting
> in an attempt to access the wrong memory location, which in turn will
> cause all kinds of unpredictable behaviour, such as a kernel crash:
>
> Console: colour dummy device 160x64
> Calibrating delay loop... 49.36 BogoMIPS (lpj=192512)
> pid_max: default: 32768 minimum: 301
> CPU 0 Unable to handle kernel paging request at virtual address 000000000203bd00, epc == ffffffffbfc08364, ra == ffffffffbfc08800
> Oops[#1]:
> CPU: 0 PID: 0 Comm: swapper Not tainted 5.18.0-rc2-00254-gfb649bda6f56-dirty #121
> $ 0 : 0000000000000000 0000000000000001 0000000000000023 ffffffff80684ba0
> $ 4 : 000000000203bd00 ffffffffbfc0f3b4 ffffffffffffffff 0000000000000073
> $ 8 : 0a303d7469000000 0000000000000000 0000000000000073 ffffffffbfc0f473
> $12 : 0000000000000002 0000000000000000 ffffffff80684c1c 0000000000000000
> $16 : 0000000000000000 ffffffff80596dc9 0000000000000000 ffffffffbfc09240
> $20 : ffffffff80684c40 ffffffffbfc0f400 000000000000002d 000000000000002b
> $24 : ffffffffffffffbf 000000000203bd00
> $28 : ffffffff805f0000 ffffffff80684b58 0000000000000030 ffffffffbfc08800
> Hi : 0000000000000000
> Lo : 0000000000000aa8
> epc : ffffffffbfc08364 0xffffffffbfc08364
> ra : ffffffffbfc08800 0xffffffffbfc08800
> Status: 140120e2 KX SX UX KERNEL EXL
> Cause : 00000008 (ExcCode 02)
> BadVA : 000000000203bd00
> PrId : 00000430 (R4000SC)
> Modules linked in:
> Process swapper (pid: 0, threadinfo=(____ptrval____), task=(____ptrval____), tls=0000000000000000)
> Stack : 0000000000000000 0000000000000000 0000000000000000 0000004d0000004d
> 80684cc0806a2a40 80596dc80000004d 8061000000000000 bfc0850c80684c38
> 0000000000000000 000000000203bd00 0000000000000000 0000000000000000
> 0000000000000000 00000000bfc0f3b4 0000000000000000 0000000000000000
> 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> 0000002500000000 0000000000000000 0000000000000000 802c1a7400000000
> 0203bd0080596dc8 0203bd4d69000000 6c61632000000018 5f746567646e6172
> 6c616320625f6d6f 5f736e5f6d6f7266 206361323778302b 303d74696e726320
> 806a0a38806b0000 806a0a38806b0000 00000000806b0000 80683c58806b0000
> ...
> Call Trace:
>
>
> Code: a082ffff 03e00008 00601021 <80820000> 00001821 10400005 24840001 80820000 24630001
>
> ---[ end trace 0000000000000000 ]---
> Kernel panic - not syncing: Fatal exception in interrupt
>
> KN04 V2.1k (PC: 0xa0026768, SP: 0x806848e8)
> >>
>
> In this case the pointer in $4 was truncated from 0x980000000203bd00 to
> 0x000000000203bd00.
>
> This may happen when no final console driver has been enabled in the
> configuration and consequently the initial console continues being used
> late into bootstrap or with an upcoming change that will switch the zs
> driver to use a platform device, which in turn will make the console
> handover happen only after other kernel threads have already been
> started.
>
> Fix the issue by making the buffer static and initdata, and therefore
> placed in the CKSEG0 32-bit compatibility segment, observing that the
> console output handler is called with the console lock held, implying
> no need for this code to be reentrant. Add an assertion to verify the
> buffer actually has been placed in a compatibility segment.
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
> Cc: stable@vger.kernel.org # v2.6.12+
> ---
> Changes from v2,
> <https://lore.kernel.org/r/alpine.DEB.2.21.2605010059310.38805@angie.orcam.me.uk/>:
>
> - Cast `buf' to `long' before casting to `int', fixing:
>
> In file included from ./include/linux/bug.h:5,
> from arch/mips/dec/prom/console.c:7:
> arch/mips/dec/prom/console.c: In function 'prom_console_write':
> arch/mips/dec/prom/console.c:21:29: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
> 21 | BUG_ON((long)buf != (int)buf);
> | ^
> ./arch/mips/include/asm/bug.h:34:44: note: in definition of macro 'BUG_ON'
> 34 | #define BUG_ON(C) __BUG_ON((unsigned long)(C))
> | ^
>
> New change in v2.
> ---
> arch/mips/dec/prom/console.c | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
applied to mips-next
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]
next prev parent reply other threads:[~2026-05-26 14:51 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-06 22:42 [PATCH v3 00/10] MIPS: DEC: Fix serial device regressions + RTC cleanup Maciej W. Rozycki
2026-05-06 22:42 ` [PATCH v3 01/10] MIPS: DEC: Ensure 32-bit stack location for o32 prom_printf() Maciej W. Rozycki
2026-05-26 14:45 ` Thomas Bogendoerfer
2026-05-06 22:42 ` [PATCH v3 02/10] MIPS: DEC: Prevent initial console buffer from landing in XKPHYS Maciej W. Rozycki
2026-05-26 14:46 ` Thomas Bogendoerfer [this message]
2026-05-06 22:42 ` [PATCH v3 03/10] serial: dz: Fix bootconsole message clobbering at chip reset Maciej W. Rozycki
2026-05-06 22:42 ` [PATCH v3 04/10] serial: dz: Fix bootconsole handover lockup Maciej W. Rozycki
2026-05-06 22:42 ` [PATCH v3 05/10] serial: zs: " Maciej W. Rozycki
2026-05-06 22:42 ` [PATCH v3 06/10] serial: zs: Switch to using channel reset Maciej W. Rozycki
2026-05-06 22:42 ` [PATCH v3 07/10] serial: dz: Convert to use a platform device Maciej W. Rozycki
2026-05-06 22:42 ` [PATCH v3 08/10] serial: zs: " Maciej W. Rozycki
2026-05-06 22:42 ` [PATCH v3 09/10] serial: dz: Enable modular build Maciej W. Rozycki
2026-05-06 22:43 ` [PATCH v3 10/10] MIPS: DEC: Ensure RTC platform device deregistration upon failure Maciej W. Rozycki
2026-05-26 14:49 ` Thomas Bogendoerfer
2026-05-22 15:15 ` [PATCH v3 00/10] MIPS: DEC: Fix serial device regressions + RTC cleanup Maciej W. Rozycki
2026-05-26 14:48 ` Thomas Bogendoerfer
2026-05-26 15:08 ` Maciej W. Rozycki
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=ahWyNMag6EZNyykS@alpha.franken.de \
--to=tsbogend@alpha.franken.de \
--cc=gregkh@linuxfoundation.org \
--cc=jirislaby@kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=macro@orcam.me.uk \
/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