回答:
Stack Clashは、かなり古い手法に基づいたエクスプロイトです。プロセスで使用されるメモリは、スタックとヒープの 2つの領域に分割されます。一般的に、スタックは下向きに成長し、ヒープは上向きに成長すると想像します。どちらかがもう一方と衝突するほど大きくなったらどうなりますか？より一般的には、関連のないメモリ空間に侵入するほどスタックが大きくなるとどうなりますか？元の脆弱性は12年前のもので、Linuxカーネル開発者はガードページを使用して一時的に修正しました。しかし、Qualysの研究者は、ガードページにもかかわらずこれを悪用することに成功しました。
Stack Clashの脆弱性は、2005年にセキュリティ研究者GaëlDelalleauの発見で最初に発見され、5年後に研究者Rafal WojtczukによるLinuxの脆弱性のリリースで広く知られるようになりました。Linux開発者 は、スタックの衝突を防ぐことを目的とした保護を導入しましたが、今日の調査では、攻撃者がその手段を迂回することは比較的容易であることを実証しています。
Qualysが開発した主要な概念実証攻撃は、CVE-2017-1000364としてインデックス付けされた脆弱性を悪用します。Qualysの研究者は、CVE-2017-1000365やCVE-2017-1000367などの個別の脆弱性を悪用するためにStack Clashを使用する攻撃も開発しました。たとえば、最近修正されたSudoの欠陥であるCVE-2017-1000367と組み合わせてQualysが発見した場合、ローカルユーザーはSudoを利用して、より広範なOSで完全なルート権限を取得できます。Qualysはこれまで、エクスプロイトにリモートでコードを実行させることはできませんでした。彼らが調査した唯一のリモートアプリケーションはEximメールサーバーであり、偶然にも悪用できないことが判明しました。Qualysは、このようなリモートコード実行エクスプロイトが存在する可能性を排除できないと述べました。Qualysは、概念実証のエクスプロイトを後日リリースする予定であり、
[...] Qualysのこの詳細なテクニカルアドバイザリとgrsecurityのこのテクニカル分析で、さらに多くの情報を利用できます。
2010年の元の修正に関するLWNの記事を引用：
Linuxはプロセススタックページとヒープページを分離しないため、スタックページを隣接するヒープページにオーバーランする可能性があります。つまり、十分な深さのスタック（たとえば、再帰呼び出しから）がヒープ内のメモリを使用することになります。そのヒープページに書き込むことができるプログラム（Xクライアントなど）は、呼び出しの1つの戻りアドレスを操作して、選択した場所にジャンプできます。つまり、クライアントはサーバーに任意のコード（任意のコード実行）を実行させることができ、これを利用してルート権限を取得できます。
上記の説明は、さまざまなUnixライクなカーネルに適用されます。
Ars Technicaは、Qualysレポートに記載されている一時的な回避策（「ローカルユーザー と リモートサービスの ハードRLIMIT STACKとRLIMIT_AS を 低い値に設定する」）に注意していますが、これは必ずしもこのエクスプロイトを保護するものではないことに注意してください。現在のところ唯一の安全な方法はアップグレードすることです。grsecurity分析によると：
本当の問題はスタック調査の欠如にあるため、この問題を解決するカーネルのみの試みは常に不完全であることは明らかです。代替の実際のソリューションは、すべてのユーザーランドの再構築に依存するため、これはおそらく予見可能な将来の唯一の実行可能なソリューションです。
2010のエクスプロイトはXサーバーを使用し、これはsudoを使用しました。次のエクスプロイトは、ある時点で、昇格された特権で実行される多数のユーザーランドプログラムのいずれかです。
Qualysは、エクスプロイトの概念実証コードをまだ公開していません（後日公開する予定です）。
CVE-2017-1000364に関連付けられた複数のUbuntuセキュリティ通知があります。
また、CVEトラッカーには、リリース/カーネルのいくつかの組み合わせが保留中の修正としてリストされていることに注意してください。
一般的に、最も簡単な修正は、システムをできるだけ早く最新のカーネルパッケージに更新することです。
USNの関連カーネルバージョン（を使用して選別for i in {24..35}; curl -s https://www.ubuntu.com/usn/usn-33$i-1/ | pup 'dl:nth-last-of-type(1)'）：
前述のsudoバグは、2017年5月30日以降のUSN-3304-1でカバーされています。
マルチOSバグはどのようにして発生しましたか？
質問のこの部分に具体的に対処するには：
この問題は、ヒープ（上向きに大きくなる）およびスタック（下向きに大きくなる）に共有アドレス空間を使用するために発生します。
この設計は多くのシステムで共通であるため、多くのシステムが同じクラスの脆弱性に対して脆弱である理由です。