---

Introduction

In early 2022, a significant vulnerability, CVE-2022-0487, was found in the memstick subsystem of the Linux Kernel—specifically, in the rtsx_usb_ms_drv_remove function inside drivers/memstick/host/rtsx_usb_ms.c. This bug can allow a local attacker with basic user privileges to potentially leak sensitive information from kernel memory, breaking system confidentiality. This issue affected all Linux kernel versions prior to 5.14-rc1.

This post takes you through the technical nature of the vulnerability, what could be done by an attacker, and how you can find this flaw in source code and practice a simple demonstration. If you’re a sysadmin, security engineer, or just a curious Linux enthusiast, this post is for you.

What’s Affected?

- Component: drivers/memstick/host/rtsx_usb_ms.c (part of 'memstick' framework for Sony memory sticks)

Attack vector: Local attacker (needs to run code on your system)

Key problem: A "use-after-free" bug means the driver used memory after it was already returned to the system. This could lead to information leaks or even potential code execution.

Reference

- NVD Entry for CVE-2022-0487
- Patch Commit

2. Digging Into the Code

Let's look at the vulnerable function, based on the Linux 5.13 and earlier source code (some comments and code simplified for clarity):

static void rtsx_usb_ms_drv_remove(struct memstick_host *host)
{
    struct rtsx_usb_ms *ms = memstick_priv(host);

    memstick_remove_host(host);    
    kfree(ms);                     // ms memory is freed here

    // ... 
    // Oops—other code that could still reference 'ms'
}

Problem: If any code after kfree(ms) tries to use the ms pointer, the kernel is now referencing freed memory. This is classic *use-after-free* and could be abused.

3. How Attackers Can Exploit This

- A normal user with access to the affected memory stick device could potentially trigger the remove path.
- If carefully timed, they could cause the kernel to leak memory (which may include sensitive info, like passwords, file names, or even data from other kernel subsystems).
- Since the flaw is local-only (i.e., can't be exploited remotely), a real attack would require a program running on the system.

Real-world Threat?

While code execution is uncommon for such bugs (as more steps are needed), infoleaks can aid other, more dangerous kernel exploits.

4. Quick Proof-of-Concept (PoC)

While a full working exploit is complex, here’s a simple code skeleton that could trigger the vulnerable path on a vulnerable kernel. Do not use this code on production systems.

#include <fcntl.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/ioctl.h>

int main() {
    // WARNING: May crash your kernel if vulnerable!
    int fd = open("/dev/memstick", O_RDWR);
    if (fd < ) {
        perror("open memstick");
        exit(EXIT_FAILURE);
    }
    // Trigger device removal (unplug, or possible via driver tricks)
    printf("Now, remove the memory stick device to trigger the bug.\n");
    sleep(10);
    close(fd);
    return ;
}

The *core idea* is to open the device, cause a remove event (like unplugging it), and see if kernel logs report a "use-after-free" or "slab corruption".

PATCH! Make sure you’re running Linux kernel 5.14-rc1 or newer.

- For older systems, the relevant patch is here.
- If you can't patch, blacklisting the affected driver (rtsx_usb_ms) will protect you (if you don't need memory stick devices).

Vendor Notification: Most major Linux distributions backported the patch to LTS kernels. Check your distro’s security bulletins for "CVE-2022-0487".

6. Learn More

- CVE-2022-0487 NVD Entry
- Linux Kernel Patch
- memstick documentation

7. Conclusion

CVE-2022-0487 is another example of how complex kernel drivers can open serious holes, even in local-privilege-only settings. As always, keep your systems updated. If you're developing kernel code, always be wary of freeing memory and reusing pointers!

If you ever see strange kernel messages after removing hardware or using memory sticks, check your kernel version—it could be this bug.

Timeline

Published on: 02/04/2022 23:15:00 UTC
Last modified on: 04/30/2022 02:40:00 UTC