CVE-2025-21977

{"id": "CVE-2025-21977", "cveTags": [], "metrics": {"cvssMetricV31": [{"type": "Primary", "source": "nvd@nist.gov", "cvssData": {"scope": "UNCHANGED", "version": "3.1", "baseScore": 5.5, "attackVector": "LOCAL", "baseSeverity": "MEDIUM", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "integrityImpact": "NONE", "userInteraction": "NONE", "attackComplexity": "LOW", "availabilityImpact": "HIGH", "privilegesRequired": "LOW", "confidentialityImpact": "NONE"}, "impactScore": 3.6, "exploitabilityScore": 1.8}]}, "published": "2025-04-01T16:15:29.077", "references": [{"url": "https://git.kernel.org/stable/c/2924802d35e00a36b1503a4e786f1926b2fdc1d0", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/304386373007aaca9236a3f36afac0bbedcd2bf0", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/cfffe46a994ac6d5de3b119917680ea1e9a96125", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}], "vulnStatus": "Analyzed", "weaknesses": [{"type": "Primary", "source": "nvd@nist.gov", "description": [{"lang": "en", "value": "NVD-CWE-noinfo"}]}], "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't 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's never any confusion about which framebuffer address the kdump\nkernel should use -- it's 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---"}], "lastModified": "2025-10-30T21:03:16.400", "configurations": [{"nodes": [{"negate": false, "cpeMatch": [{"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "AD00A08B-A8BF-407B-95F5-DCADBFF79F01", "versionEndExcluding": "6.12.20", "versionStartIncluding": "6.8"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "0A20D4D7-B329-4C68-B662-76062EA7DCF0", "versionEndExcluding": "6.13.8", "versionStartIncluding": "6.13"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:6.14:rc1:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "186716B6-2B66-4BD0-852E-D48E71C0C85F"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:6.14:rc2:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "0D3E781C-403A-498F-9DA9-ECEE50F41E75"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:6.14:rc3:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "66619FB8-0AAF-4166-B2CF-67B24143261D"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:6.14:rc4:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "D3D6550E-6679-4560-902D-AF52DCFE905B"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:6.14:rc5:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "45B90F6B-BEC7-4D4E-883A-9DBADE021750"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:6.14:rc6:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "1759FFB7-531C-41B1-9AE1-FD3D80E0D920"}], "operator": "OR"}]}], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}