EST. 2026 — บันทึกงานเซิร์ฟเวอร์จริง SYSADMIN · SECURITY · AI · DIRECTADMIN เล่มที่ 01
THE SYSADMIN ALMANAC
หน้าหลัก / Security Update / Ubuntu FIPS/Tegra แก้ CVE-2026-98432 เร่งแพตช์และรีบูต
Security Update

Ubuntu FIPS/Tegra แก้ CVE-2026-98432 เร่งแพตช์และรีบูต

โดย Ton-Or ·13 พ.ย. 2026·อ่าน 6 นาที
Ubuntu FIPS/Tegra แก้ CVE-2026-98432 เร่งแพตช์และรีบูต

คนดูแล Ubuntu ที่ใช้ kernel FIPS หรือ NVIDIA Tegra ให้ตรวจแพ็กเกจและจัดรอบอัปเดตพร้อมรีบูตโดยเร็ว โดยเฉพาะเครื่องที่รับ TCP จากเครือข่ายที่ไม่ไว้ใจ

สรุปใน 1 นาที

อาการ/ปัญหา
kernel มีช่องโหว่ในส่วนรับการเชื่อมต่อ IPv4 TCP ที่อาจนำไปถึง RCE และมีปัญหาการตรวจ checksum รวมอยู่ด้วย
ใครควรอ่าน
Ubuntu 22.04 LTS สาย linux-fips และ Ubuntu 24.04 LTS สาย linux-nvidia-tegra รวมรุ่น tegra-rt ตามประกาศ
ทางแก้แบบสั้น
อัปเดตแพ็กเกจในสายเดิมตาม USN ตรวจโมดูลภายนอกที่ต้องรองรับ ABI ใหม่ แล้วรีบูตและตรวจ kernel ที่กำลังรัน
ข้ามไปขั้นตอน

พอดีเห็นประกาศ Ubuntu USN-9027-2 กับ USN-9091-1 ลงวันที่ 13 พ.ย. 2026 ออกแพตช์ให้ kernel FIPS และ NVIDIA Tegra ผมเลยรวมไว้ให้ตรวจแยกตาม flavor ครับ แต่ละสายใช้คนละแพ็กเกจ ต้องอัปเดตให้ตรงกับที่ติดตั้งอยู่

9.8CVSS 3.1 ของ CVE-2026-98432
9.3CVSS 3.1 ของ CVE-2026-99999
FIPS / Tegraตรวจแยกตาม kernel flavor
ต้องรีบูตตามคำแนะนำทั้งสอง USN

แพตช์รอบนี้เพิ่มให้ kernel สายไหน

ตารางนี้แสดงรุ่นตาม USN ให้เทียบกับแพ็กเกจใน flavor เดียวกัน หาก repository มีรุ่นใหม่กว่า ให้ตรวจประกาศของสายนั้นประกอบ

ประกาศและ Ubuntu source package / flavor image package ที่ USN ระบุ รุ่นแพ็กเกจตาม USN
USN-9027-2 · 22.04 LTS linux-fips linux-image-5.15.0-203-fips 5.15.0-203.213+fips1
USN-9091-1 · 24.04 LTS linux-nvidia-tegra linux-image-6.8.0-1039-nvidia-tegra 6.8.0-1039.40
USN-9091-1 · 24.04 LTS Tegra RT linux-image-6.8.0-1039-nvidia-tegra-rt 6.8.0-1039.40

FIPS ในประกาศนี้ใช้ช่องทาง FIPS Updates ผ่าน Ubuntu Pro ส่วน metapackage linux-image-fips และ linux-image-fips-5.15 ใช้รุ่น 5.15.0.203.117 เลขรุ่นนี้ต่างจาก image package ส่วน Tegra แยก metapackage ปกติกับ RT ตาม USN-9091-1

หน้า CVE-2026-98432 และ CVE-2026-99999 ยังแสดง FIPS ของ 22.04 และ Tegra ของ 24.04 ว่า “Vulnerable work in progress” พร้อมเลขรุ่นเดียวกับ USN ข้อมูลสองแหล่งยังขัดกันครับ ตารางในโพสต์นี้ใช้รุ่นที่ USN วันที่ 13 พ.ย. 2026 ระบุว่าแก้แล้ว ให้ตรวจ USN-9027-2 และ USN-9091-1 เทียบกับหน้า CVE ก่อนอัปเดต

ช่องโหว่หลักและคะแนนที่ต้องแยกให้ออก

CVE-2026-98432 เป็น use-after-free ตอนสร้างการเชื่อมต่อ IPv4 TCP หากรับ SYN ซ้ำพร้อมกัน หน่วยความจำที่เก็บ options อาจถูกคืนทั้งที่ยังมีโค้ดอีกส่วนอ่านอยู่ Ubuntu ระบุว่าอาจถึง RCE และจัด priority เป็น Critical

หน้า Ubuntu ให้คะแนน CVSS 3.1 9.8 vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H ตาม vector นี้ ผู้โจมตีเข้าทางเครือข่ายได้โดยไม่ต้องมีบัญชีหรือให้ผู้ใช้กดอะไร ส่วน CVSS 4.0 เป็น 9.2 โดย AT:P หมายถึงต้องมีเงื่อนไขเพิ่มเติมในการโจมตี คะแนนไม่ได้รับรองว่าจะโจมตีสำเร็จทุกเครื่อง ดู หน้า CVE ของ Ubuntu

CVE-2026-99999 แก้การตรวจ checksum_start หาก packet มี metadata ผิด โค้ดคำนวณ checksum อาจทำให้ network header เสียหาย หน้า Ubuntu แสดงคะแนน CVSS 3.1 9.3 vector CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H ซึ่งระบุการโจมตีแบบ Local

Ubuntu จัด priority เป็น Medium ส่วน CVSS 4.0 เป็น 6.9 และระบุว่าผู้โจมตีต้องมีสิทธิ์ระดับต่ำด้วย การประเมินสองเวอร์ชันใช้เงื่อนไขต่างกัน เลยไม่ควรเรียกตัวนี้ว่า remote RCE ตามตัวแรก ดู หน้า CVE-2026-99999

CVE-2026-98432 และ CVE-2026-99999 ยังไม่อยู่ใน KEV ฉบับ 10 พ.ย. 2026 ของ CISA เลยไม่มีวันเพิ่มรายการหรือเส้นตาย KEV สำหรับสองตัวนี้ในฉบับดังกล่าว การไม่อยู่ใน KEV ไม่ได้แปลว่าไม่เคยถูกโจมตี ส่วนประกาศ Ubuntu สองฉบับที่อ้างไม่ได้ระบุว่ามีการโจมตีจริง

อย่ารอเฉพาะแพตช์แอป

ปัญหาอยู่ใน kernel ของเครื่องที่รับการเชื่อมต่อ การอัปเดต WordPress หรือ PHP อย่างเดียวไม่ครอบคลุมงานนี้ ให้ตรวจระบบปฏิบัติการและ kernel ที่กำลังรันแยกต่างหาก

FIPS แก้อะไรเพิ่ม และ Tegra ต้องดูฮาร์ดแวร์ด้วย

USN-9027-2 ระบุ CVE-2025-21656, CVE-2026-63940 และ CVE-2026-74350 เพิ่มจากสองตัวหลักด้วย ตัวแรกเกี่ยวกับไดรเวอร์ drivetemp เมื่อเกิด SCSI error เช่นดิสก์หลุด ไดรเวอร์อาจส่งข้อมูลจากหน่วยความจำที่ยังไม่ได้กำหนดค่าออกไปยัง userspace หน้า CVE-2025-21656 ของ Ubuntu ระบุ priority เป็น Medium

ส่วน CVE-2026-63940 แก้การรับคำขอ Port I/O ที่ความยาวหรือจำนวนเป็นศูนย์ใน KVM SEV เพื่อกัน underflow Ubuntu จัด priority เป็น Critical ตาม หน้า CVE-2026-63940 ส่วน Red Hat ให้คะแนน CVSS 3 ที่ 7.0 และจัดระดับ Moderate ต่างจากคะแนน 9.3 ของ cve.org ที่แสดงในตารางเดียวกัน ผู้ประเมินให้คะแนนต่างกันครับ ต้องตรวจด้วยว่าระบบใช้งานส่วนนี้หรือไม่

ประกาศ Tegra รวมช่องโหว่หลายส่วนของ kernel ผมเลือกเน้นสอง CVE ของ IPv4 ข้างต้น ส่วน CVE-2023-20585 ในประกาศระบุ AMD processors, IOMMU และ SEV-SNP โดยตรง การมีชื่อ CVE นี้ในประกาศไม่ได้แปลว่า Tegra ทุกตัวได้รับผลจากปัญหา AMD ต้องตรวจ CPU, kernel config และส่วนที่ใช้งานด้วย

บริบทเดิมอ่าน รวมแพตช์ Debian/Ubuntu, Ubuntu kernel แยก flavor และ แพตช์ NVIDIA/Tegra ได้

ตรวจแพ็กเกจ อัปเดต แล้วตรวจหลังรีบูต

เริ่มจากตรวจ Ubuntu, สถาปัตยกรรม, kernel และแพ็กเกจ คำสั่ง uname -r แสดง kernel release ที่กำลังรัน ส่วน dpkg-query แสดงรุ่นเต็มของแพ็กเกจที่ติดตั้งอยู่

cat /etc/os-release
uname -m
uname -r
dpkg-query -W -f='${binary:Package}\t${Version}\t${Status}\n' \
  'linux-image-*' 'linux-headers-*' 2>/dev/null
apt-mark showhold
  1. จับคู่สาย ตรวจ Ubuntu, flavor, image และ metapackage ที่ติดตั้งอยู่
  2. เตรียมรอบบำรุงรักษา ตรวจพื้นที่บูต ช่องทางกู้คืน และโมดูลภายนอกก่อนเปลี่ยน ABI
  3. ตรวจรายการอัปเดต จำลองการอัปเกรดแล้วอ่านแพ็กเกจที่จะเพิ่มและถอดออก
  4. ติดตั้งและรีบูต ยืนยัน kernel ใหม่กับการทำงานของอุปกรณ์ก่อนปิดงาน

FIPS ให้ตรวจช่องทางด้วย pro status หากติดตั้ง Ubuntu Pro client ไว้ อัปเดตโดยใช้สายเดิม ทั้ง FIPS, Tegra ปกติ และ Tegra RT ตรวจรุ่นที่พร้อมติดตั้งด้วย apt-cache policy linux-image-fips หรือเปลี่ยนเป็นชื่อ metapackage ที่ติดตั้งจริง หากไม่พบรุ่นตาม USN ให้ตรวจ repository และสิทธิ์ใช้งานก่อน

sudo apt update
apt -s full-upgrade
# อ่านรายการเปลี่ยนแปลงก่อนดำเนินการในรอบบำรุงรักษา
sudo apt full-upgrade
# เมื่อการติดตั้งสำเร็จและพร้อมหยุดบริการ
sudo reboot

ทั้งสอง USN เตือนว่า ABI เปลี่ยน โมดูล kernel จากภายนอกต้องคอมไพล์และติดตั้งให้ตรงกับ kernel ใหม่ ตรวจ headers และผลการสร้างโมดูลก่อนรีบูต หากใช้ DKMS ให้ดู dkms status ด้วย หากติดตั้งโมดูลด้วยวิธีอื่น ให้ทำตามขั้นตอนของผู้ผลิต การติดตั้ง image ใหม่ไม่ได้รับรองว่าไดรเวอร์เครือข่ายหรืออุปกรณ์เฉพาะจะพร้อมใช้งาน

แพ็กเกจใหม่ต้องตามด้วย kernel ที่รันจริงตรวจ flavorFIPS / Tegra / RTอัปเดตแพ็กเกจคงสายเดิมตรวจโมดูลรองรับ ABI ใหม่รีบูตและยืนยันuname -rตรวจทั้งแพ็กเกจที่ติดตั้งและ kernel ที่กำลังทำงาน
ลำดับปิดงานแพตช์ โดยตรวจโมดูลภายนอกก่อนรีบูต และตรวจ release ที่บูตขึ้นมาจริงอีกครั้ง

หลังรีบูต ตรวจ kernel กับ image package ให้ตรงกัน ค่าจากตารางคือ 5.15.0-203-fips, 6.8.0-1039-nvidia-tegra หรือ 6.8.0-1039-nvidia-tegra-rt หากติดตั้งรุ่นใหม่กว่า ค่าจะเปลี่ยนตามนั้น

uname -r
dpkg-query -W -f='${binary:Package}\t${Version}\t${Status}\n' \
  "linux-image-$(uname -r)"
systemctl --failed
journalctl -b -k -p warning --no-pager

ระหว่างรอแพตช์และการตรวจร่องรอย

หน้า CVE ของ Ubuntu แนะนำวิธีลดความเสี่ยงชั่วคราวสำหรับ CVE-2026-98432 โดยกรอง IPv4 TCP packet ที่มี IP options แต่ระบุว่าป้องกันการโจมตีได้ไม่ครบ ก่อนทำตาม ขั้นตอนของ Ubuntu ให้ตรวจว่าระบบต้องใช้ IP options หรือไม่ และใช้เครื่องมือ firewall ตัวไหนอยู่ ส่วน container ที่แยกเครือข่ายต้องตั้งกฎแยกด้วย ผมแนะนำให้ทดสอบกับระบบเดิมก่อนบันทึกกฎให้คงอยู่หลังรีบูต

ยังไม่มี IOC เฉพาะในประกาศที่อ้าง

kernel warning, Oops, panic หรือการรีบูตผิดปกติเป็นจุดเริ่มตรวจสอบ แต่ยืนยันการถูกเจาะจากอาการเหล่านี้อย่างเดียวไม่ได้ และการไม่มีข้อความใน log ก็รับรองความปลอดภัยไม่ได้

หากพบอาการผิดปกติ ให้เก็บ kernel log และเวลาที่เกิดเหตุไว้เทียบกับ log เครือข่ายตามขั้นตอน incident response การตรวจว่าใช้ kernel ที่แพตช์แล้วไม่ได้บอกว่าก่อนหน้านั้นเคยมีผู้บุกรุกหรือไม่

ผมให้ความเร่งด่วนแค่ไหน

ส่วนตัวผมให้เครื่องที่รับ IPv4 TCP จากเครือข่ายที่ไม่ไว้ใจเป็นงานเร่ง ควรจัดรอบอัปเดตและรีบูตให้เร็วที่สุดหลังทดสอบผ่าน ส่วน FIPS กับอุปกรณ์ Tegra ที่มีไดรเวอร์เฉพาะ ให้เตรียมช่องทางกู้คืนและตรวจโมดูลก่อนด้วย หลังบูตต้องตรวจว่าระบบกลับมาทำงานครบ คำสั่ง apt จบโดยไม่มี error ยังไม่พอสำหรับปิดงาน

ที่มา: Ubuntu USN-9027-2, Ubuntu USN-9091-1, Ubuntu CVE-2026-98432, Ubuntu CVE-2026-99999, Ubuntu CVE-2025-21656, Ubuntu CVE-2026-63940, Red Hat CVE-2026-63940, CISA KEV data ข้อมูลถึง 13 พ.ย. 2026 โดยไฟล์ KEV ที่ตรวจได้เป็นฉบับ 10 พ.ย. 2026 เดี๋ยวกลับมาแก้เพิ่มให้ภายหลังครับ

อยากให้เราทำให้ไหม?

ให้เราช่วยติดตั้ง ตั้งค่า ย้ายระบบ หรือแก้ปัญหาเซิร์ฟเวอร์ เพื่อให้คุณมีเวลาไปทำงานที่สำคัญกว่า

คุยเรื่องงานกับเรา

เคยเจองานแบบนี้ไหม? ติดตรงไหน?

มาแลกวิธีกันต่อในบอร์ด LinuxThai

→ คุยต่อในบอร์ด

ความคิดเห็น 0

ยังไม่มีความคิดเห็น — เป็นคนแรกเลย