CVE-2025-21977: Vulnerability in Linux Linux

Severity: mediumType: vulnerabilityCVE-2025-21977

In the Linux kernel, the following vulnerability has been resolved: fbdev: hyperv_fb: Fix hang in kdump kernel when on Hyper-V Gen 2 VMs Gen 2 Hyper-V VMs boot via EFI and have a standard EFI framebuffer device. When the kdump kernel runs in such a VM, loading the efifb driver may hang because of accessing the framebuffer at the wrong memory address. The scenario occurs when the hyperv_fb driver in the original kernel moves the framebuffer to a different MMIO address because of conflicts with an already-running efifb or simplefb driver. The hyperv_fb driver then informs Hyper-V of the change, which is allowed by the Hyper-V FB VMBus device protocol. However, when the kexec command loads the kdump kernel into crash memory via the kexec_file_load() system call, the system call doesn't know the framebuffer has moved, and it sets up the kdump screen_info using the original framebuffer address. The transition to the kdump kernel does not go through the Hyper-V host, so Hyper-V does not reset the framebuffer address like it would do on a reboot. When efifb tries to run, it accesses a non-existent framebuffer address, which traps to the Hyper-V host. After many such accesses, the Hyper-V host thinks the guest is being malicious, and throttles the guest to the point that it runs very slowly or appears to have hung. When the kdump kernel is loaded into crash memory via the kexec_load() system call, the problem does not occur. In this case, the kexec command builds the screen_info table itself in user space from data returned by the FBIOGET_FSCREENINFO ioctl against /dev/fb0, which gives it the new framebuffer location. This problem was originally reported in 2020 [1], resulting in commit 3cb73bc3fa2a ("hyperv_fb: Update screen_info after removing old framebuffer"). This commit solved the problem by setting orig_video_isVGA to 0, so the kdump kernel was unaware of the EFI framebuffer. The efifb driver did not try to load, and no hang occurred. But in 2024, commit c25a19afb81c ("fbdev/hyperv_fb: Do not clear global screen_info") effectively reverted 3cb73bc3fa2a. Commit c25a19afb81c has no reference to 3cb73bc3fa2a, so perhaps it was done without knowing the implications that were reported with 3cb73bc3fa2a. In any case, as of commit c25a19afb81c, the original problem came back again. Interestingly, the hyperv_drm driver does not have this problem because it never moves the framebuffer. The difference is that the hyperv_drm driver removes any conflicting framebuffers *before* allocating an MMIO address, while the hyperv_fb drivers removes conflicting framebuffers *after* allocating an MMIO address. With the "after" ordering, hyperv_fb may encounter a conflict and move the framebuffer to a different MMIO address. But the conflict is essentially bogus because it is removed a few lines of code later. Rather than fix the problem with the approach from 2020 in commit 3cb73bc3fa2a, instead slightly reorder the steps in hyperv_fb so conflicting framebuffers are removed before allocating an MMIO address. Then the default framebuffer MMIO address should always be available, and there's never any confusion about which framebuffer address the kdump kernel should use -- it's always the original address provided by the Hyper-V host. This approach is already used by the hyperv_drm driver, and is consistent with the usage guidelines at the head of the module with the function aperture_remove_conflicting_devices(). This approach also solves a related minor problem when kexec_load() is used to load the kdump kernel. With current code, unbinding and rebinding the hyperv_fb driver could result in the framebuffer moving back to the default framebuffer address, because on the rebind there are no conflicts. If such a move is done after the kdump kernel is loaded with the new framebuffer address, at kdump time it could again have the wrong address. This problem and fix are described in terms of the kdump kernel, but it can also occur ---truncated---

AI Analysis

Technical Summary

CVE-2025-21977 is a vulnerability in the Linux kernel's framebuffer device driver for Hyper-V virtual machines, specifically affecting the hyperv_fb driver on Generation 2 (Gen 2) Hyper-V VMs that boot via EFI and use a standard EFI framebuffer device. The issue arises during the operation of the kdump kernel, which is used for crash dumping. When the hyperv_fb driver detects a conflict with an existing efifb or simplefb framebuffer driver, it moves the framebuffer to a different MMIO (Memory-Mapped I/O) address and informs the Hyper-V host of this change. However, when the kdump kernel is loaded into crash memory using the kexec_file_load() system call, it does not recognize the new framebuffer address and instead uses the original one. Since the kdump kernel boots without going through the Hyper-V host, the host does not reset the framebuffer address as it would during a normal reboot. Consequently, the efifb driver attempts to access a non-existent framebuffer address, causing traps to the Hyper-V host. After repeated accesses, the Hyper-V host interprets this behavior as malicious and throttles the guest VM, leading to severe performance degradation or a system hang. This problem was initially reported in 2020 and temporarily fixed by commit 3cb73bc3fa2a, which prevented the efifb driver from loading by setting orig_video_isVGA to 0. However, a later commit in 2024 (c25a19afb81c) inadvertently reverted this fix, reintroducing the issue. The hyperv_drm driver does not suffer from this problem because it removes conflicting framebuffers before allocating an MMIO address, unlike hyperv_fb which does so afterward, causing the conflict and subsequent framebuffer move. The proposed fix involves reordering the steps in the hyperv_fb driver to remove conflicting framebuffers before allocating an MMIO address, ensuring the framebuffer remains at the original address provided by the Hyper-V host. This approach aligns with the hyperv_drm driver’s behavior and prevents confusion about the framebuffer address during kdump kernel loading. Additionally, it addresses a related issue where unbinding and rebinding the hyperv_fb driver could cause the framebuffer to move back to the default address after the kdump kernel has been loaded, potentially causing the same problem during crash dump operations. This vulnerability primarily affects Linux kernels that include the problematic commit c25a19afb81c and impacts systems running Gen 2 Hyper-V VMs with EFI boot and framebuffer devices. While it does not directly lead to code execution or data corruption, it causes system hangs or severe slowdowns during crash dump operations, which can impede incident response and system recovery.

Potential Impact

For European organizations, especially those relying on Linux-based virtual machines hosted on Microsoft Hyper-V infrastructure, this vulnerability can cause significant operational disruptions during system crashes. The inability to properly execute kdump kernels due to framebuffer address mismanagement can lead to system hangs or severe performance degradation, delaying crash analysis and recovery efforts. This is particularly critical for enterprises with high availability requirements, such as financial institutions, healthcare providers, and critical infrastructure operators, where downtime can have severe financial and regulatory consequences. Additionally, the throttling behavior by the Hyper-V host may be misinterpreted as malicious activity, potentially triggering false alarms or automated defensive responses. While the vulnerability does not appear to allow direct exploitation for privilege escalation or data breach, the denial-of-service-like impact during crash dump scenarios can hinder forensic investigations and prolong system outages, increasing the risk exposure window.

Mitigation Recommendations

European organizations should prioritize updating their Linux kernels to versions that include the fix for CVE-2025-21977, specifically ensuring that the hyperv_fb driver removes conflicting framebuffers before allocating MMIO addresses. Until patches are applied, administrators should consider the following mitigations: 1. Prefer using the kexec_load() system call over kexec_file_load() for loading kdump kernels, as the former correctly handles the framebuffer address. 2. Avoid unbinding and rebinding the hyperv_fb driver on running systems to prevent framebuffer address changes that could cause kdump failures. 3. Monitor Hyper-V host logs for signs of guest throttling or traps related to framebuffer access, which may indicate attempts to trigger this issue. 4. For critical systems, consider using the hyperv_drm driver instead of hyperv_fb if feasible, as it does not exhibit this problem. 5. Test kdump functionality in controlled environments after kernel updates to ensure crash dump reliability. 6. Coordinate with Hyper-V infrastructure teams to understand host-level mitigations or monitoring that can detect or prevent guest throttling due to framebuffer access anomalies. Implementing these steps will reduce the risk of system hangs during crash dumps and improve incident response capabilities.