Ubuntu NVIDIA/Tegra แพตช์ CVE-2026-93221 ควรรีบอัปเดต

พอดีผมเห็นประกาศ Ubuntu USN-9002-1 กับ USN-9003-1 ลงวันที่ 6 พ.ย. 2026 เลยรวมแพตช์ kernel NVIDIA/Tegra ไว้ด้วยกัน ผมเน้น NFS server บน Tegra ส่วน Bluetooth ให้ดูว่าเปิดใช้งานหรือเปล่า แพตช์ชุดนี้แก้ kernel ตามสายที่ระบุ ไม่ใช่แพตช์ไดรเวอร์การ์ดจอที่ Ubuntu ทุกเครื่องต้องลง

แพตช์ใหม่แยกตามสาย kernel

ตารางนี้เป็นรุ่นแพ็กเกจที่แต่ละ USN ระบุว่าแก้แล้ว ชื่อสาย kernel ในตารางเป็นชื่อ source package ต้องเทียบให้ตรงทั้ง release และ flavor แต่ละประกาศแก้คนละชุด CVE เลยใช้ตารางนี้สรุปว่า NFS แก้แล้วทุกสายไม่ได้

ฝั่ง Tegra ตัว metapackage เช่น linux-image-nvidia-tegra และ linux-image-nvidia-tegra-rt เป็นรุ่น 6.8.0-1038.42 ไม่มี +2 แบบแพ็กเกจ image ต้องดูชื่อแพ็กเกจคู่กับเลขรุ่น ส่วน generic หรือ cloud flavor อื่นให้ดู USN ของสายนั้น (USN-9002-1, USN-9003-1)

อ่าน ชุดอัปเดต Ubuntu วันที่ 5 พ.ย. 2026 ประกอบได้ โพสต์นี้เพิ่มแพตช์วันที่ 6 พ.ย. 2026

NFS server: race condition จนคืนหน่วยความจำซ้ำ

CVE-2026-93221 ใน USN-9002-1 อยู่ที่ nfsd4_end_grace() ซึ่งตรวจและตั้งธงจบ grace period แยกกัน งานเบื้องหลังกับคำสั่ง RECLAIM_COMPLETE เลยอาจเห็นว่าต้องทำงานต่อพร้อมกัน ถ้าใช้ tracking backend ที่ล้างตาราง reclaim ทั้งสองงานอาจล้างรายการเดียวกันซ้ำจนเกิด double-free งานที่อ่านตารางนี้พร้อมกันก็อาจอ่านหน่วยความจำที่คืนไปแล้ว แพตช์เปลี่ยนการตรวจและตั้งธงให้เป็น atomic (ทะเบียน CVE)

ทะเบียน CVE ระบุ CVSS 3.1 = 8.1 High กับ vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H ส่วน Ubuntu ให้ priority Critical ซึ่งเป็นคนละเกณฑ์ ผู้โจมตีเข้าทางเครือข่ายได้โดยไม่ต้องมีสิทธิ์หรือให้ผู้ใช้กดอะไร แต่ต้องมีเงื่อนไข grace/reclaim ที่เกี่ยวข้องและแข่งกับงานอีกฝั่งได้พอดี (รายละเอียด NFS, คะแนนในทะเบียน CVE)

ต้องตรวจว่าเครื่องเป็น NFS server ที่ใช้ NFSv4 grace/reclaim และ tracking backend ที่เกี่ยวข้อง การเป็น NFS client อย่างเดียวไม่พอจะสรุปว่าได้รับผลจากบั๊กนี้

Bluetooth: คะแนนสูง แต่ต้องดูทางเข้าจริง

CVE-2026-89774 อยู่ในทั้งสอง USN เป็น use-after-free ใน Bluetooth SCO ฟังก์ชัน sco_conn_ready() อาจใช้ socket พร้อมกับที่อีกงานกำลังปิด socket นั้น แพตช์เพิ่มการถือ reference และตรวจสถานะซ้ำหลังล็อก

Ubuntu แสดง 8.8 High และ priority Medium โดย vector เป็น CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H ผู้โจมตีต้องอยู่ในระยะ Bluetooth ไม่ใช่ส่ง request เว็บมาจากอินเทอร์เน็ต หน้าแจกแจงคะแนนของ Ubuntu ติดป้าย CVSS v3.0 แต่ vector ระบุ 3.1 ทะเบียน CVE ก็ระบุคะแนน 8.8 และ vector นี้เป็น CVSS 3.1 ผมเลยใช้รุ่นตามทะเบียน CVE (รายละเอียด Bluetooth, ทะเบียน CVE)

สถานะแพตช์ Bluetooth ก็ยังต่างกัน หน้า CVE ของ Ubuntu แสดง Tegra บน 24.04, linux-nvidia-7.0 บน 24.04 และ linux-nvidia-bos บน 26.04 เป็น Vulnerable พร้อมข้อความ work in progress แต่ทั้งสอง USN ระบุรุ่นแก้ตามตาราง ผมใช้รายการจาก USN และให้ตรวจ candidate ใน APT ประกอบ (สถานะแพ็กเกจในหน้า CVE)

ให้เร่งเครื่องที่เปิด Bluetooth และตรวจอุปกรณ์กับโมดูลที่ใช้อยู่ด้วย อย่าดูแค่ว่า service bluetooth หยุดอยู่แล้วสรุปว่าปลอดภัย

io_uring, AMD SEV-SNP และรายการอื่น

CVE-2026-81010 ยังถูกอ้างใน USN-9002-1 แต่ทะเบียน CVE เปลี่ยนสถานะเป็น REJECTED เมื่อ 4 พ.ย. 2026 ทะเบียนบอกเพียงว่าหน่วยงานที่ออกเลขปฏิเสธหรือถอนเลขนี้ แหล่งข้อมูลสองแห่งเลยยังไม่ตรงกัน ผมคงเลขนี้ไว้เพื่ออธิบายรายการใน USN พร้อมระบุว่าถูกถอนแล้ว (USN-9002-1, สถานะในทะเบียน CVE)

หน้า CVE ของ Ubuntu อธิบายว่างาน io_uring/waitid ที่ถูกยกเลิกอาจไปทำงานใน kworker แทน task ต้นทาง ส่วน USN ระบุว่าผู้โจมตี local อาจทำเครื่องล่มหรือ DoS ทั้งหมดนี้เป็นคำอธิบายของ Ubuntu ที่ยังอ้างหมายเลขซึ่งถูกถอนแล้ว (รายละเอียด io_uring ของ Ubuntu, USN-9002-1)

CVE-2023-20585 ใน USN-9003-1 เกี่ยวกับ AMD SEV-SNP บั๊กอยู่ที่การตรวจ Reverse Map Table เมื่อ IOMMU เข้าถึง host buffer ผู้โจมตีต้องมีสิทธิ์และควบคุม hypervisor ได้แล้ว บั๊กนี้อาจทำให้ข้อมูลในหน่วยความจำ guest ถูกแก้ไข Ubuntu ให้ priority Low โดยอธิบายว่าต้องมี CAP_SYS_ADMIN เพื่อกำหนด VFIO passthrough และสร้าง DMA ที่ทำให้เกิด IOMMU events บนฮาร์ดแวร์ที่ได้รับผล (รายละเอียด SEV-SNP)

สำหรับ CVE นี้ AMD ระบุว่าต้องอัปเดตทั้ง SEV firmware และ OS รวมถึงปิดแล้วเริ่ม SNP guest ใหม่ การอัปเดต kernel อย่างเดียวเลยยังไม่ครบขั้นตอนของ AMD (AMD-SB-3016)

ทั้งสอง USN มี CVE-2026-92502 ซึ่งแก้ xarray tags ที่ค้างอยู่ใน ext4 โหมด data=journal บั๊กนี้อาจทำให้เกิด warning ตอน remount เป็น read-only ระหว่างรีบูต รายการอื่นครอบคลุม filesystem, networking, BPF, memory management และไดรเวอร์หลายกลุ่ม ให้ดูรายชื่อเต็มตาม flavor (รายละเอียด ext4)

ประกาศทั้งสองฉบับไม่ได้ระบุว่ามีการโจมตีจริง ทั้งห้าหมายเลขที่กล่าวถึงในโพสต์นี้ยังไม่อยู่ใน KEV ฉบับ 4 พ.ย. 2026 (catalogVersion: 2026.11.04) เลยไม่มีวันเพิ่มหรือเส้นตาย CISA สำหรับรายการเหล่านี้ในฉบับนั้น ผมตรวจจาก JSON ใน repository ทางการของ CISA การไม่อยู่ใน KEV ไม่ได้แปลว่าไม่มีการโจมตี (CISA KEV JSON)

อัปเดตให้ตรงสาย แล้วรีบูต

ตรวจ release, kernel ที่กำลังรัน และ image ที่ติดตั้ง แถวที่ไม่ใช่ installed ไม่นับว่าติดตั้งอยู่

cat /etc/os-release
uname -r
uname -v
dpkg-query -W -f='${Package}\t${Version}\t${db:Status-Status}\n' \
  'linux-image-*nvidia*'

ใช้ apt-cache policy ตามด้วยชื่อแพ็กเกจที่ติดตั้ง ดูว่า candidate เป็นรุ่นแก้หรือใหม่กว่าในสายเดียวกัน ถ้าแพ็กเกจถูก hold หรือใช้ repository อื่น ต้องตรวจสาเหตุด้วย อย่าสลับ flavor เพียงเพราะเลขมากกว่า

1. ตรวจขอบเขต จับคู่ release, flavor และบริการที่เปิดจริง
2. เตรียมรีบูต สำรองข้อมูลและเตรียมทางกู้บูตตามระบบ
3. อัปเดต อ่านรายการจำลองก่อน แล้วตรวจโมดูลภายนอกหลังติดตั้ง
4. ยืนยันผล รีบูต เทียบ image ที่กำลังรัน และทดสอบบริการเดิม

sudo apt update
sudo apt -s full-upgrade
# อ่านรายการเปลี่ยนแปลงก่อนทำขั้นถัดไป
sudo apt full-upgrade
if command -v dkms >/dev/null 2>&1; then dkms status; fi
# ตรวจว่าโมดูลที่จำเป็นพร้อมสำหรับ kernel ใหม่ก่อนรีบูต
sudo reboot

ทั้งสอง USN เตือนว่า ABI เปลี่ยน โมดูลภายนอกต้องคอมไพล์และติดตั้งใหม่ ตรวจ DKMS หรือทำตามขั้นตอนของผู้ให้โมดูลก่อนรีบูต ถ้ามี error ต้องแก้ให้เรียบร้อย ระบบจะรับ kernel รุ่นใหม่ผ่านการอัปเดตตามปกติได้เมื่อยังติดตั้ง metapackage ของสายนั้นอยู่ (USN-9002-1, USN-9003-1, การจัดการแพ็กเกจ Ubuntu)

ระหว่างรอให้จำกัดผู้เข้าถึง NFS และปิด Bluetooth ที่ไม่จำเป็น เป็นการลดทางเข้าชั่วคราว ไม่ใช่ workaround ที่ USN รับรองว่าแก้บั๊กได้

ตรวจหลังบูตและเช็กสัญญาณผิดปกติ

uname -r
uname -v
dpkg-query -W -f='${Package}\t${Version}\n' "linux-image-$(uname -r)"
systemctl --failed
systemctl is-active nfs-server.service bluetooth.service
sudo journalctl -k -b --no-pager | grep -Ei 'nfsd|Bluetooth|SCO|io_uring|BUG:|Oops|double.free|use.after.free'

ตรวจว่า service ที่ต้องใช้กลับมาทำงาน ทดสอบ NFS จาก client ที่ได้รับอนุญาตและตรวจโมดูลด้วย อ่านวิธีตรวจรุ่นใน บทความ kernel ที่เข้า KEV ได้ แต่ต้องตรวจสถานะ KEV ของแต่ละ CVE แยกกัน

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

ผมให้ Tegra ที่เปิด NFS server เป็นงานเร่ง ควรนัดอัปเดตและรีบูตในช่วงบำรุงรักษาที่เร็วที่สุด ส่วน Bluetooth ให้จัดคิวตามการเปิดใช้ เครื่องอื่นในสายนี้ยังควรรับแพตช์ เพราะมีบั๊กกลุ่มอื่นรวมอยู่ด้วย

ที่มา: Ubuntu USN-9002-1, Ubuntu USN-9003-1, Ubuntu CVE-2026-93221, Ubuntu CVE-2026-89774, Ubuntu CVE-2026-81010, Ubuntu CVE-2023-20585, Ubuntu CVE-2026-92502, ทะเบียน CVE-2026-81010 ที่มีสถานะ REJECTED, AMD-SB-3016, CISA KEV JSON ตรวจแหล่งข้อมูลเมื่อ 7 พ.ย. 2026 โดย USN ทั้งสองฉบับลงวันที่ 6 พ.ย. 2026 และ KEV ที่ตรวจเป็นฉบับ 4 พ.ย. 2026 เดี๋ยวกลับมาแก้เพิ่มให้ภายหลังครับ