Cloudanix VulnDB

CVE-2026-31705

Critical · 9.8

CVSS

9.8

EPSS

0.4%

Published

May 1, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A flaw in Linux file-sharing servers could let a remote attacker crash or possibly take over an affected system if the vulnerable kernel SMB service is exposed.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Low
Impact
Full Compromise
Component
OS kernel
Class
Memory Corruption
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

CVE-2026-31705 is an out-of-bounds write in the Linux kernel ksmbd SMB server implementation. The flaw occurs in smb2_get_ea() while building SMB2 QUERY_INFO extended attribute responses: after copying an EA value into the response buffer, ksmbd unconditionally writes 1–3 bytes of 4-byte alignment padding without first confirming that enough buffer space remains. In compound SMB requests, an earlier command such as READ can consume most of the shared response buffer, leaving a narrowly sized remainder for the QUERY_INFO EA response. If the EA value exactly fills that remainder, the padding memset() writes past the allocated kvmalloc buffer into adjacent kernel heap memory. Because ksmbd runs in kernel context and the CVSS vector indicates network reachability, no authentication, no user interaction, and high confidentiality/integrity/availability impact, successful exploitation could plausibly cause kernel memory corruption, denial of service, and potentially privilege-impacting code execution depending on heap layout and exploitability on a given kernel build.

Why it matters to the business

Systems exposing the in-kernel ksmbd SMB service may be vulnerable to a remotely reachable kernel memory corruption flaw. Operationally, exploitation could crash file-sharing servers, interrupt access to shared files, corrupt kernel memory, or in a worst case allow an attacker to take control of the host. The issue is not currently listed in CISA KEV, is not flagged as ransomware-used, has no known public exploit maturity in the provided data, and has a low, flat EPSS score, which lowers evidence of active exploitation; however, the technical severity remains high because SMB services are commonly exposed inside enterprise networks and this flaw requires no authentication according to the supplied CVSS vector.

How an attack unfolds

An attacker first identifies a Linux host exposing ksmbd over SMB, typically on TCP port 445. They then establish an SMB session and send a crafted compound SMB2 request in which an earlier command, such as READ, consumes most of the shared response buffer. The same compound request includes a QUERY_INFO request for extended attributes sized so that the EA value copy exactly exhausts the remaining buffer. After the value is copied, vulnerable kernels still perform the 4-byte alignment padding memset() even though no free space remains, causing 1–3 NUL bytes to be written beyond the allocated response buffer. The immediate result may be a kernel oops, panic, ksmbd failure, or system instability. With reliable heap shaping and target-specific knowledge, an attacker may attempt to turn the controlled small overwrite into broader kernel memory corruption impact. No named threat actors or active campaigns were provided for this vulnerability.

How to fix it

Apply the Linux kernel update from the relevant distribution or kernel vendor that includes the ksmbd smb2_get_ea() bounds check for EA alignment padding. Because no exact fixed package versions were provided, use vendor advisories and changelogs to identify a kernel build containing the fix for CVE-2026-31705 or the upstream patch that adds a bounds check before the alignment memset() in smb2_get_ea(). Reboot into the fixed kernel after installation; merely installing a kernel package is not sufficient if the host continues running the vulnerable kernel. If immediate patching is not possible, disable ksmbd, unload or prevent loading the ksmbd module where feasible, stop any ksmbd-related service, and restrict SMB access to trusted networks only. Block inbound TCP/445 from untrusted networks and limit lateral SMB reachability through host firewalls, network ACLs, and segmentation. Where kernel SMB serving is not required, consider disabling ksmbd entirely and using a fully patched, supported alternative only if operationally appropriate.

How to confirm the fix worked

Confirm whether the system is running a fixed kernel, not just whether a fixed package is installed. Validate with uname -a, package manager inventory, and vendor advisory mapping for the running kernel build. Check whether ksmbd is present or active using module and process/service checks such as lsmod | grep ksmbd, modinfo ksmbd, systemctl status ksmbd where applicable, and ss or netstat checks for listeners on TCP/445. Review kernel changelogs or source package patches for a change in smb2_get_ea() that checks remaining buffer length before writing alignment padding. From an exposure perspective, confirm that SMB is not reachable from untrusted networks by testing TCP/445 from representative network segments. After remediation, reboot and re-run checks to ensure the patched kernel is active and ksmbd exposure is either removed or intentionally restricted.

Typical attack path

  1. Scan for systems exposing SMB services, especially Linux hosts using the in-kernel ksmbd server.
  2. Confirm the target negotiates SMB2/SMB3 and appears to be served by ksmbd or a Linux SMB implementation.
  3. Open an SMB connection to TCP port 445.
  4. Send a crafted compound SMB2 request where an initial command consumes most of the shared response buffer.
  5. Include a QUERY_INFO extended attribute request whose EA value exactly fills the remaining response buffer.
  6. Trigger the vulnerable alignment padding write in smb2_get_ea(), causing a 1–3 byte out-of-bounds write into adjacent kernel heap memory.
  7. Observe service crash, kernel oops, host instability, or attempt further exploitation depending on kernel heap layout.

How to detect it

To determine whether this was already exploited, review kernel logs, crash dumps, SMB service logs, and network telemetry around TCP/445. Prioritize evidence of kernel oopses, panics, BUG/WARNING traces, general protection faults, slab or KASAN reports, and stack traces involving ksmbd, smb2_get_ea(), SMB2 QUERY_INFO, or compound SMB2 request handling. If full packet capture, Zeek, Suricata, or an NDR platform is available, look for SMB2 compound requests where READ and QUERY_INFO operations occur in the same request chain, especially QUERY_INFO requests involving extended attributes and immediately followed by connection resets, service failures, or host crashes. Check systemd journal, /var/log/kern.log, /var/log/messages, /var/log/syslog, pstore, kdump/vmcore artifacts, and EDR telemetry for abrupt reboots or kernel crashes after SMB traffic. Because the overflow is a small NUL-byte overwrite, durable file-system artifacts may be absent; absence of obvious IOCs does not prove non-exploitation. No public exploit maturity, KEV listing, ransomware use, or named threat actor activity was provided, so detection should focus on behavioral crash and SMB protocol anomalies rather than known malware indicators.

  • ksmbd
  • smb2_get_ea
  • QUERY_INFO
  • SMB2 QUERY_INFO
  • compound request
  • general protection fault
  • kernel BUG
  • BUG: kernel NULL pointer dereference
  • KASAN: slab-out-of-bounds
  • KASAN: out-of-bounds
  • Out of bounds
  • kernel panic
  • Oops:
  • RIP: smb2_get_ea
  • Call Trace:
  • TCP/445
  • port 445
  • /var/log/kern.log
  • /var/log/messages
  • /var/log/syslog
  • /sys/fs/pstore
  • vmcore
  • kdump
  • ksmbd:

What your security team should do

  • Inventory Linux systems exposing SMB on TCP/445 and determine which use ksmbd rather than user-space Samba.
  • Prioritize patching internet-facing or broadly reachable internal ksmbd servers, despite the currently low EPSS and lack of KEV listing.
  • Apply vendor kernel updates containing the ksmbd smb2_get_ea() bounds-check fix, then reboot into the patched kernel.
  • If patching is delayed, disable ksmbd or restrict SMB access to trusted management and file-sharing networks only.
  • Add monitoring for kernel oops, panic, or crash messages referencing ksmbd, smb2_get_ea, SMB2 QUERY_INFO, or malformed compound SMB requests.
  • Hunt SMB logs and network telemetry for unusual compound SMB2 request patterns combining READ and QUERY_INFO extended attribute operations.
  • Ensure segmentation prevents general workstation-to-server or server-to-server SMB access unless explicitly required.
  • Track vendor advisories because exact fixed versions were not provided in the input data.

The record

In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix out-of-bounds write in smb2_get_ea() EA alignment smb2_get_ea() applies 4-byte alignment padding via memset() after writing each EA entry. The bounds check on buf_free_len is performed before the value memcpy, but the alignment memset fires unconditionally afterward with no check on remaining space. When the EA value exactly fills the remaining buffer (buf_free_len == 0 after value subtraction), the alignment memset writes 1-3 NUL bytes past the buf_free_len boundary. In compound requests where the response buffer is shared across commands, the first command (e.g., READ) can consume most of the buffer, leaving a tight remainder for the QUERY_INFO EA response. The alignment memset then overwrites past the physical kvmalloc allocation into adjacent kernel heap memory. Add a bounds check before the alignment memset to ensure buf_free_len can accommodate the padding bytes. This is the same bug pattern fixed by commit beef2634f81f ("ksmbd: fix potencial OOB in get_file_all_info() for compound requests") and commit fda9522ed6af ("ksmbd: fix OOB write in QUERY_INFO for compound requests"), both of which added bounds checks before unconditional writes in QUERY_INFO response handlers.

Affected packages

Ecosystem Package Introduced Fixed
openSUSE:Tumbleweed kernel-source 0 7.0.7-1.1

Related vulnerabilities