dbcve.org
VulnerabilityAwaiting classification

CVE-2026-63909

HIGH · 8.1 CVSS v3.1 Published 2026-07-19
Mitigation only
No fix yet — a mitigation exists. There is no fixed release. A documented workaround reduces exposure in the meantime.
See remediation →
87/100
Remediation priority · High
Remotely reachable Zero-click 5 weeks old

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: OOB read regression in smb_check_perm_dacl() ACE-walk loops Commit d07b26f39246 ("ksmbd: require minimum ACE size in smb_check_perm_dacl()") introduced a transposed bounds check: if (offsetof(struct smb_ace, sid) + aces_size < CIFS_SID_BASE_SIZE) Since offsetof(..sid) is 8 and CIFS_SID_BASE_SIZE is 8, this evaluates to `aces_size < 0`. Because `aces_size` is always non-negative, this check becomes dead code and never breaks the loop. Worse, that commit removed the old 4-byte guard, meaning the loop now reads `ace->size` (offset 2) even when `aces_size` is 0-3 bytes. This re-opens a 2-byte heap out-of-bounds (OOB) read past the pntsd allocation during subsequent SMB2_CREATE operations. Fix this by properly transposing the comparison to require at least 16 bytes (8-byte offset + 8-byte SID base), matching the correct form used in smb_inherit_dacl().

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

A transposed bounds check in ksmbd's smb_check_perm_dacl() function causes a 2-byte heap out-of-bounds read during SMB2_CREATE operations. The comparison `aces_size + 8 < 8` simplifies to `aces_size < 0`, which is always false due to non-negative size values, rendering the check dead and allowing reads beyond the allocated pntsd buffer.

MitigationApply the upstream fix to properly require at least 16 bytes (8-byte ACE offset + 8-byte SID base) before reading ace->size, restoring proper bounds checking in the ACE walk loop.

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

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
Low
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
None
Availability
High

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/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. Verify ksmbd is loaded
    Run `lsmod | grep ksmbd` or check if the ksmbd service/daemon is active. Also check /proc/fs/ksmbd/ directory existence.
    Affected if ksmbd module is loaded or the ksmbd daemon is running - the vulnerability only applies to this specific SMB implementation, not to userspace Samba or other SMB servers
  2. Check kernel version against patch
    Run `uname -r` to get the kernel version. Compare against the version that includes the fix for CVE-2026-63909. The fix involves transposing the comparison to require at least 16 bytes (offsetof + CIFS_SID_BASE_SIZE).
    Affected if Running an unpatched kernel version that contains the vulnerable ksmbd code with the dead bounds check `aces_size < 0`
  3. Confirm SMB2 protocol is enabled
    Check ksmbd configuration for SMB2 support. Inspect /etc/ksmbd/ksmbd.conf or equivalent config file for `max protocol = SMB2` or similar directives. Also verify client systems are using SMB2 or SMB3 (SMB1 is separate).
    Affected if SMB2 or SMB3 protocols are enabled - the vulnerability is triggered specifically during SMB2_CREATE operations, not during SMB1 (CIFS) operations
  4. Identify if ACE structures with small sizes can be sent
    This requires examining SMB traffic or logs for incoming SMB2_CREATE requests with DACLs containing ACE structures where aces_size is 0-3 bytes. This is difficult to detect without packet capture or debug logging enabled.
    Affected if An attacker can send SMB2_CREATE requests with malformed DACL ACE structures having size fields of 0-3 bytes, causing the out-of-bounds read

A system is affected if ksmbd is active AND the kernel is unpatched for this CVE AND SMB2 clients can send specially crafted DACL structures with ace sizes of 0-3 bytes, leading to heap out-of-bounds reads.

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
Mitigation available No clean upgrade yet — mitigate in the meantime
Mitigation

Apply the upstream fix to properly require at least 16 bytes (8-byte ACE offset + 8-byte SID base) before reading ace->size, restoring proper bounds checking in the ACE walk loop.

Recommended fix Moderate confidence

Linux kernel version containing the fix for commit d07b26f39246 (the fix commit that properly transposes the comparison to require >= 16 bytes)

  1. Identify the currently running Linux kernel version using `uname -r`
  2. Check if the kernel version is affected by searching for the vulnerable commit d07b26f39246 in the kernel's git history
  3. Obtain the fixed kernel version from kernel.org or your distribution's repositories. The fix involves changing the bounds check from `offsetof(struct smb_ace, sid) + aces_size < CIFS_SID_BASE_SIZE` to require at least 16 bytes (e.g., `offsetof(struct smb_ace, sid) + aces_size < 16` or equivalent correct comparison)
  4. Upgrade the kernel to a version that includes the fix. For mainline kernels, this would be a version after the fix commit was merged
  5. Reboot the system to load the fixed kernel
  6. Verify the fix is applied by checking the smb_check_perm_dacl() function in the kernel source matches the corrected bounds check
Caveat Kernel upgrades may require system reboot and could introduce compatibility changes with existing modules or drivers

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

Have this fixed Scoped from the published advisory
  • Consultation2.0 h
  • Implementation2.0 h
  • Testing6.0 h
  • Review / QA3.0 h
13.0 hours of engineering $2,200
Get help mitigating

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

Scan for this in your stack

Free · runs locally
dbcve dependency scanner

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

Get it on GitHub Scan in the browser

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-63909 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