CVE-2023-30637 - Memory Leak in Baidu Braft 1.1.2 via Misuse of `new` Operator (Exploit Details Inside)

In April 2023, a vulnerability identified as CVE-2023-30637 was disclosed, affecting the popular open-source distributed consensus library Braft developed by Baidu. This vulnerability directly impacts Braft version 1.1.2, specifically in the example atomic/atomic_server, leading to a memory leak due to improper use of the new operator.

In this article, we’ll break down what’s going on—using simple, clear language—so you know whether your deployments are vulnerable, how this memory leak works, what the dangerous code looks like, and how to stay safe.

> Good news: If you use brpc version .14. or later, you are not affected.

What Is Braft?

Braft is Baidu's high-performance C++ implementation of the Raft consensus algorithm. It's often used to manage distributed systems and ensure all nodes agree on a sequence of actions—even in the face of failures.

Where's the Bug?

The vulnerability is in the example at example/atomic/atomic_server/, where the server manages some shared state using atomic operations. In this example, objects are dynamically allocated with new but, in some cases, are not correctly released with delete, resulting in a memory leak that accumulates over time.

Why Does Memory Leak Matter?

A "memory leak" means your server process eats up more and more RAM the longer it runs. Eventually, it may slow down, crash, or even cause a Denial of Service (DoS) if left unchecked.

Here’s a simplified code snippet similar to what's in the vulnerable version

void example_function() {
    SomeObject* obj = new SomeObject();
    // ... (logic using obj)
    // Oops! We forgot to clean up:
    // delete obj; // <- This line is missing!
}

In the context of atomic_server, repeated requests will cause lots of SomeObject instances to build up, each living in memory forever.

Here's how an attacker (or even a regular user) could exploit this

1. Trigger repeated requests: Continuously send operations that cause the server to execute code paths where objects are allocated with new but not released.

Leaked memory grows: Each request leaks a bit more RAM.

3. Crash or slow down: Over time, the server consumes all available system memory and may crash, hang, or be killed by watchdogs.

There is no need for authentication or special privileges—this leak affects everyone accessing the vulnerable server.

How to Test for the Vulnerability

You can verify the leak in a lab by running the atomic_server and sending a lot of requests. Use top or htop to watch the server's memory:

while true; do
    # Replace with a valid command for your Braft atomic_server:
    curl http://localhost:your_port/increment
done

If memory usage keeps rising, you’ve spotted the leak.

Official Fixes and References

Fixed in brpc .14. and later:  
Baidu’s Braft maintainers rely on the BRPC framework, and as of brpc-.14., code refactoring and improvements prevent this leak.

References

- CVE-2023-30637 on NVD
- Braft GitHub Repository
- Upstream Issue / Patch PR

Are you at risk?

- You *are* vulnerable if you use the example atomic_server from Braft 1.1.2 with brpc older than .14..

Upgrade to brpc .14. or later.

- Or, manually audit your own fork/example code to ensure every new is paired with a delete.

Sample law-abiding code

void example_function() {
    SomeObject* obj = new SomeObject();
    // ... use obj ...
    delete obj; // Always free what you allocate!
}

Or, even better, use C++ smart pointers

void example_function() {
    std::unique_ptr<SomeObject> obj(new SomeObject());
    // ... use obj ...
} // obj is freed automatically here

Conclusion

CVE-2023-30637 is a memory leak in Baidu Braft 1.1.2’s atomic_server example, caused by missing delete on objects created with new. Over time, this can bring down your service.  
Check your deployment! Upgrade to the latest BRPC or patch your code to avoid being a victim of this simple, avoidable bug.

Further Reading

- Raft Algorithm
- Memory Management in C++
- Best Practices: Avoiding Memory Leaks

Timeline

Published on: 04/13/2023 23:15:00 UTC
Last modified on: 04/24/2023 16:59:00 UTC