[SOLVED] FATAL: ThreadSanitizer: unexpected memory mapping when running on Linux Kernels 6.6+

Issue

The Problem

Recently on Linux Kernels 6.6.6 and higher it was discovered that thread sanitizer will always lead to this error:

FATAL: ThreadSanitizer: unexpected memory mapping 0x5c9bd4d2b000-0x5c9bd4d4b000

I can reproduce this by writing a hello world example in C

#include <stdio.h>

int main(void)
{
    printf("Hello, World!\n");
}

And compiling it with tsan + running it on Arch Linux (Kernel 6.7.0) with:

clang -o play -fsanitize=thread -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer src/play.c
./play

This will produce the above error (with different memory addresses).

According to the github issue this will also occur in c++ files that just define an empty main() function.

The question

What are your options for dealing with this?

I have only recently started diving deeper into low-level operations and can barely use thread-sanitizer at my current knowledge levels. ASLR (which appears to be the cause of the problem) is entirely foreign to me, as are options to manipulate it and what the consequences are.

The github issue mentions 2 potential workarounds:

1. Disabling ASLR (I only found this SO question for this )
2. Reducing ASLR via sudo sysctl vm.mmap_rnd_bits=30

I have tried 2. and compiled + ran the example again as described, this did not resolve the issue.

I am hesitant to disable ASLR as per 1., as I wouldn't know what the implications of that are or how to "undo" that change.

What other general options to approach this are out there?

Solution

In this particular case, sudo sysctl vm.mmap_rnd_bits=30 is indeed sufficient, but requires a more modern clang version than arch-linux provides by default. The version at the time of writing (16.0.6) stems from June 2023.

It does not contain a fix from November 2023 that allows mmap_rnd_bits having a value of 30.

However, at least on arch linux you can set this value down to 28 at which point it should work again with 16.0.6 (albeit the implication this appears to have is reduced security of the system (?), it definitely beats shutting ASLR off entirely).

You can set it to 28 via sudo sysctl vm.mmap_rnd_bits=28 (Check the value via sudo sysctl vm.mmap_rnd_bits), which should make tsan work again.

Answered By - Philipp Doerner

Answer Checked By - Gilberto Lyons (WPSolving Admin)