[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <88d4fc24d4c0449196bf462d54bd6fa2@AcuMS.aculab.com>
Date: Tue, 26 Nov 2024 19:28:22 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Tingmao Wang' <m@...wtm.org>, Mikel Rychliski <mikel@...elr.com>, "Thomas
Gleixner" <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, "Borislav
Petkov" <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>,
"x86@...nel.org" <x86@...nel.org>, "H. Peter Anvin" <hpa@...or.com>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] x86: Fix off-by-one error in __access_ok
From: Tingmao Wang <m@...wtm.org>
> Sent: 26 November 2024 01:09
>
> I hit an issue with using gdb (and eventually more) on a system with 9p
> as rootfs which I eventually root-caused to this, so I'm just posting
> here for reference / another testing datapoint, since I couldn't find
> any other mentions of this error elsewhere and this is in the latest
> stable kernel (6.12 / 6.12.1). Apologies in advance that I might not be
> offering much else useful, but I can confirm that applying this patch
> fixes it.
I believe Linus has applied a different path that does:
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -2389,12 +2389,12 @@ void __init arch_cpu_finalize_init(void)
alternative_instructions();
if (IS_ENABLED(CONFIG_X86_64)) {
- unsigned long USER_PTR_MAX = TASK_SIZE_MAX-1;
+ unsigned long USER_PTR_MAX = TASK_SIZE_MAX;
Probably not been back-ported yet.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists