Use of a Non-reentrant Function in a Concurrent Context

This vulnerability occurs when a program uses a function that is not safe for reentrancy within a concurrent environment, such as multi-threaded code or signal handlers. If another thread or signal handler interrupts and calls the same function, it can corrupt shared data, cause crashes, or create unpredictable behavior.

Non-reentrant functions rely on or modify shared global or static data, making them unsafe when multiple execution flows can interrupt each other. In a concurrent context—like a multi-threaded application or a program using signal handlers—if one thread is inside such a function and another thread or signal handler calls the same function, the shared state can be corrupted. This leads to race conditions, memory corruption, or incorrect program outputs, often manifesting as intermittent, hard-to-debug failures. To prevent this, developers should identify functions not designed for concurrency (like many traditional C library functions) and protect their use with proper synchronization mechanisms, such as mutexes or semaphores. Alternatively, replace them with thread-safe, reentrant equivalents (often denoted with '_r' suffixes in C). Always audit code for global/static variable usage within functions that may be accessed by multiple threads or signal handlers, and design concurrent systems with clear ownership of shared resources.