CVE-2026-68086

Source
https://cve.org/CVERecord?id=CVE-2026-68086
Import Source
https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-68086.json
JSON Data
https://api.osv.dev/v1/vulns/CVE-2026-68086
Downstream
Published
2026-08-10T11:51:40.304Z
Modified
2026-08-12T04:18:45.295097285Z
Summary
mm/khugepaged: write all dirty file folios when collapsing
Details

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

mm/khugepaged: write all dirty file folios when collapsing

[There is no upstream commit, as this code was removed by upstream commit 044925f9b565 ("mm: fs: remove filemapnrthps*() functions and their users")]

As-is, khugepaged and writable-file opening exclude each other. A file cannot be open writeable and have THPs (because the filesystem is not aware of them). khugepaged will never collapse file pages for files that are opened writeable. On an open(ORDWR/OWRONLY), the page cache for that particular file is dropped. This is fine because nothing could've been dirtied.

However, there is an edge-case: collapse_file() might not be able to coexist with concurrent writers, but it can coexist with dirty folios (from previous writers). Therefore, the following can happen:

open(file, ORDWR) write(file) close(file) madvise(filemapping, MADVCOLLAPSE, some non-dirty range) open(file, ORDWR) nrthps > 0 truncateinode_pages() /* THPs are cleared out, but so are the dirty folios */

When this edge-case happens, there is data loss, as the dirty folios are fully discarded.

Fix it by fully writing back the page cache (and waiting) when collapsing file THPs. Doing so provides the guarantee that no dirty folio will be observed while there are active THPs. To fully ensure this is safe, the invalidatelock needs to be held while doing the writeout, so that dodentry_open()'s page cache truncation excludes this write-and-wait.

As a side effect, move the nrthps counter bumping outside the ipages lock. This is correct since the counter itself is an atomict and the producer <-> consumer correctness is provided by a full memory barrier: smpmb() in collapsefile()/memory barrier implied by full ordering in getwriteaccess() -> atomicincunlessnegative().

Database specific
{
    "osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/68xxx/CVE-2026-68086.json",
    "cna_assigner": "Linux"
}
References

Affected packages

Git / git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git

Affected ranges

Type
GIT
Repo
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Events
Introduced
99cb0dbd47a15d395bf3faa78dc122bc5efe3fc0
Fixed
2dfe9f5c91d0963058f8a5e46e1c2a908382cc46

Database specific

source
"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-68086.json"

Linux / Kernel

Package

Name
Kernel

Affected ranges

Type
ECOSYSTEM
Events
Introduced
5.4.0
Fixed
7.1.4

Database specific

source
"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-68086.json"