diff options
| author | Jakub Kicinski <kuba@kernel.org> | 2026-05-20 16:36:47 -0700 |
|---|---|---|
| committer | Jakub Kicinski <kuba@kernel.org> | 2026-05-20 16:36:47 -0700 |
| commit | 7769d17e023a3aa4b4bc5b700532004c8d701962 (patch) | |
| tree | 9ff4edd469803c829ad5e9cd4d94f73e685fc34e /tools/testing | |
| parent | b1a736f8bcb1b0ec4ce657f6fa9afc1f698f8f7a (diff) | |
| parent | 8bfab4b6ffc2fe92da86300728fc8c3c7ebffb56 (diff) | |
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>
Diffstat (limited to 'tools/testing')
0 files changed, 0 insertions, 0 deletions
