[PATCH net v9 07/14] rxrpc: Fix update of call->tx_pending without holding lock
netdev-bot+sashiko at kernel.org
netdev-bot+sashiko at kernel.org
Tue Sep 8 13:49:44 PDT 2026
Thank you for your contribution! Sashiko AI review found 1 potential
issue(s) to consider:
Critical: 1 · High: 0 · Medium: 0 · Low: 0
- [Critical] rxrpc_send_data() (net/rxrpc/sendmsg.c) can store an
*indeterminate* pointer into call->tx_pending.
--
rxrpc: Fix update of call->tx_pending without holding lock
This moves the release of call->user_mutex down into rxrpc_send_data() and
drops the _dropped_lock indicator parameter, so the callers no longer have
to work out whether the lock is still held. The interrupted-reacquire path
in wait_for_space now returns directly instead of falling through the
common exit path, and the exit labels are renamed to out_txb/out_unlock.
Closes: https://sashiko.dev/#/patchset/20260702144919.172295-1-dhowells%40redhat.com
> diff --git a/net/rxrpc/sendmsg.c b/net/rxrpc/sendmsg.c
> index 4ce3ae0ba2e88..8bb327dc2833e 100644
> --- a/net/rxrpc/sendmsg.c
> +++ b/net/rxrpc/sendmsg.c
[ ... ]
> @@ -464,7 +464,7 @@ static int rxrpc_send_data(struct rxrpc_sock *rx,
> if (ret == -ENOMEM)
> goto maybe_error_rewind;
> set_bit(RXRPC_CALL_TX_ERROR, &call->flags);
> - goto out;
> + goto out_txb;
> }
>
> if (len == 0 && !more)
> @@ -476,15 +476,18 @@ static int rxrpc_send_data(struct rxrpc_sock *rx,
>
> success:
> ret = copied;
> -out:
> +out_txb:
> call->tx_pending = txb;
> +out_unlock:
> + mutex_unlock(&call->user_mutex);
> _leave(" = %d", ret);
> return ret;
[Severity: Critical]
Can out_txb publish an uninitialised txb into call->tx_pending?
txb is declared without an initialiser in rxrpc_send_data():
struct rxrpc_txbuf *txb;
but the two flag tests at the top of the reload block run before txb is
ever assigned, and both jump out of the function:
reload:
if (unlikely(test_bit(RXRPC_CALL_TX_NO_MORE, &call->flags))) {
...
ret = -EPROTO;
goto maybe_error;
}
if (unlikely(test_bit(RXRPC_CALL_TX_ERROR, &call->flags))) {
...
ret = -EIO;
goto maybe_error;
}
txb = call->tx_pending;
call->tx_pending = NULL;
With copied == 0, which is the case on first entry, maybe_error falls
straight through to "goto out_txb", so "call->tx_pending = txb;" runs on a
never-assigned variable.
A two-sendmsg() sequence on one AF_RXRPC call looks like it reaches this:
the first sendmsg() sends the whole request without MSG_MORE, so
rxrpc_queue_packet() sets RXRPC_CALL_TX_NO_MORE for the last packet; a
second sendmsg() before the call completes passes the
rxrpc_call_is_complete() gate in rxrpc_do_sendmsg(), enters
rxrpc_send_data(), trips the TX_NO_MORE test and returns -EPROTO via
out_txb.
Does call->tx_pending then hold a stale stack value that rxrpc_destroy_call()
hands to rxrpc_put_txbuf()?
net/rxrpc/call_object.c:rxrpc_destroy_call() {
...
rxrpc_put_txbuf(call->tx_pending, rxrpc_txbuf_put_cleaned);
...
}
net/rxrpc/txbuf.c:rxrpc_put_txbuf() {
if (txb) {
debug_id = txb->debug_id;
call_debug_id = txb->call_debug_id;
seq = txb->seq;
dead = __refcount_dec_and_test(&txb->ref, &r);
...
}
}
That dereferences, decrements and possibly kfree()s whatever was stored.
CONFIG_INIT_STACK_ALL_ZERO would reduce this to a NULL store, but
CONFIG_INIT_STACK_NONE builds would not.
There also looks to be a txbuf reference dropped on the TX_ERROR path even
when the pointer happens to be NULL: the fatal secure_packet() error above
sets RXRPC_CALL_TX_ERROR and stores the affected txbuf into
call->tx_pending via out_txb, and the next sendmsg() overwrites that
pointer from the TX_ERROR branch before "txb = call->tx_pending;" runs, so
the txbuf and its data buffer are never freed.
The two flag tests were placed above the "txb = call->tx_pending;"
assignment by the earlier "rxrpc: Fix packet encryption error handling"
change in this series, and this patch's rename to out_txb keeps the same
path. Would having those two paths use "goto out_unlock", or initialising
txb to NULL at declaration, be preferable?
> @@ -507,36 +510,38 @@ static int rxrpc_send_data(struct rxrpc_sock *rx,
> if (rxrpc_call_is_complete(call) &&
> call->error < 0) {
> ret = call->error;
> - goto out;
> + goto out_txb;
> }
> goto success;
> }
> - goto out;
> + goto out_txb;
[ ... ]
--
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260907113743.1453210-1-dhowells%40redhat.com
More information about the linux-afs
mailing list