CVE-2023-53647
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2025-10-07

Last updated on: 2026-02-03

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: Drivers: hv: vmbus: Don't dereference ACPI root object handle Since the commit referenced in the Fixes: tag below the VMBus client driver is walking the ACPI namespace up from the VMBus ACPI device to the ACPI namespace root object trying to find Hyper-V MMIO ranges. However, if it is not able to find them it ends trying to walk resources of the ACPI namespace root object itself. This object has all-ones handle, which causes a NULL pointer dereference in the ACPI code (from dereferencing this pointer with an offset). This in turn causes an oops on boot with VMBus host implementations that do not provide Hyper-V MMIO ranges in their VMBus ACPI device or its ancestors. The QEMU VMBus implementation is an example of such implementation. I guess providing these ranges is optional, since all tested Windows versions seem to be able to use VMBus devices without them. Fix this by explicitly terminating the lookup at the ACPI namespace root object. Note that Linux guests under KVM/QEMU do not use the Hyper-V PV interface by default - they only do so if the KVM PV interface is missing or disabled. Example stack trace of such oops: [ 3.710827] ? __die+0x1f/0x60 [ 3.715030] ? page_fault_oops+0x159/0x460 [ 3.716008] ? exc_page_fault+0x73/0x170 [ 3.716959] ? asm_exc_page_fault+0x22/0x30 [ 3.717957] ? acpi_ns_lookup+0x7a/0x4b0 [ 3.718898] ? acpi_ns_internalize_name+0x79/0xc0 [ 3.720018] acpi_ns_get_node_unlocked+0xb5/0xe0 [ 3.721120] ? acpi_ns_check_object_type+0xfe/0x200 [ 3.722285] ? acpi_rs_convert_aml_to_resource+0x37/0x6e0 [ 3.723559] ? down_timeout+0x3a/0x60 [ 3.724455] ? acpi_ns_get_node+0x3a/0x60 [ 3.725412] acpi_ns_get_node+0x3a/0x60 [ 3.726335] acpi_ns_evaluate+0x1c3/0x2c0 [ 3.727295] acpi_ut_evaluate_object+0x64/0x1b0 [ 3.728400] acpi_rs_get_method_data+0x2b/0x70 [ 3.729476] ? vmbus_platform_driver_probe+0x1d0/0x1d0 [hv_vmbus] [ 3.730940] ? vmbus_platform_driver_probe+0x1d0/0x1d0 [hv_vmbus] [ 3.732411] acpi_walk_resources+0x78/0xd0 [ 3.733398] vmbus_platform_driver_probe+0x9f/0x1d0 [hv_vmbus] [ 3.734802] platform_probe+0x3d/0x90 [ 3.735684] really_probe+0x19b/0x400 [ 3.736570] ? __device_attach_driver+0x100/0x100 [ 3.737697] __driver_probe_device+0x78/0x160 [ 3.738746] driver_probe_device+0x1f/0x90 [ 3.739743] __driver_attach+0xc2/0x1b0 [ 3.740671] bus_for_each_dev+0x70/0xc0 [ 3.741601] bus_add_driver+0x10e/0x210 [ 3.742527] driver_register+0x55/0xf0 [ 3.744412] ? 0xffffffffc039a000 [ 3.745207] hv_acpi_init+0x3c/0x1000 [hv_vmbus]
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-10-07
Last Modified
2026-02-03
Generated
2026-05-07
AI Q&A
2025-10-07
EPSS Evaluated
2026-05-05
NVD
CVE-2023-53647
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel From 5.15.160 (inc) to 5.16 (inc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-476 The product dereferences a pointer that it expects to be valid but is NULL.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability occurs in the Linux kernel's hv_vmbus driver when it tries to walk the ACPI namespace from the VMBus ACPI device up to the ACPI namespace root object to find Hyper-V MMIO ranges. If these ranges are not found, the driver ends up walking the resources of the ACPI namespace root object itself, which has an all-ones handle. Dereferencing this handle causes a NULL pointer dereference in the ACPI code, leading to a kernel oops (crash) during boot on certain VMBus host implementations that do not provide Hyper-V MMIO ranges, such as QEMU's VMBus implementation. The fix involves stopping the lookup explicitly at the ACPI namespace root object to prevent this dereference.


How can this vulnerability impact me? :

This vulnerability can cause the Linux kernel to crash (kernel oops) during system boot when running on virtualized environments using VMBus host implementations that do not provide Hyper-V MMIO ranges, such as QEMU. This can lead to system instability or failure to boot properly in affected configurations.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability manifests as a NULL pointer dereference in the ACPI code causing a kernel oops during boot on systems using the VMBus client driver without Hyper-V MMIO ranges. Detection involves checking system boot logs for oops messages related to hv_vmbus or ACPI namespace errors. You can use commands like 'dmesg | grep -i vmbus' or 'journalctl -k | grep -i acpi' to look for relevant error messages indicating the issue.


What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation involves applying the Linux kernel update that includes the fix which prevents dereferencing the ACPI root object handle by terminating the lookup explicitly at the ACPI namespace root object. Until patched, avoid running Linux guests under KVM/QEMU with the VMBus client driver enabled if the host does not provide Hyper-V MMIO ranges, or disable the Hyper-V PV interface if possible.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart