grepの次の脆弱性レポートと、すべてのとがに置き換えられた関連するコミットを読みました。integer
unsigned integer
size_t
unsigned integer
簡単な質問があります。番号のオーバーフロー(または他のタイプの攻撃)を回避することで置き換えていますか?それが理由である場合は?(実際、の定義はsize_t
であると信じていたため、何が変わるかわかりません)。size_t
typedef unsigned int size_t;
size_tは、システム上でunsigned intにtypedefされる場合がありますが、他のシステム、特に組み込み(非X86)システムでは当てはまらない場合があります。ANSI規格では、unsignedintは16ビットまで小さくすることができます。
size_tは、各システムで定義されており、そのシステムで可能なオブジェクトのサイズを指定するのに十分な大きさであることが保証されています。
この脆弱性の場合、(unsigned int)->(size_t)は、少なくともX86システムでは実際には修正の一部ではなく、問題が残っていないことを保証するための関連するクリーンアップの一部であると推測しています。
それはまた、ちょうど良いプログラミングの練習です。
unsigned integer
オーバーフローすることはありません。できません。符号なし型の算術演算は、モジュラー演算を使用して行われます。そもそも。を使用して回避するオーバーフローがなかったため、 「w」unsigned integer
を「」に置き換えてもオーバーフローは回避されません。size_t
unsigned int
いくつかのコメントに応えて、私は「整数のオーバーフロー」を未定義の動作として説明するときに標準が「オーバーフロー」を使用する方法で「オーバーフロー」を意味します。たとえば、標準で「未定義動作の例は整数のオーバーフローでの動作です」と記載されている場合です。値がデータ型内に収まらない場合に、符号なし整数が未定義の動作を引き起こすことを示唆しているわけではありません。さらに、規格には次のように書かれています。
結果の符号なし整数型で表現できない結果は、結果の型で表現できる最大値より1大きい数を法として減少するため、符号なしオペランドを含む計算はオーバーフローすることはありません。
(セクション6.2.5、パラグラフ9)
size_tは、任意のオブジェクトのサイズをバイト単位で表すことができる型です。size_tは、sizeof演算子によって返される型であり、サイズとカウントを表すために標準ライブラリで広く使用されています。
したがって、size_t iaは常にサイズを正しく表すことができ、この意味でオーバーフローすることはありません。
また、size_tは、unsigned intよりも大きい、等しい、または小さい場合があり、コンパイラーは最適化の目的でそれについて仮定する場合があります。したがって、size_tとunsignedintは異なります。
size_tはintよりも大きくすることができ(ほとんどの64ビットマシンにあります)、size_tはサイズ/長さを表す正しいタイプです。
パッチはunsignedintをsize_tに変更して、unsignedintおよびintに格納できるよりも多くのメモリが使用可能な場合に発生する可能性のある問題を回避します。十分なメモリが利用可能である場合、両方ともラップ/オーバーフローします。intをラップすると、否定的な結果が得られる可能性がありますが、符号なしのintをラップするよりも、致命的な(クラッシュしやすい)結果になります。
したがって、本当の問題はintをラップアラウンドし、否定的な結果をもたらし、可能なはずの範囲外のメモリにインデックスを付けることを可能にすることであったようです-符号なしintを使用するように修正します-より多くを使用するようにすべてを変更することもできます正しいsize_t。