在infoq網(wǎng)站上，Gil Tene最近報(bào)告一個(gè)十分重要，但并不為人知Linux內(nèi)核補(bǔ)丁，特別對(duì)采用Haswell架構(gòu)的Linux系統(tǒng)用戶和管理員應(yīng)該特別關(guān)注。報(bào)告提醒Red Hat發(fā)行版的用戶(包括CentOS 6.6及Scientific Linux 6.6)，即便是運(yùn)行在虛擬機(jī)中的Linux，虛擬機(jī)在流行的Azure、Amazon云平臺(tái)上，也可能運(yùn)行在Haswell服務(wù)器上，立即更新這個(gè)補(bǔ)丁。

Gil Tene對(duì)該缺陷的描述如下：

“這個(gè)內(nèi)核漏洞的影響非常簡單：在看似不可能情況下，用戶進(jìn)程會(huì)死鎖并被掛起。即使被正確地喚醒，futex調(diào)用等待都有可能被阻止執(zhí)行。如同Java里的Thread.park()可能會(huì)一直阻塞等，若幸運(yùn)可能會(huì)在dmesg日志中發(fā)現(xiàn)soft lockup消息；如果沒那么幸運(yùn)，將不得不花幾個(gè)月的人工成本去排查問題，可能一無所獲。”

Tene解釋了這個(gè)缺陷代碼是如何執(zhí)行的（歸結(jié)到一個(gè)遺漏了default情況的switch塊）。最大的問題是，盡管問題代碼在2014年1月修復(fù)，但是在10月該缺陷又被移回了Red Hat 6.6系統(tǒng)中，使得其他系統(tǒng)包括SLES、Ubuntu、Debian等或被被影響。

據(jù)了解，這些系統(tǒng)由于修復(fù)情況不同有可能被忽略。Red Hat用戶應(yīng)該采用RHEL 6.6.z或更新的版本。Tene指出一個(gè)關(guān)鍵點(diǎn)在于，修復(fù)針對(duì)不同的發(fā)行版會(huì)有不同的選擇，這也導(dǎo)致問題的修復(fù)情況并不一致。

對(duì)于RHEL 7.1而言，其實(shí)3.10內(nèi)核是沒有這個(gè)bug的，但RHEL 7.1就像RHEL 6.6那樣在移植的時(shí)候把這個(gè)bug包含了進(jìn)去，導(dǎo)致其他發(fā)行版可能也是如此。

對(duì)基于RHEL的發(fā)行版，Tene提供了一個(gè)快速參考列表：

RHEL 6（包括CentOS 6和Scientific Linux 6）：從6.0～6.5版都沒問題。 但6.6版存在缺陷，而6.6.z版本沒有問題。

RHEL 7（包括CentOS 7和Scientific Linux 7）：7.1是有缺陷的。并且截至2015年5月13日也沒有一個(gè)7.x的修復(fù)。

RHEL 5（包括CentOS 5和Scientific Linux 5）：所有版本（包括5.11版）沒有問題。

盡管在Hacker News上對(duì)受影響系統(tǒng)的數(shù)量存在一些爭(zhēng)議，但提供了一些環(huán)境來檢查系統(tǒng)是否需要修復(fù)。