array.array.fromlist() exposes uninitialized memory when an element's __index__ resizes the array
まだ誰も着手していません。
- 主要言語
- Python
- スター
- 77.2k
- フォーク
- 35.9k
- PR マージ指標
- PR 指標を取得中
説明
Bug report
Bug description:
array.array.fromlist() preallocates n slots with array_resize(self, old_size + n) and then fills them by calling the type's setitem at an index recomputed from the live Py_SIZE(self) on every iteration:
// Modules/arraymodule.c array_array_fromlist_impl
old_size = Py_SIZE(self);
if (array_resize(self, old_size + n) == -1)
return NULL;
for (i = 0; i < n; i++) {
PyObject *v = PyList_GET_ITEM(list, i);
if ((*self->ob_descr->setitem)(self,
Py_SIZE(self) - n + i, v) != 0) { // <-- live Py_SIZE(self)
...
}
if (n != PyList_GET_SIZE(list)) { // guards the *list*, not self
...
}
}
The loop guards against the source list changing size, but not against self being resized as a side effect of converting an element. Conversion goes through setitem → _PyNumber_Index → __index__, which can run arbitrary Python. If __index__ grows self, Py_SIZE(self) increases, the write index Py_SIZE(self) - n + i slides forward, and the slots reserved by the initial array_resize are never written. array_resize uses PyMem_RESIZE (realloc) with no zeroing, so those slots hold uninitialized heap memory — fully readable from Python after a successful (no-exception) return.
Reproduction:
import array
a = array.array('i')
class Evil:
def __index__(self):
a.extend([0]*5) # grow self during the conversion callback
return 111
a.fromlist([Evil(), 222, 333])
print(a.tolist())
On a debug build:
[111, -842150451, -842150451, 0, 0, 0, 222, 333]
# ^^^^^^^^^^^ ^^^^^^^^^^ slots reserved by array_resize but never written
-842150451 is 0xCDCDCDCD, pymalloc's PYMEM_CLEANBYTE fill for allocated-but-unwritten memory, i.e. the slots are uninitialized. On a release build these slots contain arbitrary process heap bytes (information disclosure), and the real elements (222, 333) are misplaced into the wrong positions. A shrinking __index__ (e.g. del a[0]) likewise leaves an uninitialized slot exposed.
Relationship to gh-144128:
Same entry point as gh-144128 ("CPython UaF during index callbacks", fixed in gh-144138) but a distinct defect. gh-144138 fixed a use-after-free of the borrowed item reference by adding Py_INCREF/Py_DECREF around _PyNumber_Index in II/LL/QQ_setitem; it did not change array_array_fromlist_impl, so this index-recompute / uninitialized-slot issue is still present on main.
Suggested fix:
Fill the fixed slot old_size + i (rather than an offset recomputed from the live Py_SIZE) and add a guard that bails with RuntimeError("array changed size during iteration") if self is resized mid-iteration, mirroring the existing list-mutation guard. PR to follow.
CPython versions tested on:
main (3.16); the code is long-standing and earlier versions are affected too.
Linked PRs
- gh-152167
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
調査の方向性
Modules/arraymodule.c の array_array_fromlist_impl から開始し、配列のサイズを変更する、提供された index コールバックを使って問題を再現してください。既存のミューテーションガードと、関連する PR gh-152167 を確認してください。変換中のサイズ変更によって未書き込みのスロットが露出したり、要素が誤った位置に配置されたりせず、拡大と縮小の回帰テストがカバーされていれば完了です。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- c, python
- 領域
- backend, security
- issue の種類
- バグ
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 活発さ
- 停滞
- 明瞭さ
- 明確に書かれている
- 初心者へのやさしさ
- 25/100