CVE-2022-49830 in Linux
Summary
by MITRE • 05/01/2025
In the Linux kernel, the following vulnerability has been resolved:
drm/drv: Fix potential memory leak in drm_dev_init()
drm_dev_init() will add drm_dev_init_release() as a callback. When drmm_add_action() failed, the release function won't be added. As the result, the ref cnt added by device_get() in drm_dev_init() won't be put by drm_dev_init_release(), which leads to the memleak. Use drmm_add_action_or_reset() instead of drmm_add_action() to prevent memleak.
unreferenced object 0xffff88810bc0c800 (size 2048): comm "modprobe", pid 8322, jiffies 4305809845 (age 15.292s) hex dump (first 32 bytes): e8 cc c0 0b 81 88 ff ff ff ff ff ff 00 00 00 00 ................ 20 24 3c 0c 81 88 ff ff 18 c8 c0 0b 81 88 ff ff $<............. backtrace: [<000000007251f72d>] __kmalloc+0x4b/0x1c0
[<0000000045f21f26>] platform_device_alloc+0x2d/0xe0
[<000000004452a479>] platform_device_register_full+0x24/0x1c0
[<0000000089f4ea61>] 0xffffffffa0736051
[<00000000235b2441>] do_one_initcall+0x7a/0x380
[<0000000001a4a177>] do_init_module+0x5c/0x230
[<000000002bf8a8e2>] load_module+0x227d/0x2420
[<00000000637d6d0a>] __do_sys_finit_module+0xd5/0x140
[<00000000c99fc324>] do_syscall_64+0x3f/0x90
[<000000004d85aa77>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 12/19/2025
The vulnerability described in CVE-2022-49830 represents a memory leak within the Linux kernel's Direct Rendering Manager (DRM) subsystem, specifically affecting the drm_dev_init() function. This issue occurs during device initialization processes where the kernel attempts to manage reference counting and resource cleanup for graphics device drivers. The flaw stems from improper handling of cleanup callbacks when memory allocation operations fail, creating a scenario where allocated resources remain unreleased even though the initialization process has encountered an error condition.
The technical implementation of this vulnerability involves the drm_dev_init() function which internally uses device_get() to increment a reference counter for the device structure. When drmm_add_action() fails to register the cleanup callback drm_dev_init_release(), the reference counter that was incremented by device_get() is never decremented by the release function. This creates a memory leak where the allocated device structure remains in memory indefinitely, preventing proper resource recycling. The kernel's reference counting mechanism relies on proper pairing of increment and decrement operations to ensure memory safety, and this failure breaks that fundamental contract.
From an operational perspective, this vulnerability creates persistent memory leaks that can accumulate over time, particularly in systems that frequently load and unload graphics drivers or perform dynamic device initialization. The leak manifests as unreferenced objects in kernel memory, with the specific example showing a 2048-byte allocation that remains unreleased for over 15 seconds. Such memory leaks can eventually lead to system performance degradation, increased memory pressure, and in extreme cases, system instability or resource exhaustion. The vulnerability is particularly concerning in embedded systems or server environments where long-running processes and frequent driver operations are common.
The fix for this vulnerability involves replacing the drmm_add_action() call with drmm_add_action_or_reset() which provides proper error handling and ensures that cleanup operations are always registered or appropriately reset in case of failures. This change aligns with best practices for kernel memory management and follows the principle of defensive programming where error conditions are properly handled to prevent resource leaks. The vulnerability demonstrates the importance of proper resource management in kernel space, where even seemingly small oversights in callback registration can lead to significant memory consumption issues. This type of vulnerability would typically be classified under CWE-401 as "Improper Release of Memory" and could be categorized under ATT&CK technique T1490 for "Inhibit System Recovery" due to its potential impact on system stability through resource exhaustion. The affected code path through platform_device_alloc and module loading operations indicates that this vulnerability could be triggered during normal system operations when graphics drivers are loaded or unloaded, making it a persistent threat to system memory integrity.