CVE-2026-89767

linux: In the Linux kernel, the following vulnerability has been resolved: ovl: fix double end_creating() on the casefold-m...

CVE-2026-89767 is fixed in 20 products on 1 platform, first by DEBIAN-CVE-2026-89767, released September 23, 2026. It is not reported as exploited. Patch Radar priority: High.

High
CVSS
7.8
high
Exploitation
None reported
No vendor assessment
CISA KEV
Not listed
Not in the Known Exploited Vulnerabilities catalog
EPSS
0.0017
6th percentile

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.

Where it's fixed

ProductFixed inFixReleased
Linux
bpftool6.18 · amzn 2023 1:6.18.51-120.162.amzn2023 ALAS2023-2026-3187 Nov 7, 2026
bpftool6.18-debuginfo · amzn 2023 1:6.18.51-120.162.amzn2023 ALAS2023-2026-3187 Nov 7, 2026
kernel-livepatch-6.18.51-120.162 · amzn 2023 1:1.0-0.amzn2023 ALAS2023-2026-3187 Nov 7, 2026
kernel6.18 · amzn 2023 1:6.18.51-120.162.amzn2023 ALAS2023-2026-3187 Nov 7, 2026
kernel6.18-debuginfo · amzn 2023 1:6.18.51-120.162.amzn2023 ALAS2023-2026-3187 Nov 7, 2026
kernel6.18-debuginfo-common-aarch64 · amzn 2023 1:6.18.51-120.162.amzn2023 ALAS2023-2026-3187 Nov 7, 2026
kernel6.18-debuginfo-common-x86_64 · amzn 2023 1:6.18.51-120.162.amzn2023 ALAS2023-2026-3187 Nov 7, 2026
kernel6.18-devel · amzn 2023 1:6.18.51-120.162.amzn2023 ALAS2023-2026-3187 Nov 7, 2026
kernel6.18-headers · amzn 2023 1:6.18.51-120.162.amzn2023 ALAS2023-2026-3187 Nov 7, 2026
kernel6.18-modules-extra · amzn 2023 1:6.18.51-120.162.amzn2023 ALAS2023-2026-3187 Nov 7, 2026
kernel6.18-modules-extra-common · amzn 2023 1:6.18.51-120.162.amzn2023 ALAS2023-2026-3187 Nov 7, 2026
kernel6.18-tools · amzn 2023 1:6.18.51-120.162.amzn2023 ALAS2023-2026-3187 Nov 7, 2026
kernel6.18-tools-debuginfo · amzn 2023 1:6.18.51-120.162.amzn2023 ALAS2023-2026-3187 Nov 7, 2026
kernel6.18-tools-devel · amzn 2023 1:6.18.51-120.162.amzn2023 ALAS2023-2026-3187 Nov 7, 2026
linux · Debian 14 7.2.6-1 DEBIAN-CVE-2026-89767 Sep 23, 2026
microvm-kernel6.18 · amzn 2023 1:6.18.51-120.162.amzn2023 ALAS2023-2026-3187 Nov 7, 2026
perf6.18 · amzn 2023 1:6.18.51-120.162.amzn2023 ALAS2023-2026-3187 Nov 7, 2026
perf6.18-debuginfo · amzn 2023 1:6.18.51-120.162.amzn2023 ALAS2023-2026-3187 Nov 7, 2026
python3-perf6.18 · amzn 2023 1:6.18.51-120.162.amzn2023 ALAS2023-2026-3187 Nov 7, 2026
python3-perf6.18-debuginfo · amzn 2023 1:6.18.51-120.162.amzn2023 ALAS2023-2026-3187 Nov 7, 2026

Patch Radar data is free to use with attribution. Terms and how to credit it.

Product names, logos and trademarks shown on Patch Radar belong to their respective owners. They are used only to identify the software each security fix applies to and to help readers find their platform. Their use does not imply any affiliation with, or endorsement by, those owners, and Patchblox is not affiliated with any of them.