CVE-2026-64380

What it actually does

This is an out-of-bounds read in the Linux kernel SMB client. When parsing POSIX security identifiers returned over SMB, the client-side helper that determines the SID length can read the second byte of a SID buffer even when only one byte remains. A malicious or compromised SMB server can send a truncated POSIX SID in a response that reaches this parser, causing the kernel SMB client to read beyond the supplied buffer. The practical impact is primarily kernel instability or denial of service, with a lower-probability risk of limited information exposure depending on kernel build, memory layout, and hardening features.

Why it matters to the business

Systems that mount or access SMB shares from untrusted, compromised, or attacker-controlled servers could be crashed or destabilized remotely without authentication to the affected client. This can interrupt file access, workloads that depend on network shares, and potentially entire hosts if the kernel panics. The issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has a low EPSS score, but the CVSS severity is high because exploitation can be network-based and may cause high availability impact.

How an attack unfolds

An attacker first needs a Linux system to connect to an SMB server the attacker controls or has compromised. When the client performs SMB operations that return POSIX ownership or SID-related metadata, the server replies with a malformed response containing a truncated POSIX SID. The vulnerable kernel SMB client accepts a buffer that is too short for the parser's subsequent read of the SID subauthority-count byte. That invalid read can trigger a kernel fault, KASAN report, oops, or panic, producing denial of service on the client. In less common conditions, the same out-of-bounds read could expose a small amount of adjacent kernel memory through error behavior or response processing, though the main realistic outcome is client crash or instability.

How to fix it

Apply a Linux kernel update that includes the SMB client fix requiring at least two bytes before reading the POSIX SID subauthority-count field. Because no product-specific fixed versions were provided, use the fixed kernel packages from the relevant Linux distribution or vendor advisory and reboot into the updated kernel. Where immediate patching is not possible, reduce exposure by avoiding SMB mounts to untrusted servers, restricting outbound SMB traffic to approved file servers, disabling unnecessary CIFS/SMB client usage, and using network controls to prevent clients from connecting to attacker-controlled SMB services. Kernel hardening features such as KASAN are useful for detection in test environments but are not a substitute for patching.

How to confirm the fix worked

Confirm that the running kernel, not just the installed package, includes the SMB client SID parsing fix. On managed Linux systems, verify the active kernel version after reboot with standard OS tooling and compare it with the distribution's security advisory for this issue. Review whether the kernel source or vendor patch contains the corrected boundary check in the SMB client POSIX SID parsing helper so that two bytes are required before reading sid[1]. Validate exposure reduction by inventorying systems that use CIFS/SMB mounts and confirming they only connect to trusted SMB servers. If possible, test in a non-production environment with a malformed SMB response generator or regression test and confirm the patched client rejects truncated POSIX SID data without a kernel oops, panic, or KASAN out-of-bounds read report.

Typical attack path

1. Attacker operates, compromises, or positions a malicious SMB server reachable by Linux clients.
2. A Linux host mounts or accesses the attacker-controlled SMB share using the kernel SMB/CIFS client.
3. The attacker waits for or induces metadata operations that cause the client to request POSIX SID-related information.
4. The SMB server returns a crafted response with a truncated POSIX SID field.
5. The vulnerable client parser reads past the end of the SID buffer while determining the SID length.
6. The Linux kernel may generate an oops, KASAN finding, panic, or other instability, disrupting the client system or workloads depending on SMB-mounted storage.

How to detect it

To determine whether exploitation may have occurred, review Linux kernel logs, system journals, crash dumps, and monitoring alerts for crashes or memory-safety reports in the SMB/CIFS client path. Useful sources include journalctl kernel messages, /var/log/kern.log, /var/log/messages, /var/log/syslog, kdump/vmcore artifacts, kernel oops reports, KASAN reports, and EDR telemetry showing SMB connections immediately before a crash. Look for stack traces referencing SMB client code, CIFS/VFS messages, POSIX SID handling, or the function posix_info_sid_size. Correlate any kernel crash or oops with outbound TCP/445 connections to SMB servers, newly added CIFS mounts, automount activity, or user access to network shares. Network evidence may show SMB2/SMB3 metadata responses from a suspicious server shortly before client failure, but the malformed truncated SID is protocol-field-specific and may require packet capture plus SMB parsing to confirm. Absence of these logs does not prove non-exploitation, because kernel panics can truncate logging if persistent logging or crash dumping is not enabled.

• posix_info_sid_size
• CIFS: VFS
• fs/smb/client
• fs/cifs
• BUG: KASAN: slab-out-of-bounds
• BUG: KASAN: global-out-of-bounds
• BUG: unable to handle kernel paging request
• Oops:
• Kernel panic - not syncing
• RIP: 0010:posix_info_sid_size
• Call Trace:.*cifs
• Call Trace:.*smb2
• TCP/445 outbound connection immediately before kernel oops or panic

What your security team should do

• Prioritize patching Linux systems that mount SMB/CIFS shares, especially servers, workstations, containers hosts, and appliances that connect to file shares across trust boundaries.
• Reboot systems after kernel package updates and verify the running kernel is the remediated version.
• Restrict outbound SMB connections from Linux clients to approved file servers using host firewalls, network firewalls, or egress filtering.
• Inventory CIFS/SMB mounts and remove unused or legacy mounts, particularly those pointing to third-party, user-controlled, or unmanaged servers.
• Monitor kernel logs for oops, panic, KASAN, or CIFS/SMB client errors involving POSIX SID parsing or SMB metadata handling.
• Treat crashes that occur shortly after connecting to unfamiliar SMB shares as potentially suspicious and preserve kernel logs, crash dumps, and network captures where available.
• Because exploit maturity is currently reported as none and EPSS is low, handle as high-priority for exposed SMB client populations rather than as an active mass-exploitation emergency.