กลับ

2026/11/04

CVE-2026-98432: ช่องโหว่ use-after-free ใน TCP ของ Linux การยึดสิทธิ์ root จากระยะไกลผ่าน MPTCP ด้วย AI และแนวป้องกันสำหรับ Linux องค์กร

race condition ในการจัดการ IPv4 TCP ของ Linux การสาธิตยึดสิทธิ์ root ผ่าน MPTCP และการแก้ไขกับมาตรการบรรเทาสำหรับ RHEL, Ubuntu, Oracle Linux และ Debian

ตรวจสอบข้อมูลเมื่อ: 3 พฤศจิกายน 2026 | บทวิเคราะห์ทางเทคนิคของ LOGIQ

ในเดือนตุลาคม 2026 มีการเปิดเผยช่องโหว่ use-after-free (UAF) หมายเลข CVE-2026-98432 ในส่วนจัดการการเชื่อมต่อ IPv4 TCP ของเคอร์เนล Linux ทีม CVE ของเคอร์เนล Linux ออกประกาศเมื่อวันที่ 15 ตุลาคม และในวันที่ 27 ตุลาคม Anthropic รายงานว่าโมเดลวิจัยภายในที่ยังไม่เปิดตัวสามารถสาธิตการรันคำสั่งจากระยะไกลด้วยสิทธิ์ root โดยไม่ต้องยืนยันตัวตน บนเซิร์ฟเวอร์ Linux ที่มี listener แบบ MPTCP (Multipath TCP) สิ่งสำคัญคือ ไม่ควรนำเงื่อนไขการโจมตีเฉพาะนี้ไปปะปนกับความเสี่ยงของช่องโหว่และการปฏิเสธการให้บริการในวงกว้างที่กระทบบริการ IPv4 TCP ทั่วไป

ประเด็นสำคัญ

  • ข้อบกพร่องนี้เป็น race condition ในการจัดการคำขอเชื่อมต่อ IPv4 TCP ทั่วไป ซึ่งมีมาตั้งแต่ Linux 4.4 และตัวบั๊กเองไม่จำเป็นต้องใช้ MPTCP
  • การสาธิตยึดสิทธิ์ root จากระยะไกลของ Anthropic มุ่งเป้าไปที่เซิร์ฟเวอร์ที่มี listener แบบ MPTCP ส่วนบริการ TCP อื่น ๆ ยังคงเสี่ยงต่อการล่ม การปฏิเสธการให้บริการ และหน่วยความจำเสียหาย
  • Red Hat จัดระดับปัญหานี้เป็น Critical (CVSS v3.1 9.8) และออกเคอร์เนลที่แก้ไขแล้วสำหรับ RHEL 8, 9 และ 10 เมื่อวันที่ 1 พฤศจิกายน ส่วนการแก้ไขของ Ubuntu ยังอยู่ระหว่างดำเนินการ ณ วันที่ 3 พฤศจิกายน
  • ติดตั้งเคอร์เนลที่แก้ไขแล้วซึ่งผู้จำหน่ายรับรอง รีบูต และยืนยันเคอร์เนลที่กำลังทำงานอยู่ มาตรการบรรเทาช่วยลดความเสี่ยงได้ แต่ไม่สามารถใช้แทนแพตช์ได้

race condition เกิดขึ้นที่ใด

ปัญหานี้เกี่ยวข้องกับกระบวนการ three-way handshake ของ IPv4 TCP โดย IP options ที่ request socket ถืออยู่ (ireq->ireq_opt) อาจถูกย้ายไปยัง inet_opt ของ child socket ระหว่าง tcp_v4_syn_recv_sock() โดยไม่มีการคัดลอก หาก CPU อีกตัวกำลังประมวลผล SYN ที่ถูกส่งซ้ำและสร้าง SYN/ACK อยู่ในขณะที่ child socket ถูกทำลาย หน่วยความจำของ options อาจถูกปล่อยคืนทั้งที่ยังถูกใช้งานอยู่ และการเข้าถึงในภายหลังโดยฟังก์ชันอย่าง ip_options_build() อาจทำให้เกิด UAF

race condition ที่เกี่ยวข้องยังเกิดขึ้นในการย้าย request socket ผ่าน net.ipv4.tcp_migrate_req=1 หรือ BPF_SK_REUSEPORT_SELECT_OR_MIGRATE ซึ่งข้อมูล options อาจถูกใช้ร่วมกันระหว่าง request socket ต้นฉบับกับตัวที่ถูกโคลน พฤติกรรมที่มีช่องโหว่นี้มีมาตั้งแต่ Linux 4.4 แต่ความเสี่ยงที่แท้จริงต้องประเมินตามเคอร์เนลของผู้จำหน่ายแต่ละราย รวมถึงการ backport ด้วย

commit แก้ไขจาก upstream e3f33b0a1d89 (“ipv4: free inet_opt and ireq_opt after an RCU grace period”) เปลี่ยนการคืนหน่วยความจำทันทีใน inet_sock_destruct() และ tcp_v4_reqsk_destructor() ให้เป็นการคืนหน่วยความจำแบบหน่วงเวลาตาม RCU ผ่าน kfree_rcu() ประกาศ CVE ของ Linux ระบุว่ามีการแก้ไขในเคอร์เนลเวอร์ชัน 6.12.113, 6.18.56, 7.2.10 และ 7.3-rc7 เส้นทาง IPv6 เริ่มต้นไม่ใช่ช่องโหว่เดียวกัน แม้ว่าเส้นทางการย้ายของ IPv6 ที่เกี่ยวข้องกับ CALIPSO จะได้รับการแก้ไขด้วยแพตช์แยกต่างหาก

อย่าสับสนระหว่างการยึดสิทธิ์ root จากระยะไกลที่สาธิตแล้วกับความเสี่ยงโดยทั่วไป

proof of concept ของ Anthropic มุ่งเป้าไปที่เซิร์ฟเวอร์ที่มี listener แบบ MPTCP และผสานการรั่วไหลของข้อมูลแอดเดรสในเคอร์เนลเข้ากับการยึดการควบคุมลำดับการทำงาน (control-flow hijacking) ตามรายงาน การทดลองใช้เวลาประมาณ 48 นาทีในการได้ข้อมูลที่รั่วไหล และอีกห้านาทีเพื่อรันคำสั่งได้สำเร็จ เนื่องจากการแพ้ race เพียงทำให้ handshake ล้มเหลวโดยไม่ทำให้ระบบล่ม ผู้โจมตีจึงลองซ้ำได้เรื่อย ๆ อย่างไรก็ตาม UAF ที่เป็นต้นเหตุอยู่ในการจัดการคำขอเชื่อมต่อ IPv4 TCP ทั่วไป ไม่ได้อยู่เฉพาะในโค้ดของ MPTCP

เทคนิคการยึดสิทธิ์ root จากระยะไกลแบบเดียวกันนี้ยังไม่ได้รับการสาธิตกับบริการ TCP แบบดั้งเดิมทุกตัวที่ไม่มี MPTCP แต่การคิดว่าการปิด MPTCP จะทำให้ระบบปลอดภัยโดยสมบูรณ์ก็ไม่ถูกต้องเช่นกัน Red Hat ระบุว่า MPTCP ไม่ใช่เงื่อนไขที่จำเป็น ระบบที่ปิด MPTCP (ค่าเริ่มต้น) ยังคงได้รับผลกระทบ และเตือนถึงความเสี่ยงที่ระบบจะล่มจากระยะไกลโดยไม่ต้องยืนยันตัวตน การปฏิเสธการให้บริการ และหน่วยความจำเสียหายในบริการ IPv4 TCP มาตรฐาน

การประเมินหลักของผู้จำหน่าย: ระดับความรุนแรงและสถานะการแก้ไข

สถานะ ณ วันที่ตรวจสอบ 3 พฤศจิกายน 2026 หน้าเว็บของผู้จำหน่ายอาจเปลี่ยนแปลงได้ ควรตรวจสอบข้อมูลล่าสุดทุกครั้งก่อนดำเนินการ

ผู้จำหน่ายระดับความรุนแรงสถานะการแก้ไข
Red HatCritical, CVSS v3.1 9.8ออกเคอร์เนลที่แก้ไขแล้วเมื่อ 1 พฤศจิกายน: RHEL 8 (RHSA-2026:93414; kernel-rt สำหรับ NFV RHSA-2026:93415), RHEL 9 (RHSA-2026:93412), RHEL 10 (RHSA-2026:93413) ส่วน RHEL 9 kernel-rt และ OpenShift (RHCOS) ยังอยู่ในสถานะ Affected โดย RHEL 6 และ 7 ไม่ได้รับผลกระทบ
Ubuntuลำดับความสำคัญ High; CVSS 9.8linux สำหรับ 26.10, 26.04, 24.04 และ 22.04: Vulnerable, work in progress ส่วน 20.04, 18.04 และ 16.04: Vulnerable ยังไม่มีแพ็กเกจที่แก้ไขแล้วออกมา
Oracle LinuxImportant; CVSS เบื้องต้น 8.1errata ของ UEK ลงวันที่ 16 ตุลาคม (ELSA-2026-500397, -500398, -500399) สำหรับ OL7 ถึง OL10 และ errata ของ RHCK ลงวันที่ 2 พฤศจิกายน สำหรับ OL8 (ELSA-2026-93414) และ OL10 (ELSA-2026-93413) ยังไม่มี erratum ของ RHCK สำหรับ OL9
Debian(Security Tracker)แก้ไขแล้วใน bookworm 6.1.190-1 (DLA-4841-1), bookworm linux-6.12 6.12.113-1~deb12u1 (DLA-4850-1) และ trixie 6.12.113-1 (DSA-6568-1) ส่วน forky และ sid แก้ไขแล้ว

Red Hat (แก้ไขการประเมินเมื่อ 30 ตุลาคม; ประกาศอัปเดตล่าสุดเมื่อ 2 พฤศจิกายน) หน้า CVE อย่างเป็นทางการจัดระดับปัญหานี้เป็น Critical, CVSS v3.1 9.8 เนื่องจากผู้โจมตีจากระยะไกลที่ไม่ต้องยืนยันตัวตนสามารถทำให้หน่วยความจำของเคอร์เนลเสียหายหรือทำให้ระบบล่มได้ผ่านทราฟฟิก IPv4 TCP ทั่วไป RHEL 8, 9, 10 และ OpenShift อยู่ในรายการที่ได้รับผลกระทบ ส่วนเคอร์เนลของ RHEL 7 ไม่ได้รับผลกระทบเพราะไม่มีโค้ดส่วนที่เกี่ยวข้อง ตั้งแต่ 1 พฤศจิกายน ข้อมูล CVE ของ Red Hat ระบุเคอร์เนลที่แก้ไขแล้ว ได้แก่ kernel-4.18.0-553.182.1.el8_10 (RHEL 8), kernel-5.14.0-687.64.1.el9_8 (RHEL 9) และ kernel-6.12.0-211.72.1.el10_2 (RHEL 10) ประกาศด้านความปลอดภัย RHSB-2026-016 ยังมีสถานะกำลังดำเนินการ และเป็นแหล่งข้อมูลสำหรับขั้นตอนการบรรเทาผลกระทบ ไม่ควรนำคะแนนเก่าจากแหล่งข้อมูลทุติยภูมิ เช่น 5.9 หรือ 8.1 มาอ้างเป็นการประเมินปัจจุบันของ Red Hat

Ubuntu (ตารางอย่างเป็นทางการอัปเดตล่าสุดเมื่อ 30 ตุลาคม) CVSS ของ CVE คือ 9.8 ขณะที่ลำดับความสำคัญของ Ubuntu เองคือ High แพ็กเกจ linux มาตรฐานสำหรับ Ubuntu 26.10, 26.04, 24.04 และ 22.04 ถูกระบุว่า “Vulnerable, work in progress” พร้อมเวอร์ชันที่วางแผนจะแก้ไขแสดงอยู่บนหน้าเว็บ ส่วน 20.04 ถูกระบุว่า Vulnerable รวมถึงสถานะอื่น ๆ เคอร์เนลรุ่นย่อยอย่าง AWS, Azure, HWE, RT และอื่น ๆ ต้องประเมินแยกกัน “work in progress” ไม่ได้หมายความว่ามีการออกการแก้ไขแล้ว

Oracle Linux การประเมินของ Oracle เองคือ Important โดยมีคะแนน CVSS เบื้องต้น 8.1 errata ของ UEK สำหรับ OL7, OL8, OL9 และ OL10 ลงวันที่ 16 ตุลาคม และ errata ของ RHCK สำหรับ OL8 และ OL10 ตามมาในวันที่ 2 พฤศจิกายน ไม่ควรเหมารวมว่าการแก้ไขใน UEK ใช้ได้กับ RHCK หรือทุก minor release ให้ประเมินจากเคอร์เนลที่ติดตั้งจริงและ errata ที่ตรงกัน

Debian Security Tracker อย่างเป็นทางการระบุว่า bookworm-security 6.1.190-1 และ trixie-security 6.12.113-1 รวมถึงเวอร์ชันอื่น ๆ ได้รับการแก้ไขแล้ว ให้ตรวจสอบทั้งเวอร์ชันแพ็กเกจที่ติดตั้งและเคอร์เนลที่กำลังทำงานหลังรีบูต

ผล CVSS ระหว่าง CNA กับผู้จำหน่ายอาจแตกต่างกันได้ เนื่องจากการกำหนดค่าและการแก้ไขเฉพาะของแต่ละดิสทริบิวชัน และการประเมินอาจเปลี่ยนแปลงได้ ควรบันทึกวันที่ตรวจสอบและลิงก์ไปยังแหล่งข้อมูลอย่างเป็นทางการแต่ละแห่งทุกครั้ง

มาตรการป้องกัน: การบรรเทาผลกระทบไม่สามารถใช้แทนแพตช์ได้

สิ่งที่ต้องทำเป็นอันดับแรกคือ ติดตั้งเคอร์เนลที่แก้ไขแล้วซึ่งผู้จำหน่ายรับรอง และตรวจสอบเวอร์ชันที่กำลังทำงานหลังรีบูต หากยังไม่มีการแก้ไข ให้พิจารณาปิดบริการ TCP สาธารณะที่ไม่จำเป็น จำกัดเครือข่ายต้นทางที่อนุญาต และให้ความสำคัญกับการเฝ้าระวังโฮสต์ที่เปิดเผยสู่ภายนอก

ประกาศของ Red Hat อธิบายมาตรการบรรเทาด้วย nftables ที่ทิ้งแพ็กเก็ต IPv4 TCP ขาเข้าซึ่งมี IP options อยู่ใน IPv4 header:

table inet cve_2026_98432 {
  chain input {
    type filter hook input priority -310; policy accept;
    ip protocol tcp ip hdrlength > 5 counter drop
  }
}

มาตรการนี้ไม่ใช่การป้องกันที่สมบูรณ์ อาจรบกวนเวิร์กโหลดที่พึ่งพา IP options และต้องทดสอบผลกระทบต่อทราฟฟิกทางธุรกิจก่อนนำไปใช้ TCP options ทั่วไปใน TCP header ยังคงได้รับอนุญาต นี่ไม่ใช่การบล็อกฟิลด์ TCP Options บน OpenShift กฎระดับโหนดไม่ได้กรองทราฟฟิกระหว่าง pod ภายในเครือข่ายคลัสเตอร์ การกรองที่ขอบเขตเครือข่ายจึงมีความสำคัญในกรณีนี้ เมื่อเคอร์เนลที่แก้ไขแล้วทำงานแล้ว ให้ลบ table นี้ออก

เคล็ดลับ: หลังติดตั้งแพตช์ ให้เปรียบเทียบผลของ uname -r กับเวอร์ชันที่แก้ไขแล้วใน erratum ของผู้จำหน่าย และเก็บผลลัพธ์นั้นไว้กับบันทึกการเปลี่ยนแปลง แพ็กเกจที่ติดตั้งแล้วแต่ยังไม่ได้บูตเข้าใช้งาน ไม่ได้ปิดช่องโหว่นี้

บน Linux แพ็กเกจ net ของ Go ใน Go 1.24 ขึ้นไปจะเปิดใช้ MPTCP สำหรับ listener เป็นค่าเริ่มต้น ทีม Go ระบุในเอกสารว่าสามารถปิดได้ด้วย GODEBUG=multipathtcp=0 (หรือใช้บรรทัด godebug ใน go.mod) ข้อเสนอให้เปลี่ยนค่าเริ่มต้นยังอยู่ระหว่างการพิจารณา และผู้ดูแล Go ชี้ว่าการแก้ไขที่แท้จริงคือเคอร์เนลที่ติดตั้งแพตช์แล้ว การตั้งค่านี้ช่วยลดความเสี่ยงจากเส้นทางการโจมตีที่ต้องพึ่ง MPTCP ซึ่ง Anthropic สาธิต แต่ไม่ได้แก้ไข UAF ในเคอร์เนลโดยตรง ควรตรวจสอบการใช้ MPTCP ทีละบริการ

มุมมองของ LOGIQ

การดูแลรักษา Linux ระดับองค์กรไม่สามารถตัดสินความปลอดภัยจากคะแนน CVSS สาธารณะหรือ uname -r เพียงอย่างเดียว ต้องประเมินเวอร์ชันระบบปฏิบัติการ ตระกูลเคอร์เนล (เช่น UEK เทียบกับ RHCK) เวอร์ชันแพ็กเกจ เคอร์เนลที่บูตอยู่ในปัจจุบัน การเปิดเผยทางเครือข่าย การตั้งค่า MPTCP errata ของผู้จำหน่าย และหลักฐานการรีบูตไปพร้อมกัน และติดตามทั้งห่วงโซ่ตั้งแต่การประเมินผลกระทบและการทดสอบ ไปจนถึงการนำไปใช้และการเฝ้าระวังการทำงาน

ในช่วงที่ผู้จำหน่ายยังไม่ออกการแก้ไข ให้บันทึกความเสี่ยงคงเหลือจากมาตรการบรรเทาชั่วคราว และประเมินมาตรการเหล่านั้นใหม่เมื่อมีแพตช์ออกมา เมื่อ AI ทำให้ช่องโหว่ถูกนำไปใช้โจมตีได้จริงง่ายขึ้น การดูแลรักษาระบบองค์กรจึงต้องครอบคลุมทั้งวงจร ได้แก่ การตรวจพบ การยืนยัน การแก้ไข และหลักฐานว่าระบบทำงานได้เป็นปกติ

แหล่งข้อมูลหลักและเอกสารอ้างอิง