CVE-2026-64026

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: Fix DATA decrypt vs splice() by copying data to buffer in recvmsg<br /> <br /> This improves the fix for CVE-2026-43500.<br /> <br /> Fix the pagecache corruption from in-place decryption of a DATA packet<br /> transmitted locally by splice() by getting rid of the packet sharing in the<br /> I/O thread and unconditionally extracting the packet content into a bounce<br /> buffer in which the buffer is decrypted. recvmsg() (or the kernel<br /> equivalent) then copies the data from the bounce buffer to the destination<br /> buffer. The sk_buff then remains unmodified.<br /> <br /> This has an additional advantage in that the packet is then arranged in the<br /> buffer with the correct alignment required for the crypto algorithms to<br /> process directly. The performance of the crypto does seem to be a little<br /> faster and, surprisingly, the unencrypted performance doesn&amp;#39;t seem to<br /> change much - possibly due to removing complexity from the I/O thread.<br /> <br /> Yet another advantage is that the I/O thread doesn&amp;#39;t have to copy packets<br /> which would slow down packet distribution, ACK generation, etc..<br /> <br /> The buffer belongs to the call and is allocated initially at 2K,<br /> sufficiently large to hold a whole jumbo subpacket, but the buffer will be<br /> increased in size if needed. However, to take this work, MSG_PEEK may<br /> cause a later packet to be decrypted into the buffer, in which case the<br /> earlier one will need re-decrypting for a subsequent recvmsg().<br /> <br /> Note that rx_pkt_offset may legitimately see 0 as a valid offset now, so<br /> switch to using USHRT_MAX to indicate an invalid offset.<br /> <br /> Note also that I would generally prefer to replace the buffers of the<br /> current sk_buff with a new kmalloc&amp;#39;d buffer of the right size, ditching the<br /> old data and frags as this makes the handling of MSG_PEEK easier and<br /> removes the re-decryption issue, but this looks like quite a complicated<br /> thing to achieve. skb_morph() looks half way to what I want, but I don&amp;#39;t<br /> want to have to allocate a new sk_buff.