Re: [PATCH v3 3/4] selinux: use vma_is_initial_stack() and vma_is_initial_heap()

[Marc Reisner <reisner.marc@gmail.com>]

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.