Re: [PATCH v14 03/19] unwind_user/sframe: Store .sframe section data in per-mm maple tree

On 5/5/2026 8:51 PM, [email protected] wrote:
> Thank you for your contribution! Sashiko AI review found 6 potential issue(s) to consider:

> - [High] Unbounded memory leak of sframe_section allocations leading to Denial of Service (OOM)

> --
> 
> commit 3b41045a6b38a262cb32acf9ed118e4d667448dd
> Author: Josh Poimboeuf <[email protected]>
> 
> unwind_user/sframe: Store .sframe section data in per-mm maple tree
> 
> Associate an .sframe section with its mm by adding it to a per-mm maple
> tree which is indexed by the corresponding text address range. A single
> .sframe section can be associated with multiple text ranges.
> 

>> diff --git a/kernel/unwind/sframe.c b/kernel/unwind/sframe.c
>> index c128c1eeaca20..fdb2a49085638 100644
>> --- a/kernel/unwind/sframe.c
>> +++ b/kernel/unwind/sframe.c
> [ ... ]
>> @@ -81,6 +81,7 @@ static int sframe_read_header(struct sframe_section *sec)
>>  int sframe_add_section(unsigned long sframe_start, unsigned long sframe_end,
>>  		       unsigned long text_start, unsigned long text_end)
>>  {

> [ ... ]
>>  		}
>>  	}
>>  
>>  	sec = kzalloc(sizeof(*sec), GFP_KERNEL);

Replace with the following to resolve below issue:

	sec = kzalloc(sizeof(*sec), GFP_KERNEL_ACCOUNT);

> 
> This allocates the section with GFP_KERNEL instead of GFP_KERNEL_ACCOUNT,
> which bypasses memory cgroup limits.

Documentation/core-api/memory-allocation.rst states:

* Untrusted allocations triggered from userspace should be a subject
  of kmem accounting and must have ``__GFP_ACCOUNT`` bit set. There
  is the handy ``GFP_KERNEL_ACCOUNT`` shortcut for ``GFP_KERNEL``
  allocations that should be accounted.

Additionally I verified that a user space program can register a forged
.sframe section for every byte of a mmap'ed area to trigger the OOM
killer.  Using cgroup memory and swap limits I can see a difference in
behavior between GFP_KERNEL and GFP_KERNEL_ACCOUNT on my s390 test
system:

# cgcreate -g "memory:test_group" -t root:root
# cgset -r memory.max=1G "test_group"
# cgset -r memory.swap.max=3G "test_group"


Kernel with unwind user sframe using GFP_KERNEL:

# time cgexec -g "memory:test_group" ~/test/malicious-sframe/sframe_test 1000000
...
Killed                     cgexec -g "memory:test_group" ~/test/malicious-sframe/sframe_test 1000000

real    0m21.106s
user    0m0.700s
sys     0m20.305s


Kernel with unwind user sframe using GFP_KERNEL_ACCOUNT:

# time cgexec -g "memory:test_group" ~/test/malicious-sframe/sframe_test 1000000
...
Killed                     cgexec -g "memory:test_group" ~/test/malicious-sframe/sframe_test 1000000

real    0m3.566s
user    0m0.295s
sys     0m3.248s


Running the following in parallel to monitor the cgroup memory usage:
# watch -n1 cat /sys/fs/cgroup/test_group/memory.stat
shows that in case of GFP_KERNEL the value for "kernel" bumps to a high
value and stays there whereas in case of GFP_KERNEL_ACCOUNT it continues
to increase.

> 
> Furthermore, is there a mechanism to clean up these allocated sections when
> the corresponding VMA is torn down (e.g., via munmap)? Without cleanup hooks
> in the VMA teardown paths, it looks like an application could repeatedly mmap
> an executable region, register it here, and munmap it, leaking kernel memory
> and maple tree nodes indefinitely.

IIUC this is already being taken care of the change in __mmdrop() to
call sframe_free_mm(mm), which is part of this patch.

Regards,
Jens
-- 
Jens Remus
Linux on Z Development (D3303)
[email protected] / [email protected]

IBM Deutschland Research & Development GmbH; Vorsitzender des Aufsichtsrats: Wolfgang Wendt; Geschäftsführung: David Faller; Sitz der Gesellschaft: Ehningen; Registergericht: Amtsgericht Stuttgart, HRB 243294
IBM Data Privacy Statement: https://www.ibm.com/privacy/