* Ingo Molnar <[email protected]> wrote:
> > * Borislav Petkov <[email protected]> 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? BTW., mind sending the full bootlog as well? I cannot reproduce it here with CONFIG_HARDENED_USERCOPY=y, so I suspect it's something about the build, HW or boot environment. Thanks, Ingo
