Use of a Non-reentrant Function in a Concurrent Context

Draft Base
Structure: Simple
Description

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.

Extended Description

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.

Common Consequences 1
Scope: IntegrityConfidentialityOther

Impact: Modify MemoryRead MemoryModify Application DataRead Application DataAlter Execution Logic

Potential Mitigations 3
Phase: Implementation
Use reentrant functions if available.
Phase: Implementation
Add synchronization to your non-reentrant function.
Phase: Implementation
In Java, use the ReentrantLock Class.
Demonstrative Examples 2

ID : DX-171

In this example, a signal handler uses syslog() to log a message:

Code Example:

Bad
C
c

ID : DX-172

The following code relies on getlogin() to determine whether or not a user is trusted. It is easily subverted.

Code Example:

Bad
C
c
Observed Examples 2
CVE-2001-1349unsafe calls to library functions from signal handler
CVE-2004-2259SIGCHLD signal to FTP server can cause crash under heavy load while executing non-reentrant functions like malloc/free.
References 2
Use reentrant functions for safer signal handling
Dipak Jha, Software Engineer, IBM
ID: REF-548
Modes of Introduction
Implementation
Related Attack Patterns
Related Weaknesses