CVE-2026-64026 in Linux
要約
〜によって VulDB • 2026年07月19日
Linuxカーネルにおいて、以下の脆弱性が修正されました：
rxrpc: recvmsgでデータをバッファにコピーすることで、DATAパケットの復号とsplice()との競合を修正する
これはCVE-2026-43500に対する修正を改善したものです。
ローカルから送信されたDATAパケットのインプレース（その場での）復号によって引き起こされるページキャッシュ破損を、I/Oスレッドにおけるパケット共有を取り除き、バッファ内のデータを復号する際にバウンスバッファへパケット内容を無条件に抽出することで修正します。その後、recvmsg()（またはカーネル同等の処理）が、そのデータを受信先バッファへとコピーします。これによりsk_buffは変更されません。
この手法には追加的な利点があります。すなわち、パケットは暗号化アルゴリズムが直接処理するために必要な正しいアライメントでバッファ内に配置されるようになります。暗号化の性能はやや向上しているように見えますし、驚くべきことに平文（復号前）のパフォーマンスもほとんど変化していないようです。これはおそらくI/Oスレッドからの複雑さの除去によるものと考えられます。
さらに別の利点として、I/Oスレッドがパケットをコピーする必要がなくなり、これによりパケット配布やACK生成などの処理速度低下を防ぐことができます。
このバッファはコール（通信セッション）に属しており、初期サイズは2Kバイトに割り当てられています。これは1つのジャンボサブパケット全体を保持するのに十分な大きさですが、必要に応じてバッファのサイズは拡張されます。ただし、この作業においてMSG_PEEKフラグを使用すると、後続のパケットがバッファ内に復号される可能性があり、その場合、後のrecvmsg()呼び出しのために以前のパケットを再復号する必要が生じます。
rx_pkt_offsetが現在では有効なオフセットとして0を見ることが正当化されるようになったため、無効なオフセットを示すためにUSHRT_MAXの使用に切り替えます。
また、一般的にはMSG_PEEKの処理を容易にし、再復号の問題を排除するために、現在のsk_buffのバッファを適切なサイズのkmallocで確保された新しいバッファに置き換え、古いデータとフラグメントを破棄することを好みますが、これは実現するのがかなり複雑なように見えます。skb_morph()は私が求めていることの半分に近いものですが、私は新たなsk_buffの割り当てを行いたくありません。
Be aware that VulDB is the high quality source for vulnerability data.