Answer in brief
CVE-2024-36943 records a Unknown severity vulnerability in fs/proc/task_mmu: fix loss of young/dirty bits during pagemap scan. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=52526ca7fdb905a768a93f8faa418e9b988fc34b <74b3d66f91d9f539f99faad74d796fa9a389a015 || >=52526ca7fdb905a768a93f8faa418e9b988fc34b <c70dce4982ce1718bf978a35f8e26160b82081f4 | 74b3d66f91d9f539f99faad74d796fa9a389a015, c70dce4982ce1718bf978a35f8e26160b82081f4 |
| Linux/Linuxgeneric | 6.7 | Not reported |
Published upstream
May 30, 2024
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 5, 2026
In the Linux kernel, the following vulnerability has been resolved: fs/proc/task_mmu: fix loss of young/dirty bits during pagemap scan make_uffd_wp_pte() was previously doing: pte = ptep_get(ptep); ptep_modify_prot_start(ptep); pte = pte_mkuffd_wp(pte); ptep_modify_prot_commit(ptep, pte); But if another thread accessed or dirtied the pte between the first 2 calls, this could lead to loss of that information. Since ptep_modify_prot_start() gets and clears atomically, the following is the correct pattern and prevents any possible race. Any access after the first call would see an invalid pte and cause a fault: pte = ptep_modify_prot_start(ptep); pte = pte_mkuffd_wp(pte); ptep_modify_prot_commit(ptep, pte);
Quoted source text, attributed separately from HOL analysis.
Answer in brief
CVE-2024-36943 records a Unknown severity vulnerability in fs/proc/task_mmu: fix loss of young/dirty bits during pagemap scan. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=52526ca7fdb905a768a93f8faa418e9b988fc34b <74b3d66f91d9f539f99faad74d796fa9a389a015 || >=52526ca7fdb905a768a93f8faa418e9b988fc34b <c70dce4982ce1718bf978a35f8e26160b82081f4 | 74b3d66f91d9f539f99faad74d796fa9a389a015, c70dce4982ce1718bf978a35f8e26160b82081f4 |
| Linux/Linuxgeneric | 6.7 | Not reported |
Published upstream
May 30, 2024
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 5, 2026
In the Linux kernel, the following vulnerability has been resolved: fs/proc/task_mmu: fix loss of young/dirty bits during pagemap scan make_uffd_wp_pte() was previously doing: pte = ptep_get(ptep); ptep_modify_prot_start(ptep); pte = pte_mkuffd_wp(pte); ptep_modify_prot_commit(ptep, pte); But if another thread accessed or dirtied the pte between the first 2 calls, this could lead to loss of that information. Since ptep_modify_prot_start() gets and clears atomically, the following is the correct pattern and prevents any possible race. Any access after the first call would see an invalid pte and cause a fault: pte = ptep_modify_prot_start(ptep); pte = pte_mkuffd_wp(pte); ptep_modify_prot_commit(ptep, pte);
Quoted source text, attributed separately from HOL analysis.