CVE-2024-44943

In the Linux kernel, the following vulnerability has been resolved: mm: gup: stop abusing try_grab_folio A kernel warning was reported when pinning folio in CMA memory when launching SEV virtual machine. The splat looks like: [ 464.325306] WARNING: CPU: 13 PID: 6734 at mm/gup.c:1313 __get_user_pages+0x423/0x520 [ 464.325464] CPU: 13 PID: 6734 Comm: qemu-kvm Kdump: loaded Not tainted 6.6.33+ #6 [ 464.325477] RIP: 0010:__get_user_pages+0x423/0x520 [ 464.325515] Call Trace: [ 464.325520] <TASK> [ 464.325523] ? __get_user_pages+0x423/0x520 [ 464.325528] ? __warn+0x81/0x130 [ 464.325536] ? __get_user_pages+0x423/0x520 [ 464.325541] ? report_bug+0x171/0x1a0 [ 464.325549] ? handle_bug+0x3c/0x70 [ 464.325554] ? exc_invalid_op+0x17/0x70 [ 464.325558] ? asm_exc_invalid_op+0x1a/0x20 [ 464.325567] ? __get_user_pages+0x423/0x520 [ 464.325575] __gup_longterm_locked+0x212/0x7a0 [ 464.325583] internal_get_user_pages_fast+0xfb/0x190 [ 464.325590] pin_user_pages_fast+0x47/0x60 [ 464.325598] sev_pin_memory+0xca/0x170 [kvm_amd] [ 464.325616] sev_mem_enc_register_region+0x81/0x130 [kvm_amd] Per the analysis done by yangge, when starting the SEV virtual machine, it will call pin_user_pages_fast(..., FOLL_LONGTERM, ...) to pin the memory. But the page is in CMA area, so fast GUP will fail then fallback to the slow path due to the longterm pinnalbe check in try_grab_folio(). The slow path will try to pin the pages then migrate them out of CMA area. But the slow path also uses try_grab_folio() to pin the page, it will also fail due to the same check then the above warning is triggered. In addition, the try_grab_folio() is supposed to be used in fast path and it elevates folio refcount by using add ref unless zero. We are guaranteed to have at least one stable reference in slow path, so the simple atomic add could be used. The performance difference should be trivial, but the misuse may be confusing and misleading. Redefined try_grab_folio() to try_grab_folio_fast(), and try_grab_page() to try_grab_folio(), and use them in the proper paths. This solves both the abuse and the kernel warning. The proper naming makes their usecase more clear and should prevent from abusing in the future. peterx said: : The user will see the pin fails, for gpu-slow it further triggers the WARN : right below that failure (as in the original report): : : folio = try_grab_folio(page, page_increm - 1, : foll_flags); : if (WARN_ON_ONCE(!folio)) { <------------------------ here : /* : * Release the 1st page ref if the : * folio is problematic, fail hard. : */ : gup_put_folio(page_folio(page), 1, : foll_flags); : ret = -EFAULT; : goto out; : } [1] https://lore.kernel.org/linux-mm/1719478388-31917-1-git-send-email-yangge1116@126.com/ [shy828301@gmail.com: fix implicit declaration of function try_grab_folio_fast] Link: https://lkml.kernel.org/r/CAHbLzkowMSso-4Nufc9hcMehQsK9PNz3OSu-+eniU-2Mm-xjhA@mail.gmail.com
Configurations

Configuration 1 (hide)

OR cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.10:rc1:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.10:rc2:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.10:rc3:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.10:rc4:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.10:rc5:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.10:rc6:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.10:rc7:*:*:*:*:*:*

History

10 Sep 2024, 18:12

Type Values Removed Values Added
References () https://git.kernel.org/stable/c/26273f5f4cf68b29414e403837093408a9c98e1f - () https://git.kernel.org/stable/c/26273f5f4cf68b29414e403837093408a9c98e1f - Patch
References () https://git.kernel.org/stable/c/f442fa6141379a20b48ae3efabee827a3d260787 - () https://git.kernel.org/stable/c/f442fa6141379a20b48ae3efabee827a3d260787 - Patch
CWE NVD-CWE-noinfo
CVSS v2 : unknown
v3 : unknown
v2 : unknown
v3 : 5.5
CPE cpe:2.3:o:linux:linux_kernel:6.10:rc5:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.10:rc6:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.10:rc3:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.10:rc1:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.10:rc7:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.10:rc4:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.10:rc2:*:*:*:*:*:*
First Time Linux linux Kernel
Linux

28 Aug 2024, 12:57

Type Values Removed Values Added
Summary
  • (es) En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mm: gup: deja de abusar de try_grab_folio Se informó una advertencia del kernel al fijar folio en la memoria CMA al iniciar la máquina virtual SEV. El símbolo se ve así: [464.325306] ADVERTENCIA: CPU: 13 PID: 6734 en mm/gup.c:1313 __get_user_pages+0x423/0x520 [464.325464] CPU: 13 PID: 6734 Comm: qemu-kvm Kdump: cargado No contaminado 6.6. 33+ #6 [ 464.325477] RIP: 0010:__get_user_pages+0x423/0x520 [ 464.325515] Seguimiento de llamadas: [ 464.325520] [ 464.325523] ? __get_user_pages+0x423/0x520 [464.325528] ? __advertir+0x81/0x130 [ 464.325536] ? __get_user_pages+0x423/0x520 [464.325541] ? report_bug+0x171/0x1a0 [464.325549]? handle_bug+0x3c/0x70 [464.325554]? exc_invalid_op+0x17/0x70 [464.325558]? asm_exc_invalid_op+0x1a/0x20 [464.325567]? __get_user_pages+0x423/0x520 [ 464.325575] __gup_longterm_locked+0x212/0x7a0 [ 464.325583] internal_get_user_pages_fast+0xfb/0x190 [ 464.325590] pin_user_pages_fast+0x47/0x60 [ 4 64.325598] sev_pin_memory+0xca/0x170 [kvm_amd] [ 464.325616] sev_mem_enc_register_region+0x81/0x130 [kvm_amd ] Según el análisis realizado por yangge, al iniciar la máquina virtual SEV, llamará a pin_user_pages_fast(..., FOLL_LONGTERM, ...) para fijar la memoria. Pero la página está en el área CMA, por lo que el GUP rápido fallará y luego volverá a la ruta lenta debido a la verificación pinnalbe a largo plazo en try_grab_folio(). La ruta lenta intentará fijar las páginas y luego migrarlas fuera del área CMA. Pero la ruta lenta también usa try_grab_folio() para fijar la página, también fallará debido a la misma verificación y luego se activa la advertencia anterior. Además, se supone que try_grab_folio() se usa en la ruta rápida y eleva el recuento de folios usando add ref a menos que sea cero. Tenemos la garantía de tener al menos una referencia estable en una ruta lenta, por lo que se podría utilizar la adición atómica simple. La diferencia de rendimiento debería ser trivial, pero el mal uso puede resultar confuso y engañoso. Redefinió try_grab_folio() a try_grab_folio_fast() y try_grab_page() a try_grab_folio(), y utilícelos en las rutas adecuadas. Esto resuelve tanto el abuso como la advertencia del kernel. La denominación adecuada aclara su caso de uso y debería evitar abusos en el futuro. peterx dijo: El usuario verá que el pin falla, para gpu-slow activa aún más la ADVERTENCIA: justo debajo de ese error (como en el informe original): : : folio = try_grab_folio(page, page_increm - 1, : foll_flags); : if (WARN_ON_ONCE(!folio)) { &lt;------------------------ aquí : /* : * Liberar la referencia de la primera página si : * El folio es problemático, falla mucho. : */ : gup_put_folio(page_folio(página), 1, : foll_flags); : ret = -EFALLO; : salir; : } [1] https://lore.kernel.org/linux-mm/1719478388-31917-1-git-send-email-yangge1116@126.com/ [shy828301@gmail.com: corrige la declaración implícita de la función try_grab_folio_fast ] Enlace: https://lkml.kernel.org/r/CAHbLzkowMSso-4Nufc9hcMehQsK9PNz3OSu-+eniU-2Mm-xjhA@mail.gmail.com

28 Aug 2024, 08:15

Type Values Removed Values Added
New CVE

Information

Published : 2024-08-28 08:15

Updated : 2024-09-10 18:12


NVD link : CVE-2024-44943

Mitre link : CVE-2024-44943

CVE.ORG link : CVE-2024-44943


JSON object : View

Products Affected

linux

  • linux_kernel