CVE-2026-72266 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
fbdev: vesafb: fix memory leak in vesafb_probe()
Since commit 73ce73c30ba9 ("fbdev: Transfer video= option strings to caller; clarify ownership") the string returned from fb_get_options() is expected to be freed by the caller. But the string is not freed in vesafb_probe(). Fix that by freeing the option string after setup.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/15/2026
The vulnerability identified in the Linux kernel represents a memory leak within the framebuffer device driver subsystem, specifically affecting the vesafb driver responsible for handling VESA framebuffer operations. This issue emerged from a change in how video option strings are managed within the fbdev framework, where commit 73ce73c30ba9 introduced a new pattern requiring callers to explicitly free strings returned by fb_get_options(). The vesafb_probe function failed to implement this required cleanup operation, creating a persistent memory allocation that grows with each driver initialization attempt.
The technical flaw manifests as a classic memory management error where allocated resources are not properly released, violating fundamental principles of resource lifecycle management in kernel space. When the vesafb driver initializes, it calls fb_get_options() to retrieve video parameter strings but neglects to invoke the corresponding free operation on the returned memory allocation. This pattern creates a gradual memory consumption that can accumulate over time, particularly in systems with frequent driver reloads or multiple initialization cycles.
The operational impact of this vulnerability extends beyond simple memory waste to potentially affect system stability and performance under sustained usage conditions. While individual memory leaks may appear minor, in kernel contexts these issues can compound over time, leading to increased memory pressure that might trigger system throttling or even out-of-memory conditions. The vulnerability affects systems utilizing VESA framebuffer drivers where the vesafb module is loaded, particularly impacting embedded systems or virtualized environments where memory resources are constrained.
This memory leak aligns with CWE-401, which specifically addresses improper release of memory after use, and demonstrates a clear violation of proper resource management practices required for kernel-level programming. The fix implemented represents a straightforward but critical correction that ensures all allocated memory is properly returned to the system's memory pool. Security implications extend beyond pure performance concerns as this type of resource exhaustion could potentially be exploited in denial-of-service scenarios, particularly when combined with other vulnerabilities or under high-load conditions.
Mitigation strategies include applying the kernel patch that implements proper string freeing after setup completion, ensuring all callers of fb_get_options() properly clean up their allocations, and monitoring system memory usage patterns for unusual growth. System administrators should prioritize updating affected kernel versions while maintaining awareness of similar memory management issues in other framebuffer drivers or kernel subsystems. The fix also serves as a reminder of the importance of thorough code review processes when modifying kernel APIs, particularly those involving resource ownership transfer patterns that require careful attention to memory lifecycle management.
This vulnerability exemplifies how seemingly small changes in kernel APIs can introduce subtle but significant issues across multiple driver implementations, emphasizing the need for comprehensive testing and validation when introducing modifications to core system components. The issue demonstrates the critical importance of maintaining consistency in resource management patterns throughout kernel codebases, where proper cleanup operations must be implemented for every allocation to prevent long-term system degradation.