linux-kernel - Re: [PATCH] x86/sgx: Replace kmalloc() + copy_from_user() with memdup

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <ee907cef-684b-49a3-84c3-ba2efead9caa@intel.com>
Date: Thu, 25 Sep 2025 08:37:22 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Thorsten Blum <thorsten.blum@...ux.dev>,
 kernel test robot <oliver.sang@...el.com>
Cc: oe-lkp@...ts.linux.dev, lkp@...el.com, linux-sgx@...r.kernel.org,
 Jarkko Sakkinen <jarkko@...nel.org>,
 Dave Hansen <dave.hansen@...ux.intel.com>,
 Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
 Borislav Petkov <bp@...en8.de>, x86@...nel.org,
 "H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86/sgx: Replace kmalloc() + copy_from_user() with
 memdup_user()

On 9/22/25 06:18, Thorsten Blum wrote:
>> The kernel config and materials to reproduce are available at:
>> https://download.01.org/0day-ci/archive/20250921/202509211747.1edb60f-
>> lkp@...el.com
> Can someone explain why this test is failing?
> 
> After some digging into SGX, I think it's the different allocators
> kmalloc() vs. kmem_buckets_alloc_track_caller(), but I'm not exactly
> sure why it fails.
> 
> Perhaps we should add a comment for anyone else trying to replace this?

I can't fathom that this is an SGX problem. The SGX code is as dirt
simple as it gets:

	secs = kmalloc(PAGE_SIZE, GFP_KERNEL);

There are literally thousands of those in the kernel.

memdup_user() look suspicious to me, though:

        p = kmem_buckets_alloc_track_caller(...GFP_USER | __GFP_NOWARN);

That GFP_USER looks wrong. It shouldn't matter _much_ in practice, but
it's allocating kernel memory with GFP_USER.