In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix delayed ACKs to not set the reference serial number The Linux kernel CVE team has assigned CVE-2024-26677 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024040252-CVE-2024-26677-8bc6@gregkh/T
Created kernel tracking bugs for this issue: Affects: fedora-all [bug 2272835]
This was fixed for Fedora with the 6.7.5 stable kernel updates.
I do not see a security problem in this fix.
The upstream commit e7870cf13d20f56bfc19f9c3e89707c69cf104ef has been merged to centos-stream-9 as commit 822afb772db3080089dcfc9cd619f46be198d491. The upstream commit was authored by David Howells in response to a bug report from me. Neither of us deem this change worthy of a CVE. Prior this change "rxrpc" remembered the serial number of the incoming DATA packet that resulted in the scheduling of a delayed ACK. ACK transmission is delayed either when another DATA packet is required to satisfy the ACK every other DATA packet rule; or when all of the incoming DATA packets have been received and it is hoped that a response DATA packet can be sent in place of the delayed ACK. When constructing an ACK packet with reason RX_ACK_DELAY setting the serial number of the DATA packet that triggered the delayed ACK to be scheduled is unnecessary. All of the RxRPC implementations filter out ACK packets with reason RX_ACK_DELAY when using ACKs to estimate round trip times. The aforementioned change is not a security issue but a performance optimization.
As described in https://bugzilla.redhat.com/show_bug.cgi?id=2272834#c8, there is no vulnerability fixed by upstream commit e7870cf13d20f56bfc19f9c3e89707c69cf104ef. Can someone with privileges please close this ticket as NOT A BUG.