CVE-2026-80810 in Linux
要約
〜によって VulDB • 2026年09月04日
Linuxカーネルにおいて、以下の脆弱性が修正されました：
io_uring/rsrc: io_vec_fill_bvec()におけるfolioサイズオーバーフローの修正
io_vec_fill_bvec()は、単純なint型リテラル1を用いてfolioサイズを計算しています。
```c unsigned long folio_size = 1 << imu->folio_shift; ```
imu->folio_shiftは符号なし整数であり、登録されたバッファを支えるfolioのfolio_shift()から取得されるため、64ビットカーネルでは32以上になる可能性があります。int型リテラル1をそこまでシフトすることは未定義動作であり、x86およびarm64アーキテクチャでは演算結果が32でモジュロ（剰余）処理されるため、34のシフトは16Gではなく4を生成します。このファイル内の他のfolio_shiftに関するすべてのシフト操作では既に1ULが使用されています。
その結果、セグメント見積もりとfillループの間で不一致が生じます。io_estimate_bvec_size()関数は、実際のシフト値を用いてbvec配列のサイズを設定しています。
```c max_segs += (iov[i].iov_len >> shift) + 2;
```
したがって、16Gのfolio上で1Mのiovecを処理する場合、io_estimate_bvec_size()では2セグメントとして課金されますが、io_vec_fill_bvec()はその後、4バイト単位のfolio_sizeチャンクで同じiovecを走査し、res_bvec[bvec_idx]に対して配列の末尾を超えて約25万回書き込みを行います。src_bvecもまた各イテレーションごとに1つずつ進められるため、imu->bvecも同時にその末尾を超えて読み込まれます。validate_fixed_range()関数は範囲が登録されたバッファ内にあるかどうかのみをチェックしており、セグメント数には上限を設けていません。
これに到達するには、少なくとも32のシフト値を持つfolioが必要であり、これは巨大なhugetlbページ（arm64で64Kページの環境では16G、CONT_PMD_SHIFTは34であり、hugetlb_add_hstate(CONT_PMD_SHIFT - PAGE_SHIFT)によってこのサイズが登録されます。同様にpowerpcでも同様です）を意味します。x86_64の最大値は1Gであるため、シフト値30（int型に収まり、影響を受けません）では問題になりません。
ファイル内の他の箇所と同様、1ULを使用してください。
If you want to get best quality of vulnerability data, you may have to visit VulDB.