アカウント名:
パスワード:
良く分からないなぁ。
struct sock *sk = tun->sk;
tun が NULL なら tun->sk を参照した時点で落ちるんじゃないの?その時点で後ろの if ブロックが削られようが削られまいが何も問題ないと思うんだけど。それとも sk のオフセットはメモリアクセスできちゃうエリアに到達するほど大きい値?
struct sock *sk = &tun->sk;
なら分からないでもないけど、それだとGCCの問題な気が・・・
>tun が NULL なら tun->sk を参照した時点で落ちるんじゃないの?>その時点で後ろの if ブロックが削られようが削られまいが何も問題ないと思うんだけど。
gccもそう思って最適化しちゃうんだけど、mmapでメモリを割り当てていた場合、落ちずに処理が進む。進んだときにおかしくなるデータをtun->sk(0x0+offsetof(sk))に仕込んどけはexploitになる。
上記の解説はちょっと変>コンパイラは 'if' ブロックを外してしまい、カーネルは0x00000000にアクセスしようとし、
アクセスした後で NULLチェックしても常に偽と判断され最適化で消えちゃう、というべきか
>上記の解説はちょっと変>>コンパイラは 'if' ブロックを外してしまい、カーネルは0x00000000にアクセスしようとし、>アクセスした後で NULLチェックしても常に偽と判断され最適化で消えちゃう、というべきか
原文はまともです。翻訳するときに時間がなかったのでしょう。よくあることです
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
弘法筆を選ばず、アレゲはキーボードを選ぶ -- アレゲ研究家
バグ?仕様? (スコア:1, 参考になる)
Re: (スコア:1, 興味深い)
良く分からないなぁ。
tun が NULL なら tun->sk を参照した時点で落ちるんじゃないの?
その時点で後ろの if ブロックが削られようが削られまいが何も問題ないと思うんだけど。
それとも sk のオフセットはメモリアクセスできちゃうエリアに到達するほど大きい値?
なら分からないでもないけど、それだとGCCの問題な気が・・・
Re:バグ?仕様? (スコア:3, 参考になる)
>tun が NULL なら tun->sk を参照した時点で落ちるんじゃないの?
>その時点で後ろの if ブロックが削られようが削られまいが何も問題ないと思うんだけど。
gccもそう思って最適化しちゃうんだけど、mmapでメモリを割り当てていた場合、落ちずに処理が進む。
進んだときにおかしくなるデータをtun->sk(0x0+offsetof(sk))に仕込んどけはexploitになる。
上記の解説はちょっと変
>コンパイラは 'if' ブロックを外してしまい、カーネルは0x00000000にアクセスしようとし、
アクセスした後で NULLチェックしても常に偽と判断され最適化で消えちゃう、というべきか
Re:バグ?仕様? (スコア:2)
>上記の解説はちょっと変
>>コンパイラは 'if' ブロックを外してしまい、カーネルは0x00000000にアクセスしようとし、
>アクセスした後で NULLチェックしても常に偽と判断され最適化で消えちゃう、というべきか
原文はまともです。翻訳するときに時間がなかったのでしょう。よくあることです