CVE-2026-43362

What it actually does

This Linux kernel SMB client flaw can corrupt data during encrypted SMB2/SMB3 write retries. The SMB client may encrypt the write buffer in place; if the write must be retried after a replayable transport or session error, the retry can send the already-encrypted ciphertext as though it were the original plaintext. The result is server-side file or metadata corruption rather than remote code execution. The issue is most likely when SMB encryption is enabled and connections are unstable, especially during reconnects or retryable errors. It affects SMB client write paths including SFU mknod and Minshall+French symlink handling; on kernels before 6.10, synchronous writes also used the affected path.

Why it matters to the business

Systems that mount SMB/CIFS shares from Linux clients may silently corrupt files or special-file metadata during network instability, which can affect backups, shared file repositories, build artifacts, user home directories, application data stored on SMB shares, or cross-platform file services. Because the symptom is integrity loss rather than an obvious crash, organizations may not notice until data is unreadable, malformed, or fails validation. EPSS is currently low and this is not listed in CISA KEV, so broad active exploitation is not indicated, but the high integrity and availability impact makes remediation important for systems that rely on encrypted SMB mounts.

How an attack unfolds

An attacker would need to place a Linux SMB client in a condition where encrypted SMB writes are retried. This could involve operating a malicious SMB server, interfering with an SMB connection, or inducing network/session instability during client writes. The client prepares a write request, the SMB encryption path modifies the shared write buffer in place, and then a replayable error causes the client to retry the write. Because the original plaintext buffer has already been replaced with ciphertext, the retry sends corrupted data to the SMB server. The attacker’s practical outcome is data corruption or disruption of workloads using the mounted SMB share; the vulnerability does not provide a straightforward path to code execution or data disclosure based on the available information.

How to fix it

Upgrade affected Linux kernels to a vendor-provided fixed kernel containing the SMB client patch that moves write payloads into rq_iter so they are deep-copied before encryption. Because no exact fixed package versions were provided, use the latest stable kernel or distribution security update that explicitly references this CVE or the upstream fix for `smb: client: fix in-place encryption corruption in SMB2_write()`. Reboot after installing the kernel update to ensure the fixed kernel is running. As temporary risk reduction, avoid using affected Linux clients for critical writes to encrypted SMB shares over unstable networks, reduce network instability where possible, and consider pausing high-integrity workflows that write to SMB shares until patched. Do not treat disabling SMB encryption as a universal mitigation; it may reduce exposure to this specific bug but can weaken confidentiality and may violate policy or regulatory requirements.

How to confirm the fix worked

Confirm that affected systems are running a kernel build that includes the SMB client fix from the Linux distribution or upstream stable release. Validate with `uname -a` and the distribution package manager, then compare against the vendor advisory for this CVE. Review active SMB mounts with `mount`, `/proc/mounts`, or `findmnt -t cifs` and identify clients using encrypted SMB sessions. After patching and rebooting, perform controlled write/retry testing only in a non-production environment if needed, especially with SMB encryption and simulated reconnects, and verify that file hashes remain stable after retries. For production validation, monitor kernel logs for SMB/CIFS reconnect or write retry errors and perform integrity checks on critical data written to SMB shares during periods of network instability.

Typical attack path

1. Identify or lure a Linux system into writing to an SMB/CIFS share with SMB encryption enabled.
2. Position as the SMB server or otherwise influence the SMB session or transport path.
3. Trigger or wait for unstable connectivity, reconnects, or replayable SMB write errors during client write operations.
4. Cause the Linux SMB client to retry a write after the original write buffer has been encrypted in place.
5. Have the client resend ciphertext instead of plaintext, corrupting the destination file or SMB metadata.
6. Leverage resulting file corruption to disrupt application workflows, backups, shared storage, or user data integrity.

How to detect it

To determine whether this may have already affected systems, focus on evidence of SMB/CIFS write retries and reconnects near the time files became corrupted. Review Linux kernel logs via `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, and `/var/log/syslog` for CIFS, SMB3, reconnect, transport, session, and write-related errors. Correlate those events with file modification times on SMB shares and application reports of malformed, unreadable, or failed-validation files. On file servers, inspect SMB server logs for disconnects, durable-handle reconnects, failed writes, session resets, or repeated writes from the same Linux client around the same offsets or file paths. Because this flaw produces corruption rather than a distinctive malware artifact, absence of a specific IOC does not rule out impact. The most useful detection approach is correlation of Linux SMB client reconnect/write errors with integrity-check failures, unexpected binary-looking content in text or metadata files, hash mismatches, backup verification failures, or application parse errors for files written over SMB.

• CIFS VFS: Error connecting to socket
• CIFS VFS: reconnect
• CIFS VFS: \Send error
• CIFS VFS: \Server requires packet signing
• CIFS VFS: \No response for cmd
• CIFS VFS: \Send error in SessSetup
• CIFS VFS: \Status code returned 0xc000020c STATUS_CONNECTION_DISCONNECTED
• CIFS VFS: \Status code returned 0xc00000b5 STATUS_IO_TIMEOUT
• CIFS VFS: \Status code returned 0xc0000001 STATUS_UNSUCCESSFUL
• CIFS VFS: \Status code returned 0xc000000e STATUS_NO_SUCH_DEVICE
• smb3: reconnect
• SMB2_write
• cifs_reconnect
• /proc/fs/cifs/DebugData
• /proc/fs/cifs/Stats
• mount.cifs
• cifs.ko

What your security team should do

• Inventory Linux systems that mount SMB/CIFS shares, especially systems performing automated writes, backups, build artifact publication, home-directory storage, or application data writes.
• Prioritize patching Linux SMB clients that use SMB encryption, traverse unreliable networks, or write business-critical data to SMB shares.
• Apply the vendor-fixed kernel and reboot; verify the running kernel is the updated one, not only that the package is installed.
• Review data written to SMB shares during recent periods of CIFS reconnects, transport errors, or unstable network conditions for possible corruption.
• Increase monitoring for CIFS/SMB kernel log errors indicating reconnects, failed writes, or session resets.
• If patching is delayed, reduce write activity from affected clients to critical SMB shares and stabilize network paths until remediation is complete.
• Coordinate with storage, Linux, and application teams to validate integrity of high-value datasets that may have been written by vulnerable clients.