Gil Tene氏は先日の記事で，Linuxシステムのすべてのユーザと管理者，中でもHaswellプロセッサの利用者に対して，重要だがあまり知られていないLinuxカーネルのパッチを再検討するべきだと，その重要性を提起している。特にRed Hatベースのディストリビューション(CentOS 6.6やScientific Linux 6.6を含む)ユーザは，可能な限り速やかにパッチを適用するべきだ，と氏は言う。LinuxインスタンスがVM上で稼働していたとしても，一般的なクラウドプロバイダ(Azue/Amazonなど)では，VMがHaswellマシン上で稼働している可能性が高いので，パッチを適用する価値はある。
今回の欠陥について，氏は，次のように説明する。
“このカーネルバグによる影響は，一見不可解な状況でユーザプロセスがデッドロックあるいはハングアップするという，極めて単純なものです。futex waitコール(およびfutex callを使用するすべて)が，誰かによって適切に起動されたにも関わらず，ブロックされたままになる可能性があるのです。影響を受けるのは，JavaのThread.park()などです。運がよければdmesgのログに，ソフトロックアップのメッセージが記録されるかも知れません。あまり運がよくなくて(例えば私たちのように)，ログに何も残っていないような場合には，自分のコードの中から原因を見つけようと，誰かの時間を何ヶ月も費やしてしまう可能性もあります。”
さらに氏は，欠陥を持ったコードがどのように動作するかについても説明している(結局それは，defaultのケースのないswicth文のようなものだ)。この問題の大きな原因は，問題のコードが2014年1月にフィックスされているにも関わらず，欠陥が2014年10月頃のRed Hat 6.6ファミリにバックポートされてしまったことにある。他のシステム(SLES, Ubuntu, Debianなど)にもおそらく影響があるだろう。
これらシステムのフィックスは今だけ配布されているなので，見落としてしまう可能性がある。Red HatユーザはRHEL 6.6.z移行を探さなくてはならない。重要な点として氏が指摘するのは，フィックスの提供が限定的であるため，それぞれのディストリビューションで，使用しているカーネルに合った選択をする必要があることだ。
例えばRHEL 7.1では，“upstream 3.10にはバグはないのですが，RHEL 7のバージョンは，純粋なupstreamバージョンと同じではありません。残念ながらRHEL 7.1には(RHEL 6.6と同じように)，バグを含んだ変更がバックポートされているのです ... 他のディストリビューションでも，同じような問題があると思われます。”
RHELベースのディストリビューションに関して，氏は，参照用のクイックテーブルを用意している(強調文字は原文のまま)。
RHEL 6 (およびCentOS 6, SL 6): 6.0-6.5はOK。6.6はNG，6.6.z はOK。
RHEL 7 (およびCentOS, SL 7) : 7.1はNG。昨日時点では，7.xフィックスは公開されていない。[2015年5月13日]
RHEL 5 (およびCentOS 5, SL 5): すべてのバージョンがOK (5.11含む)。
今回の発見についてのHacker Newsの議論では，影響を受けるシステムの数に異論が見られるものの，システムにパッチが必要かどうかを確認するための検証用コンテキストがいくつか提供されている。