CVE-2026-31444
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 · uneditedIn 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 confidenceIn 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.
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>= 6.12.78, < 6.12.80>= 6.18.19, < 6.18.21>= 6.19.9, < 6.19.11= 6.6.130= 7.0CVSS 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 checksWork through these to decide whether this CVE applies to you.
-
Check kernel version against affected rangesRun `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.0Affected if The running kernel version matches any of the affected version ranges
-
Verify ksmbd is loadedRun `lsmod | grep ksmbd` for the kernel module, or check for ksmbd-process via `ps aux | grep ksmbd` for userspace daemonAffected if The ksmbd module is loaded or ksmbd daemon is running
-
Check if SMB shares are exportedRun `cat /proc/fs/ksmbd-server/smb2_stats` if available, or check for active SMB connections via `smbstatus` if samba tools are installedAffected if SMB shares are actively exported or served by ksmbd
-
Inspect ksmbd lease configurationCheck for lease/oplocks configuration in ksmbd config files (typically /etc/ksmbd/ksmbd.conf) or via `cat /sys/module/ksmbd/parameters/*` if module parameters existAffected if Oplock or lease features are enabled in ksmbd configuration
-
Look for crash indicators in kernel logsRun `dmesg | grep -i 'ksmbd\|oplock\|use-after-free'` and check /var/log/kern.log for related errorsAffected 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.
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 · scoped6.12.806.18.216.19.11
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.
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)
- Identify the current running kernel version using 'uname -r' or 'cat /proc/version'
- 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
- 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)
- 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
- Reboot the system to load the fixed kernel
- Verify the new kernel version is running with 'uname -r' and confirm it is no longer in the affected version range
- If using a custom-built kernel, apply the upstream stable patch commit 48623ec358c1c600fa1e38368746f933e0f1a617 and rebuild the kernel
Generated from the published advisory — verify against the referenced sources before acting.
- Consultation3.0 h
- Implementation8.0 h
- Testing6.0 h
- Review / QA3.0 h
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 locallyCheck 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 sourcesPractitioner notes
ContributedPeer-ranked notes from engineers who’ve handled CVE-2026-31444 in production — separate from our analysis above.
The advisory tells you what broke. It rarely tells you what actually worked. If you’ve dealt with this one, that detail is what the next engineer is searching for.
- The version that genuinely resolved it — not the one the vendor claimed
- A config change or rule that shut the vector down
- A gotcha in the upgrade path that cost you an afternoon
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.
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.
- 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