]> git.ipfire.org Git - thirdparty/linux.git/commit
Merge branch 'rxrpc-better-fix-for-data-response-decrypt-vs-splice'
authorJakub Kicinski <kuba@kernel.org>
Wed, 20 May 2026 23:36:47 +0000 (16:36 -0700)
committerJakub Kicinski <kuba@kernel.org>
Wed, 20 May 2026 23:36:47 +0000 (16:36 -0700)
commit7769d17e023a3aa4b4bc5b700532004c8d701962
tree9ff4edd469803c829ad5e9cd4d94f73e685fc34e
parentb1a736f8bcb1b0ec4ce657f6fa9afc1f698f8f7a
parent8bfab4b6ffc2fe92da86300728fc8c3c7ebffb56
Merge branch 'rxrpc-better-fix-for-data-response-decrypt-vs-splice'

David Howells says:

====================
rxrpc: Better fix for DATA/RESPONSE decrypt vs splice()

Here are two patches containing better fixes for the in-place decryption of
DATA and RESPONSE packets that can corrupt pagecache spliced into UDP
packets and sent to an AF_RXRPC server [CVE-2026-43500], plus a patch to
precheck the length of rxgk-secured DATA packets.

Of the main patches, one patch fixes DATA decryption by having recvmsg
unconditionally extract the data into a flat bounce buffer and, if need be,
decrypt it there.  It doesn't seem to cause a performance problem to do
this even on unencrypted packets; for encrypted packets it makes sure the
content is correctly aligned for crypto which seems to get a small
performance gain.

Further, it means that DATA packets are no longer copied in the I/O thread,
avoiding a slowdown of the protocol engine that runs there.

The other main patch fixes RESPONSE decryption by having the connection
event handler worker copy the data to a flat buffer and, again, decrypt it
there.  This simplifies RESPONSE handling.

With these two fixes, the data content of the received sk_buff no longer
gets altered.
====================

Link: https://patch.msgid.link/20260515230516.2718212-1-dhowells@redhat.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>