CVE-2025-21977 (GCVE-0-2025-21977)
Vulnerability from cvelistv5
Published
2025-04-01 15:47
Modified
2025-05-04 07:26
Severity ?
VLAI Severity ?
EPSS score ?
Summary
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---
References
Impacted products
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/video/fbdev/hyperv_fb.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "cfffe46a994ac6d5de3b119917680ea1e9a96125",
"status": "affected",
"version": "c25a19afb81cfd73dab494ba64f9a434cf1a4499",
"versionType": "git"
},
{
"lessThan": "2924802d35e00a36b1503a4e786f1926b2fdc1d0",
"status": "affected",
"version": "c25a19afb81cfd73dab494ba64f9a434cf1a4499",
"versionType": "git"
},
{
"lessThan": "304386373007aaca9236a3f36afac0bbedcd2bf0",
"status": "affected",
"version": "c25a19afb81cfd73dab494ba64f9a434cf1a4499",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/video/fbdev/hyperv_fb.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "6.8"
},
{
"lessThan": "6.8",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.20",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.13.*",
"status": "unaffected",
"version": "6.13.8",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.14",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.20",
"versionStartIncluding": "6.8",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.13.8",
"versionStartIncluding": "6.8",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.14",
"versionStartIncluding": "6.8",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: hyperv_fb: Fix hang in kdump kernel when on Hyper-V Gen 2 VMs\n\nGen 2 Hyper-V VMs boot via EFI and have a standard EFI framebuffer\ndevice. When the kdump kernel runs in such a VM, loading the efifb\ndriver may hang because of accessing the framebuffer at the wrong\nmemory address.\n\nThe scenario occurs when the hyperv_fb driver in the original kernel\nmoves the framebuffer to a different MMIO address because of conflicts\nwith an already-running efifb or simplefb driver. The hyperv_fb driver\nthen informs Hyper-V of the change, which is allowed by the Hyper-V FB\nVMBus device protocol. However, when the kexec command loads the kdump\nkernel into crash memory via the kexec_file_load() system call, the\nsystem call doesn\u0027t know the framebuffer has moved, and it sets up the\nkdump screen_info using the original framebuffer address. The transition\nto the kdump kernel does not go through the Hyper-V host, so Hyper-V\ndoes not reset the framebuffer address like it would do on a reboot.\nWhen efifb tries to run, it accesses a non-existent framebuffer\naddress, which traps to the Hyper-V host. After many such accesses,\nthe Hyper-V host thinks the guest is being malicious, and throttles\nthe guest to the point that it runs very slowly or appears to have hung.\n\nWhen the kdump kernel is loaded into crash memory via the kexec_load()\nsystem call, the problem does not occur. In this case, the kexec command\nbuilds the screen_info table itself in user space from data returned\nby the FBIOGET_FSCREENINFO ioctl against /dev/fb0, which gives it the\nnew framebuffer location.\n\nThis problem was originally reported in 2020 [1], resulting in commit\n3cb73bc3fa2a (\"hyperv_fb: Update screen_info after removing old\nframebuffer\"). This commit solved the problem by setting orig_video_isVGA\nto 0, so the kdump kernel was unaware of the EFI framebuffer. The efifb\ndriver did not try to load, and no hang occurred. But in 2024, commit\nc25a19afb81c (\"fbdev/hyperv_fb: Do not clear global screen_info\")\neffectively reverted 3cb73bc3fa2a. Commit c25a19afb81c has no reference\nto 3cb73bc3fa2a, so perhaps it was done without knowing the implications\nthat were reported with 3cb73bc3fa2a. In any case, as of commit\nc25a19afb81c, the original problem came back again.\n\nInterestingly, the hyperv_drm driver does not have this problem because\nit never moves the framebuffer. The difference is that the hyperv_drm\ndriver removes any conflicting framebuffers *before* allocating an MMIO\naddress, while the hyperv_fb drivers removes conflicting framebuffers\n*after* allocating an MMIO address. With the \"after\" ordering, hyperv_fb\nmay encounter a conflict and move the framebuffer to a different MMIO\naddress. But the conflict is essentially bogus because it is removed\na few lines of code later.\n\nRather than fix the problem with the approach from 2020 in commit\n3cb73bc3fa2a, instead slightly reorder the steps in hyperv_fb so\nconflicting framebuffers are removed before allocating an MMIO address.\nThen the default framebuffer MMIO address should always be available, and\nthere\u0027s never any confusion about which framebuffer address the kdump\nkernel should use -- it\u0027s always the original address provided by\nthe Hyper-V host. This approach is already used by the hyperv_drm\ndriver, and is consistent with the usage guidelines at the head of\nthe module with the function aperture_remove_conflicting_devices().\n\nThis approach also solves a related minor problem when kexec_load()\nis used to load the kdump kernel. With current code, unbinding and\nrebinding the hyperv_fb driver could result in the framebuffer moving\nback to the default framebuffer address, because on the rebind there\nare no conflicts. If such a move is done after the kdump kernel is\nloaded with the new framebuffer address, at kdump time it could again\nhave the wrong address.\n\nThis problem and fix are described in terms of the kdump kernel, but\nit can also occur\n---truncated---"
}
],
"providerMetadata": {
"dateUpdated": "2025-05-04T07:26:26.566Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/cfffe46a994ac6d5de3b119917680ea1e9a96125"
},
{
"url": "https://git.kernel.org/stable/c/2924802d35e00a36b1503a4e786f1926b2fdc1d0"
},
{
"url": "https://git.kernel.org/stable/c/304386373007aaca9236a3f36afac0bbedcd2bf0"
}
],
"title": "fbdev: hyperv_fb: Fix hang in kdump kernel when on Hyper-V Gen 2 VMs",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2025-21977",
"datePublished": "2025-04-01T15:47:07.642Z",
"dateReserved": "2024-12-29T08:45:45.798Z",
"dateUpdated": "2025-05-04T07:26:26.566Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1",
"vulnerability-lookup:meta": {
"nvd": "{\"cve\":{\"id\":\"CVE-2025-21977\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2025-04-01T16:15:29.077\",\"lastModified\":\"2025-04-01T20:26:01.990\",\"vulnStatus\":\"Awaiting Analysis\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nfbdev: hyperv_fb: Fix hang in kdump kernel when on Hyper-V Gen 2 VMs\\n\\nGen 2 Hyper-V VMs boot via EFI and have a standard EFI framebuffer\\ndevice. When the kdump kernel runs in such a VM, loading the efifb\\ndriver may hang because of accessing the framebuffer at the wrong\\nmemory address.\\n\\nThe scenario occurs when the hyperv_fb driver in the original kernel\\nmoves the framebuffer to a different MMIO address because of conflicts\\nwith an already-running efifb or simplefb driver. The hyperv_fb driver\\nthen informs Hyper-V of the change, which is allowed by the Hyper-V FB\\nVMBus device protocol. However, when the kexec command loads the kdump\\nkernel into crash memory via the kexec_file_load() system call, the\\nsystem call doesn\u0027t know the framebuffer has moved, and it sets up the\\nkdump screen_info using the original framebuffer address. The transition\\nto the kdump kernel does not go through the Hyper-V host, so Hyper-V\\ndoes not reset the framebuffer address like it would do on a reboot.\\nWhen efifb tries to run, it accesses a non-existent framebuffer\\naddress, which traps to the Hyper-V host. After many such accesses,\\nthe Hyper-V host thinks the guest is being malicious, and throttles\\nthe guest to the point that it runs very slowly or appears to have hung.\\n\\nWhen the kdump kernel is loaded into crash memory via the kexec_load()\\nsystem call, the problem does not occur. In this case, the kexec command\\nbuilds the screen_info table itself in user space from data returned\\nby the FBIOGET_FSCREENINFO ioctl against /dev/fb0, which gives it the\\nnew framebuffer location.\\n\\nThis problem was originally reported in 2020 [1], resulting in commit\\n3cb73bc3fa2a (\\\"hyperv_fb: Update screen_info after removing old\\nframebuffer\\\"). This commit solved the problem by setting orig_video_isVGA\\nto 0, so the kdump kernel was unaware of the EFI framebuffer. The efifb\\ndriver did not try to load, and no hang occurred. But in 2024, commit\\nc25a19afb81c (\\\"fbdev/hyperv_fb: Do not clear global screen_info\\\")\\neffectively reverted 3cb73bc3fa2a. Commit c25a19afb81c has no reference\\nto 3cb73bc3fa2a, so perhaps it was done without knowing the implications\\nthat were reported with 3cb73bc3fa2a. In any case, as of commit\\nc25a19afb81c, the original problem came back again.\\n\\nInterestingly, the hyperv_drm driver does not have this problem because\\nit never moves the framebuffer. The difference is that the hyperv_drm\\ndriver removes any conflicting framebuffers *before* allocating an MMIO\\naddress, while the hyperv_fb drivers removes conflicting framebuffers\\n*after* allocating an MMIO address. With the \\\"after\\\" ordering, hyperv_fb\\nmay encounter a conflict and move the framebuffer to a different MMIO\\naddress. But the conflict is essentially bogus because it is removed\\na few lines of code later.\\n\\nRather than fix the problem with the approach from 2020 in commit\\n3cb73bc3fa2a, instead slightly reorder the steps in hyperv_fb so\\nconflicting framebuffers are removed before allocating an MMIO address.\\nThen the default framebuffer MMIO address should always be available, and\\nthere\u0027s never any confusion about which framebuffer address the kdump\\nkernel should use -- it\u0027s always the original address provided by\\nthe Hyper-V host. This approach is already used by the hyperv_drm\\ndriver, and is consistent with the usage guidelines at the head of\\nthe module with the function aperture_remove_conflicting_devices().\\n\\nThis approach also solves a related minor problem when kexec_load()\\nis used to load the kdump kernel. With current code, unbinding and\\nrebinding the hyperv_fb driver could result in the framebuffer moving\\nback to the default framebuffer address, because on the rebind there\\nare no conflicts. If such a move is done after the kdump kernel is\\nloaded with the new framebuffer address, at kdump time it could again\\nhave the wrong address.\\n\\nThis problem and fix are described in terms of the kdump kernel, but\\nit can also occur\\n---truncated---\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fbdev: hyperv_fb: Se corrige el bloqueo del kernel kdump en m\u00e1quinas virtuales Hyper-V Gen 2. Las m\u00e1quinas virtuales Hyper-V Gen 2 arrancan mediante EFI y tienen un dispositivo de b\u00fafer de trama EFI est\u00e1ndar. Cuando el kernel kdump se ejecuta en una m\u00e1quina virtual de este tipo, la carga del controlador efifb puede bloquearse debido al acceso al b\u00fafer de trama en la direcci\u00f3n de memoria incorrecta. Esto ocurre cuando el controlador hyperv_fb del kernel original mueve el b\u00fafer de trama a una direcci\u00f3n MMIO diferente debido a conflictos con un controlador efifb o simplefb ya en ejecuci\u00f3n. El controlador hyperv_fb informa a Hyper-V del cambio, permitido por el protocolo de dispositivo VMBus de Hyper-V FB. Sin embargo, cuando el comando kexec carga el kernel kdump en la memoria de fallos mediante la llamada al sistema kexec_file_load(), esta desconoce el desplazamiento del framebuffer y configura el screen_info de kdump con la direcci\u00f3n original del framebuffer. La transici\u00f3n al kernel kdump no pasa por el host de Hyper-V, por lo que Hyper-V no restablece la direcci\u00f3n del framebuffer como lo har\u00eda al reiniciar. Cuando efifb intenta ejecutarse, accede a una direcci\u00f3n de framebuffer inexistente, lo que redirige al host de Hyper-V. Tras varios accesos de este tipo, el host de Hyper-V considera que el invitado es malicioso y lo limita hasta el punto de que se ejecuta muy lentamente o parece haberse colgado. Cuando el kernel kdump se carga en la memoria de fallos mediante la llamada al sistema kexec_load(), el problema no se produce. En este caso, el comando kexec crea la tabla screen_info en el espacio de usuario a partir de los datos devueltos por el comando ioctl FBIOGET_FSCREENINFO contra /dev/fb0, lo que le asigna la nueva ubicaci\u00f3n del framebuffer. Este problema se report\u00f3 originalmente en 2020 [1], lo que result\u00f3 en el commit 3cb73bc3fa2a (\\\"hyperv_fb: Actualizar screen_info tras eliminar el framebuffer antiguo\\\"). Esta confirmaci\u00f3n solucion\u00f3 el problema estableciendo orig_video_isVGA a 0, por lo que el kernel de kdump desconoc\u00eda el framebuffer EFI. El controlador efifb no intent\u00f3 cargarse y no se produjo ning\u00fan bloqueo. Sin embargo, en 2024, el commit c25a19afb81c (\\\"fbdev/hyperv_fb: No borrar la informaci\u00f3n global del screen_info\\\") revirti\u00f3 eficazmente el problema 3cb73bc3fa2a. el commit c25a19afb81c no hace referencia a 3cb73bc3fa2a, por lo que quiz\u00e1s se realiz\u00f3 sin conocer las implicaciones reportadas con 3cb73bc3fa2a. En cualquier caso, a partir de el commit c25a19afb81c, el problema original reapareci\u00f3. Curiosamente, el controlador hyperv_drm no presenta este problema porque nunca mueve el framebuffer. La diferencia radica en que el controlador hyperv_drm elimina cualquier framebuffer conflictivo *antes* de asignar una direcci\u00f3n MMIO, mientras que el controlador hyperv_fb lo hace *despu\u00e9s* de asignar una direcci\u00f3n MMIO. Con la ordenaci\u00f3n \\\"despu\u00e9s\\\", hyperv_fb puede encontrar un conflicto y mover el framebuffer a una direcci\u00f3n MMIO diferente. Sin embargo, el conflicto es esencialmente falso porque se elimina unas l\u00edneas de c\u00f3digo m\u00e1s adelante. En lugar de corregir el problema con el enfoque de 2020 en el commit 3cb73bc3fa2a, se recomienda reordenar ligeramente los pasos en hyperv_fb para eliminar los framebuffers conflictivos antes de asignar una direcci\u00f3n MMIO. De esta forma, la direcci\u00f3n MMIO predeterminada del framebuffer siempre estar\u00e1 disponible y nunca habr\u00e1 confusi\u00f3n sobre qu\u00e9 direcci\u00f3n debe usar el kernel de kdump: siempre es la direcci\u00f3n original proporcionada por el host de Hyper-V. Este enfoque ya lo utiliza el controlador hyperv_drm y es coherente con las directrices de uso que se indican al principio del m\u00f3dulo con la funci\u00f3n aperture_remove_conflicting_devices(). Este enfoque tambi\u00e9n resuelve un problema menor relacionado cuando se utiliza kexec_load() para cargar el kernel de kdump. Con el c\u00f3digo actual, desvincular y volver a vincular el controlador hyperv_fb podr\u00eda---truncado---\"}],\"metrics\":{},\"references\":[{\"url\":\"https://git.kernel.org/stable/c/2924802d35e00a36b1503a4e786f1926b2fdc1d0\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/304386373007aaca9236a3f36afac0bbedcd2bf0\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/cfffe46a994ac6d5de3b119917680ea1e9a96125\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}]}}"
}
}
Loading…
Loading…
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.
Loading…
Loading…