VulnerabilityPublished 12 Aug 2026Updated 21 Oct 2026

CVE-2026-68448: Linux kernel · ovl: check access to copy_file_range source with src mounter creds

Affects Linux kernelSource CVE Database V5

Not known to be exploited · fixed in a1e0eb8f55cfe09bb31a202a388babc411292656 : update Linux kernel when convenient.

Data as of 26 Oct 2026, 13:47 UTC

Severity

Unrated

Rated by Threat Radar · CVSS not yet scored by NVD

EPSS: 0.1% chance of exploitation in 30 days – higher than 4% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch: Available – fixed in a1e0eb8f55cfe09bb31a202a388babc411292656, 46c296aa678828105842eee29a147508d803d926, 9ec22c8113d8cf72ed7197bb61037dcad09e50d8 +2

Exploitation evidence

Disclosed: evidence found.
CVE published 12 Aug 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

Disclosed: The CVE record is public on cve.org. Its publication is t = 0.
Detectable: A public nuclei template can find exposed instances, for defenders and attackers alike.
Weaponised: Public exploit code exists in Metasploit or Exploit-DB, or CISA SSVC or the CVSS exploit maturity reports a public proof of concept.
Exploited in the wild: CISA KEV lists it, CISA SSVC rates exploitation active, or a source reports attacks.
Observed by OffSeq Mirage: OffSeq Mirage honeypot sensors recorded attack traffic for this CVE, or found exposed hosts without attack traffic.

Moments are spaced evenly, not to scale; a dashed line marks a gap of six months or more. Deltas count from t = 0. Sources that give only a date (CISA KEV, Exploit-DB, or a time of exactly 00:00Z) read “same day” rather than hours. Metasploit modules carry the flaw’s disclosure date, not their release date, and nuclei templates carry no date, so both appear above but not on the timeline.

What to do

Upgrade to a fixed release listed under Affected software.

Affected software

Product	Affected	Fixed in
LinuxLinux	Affected ≥ 5dae222a5ff0c269730393018a5539cc970a4726, < a1e0eb8f55cfe09bb31a202a388babc411292656	Fixed in a1e0eb8f55cfe09bb31a202a388babc411292656
LinuxLinux	Affected ≥ 5dae222a5ff0c269730393018a5539cc970a4726, < 46c296aa678828105842eee29a147508d803d926	Fixed in 46c296aa678828105842eee29a147508d803d926
LinuxLinux	Affected ≥ 5dae222a5ff0c269730393018a5539cc970a4726, < 9ec22c8113d8cf72ed7197bb61037dcad09e50d8	Fixed in 9ec22c8113d8cf72ed7197bb61037dcad09e50d8
LinuxLinux	Affected ≥ 5dae222a5ff0c269730393018a5539cc970a4726, < 7e13e5b087375f1aee1e930503d20efa7084c0fa	Fixed in 7e13e5b087375f1aee1e930503d20efa7084c0fa
LinuxLinux	Affected ≥ 5dae222a5ff0c269730393018a5539cc970a4726, < 1f4a107439d2e43db176e34919933e617cb7f2c5	Fixed in 1f4a107439d2e43db176e34919933e617cb7f2c5
LinuxLinux	Affected =5.3	Fixed in–

Description

In the Linux kernel, the following vulnerability has been resolved: ovl: check access to copy_file_range source with src mounter creds Commit 5dae222a5ff0c ("vfs: allow copy_file_range to copy across devices") allowed filesystems that implement the copy_file_range() f_op to decide if they want to access cross-sb copy from/to the same fs type. The same commit added checks to verify same sb copy for filesystems that implement ->copy_file_range() and do not support cross-sb copy at the time, namely, to ceph, fuse and nfs. The two remaining fs which implement ->copy_file_range(), cifs and overlayfs started to support cross-sb copy from this time. While overlayfs does support cross-sb copy when the two underlying files are on the same base fs, the copy operation on the two real files from two different overalyfs filesystems is performed with the mounter creds of the destination overlayfs and the read permission access hook for the source file was called with the wrong creds. This could cause either deny of access to copy which would otherwise be allowed (e.g. with splice) or allow read access to file which would otherwise be denied. Fix the latter case by explicitly verifying read access to source file with the source overlayfs mounter creds. The former case remains a quirk of cross-sb overlayfs copy, but userspace could fall back to regular copy so no harm done.

References

Community reviews

Loading reviews…