CVE-2026-98451

What it actually does

O_CREAT opens on existing non-regular inodes such as symlinks in the CIFS client cause cifsFileInfo to hold a dentry reference without a matching release operation, leaking the reference, while FMODE_OPENED blocks normal VFS symlink traversal.

Why it matters to the business

Systems mounting remote SMB shares may experience gradual memory exhaustion or unexpected failures when applications create files that collide with existing symlinks or special inodes, increasing operational risk on Linux servers and workstations that rely on CIFS.

How an attack unfolds

An attacker with the ability to create or influence file names on a remote SMB share triggers the client to perform an O_CREAT open against an existing symlink; the client incorrectly attaches tracking state and returns the handle without allowing VFS symlink resolution, leading to the reference leak on every such access.

How to fix it

Update the Linux kernel to a version containing the referenced fix for smb client non-regular inode handling; rebuild and reboot affected systems; verify CIFS mounts behave correctly after upgrade.

How to confirm the fix worked

Confirm the kernel version includes the commit that replaces finish_open with finish_no_open for non-regular inodes in cifs_atomic_open; test O_CREAT opens against existing symlinks on CIFS mounts to ensure no dentry leaks and correct -ELOOP behavior with O_NOFOLLOW.

Typical attack path

1. Attacker places or predicts a symlink at a path an application will open with O_CREAT via CIFS mount
2. Victim application issues open(O_CREAT) on that path
3. CIFS client calls cifs_atomic_open and finish_open on the non-regular inode
4. Dentry reference is retained without release operation and FMODE_OPENED is set
5. Repeated accesses accumulate leaks until memory pressure or incorrect symlink behavior manifests

How to detect it

Search kernel logs and audit records for repeated cifs_atomic_open or cifs_do_create entries involving non-regular inodes; inspect slab or dentry cache growth correlated with CIFS mount activity; look for applications receiving unexpected -ELOOP or failing to traverse symlinks on SMB paths.

What your security team should do

• Prioritize kernel updates on all Linux systems with active CIFS/SMB mounts within normal patch windows
• Monitor memory usage on CIFS clients for unexplained dentry or inode cache growth
• Review application code that performs unconditional O_CREAT opens on network shares for safer patterns