CVE-2026-43231

What it actually does

CVE-2026-43231 is a Linux kernel memory-leak flaw in the media USB radio driver for Keene devices. During usb_keene_probe(), the driver initializes a V4L2 control handler and then attempts to register the V4L2 device and video device. If either later registration step fails, the error path previously did not free the initialized control handler, causing kernel memory to be leaked. Because the bug is reachable through local device-probe activity and affects kernel memory, repeated triggering can degrade system availability and potentially exhaust memory, leading to denial of service. The vulnerability does not directly provide confidentiality or integrity impact.

Why it matters to the business

Systems running affected Linux kernels with the vulnerable Keene USB radio media driver enabled could experience instability or outages if an attacker with local access can repeatedly trigger the faulty probe path. The practical risk is primarily availability-related: memory pressure, service disruption, degraded host performance, or a crash/reboot if kernel memory is exhausted. EPSS is very low, there is no known public exploit maturity, and it is not listed in CISA KEV, so broad internet-scale exploitation is unlikely; however, organizations with exposed physical/USB access, shared workstations, lab systems, kiosks, or environments allowing untrusted USB devices should still treat this as a hardening and patching issue.

How an attack unfolds

An attacker needs local access or another path to cause the affected kernel driver to probe a Keene USB radio-compatible device. The attacker connects or emulates a USB device that reaches the radio-keene probe logic and causes a later registration operation, such as V4L2 device registration or video device registration, to fail after the control handler has already been initialized. On vulnerable kernels, the error path exits without freeing that handler. By repeatedly triggering the probe-failure path, the attacker can cause incremental kernel memory loss. Over time, this can create memory pressure, trigger out-of-memory behavior, kill workloads, or destabilize the host. Exploitation is therefore local and availability-focused rather than remote code execution or data theft.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix adding v4l2_ctrl_handler_free() to the radio-keene error path. Because no exact fixed package versions were provided, use the fixed kernel versions supplied by the relevant Linux distribution, appliance vendor, cloud image provider, or long-term-stable kernel branch. If immediate patching is not possible, reduce exposure by disabling or blacklisting the radio-keene driver if it is not needed, restricting untrusted USB device access, disabling unused media/USB radio support in custom kernels, and enforcing physical port controls or USB device allow-listing. For custom kernel builds, confirm that drivers/media/radio/radio-keene.c includes the corrected cleanup path for failures after V4L2 control handler initialization.

How to confirm the fix worked

Confirm remediation by verifying the running kernel package/version against the vendor advisory or changelog that includes the radio-keene memory-leak fix. On source-based or custom kernels, inspect drivers/media/radio/radio-keene.c and confirm the error path after v4l2_ctrl_handler_init() calls v4l2_ctrl_handler_free() when v4l2_device_register() or video_register_device() fails. Check whether the radio-keene module is present or loaded using module inventory tools such as lsmod, modinfo, kernel config review, or /sys/module inspection. Validate mitigation by confirming the module is absent, unloaded, or blacklisted where not required. After patching, monitor dmesg/journal logs while testing device attach/detach or driver probe failure scenarios and confirm memory usage does not grow abnormally across repeated failed probes.

Typical attack path

1. Gain local access to a Linux system or physical/logical ability to attach or emulate USB devices.
2. Identify that the affected radio-keene media driver is present, loadable, or automatically bound to matching USB hardware.
3. Connect or emulate a Keene radio-compatible USB device that causes the driver probe routine to run.
4. Trigger failure after V4L2 control handler initialization, such as during V4L2 device or video device registration.
5. Repeat the attach/probe/fail cycle to leak kernel memory repeatedly.
6. Cause degraded performance, out-of-memory conditions, killed processes, service disruption, or system crash/reboot.

How to detect it

Look for evidence of repeated driver probing or failures associated with the radio-keene media driver, followed by rising kernel memory pressure or out-of-memory behavior. Useful log sources include the kernel ring buffer, systemd journal, /var/log/kern.log, /var/log/messages, audit logs for module loading, endpoint telemetry for USB device insertion, and configuration management inventories showing loaded kernel modules. Investigate repeated USB attach/detach activity for Keene radio-like devices, repeated radio-keene probe failures, V4L2 registration failures, and OOM events occurring shortly afterward. Because this is a memory leak rather than code execution, there may be no durable file artifact or network indicator; detection should focus on temporal correlation between USB/media-driver probe errors and memory exhaustion. If threat hunting at scale, search for hosts with the radio-keene module loaded or available, recent USB device churn, kernel logs mentioning radio-keene or usb_keene_probe, and unexplained OOM killer activity.

• radio-keene
• radio_keene
• usb_keene_probe
• drivers/media/radio/radio-keene.c
• /sys/module/radio_keene
• /sys/bus/usb/drivers/radio-keene
• v4l2_device_register
• video_register_device
• v4l2_ctrl_handler
• Out of memory: Killed process

What your security team should do

• Prioritize patching affected Linux kernels on systems where local users, untrusted peripherals, kiosks, labs, shared workstations, or physical USB access are in scope.
• If the Keene USB radio driver is not required, blacklist or remove the radio-keene module and consider disabling unused media USB drivers as a broader hardening measure.
• Restrict untrusted USB devices using physical controls, BIOS/UEFI settings, USBGuard, udev policy, endpoint controls, or device allow-listing.
• Review kernel package advisories from the relevant Linux distribution or vendor and schedule upgrades to a kernel containing the radio-keene cleanup fix.
• For custom kernels, backport the small driver cleanup patch and rebuild with only required media drivers enabled.
• Monitor systems for repeated USB probe failures, radio-keene driver activity, abnormal kernel memory growth, and out-of-memory events.
• Treat this as a low-likelihood but potentially disruptive local denial-of-service issue rather than a remote compromise risk.