In early 2022, a vulnerability was found and fixed in the Linux kernel's TTY subsystem, specifically within the icom_probe function. This bug—now tracked as CVE-2022-49314—could cause resource leaks if a hardware initialization step failed, potentially leading to system instability or denial of service.

This post explains what happened, why it was dangerous, shows you direct snippets of the buggy and patched code, and walks you through what an exploit might look like. Everything is broken down in simple terms so you can follow along, whether you’re a seasoned kernel hacker or just learning about system security.

What is icom_probe?

The icom_probe function is part of a Linux kernel driver for certain IBM serial/communications adapters (often used in PCI cards). It's responsible for setting up communication between the kernel and the device hardware. It allocates resources, requests access to PCI regions, and reads device configuration.

The Bug — Resource Leak

Inside icom_probe, the driver allocates certain resources. If a later initialization step fails due to a problem—say, a failed call to pci_read_config_dword() (which fetches configuration data from the device)—the error handling *didn't* clean up the resources it had already allocated: pci regions and enabled device state.

Real-world effect: If such a failure happens multiple times (for example, during scan and probe of many devices), your system may eventually run out of PCI resources or get into a bad state. In high-security or uptime-critical environments, this is a problem.

Affected Versions

- Kernel versions before the fix commit on January 2, 2022.

This mainly affected systems using icom hardware—but as with any kernel bug, it could impact system stability if probed with malicious PCI devices.

Here’s a simplified look at the relevant logic in the vulnerable code (before the fix)

int icom_probe(...){
    ...
    err = pci_enable_device(pdev);
    if (err) return err;

    err = pci_request_regions(pdev, "icom");
    if (err) goto disable;

    // Read config; could fail!
    err = pci_read_config_dword(pdev, SOME_CONFIG, &some_var);
    if (err) goto release;

    // SUCCESS PATH
    ...
    return ;

release:
    // Oops! Only release regions.
    pci_release_regions(pdev);
disable:
    pci_disable_device(pdev);
    return err;
}

THE BUG:
If pci_read_config_dword() fails, pci_release_regions() is called without also disabling the device. That means resources and device state are leaked.

Developers added proper clean-up on error to prevent resource leakage

release:
    pci_release_regions(pdev);
    /* Add this line to properly disable device */
    pci_disable_device(pdev);
    return err;

See the patch commit on kernel.org.

Exploit Details

Is this exploitable by attackers?
It is unlikely to result in code execution or typical privilege escalation. However, a malicious or faulty PCI device—real, virtual, or emulated—could repeatedly trigger this codepath by failing pci_read_config_dword(), intentionally or otherwise.

Potential impact:

This could be triggered by

- Plugging in specially crafted/faulty PCI adapter

Suppose you have control over PCI device emulation, e.g., via QEMU, PCIe fuzzing, or hotplugging

1. Emulate/plug a device that registers as an icom-compatible device.

Ensure device's PCI config space triggers failure during pci_read_config_dword().

3. Repeatedly unplug/plug device (or use a VM reset) to trigger resource leaks.

Why is it exclusive?
With enough repeats, you can exhaust PCI resources or destabilize the kernel. On embedded environments or high-availability systems, this is a serious risk.

Code Example: Proof-of-Concept PCI Device Fuzzer (Pseudocode)

# This is conceptual: use PCI fuzzing tools like 'pcie-fuzz' for real tests
for i in range(10000):
    emulate_pci_device(class_code=ICOM_CLASS, bad_config=True)
    hotplug_device_to_linux()
    remove_device()

Kernel 5.16.1, and all mainline versions after January 2022.

- Direct patch link

If running unpatched custom kernels:
Apply the commit above, recompile, and deploy.

References

- CVE-2022-49314 (NVD)
- Linux commit with fix
- Full diff (lore.kernel.org)
- PCI Fuzzing tools for security researchers

Conclusion

CVE-2022-49314 is a classic example of how even small cleanup oversights in kernel code can lead to security and stability problems, especially when triggered by hardware input. Thanks to clear patching, the resource leaks are fixed. Still, it’s a reminder: Even error paths need as much attention as the “happy path” in system programming!

For maximum security, keep your kernel up to date—small bugs like this can become big headaches in the wrong hands.

Timeline

Published on: 02/26/2025 07:01:08 UTC
Last modified on: 04/14/2025 19:59:14 UTC