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

rxrpc: Fix ACKALL packet handling

rxrpc_input_ackall() accepts ACKALL packets without checking whether the
call is in a state that can legitimately have outstanding transmit buffers.
A forged ACKALL can therefore reach a new service call in
RXRPC_CALL_SERVER_RECV_REQUEST before any reply packets have been queued.

In that state call->tx_top is zero and call->tx_queue is NULL, so
rxrpc_rotate_tx_window() dereferences a NULL txqueue and triggers a
null-pointer dereference.

Fix the handling of ACKALL packets by the following means:

(1) Add two new call states: RXRPC_CALL_CLIENT_PRE_SEND which indicates
that the client call is connected, but nothing has been transmitted as
yet; and RXRPC_CALL_CLIENT_AWAIT_ACK, which indicates that everything
has been transmitted at least once, but we're now waiting for the
stuff remaining in the Tx buffer to be ACK'd (retransmissions may
still happen).

The RXRPC_CALL_CLIENT_PRE_SEND state is set when the call is assigned
a channel and transitions to RXRPC_CALL_CLIENT_SEND_REQUEST when the
first packet is transmitted.

RXRPC_CALL_CLIENT_AWAIT_REPLY is then narrowed in scope to indicate
that all Tx packets have been ACK'd and we're now waiting for the
reply to be received.

(2) As per Wyatt Feng's original patch[1], the ACKALL handler then checks
that the call state is one in which there might be stuff in the Tx
buffer to ACK, but now this includes AWAIT_ACK rather than
AWAIT_REPLY. ACKALL packets are ignored if received in the wrong
state.

Note that unlike Wyatt Feng's patch, it's no longer necessary to check
to see if the Tx buffer exists as this the state set now covers this.

(3) Make the ACKALL handler use call->tx_transmitted rather than
call->tx_top as the former is explicitly the highest packet seq number
transmitted, whereas the latter has a looser definition.

Thanks to Jeffrey Altman for a description of the history of the ACKALL
packet[1].
Published: 2026-08-15
Score: 7.5 High
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The rxrpc subsystem of the Linux kernel accepts ACKALL packets without verifying that the call is in a state with outstanding transmit buffers. A forged ACKALL can reach a call in the RXRPC_CALL_SERVER_RECV_REQUEST state, where the transmission queue is empty. In that state rxrpc_rotate_tx_window dereferences a NULL txqueue, causing a null-pointer dereference classified as CWE-476. This results in a kernel crash and a denial‑of‑service.

Affected Systems

Linux kernel builds that do not include the patch adding three new client states and the ACKALL state validation are affected. The vulnerability exists in any Linux kernel prior to the commit referenced by the supplied patch URLs. Systems running older kernel releases are vulnerable; newer kernels that incorporate the fix are not.

Risk and Exploitability

The CVSS score of 7.5 reflects the severity of a kernel null‑pointer dereference that can be executed remotely over the network. The EPSS score of <1% indicates a low probability of exploitation in the wild, yet the attack can be triggered by a crafted network packet, making it a remote denial‑of‑service threat. The vulnerability is not listed in CISA KEV, and no public exploit has been reported, but the potential impact and remote nature warrant immediate attention.

Generated by OpenCVE AI on August 21, 2026 at 22:13 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Apply a kernel update that includes the rxrpc_ACKALL fix from the Linux kernel maintainers' patch commits.
  • If an update cannot be applied immediately, block or restrict incoming RXRPC traffic using the system firewall or by disabling the rxrpc module (e.g., through module blacklisting or kernel configuration options).
  • After mitigation, monitor kernel logs (dmesg, /var/log/kern.log) for evidence of repeated kernel panics related to rxrpc to confirm that the issue has been resolved.

Generated by OpenCVE AI on August 21, 2026 at 22:13 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Fri, 21 Aug 2026 00:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-476
References
Metrics threat_severity

None

 threat_severity

Moderate

Mon, 17 Aug 2026 06:00:00 +0000

Type Values Removed Values Added
Metrics cvssV3_1

{'score': 7.5, 'vector': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H'}

Sat, 15 Aug 2026 06:15:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix ACKALL packet handling rxrpc_input_ackall() accepts ACKALL packets without checking whether the call is in a state that can legitimately have outstanding transmit buffers. A forged ACKALL can therefore reach a new service call in RXRPC_CALL_SERVER_RECV_REQUEST before any reply packets have been queued. In that state call->tx_top is zero and call->tx_queue is NULL, so rxrpc_rotate_tx_window() dereferences a NULL txqueue and triggers a null-pointer dereference. Fix the handling of ACKALL packets by the following means: (1) Add two new call states: RXRPC_CALL_CLIENT_PRE_SEND which indicates that the client call is connected, but nothing has been transmitted as yet; and RXRPC_CALL_CLIENT_AWAIT_ACK, which indicates that everything has been transmitted at least once, but we're now waiting for the stuff remaining in the Tx buffer to be ACK'd (retransmissions may still happen). The RXRPC_CALL_CLIENT_PRE_SEND state is set when the call is assigned a channel and transitions to RXRPC_CALL_CLIENT_SEND_REQUEST when the first packet is transmitted. RXRPC_CALL_CLIENT_AWAIT_REPLY is then narrowed in scope to indicate that all Tx packets have been ACK'd and we're now waiting for the reply to be received. (2) As per Wyatt Feng's original patch[1], the ACKALL handler then checks that the call state is one in which there might be stuff in the Tx buffer to ACK, but now this includes AWAIT_ACK rather than AWAIT_REPLY. ACKALL packets are ignored if received in the wrong state. Note that unlike Wyatt Feng's patch, it's no longer necessary to check to see if the Tx buffer exists as this the state set now covers this. (3) Make the ACKALL handler use call->tx_transmitted rather than call->tx_top as the former is explicitly the highest packet seq number transmitted, whereas the latter has a looser definition. Thanks to Jeffrey Altman for a description of the history of the ACKALL packet[1].
Title rxrpc: Fix ACKALL packet handling
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-08-17T05:47:05.522Z

Reserved: 2026-08-15T05:44:03.895Z

Link: CVE-2026-74430

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-08-15T06:22:45.120

Modified: 2026-08-17T06:19:38.597

Link: CVE-2026-74430

cve-icon Redhat

Severity : Moderate

Publid Date: 2026-08-15T00:00:00Z

Links: CVE-2026-74430 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-08-21T22:15:04Z

Weaknesses