LiveActive security incident?Get immediate response
CVE Record

CVE-2023-53647: Drivers: hv: vmbus: Don't dereference ACPI root object handle

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]

UnknownCVSS not scoredNot KEV-listedUpdated
Discuss exposureBack to CVEs
Glexia's TakeAutomated analysismoderate

Security readout for executives and security teams

Plain-English summary

This is a Linux kernel boot-time crash in Hyper-V VMBus handling. In specific virtual machine setups, Linux can dereference an invalid ACPI root object while looking for Hyper-V MMIO ranges, causing a kernel oops during boot. The sources describe availability impact, not data theft or code execution.

Executive priority

Prioritize for virtualized Linux fleets where boot reliability matters, especially custom KVM/QEMU or VMBus environments. It is not supported by the provided sources as actively exploited or confidentiality-impacting. Patch through normal kernel maintenance unless affected systems are failing to boot.

Technical view

The hv_vmbus driver walks ACPI ancestors from the VMBus ACPI device to find Hyper-V MMIO ranges. If none exist, it can attempt resource walking on the ACPI namespace root object, whose all-ones handle leads to a NULL pointer dereference in ACPI code. The fix stops lookup at the ACPI root.

Likely exposure

Exposure appears limited to Linux guests using the Hyper-V VMBus path on host implementations that do not publish Hyper-V MMIO ranges. QEMU VMBus is named as an example. The source notes KVM/QEMU guests do not use Hyper-V paravirtualization by default unless KVM PV is missing or disabled.

Exploitation context

The bundle does not show active exploitation, KEV listing, exploit code, or remote attacker requirements. The documented trigger is an incompatible or incomplete virtualized VMBus/ACPI environment causing boot oops. Treat this mainly as a virtualization availability risk unless vendor advisories state otherwise.

Researcher notes

Key constraints are environmental: VMBus ACPI device ancestry, absence of Hyper-V MMIO ranges, and Linux choosing the Hyper-V PV path. The CVE data lacks CVSS, CWE, and precise distro package mapping. Validate against upstream stable commits and downstream vendor advisories before declaring fleet impact.

Mitigation direction

  • Apply Linux kernel updates containing the referenced stable hv_vmbus fix.
  • Check distribution advisories for backported fixes and affected kernel packages.
  • Avoid non-default Hyper-V PV usage on KVM/QEMU unless operationally required.
  • Test boot behavior after patching affected virtual machine images.

Validation and detection

  • Inventory Linux guests using hv_vmbus or Hyper-V paravirtual interfaces.
  • Confirm whether KVM PV is disabled or unavailable on QEMU/KVM guests.
  • Compare running kernels with vendor-fixed builds or referenced stable commits.
  • Review boot logs for hv_vmbus, ACPI, or NULL pointer oops traces.
Prepared
Confidence
medium
Sources
6

Public sources used

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-2023-53647 mapping review

Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.

Open ATT&CK lookup
Vulnerability profileCVE Program record
Severity
Unknown
CVSS
Not scored
Known Exploited
No
Published
Official CVE source material

CNA and ADP enrichment extracted from CVE v5

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.

0CVSS vectors
3Timeline events
0ADP providers
5Source links

Vulnerability timeline

Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.

  1. CVE reservedCVE Program

    The CVE ID was reserved by the assigning CNA.

  2. CVE publishedCVE Program

    The CVE record was published.

  3. CVE updatedCVE Program

    The CVE record metadata indicates this as the latest update time.

Source materials

Affected products

Products and packages named in the record

VendorProductVersion / packageStatus
LinuxLinux7f163a6fd957a85f7f66a129db1ad243a44399ee, 7f163a6fd957a85f7f66a129db1ad243a44399ee, 7f163a6fd957a85f7f66a129db1ad243a44399ee, 7f163a6fd957a85f7f66a129db1ad243a44399eeunaffected
LinuxLinux4.3, 0, 6.1.53, 6.4.16, 6.5.3, 6.6affected
Weakness

CWE details

No CWE listed

CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.