linux-kernel - Re: [PATCH] selftests/futex: Fix futex_numa

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <61725722-f933-447c-a041-71b2d28e7f90@igalia.com>
Date: Thu, 28 Aug 2025 15:06:26 -0300
From: André Almeida <andrealmeid@...lia.com>
To: Waiman Long <llong@...hat.com>,
 Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: Darren Hart <dvhart@...radead.org>, Davidlohr Bueso <dave@...olabs.net>,
 Ingo Molnar <mingo@...hat.com>, Juri Lelli <juri.lelli@...hat.com>,
 Peter Zijlstra <peterz@...radead.org>, Thomas Gleixner <tglx@...utronix.de>,
 Valentin Schneider <vschneid@...hat.com>, Borislav Petkov <bp@...en8.de>,
 kernel-dev@...lia.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] selftests/futex: Fix futex_numa_mpol's memory out of
 range subtest

Em 27/08/2025 14:58, Waiman Long escreveu:
> 
> On 8/27/25 11:44 AM, André Almeida wrote:
>> The "Memory out of range" subtest works by pointing the futex pointer
>> to the memory exactly after the allocated map (futex_ptr + mem_size).
>> This address is out of the allocated range for futex_ptr, but depending
>> on the memory layout, it might be pointing to a valid memory address of
>> the process. In order to make this test deterministic, create a "buffer
>> zone" with PROT_NONE just before allocating the valid futex_ptr memory,
>> to make sure that futex_ptr + mem_size falls into a memory address that
>> will return an invalid access error.
>>
>> Fixes: 3163369407ba ("selftests/futex: Add futex_numa_mpol")
>> Signed-off-by: André Almeida <andrealmeid@...lia.com>
>> ---
>> This patch comes from this series:
>> https://lore.kernel.org/lkml/20250704-tonyk-robust_test_cleanup-v1-13- 
>> c0ff4f24c4e1@...lia.com/
>> ---
>>   .../futex/functional/futex_numa_mpol.c          | 17 ++++++++++++++++-
>>   1 file changed, 16 insertions(+), 1 deletion(-)
>>
>> diff --git a/tools/testing/selftests/futex/functional/ 
>> futex_numa_mpol.c b/tools/testing/selftests/futex/functional/ 
>> futex_numa_mpol.c
>> index a9ecfb2d3932..1eb3e67d999b 100644
>> --- a/tools/testing/selftests/futex/functional/futex_numa_mpol.c
>> +++ b/tools/testing/selftests/futex/functional/futex_numa_mpol.c
>> @@ -143,7 +143,7 @@ int main(int argc, char *argv[])
>>   {
>>       struct futex32_numa *futex_numa;
>>       int mem_size, i;
>> -    void *futex_ptr;
>> +    void *futex_ptr, *buffer_zone;
>>       int c;
>>       while ((c = getopt(argc, argv, "chv:")) != -1) {
>> @@ -168,6 +168,17 @@ int main(int argc, char *argv[])
>>       ksft_set_plan(1);
>>       mem_size = sysconf(_SC_PAGE_SIZE);
>> +
>> +    /*
>> +     * The "Memory out of range" test depends on having a pointer to an
>> +     * invalid address. To make this test deterministic, and to not 
>> depend
>> +     * on the memory layout of the process, create a "buffer zone" with
>> +     * PROT_NONE just before the valid memory (*futex_ptr).
>> +     */
>> +    buffer_zone = mmap(NULL, mem_size, PROT_NONE, MAP_PRIVATE | 
>> MAP_ANONYMOUS, 0, 0);
>> +    if (buffer_zone == MAP_FAILED)
>> +        ksft_exit_fail_msg("mmap() for %d bytes failed\n", mem_size);
>> +
>>       futex_ptr = mmap(NULL, mem_size, PROT_READ | PROT_WRITE, 
>> MAP_PRIVATE | MAP_ANONYMOUS, 0, 0);
>>       if (futex_ptr == MAP_FAILED)
>>           ksft_exit_fail_msg("mmap() for %d bytes failed\n", mem_size);
> 
> This patch makes the assumption that consecutive mmap() calls will 
> allocate pages consecutively downward from a certain address. I don't 
> know if this assumption will be valid in all cases. I think it will be 
> safer to just allocate the 2-page memory block and then change the 2nd 
> page protection to PROT_NONE to make it a guard page.
> 

Thanks for the feedback! I will send a v2 addressing this by next week.