On Wed, Aug 7, 2024 at 5:26 PM Marc Reisner <reisner.marc@xxxxxxxxx> wrote: > > It looks like this issue is still not fixed. There has been some > investigation on going in this Bugzilla for Fedora: > > https://bugzilla.redhat.com/show_bug.cgi?id=2254434 FWIW, I recently learned there was also a report in the kernel bugzilla about the same issue: https://bugzilla.kernel.org/show_bug.cgi?id=218258 > The behavior we are seeing is that when a process has no heap and > mmap(2) is called with MAP_PRIVATE | MAP_ANONYMOUS, it allocates memory > on the heap. > > If the address space returned by mmap(2) is later on made executable > with mprotect(2), that triggers an execheap avc. ... > This has been reproduced on kernels >= 6.6. > > In reviewing the code, my best guess is that this is caused by the > scenario where brk == start_brk not being handled, though I am not > expert enough in kernel code to know. If the start address allocated > by mmap is before the starting program break, and the end address is > after the starting program break, then the avc will trigger. However, > I don't know how mmap deals with determining an address and if it takes > into account the program break, or if calling brk(2) later on will just > pick a new location. I'm not a mm expert, but thankfully we have some on the To/CC line so I'm hopeful they will be able to take a look and provide some insight. To bring the relevant code into this email, prior to using the vma_is_initial_heap() helper the SELinux execheap logic looked like this: /* WORKING */ if (vma->vm_start >= vma->vm_mm->start_brk && vma->vm_end <= vma->vm_mm->brk) /* execheap denial */ ... while the current vma_is_initial_heap() helper has logic that looks like this: /* BUGGY */ if (vma->vm_start < vma->vm_mm->brk && vma->vm_end > vma->vm_mm->start_brk) /* execheap denial */ -- paul-moore.com
