The world of Linux is all about stability and efficiency, but sometimes even the smallest mistakes can create security risks and reliability problems. CVE-2021-47043 (see NVD reference) is such a case: a resource leak found and fixed in the Venus driver, which is used for video hardware acceleration on Qualcomm chips.

Let’s break it down for beginners and show you the raw details, including the nature of the bug, affected code, an exploit scenario, and how developers fixed it.

What is the Venus Driver?

The Venus driver (venus) is part of the “media” subsystem in the Linux Kernel. It manages video encoding and decoding through hardware on certain Qualcomm chips. If you have an Android phone with a Qualcomm CPU, you’re probably relying on Venus for smooth video.

What’s CVE-2021-47043 About?

Short answer:
A resource (Interconnect Path) was allocated in the driver but not always properly freed when the driver initialization (the probing sequence) failed. Over time, failing to free resources leads to RAM and handle leaks that can impact system performance and, in rare cases, be exploitable.

Before Patch

// In venus_probe()

icc = of_icc_get(dev, "video-mem");  // Interconnect path is acquired
if (IS_ERR(icc))
    return PTR_ERR(icc);

// ... errors can occur further down, leading to returning early
if (some_error)
    return -EINVAL; // Resource not freed if we return here

// ... normal code continues

// elsewhere
icc_put(icc); // Only called during normal teardown, not on error path

The Bug

If an error happens after of_icc_get() is successful, but before the normal shutdown/teardown path is reached, the “video-mem” interconnect handle is leaked — it’s never released. Do this enough times (like repeatedly loading/unloading the driver), and you’re in trouble.

#### Reference to the commit

When: Reported in early 2021, fixed in Linux 5.13 and later.

- Where: All Linux systems using Venus driver (mainly ARM/Android devices).
- Exploit likelihood: Very low for classic "attacker" exploitation, but it could allow a malicious app with kernel access, or a buggy script, to cause the kernel to exhaust resources and destabilize the device.

Exploit Example:

You could imagine an automated script (or a driver flaw) that repeatedly inserts and removes the Venus module:

# UNFRIENDLY LOOP - DO NOT RUN ON PRODUCTION SYSTEMS
while true; do
    modprobe venus
    rmmod venus
done

Each time an error path is taken in venus_probe(), leaked resources would slowly choke the system. If you’re a determined adversary, this is an easy (if not very high-return) local DoS vector.

The maintainers swapped in the device-managed variant of the interconnect acquisition

What does device-managed mean?
When you use device-managed (“devm_” prefixed) functions, the kernel *automatically* cleans up any resources if the device (driver) is removed or if probe fails.

After Patch

// In venus_probe()
icc = devm_of_icc_get(dev, "video-mem");
if (IS_ERR(icc))
    return PTR_ERR(icc);

// ...
// No manual 'icc_put' needed, devm will handle it now!

Since cleanup is now automatic, they also removed related icc_put() calls – less code, fewer bugs.

Key Takeaways

- The bug caused *resource leaks* in the venus kernel module by not properly cleaning up after itself when error paths were triggered.
- The devm_of_icc_get() API is safer, because it guarantees clean-up no matter how the initialization ends.
- Classic attacker exploitation is unlikely, but local denial of service or gradual performance degradation was possible.

- Original Patch Commit
- NVD CVE-2021-47043 Description
- Linux Kernel source tree: drivers/media/platform/qcom/venus/venus-core.c

Conclusion

CVE-2021-47043 is a classic example of resource leak that may not be flashy, but it’s the kind of thing that can make systems unreliable if left unchecked. The fix was both elegant and robust: use better APIs, and let the kernel do the clean-up.

If you maintain drivers or write kernel code, the lesson is simple: always use device-managed resources wherever possible!


*Stay tuned for more root-cause and exploit breakdowns in simple language. Got questions? Drop them below!*

Timeline

Published on: 02/28/2024 09:15:40 UTC
Last modified on: 01/09/2025 15:21:46 UTC