Linux KernelOperating system · Linux

CVE-2026-31444

CRITICAL · 9.8 CVSS v3.1 Published 2026-04-22
Fix available
A fix is available. Upgrade to 6.12.80 / 6.18.21 or later.
See remediation →
100/100
Remediation priority · Urgent
Remotely reachable No privileges Zero-click Patch available

Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.

NVD · unedited
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free and NULL deref in smb_grant_oplock() smb_grant_oplock() has two issues in the oplock publication sequence: 1) opinfo is linked into ci->m_op_list (via opinfo_add) before add_lease_global_list() is called. If add_lease_global_list() fails (kmalloc returns NULL), the error path frees the opinfo via __free_opinfo() while it is still linked in ci->m_op_list. Concurrent m_op_list readers (opinfo_get_list, or direct iteration in smb_break_all_levII_oplock) dereference the freed node. 2) opinfo->o_fp is assigned after add_lease_global_list() publishes the opinfo on the global lease list. A concurrent find_same_lease_key() can walk the lease list and dereference opinfo->o_fp->f_ci while o_fp is still NULL. Fix by restructuring the publication sequence to eliminate post-publish failure: - Set opinfo->o_fp before any list publication (fixes NULL deref). - Preallocate lease_table via alloc_lease_table() before opinfo_add() so add_lease_global_list() becomes infallible after publication. - Keep the original m_op_list publication order (opinfo_add before lease list) so concurrent opens via same_client_has_lease() and opinfo_get_list() still see the in-flight grant. - Use opinfo_put() instead of __free_opinfo() on err_out so that the RCU-deferred free path is used. This also requires splitting add_lease_global_list() to take a preallocated lease_table and changing its return type from int to void, since it can no longer fail.

Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.

dbcve analysis · high confidence

In the Linux kernel's ksmbd (SMB server), the smb_grant_oplock() function has a race condition where it publishes an oplock info structure to lists before fully initializing it. If memory allocation fails during add_lease_global_list(), the error handler frees the structure via __free_oplock() while it's still linked in ci->m_op_list, causing a use-after-free when concurrent readers access the freed node. Additionally, opinfo->o_fp is assigned after the lease list publication, allowing find_same_lease_key() to dereference a NULL pointer.

MitigationApply the kernel patch that restructures the oplock publication sequence to initialize opinfo->o_fp before list publication, preallocates the lease_table to make add_lease_global_list() infallible, and uses opinfo_put() instead of __free_opinfo() for proper RCU-deferred cleanup.

Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.

Affected products & versions What the vendor confirmedThe version ranges the vendor confirmed as vulnerable. If your version sits inside a range here, treat yourself as exposed until you have upgraded.

NVD · CPE data
Linux KernelOperating system
Affected:>= 6.12.78, < 6.12.80>= 6.18.19, < 6.18.21>= 6.19.9, < 6.19.11= 6.6.130= 7.0

CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.

From the vector
Attack vector
Network
Complexity
Low
Privileges
None
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.

dbcve checks

Work through these to decide whether this CVE applies to you.

  1. Check kernel version against affected ranges
    Run `uname -r` or `cat /proc/version` and compare to the affected versions: 6.12.78 to 6.12.79, 6.18.19 to 6.18.20, 6.19.9 to 6.19.10, 6.6.130, or 7.0
    Affected if The running kernel version matches any of the affected version ranges
  2. Verify ksmbd is loaded
    Run `lsmod | grep ksmbd` for the kernel module, or check for ksmbd-process via `ps aux | grep ksmbd` for userspace daemon
    Affected if The ksmbd module is loaded or ksmbd daemon is running
  3. Check if SMB shares are exported
    Run `cat /proc/fs/ksmbd-server/smb2_stats` if available, or check for active SMB connections via `smbstatus` if samba tools are installed
    Affected if SMB shares are actively exported or served by ksmbd
  4. Inspect ksmbd lease configuration
    Check for lease/oplocks configuration in ksmbd config files (typically /etc/ksmbd/ksmbd.conf) or via `cat /sys/module/ksmbd/parameters/*` if module parameters exist
    Affected if Oplock or lease features are enabled in ksmbd configuration
  5. Look for crash indicators in kernel logs
    Run `dmesg | grep -i 'ksmbd\|oplock\|use-after-free'` and check /var/log/kern.log for related errors
    Affected if Kernel logs show use-after-free errors or NULL pointer dereferences related to ksmbd oplock handling

If the kernel version is in an affected range AND ksmbd is actively serving SMB shares with oplocks enabled, the environment is vulnerable to CVE-2026-31444

Generated from the published advisory. Verify against your own configuration.

Check your environment

Paste your version and any relevant configuration and it will be compared against the affected criteria above. Do not include secrets or credentials.

AI-assisted, checked against the advisory. Informational, not a guarantee.

Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.

dbcve · scoped
Upgrade available Upgrade to 6.12.80 / 6.18.21 / 6.19.11 or later
Fixed in 6.12.806.18.216.19.11
Vendor patch git.kernel.org →
Interim mitigation

Apply the kernel patch that restructures the oplock publication sequence to initialize opinfo->o_fp before list publication, preallocates the lease_table to make add_lease_global_list() infallible, and uses opinfo_put() instead of __free_opinfo() for proper RCU-deferred cleanup.

Recommended fix High confidence

Upgrade to kernel version 6.12.80, 6.18.21, 6.19.11, or any version newer than 6.6.130 (e.g., 6.6.131 or later)

  1. Identify the current running kernel version using 'uname -r' or 'cat /proc/version'
  2. Check if the system is running any of the affected versions: 6.12.78-6.12.79, 6.18.19-6.18.20, 6.19.9-6.19.10, or 6.6.130
  3. For systems using distribution kernels, check for available updates via package manager (e.g., 'apt update && apt list --upgradable' for Debian/Ubuntu, 'yum check-update' for RHEL/CentOS, 'pacman -Syu' for Arch)
  4. Upgrade the kernel package to the fixed version: 6.12.80, 6.18.21, 6.19.11, or a version newer than 6.6.130
  5. Reboot the system to load the fixed kernel
  6. Verify the new kernel version is running with 'uname -r' and confirm it is no longer in the affected version range
  7. If using a custom-built kernel, apply the upstream stable patch commit 48623ec358c1c600fa1e38368746f933e0f1a617 and rebuild the kernel
Caveat Kernel upgrades may require system reboot and could have compatibility implications with proprietary kernel modules or specific hardware drivers; test in staging environment before production deployment

Generated from the published advisory — verify against the referenced sources before acting.

Fix this in Linux Kernel Scoped from the published advisory
  • Consultation3.0 h
  • Implementation8.0 h
  • Testing6.0 h
  • Review / QA3.0 h
20.0 hours of engineering $3,480
Get the upgrade done

An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $5,568.

Scan for this in your stack

Free · runs locally
dbcve dependency scanner

Check whether your project pulls in CVE-2026-31444 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.

References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.

Primary sources

Practitioner notes

Contributed

Peer-ranked notes from engineers who’ve handled CVE-2026-31444 in production — separate from our analysis above.

No notes yet

Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.

What this is

A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.

What belongs here
  • Verified mitigations, workarounds, and config changes
  • Version or environment caveats, and links to real fixes
  • No weaponised exploit code, or anything meant to cause harm
  • No spam, self-promotion, credentials, or personal data