CVE-2024-36910: Linux Kernel Memory Free Bug in uio_hv_generic Fixed

A subtle memory-management oversight in the Linux kernel’s Hyper‑V UIO driver has been cataloged as CVE‑2024‑36910: a condition where decrypted pages can be incorrectly freed when re‑encryption or decryption calls fail, creating a tangible availability and confidentiality risk for Confidential Computing (CoCo) virtual machines and any environments that rely on the uio_hv_generic driver. The bug has been fixed in upstream kernels, and major distributors have issued advisories and patches — but the vulnerability’s combination of low trigger complexity and direct interaction with memory encryption semantics means operators should act promptly to assess exposure and apply updates.

Background​

The issue revolves around the Linux kernel component uio_hv_generic, which implements Userspace I/O (UIO) support for Hyper‑V’s VMBus devices. UIO presents kernel-managed device memory to userspace processes and is commonly used by lightweight drivers and device testing stacks. In Confidential Computing scenarios (so‑called CoCo VMs), the platform and guest coordinate to encrypt and decrypt memory pages at runtime; kernel helpers such as set_memory_encrypted() and set_memory_decrypted() perform the necessary page attribute changes. If those helpers fail or return errors, callers must not treat the pages as safely decrypted and must not hand them back to the allocator in a way that would expose or corrupt shared memory state. The uio_hv_generic driver included a code path that could free pages even when decryption failed, returning decrypted/shared memory to the page allocator. This is what CVE‑2024‑36910 corrects.
Why this matters: freeing or returning incorrectly‑marked pages can lead to two practical classes of harm. First, from an availability standpoint, returning shared pages to the allocator or double‑freeing memory can quickly destabilize the kernel, producing crashes, hung devices, or sustained denial‑of‑service (DoS) conditions for workloads that depend on the Hyper‑V device paths. Second, from a confidentiality perspective, pages that should remain encrypted or isolated could be mapped in different contexts, exposing plaintext content to untrusted actors or other guests if the memory becomes shared inadvertently. The CVSS vector assigned by multiple analysts reflects this dual concern: the primary impact is availability, but there are clear confidentiality implications as well.

---

What the public advisories say​

• The National Vulnerability Database (NVD) summarizes the root cause succinctly: callers must handle errors from set_memory_encrypted() / set_memory_decrypted() correctly to avoid returning decrypted (shared) memory to the page allocator; the VMBus UIO driver could free decrypted/shared pages if set_memory_decrypted() fails. This summary matches the upstream kernel discussion and vendor notes.
• Vendor and distribution advisories track the same fix: the uio_hv_generic driver now checks the decrypted field in the vmbus gpadl (guest physical address descriptor list) before freeing pages, ensuring pages are only freed in the correct state. This is the functional change shipped in the upstream patches.
• Amazon Linux and other distributors rolled CVE‑2024‑36910 into broader kernel backports and advisories; Amazon’s ALAS advisory includes CVE‑2024‑36910 as resolved in their published kernel updates, while other distros classified the issue as moderate to medium severity with a CVSSv3 base score around 6.2. These vendor blurbs confirm both the vulnerability and the applied remediation strategy.
• Independent vulnerability trackers and research‑facing databases (Rapid7, Wiz, Feedly, etc.) echo the technical description and note that no public proof‑of‑concept exploit was known at disclosure time. Those resources also link to the kernel commits that implement the defensive checks.

---

Technical analysis: root cause and fix​

How the bug triggers​

At a high level, the problem occurs when the untrusted host can provoke a failure in the memory state change helpers used by the guest kernel — specifically set_memory_encrypted() and set_memory_decrypted(). When those helpers fail, the kernel must treat the affected pages as still shared or encrypted. The uio_hv_generic path mistakenly proceeded to free some pages despite the failure, because it did not consult the GPADL (guest physical address descriptor list) entry’s decrypted flag to confirm the page’s final state. The result: memory that should not have been freed (or should not have been considered safe to hand back to the allocator as plaintext) was returned to the general pool, creating the possibility of reuse, corruption, or cross‑context disclosure.

Upstream patch and mitigation approach​

The upstream fix is surgical: before freeing pages, the driver now checks the GPADL’s decrypted bit to ensure only pages that were truly decrypted (and safe to free) are returned to the allocator. If set_memory_decrypted() fails, the code path avoids freeing the page or otherwise ensures the page remains correctly tracked as shared/encrypted. This change prevents the incorrect return/free path and eliminates the window in which the allocator could recycle sensitive pages. The kernel commits referenced in public trackers are precise and minimal, illustrating defensive coding in a low‑level I/O path rather than a heavy redesign.

Why checking the GPADL matters​

GPADL entries describe guest memory regions and include state flags (such as decrypted) that are authoritative for whether a page may be treated as plaintext within the guest. If the driver relies on local, transient assumptions about page state without rechecking the GPADL after an operation that can fail, the driver creates a time‑of‑check / time‑of‑use (TOC/TOU) mismatch. The fix eliminates that mismatch by using the canonical GPADL flag as the single source of truth for whether a page is freeable.

---

Affected environments and vendor responses​

• Affected component: Linux kernel — uio_hv_generic (UIO driver for Hyper‑V VMBus devices). The vulnerability is kernel‑level and therefore affects any product or distribution that includes a vulnerable kernel tree.
• Typical exposure scenarios:
• Confidential Computing VMs (CoCo VMs) where the host participates in page re‑encryption/decryption semantics.
• Any virtualised environment using Hyper‑V VMBus with UIO devices exposed to userspace drivers that rely on uio_hv_generic semantics.
• Cloud images and vendor kernels that include the vulnerable codepath (distributors have published CPE ranges for affected kernel versions).
• Vendor action: distributions that track the upstream kernel have backported the patch or issued fixed kernel packages. Amazon Linux’s ALAS advisory lists CVE‑2024‑36910 among resolved issues in the relevant kernel packages; SUSE and other major maintainers also classified the issue as resolved and provided updates with the defensive check. Operators must check their vendor’s advisory feed and apply the appropriate kernel update or backport.
• Exploit status: as of public advisories and common vulnerability trackers at disclosure, there is no known public exploit or evidence of active exploitation. That said, the vulnerability’s semantics (memory handling error with potential to affect availability and confidentiality) make it high‑value to attackers with local presence; therefore absence of proof is not the same as absence of risk.

---

Practical risk assessment​

Likely impact​

• Availability (primary): The most immediate operational risk is a denial‑of‑service condition. If the allocator sees inconsistent page ownership or if freed pages are reused improperly, kernel panics, oops messages, stuck device paths, or service crashes can occur. The real‑world effect can be sustained (attacker keeps triggering the condition) or persistent (state corruption requires reboot or manual remediation). This is consistent with kernel memory‑management vulnerabilities that mishandle page state.
• Confidentiality (secondary but real): In CoCo environments, memory encryption is intended to provide strong confidentiality guarantees. If decrypted pages are inadvertently recycled or mapped where they shouldn’t be, plaintext data leakage between contexts is possible. The vulnerability description explicitly identifies the risk of returning decrypted/shared memory to the allocator as a confidentiality problem.
• Exploit complexity: The flaw requires the attacker to be able to cause set_memory_encrypted()/set_memory_decrypted() to fail — most practical in CoCo VM setups where an untrusted host can manipulate the encryption state or in local scenarios where privileged host interactions occur. It is not a remote, unauthenticated kernel exploit. The CVSS vector reflects a lower attack surface but a meaningful impact if local access is available.

Threat actor profile​

• Local attackers or malicious guests with some level of host interaction or the ability to influence VMBus behavior are the most realistic threat actors. For cloud operators, this maps to a risk model where a malicious tenant co‑resides on a host or an untrusted host component can manufacture error conditions. For on‑premises operators, the attacker would usually need local guest privileges or misconfigured host/guest stacks.

---

Recommended mitigation and remediation steps​

If you manage Linux hosts, virtual machines, or cloud images that rely on Hyper‑V/VMbus features, take the following actions immediately:

• Inventory: Identify hosts and VM images running vulnerable kernel versions. Use your configuration management tools to list installed kernels and map them to the vendor CPE ranges for CVE‑2024‑36910. Vendor advisories and the NVD entry provide version ranges to check.
• Patch: Apply vendor kernel updates or upstream backports that include the uio_hv_generic fix. For managed cloud images, use provider images that include the patched kernel. Distributors that published advisories (ALAS, SUSE, Ubuntu, etc.) have fixed packages — prioritize those updates for Confidential Computing hosts and any systems exposing UIO HV devices.
• Compensating controls (when immediate patching is not possible):
• Disable uio_hv_generic or unload UIO HV modules on systems that do not require the device, reducing the attack surface.
• Restrict local administrative access to guests and hosts to prevent untrusted actors from manipulating memory encryption state.
• For cloud operators, ensure strict tenant isolation and validate host platform components that perform memory encryption operations.
• Monitor kernel logs and OOPS/crash reports for symptoms such as repeated memory allocation failures or device‑specific panics that coincide with UIO activity.
• Testing and staged rollout: Because kernel updates touch many subsystems, roll patches through a staged testing pipeline — prioritize CoCo hosts and production systems with Hyper‑V VMBus device usage. Validate workloads under stress to confirm that the GPADL state transitions behave correctly after patching (no unexpected oopses, no degraded device behavior).
• Incident readiness: If you suspect exploitation or unexplained memory corruption, capture kernel oops logs, enable panic on oops (if safe for your environment) and gather memory dumps for forensic analysis. Consult vendor support for deep diagnostics if you observe persistent instability after patching.

---

Operational guidance for cloud and CoCo deployments​

Confidential Computing environments place special emphasis on host/guest contracts for memory encryption. This vulnerability underscores two operational realities:

• Trust boundaries are as strong as the code that mediates them. When memory encryption state transitions are mediated through kernel helpers and device drivers, even small defects can break the confidentiality and integrity guarantees that CoCo promises to provide. Cloud operators must prioritize patches that affect those mediation paths.
• Rapid, measurable testing is essential. For providers offering CoCo VMs or customers running CoCo images, include microbenchmarks and stress tests that exercise set_memory_encrypted()/set_memory_decrypted() semantics and the VMBus UIO paths. Doing so before pushing updates to production reduces the risk of discovery of latent bugs in vendor kernels under production loads.

---

Cross‑verification and evidence​

Multiple independent sources confirm the technical details, the existence of a fix, and the risk posture:

• The NVD entry provides the canonical vulnerability description and scoring context.
• Distribution advisories (for example, SUSE and Amazon Linux ALAS) list CVE‑2024‑36910 in their resolved issue sets and indicate that fixed packages or patches are available.
• Vulnerability aggregators and research databases (Rapid7, Wiz, cvefeed) cross‑link to the upstream kernel commits that implement the GPADL check and summarize the patch rationale, giving operators quick references to the exact code changes. Those trackers also note the lack of known weaponized exploits at disclosure time while flagging the availability and confidentiality risk.

Where public evidence is lacking — notably, demonstrable in‑the‑wild exploitation — we flag that absence as important but not exculpatory. The vulnerability is local‑attackable and affects a kernel memory path; those qualities elevate its operational impact even if no exploit headlines exist.

---

Developer and upstream takeaways​

• Defensive checks matter in low‑level code: The fix is a useful reminder that state flags and authoritative structures (such as GPADL entries) are the correct source of truth after operations that can fail. Relying on transient assumptions invites TOC/TOU bugs.
• Regression risk is manageable when patches are surgical: The kernel commits for this CVE are small and focused, limiting regression surface. Still, maintainers and vendors should include CI tests that emulate failed encryption state transitions to prevent similar regressions in the future.
• Supply‑chain awareness: Distributors that ship kernels must map and track such fixes across their backport trees. Operators should consume vendor advisories rather than guessing patch status from upstream alone. The ALAS advisory demonstrates how vendor CVE tracking can be used to determine whether a given cloud image includes the remediation.

---

Summary and final recommendations​

CVE‑2024‑36910 is a clear example of how even modest‑sounding kernel defects — failing to check a decrypted flag before freeing a page — can have outsized operational consequences in modern, virtualized environments. The vulnerability concerns the uio_hv_generic driver’s handling of decrypted/shared pages and has been corrected upstream by checking GPADL state before freeing memory; major distributions have released patches or advisories addressing the issue. Administrators should:

• Immediately inventory and prioritize systems that run vulnerable kernels, particularly Confidential Computing (CoCo) hosts and any environment where Hyper‑V VMBus UIO devices are used.
• Apply vendor kernel updates or upstream backports that include the uio_hv_generic GPADL check. If updates cannot be applied immediately, apply compensating controls such as unloading the module or restricting access to affected functionality.
• Monitor for kernel oopses, repeated memory allocation failures, or device instability; preserve logs and crash dumps if you suspect the issue has been triggered.
• For cloud and CoCo environments, add targeted tests that exercise memory encryption/decryption transitions and VMBus UIO behavior to your CI pipelines to detect regressions or missing patches early.

The community’s patch shows that a small, focused change can eliminate a class of memory‑state errors; what remains necessary is deliberate operational follow‑through. Apply the available fixes, audit exposed systems, and treat memory‑handling bugs with the urgency they deserve — the cost of inaction can be both service outage and, in CoCo contexts, erosion of the confidentiality guarantees operators promise.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center