Hunting a Critical Use-After-Free in a C++ Sensor Pipeline

The Critical Find: Shutdown Race

The most dangerous finding was a shutdown race on the running flag.

The destroy_pipeline() function writes running = false without holding any lock and without calling pthread_join(). Because of this, background threads reading this flag may attempt to access data after it has been deleted.

// Vulnerable Code - destroy_pipeline() (simplified)
void destroy_pipeline() {
    // Unsynchronised write! No lock, threads may not see this immediately
    g_pipeline.running = false;  

    // Frees shared memory too early
    delete[] g_pipeline.readings;  

    // No pthread_join()
    // background threads could still be reading the deleted array!
}

// Valgrind Trace Example (Data Race)
Possible data race during write of size 1 at 0x10C28C by thread #1
Locks held: none
   at 0x10973F: destroy_pipeline() (sensor_pipeline.cpp:123)
   by 0x10998C: main (sensor_pipeline.cpp:146)

This conflicts with a previous read of size 1 by thread #2
Locks held: none
   at 0x1095DA: flush_thread(void*) (sensor_pipeline.cpp:81)

Recommended Remediation

To fix the race, the diagnostic recommends adding a pthread_join to destroy_pipeline() to ensure all background tasks conclude before memory is reclaimed.

// Recommended Fix - destroy_pipeline()
void destroy_pipeline() {
    pthread_mutex_lock(&g_pipeline.lock);
    g_pipeline.running = false; 
    pthread_mutex_unlock(&g_pipeline.lock);

    // Wait for threads to exit BEFORE freeing memory
    pthread_join(g_flusher, nullptr);
    pthread_join(g_alerter, nullptr);

    delete[] g_pipeline.readings;
    pthread_mutex_destroy(&g_pipeline.lock);
}

For long-term prevention, consider modern C++ alternatives like std::unique_ptr or std::shared_ptr for managing the readings array. These smart pointers automatically handle deletion when the last reference goes out of scope, reducing the risk of dangling pointers that lead to UAF.

Leak Detection & Noise Filtering

The diagnostic uncovered specific areas where the system "forgets" to release memory when it encounters bad data, leading to memory bloat that can slow down or crash the application over time.

Equally important, we identified several "false alarms" in the system's background tasks. By classifying these as standard system behavior rather than actual bugs, we ensure your engineering team doesn't waste hours "chasing ghosts" or fixing code that isn't actually broken.

Modernizing the Pipeline

The final Prioritised Remediation Roadmap suggests moving beyond simple bug fixes toward safer C++ patterns:

• Atomics: Replace bool running and int count with std::atomic types (e.g., std::atomic<bool>). This ensures thread-safe reads/writes without locks for simple variables, preventing data races that could delay flag visibility and contribute to UAF scenarios.
• RAII: Replace raw char with std::string and use std::unique_ptr for sensor readings to prevent future leaks.
• Validation: Re-run Memcheck and Helgrind, targeting 0 errors from 0 contexts.