Cloudanix VulnDB

CVE-2026-89767

High · 7.8

CVSS

7.8

EPSS

0.2%

Published

Sep 11, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A bug in the Linux overlay filesystem can let a regular user freeze directory creation for everyone sharing the same mount, requiring a kernel update to restore normal operation.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Denial Of Service
Component
OS kernel
Class
Memory Corruption
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Double call to end_creating() (end_dirop) on casefold-mismatch error path in ovl_create_real releases the parent i_rwsem twice and dputs the dentry twice, causing an unbalanced unlock and reference drop.

Why it matters to the business

Unprivileged local users can wedge directory creation under an overlay mount, leading to denial of service for any workload that performs file or directory creation in the affected overlay.

How an attack unfolds

An attacker creates an overlay with a workdir whose internal work subdirectory is marked casefolded after mount, then triggers a directory copy-up that reaches ovl_create_real via ovl_start_creating_temp; the casefold mismatch path executes the first end_creating while the common error path executes it again, leaving the parent locked state corrupted and subsequent operations blocked on the semaphore.

How to fix it

Apply the upstream fix that removes the erroneous end_creating call inside the casefold-mismatch branch so that the common out: label owns cleanup for all error paths; rebuild and deploy the corrected kernel.

How to confirm the fix worked

Confirm the patch is present by inspecting ovl_create_real for a single end_creating call on the error path; attempt the published reproducer (unshare+mount+chattr+mkdir) and verify it no longer hangs; run kernel selftests for overlayfs casefold handling.

Typical attack path

  1. Mount an overlay filesystem whose workdir work/ subdirectory has casefold attribute set after mount validation
  2. Perform an operation that triggers copy-up of a directory (e.g., mkdir inside a lower-layer directory)
  3. ovl_create_temp calls ovl_start_creating_temp then ovl_create_real
  4. Casefold mismatch branch calls end_creating and sets error
  5. Common out: label calls end_creating again on the same dentry
  6. Parent i_rwsem is unlocked without being held and dentry reference is dropped without having been taken
  7. All subsequent creation attempts under that parent block indefinitely

How to detect it

Search kernel logs for the ratelimited warning 'overlay: wrong inherited casefold' followed by processes blocked in start_creating or ovl_start_creating_temp; inspect /proc/lockdep or hung-task backtraces showing repeated overlay create paths.

  • overlay: wrong inherited casefold
  • start_creating+0x65
  • ovl_start_creating_temp
  • ovl_create_temp

What your security team should do

  • Prioritize kernel update on any system exposing overlay mounts to untrusted local users
  • Audit workloads that use overlayfs with casefold-enabled tmpfs or ext4 workdirs
  • Add monitoring for processes stuck in start_creating or ovl_create_temp

The record

In the Linux kernel, the following vulnerability has been resolved: ovl: fix double end_creating() on the casefold-mismatch path ovl_create_real() releases the new dentry twice when the casefold consistency check fails. The S_IFDIR branch calls end_creating() and sets err, then falls through to the common out: label which calls end_creating() on the same dentry again: case S_IFDIR: newdentry = ovl_do_mkdir(ofs, dir, newdentry, attr->mode); err = PTR_ERR_OR_ZERO(newdentry); if (!err && ofs->casefold != ovl_dentry_casefolded(newdentry)) { pr_warn_ratelimited(...); end_creating(newdentry); /* first */ err = -EINVAL; } break; ... if (err) goto out; ... out: if (err) { end_creating(newdentry); /* second, same dentry */ return ERR_PTR(err); } end_creating() is end_dirop(), which does inode_unlock() on the parent and dput() on the dentry, so the parent directory's i_rwsem is unlocked twice and the dentry is put twice. The second unlock releases a lock that is not held, which is what wedges every later creation under that parent, and the second dput() drops a reference that was never taken. The branch was added by commit dfc7da402ccc ("ovl: Check for casefold consistency when creating new dentries") as a bare dput(), which already released the reference twice; commit fe497f0759e0 ("VFS: change vfs_mkdir() to unlock on failure.") converted both sites to end_creating(), adding the double unlock. This is reachable by an unprivileged user. The casefold consistency of the layers is validated at mount time in ovl_parse_layer(), and again on every lookup in ovl_lookup_single(), but ofs->workdir is the internal "work" subdirectory created inside the user-supplied workdir, and that subdirectory is not re-checked. Marking it casefolded after the mount therefore makes every ovl_create_temp() inherit the wrong state - and that path reaches ovl_create_real() through ovl_start_creating_temp(), which uses start_creating() with a generated name and so never runs the lookup-time check. unshare -Urm mount -t tmpfs -o casefold=utf8-12.1.0 tmpfs mnt mkdir -p mnt/lower/d mnt/upper mnt/work mnt/merged mount -t overlay ovl -o lowerdir=mnt/lower,\ upperdir=mnt/upper,workdir=mnt/work mnt/merged chattr +F mnt/work/work mkdir mnt/merged/d/sub # directory copy-up overlayfs: wrong inherited casefold (work/#5) and the next copy-up blocks forever on the parent's i_rwsem: mkdir D start_creating+0x65/0xb0 ovl_start_creating_temp+0xb0/0xe0 [overlay] ovl_create_temp+0xa3/0x1d0 [overlay] ovl_copy_up_one+0x1f1c/0x21c0 [overlay] ovl_copy_up_flags+0xf5/0x140 [overlay] ovl_create_object+0xb7/0x220 [overlay] ovl_mkdir+0x23/0x40 [overlay] Drop the end_creating() from the branch and let out: own the cleanup, which is what every other error path in this function already does.

Affected packages

Ecosystem Package Introduced Fixed