GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration

GHSA-F7XG-FGXP-P6W3

Vulnerability from github – Published: 2026-08-15 06:32 – Updated: 2026-08-17 06:33
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

LoongArch: Fix missing dirty page tracking in {pte,pmd}_wrprotect()

When hardware page table walker (PTW) is enabled on LoongArch, the CPU may set _PAGE_DIRTY directly in the page table entry during a write TLB miss, without going through the software TLB store handler. The software TLB store handler (tlbex.S:254) sets both _PAGE_DIRTY and_PAGE_MODIFIED together:

ori t0, t0, (_PAGE_VALID | _PAGE_DIRTY | _PAGE_MODIFIED)

Since hardware PTW only sets _PAGE_DIRTY, the software-only bit, i.e. _PAGE_MODIFIED is left unchanged. This creates a window where a PTE has _PAGE_DIRTY set (hardware knows the page is dirty) but _PAGE_MODIFIED clear (software is unaware).

When fork()/clone() triggers copy-on-write, __copy_present_ptes() calls pte_wrprotect(), which unconditionally clears both the _PAGE_WRITE and _PAGE_DIRTY bits:

pte_val(pte) &= ~(_PAGE_WRITE | _PAGE_DIRTY);

Since _PAGE_MODIFIED was never set, the dirtiness information is lost completely. Subsequently, when memory pressure triggers page reclaim, page_mkclean() / try_to_unmap() sees the page as clean (i.e. pte_dirty() returns false) and the page may be freed without writeback, causing data corruption.

Fix this by propagating the _PAGE_DIRTY bit to the _PAGE_MODIFIED bit in both pte_wrprotect() and pmd_wrprotect() before clearing writeable bits:

if (pte_val(pte) & _PAGE_DIRTY)
    pte_val(pte) |= _PAGE_MODIFIED;

The pmd_wrprotect() fix handles the CONFIG_TRANSPARENT_HUGEPAGE case, where pmd entries need the same treatment.

This ensures the software dirty tracking bit (checked by pte_dirty() and pmd_dirty(), which read both the _PAGE_DIRTY and _PAGE_MODIFIED bits) is preserved across fork COW write-protection.

The issue was found by the LTP madvise09 test case, which exercises page reclaim after "madvise(MADV_FREE), write and fork" operation sequence on private anonymous mappings.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-72043"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-15T06:21:13Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nLoongArch: Fix missing dirty page tracking in {pte,pmd}_wrprotect()\n\nWhen hardware page table walker (PTW) is enabled on LoongArch, the CPU\nmay set _PAGE_DIRTY directly in the page table entry during a write TLB\nmiss, without going through the software TLB store handler. The software\nTLB store handler (tlbex.S:254) sets both _PAGE_DIRTY and_PAGE_MODIFIED\ntogether:\n\n    ori t0, t0, (_PAGE_VALID | _PAGE_DIRTY | _PAGE_MODIFIED)\n\nSince hardware PTW only sets _PAGE_DIRTY, the software-only bit, i.e.\n_PAGE_MODIFIED is left unchanged. This creates a window where a PTE has\n_PAGE_DIRTY set (hardware knows the page is dirty) but _PAGE_MODIFIED\nclear (software is unaware).\n\nWhen fork()/clone() triggers copy-on-write, __copy_present_ptes() calls\npte_wrprotect(), which unconditionally clears both the _PAGE_WRITE and\n_PAGE_DIRTY bits:\n\n    pte_val(pte) \u0026= ~(_PAGE_WRITE | _PAGE_DIRTY);\n\nSince _PAGE_MODIFIED was never set, the dirtiness information is lost\ncompletely. Subsequently, when memory pressure triggers page reclaim,\npage_mkclean() / try_to_unmap() sees the page as clean (i.e. pte_dirty()\nreturns false) and the page may be freed without writeback, causing data\ncorruption.\n\nFix this by propagating the _PAGE_DIRTY bit to the _PAGE_MODIFIED bit in\nboth pte_wrprotect() and pmd_wrprotect() before clearing writeable bits:\n\n    if (pte_val(pte) \u0026 _PAGE_DIRTY)\n        pte_val(pte) |= _PAGE_MODIFIED;\n\nThe pmd_wrprotect() fix handles the CONFIG_TRANSPARENT_HUGEPAGE case,\nwhere pmd entries need the same treatment.\n\nThis ensures the software dirty tracking bit (checked by pte_dirty() and\npmd_dirty(), which read both the _PAGE_DIRTY and _PAGE_MODIFIED bits) is\npreserved across fork COW write-protection.\n\nThe issue was found by the LTP madvise09 test case, which exercises page\nreclaim after \"madvise(MADV_FREE), write and fork\" operation sequence on\nprivate anonymous mappings.",
  "id": "GHSA-f7xg-fgxp-p6w3",
  "modified": "2026-08-17T06:33:06Z",
  "published": "2026-08-15T06:32:10Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72043"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/018e9828eb523c638fa3d9bdf0fd4956b74555b2"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/39bb21a4bff0d70058bf752d7b5aa2e2ccc864a9"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/76f88650763a35cbf1384c65d66d096fa31cc58d"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a65f49b6f7ece756394f8f0e85570020e7fd0e35"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e483da960892c41fa7f0cf0d2fc2410d65a483d6"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e8a916579e427af32f2de8213dfa23c5df6e6664"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…

Loading…