Bug 2507523 - CVE-2026-64535 kernel: nvmet-tcp: Fix potential UAF when ddgst mismatch [fedora-all]
Summary: CVE-2026-64535 kernel: nvmet-tcp: Fix potential UAF when ddgst mismatch [fedo...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
Assignee: Justin M. Forbes
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: {"flaws": ["5de149a5-3fa1-4963-a292-e...
Depends On:
Blocks: CVE-2026-64535
TreeView+ depends on / blocked
 
Reported: 2026-07-27 15:42 UTC by jkelly
Modified: 2026-07-27 17:20 UTC (History)
15 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2026-07-27 17:20:03 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description jkelly 2026-07-27 15:42:40 UTC
Disclaimer: Community trackers are created by Red Hat Product Security team on a best effort basis. Package maintainers are required to ascertain if the flaw indeed affects their package, before starting the update process.

In the Linux kernel, the following vulnerability has been resolved:

nvmet-tcp: Fix potential UAF when ddgst mismatch

Shivam Kumar found via vulnerability testing:
When data digest is enabled on an NVMe/TCP connection and a digest
mismatch occurs on a non-final H2C_DATA PDU during an R2T-based
data transfer, the digest error handler in nvmet_tcp_try_recv_ddgst()
calls nvmet_req_uninit() — which performs percpu_ref_put() on the
submission queue — but does NOT mark the command as completed. It
does not set cqe->status, does not modify rbytes_done, and does not
clear any flag. When the subsequent fatal error triggers queue
teardown, nvmet_tcp_uninit_data_in_cmds() iterates all commands,
checks nvmet_tcp_need_data_in() for each one, and finds that the
already-uninited command still appears to need data (because
rbytes_done < transfer_len and cqe->status == 0). It therefore calls
nvmet_req_uninit() a second time on the same command — a double
percpu_ref_put against a single percpu_ref_get.

Reproducers, if any, will remain confidential and never be made public, unless done so by the security team.

Comment 1 Justin M. Forbes 2026-07-27 17:20:03 UTC
By upstream policy, if a CVE exists, it is already fixed in Fedora. CVEs aren't created until after a stable release with the patch, and Fedora builds stable releases before CVEs are published on them.

Fixed in 7.1 with commit dbbd07d0a7020b80f6a7028e561908f7b83b3d5a


Note You need to log in before you can comment on or make changes to this bug.