CVE-2025-21977

published 2025-04-01

CVE-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…

Priority P4 22 medium 5.5 CVSS 3.1

AV L AC L PR L UI N S U C N I N A H

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
c25a19a

Affected

11 ranges

Vendor	Product	Version range	Fixed in
debian	linux	< linux 6.12.20-1 (forky)	linux 6.12.20-1 (forky)
linux	linux	—	—
linux	linux	>= c25a19afb81cfd73dab494ba64f9a434cf1a4499 < cfffe46a994ac6d5de3b119917680ea1e9a96125	cfffe46a994ac6d5de3b119917680ea1e9a96125
linux	linux	>= c25a19afb81cfd73dab494ba64f9a434cf1a4499 < 2924802d35e00a36b1503a4e786f1926b2fdc1d0	2924802d35e00a36b1503a4e786f1926b2fdc1d0
linux	linux	>= c25a19afb81cfd73dab494ba64f9a434cf1a4499 < 304386373007aaca9236a3f36afac0bbedcd2bf0	304386373007aaca9236a3f36afac0bbedcd2bf0
linux	linux_kernel	—	—
linux	linux_kernel	>= 0 < 6.12.20-1	6.12.20-1
linux	linux_kernel	>= 0 < 6.12.20-1	6.12.20-1
linux	linux_kernel	>= 0 < 6.8.0-84.84	6.8.0-84.84
linux	linux_kernel	>= 6.13 < 6.13.8	6.13.8
linux	linux_kernel	>= 6.8 < 6.12.20	6.12.20

CVSS provenance

nvd v3.1 5.5 MEDIUM CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

osv 5.9 MEDIUM

vendor_ubuntu 5.9 MEDIUM

vendor_debian 5.5 LOW

vendor_redhat 5.5 MEDIUM

Stop checking back — get the weekly exploitation signal.

Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.