Re: [PATCH RFC 6.6] rxrpc: Fix potential UAF after skb_unshare() failure

[Greg KH <gregkh@linuxfoundation.org>]

On Fri, May 08, 2026 at 04:31:42PM +0800, Wentao Guan wrote:
> From: David Howells <dhowells@redhat.com>
> 
> [ Upstream commit 1f2740150f904bfa60e4bad74d65add3ccb5e7f8 ]
> 
> If skb_unshare() fails to unshare a packet due to allocation failure in
> rxrpc_input_packet(), the skb pointer in the parent (rxrpc_io_thread())
> will be NULL'd out.  This will likely cause the call to
> trace_rxrpc_rx_done() to oops.
> 
> Fix this by moving the unsharing down to where rxrpc_input_call_event()
> calls rxrpc_input_call_packet().  There are a number of places prior to
> that where we ignore DATA packets for a variety of reasons (such as the
> call already being complete) for which an unshare is then avoided.
> 
> And with that, rxrpc_input_packet() doesn't need to take a pointer to the
> pointer to the packet, so change that to just a pointer.
> 
> Fixes: 2d1faf7a0ca3 ("rxrpc: Simplify skbuff accounting in receive path")
> Closes: https://sashiko.dev/#/patchset/20260408121252.2249051-1-dhowells%40redhat.com
> Signed-off-by: David Howells <dhowells@redhat.com>
> cc: Marc Dionne <marc.dionne@auristor.com>
> cc: Jeffrey Altman <jaltman@auristor.com>
> cc: Simon Horman <horms@kernel.org>
> cc: linux-afs@lists.infradead.org
> cc: stable@kernel.org
> Link: https://patch.msgid.link/20260422161438.2593376-4-dhowells@redhat.com
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
> [ Relocated the unshare/skb_copy block from rxrpc_input_call_event()'s rx_queue dequeue loop to existing `if (skb) rxrpc_input_call_packet()` site, and substituted rxrpc_skb_put_call_rx with rxrpc_skb_put_input. ]
> Signed-off-by: Sasha Levin <sashal@kernel.org>
> [ Readd rxrpc_skb_put_response_copy() or will cause a build fail with commit 24481a7f5733 ("rxrpc: Fix conn-level packet handling to unshare RESPONSE packets") ]
> Signed-off-by: Wentao Guan <guanwentao@uniontech.com>

Why not backport the needed commits before this one instead?  That would
make the difference here much smaller.

thanks,

greg k-h