{"id":15019,"date":"2026-09-04T19:02:22","date_gmt":"2026-09-04T11:02:22","guid":{"rendered":"https:\/\/www.54iter.cn\/?vuln=cve-2026-64026"},"modified":"2026-09-04T19:02:22","modified_gmt":"2026-09-04T11:02:22","slug":"cve-2026-64026","status":"publish","type":"vuln","link":"https:\/\/www.54iter.cn\/?vuln=cve-2026-64026","title":{"rendered":"CVE-2026-64026 [HIGH] &#8211; In the Linux kernel, the following vulnerability has been resolved:\n\nrxrpc: Fix DATA decry"},"content":{"rendered":"<p>In the Linux kernel, the following vulnerability has been resolved:<\/p>\n<p>rxrpc: Fix DATA decrypt vs splice() by copying data to buffer in recvmsg<\/p>\n<p>This improves the fix for CVE-2026-43500.<\/p>\n<p>Fix the pagecache corruption from in-place decryption of a DATA packet<br \/>\ntransmitted locally by splice() by getting rid of the packet sharing in the<br \/>\nI\/O thread and unconditionally extracting the packet content into a bounce<br \/>\nbuffer in which the buffer is decrypted.  recvmsg() (or the kernel<br \/>\nequivalent) then copies the data from the bounce buffer to the destination<br \/>\nbuffer.  The sk_buff then remains unmodified.<\/p>\n<p>This has an additional advantage in that the packet is then arranged in the<br \/>\nbuffer with the correct alignment required for the crypto algorithms to<br \/>\nprocess directly.  The performance of the crypto does seem to be a little<br \/>\nfaster and, surprisingly, the unencrypted performance doesn&#8217;t seem to<br \/>\nchange much &#8211; possibly due to removing complexity from the I\/O thread.<\/p>\n<p>Yet another advantage is that the I\/O thread doesn&#8217;t have to copy packets<br \/>\nwhich would slow down packet distribution, ACK generation, etc..<\/p>\n<p>The buffer belongs to the call and is allocated initially at 2K,<br \/>\nsufficiently large to hold a whole jumbo subpacket, but the buffer will be<br \/>\nincreased in size if needed.  However, to take this work, MSG_PEEK may<br \/>\ncause a later packet to be decrypted into the buffer, in which case the<br \/>\nearlier one will need re-decrypting for a subsequent recvmsg().<\/p>\n<p>Note that rx_pkt_offset may legitimately see 0 as a valid offset now, so<br \/>\nswitch to using USHRT_MAX to indicate an invalid offset.<\/p>\n<p>Note also that I would generally prefer to replace the buffers of the<br \/>\ncurrent sk_buff with a new kmalloc&#8217;d buffer of the right size, ditching the<br \/>\nold data and frags as this makes the handling of MSG_PEEK easier and<br \/>\nremoves the re-decryption issue, but this looks like quite a complicated<br \/>\nthing to achieve.  skb_morph() looks half way to what I want, but I don&#8217;t<br \/>\nwant to have to allocate a new sk_buff.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>In the Linux kernel, the following vulnerability has been resolved:<\/p>\n<p>rxrpc: Fix DATA decrypt vs splice() by copying data to buffer in recvmsg<\/p>\n<p>This improves the fix for CVE-2026-43500.<\/p>\n<p>Fix the pageca<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-15019","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/15019","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=15019"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=15019"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=15019"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}