CWE-754
Allowed-with-ReviewImproper Check for Unusual or Exceptional Conditions
Abstraction: Class · Status: Incomplete
The product does not check or incorrectly checks for unusual or exceptional conditions that are not expected to occur frequently during day to day operation of the product.
974 vulnerabilities reference this CWE, most recent first.
GHSA-C93V-4QMP-8W98
Vulnerability from github – Published: 2025-03-12 21:31 – Updated: 2025-03-12 21:31A Denial of Service (DoS) vulnerability in Palo Alto Networks PAN-OS software causes the firewall to unexpectedly reboot when processing a specially crafted LLDP frame sent by an unauthenticated adjacent attacker. Repeated attempts to initiate this condition causes the firewall to enter maintenance mode.
This issue does not apply to Cloud NGFWs or Prisma Access software.
{
"affected": [],
"aliases": [
"CVE-2025-0116"
],
"database_specific": {
"cwe_ids": [
"CWE-754"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-12T19:15:37Z",
"severity": "MODERATE"
},
"details": "A Denial of Service (DoS) vulnerability in Palo Alto Networks PAN-OS software causes the firewall to unexpectedly reboot when processing a specially crafted LLDP frame sent by an unauthenticated adjacent attacker. Repeated attempts to initiate this condition causes the firewall to enter maintenance mode.\n\nThis issue does not apply to Cloud NGFWs or Prisma Access software.",
"id": "GHSA-c93v-4qmp-8w98",
"modified": "2025-03-12T21:31:29Z",
"published": "2025-03-12T21:31:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-0116"
},
{
"type": "WEB",
"url": "https://security.paloaltonetworks.com/CVE-2025-0116"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:P/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:N/R:U/V:C/RE:M/U:Amber",
"type": "CVSS_V4"
}
]
}
GHSA-C948-477J-77C3
Vulnerability from github – Published: 2023-12-15 18:30 – Updated: 2023-12-15 18:30A denial of service vulnerability exists in all Silicon Labs Z-Wave controller and endpoint devices running Z-Wave SDK v7.20.3 (Gecko SDK v4.3.3) and earlier. This attack can be carried out only by devices on the network sending a stream of packets to the device.
{
"affected": [],
"aliases": [
"CVE-2023-5310"
],
"database_specific": {
"cwe_ids": [
"CWE-248",
"CWE-754"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-12-15T16:15:46Z",
"severity": "MODERATE"
},
"details": "\nA denial of service vulnerability exists in all Silicon Labs Z-Wave controller and endpoint devices running Z-Wave SDK v7.20.3 (Gecko SDK v4.3.3) and earlier. This attack can be carried out only by devices on the network sending a stream of packets to the device.\n\n",
"id": "GHSA-c948-477j-77c3",
"modified": "2023-12-15T18:30:28Z",
"published": "2023-12-15T18:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-5310"
},
{
"type": "WEB",
"url": "https://github.com/SiliconLabs/gecko_sdk/releases"
},
{
"type": "WEB",
"url": "https://siliconlabs.lightning.force.com/sfc/servlet.shepherd/document/download/069Vm0000005E7EIAU?%20operationContext=S1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-C96H-CXX6-RMG9
Vulnerability from github – Published: 2024-05-18 00:30 – Updated: 2025-03-27 18:40In Tor Arti before 1.2.3, circuits sometimes incorrectly have a length of 3 (with full vanguards), aka TROVE-2024-004.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "tor-circmgr"
},
"ranges": [
{
"events": [
{
"introduced": "0.18.0"
},
{
"fixed": "0.18.1"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"0.18.0"
]
},
{
"package": {
"ecosystem": "crates.io",
"name": "arti"
},
"ranges": [
{
"events": [
{
"introduced": "1.2.2"
},
{
"fixed": "1.2.3"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"1.2.2"
]
}
],
"aliases": [
"CVE-2024-35313"
],
"database_specific": {
"cwe_ids": [
"CWE-130",
"CWE-754"
],
"github_reviewed": true,
"github_reviewed_at": "2024-05-20T16:37:19Z",
"nvd_published_at": "2024-05-17T22:15:07Z",
"severity": "MODERATE"
},
"details": "In Tor Arti before 1.2.3, circuits sometimes incorrectly have a length of 3 (with full vanguards), aka TROVE-2024-004.",
"id": "GHSA-c96h-cxx6-rmg9",
"modified": "2025-03-27T18:40:05Z",
"published": "2024-05-18T00:30:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35313"
},
{
"type": "PACKAGE",
"url": "https://gitlab.torproject.org/tpo/core/arti"
},
{
"type": "WEB",
"url": "https://gitlab.torproject.org/tpo/core/arti/-/blob/main/CHANGELOG.md#arti-123-15-may-2024"
},
{
"type": "WEB",
"url": "https://gitlab.torproject.org/tpo/core/arti/-/commit/1a89d5c9659d799a84dd3ff00fae530f5c8ba280"
},
{
"type": "WEB",
"url": "https://gitlab.torproject.org/tpo/core/arti/-/issues/1400"
},
{
"type": "WEB",
"url": "https://gitlab.torproject.org/tpo/core/arti/-/issues/1409"
},
{
"type": "WEB",
"url": "https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/TROVE"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2024-0339.html"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2024-0340.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Tor path lengths too short when \"full Vanguards\" configured"
}
GHSA-C9QP-272Q-MVF9
Vulnerability from github – Published: 2024-11-08 06:30 – Updated: 2025-11-04 00:31In the Linux kernel, the following vulnerability has been resolved:
virtio_pmem: Check device status before requesting flush
If a pmem device is in a bad status, the driver side could wait for host ack forever in virtio_pmem_flush(), causing the system to hang.
So add a status check in the beginning of virtio_pmem_flush() to return early if the device is not activated.
{
"affected": [],
"aliases": [
"CVE-2024-50184"
],
"database_specific": {
"cwe_ids": [
"CWE-754"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-08T06:15:15Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nvirtio_pmem: Check device status before requesting flush\n\nIf a pmem device is in a bad status, the driver side could wait for\nhost ack forever in virtio_pmem_flush(), causing the system to hang.\n\nSo add a status check in the beginning of virtio_pmem_flush() to return\nearly if the device is not activated.",
"id": "GHSA-c9qp-272q-mvf9",
"modified": "2025-11-04T00:31:57Z",
"published": "2024-11-08T06:30:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50184"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4ce662fe4be6fbc2595d9ef4888b2b6e778c99ed"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/59ac565c6277d4be6661e81ea6a7f3ca2c5e4e36"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6a5ca0ab94e13a1474bf7ad8437a975c2193618f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9a2bc9b6f929a2ce1ebe4d1a796ddab37568c5b4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b01793cc63dd39c8f12b9a3d8dc115fbebb19e2a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ce7a3a62cc533c922072f328fd2ea2fd7cb893d4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e25fbcd97cf52c3c9824d44b5c56c19673c3dd50"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-CC72-WC5X-7WMJ
Vulnerability from github – Published: 2025-02-14 18:30 – Updated: 2025-02-14 18:30Mattermost versions 9.11.x <= 9.11.6 fail to filter out DMs from the deleted channels endpoint which allows an attacker to infer user IDs and other metadata from deleted DMs if someone had manually marked DMs as deleted in the database.
{
"affected": [],
"aliases": [
"CVE-2025-0503"
],
"database_specific": {
"cwe_ids": [
"CWE-754"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-14T18:15:23Z",
"severity": "LOW"
},
"details": "Mattermost versions 9.11.x \u003c= 9.11.6 fail to filter out DMs from the deleted channels endpoint which allows an attacker to infer user IDs and other metadata from deleted DMs if someone had manually marked DMs as deleted in the database.",
"id": "GHSA-cc72-wc5x-7wmj",
"modified": "2025-02-14T18:30:53Z",
"published": "2025-02-14T18:30:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-0503"
},
{
"type": "WEB",
"url": "https://mattermost.com/security-updates"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-CCPP-J37G-5J85
Vulnerability from github – Published: 2025-12-16 06:30 – Updated: 2025-12-16 06:30CHOCO TEI WATCHER mini (IB-MCT001) contains an issue with improper check for unusual or exceptional conditions. When the Video Download feature is in a specific communication state, the product's resources may be consumed abnormally.
{
"affected": [],
"aliases": [
"CVE-2025-66357"
],
"database_specific": {
"cwe_ids": [
"CWE-754"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-16T05:16:14Z",
"severity": "MODERATE"
},
"details": "CHOCO TEI WATCHER mini (IB-MCT001) contains an issue with improper check for unusual or exceptional conditions. When the Video Download feature is in a specific communication state, the product\u0027s resources may be consumed abnormally.",
"id": "GHSA-ccpp-j37g-5j85",
"modified": "2025-12-16T06:30:19Z",
"published": "2025-12-16T06:30:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-66357"
},
{
"type": "WEB",
"url": "https://jvn.jp/en/vu/JVNVU92827367"
},
{
"type": "WEB",
"url": "https://www.inaba.co.jp/files/chocomini_vulnerability_newly_identified.pdf"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-CF97-GPJM-X8FJ
Vulnerability from github – Published: 2024-11-19 03:31 – Updated: 2025-11-04 00:32In the Linux kernel, the following vulnerability has been resolved:
ksmbd: Fix the missing xa_store error check
xa_store() can fail, it return xa_err(-EINVAL) if the entry cannot be stored in an XArray, or xa_err(-ENOMEM) if memory allocation failed, so check error for xa_store() to fix it.
{
"affected": [],
"aliases": [
"CVE-2024-50284"
],
"database_specific": {
"cwe_ids": [
"CWE-754"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-19T02:16:30Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: Fix the missing xa_store error check\n\nxa_store() can fail, it return xa_err(-EINVAL) if the entry cannot\nbe stored in an XArray, or xa_err(-ENOMEM) if memory allocation failed,\nso check error for xa_store() to fix it.",
"id": "GHSA-cf97-gpjm-x8fj",
"modified": "2025-11-04T00:32:03Z",
"published": "2024-11-19T03:31:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50284"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3abab905b14f4ba756d413f37f1fb02b708eee93"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/726c1568b9145fa13ee248df184b186c382a7ff8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c2a232c4f790f4bcd4d218904c56ac7a39a448f5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d8664ce789bd46290c59a00da6897252f92c237d"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-CHRH-M3H6-4898
Vulnerability from github – Published: 2025-07-10 09:32 – Updated: 2025-12-16 18:31In the Linux kernel, the following vulnerability has been resolved:
x86/sgx: Prevent attempts to reclaim poisoned pages
TL;DR: SGX page reclaim touches the page to copy its contents to secondary storage. SGX instructions do not gracefully handle machine checks. Despite this, the existing SGX code will try to reclaim pages that it knows are poisoned. Avoid even trying to reclaim poisoned pages.
The longer story:
Pages used by an enclave only get epc_page->poison set in arch_memory_failure() but they currently stay on sgx_active_page_list until sgx_encl_release(), with the SGX_EPC_PAGE_RECLAIMER_TRACKED flag untouched.
epc_page->poison is not checked in the reclaimer logic meaning that, if other conditions are met, an attempt will be made to reclaim an EPC page that was poisoned. This is bad because 1. we don't want that page to end up added to another enclave and 2. it is likely to cause one core to shut down and the kernel to panic.
Specifically, reclaiming uses microcode operations including "EWB" which accesses the EPC page contents to encrypt and write them out to non-SGX memory. Those operations cannot handle MCEs in their accesses other than by putting the executing core into a special shutdown state (affecting both threads with HT.) The kernel will subsequently panic on the remaining cores seeing the core didn't enter MCE handler(s) in time.
Call sgx_unmark_page_reclaimable() to remove the affected EPC page from sgx_active_page_list on memory error to stop it being considered for reclaiming.
Testing epc_page->poison in sgx_reclaim_pages() would also work but I assume it's better to add code in the less likely paths.
The affected EPC page is not added to &node->sgx_poison_page_list until later in sgx_encl_release()->sgx_free_epc_page() when it is EREMOVEd. Membership on other lists doesn't change to avoid changing any of the lists' semantics except for sgx_active_page_list. There's a "TBD" comment in arch_memory_failure() about pre-emptive actions, the goal here is not to address everything that it may imply.
This also doesn't completely close the time window when a memory error notification will be fatal (for a not previously poisoned EPC page) -- the MCE can happen after sgx_reclaim_pages() has selected its candidates or even inside a microcode operation (actually easy to trigger due to the amount of time spent in them.)
The spinlock in sgx_unmark_page_reclaimable() is safe because memory_failure() runs in process context and no spinlocks are held, explicitly noted in a mm/memory-failure.c comment.
{
"affected": [],
"aliases": [
"CVE-2025-38334"
],
"database_specific": {
"cwe_ids": [
"CWE-754"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-10T09:15:27Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nx86/sgx: Prevent attempts to reclaim poisoned pages\n\nTL;DR: SGX page reclaim touches the page to copy its contents to\nsecondary storage. SGX instructions do not gracefully handle machine\nchecks. Despite this, the existing SGX code will try to reclaim pages\nthat it _knows_ are poisoned. Avoid even trying to reclaim poisoned pages.\n\nThe longer story:\n\nPages used by an enclave only get epc_page-\u003epoison set in\narch_memory_failure() but they currently stay on sgx_active_page_list until\nsgx_encl_release(), with the SGX_EPC_PAGE_RECLAIMER_TRACKED flag untouched.\n\nepc_page-\u003epoison is not checked in the reclaimer logic meaning that, if other\nconditions are met, an attempt will be made to reclaim an EPC page that was\npoisoned. This is bad because 1. we don\u0027t want that page to end up added\nto another enclave and 2. it is likely to cause one core to shut down\nand the kernel to panic.\n\nSpecifically, reclaiming uses microcode operations including \"EWB\" which\naccesses the EPC page contents to encrypt and write them out to non-SGX\nmemory. Those operations cannot handle MCEs in their accesses other than\nby putting the executing core into a special shutdown state (affecting\nboth threads with HT.) The kernel will subsequently panic on the\nremaining cores seeing the core didn\u0027t enter MCE handler(s) in time.\n\nCall sgx_unmark_page_reclaimable() to remove the affected EPC page from\nsgx_active_page_list on memory error to stop it being considered for\nreclaiming.\n\nTesting epc_page-\u003epoison in sgx_reclaim_pages() would also work but I assume\nit\u0027s better to add code in the less likely paths.\n\nThe affected EPC page is not added to \u0026node-\u003esgx_poison_page_list until\nlater in sgx_encl_release()-\u003esgx_free_epc_page() when it is EREMOVEd.\nMembership on other lists doesn\u0027t change to avoid changing any of the\nlists\u0027 semantics except for sgx_active_page_list. There\u0027s a \"TBD\" comment\nin arch_memory_failure() about pre-emptive actions, the goal here is not\nto address everything that it may imply.\n\nThis also doesn\u0027t completely close the time window when a memory error\nnotification will be fatal (for a not previously poisoned EPC page) --\nthe MCE can happen after sgx_reclaim_pages() has selected its candidates\nor even *inside* a microcode operation (actually easy to trigger due to\nthe amount of time spent in them.)\n\nThe spinlock in sgx_unmark_page_reclaimable() is safe because\nmemory_failure() runs in process context and no spinlocks are held,\nexplicitly noted in a mm/memory-failure.c comment.",
"id": "GHSA-chrh-m3h6-4898",
"modified": "2025-12-16T18:31:29Z",
"published": "2025-07-10T09:32:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38334"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/00a88e9ea1b170d579c56327c38f7e8cf689df87"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/31dcbac94bfeabb86bf85b0c36803fdd6536437b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/62b62a2a6dc51ed6e8e334861f04220c9cf8106a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dc5de5bd6deabd327ced2b2b1d0b4f14cd146afe"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ed16618c380c32c68c06186d0ccbb0d5e0586e59"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-CJ48-543V-8FR9
Vulnerability from github – Published: 2022-05-06 00:00 – Updated: 2022-05-17 00:01On F5 BIG-IP 16.1.x versions prior to 16.1.2.2, 15.1.x versions prior to 15.1.5.1, 14.1.x versions prior to 14.1.4.6, and 13.1.x versions prior to 13.1.5, when an Active mode-enabled FTP profile is configured on a virtual server, undisclosed traffic can cause the virtual server to stop processing active FTP data channel connections. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated
{
"affected": [],
"aliases": [
"CVE-2022-26130"
],
"database_specific": {
"cwe_ids": [
"CWE-754"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-05-05T17:15:00Z",
"severity": "MODERATE"
},
"details": "On F5 BIG-IP 16.1.x versions prior to 16.1.2.2, 15.1.x versions prior to 15.1.5.1, 14.1.x versions prior to 14.1.4.6, and 13.1.x versions prior to 13.1.5, when an Active mode-enabled FTP profile is configured on a virtual server, undisclosed traffic can cause the virtual server to stop processing active FTP data channel connections. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated",
"id": "GHSA-cj48-543v-8fr9",
"modified": "2022-05-17T00:01:48Z",
"published": "2022-05-06T00:00:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-26130"
},
{
"type": "WEB",
"url": "https://support.f5.com/csp/article/K82034427"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-CJW7-M4QF-XC59
Vulnerability from github – Published: 2024-05-21 15:31 – Updated: 2025-04-29 21:31In the Linux kernel, the following vulnerability has been resolved:
x86/fpu: Prevent state corruption in __fpu__restore_sig()
The non-compacted slowpath uses __copy_from_user() and copies the entire user buffer into the kernel buffer, verbatim. This means that the kernel buffer may now contain entirely invalid state on which XRSTOR will #GP. validate_user_xstate_header() can detect some of that corruption, but that leaves the onus on callers to clear the buffer.
Prior to XSAVES support, it was possible just to reinitialize the buffer, completely, but with supervisor states that is not longer possible as the buffer clearing code split got it backwards. Fixing that is possible but not corrupting the state in the first place is more robust.
Avoid corruption of the kernel XSAVE buffer by using copy_user_to_xstate() which validates the XSAVE header contents before copying the actual states to the kernel. copy_user_to_xstate() was previously only called for compacted-format kernel buffers, but it works for both compacted and non-compacted forms.
Using it for the non-compacted form is slower because of multiple __copy_from_user() operations, but that cost is less important than robust code in an already slow path.
[ Changelog polished by Dave Hansen ]
{
"affected": [],
"aliases": [
"CVE-2021-47227"
],
"database_specific": {
"cwe_ids": [
"CWE-754"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-21T15:15:11Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nx86/fpu: Prevent state corruption in __fpu__restore_sig()\n\nThe non-compacted slowpath uses __copy_from_user() and copies the entire\nuser buffer into the kernel buffer, verbatim. This means that the kernel\nbuffer may now contain entirely invalid state on which XRSTOR will #GP.\nvalidate_user_xstate_header() can detect some of that corruption, but that\nleaves the onus on callers to clear the buffer.\n\nPrior to XSAVES support, it was possible just to reinitialize the buffer,\ncompletely, but with supervisor states that is not longer possible as the\nbuffer clearing code split got it backwards. Fixing that is possible but\nnot corrupting the state in the first place is more robust.\n\nAvoid corruption of the kernel XSAVE buffer by using copy_user_to_xstate()\nwhich validates the XSAVE header contents before copying the actual states\nto the kernel. copy_user_to_xstate() was previously only called for\ncompacted-format kernel buffers, but it works for both compacted and\nnon-compacted forms.\n\nUsing it for the non-compacted form is slower because of multiple\n__copy_from_user() operations, but that cost is less important than robust\ncode in an already slow path.\n\n[ Changelog polished by Dave Hansen ]",
"id": "GHSA-cjw7-m4qf-xc59",
"modified": "2025-04-29T21:31:33Z",
"published": "2024-05-21T15:31:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47227"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/076f732b16a5bf842686e1b43ab6021a2d98233e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/484cea4f362e1eeb5c869abbfb5f90eae6421b38"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ec25ea1f3f05d6f8ee51d1277efea986eafd4f2a"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
Mitigation MIT-3
Strategy: Language Selection
- Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
- Choose languages with features such as exception handling that force the programmer to anticipate unusual conditions that may generate exceptions. Custom exceptions may need to be developed to handle unusual business-logic conditions. Be careful not to pass sensitive exceptions back to the user (CWE-209, CWE-248).
Mitigation
Check the results of all functions that return a value and verify that the value is expected.
Mitigation
If using exception handling, catch and throw specific exceptions instead of overly-general exceptions (CWE-396, CWE-397). Catch and handle exceptions as locally as possible so that exceptions do not propagate too far up the call stack (CWE-705). Avoid unchecked or uncaught exceptions where feasible (CWE-248).
Mitigation MIT-39
- Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success.
- If errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files.
- Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not.
- Exposing additional information to a potential attacker in the context of an exceptional condition can help the attacker determine what attack vectors are most likely to succeed beyond DoS.
Mitigation MIT-5
Strategy: Input Validation
- Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
- When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
- Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
Mitigation MIT-38
If the program must fail, ensure that it fails gracefully (fails closed). There may be a temptation to simply let the program fail poorly in cases such as low memory conditions, but an attacker may be able to assert control before the software has fully exited. Alternately, an uncontrolled failure could cause cascading problems with other downstream components; for example, the program could send a signal to a downstream process so the process immediately knows that a problem has occurred and has a better chance of recovery.
Mitigation
Use system limits, which should help to prevent resource exhaustion. However, the product should still handle low resource conditions since they may still occur.
No CAPEC attack patterns related to this CWE.