CVE-2026-93071 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
media: bcm2835-unicam: Fix asc leaked in error/remove path
v4l2_async_nf_add_fwnode_remote() allocates the asc, which is freed when v4l2_async_nf_cleanup() is called.
Call v4l2_async_nf_cleanup() properly in the driver paths.
Discovered with kmemleak after rmmod:
unreferenced object 0xffff000084526b80 (size 64): comm "modprobe", pid 185, jiffies 4295013512 hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 e8 0d ff bf 00 00 ff ff ................ 40 83 bc 84 00 00 ff ff 60 83 bc 84 00 00 ff ff @.......`....... backtrace (crc ac584083): [<00000000ffb081a7>] kmemleak_alloc+0x38/0x44
[<00000000d2fd9301>] __kmalloc+0x1b0/0x250
[<000000004dd5354d>] __v4l2_async_nf_add_fwnode+0x28/0x9c
[<0000000067587657>] __v4l2_async_nf_add_fwnode_remote+0x3c/0x64
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel driver for the BCM2835 Unicam media interface contains a resource management flaw that results in memory leaks during module removal or error handling sequences. This vulnerability specifically affects the v4l2_async_nf_add_fwnode_remote function, which is responsible for adding remote firmware node references to an asynchronous notifier framework within the Video4Linux subsystem. When this function executes successfully, it allocates a struct v4l2_async_subdev structure, commonly referred to as asc in internal code paths. The lifecycle of this allocated memory is tied to the cleanup routine v4l2_async_nf_cleanup, which is designed to release all resources associated with the notifier framework when the driver is unloaded or encounters a critical failure that necessitates teardown.
The core technical flaw lies in the improper invocation of the cleanup function within specific error paths and during module removal. In several code branches where initialization fails or the device is being detached from the system, the driver fails to call v4l2_async_nf_cleanup before returning an error code or completing the unbind process. Consequently, any asc structures allocated prior to these failure points remain referenced by the kernel memory allocator but are never freed because the cleanup routine that would release them is bypassed. This behavior creates a classic resource leak scenario where dynamic memory allocations accumulate over time if the driver initialization fails repeatedly or if the module is frequently loaded and unloaded during development or debugging cycles.
Detection of this issue was facilitated by kmemleak, a kernel tool designed to detect memory leaks by tracking object allocation and reference counts. The diagnostic output identified an unreferenced object with a size of sixty-four bytes, which corresponds exactly to the sizeof(struct v4l2_async_subdev). The backtrace confirms that the leak originates from __v4l2_async_nf_add_fwnode_remote, validating that the memory was indeed allocated but not subsequently freed. This type of defect is categorized under CWE-401, which describes a missing release of memory after effective usage. Although this specific instance involves relatively small amounts of data per occurrence, repeated occurrences can lead to significant kernel memory exhaustion, potentially degrading system performance or causing out-of-memory conditions in resource-constrained environments such as embedded systems where the BCM2835 SoC is commonly deployed.
From an operational perspective, while a single leak may not immediately crash the system due to its small size, it represents a violation of proper driver lifecycle management principles. In production environments, frequent module reloads or repeated initialization failures could gradually consume available kernel memory. Furthermore, such leaks indicate broader inconsistencies in error handling logic within the driver, suggesting that other resources might also be improperly managed in similar failure scenarios. The ATT&CK framework does not directly map to this type of vulnerability as it is primarily focused on adversary tactics and techniques rather than software defects; however, from a defensive security posture perspective, such memory management errors can sometimes be leveraged in conjunction with other vulnerabilities to achieve denial-of-service conditions or potentially aid in heap-based exploitation strategies if the leaked pointers are later reused improperly.
To mitigate this vulnerability, developers must ensure that v4l2_async_nf_cleanup is called consistently across all exit paths of the driver's probe and remove functions. This includes adding explicit cleanup calls before returning error codes from initialization routines where async notifier structures have already been allocated. Additionally, code review processes should enforce strict adherence to resource acquisition order reversal during teardown sequences. Static analysis tools can be configured to detect patterns where allocation functions are followed by conditional returns without corresponding deallocation calls. Regular use of memory debugging tools like kmemleak or Valgrind in kernel development cycles is recommended to catch such discrepancies early. Ensuring that every code path that allocates resources also has a guaranteed mechanism for their release maintains system stability and prevents the gradual degradation of kernel memory integrity over time.