UBUNTU-CVE-2026-43362: Medium severity ubuntu/linux-aws vulnerability
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix in-place encryption corruption in SMB2write() SMB2write() places write payload in iov[1..n] as part of rqiov. smb3inittransformrq() pointer-shares rqiov, so cryptmessage() encrypts iov[1] in-place, replacing the original plaintext with ciphertext. On a replayable error, the retry sends the same iov[1] which now contains ciphertext instead of the original data, resulting in corruption. The corruption is most likely to be observed when connections are unstable, as reconnects trigger write retries that re-send the already-encrypted data. This affects SFU mknod, MF symlinks, etc. On kernels before 6.10 (prior to the netfs conversion), sync writes also used this path and were similarly affected. The async write path wasn't unaffected as it uses rqiter which gets deep-copied. Fix by moving the write payload into rqiter via ioviterkvec(), so smb3inittransformrq() deep-copies it before encryption.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/linux-aws-6.8to a version that resolves this vulnerability.Fixed in 6.8.0-1061.64~22.04.1 - Upgrade
Upgrade
ubuntu/linux-azure-6.8to a version that resolves this vulnerability.Fixed in 6.8.0-1059.65~22.04.1 - Upgrade
Upgrade
ubuntu/linux-azure-fde-6.8to a version that resolves this vulnerability.Fixed in 6.8.0-1058.65~22.04.1 - Upgrade
Upgrade
ubuntu/linux-gcp-6.8to a version that resolves this vulnerability.Fixed in 6.8.0-1064.72~22.04.1 - Upgrade
Upgrade
ubuntu/linux-hwe-6.8to a version that resolves this vulnerability.Fixed in 6.8.0-136.136~22.04.1 - Upgrade
Upgrade
ubuntu/linux-ibm-6.8to a version that resolves this vulnerability.Fixed in 6.8.0-1061.62~22.04.1 - Upgrade
Upgrade
ubuntu/linux-lowlatency-hwe-6.8to a version that resolves this vulnerability.Fixed in 6.8.0-136.136.2~22.04.1 - Upgrade
Upgrade
ubuntu/linux-nvidia-6.8to a version that resolves this vulnerability.Fixed in 6.8.0-1059.62~22.04.1 - Upgrade
Upgrade
ubuntu/linux-oracle-6.8to a version that resolves this vulnerability.Fixed in 6.8.0-1058.61~22.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-6.8to a version that resolves this vulnerability.Fixed in 6.8.0-136.136~22.04.3 - Upgrade
Upgrade
ubuntu/linux-realtime-6.8to a version that resolves this vulnerability.Fixed in 6.8.1-1056.57~22.04.2 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 6.8.0-136.136 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 6.8.0-1061.64 - Upgrade
Upgrade
ubuntu/linux-azureto a version that resolves this vulnerability.Fixed in 6.8.0-1054.60 - Upgrade
Upgrade
ubuntu/linux-azure-6.17to a version that resolves this vulnerability.Fixed in 6.17.0-1013.13~24.04.1 - Upgrade
Upgrade
ubuntu/linux-azure-fdeto a version that resolves this vulnerability.Fixed in 6.8.0-1058.65 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 6.8.0-1064.72 - Upgrade
Upgrade
ubuntu/linux-gketo a version that resolves this vulnerability.Fixed in 6.8.0-1059.67 - Upgrade
Upgrade
ubuntu/linux-gkeopto a version that resolves this vulnerability.Fixed in 6.8.0-1046.50 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 6.8.0-1061.62 - Upgrade
Upgrade
ubuntu/linux-lowlatencyto a version that resolves this vulnerability.Fixed in 6.8.0-136.136.2 - Upgrade
Upgrade
ubuntu/linux-nvidiato a version that resolves this vulnerability.Fixed in 6.8.0-1059.62 - Upgrade
Upgrade
ubuntu/linux-nvidia-lowlatencyto a version that resolves this vulnerability.Fixed in 6.8.0-1059.62.1 - Upgrade
Upgrade
ubuntu/linux-nvidia-tegrato a version that resolves this vulnerability.Fixed in 6.8.0-1030.31 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 6.8.0-1058.61 - Upgrade
Upgrade
ubuntu/linux-raspito a version that resolves this vulnerability.Fixed in 6.8.0-1061.65 - Upgrade
Upgrade
ubuntu/linux-vmwareto a version that resolves this vulnerability.Fixed in 6.8.0-1008.8 - Upgrade
Upgrade
ubuntu/linux-xilinxto a version that resolves this vulnerability.Fixed in 6.8.0-1033.34 - Upgrade
Upgrade
ubuntu/linux-bluefieldto a version that resolves this vulnerability.Fixed in 6.8.0-1028.33 - Upgrade
Upgrade
ubuntu/linux-raspi-realtimeto a version that resolves this vulnerability.Fixed in 6.8.0-2050.52 - Upgrade
Upgrade
ubuntu/linux-realtimeto a version that resolves this vulnerability.Fixed in 6.8.1-1056.57 - Upgrade
Upgrade
ubuntu/linux-aws-fipsto a version that resolves this vulnerability.Fixed in 6.8.0-1061.64+fips1 - Upgrade
Upgrade
ubuntu/linux-azure-fipsto a version that resolves this vulnerability.Fixed in 6.8.0-1054.60+fips1 - Upgrade
Upgrade
ubuntu/linux-fipsto a version that resolves this vulnerability.Fixed in 6.8.0-136.136+fips2 - Upgrade
Upgrade
ubuntu/linux-gcp-fipsto a version that resolves this vulnerability.Fixed in 6.8.0-1064.72+fips1 - Upgrade
Upgrade
ubuntu/linux-azureto a version that resolves this vulnerability.Fixed in 6.17.0-1013.13 - Compensating control
Modify SMB2_write() to move the write payload into rq_iter using iov_iter_kvec(), so smb3_init_transform_rq() deep-copies it before encryption and retries do not resend in-place ciphertext.
Event History
Frequently Asked Questions
Which systems are most likely to encounter data corruption?
Systems using the SMB client with in-place encryption are most likely to observe corruption when connections are unstable. Reconnects can trigger write retries that resend ciphertext in place of the original plaintext.
What operations can be affected?
The issue affects write payloads that are retried after encryption, including SFU mknod and MF symlink operations. On kernels before 6.10, synchronous writes also used the affected path; the asynchronous write path uses a deep-copied iterator and was not affected.
How can I reduce risk if I cannot apply the fix immediately?
Avoid or minimize unstable SMB connections and reconnect-driven write retries where possible. The described corruption occurs when a replayable error causes an encrypted write payload to be resent.
How can I tell whether corruption may have occurred?
Review SMB client activity for write retries following reconnects or other replayable errors, especially around SFU mknod or MF symlink operations. Affected retries may have written ciphertext rather than the intended plaintext.