August Kernel Drop: The Enterprise CVEs Nobody Wrote About

The August 15 Linux stable drop put thirty-plus CVEs on NVD in a single day. The WiFi heap overflow, the CAN subsystem race cluster, and the SMB server stack overflow all got written up within hours. That is, predictably, not the full picture.

Three fixes in the same batch affect infrastructure that runs in enterprise data centers, storage networks, and secure computing environments. They did not trend. They are worth your attention regardless.

CVE-2026-72157 — ThunderboltIP frags[] overflow

Source: kernel.org stable commit, NVD entry published 2026-08-15. No CVSS score assigned as of publication.

tbnet_poll() in the kernel’s ThunderboltIP driver assembles multi-frame packets by adding each subsequent frame as a page fragment to the skb. skb_add_rx_frag() runs up to frame_count - 1 times without checking skb_shinfo(skb)->nr_frags against MAX_SKB_FRAGS (17 on x86). A peer sending a packet with more than 18 frames overflows the frags[] array — a kernel heap corruption condition. The patch bounds frame_count before the loop starts.

Attack prerequisite: a malicious or compromised peer on a Thunderbolt connection. ThunderboltIP is used for direct device-to-device networking — Mac-to-Mac, workstation-to-NAS, cross-device docking. Physical access or supply-chain compromise of an attached device is the relevant threat model, not remote exploitation. In enterprise environments where Thunderbolt networking is used for high-speed workstation-to-storage transfers, a malicious or tampered dock is the exposure.

CVE-2026-72130 — NVMe-oF auth short-buffer heap overflow

Source: kernel.org stable commit, NVD entry published 2026-08-15. No CVSS score assigned as of publication.

NVMe over Fabrics implements DH-HMAC-CHAP authentication between initiator and target. nvmet_execute_auth_receive() on the target validates that the AUTH_RECEIVE allocation length is nonzero and matches the transfer length — but does not verify it is large enough for the fixed-size response structures. In the SUCCESS1 and FAILURE1 states, nvmet_auth_success1() and nvmet_auth_failure1() write a fixed-size DH-HMAC-CHAP response into that buffer without further size validation. A short-but-nonzero allocation length supplied by a remote initiator writes past the end of the heap allocation. The fix validates the allocation length against the response size before committing.

Prerequisite: a compromised or malicious NVMe-oF initiator on the fabric. In environments using in-kernel NVMe target support (nvmet), any host able to reach the target port can trigger this depending on fabric ACLs. NVMe/TCP extends that exposure to standard Ethernet-connected storage networks — no InfiniBand required.

This is the class of bug — fixed-size response, caller-supplied buffer size, no minimum check — that recurs in cryptographic handshake code across the industry. Per-protocol reinvention of authenticated key exchange tends to produce it. This is not the first time NVMe-oF auth code has needed this kind of review, and it will not be the last.

CVE-2026-72135 — TPM character device pread() OOB read

Source: kernel.org stable commit, NVD entry published 2026-08-15. No CVSS score assigned as of publication.

TPM character devices (/dev/tpm0, /dev/tpmrm0) expose a sequential command-response interface but were registered with FMODE_PREAD and FMODE_PWRITE enabled, permitting pread() with arbitrary offsets. tpm_common_read() bounds the transfer length against response_length but passes *off unchecked into data_buffer + *off. An out-of-bounds read follows for any offset past the response buffer.

Access to a TPM character device is privileged but not root-only in configurations where a service account has been granted TPM access — which includes several TPM attestation and key management setups. Less severe than the two networking bugs above, and no exploitation reported. The fix marks TPM character devices non-seekable via nonseekable_open().

The recurring pattern

Three CVEs in one batch, three different subsystems, the same structural failure each time: an integer or size value arriving from a peer or caller was not validated against the fixed-size structure it populated. This is not a novel bug class. The kernel’s networking and storage stack is large enough that no single team reviews all of it with equal depth, and the result is that the same mistake recurs in different code paths, across different subsystem development histories, until a KCSAN run or a careful reader surfaces it.

The WiFi and CAN fixes got the headlines because WiFi and CAN have broad consumer exposure and known weaponization histories. ThunderboltIP, NVMe-oF, and TPM do not have that reputation — which is the same mistake, just operating on a different set of assumptions about what matters.

What to do

Update to the current Linux stable release. None of these three have confirmed exploitation in the wild as of publication; none are on CISA’s KEV list. The patch is the remediation.

For environments with specific exposure: review whether ThunderboltIP is actually in use and disable it if not; audit NVMe-oF target ACLs and fabric segmentation to minimize the set of hosts that can reach authentication endpoints; review TPM device permissions for non-root service accounts.

---

Related coverage from the same August 15 stable drop: brcmfmac WiFi heap overflow and BPF verifier fix, CAN subsystem 14-CVE race cluster, ksmbd SMB server stack overflow, dm-crypt LUKS key wipe.