732字節攻破Linux：一個AI發現的七年老洞

「用AI找漏洞的人，正在重新定義安全研究的節奏。」Xint Code團隊這句輕描淡寫的備注，讓整個Linux生態在補丁周里手忙腳亂。

他們公開了一個存在了七年的內核漏洞。攻擊代碼只有732字節，卻能讓任何本地普通用戶瞬間拿到root權限。更麻煩的是，披露窗口太短，各大發行版根本來不及反應。

一圖讀懂：這個漏洞到底怎么回事

先放下那張核心圖——整個事件的技術鏈條其實不復雜，但每個環節都踩在了Linux架構的敏感神經上。

漏洞編號CVE-2026-31431，根因是密碼學優化引入的代碼缺陷。Linux內核的加密子系統為了性能，把一部分算法處理做成了可加載模塊。問題出在algif_aead這個接口：它允許用戶空間通過AF_ALG套接字與內核加密模塊交互，但在權限校驗上留了空子。

攻擊路徑很直接。普通用戶打開AF_ALG套接字，請求aead（認證加密關聯數據）服務，觸發內核模塊的特定代碼路徑。由于實現缺陷，內核在某些錯誤處理流程中錯誤地提升了進程權限——不是設計如此，純粹是代碼層面的疏忽。

732字節的攻擊代碼做了什么？它精心構造了一系列系統調用序列，觸發那個有缺陷的錯誤處理分支。一旦成功，當前shell的uid就變成了0。不需要內存破壞，不需要ROP鏈，不需要任何現代漏洞利用的復雜技巧。這種簡潔本身就說明了問題的嚴重性：攻擊面太干凈，防御層根本沒設防。

影響范圍是全覆蓋式的。Ubuntu 24（26版上周剛發）、RHEL 10、Suse 16、Amazon Linux 2023，甚至Windows的WSL2都在名單上。2017年至今，幾乎所有主流發行版都攜帶了這個缺陷。

為什么七年沒人發現

這里有個反直覺的點。algif_aead不是冷門代碼，它是Linux內核加密API的標準組件。每天有大量系統在用：TLS卸載、磁盤加密、VPN隧道，都依賴這套接口。

問題藏在「優化」兩個字里。2017年的某次性能改進，重構了錯誤處理流程。代碼審查時，所有人都在看正常路徑對不對，沒人想到異常分支會越權。這種模式在安全史上反復出現：性能壓力下的重構，往往伴隨著權限模型的隱性破壞。

Xint Code的披露策略也引發了爭議。他們沒有給標準的安全響應周期，而是快速公開。團隊只解釋了一句：用AI輔助發現的。這句話信息量很大——AI在代碼審計中的角色，正在從「輔助工具」變成「發現主力」，而發現者的心態也在變化：既然AI能批量掃描，保密窗口期的價值在貶值。

兩種應急方案，都有代價

如果你的內核把algif_aead編譯成模塊，解法相對干凈。寫一條modprobe規則，禁止加載這個模塊，重啟生效。代價是：任何依賴內核aead服務的應用會掛掉，比如某些配置下的IPsec、WireGuard。

RHEL和WSL2的用戶更頭疼。它們把algif_aead編進了內核核心，不是模塊，沒法卸載。這時候只能上強制訪問控制：用seccomp掐掉AF_ALG套接字創建權限，或者配AppArmor/SELinux策略，禁止用戶進程走這條路徑。

這兩種方案的共同問題是：它們都在破壞正常功能。Linux的加密子系統設計上就是給普通用戶用的，現在為了安全要把它封死。多用戶服務器、容器平臺、CI/CD流水線，這些場景本來依賴內核提供的隔離和加密服務，現在要么冒險開著漏洞，要么親手拆掉基礎設施。

驗證漏洞的指令，本身就是個信任陷阱

Xint Code給了一條測試命令：curl一個遠程腳本，用python3跑，然后su。他們自己也備注了——「你在信任一個在線腳本」。

這幾乎是安全研究者的黑色幽默。驗證系統是否脆弱的行為，本身就引入了新的脆弱點。更謹慎的做法是下載他們發布的源碼，本地編譯運行。但多數人會選擇那條732字節的捷徑，因為快。

這種張力貫穿整個事件：AI讓漏洞發現變快了，披露變快了，利用也變快了。但補丁鏈條的響應速度沒有同比例提升。內核補丁已經存在，但流到各個發行版的穩定通道需要時間。Ubuntu、RHEL、Suse的更新節奏不同，容器鏡像的重建和分發又有一層延遲。

對于跑Kubernetes集群的工程師，這意味著什么？你的節點操作系統可能還沒補丁，但集群里跑著不可信的工作負載。傳統的容器逃逸防護假設內核是可信邊界，現在這個假設在本地用戶場景下失效了。

AI輔助漏洞研究的拐點

Xint Code沒有詳細說明AI的具體用法，但語境很清楚：不是用AI生成攻擊代碼，而是用AI審計代碼。這區分了兩種AI安全應用——生成側和發現側。

發現側的規模化正在改變漏洞經濟學的平衡。傳統模式下，安全研究員投入時間挖掘漏洞，選擇負責任的披露或漏洞賞金，都是基于「發現成本高昂」的前提。如果AI把發現成本壓到接近零，披露策略的激勵結構就會重構。快速公開、制造壓力、迫使廠商加速響應，可能變成更理性的選擇——至少對發現者而言。

這不是說Xint Code做錯了什么。他們的做法在倫理上有爭議空間，但技術趨勢是明確的：AI審計工具的普及，會讓更多「沉睡的漏洞」被批量喚醒。Linux內核有3000萬行代碼，加密子系統只是其中一小塊。類似的優化引入的缺陷，可能還藏在文件系統、網絡棧、調度器的某個角落。

給你的行動清單

如果你是基礎設施負責人，現在該做什么：

第一，確認你的內核版本和發行版補丁狀態。不要假設「我上周剛更新過就安全」，這個漏洞的補丁窗口還在滾動。

第二，檢查algif_aead的加載方式。運行lsmod看它在不在模塊列表，或者查/proc/config.gz里的CONFIG_CRYPTO_USER_API_AEAD配置。編進內核核心的，必須走強制訪問控制路線。

第三，評估AF_ALG套接字在你的環境中的真實用量。很多系統其實沒在用內核加密服務，封掉無感知。如果確實在用，規劃補丁窗口期的臨時降級方案。

第四，重新審視容器和多用戶場景的隔離假設。這個漏洞的利用前提是本地用戶權限，但「本地」的定義在容器時代很模糊。sidecar、init容器、調試用的kubectl exec，都可能創造本地用戶上下文。

最后，把AI輔助代碼審計加入你的安全工具鏈。不是為了追趕時髦，而是因為攻擊者已經在用了。防御側的反應速度，必須匹配發現側的加速。