From: Simon Horman <horms@kernel.org>
To: dhowells@redhat.com
Cc: Simon Horman <horms@kernel.org>,
netdev@vger.kernel.org, marc.dionne@auristor.com,
kuba@kernel.org, davem@davemloft.net, edumazet@google.com,
pabeni@redhat.com, linux-afs@lists.infradead.org,
linux-kernel@vger.kernel.org, d4n.for.sec@gmail.com,
n05ec@lzu.edu.cn, jaltman@auristor.com, stable@kernel.org
Subject: Re: [PATCH net 1/5] rxrpc: input: reject ACKALL outside transmit phase
Date: Thu, 18 Jun 2026 10:27:33 +0100 [thread overview]
Message-ID: <20260618092733.887894-1-horms@kernel.org> (raw)
In-Reply-To: <20260616155749.2125907-2-dhowells@redhat.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Full review at: https://sashiko.dev
---
rxrpc: input: reject ACKALL outside transmit phase
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 reach a new service call and trigger a null
pointer dereference.
> diff --git a/net/rxrpc/input.c b/net/rxrpc/input.c
> index ce761466b02d6..37881dffa898b 100644
> --- a/net/rxrpc/input.c
> +++ b/net/rxrpc/input.c
[ ... ]
> @@ -1214,8 +1214,22 @@ static void rxrpc_input_ack(struct rxrpc_call *call, struct sk_buff *skb)
> static void rxrpc_input_ackall(struct rxrpc_call *call, struct sk_buff *skb)
> {
> struct rxrpc_ack_summary summary = { 0 };
> + rxrpc_seq_t top = READ_ONCE(call->tx_top);
> +
> + switch (__rxrpc_call_state(call)) {
> + case RXRPC_CALL_CLIENT_SEND_REQUEST:
> + case RXRPC_CALL_CLIENT_AWAIT_REPLY:
> + case RXRPC_CALL_SERVER_SEND_REPLY:
> + case RXRPC_CALL_SERVER_AWAIT_ACK:
> + break;
> + default:
> + return;
> + }
> +
> + if (call->tx_bottom == top)
> + return;
>
> - if (rxrpc_rotate_tx_window(call, call->tx_top, &summary))
> + if (rxrpc_rotate_tx_window(call, top, &summary))
[Severity: High]
This isn't a bug introduced by this patch, but it appears the fix might be
incomplete. The patch prevents a NULL pointer dereference in
rxrpc_input_ackall() by checking if call->tx_bottom == top before calling
rxrpc_rotate_tx_window().
However, does the same vulnerability remain in rxrpc_receiving_reply()?
If a client in the RXRPC_CALL_CLIENT_SEND_REQUEST state receives a forged or
early DATA packet (acting as a reply) before it has queued any transmit data,
call->tx_top and call->tx_bottom will both be 0, and call->tx_queue will be
NULL.
rxrpc_receiving_reply() will then unconditionally call:
if (!rxrpc_rotate_tx_window(call, top, &summary)) {
Because rxrpc_rotate_tx_window() uses a do { ... } while (before_eq(seq, to))
loop, it executes exactly once for seq = 1 and to = 0, which dereferences
the NULL tq:
if (tq->bufs[ix]->flags & RXRPC_LAST_PACKET) {
Should the empty window check be placed at the top of rxrpc_rotate_tx_window()
instead, or mirrored in rxrpc_receiving_reply() to protect against early
replies?
> rxrpc_end_tx_phase(call, false, rxrpc_eproto_unexpected_ackall);
> }
next prev parent reply other threads:[~2026-06-18 9:28 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-16 15:57 [PATCH net 0/5] rxrpc: Miscellaneous fixes David Howells
2026-06-16 15:57 ` [PATCH net 1/5] rxrpc: input: reject ACKALL outside transmit phase David Howells
2026-06-18 9:27 ` Simon Horman [this message]
2026-06-16 15:57 ` [PATCH net 2/5] rxrpc: Fix leak of connection from OOB challenge David Howells
2026-06-16 15:57 ` [PATCH net 3/5] rxrpc: Fix double unlock in rxrpc_recvmsg() David Howells
2026-06-16 15:57 ` [PATCH net 4/5] afs: Fix further netns teardown to cancel the preallocation charger David Howells
2026-06-18 9:29 ` Simon Horman
2026-06-16 15:57 ` [PATCH net 5/5] afs: Fix uncancelled rxrpc OOB message handler David Howells
2026-06-18 9:29 ` Simon Horman
2026-06-18 12:01 ` [PATCH net 0/5] rxrpc: Miscellaneous fixes David Howells
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260618092733.887894-1-horms@kernel.org \
--to=horms@kernel.org \
--cc=d4n.for.sec@gmail.com \
--cc=davem@davemloft.net \
--cc=dhowells@redhat.com \
--cc=edumazet@google.com \
--cc=jaltman@auristor.com \
--cc=kuba@kernel.org \
--cc=linux-afs@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marc.dionne@auristor.com \
--cc=n05ec@lzu.edu.cn \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=stable@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.