Linux เผชิญช่องโหว่ร้ายแรงครั้งที่สองในรอบสองสัปดาห์ เมื่อนักวิจัย Hyunwoo Kim เปิดเผย "Dirty Frag" ซึ่งเชื่อมช่องโหว่ระดับเคอร์เนลสองรายการเข้าด้วยกัน ทำให้ผู้ใช้ที่มีสิทธิ์ต่ำสามารถยึดสิทธิ์ root ได้บนดิสทริบิวชันหลักแทบทุกตัว Microsoft รายงานว่าพบสัญญาณการโจมตีในสภาพแวดล้อมจริงแล้ว และโค้ด PoC ก็เผยแพร่สู่สาธารณะแล้วเช่นกัน
Dirty Frag คืออะไร และทำงานอย่างไร
Dirty Frag เป็นการโจมตีแบบ Local Privilege Escalation (LPE) ที่เชื่อมช่องโหว่สองรายการในเคอร์เนล Linux เข้าด้วยกัน ได้แก่
- CVE-2026-43284 (CVSS 8.8 — HIGH): พบในฟังก์ชัน
esp_input()ของ IPsec ESP ซึ่งประมวลผลแพ็กเก็ต esp4 และ esp6 - CVE-2026-43500 (CVSS 7.8 — HIGH): พบใน
rxkad_verify_packet_1()ของโปรโตคอล RxRPC
ทั้งสองช่องโหว่มีต้นตอจากการจัดการ page cache ในหน่วยความจำที่บกพร่อง โดยนักวิจัยจาก Automox อธิบายว่า Dirty Frag อยู่ในตระกูลเดียวกับ "Dirty Pipe" (2022) แต่เปลี่ยนเป้าหมายจาก pipe_buffer มาเป็น struct sk_buff frag แทน
กลไกการโจมตีคือการใช้ splice() เพื่อฝังการอ้างอิงไปยัง page cache แบบอ่านอย่างเดียว เช่น /etc/passwd หรือ /usr/bin/su เข้าไปใน frag slot ของ skb ฝั่งส่ง จากนั้นเมื่อเคอร์เนลฝั่งรับทำการเข้ารหัสบน frag นั้น page cache ใน RAM จะถูกเขียนทับ ผู้โจมตีที่มีเพียงสิทธิ์อ่านก็สามารถทำให้ระบบมองเห็นไฟล์เวอร์ชันที่ถูกดัดแปลงได้ในการอ่านครั้งต่อไป
ช่องโหว่ทั้งสองมีอยู่ในเคอร์เนลมาตั้งแต่ปี 2017 (xfrm-ESP) และ 2023 (RxRPC) ตามลำดับ หมายความว่าเคอร์เนลที่ปล่อยออกมาในช่วง 9 ปีที่ผ่านมาล้วนได้รับผลกระทบ
เหตุใดจึงอันตรายเป็นพิเศษ — PoC เผยแพร่แล้ว Microsoft พบการโจมตีจริง
สิ่งที่ทำให้ Dirty Frag น่ากังวลกว่าช่องโหว่ทั่วไปมีหลายประการ
ประการแรก เอกสารเผยแพร่ถูกรั่วไหลโดยบุคคลที่สามทันทีหลัง Kim เปิดเผย ส่งผลให้เกิดสภาวะ zero-day ก่อนที่แพตช์จะแพร่หลาย Kim จึงตัดสินใจปล่อยโค้ด PoC ของตัวเองออกมา และโค้ดที่รั่วไหลก็หมุนเวียนอยู่ในอินเทอร์เน็ตแล้ว
ประการที่สอง เอกสพลอยต์ทำงานแบบ deterministic คือให้ผลลัพธ์เดิมทุกครั้งที่รัน ไม่ขึ้นกับดิสทริบิวชัน และที่สำคัญคือ ไม่ทำให้ระบบ crash ซึ่งทำให้ตรวจจับได้ยากมาก
ประการที่สาม Microsoft รายงานว่าพบ timeline การโจมตีจริงในสภาพแวดล้อมจริง ได้แก่ การเข้าถึงผ่าน SSH → สร้าง interactive shell → ปล่อย ELF binary (./update) → ยกระดับสิทธิ์ด้วย su
นักวิจัยจาก Aviatrix ระบุว่า "เนื่องจาก PoC exploit เผยแพร่สู่สาธารณะแล้ว และมีหลักฐานการโจมตีในสภาพแวดล้อมจริงแม้จะจำกัด องค์กรต่าง ๆ จำเป็นต้องเร่งใช้แพตช์และมาตรการบรรเทาโดยเร็วที่สุด"
สภาพแวดล้อมไหนเสี่ยงที่สุด
ความเสี่ยงแตกต่างกันตามการตั้งค่าของระบบ
ความเสี่ยงสูง:
- เซิร์ฟเวอร์ที่มีผู้ใช้หลายรายร่วมกัน (multi-tenant / shared hosting)
- VPS ที่อนุญาตให้ผู้ใช้ทั่วไป SSH เข้าได้
- Virtual Machine ที่ไม่ได้ hardened
- Ubuntu บนโฮสต์ที่ไม่ได้รันคอนเทนเนอร์ — ผู้ใช้ local สามารถยกระดับสิทธิ์เป็น root ได้
ความเสี่ยงต่ำกว่า:
- Kubernetes ที่ใช้ค่าเริ่มต้น seccomp profile — นักวิจัยจาก Wiz (Google) ระบุว่าโอกาส container escape ต่ำ
- ระบบที่ AppArmor บล็อกการสร้าง namespace โดยผู้ใช้ที่ไม่น่าเชื่อถือ (ช่วยบล็อกเส้นทาง ESP)
- ระบบที่ไม่ได้โหลด
rxrpc.koตามค่าเริ่มต้น (ช่วยบล็อกเส้นทาง RxRPC)
อย่างไรก็ตาม เมื่อใช้ทั้งสองช่องโหว่ร่วมกัน Kim ยืนยันว่าสามารถยึด root ได้บนดิสทริบิวชันหลักทุกตัวที่ทดสอบ
สำหรับผู้ดูแลระบบในไทยที่ใช้งาน VPS หรือ cloud server บน Linux ไม่ว่าจะเป็นบน AWS, Google Cloud, หรือผู้ให้บริการในประเทศ ควรถือว่าระบบของตนอยู่ในกลุ่มเสี่ยงจนกว่าจะได้รับการแพตช์
สถานะแพตช์และวิธีรับมือ
เคอร์เนล Linux mainline แก้ไขช่องโหว่ทั้งสองแล้ว โดย CVE-2026-43284 แก้ไขที่ commit f4c50a4034e6 และ CVE-2026-43500 ที่ commit aa54b1d27fe0 ช่องโหว่ถูกรายงานต่อทีม Linux kernel maintainer เมื่อวันที่ 30 เมษายน 2026
| ดิสทริบิวชัน | สถานะ |
|---|---|
| Debian | ปล่อยแพตช์แล้ว |
| AlmaLinux 8 | ปล่อยแพตช์แล้ว (CVE-2026-43284) |
| AlmaLinux 9/10 | ปล่อยแพตช์แล้ว (CVE-2026-43500 เฉพาะเมื่อติดตั้ง kernel-modules-partner) |
| Fedora | ปล่อยแพตช์แล้ว |
| Red Hat / OpenShift | เผยแพร่ข้อมูลใน RHSB-2026-003 พร้อมวิธีบล็อก kernel module ชั่วคราว (ไม่ต้องรีบูต) |
| ดิสทริบิวชันอื่น ๆ | ให้ตรวจสอบกับผู้ให้บริการโดยตรง |
ขั้นตอนที่แนะนำ:
- อัปเดตเคอร์เนลทันที — ใช้คำสั่ง
apt upgrade/dnf upgrade/yum updateตามดิสทริบิวชัน - รีบูตระบบ หลังอัปเดต เนื่องจากการแก้ไขเคอร์เนลต้องการการรีสตาร์ท
- หากยังไม่มีแพตช์ ให้ใช้มาตรการชั่วคราวของผู้ให้บริการ เช่น blacklist kernel module ตามคำแนะนำของ Red Hat
- ตรวจสอบ log หาสัญญาณผิดปกติ โดยเฉพาะ SSH login จากแหล่งที่ไม่คุ้นเคย และการรัน binary ที่ไม่รู้จัก
ควรระลึกว่า Dirty Frag ไม่สามารถป้องกันได้ด้วยมาตรการที่ใช้กับ Copy Fail เนื่องจากสามารถทำงานได้โดยไม่ต้องพึ่ง algif_aead module ดังนั้นระบบที่ blacklist algif_aead แล้วก็ยังคงเสี่ยงอยู่
