[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aBcM7UXj8HQWZeHJ@gmail.com>
Date: Sun, 4 May 2025 08:45:01 +0200
From: Ingo Molnar <mingo@...nel.org>
To: Borislav Petkov <bp@...en8.de>
Cc: Kees Cook <kees@...nel.org>,
"Gustavo A. R. Silva" <gustavoars@...nel.org>,
linux-hardening@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-tip-commits@...r.kernel.org,
Andy Lutomirski <luto@...nel.org>, Brian Gerst <brgerst@...il.com>,
"Chang S. Bae" <chang.seok.bae@...el.com>,
"H. Peter Anvin" <hpa@...or.com>,
Linus Torvalds <torvalds@...ux-foundation.org>, x86@...nel.org,
Oleg Nesterov <oleg@...hat.com>
Subject: Re: hardened_usercopy 32-bit (was: Re: [tip: x86/merge] x86/fpu:
Make task_struct::thread constant size)
* Borislav Petkov <bp@...en8.de> wrote:
> On Mon, Apr 14, 2025 at 07:34:48AM -0000, tip-bot2 for Ingo Molnar wrote:
>
> > The fpu_thread_struct_whitelist() quirk to hardened usercopy can be
> > removed, now that the FPU structure is not embedded in the task
> > struct anymore, which reduces text footprint a bit.
>
> Well, hardened usercopy still doesn't like it on 32-bit, see splat below:
>
> I did some debugging printks and here's what I see:
>
> That's the loop in copy_uabi_to_xstate(), copying the first FPU state
> - XFEATURE_FP - to the kernel buffer:
>
> [ 1.752756] copy_uabi_to_xstate: i: 0 dst: 0xcab11f40, offset: 0, size: 160, kbuf: 0x00000000, ubuf: 0xbfcbca80
> [ 1.754600] copy_from_buffer: dst: 0xcab11f40, src: 0xbfcbca80, size: 160
>
> hardened wants to check it:
>
> [ 1.755823] __check_heap_object: ptr: 0xcab11f40, slap_address: 0xcab10000, size: 2944
> [ 1.757102] __check_heap_object: offset: 2112
>
> and figures out it is in some weird offset 2112 from *task_struct* even
> though:
>
> [ 1.750149] copy_uabi_to_xstate: sizeof(task_struct): 1984
>
> btw, the buffer is big enough too:
>
> [ 1.749077] copy_uabi_to_xstate: sizeof(&fpstate->regs.xsave): 576
>
> but then it decides to BUG because an overwrite attempt is being done on
> task_struct which is bollocks now as struct fpu is not part of it anymore.
>
> And this is where I'm all out of ideas so lemme CC folks.
Thx for the report, mind sending the exact .config that fails for you?
Thanks,
Ingo
Powered by blists - more mailing lists