{"resultsPerPage":1,"startIndex":0,"totalResults":1,"format":"NVD_CVE","version":"2.0","timestamp":"2026-06-11T08:52:57.047","vulnerabilities":[{"cve":{"id":"CVE-2021-47226","sourceIdentifier":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","published":"2024-05-21T15:15:11.823","lastModified":"2025-04-29T19:26:36.690","vulnStatus":"Analyzed","cveTags":[],"descriptions":[{"lang":"en","value":"In the Linux kernel, the following vulnerability has been resolved:\n\nx86/fpu: Invalidate FPU state after a failed XRSTOR from a user buffer\n\nBoth Intel and AMD consider it to be architecturally valid for XRSTOR to\nfail with #PF but nonetheless change the register state.  The actual\nconditions under which this might occur are unclear [1], but it seems\nplausible that this might be triggered if one sibling thread unmaps a page\nand invalidates the shared TLB while another sibling thread is executing\nXRSTOR on the page in question.\n\n__fpu__restore_sig() can execute XRSTOR while the hardware registers\nare preserved on behalf of a different victim task (using the\nfpu_fpregs_owner_ctx mechanism), and, in theory, XRSTOR could fail but\nmodify the registers.\n\nIf this happens, then there is a window in which __fpu__restore_sig()\ncould schedule out and the victim task could schedule back in without\nreloading its own FPU registers. This would result in part of the FPU\nstate that __fpu__restore_sig() was attempting to load leaking into the\nvictim task's user-visible state.\n\nInvalidate preserved FPU registers on XRSTOR failure to prevent this\nsituation from corrupting any state.\n\n[1] Frequent readers of the errata lists might imagine \"complex\n    microarchitectural conditions\"."},{"lang":"es","value":"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/fpu: Invalida el estado de la FPU después de un XRSTOR fallido desde un búfer de usuario. Tanto Intel como AMD consideran que es arquitectónicamente válido que XRSTOR falle con #PF pero aun así cambie el estado del registro. . Las condiciones reales bajo las cuales esto podría ocurrir no están claras [1], pero parece plausible que esto pueda desencadenarse si un hilo hermano desasigna una página e invalida el TLB compartido mientras otro hilo hermano está ejecutando XRSTOR en la página en cuestión. __fpu__restore_sig() puede ejecutar XRSTOR mientras los registros de hardware se conservan en nombre de una tarea de víctima diferente (usando el mecanismo fpu_fpregs_owner_ctx) y, en teoría, XRSTOR podría fallar pero modificar los registros. Si esto sucede, entonces hay una ventana en la que __fpu__restore_sig() podría programar la salida y la tarea de la víctima podría volver a programarse sin recargar sus propios registros FPU. Esto resultaría en parte del estado de la FPU en el que __fpu__restore_sig() intentaba cargar una filtración en el estado visible para el usuario de la tarea de la víctima. Invalide los registros FPU preservados en caso de falla de XRSTOR para evitar que esta situación corrompa cualquier estado. [1] Los lectores frecuentes de las listas de erratas podrían imaginar \"condiciones microarquitectónicas complejas\"."}],"metrics":{"cvssMetricV31":[{"source":"nvd@nist.gov","type":"Primary","cvssData":{"version":"3.1","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H","baseScore":7.1,"baseSeverity":"HIGH","attackVector":"LOCAL","attackComplexity":"LOW","privilegesRequired":"LOW","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"NONE","integrityImpact":"HIGH","availabilityImpact":"HIGH"},"exploitabilityScore":1.8,"impactScore":5.2}]},"weaknesses":[{"source":"nvd@nist.gov","type":"Primary","description":[{"lang":"en","value":"CWE-203"}]}],"configurations":[{"nodes":[{"operator":"OR","negate":false,"cpeMatch":[{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"5.2","versionEndExcluding":"5.10.46","matchCriteriaId":"71A9FF74-A7CD-4A97-B822-6302C3124C48"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"5.11","versionEndExcluding":"5.12.13","matchCriteriaId":"7806E7E5-6D4F-4E18-81C1-79B3C60EE855"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:5.13:rc1:*:*:*:*:*:*","matchCriteriaId":"0CBAD0FC-C281-4666-AB2F-F8E6E1165DF7"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:5.13:rc2:*:*:*:*:*:*","matchCriteriaId":"96AC23B2-D46A-49D9-8203-8E1BEDCA8532"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:5.13:rc3:*:*:*:*:*:*","matchCriteriaId":"DA610E30-717C-4700-9F77-A3C9244F3BFD"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:5.13:rc4:*:*:*:*:*:*","matchCriteriaId":"1ECD33F5-85BE-430B-8F86-8D7BD560311D"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:5.13:rc5:*:*:*:*:*:*","matchCriteriaId":"CF351855-2437-4CF5-AD7C-BDFA51F27683"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:5.13:rc6:*:*:*:*:*:*","matchCriteriaId":"25A855BA-2118-44F2-90EF-EBBB12AF51EF"}]}]}],"references":[{"url":"https://git.kernel.org/stable/c/002665dcba4bbec8c82f0aeb4bd3f44334ed2c14","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":["Patch"]},{"url":"https://git.kernel.org/stable/c/a7748e021b9fb7739e3cb88449296539de0b6817","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":["Patch"]},{"url":"https://git.kernel.org/stable/c/d8778e393afa421f1f117471144f8ce6deb6953a","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":["Patch"]},{"url":"https://git.kernel.org/stable/c/002665dcba4bbec8c82f0aeb4bd3f44334ed2c14","source":"af854a3a-2127-422b-91ae-364da2661108","tags":["Patch"]},{"url":"https://git.kernel.org/stable/c/a7748e021b9fb7739e3cb88449296539de0b6817","source":"af854a3a-2127-422b-91ae-364da2661108","tags":["Patch"]},{"url":"https://git.kernel.org/stable/c/d8778e393afa421f1f117471144f8ce6deb6953a","source":"af854a3a-2127-422b-91ae-364da2661108","tags":["Patch"]}]}}]}