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/