osdn 曰く、

スタックが伸びすぎるとどうなるのか、という疑問は誰しも考えたことはあるでしょう。
実際にスタック範囲を他のメモリ領域と衝突させて悪用できることが 2005 年と 2010 年に示され、対策が取られてきました。
しかしセキュリティ企業 Qualys は 19 日、少なくとも Linux, OpenBSD, NetBSD, FreeBSD, Solaris の i386 と amd64 では対策の不備があり、実際に悪用可能か、少なくとも PoC が存在することを示しました。(ITmediaの日本語記事)
数多くの入口からローカル権限上昇攻撃ができた (あるいは理論上可能な道筋がある) そうです。
緩和策としては limits.conf 等でスタックを制限することなどがありますが、完全ではありませんし副作用も大きいです。各ベンダーには既に通知され、順次対策が取られることになっていますので、アップデートの用意をしておくのが最善でしょう。
アドバイザリによれば、Debian でも 8.5 と 8.6, また 8.x と 9 以上の間には脆弱さに大きな違いがあり、最新のものほど効率よく悪用することは難しくなってきているそうです。
しかし現状で最も簡単に悪用できる方法は i386 の Debian で Exim を使ってローカル権限上昇をすることだ、と Qualys は指摘しています。
また OpenBSD では at を使って攻撃しようとしたものの、ファイルシステムが遅すぎて、一週間かけてもヒープがスタックに届くほどの数のジョブファイルを作成できなかったそうです。
なお、今回は 64bit でもスタックと他領域が近い場合があることも示されましたが、基本的にはメモリ領域が広い方が安全です。
grsecurity/PaX にはスタック・ガードページの大きさを変更できる機能があるので、これを大きくするのは簡単で有効です。また GCC には -fstack-check というオプションがあり、各 4KB ページにアクセスすることで、スタックポインタが他領域に行ってしまう前に必ずガードページに当たり、SEGV になってくれるそうです。パフォーマンスに影響はありますが、長期的には良い方法だと Qualys は指摘しています。

情報元へのリンク