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 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. We have a fairly simple reproducer. We widdled it down from picking an address to pass to mmap(2) using getrandom(2) to using the same address every time. Sometimes it triggers the behavior, sometimes it does not. We also observe that disabling ASLR via sysctl kernel.randomize_va_space=0 works around the issue, with obvious caveats. Here is a reproducer, which raises SIGSTOP so that you can analyze /proc/<pid>/maps. It allocates a 512 MB address space and then attempts to give it execute permissions. Running it multiple times will eventually trigger the behavior. #include <stdint.h> #include <unistd.h> #include <errno.h> #include <sys/mman.h> #include <sys/random.h> #include <signal.h> int main(void) { uintptr_t raw_addr = 0x25085000; int length = 512 * 1024 * 1024; void* pointer = mmap((void *)raw_addr, length, PROT_NONE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); if (!pointer) { raise(SIGSTOP); return 1; } if (mprotect(pointer, length, PROT_READ | PROT_WRITE | PROT_EXEC) == -1) { raise(SIGSTOP); return 1; } return 0; } As far as impact goes, this is mostly causing Chromium/Electron based applications to fail randomly, but I believe other applications such as wine-preloader (which I do not think is based on Chromium) are also affected. 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.
