Rustの安全検査に11年前から穴が開いていた

10月13日、jsnellという利用者が、プログラミング言語Rustの開発ページ（GitHub）に、20行ほどのコードを貼った。unsafeという、危ない操作をするときに書く印は、どこにも使っていない。それでも、そのコードは、出番の終わった文字列の置き場所を読んだ。画面に出たのは、そのあとに作った、Xが並ぶだけの別の文字列だった。

Rustは「メモリの安全」を看板にしてきた言語だ。それを支えているのが、借用検査器と呼ばれる自動の検査だ。公式の教科書は、危ない操作をunsafeの中に閉じ込めておけば、メモリ安全の間違いはその中にしかない、と書いている。

報告の題は、構造体に付けたライフタイムの条件が、共変を使った代入で迂回できる、というものだ。報告した人は、最新の試験版と、少なくとも安定版1.85.0で同じことが起きると書いている。

11年前から通っていた

なぜ、だれも気づかなかったのか。

同じ日の議論で、Rustの型システムのチームを率いるlcnrが、「unsound since 1.4 🤣」とだけ書き込んだ。1.4から健全じゃなかった、という意味だ。Rust 1.4が出たのは2015年10月29日。ちょうど11年前の、同じ月だ。

別の開発者theemathasは、どうして今まで見つからなかったんだ、と書き込んだ。

原因はどこにあるのか。開発者maxdexhは、型を重ね合わせるときに、その型に付いたライフタイムの条件を見ていないのではないか、と書き込んだ。ただ、報告のページでは、原因がこれと決まったとは書かれていない。

15分で、危険度が一段下がった

報告から25分後、自動の番人（rustbot）が、いちばん重い「P-critical」の札を貼った。ところが、その15分後、同じ番人が「P-high」に貼り替えた。どちらも、開発者がZulipで話し合った結果だという。

理由は、報告の冒頭に、あとから書き足された。本来ならP-criticalのバグだが、11年も見つからなかったバグが、そう簡単に踏めるわけがない、と。悪用するには、わざと意地の悪い後片付けの処理（Drop）を書く必要があるとも書いてある。

Rustの型システムのチームは今年、「Project Zero」という目標を出している。分かっている健全性のバグを全部直し、未定義の動きを起こす方法をunsafeだけにする、という中身だ。今回の穴は、11年のあいだ、その「分かっている」の外にあった。

では、だれが安全を検査しているのか。検査そのものは機械がやる。でも、その機械に開いた穴を見つけるのも、穴の重さを決めるのも、人だった。

ネットの評判

Hacker Newsに出たこの話には、10月14日の時点で689点、381件のコメントが付いた。

多いのは、穴が1つ見つかってもRustの値打ちは変わらない、という声だ。不完全だからといって、効いていない証拠にはならない、という書き込みが目立つ。Cのコンパイラにも、この手のバグは山ほどあるとの指摘も多い。

一方で、Cを責めて人気を得た言語が、偽の安心を与えていたとも言える、という声もある。

直し方の案は、報告から10時間ほどで届いた。Li-Zheng-Rongという人が出した案（#164277）の本文は、2行だけ。「Fixes rust-lang/rust#164250」「sound again :)」。また健全になった、という意味だ。11年開いていた穴をふさぐこの案は、10月14日の時点で、まだ確認待ちだ。

欠陥が分かった物、まだ使う？この話、あなたはどっち？ →