Re: [PATCH v14 11/19] unwind_user/sframe: Show file name in debug output

Jens Remus <[email protected]> Mon, 18 May 2026 17:27:30 +0200
Newsgroups dev.linux.lists.sashiko,org.kernel.vger.bpf
Organization IBM Deutschland Research & Development GmbH
Message-ID <[email protected]>
On 5/5/2026 8:46 PM, [email protected] wrote:
> Thank you for your contribution! Sashiko AI review found 6 potential issue(s) to consider:

> - [High] Unbounded kernel memory allocations controlled by user space do not use `__GFP_ACCOUNT`, allowing memory cgroup limit bypass.

> --
> 
> commit d6a437647b4507fcb6d70115c0d08b1d68cafa8a
> Author: Josh Poimboeuf <[email protected]>
> 
> unwind_user/sframe: Show file name in debug output
> 
> This commit adds the file name to debug output messages for sframe sections
> to make debugging easier. It records the filename when the section is added
> by inspecting the associated VMA.

>> diff --git a/kernel/unwind/sframe_debug.h b/kernel/unwind/sframe_debug.h

>> +static inline void dbg_init(struct sframe_section *sec)
>> +{
>> +	struct mm_struct *mm = current->mm;
>> +	struct vm_area_struct *vma;
>> +
>> +	guard(mmap_read_lock)(mm);
>> +	vma = vma_lookup(mm, sec->sframe_start);
>> +	if (!vma)
>> +		sec->filename = kstrdup("(vma gone???)", GFP_KERNEL);
>> +	else if (vma->vm_file)
>> +		sec->filename = kstrdup_quotable_file(vma->vm_file, GFP_KERNEL);

> Do these string allocations need __GFP_ACCOUNT? Since they are triggered by
> user space and persist until the section is removed, could a user allocate
> large amounts of uncharged memory and bypass memory cgroup limits?
> 
>> +	else if (vma->vm_ops && vma->vm_ops->name)
>> +		sec->filename = kstrdup(vma->vm_ops->name(vma), GFP_KERNEL);

>> +	else if (arch_vma_name(vma))
>> +		sec->filename = kstrdup(arch_vma_name(vma), GFP_KERNEL);
>> +	else if (!vma->vm_mm)
>> +		sec->filename = kstrdup("(vdso)", GFP_KERNEL);
>> +	else
>> +		sec->filename = kstrdup("(anonymous)", GFP_KERNEL);
>> +}
> 

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.

Use GFP_KERNEL_ACCOUNT instead of GFP_KERNEL.  See my related reply to
"[PATCH v14 03/19] unwind_user/sframe: Store .sframe section data in
per-mm maple tree" for further details.

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/