[PATCH net-next 2/5] net/rxrpc: Use local FCrypt-PCBC implementation

[Eric Biggers]

On Fri, May 08, 2026 at 07:02:05PM +0100, David Howells wrote:
> Eric Biggers <ebiggers at kernel.org> wrote:
> 
> > +	if (skb_linearize(skb) < 0)
> > +		return -ENOMEM;
> 
> It seems skb_linearize() doesn't like being used in this fashion:
> 
> 	kernel BUG at net/core/skbuff.c:2295!
> 	...
> 	RIP: 0010:pskb_expand_head+0x41/0x220
> 	 __pskb_pull_tail+0x5e/0x2f0
> 	 rxkad_verify_packet_2+0xa8/0x190
> 	 rxkad_verify_packet+0x12c/0x150
> 	 rxrpc_recvmsg_data+0x1b0/0x470
> 	 rxrpc_kernel_recv_data+0xa6/0x210
> 	 afs_extract_data+0x5e/0x180
> 	 yfs_deliver_fs_fetch_data64+0x10b/0x200
> 	 afs_deliver_to_call+0xea/0x440
> 	 afs_read_receive+0x8d/0x150
> 	 afs_fetch_data_async_rx+0x12/0x20
> 	 process_one_work+0x18e/0x2b0
> 
> which corresponds to this:
> 
> 	BUG_ON(skb_shared(skb));
> 
> Presumably this is done because fcrypt_pcbc_decrypt() doesn't handle being
> called on a split buffer.  I think this may require skb_copy() to be used
> instead, but that would need to be handled in rxrpc_input_call_event().
> 
> I think rxkad_decrypt_response() should be okay because the encrypted data is
> extracted into a buffer first before being decrypted.

Yes, Marc pointed this out already.  Thanks for the review and testing.
I just haven't had a chance to decide what to do with this patch yet.
It could be an unconditional skb_copy(), it could be decrypting the
fragmented skb in-place, or it could be fixing up the RxRPC code to no
longer take multiple references to the skb (so skb_shared() would no
longer be true).  Let me know if you have a preference.

Also I'm waiting to see if the following patch gets merged:
https://lore.kernel.org/netdev/20260502211340.446927-1-n7l8m4@u.northwestern.edu/
That does the skb_copy() anyway, which would solve this problem.

- Eric