Ubuntu kernel แพตช์ CVE-2026-99999 เช็ก flavor แล้วนัดรีบูต
ผู้ดูแล Ubuntu server และโฮสต์ VM ควรตรวจ release กับ kernel flavor แล้วจัดรอบอัปเดตและรีบูต โดยเร่งเครื่องที่เปิดให้ผู้ใช้หลายรายรันโค้ดและโฮสต์ SEV-SNP
สรุปใน 1 นาที
- อาการ/ปัญหา
- kernel มีข้อผิดพลาดหลายส่วน รวม checksum metadata ใน IPv4 และการเข้าถึงหน่วยความจำ VM แต่ละช่องโหว่มีเงื่อนไขโจมตีต่างกัน
- ใครควรอ่าน
- Ubuntu release และ kernel flavor ที่ระบุในแต่ละ USN แต่ละประกาศครอบคลุมต่างกัน ต้องตรวจให้ตรงกับเครื่องที่ดูแล
- ทางแก้แบบสั้น
- อัปเดตแพ็กเกจจากคลังที่ตรงกับ release และ flavor รีบูตแล้วตรวจ kernel ที่กำลังรัน ส่วน SEV-SNP ต้องทำตามข้อกำหนด firmware ของ AMD เพิ่มด้วย
พอดีเห็นประกาศอัปเดต kernel ของ Ubuntu ลงวันที่ 10 พ.ย. 2026 หลายฉบับ ผมเลยรวมรายการที่เกี่ยวกับงาน server และ VM ไว้ด้านล่าง CVE-2026-99999 ได้คะแนน Critical ใน CVSS 3.1 และมี attack vector เป็น Local ก่อนอัปเดตต้องเช็กทั้ง Ubuntu release และ kernel flavor ให้ตรงกัน
ประกาศไหนตรงกับ kernel ที่ใช้อยู่
ตารางนี้ระบุ Ubuntu release ตามหน้ารวมประกาศทางการ ส่วน kernel flavor และรุ่นแพ็กเกจที่แก้ ต้องดูรายละเอียดของแต่ละ USN เพิ่ม ผมตัดเลขแพ็กเกจออกจากฉบับนี้ เพราะเปิดหน้ารายละเอียด USN เพื่อตรวจซ้ำไม่ได้
| USN | Ubuntu release ที่ประกาศครอบคลุม |
|---|---|
| 9022-1 | 24.04 LTS |
| 9023-1 | 24.04 LTS |
| 9024-1 | 24.04 LTS และ 22.04 LTS |
| 9025-1 | 24.04 LTS และ 22.04 LTS |
| 9026-1 | 22.04 LTS (Azure) |
| 9029-1 | 22.04 LTS (Raspberry Pi) |
| 9032-1 | 18.04 LTS, 16.04 LTS และ 14.04 LTS |
| 9033-1 | 16.04 LTS และ 14.04 LTS |
| 9034-1 | 14.04 LTS (AWS) |
| 9035-1 | 14.04 LTS |
จำนวน USN ไม่ใช่จำนวนช่องโหว่ เพราะ CVE เดียวอยู่ได้หลายประกาศ ผมเลยไม่บวกจำนวน CVE จากแต่ละประกาศเข้าด้วยกัน
CVE-2026-99999 รุนแรงแค่ไหน
Ubuntu อธิบาย ว่าข้อผิดพลาดอยู่ใน IPv4 ตอนจัดการแพ็กเก็ตที่มี checksum metadata ไม่ถูกต้อง ฟังก์ชัน skb_checksum_help อาจทำให้ network header เสียหาย แพตช์เพิ่มการตรวจ checksum_start ก่อนคำนวณ checksum
หน้าเดียวกันให้ CVSS 3.1 = 9.3 Critical ด้วย vector CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H ขณะที่ CVSS 4.0 = 6.9 Medium ใช้ CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:H/SC:N/SI:N/SA:N และ Ubuntu priority เป็น Medium ทั้งสอง vector ระบุสิทธิ์ที่ต้องใช้ต่างกัน: CVSS 3.1 เป็น PR:N ส่วน CVSS 4.0 เป็น PR:L เวลาเทียบคะแนนต้องดูทั้งเวอร์ชัน CVSS และเงื่อนไขใน vector
ทั้งสอง vector ระบุ AV:L การเปิดเว็บออกอินเทอร์เน็ตอย่างเดียวไม่ได้ยืนยันว่าโจมตี CVE นี้ได้โดยตรง แต่เครื่องที่ให้ผู้ใช้รันโค้ดหรือมีบัญชีถูกยึดอยู่แล้วควรเร่งประเมินเงื่อนไขในเครื่อง
สถานะบนหน้า Ubuntu ยังไม่ตรงกัน: หน้ารวมประกาศลง USN-9022-1 วันที่ 10 พ.ย. 2026 ว่ามีการแก้ Linux kernel และหน้า CVE ก็ลิงก์ถึง USN นี้ แต่หน้า CVE ที่อัปเดต 9 พ.ย. 2026 ยังระบุ linux ของ 24.04 ว่า Vulnerable / work in progress พร้อมเลข 6.8.0-149.149 ผมเลยไม่ถือว่าเลขนี้เป็นรุ่นที่แก้แล้ว ต้องเทียบกับรายละเอียด USN และแพ็กเกจในคลังอีกครั้ง
CVE-2026-99999, CVE-2023-20585, CVE-2022-23036 และ CVE-2022-23037 ยังไม่อยู่ใน KEV ฉบับ 9 พ.ย. 2026 ตามไฟล์ JSON ทางการของ CISA การไม่อยู่ใน KEV ไม่ได้แปลว่าไม่มีการโจมตี
โฮสต์ VM ต้องดู AMD และ Xen เพิ่ม
CVE-2023-20585 เชื่อมกับ USN-9024-1, USN-9025-1 และ USN-9026-1 ในหน้า CVE ของ Ubuntu ปัญหาอยู่ที่การตรวจ Reverse Map Table ตอน IOMMU เข้าถึง host buffer ตาม AMD-SB-3016 ผู้โจมตีต้องมีสิทธิ์และควบคุม hypervisor ที่ถูกยึดแล้ว ถึงอาจเขียนข้อมูลจนกระทบความถูกต้องของหน่วยความจำ SEV-SNP guest ได้
AMD กำหนดให้ทำทั้ง SEV firmware และ OS update รวมถึงปิด SNP guest แล้วเริ่มต้นใหม่ตามขั้นตอนของ AMD เลยต้องประสานผู้ดูแลเครื่องจริงหรือผู้ให้บริการ cloud ด้วย การรีบูตเฉพาะ guest ยังไม่พอจะบอกว่าฝั่ง host และ firmware แก้ครบแล้ว
Ubuntu เชื่อม CVE-2022-23037 กับ USN-9033-1 และ USN-9034-1 ส่วน Xen XSA-396 อธิบายทั้ง CVE-2022-23036 และ CVE-2022-23037 ตัวแรกอยู่ใน blkfront ตัวหลังอยู่ใน netfront ทั้งคู่มี race ตอน frontend ยกเลิกสิทธิ์ที่เคยให้ backend เข้าถึงหน่วยความจำของ guest ทำให้ backend ที่เป็นอันตรายอาจยังอ่านหรือเขียนหน่วยความจำนั้นได้หลัง I/O จบ ต้องตรวจ kernel ฝั่ง guest ที่ใช้ frontend เหล่านี้ด้วย
สำหรับงานเครือข่าย หน้า CVE ของ Ubuntu ยังเชื่อม USN-9032-1 กับ CVE-2026-53086 ซึ่งเป็น race ใน timeout handler ของไดรเวอร์ bcmgenet ตัว handler ไปหยุดทุก transmit queue ทั้งที่มีเพียง queue เดียว timeout ก่อนจัดลำดับแพตช์ ให้ตรวจว่าเครื่องใช้อุปกรณ์และไดรเวอร์นี้หรือไม่
อัปเดตให้ตรง flavor และนัดรีบูต
เริ่มจากตรวจ release, kernel ที่รัน, แพ็กเกจที่ติดตั้ง และรายการ hold
cat /etc/os-release
uname -r
dpkg-query -W -f='${binary:Package}\t${Version}\n' 'linux-image*'
apt-mark showhold
pro status
ถ้าแพ็กเกจต้องใช้ Ubuntu Pro/ESM ให้ตรวจสิทธิ์และบริการที่เปิดไว้ด้วย pro status ตามคู่มือ ESM ก่อน จากนั้นตรวจว่าคลังที่เครื่องใช้มีแพ็กเกจรุ่นที่ต้องการแล้วหรือยัง
- จับคู่ release กับ flavor เทียบแพ็กเกจใน USN และตรวจคลังกับสิทธิ์ Pro/ESM
- เตรียมรอบบำรุงรักษา สำรองข้อมูล เตรียม console และจัดการ workload ของ VM
- ติดตั้งแพตช์ ตรวจรายการอัปเกรดและโมดูลภายนอกก่อนรีบูต
- ยืนยันหลังบูต ตรวจ kernel ที่รันและบริการจริง ส่วน SNP ตรวจ firmware กับการเริ่ม guest ใหม่เพิ่ม
อัปเดตตามคู่มือ Ubuntu ตรวจว่ามี kernel metapackage ของ flavor ที่ใช้อยู่ แล้วดูผลจำลองก่อนติดตั้งจริง
sudo apt update
sudo apt upgrade --simulate
sudo apt upgrade
ถ้า kernel ยังไม่ถูกอัปเกรด ให้ตรวจ hold และ dependency ก่อน ใครใช้ DKMS ให้ตรวจผลการสร้างโมดูลด้วย พอติดตั้งครบแล้วค่อยรีบูตในรอบที่เตรียมไว้
sudo systemctl reboot
เช็กหลังอัปเดตและหาความผิดปกติ
หลังเชื่อมต่อกลับมา ให้ดูทั้ง uname -r กับเวอร์ชันแพ็กเกจของ kernel ที่กำลังรัน การติดตั้งแพ็กเกจสำเร็จยังไม่ได้บอกว่าเครื่องบูตด้วย kernel ใหม่แล้ว
uname -r
dpkg-query -W -f='${binary:Package}\t${Version}\n' "linux-image-$(uname -r)"
systemctl --failed
sudo journalctl -k -b --no-pager
เทียบเวอร์ชันแพ็กเกจกับ release และ flavor เดียวกันในรายละเอียด USN จากนั้นทดสอบ network, storage และบริการเว็บหรือ mail ที่เครื่องนั้นให้บริการ ถ้าเครื่องบูตด้วย kernel เก่า ให้ตรวจว่าเลือก kernel ตัวไหนตอนบูต และหาสาเหตุที่ kernel ใหม่ใช้ไม่ได้ก่อนปิดงาน
ตรวจ kernel Oops, panic, ปัญหา I/O และ VM crash เป็นเบาะแสประกอบได้ แต่พบอาการเหล่านี้ไม่ได้ยืนยันว่าโดน และไม่พบก็ไม่ได้ยืนยันว่าปลอดภัย
ส่วนตัวผมจะเร่งเครื่องไหนก่อน
ส่วนตัวผมจะเร่งนัดแพตช์และรีบูตเครื่องที่ให้หลายผู้ใช้รันโค้ด กับโฮสต์ที่ใช้ SEV-SNP ปกป้อง guest ส่วนเครื่องอื่นให้ตรวจเงื่อนไขของแต่ละ CVE แล้วจัดเข้ารอบบำรุงรักษาหลังตรวจ flavor ครบ
ที่มา: หน้ารวม Ubuntu Security Notices และรายการ USN 9022-1, 9023-1, 9024-1, 9025-1, 9026-1, 9029-1, 9032-1, 9033-1, 9034-1, 9035-1 ส่วนข้อมูลช่องโหว่ดูจาก Ubuntu CVE-2026-99999, Ubuntu CVE-2026-53086, AMD-SB-3016, Xen XSA-396, CISA KEV และหน้า CVE กับคู่มือ Ubuntu ที่ลิงก์ในเนื้อหา ตรวจข้อมูลวันที่ 10 พ.ย. 2026 โดย KEV เป็นฉบับ 9 พ.ย. 2026 ส่วนรายละเอียดรุ่นแพ็กเกจใน USN ยังเปิดตรวจไม่ได้ เดี๋ยวกลับมาแก้เพิ่มให้ภายหลังครับ
อยากให้เราทำให้ไหม?
ให้เราช่วยติดตั้ง ตั้งค่า ย้ายระบบ หรือแก้ปัญหาเซิร์ฟเวอร์ เพื่อให้คุณมีเวลาไปทำงานที่สำคัญกว่า
เคยเจองานแบบนี้ไหม? ติดตรงไหน?
มาแลกวิธีกันต่อในบอร์ด LinuxThai
ความคิดเห็น 0
ยังไม่มีความคิดเห็น — เป็นคนแรกเลย