CVE-2025-39989 (GCVE-0-2025-39989)
Vulnerability from cvelistv5
Published
2025-04-18 07:01
Modified
2025-05-26 05:25
Severity ?
VLAI Severity ?
EPSS score ?
Summary
In the Linux kernel, the following vulnerability has been resolved:
x86/mce: use is_copy_from_user() to determine copy-from-user context
Patch series "mm/hwpoison: Fix regressions in memory failure handling",
v4.
## 1. What am I trying to do:
This patchset resolves two critical regressions related to memory failure
handling that have appeared in the upstream kernel since version 5.17, as
compared to 5.10 LTS.
- copyin case: poison found in user page while kernel copying from user space
- instr case: poison found while instruction fetching in user space
## 2. What is the expected outcome and why
- For copyin case:
Kernel can recover from poison found where kernel is doing get_user() or
copy_from_user() if those places get an error return and the kernel return
-EFAULT to the process instead of crashing. More specifily, MCE handler
checks the fixup handler type to decide whether an in kernel #MC can be
recovered. When EX_TYPE_UACCESS is found, the PC jumps to recovery code
specified in _ASM_EXTABLE_FAULT() and return a -EFAULT to user space.
- For instr case:
If a poison found while instruction fetching in user space, full recovery
is possible. User process takes #PF, Linux allocates a new page and fills
by reading from storage.
## 3. What actually happens and why
- For copyin case: kernel panic since v5.17
Commit 4c132d1d844a ("x86/futex: Remove .fixup usage") introduced a new
extable fixup type, EX_TYPE_EFAULT_REG, and later patches updated the
extable fixup type for copy-from-user operations, changing it from
EX_TYPE_UACCESS to EX_TYPE_EFAULT_REG. It breaks previous EX_TYPE_UACCESS
handling when posion found in get_user() or copy_from_user().
- For instr case: user process is killed by a SIGBUS signal due to #CMCI
and #MCE race
When an uncorrected memory error is consumed there is a race between the
CMCI from the memory controller reporting an uncorrected error with a UCNA
signature, and the core reporting and SRAR signature machine check when
the data is about to be consumed.
### Background: why *UN*corrected errors tied to *C*MCI in Intel platform [1]
Prior to Icelake memory controllers reported patrol scrub events that
detected a previously unseen uncorrected error in memory by signaling a
broadcast machine check with an SRAO (Software Recoverable Action
Optional) signature in the machine check bank. This was overkill because
it's not an urgent problem that no core is on the verge of consuming that
bad data. It's also found that multi SRAO UCE may cause nested MCE
interrupts and finally become an IERR.
Hence, Intel downgrades the machine check bank signature of patrol scrub
from SRAO to UCNA (Uncorrected, No Action required), and signal changed to
#CMCI. Just to add to the confusion, Linux does take an action (in
uc_decode_notifier()) to try to offline the page despite the UC*NA*
signature name.
### Background: why #CMCI and #MCE race when poison is consuming in
Intel platform [1]
Having decided that CMCI/UCNA is the best action for patrol scrub errors,
the memory controller uses it for reads too. But the memory controller is
executing asynchronously from the core, and can't tell the difference
between a "real" read and a speculative read. So it will do CMCI/UCNA if
an error is found in any read.
Thus:
1) Core is clever and thinks address A is needed soon, issues a
speculative read.
2) Core finds it is going to use address A soon after sending the read
request
3) The CMCI from the memory controller is in a race with MCE from the
core that will soon try to retire the load from address A.
Quite often (because speculation has got better) the CMCI from the memory
controller is delivered before the core is committed to the instruction
reading address A, so the interrupt is taken, and Linux offlines the page
(marking it as poison).
## Why user process is killed for instr case
Commit 046545a661af ("mm/hwpoison: fix error page recovered but reported
"not
---truncated---
References
Impacted products
| Vendor | Product | Version | ||
|---|---|---|---|---|
| ► | Linux | Linux |
Version: 4c132d1d844a53fc4e4b5c34e36ef10d6124b783 Version: 4c132d1d844a53fc4e4b5c34e36ef10d6124b783 Version: 4c132d1d844a53fc4e4b5c34e36ef10d6124b783 Version: 4c132d1d844a53fc4e4b5c34e36ef10d6124b783 Version: 4c132d1d844a53fc4e4b5c34e36ef10d6124b783 Version: 88eded8104d2ca0429703755dd250f8cbecc1447 |
|
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"arch/x86/kernel/cpu/mce/severity.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "5724654a084f701dc64b08d34a0e800f22f0e6e4",
"status": "affected",
"version": "4c132d1d844a53fc4e4b5c34e36ef10d6124b783",
"versionType": "git"
},
{
"lessThan": "3e3d8169c0950a0b3cd5105f6403a78350dcac80",
"status": "affected",
"version": "4c132d1d844a53fc4e4b5c34e36ef10d6124b783",
"versionType": "git"
},
{
"lessThan": "449413da90a337f343cc5a73070cbd68e92e8a54",
"status": "affected",
"version": "4c132d1d844a53fc4e4b5c34e36ef10d6124b783",
"versionType": "git"
},
{
"lessThan": "0b8388e97ba6a8c033f9a8b5565af41af07f9345",
"status": "affected",
"version": "4c132d1d844a53fc4e4b5c34e36ef10d6124b783",
"versionType": "git"
},
{
"lessThan": "1a15bb8303b6b104e78028b6c68f76a0d4562134",
"status": "affected",
"version": "4c132d1d844a53fc4e4b5c34e36ef10d6124b783",
"versionType": "git"
},
{
"status": "affected",
"version": "88eded8104d2ca0429703755dd250f8cbecc1447",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"arch/x86/kernel/cpu/mce/severity.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "5.17"
},
{
"lessThan": "5.17",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.89",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.23",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.13.*",
"status": "unaffected",
"version": "6.13.11",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.14.*",
"status": "unaffected",
"version": "6.14.2",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.15",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.89",
"versionStartIncluding": "5.17",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.23",
"versionStartIncluding": "5.17",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.13.11",
"versionStartIncluding": "5.17",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.14.2",
"versionStartIncluding": "5.17",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.15",
"versionStartIncluding": "5.17",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "5.15.58",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nx86/mce: use is_copy_from_user() to determine copy-from-user context\n\nPatch series \"mm/hwpoison: Fix regressions in memory failure handling\",\nv4.\n\n## 1. What am I trying to do:\n\nThis patchset resolves two critical regressions related to memory failure\nhandling that have appeared in the upstream kernel since version 5.17, as\ncompared to 5.10 LTS.\n\n - copyin case: poison found in user page while kernel copying from user space\n - instr case: poison found while instruction fetching in user space\n\n## 2. What is the expected outcome and why\n\n- For copyin case:\n\nKernel can recover from poison found where kernel is doing get_user() or\ncopy_from_user() if those places get an error return and the kernel return\n-EFAULT to the process instead of crashing. More specifily, MCE handler\nchecks the fixup handler type to decide whether an in kernel #MC can be\nrecovered. When EX_TYPE_UACCESS is found, the PC jumps to recovery code\nspecified in _ASM_EXTABLE_FAULT() and return a -EFAULT to user space.\n\n- For instr case:\n\nIf a poison found while instruction fetching in user space, full recovery\nis possible. User process takes #PF, Linux allocates a new page and fills\nby reading from storage.\n\n\n## 3. What actually happens and why\n\n- For copyin case: kernel panic since v5.17\n\nCommit 4c132d1d844a (\"x86/futex: Remove .fixup usage\") introduced a new\nextable fixup type, EX_TYPE_EFAULT_REG, and later patches updated the\nextable fixup type for copy-from-user operations, changing it from\nEX_TYPE_UACCESS to EX_TYPE_EFAULT_REG. It breaks previous EX_TYPE_UACCESS\nhandling when posion found in get_user() or copy_from_user().\n\n- For instr case: user process is killed by a SIGBUS signal due to #CMCI\n and #MCE race\n\nWhen an uncorrected memory error is consumed there is a race between the\nCMCI from the memory controller reporting an uncorrected error with a UCNA\nsignature, and the core reporting and SRAR signature machine check when\nthe data is about to be consumed.\n\n### Background: why *UN*corrected errors tied to *C*MCI in Intel platform [1]\n\nPrior to Icelake memory controllers reported patrol scrub events that\ndetected a previously unseen uncorrected error in memory by signaling a\nbroadcast machine check with an SRAO (Software Recoverable Action\nOptional) signature in the machine check bank. This was overkill because\nit\u0027s not an urgent problem that no core is on the verge of consuming that\nbad data. It\u0027s also found that multi SRAO UCE may cause nested MCE\ninterrupts and finally become an IERR.\n\nHence, Intel downgrades the machine check bank signature of patrol scrub\nfrom SRAO to UCNA (Uncorrected, No Action required), and signal changed to\n#CMCI. Just to add to the confusion, Linux does take an action (in\nuc_decode_notifier()) to try to offline the page despite the UC*NA*\nsignature name.\n\n### Background: why #CMCI and #MCE race when poison is consuming in\n Intel platform [1]\n\nHaving decided that CMCI/UCNA is the best action for patrol scrub errors,\nthe memory controller uses it for reads too. But the memory controller is\nexecuting asynchronously from the core, and can\u0027t tell the difference\nbetween a \"real\" read and a speculative read. So it will do CMCI/UCNA if\nan error is found in any read.\n\nThus:\n\n1) Core is clever and thinks address A is needed soon, issues a\n speculative read.\n\n2) Core finds it is going to use address A soon after sending the read\n request\n\n3) The CMCI from the memory controller is in a race with MCE from the\n core that will soon try to retire the load from address A.\n\nQuite often (because speculation has got better) the CMCI from the memory\ncontroller is delivered before the core is committed to the instruction\nreading address A, so the interrupt is taken, and Linux offlines the page\n(marking it as poison).\n\n\n## Why user process is killed for instr case\n\nCommit 046545a661af (\"mm/hwpoison: fix error page recovered but reported\n\"not\n---truncated---"
}
],
"providerMetadata": {
"dateUpdated": "2025-05-26T05:25:34.006Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/5724654a084f701dc64b08d34a0e800f22f0e6e4"
},
{
"url": "https://git.kernel.org/stable/c/3e3d8169c0950a0b3cd5105f6403a78350dcac80"
},
{
"url": "https://git.kernel.org/stable/c/449413da90a337f343cc5a73070cbd68e92e8a54"
},
{
"url": "https://git.kernel.org/stable/c/0b8388e97ba6a8c033f9a8b5565af41af07f9345"
},
{
"url": "https://git.kernel.org/stable/c/1a15bb8303b6b104e78028b6c68f76a0d4562134"
}
],
"title": "x86/mce: use is_copy_from_user() to determine copy-from-user context",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2025-39989",
"datePublished": "2025-04-18T07:01:39.321Z",
"dateReserved": "2025-04-16T07:20:57.150Z",
"dateUpdated": "2025-05-26T05:25:34.006Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1",
"vulnerability-lookup:meta": {
"nvd": "{\"cve\":{\"id\":\"CVE-2025-39989\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2025-04-18T07:15:44.550\",\"lastModified\":\"2025-05-02T07:16:05.207\",\"vulnStatus\":\"Awaiting Analysis\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nx86/mce: use is_copy_from_user() to determine copy-from-user context\\n\\nPatch series \\\"mm/hwpoison: Fix regressions in memory failure handling\\\",\\nv4.\\n\\n## 1. What am I trying to do:\\n\\nThis patchset resolves two critical regressions related to memory failure\\nhandling that have appeared in the upstream kernel since version 5.17, as\\ncompared to 5.10 LTS.\\n\\n - copyin case: poison found in user page while kernel copying from user space\\n - instr case: poison found while instruction fetching in user space\\n\\n## 2. What is the expected outcome and why\\n\\n- For copyin case:\\n\\nKernel can recover from poison found where kernel is doing get_user() or\\ncopy_from_user() if those places get an error return and the kernel return\\n-EFAULT to the process instead of crashing. More specifily, MCE handler\\nchecks the fixup handler type to decide whether an in kernel #MC can be\\nrecovered. When EX_TYPE_UACCESS is found, the PC jumps to recovery code\\nspecified in _ASM_EXTABLE_FAULT() and return a -EFAULT to user space.\\n\\n- For instr case:\\n\\nIf a poison found while instruction fetching in user space, full recovery\\nis possible. User process takes #PF, Linux allocates a new page and fills\\nby reading from storage.\\n\\n\\n## 3. What actually happens and why\\n\\n- For copyin case: kernel panic since v5.17\\n\\nCommit 4c132d1d844a (\\\"x86/futex: Remove .fixup usage\\\") introduced a new\\nextable fixup type, EX_TYPE_EFAULT_REG, and later patches updated the\\nextable fixup type for copy-from-user operations, changing it from\\nEX_TYPE_UACCESS to EX_TYPE_EFAULT_REG. It breaks previous EX_TYPE_UACCESS\\nhandling when posion found in get_user() or copy_from_user().\\n\\n- For instr case: user process is killed by a SIGBUS signal due to #CMCI\\n and #MCE race\\n\\nWhen an uncorrected memory error is consumed there is a race between the\\nCMCI from the memory controller reporting an uncorrected error with a UCNA\\nsignature, and the core reporting and SRAR signature machine check when\\nthe data is about to be consumed.\\n\\n### Background: why *UN*corrected errors tied to *C*MCI in Intel platform [1]\\n\\nPrior to Icelake memory controllers reported patrol scrub events that\\ndetected a previously unseen uncorrected error in memory by signaling a\\nbroadcast machine check with an SRAO (Software Recoverable Action\\nOptional) signature in the machine check bank. This was overkill because\\nit\u0027s not an urgent problem that no core is on the verge of consuming that\\nbad data. It\u0027s also found that multi SRAO UCE may cause nested MCE\\ninterrupts and finally become an IERR.\\n\\nHence, Intel downgrades the machine check bank signature of patrol scrub\\nfrom SRAO to UCNA (Uncorrected, No Action required), and signal changed to\\n#CMCI. Just to add to the confusion, Linux does take an action (in\\nuc_decode_notifier()) to try to offline the page despite the UC*NA*\\nsignature name.\\n\\n### Background: why #CMCI and #MCE race when poison is consuming in\\n Intel platform [1]\\n\\nHaving decided that CMCI/UCNA is the best action for patrol scrub errors,\\nthe memory controller uses it for reads too. But the memory controller is\\nexecuting asynchronously from the core, and can\u0027t tell the difference\\nbetween a \\\"real\\\" read and a speculative read. So it will do CMCI/UCNA if\\nan error is found in any read.\\n\\nThus:\\n\\n1) Core is clever and thinks address A is needed soon, issues a\\n speculative read.\\n\\n2) Core finds it is going to use address A soon after sending the read\\n request\\n\\n3) The CMCI from the memory controller is in a race with MCE from the\\n core that will soon try to retire the load from address A.\\n\\nQuite often (because speculation has got better) the CMCI from the memory\\ncontroller is delivered before the core is committed to the instruction\\nreading address A, so the interrupt is taken, and Linux offlines the page\\n(marking it as poison).\\n\\n\\n## Why user process is killed for instr case\\n\\nCommit 046545a661af (\\\"mm/hwpoison: fix error page recovered but reported\\n\\\"not\\n---truncated---\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/mce: usar is_copy_from_user() para determinar el contexto de copia del usuario. Serie de parches \\\"mm/hwpoison: Corregir regresiones en la gesti\u00f3n de fallos de memoria\\\", v4. ## 1. \u00bfQu\u00e9 intento hacer?: Este conjunto de parches resuelve dos regresiones cr\u00edticas relacionadas con la gesti\u00f3n de fallos de memoria que han aparecido en el kernel original desde la versi\u00f3n 5.17, en comparaci\u00f3n con la 5.10 LTS. - caso de copyin: se encontr\u00f3 un error en la p\u00e1gina de usuario mientras el kernel copiaba desde el espacio de usuario. - caso de instr: se encontr\u00f3 un error al obtener instrucciones en el espacio de usuario. ## 2. \u00bfCu\u00e1l es el resultado esperado y por qu\u00e9? - Para el caso de copyin: el kernel puede recuperarse del error encontrado donde el kernel ejecuta get_user() o copy_from_user() si en esos lugares se obtiene un error y el kernel devuelve -EFAULT al proceso en lugar de bloquearse. M\u00e1s espec\u00edficamente, el controlador de MCE comprueba el tipo de controlador de correcci\u00f3n para decidir si se puede recuperar un #MC en el kernel. Cuando se encuentra EX_TYPE_UACCESS, el PC salta al c\u00f3digo de recuperaci\u00f3n especificado en _ASM_EXTABLE_FAULT() y devuelve un -EFAULT al espacio de usuario. - En el caso de instr: Si se encuentra un error durante la obtenci\u00f3n de instrucciones en el espacio de usuario, es posible una recuperaci\u00f3n completa. El proceso de usuario toma #PF, Linux asigna una nueva p\u00e1gina y la completa leyendo del almacenamiento. ## 3. Qu\u00e9 sucede realmente y por qu\u00e9 - En el caso de copyin: P\u00e1nico del kernel desde la v5.17. El commit 4c132d1d844a (\\\"x86/futex: Eliminar el uso de .fixup\\\") introdujo un nuevo tipo de correcci\u00f3n extable, EX_TYPE_EFAULT_REG, y parches posteriores actualizaron el tipo de correcci\u00f3n extable para operaciones de copia desde el usuario, cambi\u00e1ndolo de EX_TYPE_UACCESS a EX_TYPE_EFAULT_REG. Esto interrumpe la gesti\u00f3n previo de EX_TYPE_UACCESS cuando se encuentra error en get_user() o copy_from_user(). - Para el caso instr: el proceso del usuario es eliminado por una se\u00f1al SIGBUS debido a la ejecuci\u00f3n #CMCI y #MCE Cuando se consume un error de memoria sin corregir, hay una ejecuci\u00f3n entre el CMCI del controlador de memoria que informa un error sin corregir con una firma UCNA y el informe del n\u00facleo y la comprobaci\u00f3n de la m\u00e1quina con firma SRAR cuando los datos est\u00e1n a punto de consumirse. ### Antecedentes: por qu\u00e9 los errores *UN*corregidos est\u00e1n vinculados a *C*MCI en la plataforma Intel [1] Antes de Icelake, los controladores de memoria informaban de eventos de depuraci\u00f3n de patrullaje que detectaban un error sin corregir no visto previamente en la memoria mediante la se\u00f1alizaci\u00f3n de una comprobaci\u00f3n de la m\u00e1quina de difusi\u00f3n con una firma SRAO (Acci\u00f3n recuperable de software opcional) en el banco de comprobaci\u00f3n de la m\u00e1quina. Esto era excesivo porque no es un problema urgente que ning\u00fan n\u00facleo est\u00e9 a punto de consumir esos datos err\u00f3neos. Tambi\u00e9n se ha descubierto que varias UCE SRAO pueden causar interrupciones MCE anidadas y, finalmente, convertirse en una IERR. Por lo tanto, Intel degrada la firma del banco de verificaci\u00f3n de la m\u00e1quina de la limpieza de patrullaje de SRAO a UCNA (sin corregir, no se requiere acci\u00f3n) y la se\u00f1al cambia a #CMCI. Para aumentar la confusi\u00f3n, Linux realiza una acci\u00f3n (en uc_decode_notifier()) para intentar desconectar la p\u00e1gina a pesar del nombre de la firma UC*NA*. ### Antecedentes: \u00bfpor qu\u00e9 #CMCI y #MCE compiten cuando el veneno consume datos en la plataforma Intel? [1] Tras decidir que CMCI/UCNA es la mejor acci\u00f3n para los errores de limpieza de patrullaje, el controlador de memoria tambi\u00e9n la utiliza para las lecturas. Sin embargo, el controlador de memoria se ejecuta de forma as\u00edncrona desde el n\u00facleo y no puede distinguir entre una lectura \\\"real\\\" y una lectura especulativa. Por lo tanto, ejecutar\u00e1 CMCI/UCNA si se encuentra un error en cualquier lectura. Por lo tanto: 1) El n\u00facleo es inteligente y cree que ----truncada---\"}],\"metrics\":{},\"references\":[{\"url\":\"https://git.kernel.org/stable/c/0b8388e97ba6a8c033f9a8b5565af41af07f9345\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/1a15bb8303b6b104e78028b6c68f76a0d4562134\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/3e3d8169c0950a0b3cd5105f6403a78350dcac80\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/449413da90a337f343cc5a73070cbd68e92e8a54\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/5724654a084f701dc64b08d34a0e800f22f0e6e4\",\"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…