{"api_version":"1","generated_at":"2026-11-09T01:40:33+00:00","cve":"CVE-2025-39989","urls":{"html":"https://cve.report/CVE-2025-39989","api":"https://cve.report/api/cve/CVE-2025-39989.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2025-39989","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2025-39989"},"summary":{"title":"x86/mce: use is_copy_from_user() to determine copy-from-user context","description":"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's not an urgent problem that no core is on the verge of consuming that\nbad data.  It's 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't 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---","state":"PUBLISHED","assigner":"Linux","published_at":"2025-04-18 07:15:44","updated_at":"2026-11-05 22:17:35"},"problem_types":["CWE-401"],"metrics":[{"version":"3.1","source":"nvd@nist.gov","type":"Primary","score":"5.5","severity":"MEDIUM","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","data":{"version":"3.1","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","baseScore":5.5,"baseSeverity":"MEDIUM","attackVector":"LOCAL","attackComplexity":"LOW","privilegesRequired":"LOW","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"NONE","integrityImpact":"NONE","availabilityImpact":"HIGH"}}],"references":[{"url":"https://git.kernel.org/stable/c/3e3d8169c0950a0b3cd5105f6403a78350dcac80","name":"https://git.kernel.org/stable/c/3e3d8169c0950a0b3cd5105f6403a78350dcac80","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":["Patch"],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/7a1168257e81954fa1b5b1ce86f47d2567e734ab","name":"https://git.kernel.org/stable/c/7a1168257e81954fa1b5b1ce86f47d2567e734ab","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/1a15bb8303b6b104e78028b6c68f76a0d4562134","name":"https://git.kernel.org/stable/c/1a15bb8303b6b104e78028b6c68f76a0d4562134","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":["Patch"],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/449413da90a337f343cc5a73070cbd68e92e8a54","name":"https://git.kernel.org/stable/c/449413da90a337f343cc5a73070cbd68e92e8a54","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":["Patch"],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/5724654a084f701dc64b08d34a0e800f22f0e6e4","name":"https://git.kernel.org/stable/c/5724654a084f701dc64b08d34a0e800f22f0e6e4","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":["Patch"],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/0b8388e97ba6a8c033f9a8b5565af41af07f9345","name":"https://git.kernel.org/stable/c/0b8388e97ba6a8c033f9a8b5565af41af07f9345","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":["Patch"],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2025-39989","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39989","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 4c132d1d844a53fc4e4b5c34e36ef10d6124b783 7a1168257e81954fa1b5b1ce86f47d2567e734ab git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 4c132d1d844a53fc4e4b5c34e36ef10d6124b783 5724654a084f701dc64b08d34a0e800f22f0e6e4 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 4c132d1d844a53fc4e4b5c34e36ef10d6124b783 3e3d8169c0950a0b3cd5105f6403a78350dcac80 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 4c132d1d844a53fc4e4b5c34e36ef10d6124b783 449413da90a337f343cc5a73070cbd68e92e8a54 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 4c132d1d844a53fc4e4b5c34e36ef10d6124b783 0b8388e97ba6a8c033f9a8b5565af41af07f9345 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 4c132d1d844a53fc4e4b5c34e36ef10d6124b783 1a15bb8303b6b104e78028b6c68f76a0d4562134 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 88eded8104d2ca0429703755dd250f8cbecc1447 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 5.15.58 5.16 semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 5.17","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 5.17 semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.1.191 6.1.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.6.89 6.6.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.12.23 6.12.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.13.11 6.13.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.14.2 6.14.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.15 * original_commit_for_fix","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[],"nvd_cpes":[{"cve_year":"2025","cve_id":"39989","vulnerable":"1","versionEndIncluding":"","cpe1":"cpe","cpe2":"2.3","cpe3":"o","cpe4":"linux","cpe5":"linux_kernel","cpe6":"*","cpe7":"*","cpe8":"*","cpe9":"*","cpe10":"*","cpe11":"*","cpe12":"*","cpe13":"*"}],"vendor_comments":[],"enrichments":{"kev":null,"epss":null,"legacy_qids":[]},"source_records":{"cve_program":{"containers":{"adp":[{"metrics":[{"other":{"content":{"id":"CVE-2025-39989","options":[{"Exploitation":"none"},{"Automatable":"no"},{"Technical Impact":"partial"}],"role":"CISA Coordinator","timestamp":"2026-11-05T21:13:35.533126Z","version":"2.0.3"},"type":"ssvc"}}],"providerMetadata":{"dateUpdated":"2026-11-05T21:23:07.520Z","orgId":"134c704f-9b21-4f2e-91b3-4a467353bcc0","shortName":"CISA-ADP"},"title":"CISA ADP Vulnrichment"}],"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":"7a1168257e81954fa1b5b1ce86f47d2567e734ab","status":"affected","version":"4c132d1d844a53fc4e4b5c34e36ef10d6124b783","versionType":"git"},{"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"},{"lessThan":"5.16","status":"affected","version":"5.15.58","versionType":"semver"}]},{"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.1.*","status":"unaffected","version":"6.1.191","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.1.191","versionStartIncluding":"5.17","vulnerable":true},{"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's not an urgent problem that no core is on the verge of consuming that\nbad data.  It's 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't 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":"2026-10-30T12:22:41.709Z","orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux"},"references":[{"url":"https://git.kernel.org/stable/c/7a1168257e81954fa1b5b1ce86f47d2567e734ab"},{"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":"2026-11-05T21:23:07.520Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2025-04-18 07:15:44","lastModifiedDate":"2026-11-05 22:17:35","problem_types":["CWE-401"],"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:N/A:H","baseScore":5.5,"baseSeverity":"MEDIUM","attackVector":"LOCAL","attackComplexity":"LOW","privilegesRequired":"LOW","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"NONE","integrityImpact":"NONE","availabilityImpact":"HIGH"},"exploitabilityScore":1.8,"impactScore":3.6}],"ssvcV203":[{"source":"134c704f-9b21-4f2e-91b3-4a467353bcc0","ssvcData":{"timestamp":"2026-11-05T21:13:35.533126Z","id":"CVE-2025-39989","options":[{"exploitation":"none"},{"automatable":"no"},{"technicalImpact":"partial"}],"role":"CISA Coordinator","version":"2.0.3"}}]},"configurations":[{"nodes":[{"operator":"OR","negate":false,"cpeMatch":[{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"5.15.58","versionEndExcluding":"5.16","matchCriteriaId":"B538ABF8-E348-4E1D-BA4F-0666014585B9"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"5.17","versionEndExcluding":"6.6.89","matchCriteriaId":"5574C785-D3F1-4E95-8EFD-846610F67BAA"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.7","versionEndExcluding":"6.12.23","matchCriteriaId":"26CAB76D-F00F-43CE-BEAD-7097F8FB1D6C"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.13","versionEndExcluding":"6.13.11","matchCriteriaId":"E7E864B0-8C00-4679-BA55-659B4C9C3AD3"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.14","versionEndExcluding":"6.14.2","matchCriteriaId":"FADAE5D8-4808-442C-B218-77B2CE8780A0"}]}]}]},"legacy_mitre":{"record":{"CveYear":"2025","CveId":"39989","Ordinal":"1","Title":"x86/mce: use is_copy_from_user() to determine copy-from-user con","CVE":"CVE-2025-39989","Year":"2025"},"notes":[{"CveYear":"2025","CveId":"39989","Ordinal":"1","NoteData":"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's not an urgent problem that no core is on the verge of consuming that\nbad data.  It's 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't 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---","Type":"Description","Title":"x86/mce: use is_copy_from_user() to determine copy-from-user con"}]}}}