Linuxカーネルにおいて、以下の脆弱性が修正されました。arm64/entryの`cpu_switch_to()`および`call_on_irq_stack()`内でDAIFをマスクします。`cpu_switch_to()`と`call_on_irq_stack()`は、Shadow Call Stackが有効な場合にSPを操作して異なるスタックに切り替えます。これらのスタック切り替えはアトミックには行えず、両関数はSErrorsやDebug Exceptionsによって割り込まれる可能性があります。割り込みが発生するとスタックやShadow Call Stackが不整合となり、スタックの破損を招きます。`cpu_switch_to()`内では、SP_EL0が新しいタスクを指している一方で、x18が古いタスクのSCSを指したままの状態で割り込みが起こる場合があります。割り込みハンドラがタスクのSCSポインタを保存しようとすると、古いタスクのSCSポインタ(x18)が新しいタスク構造体(SP_EL0が指す)に保存されて上書きされます。`call_on_irq_stack()`では、タスクスタックからIRQスタックへの切り替えおよび戻る際の切り替え時に同様の問題が発生します。SCSポインタがIRQ SCSを指しているがSPがタスクスタックを指している場合、ネストされた割り込みハンドラがIRQ SCSにリターンアドレスをプッシュし、その後SPがタスクスタックを指していることを検知して`call_on_irq_stack()`を呼び出し、タスクのSCSポインタをIRQ SCSポインタで上書きします。これによりタスクは誤ったSCSやIRQ SCS上のアドレスに戻り、CONFIG_VMAP_STACKやFPACが有効な場合にカーネルパニックを引き起こす可能性があります。通常の設定では可能性は低いものの、CONFIG_ARM64_PSEUDO_NMIが有効でDAIFがアンマスクされる場合、GICは割り込みの優先度に基づきCPUに受ける割り込みを制御します。擬似NMIは`cpu_switch_to()`や`call_on_irq_stack()`の処理中でも非常に頻繁に発生し得て、予測不可能なカーネルパニックを誘発する恐れがあります。これを防ぐために`cpu_switch_to()`内ではDAIFを完全にマスクし、終了時に復元します。`call_on_irq_stack()`でも同様にマスクと復元を分岐の前後に行います。CONFIG_SHADOW_CALL_STACKが有効でない場合でも、全ての設定で挙動を統一するためにDAIFをマスクします。既存のマクロはIFのみをマスクして保存するため、新たにDAIFを保存しマスクするアセンブリマクロを導入して使用します。

正式な対策が公開されています。ベンダ情報を参照して適切な対策を実施してください。