CVE-2024-46738 in Linux
Summary
by MITRE • 09/18/2024
In the Linux kernel, the following vulnerability has been resolved:
VMCI: Fix use-after-free when removing resource in vmci_resource_remove()
When removing a resource from vmci_resource_table in vmci_resource_remove(), the search is performed using the resource handle by comparing context and resource fields.
It is possible though to create two resources with different types but same handle (same context and resource fields).
When trying to remove one of the resources, vmci_resource_remove() may not remove the intended one, but the object will still be freed as in the case of the datagram type in vmci_datagram_destroy_handle(). vmci_resource_table will still hold a pointer to this freed resource leading to a use-after-free vulnerability.
BUG: KASAN: use-after-free in vmci_handle_is_equal include/linux/vmw_vmci_defs.h:142 [inline]
BUG: KASAN: use-after-free in vmci_resource_remove+0x3a1/0x410 drivers/misc/vmw_vmci/vmci_resource.c:147 Read of size 4 at addr ffff88801c16d800 by task syz-executor197/1592 Call Trace: __dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x82/0xa9 lib/dump_stack.c:106 print_address_description.constprop.0+0x21/0x366 mm/kasan/report.c:239 __kasan_report.cold+0x7f/0x132 mm/kasan/report.c:425 kasan_report+0x38/0x51 mm/kasan/report.c:442 vmci_handle_is_equal include/linux/vmw_vmci_defs.h:142 [inline]
vmci_resource_remove+0x3a1/0x410 drivers/misc/vmw_vmci/vmci_resource.c:147 vmci_qp_broker_detach+0x89a/0x11b9 drivers/misc/vmw_vmci/vmci_queue_pair.c:2182 ctx_free_ctx+0x473/0xbe1 drivers/misc/vmw_vmci/vmci_context.c:444 kref_put include/linux/kref.h:65 [inline]
vmci_ctx_put drivers/misc/vmw_vmci/vmci_context.c:497 [inline]
vmci_ctx_destroy+0x170/0x1d6 drivers/misc/vmw_vmci/vmci_context.c:195 vmci_host_close+0x125/0x1ac drivers/misc/vmw_vmci/vmci_host.c:143 __fput+0x261/0xa34 fs/file_table.c:282 task_work_run+0xf0/0x194 kernel/task_work.c:164 tracehook_notify_resume include/linux/tracehook.h:189 [inline]
exit_to_user_mode_loop+0x184/0x189 kernel/entry/common.c:187 exit_to_user_mode_prepare+0x11b/0x123 kernel/entry/common.c:220 __syscall_exit_to_user_mode_work kernel/entry/common.c:302 [inline]
syscall_exit_to_user_mode+0x18/0x42 kernel/entry/common.c:313 do_syscall_64+0x41/0x85 arch/x86/entry/common.c:86 entry_SYSCALL_64_after_hwframe+0x6e/0x0
This change ensures the type is also checked when removing the resource from vmci_resource_table in vmci_resource_remove().
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 04/05/2026
The vulnerability identified as CVE-2024-46738 resides within the Linux kernel's VMware Virtual Machine Communication Interface (VMCI) subsystem, specifically in the vmci_resource_remove() function. This flaw manifests as a use-after-free condition that occurs during resource cleanup operations, presenting a significant security risk for systems utilizing VMCI. The vulnerability is classified under CWE-415 as an improper cleanup of memory resources, and it aligns with ATT&CK technique T1059.003 for execution through kernel-level code manipulation. The VMCI subsystem facilitates communication between virtual machines and host systems, making this vulnerability particularly concerning for virtualized environments where privilege escalation or system compromise could occur through kernel-level attacks.
The technical root cause of this vulnerability stems from insufficient resource identification during the removal process. When vmci_resource_remove() attempts to locate and remove a resource from vmci_resource_table, it relies solely on matching context and resource fields from the handle structure. However, the implementation permits the creation of multiple resources with identical handle values but different types, effectively creating a scenario where the removal function cannot distinguish between resources of different types that share the same handle. The function performs a search using vmci_handle_is_equal() which only compares context and resource fields, neglecting the resource type field that should serve as a crucial discriminator. This design flaw allows for a situation where the wrong resource gets removed, leading to premature deallocation of memory while the resource table continues to hold a pointer to the freed memory location, resulting in use-after-free conditions.
The operational impact of this vulnerability extends beyond simple memory corruption, potentially enabling privilege escalation and system instability. When a resource is freed inappropriately, subsequent access to that freed memory location triggers KASAN (Kernel Address Sanitizer) reports indicating use-after-free conditions. The call trace demonstrates how the vulnerability manifests during normal operation when a context is being destroyed and resources are being cleaned up, particularly during vmci_qp_broker_detach() operations. Attackers could exploit this by crafting specific resource creation sequences that result in the targeted resource being freed while the table still points to it, potentially allowing for data corruption, information disclosure, or even remote code execution in kernel space. The vulnerability affects systems running Linux kernels with VMCI support, particularly those in virtualized environments where VMCI is actively used for inter-VM or VM-to-host communication.
Mitigation strategies for this vulnerability require kernel-level patches that enhance the resource removal logic to include type checking during the search process in vmci_resource_remove(). The fix implemented ensures that resource type is verified alongside handle fields, preventing the scenario where different resource types with identical handles could lead to incorrect removal. Organizations should prioritize applying the latest kernel patches from their distribution vendors, as the fix directly addresses the core issue without requiring architectural changes. Additionally, system administrators should monitor for potential exploitation attempts through kernel memory access patterns and implement runtime protections such as kernel hardening features and memory protection mechanisms. The vulnerability highlights the importance of proper resource management in kernel space and reinforces the need for comprehensive testing of resource handling logic, particularly in subsystems that manage complex object lifecycles. System monitoring should include detection of KASAN reports and abnormal resource cleanup patterns that may indicate exploitation attempts.