CVE-2025-68736 json
landlock: Fix handling of disconnected directories
published 10mo ago modified 24d ago also EUVD-2025-205226
- cvss
- 8.8
- version 3.1, CNA
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- 0.1%
- EPSS 0.1% chance of exploitation in 30 days, percentile 3%
- public exploits
- 0
- none known
Summary
In the Linux kernel, the following vulnerability has been resolved:
landlock: Fix handling of disconnected directories
Disconnected files or directories can appear when they are visible and opened from a bind mount, but have been renamed or moved from the source of the bind mount in a way that makes them inaccessible from the mount point (i.e. out of scope).
Previously, access rights tied to files or directories opened through a disconnected directory were collected by walking the related hierarchy down to the root of the filesystem, without taking into account the mount point because it couldn't be found. This could lead to inconsistent access results, potential access right widening, and hard-to-debug renames, especially since such paths cannot be printed.
For a sandboxed task to create a disconnected directory, it needs to have write access (i.e. FS_MAKE_REG, FS_REMOVE_FILE, and FS_REFER) to the underlying source of the bind mount, and read access to the related mount point. Because a sandboxed task cannot acquire more access rights than those defined by its Landlock domain, this could lead to inconsistent access rights due to missing permissions that should be inherited from the mount point hierarchy, while inheriting permissions from the filesystem hierarchy hidden by this mount point instead.
Landlock now handles files and directories opened from disconnected directories by taking into account the filesystem hierarchy when the mount point is not found in the hierarchy walk, and also always taking into account the mount point from which these disconnected directories were opened. This ensures that a rename is not allowed if it would widen access rights [1].
The rationale is that, even if disconnected hierarchies might not be visible or accessible to a sandboxed task, relying on the collected access rights from them improves the guarantee that access rights will not be widened during a rename because of the access right comparison between the source and the destination (see LANDLOCK_ACCESS_FS_REFER). It may look like this would grant more access on disconnected files and directories, but the security policies are always enforced for all the evaluated hierarchies. This new behavior should be less surprising to users and safer from an access control perspective.
Remove a wrong WARN_ON_ONCE() canary in collect_domain_accesses() and fix the related comment.
Because opened files have their access rights stored in the related file security properties, there is no impact for disconnected or unlinked files.
Patch / fix
- Linux Linux 6.1.189, 6.6.143, 6.12.80, 6.18.2, 6.19
- linux Debian 12 6.1.190-1
- linux Debian 13 6.12.85-1
- linux Debian 14 6.18.3-1
debian advisories DEBIAN-CVE-2025-68736
- linux Ubuntu 24.04 LTS 6.8.0-136.136
- linux Ubuntu 25.10 6.17.0-22.22
- linux-aws Ubuntu 24.04 LTS 6.8.0-1061.64
- linux-aws Ubuntu 25.10 6.17.0-1012.12
- linux-gcp Ubuntu 24.04 LTS 6.8.0-1064.72
- linux-gcp Ubuntu 25.10 6.17.0-1012.12
- linux-gke Ubuntu 24.04 LTS 6.8.0-1059.67
- linux-ibm Ubuntu 24.04 LTS 6.8.0-1061.62
ubuntu advisories UBUNTU-CVE-2025-68736
Ubuntu security data © Canonical Ltd., from https://github.com/canonical/ubuntu-security-notices via OSV; changed: normalised to fixed package versions per release. CC BY-SA 4.0
- kernel-64kb SLE Module for Basesystem 15 SP7 6.4.0-150700.53.34.1
- kernel-syms SLE Module for Development Tools 15 SP7 6.4.0-150700.53.34.1
- kernel-azure SLE Module for Public Cloud 15 SP7 6.4.0-150700.53.34.1
- kernel-source SLE Module for Development Tools 15 SP7, SLE Module for Basesystem 15 SP7 6.4.0-150700.53.34.1
- kernel-default SLE Workstation Extension 15 SP7, SLE Module for Legacy 15 SP7, SLE Module for Basesystem 15 SP7 +2 more 6.4.0-150700.53.34.1
- kernel-zfcpdump SLE Module for Basesystem 15 SP7 6.4.0-150700.53.34.1
- kernel-obs-build SLE Module for Development Tools 15 SP7 6.4.0-150700.53.34.1
- kernel-default-base SLE Module for Basesystem 15 SP7 6.4.0-150700.53.34.1.150700.17.23.1
suse advisories SUSE-SU-2026:1081-1SUSE-SU-2026:20845-1SUSE-SU-2026:20876-1SUSE-SU-2026:0962-1SUSE-SU-2026:20720-1SUSE-SU-2026:20667-1
- kernel-source-longterm openSUSE Tumbleweed 6.18.16-1.1
- kernel-rt openSUSE Leap 16.0 6.12.0-160000.9.1
- dtb-aarch64 openSUSE Leap 16.0 6.12.0-160000.9.1
- kernel-64kb openSUSE Leap 16.0 6.12.0-160000.9.1
- kernel-syms openSUSE Leap 16.0 6.12.0-160000.9.1
- kernel-azure openSUSE Leap 16.0 6.12.0-160000.9.1
- kernel-obs-qa openSUSE Leap 16.0 6.12.0-160000.9.1
- kernel-source openSUSE Leap 16.0 6.12.0-160000.9.1
opensuse advisories openSUSE-SU-2026:10301-1openSUSE-SU-2026:20145-1openSUSE-SU-2026:10039-1
- git.kernel.org/stable/c/4f5cdc82a6c7e22cfd9a92d203cec13a52a3f363 commit
- git.kernel.org/stable/c/fbf718d5afe21057694a0c0223a18b0c7a5960b6 commit
- git.kernel.org/stable/c/426d5b681b2f3339ff04da39b81d71176dc8c87c commit
- git.kernel.org/stable/c/cadb28f8b3fd6908e3051e86158c65c3a8e1c907 commit
- git.kernel.org/stable/c/49c9e09d961025b22e61ef9ad56aa1c21b6ce2f1 commit
Is CVE-2025-68736 in your stack? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.
Check with FencerVendor advisories
What the vendors themselves say about their products: affected, fixed or not affected, and what to do.
red hat product security vex CVE-2025-68736 updated cvss 6.1
kernel: landlock: Fix handling of disconnected directories
-
Red Hat Enterprise Linux 9 rv, perf, rtla, kernel, bpftool, libperf, +83 more Red Hat Enterprise Linux 10 kernelaffected: no fix available “Fix deferred”
-
Red Hat Enterprise Linux 6 perf, kernel, python-perf, kernel-kdump, kernel-firmware, kernel-bootwrapper, +1 more Red Hat Enterprise Linux 7 perf, kernel, bpftool, kernel-rt, python-perf, kernel-kdump, +8 more Red Hat Enterprise Linux 8 perf, kernel, bpftool, kernel-rt, kernel-core, kernel-tools, +29 morenot affected: vulnerable code not present
Red Hat CSAF VEX © Red Hat, Inc., from https://security.access.redhat.com/data/csaf/v2/vex/; changed: reduced to product statuses and remediations. CC BY 4.0 · csaf
CISA SSVC
- Exploitation
- none
- Automatable
- no
- Technical impact
- total
- Assessed
- 24d ago
Exploit prediction
0.14% chance of exploitation in the next 30 days, higher than 3% of all scored CVEs (FIRST EPSS, 2026-11-09).
CVSS scores
| assigned by | version | score | vector |
|---|---|---|---|
| CNA | 3.1 | 8.8 | CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H |
Affected products
- Linux Linux
Classification
- Technology feeds
References
- git.kernel.org /stable/c/4f5cdc82a6c7e22cfd9a92d203cec13a52a3f363
- git.kernel.org /stable/c/fbf718d5afe21057694a0c0223a18b0c7a5960b6
- git.kernel.org /stable/c/426d5b681b2f3339ff04da39b81d71176dc8c87c
- git.kernel.org /stable/c/cadb28f8b3fd6908e3051e86158c65c3a8e1c907
- git.kernel.org /stable/c/49c9e09d961025b22e61ef9ad56aa1c21b6ce2f1
Sources
- CVE List CVE-2025-68736
- NVD CVE-2025-68736
Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.