CVE-2024-46738: VMCI: Fix use-after-free when removing resource in vmci_resource_remove()
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:
<TASK>
__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().
Security readout for executives and security teams
Plain-English summary
A Linux VMware VMCI resource-management flaw can leave the kernel referencing freed memory. A local, low-privileged user may be able to trigger memory corruption without user interaction, potentially affecting confidentiality, integrity, or availability. The supplied evidence does not establish real-world exploitation.
Executive priority
Treat as a high-priority kernel maintenance issue, especially for shared systems permitting untrusted local access. Schedule tested kernel updates promptly, but avoid declaring an incident solely from vulnerability presence because active exploitation is not evidenced.
Technical view
vmci_resource_remove() matched resources using context and resource identifiers but omitted resource type. Two differently typed resources could share a handle, causing removal of the wrong entry while the intended object was freed. The table then retained a dangling pointer, producing a kernel use-after-free. The fix includes resource type in the comparison.
Likely exposure
Exposure is most likely on systems running affected Linux kernels where VMware VMCI functionality is present and reachable by a local low-privileged user. The supplied version metadata spans releases from 3.9 through 6.11, but distribution backports may alter status. Confirm using the running kernel and vendor package guidance.
Exploitation context
CVSS 3.1 scores this 7.8: local access, low privileges, low complexity, and no user interaction, with potentially high confidentiality, integrity, and availability impact. It is not listed as KEV, and the supplied sources provide no evidence of active exploitation or a public weaponized exploit.
Researcher notes
The demonstrated failure is a KASAN-detected read-after-free during VMCI resource removal and later comparison. Root cause and patch direction are clear. Exact exploitability, reachable configurations, and affected distribution package boundaries are not fully established by the bundle; distribution backports require separate confirmation.
Mitigation direction
Upgrade to a distribution kernel containing the upstream stable fix for CVE-2024-46738.
Reboot into the updated kernel; installing a package alone does not replace the running kernel.
If upgrading is delayed, consult distribution guidance; the supplied sources name no supported workaround.
Prioritize exposed multi-user or workload-hosting systems where untrusted local users can reach VMCI functionality.
Validation and detection
Record the running kernel version and identify whether VMware VMCI drivers or interfaces are present.
Compare the installed package against distribution advisories and the referenced upstream stable commits.
After remediation, verify the system booted the intended fixed kernel.
Review kernel logs for VMCI-related crashes or memory-safety reports, while recognizing absence does not prove safety.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2024-46738 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.