บั๊กวันที่ใน coreutils ที่พัฒนาด้วย Rust ทำให้การอัปเดตอัตโนมัติของ Ubuntu 25.10 หยุดทำงาน

• ใน Ubuntu 25.10 เกิดปัญหา ฟังก์ชันอัปเดตอัตโนมัติของบางระบบไม่ทำงาน เนื่องจากบั๊กในคำสั่ง date ของ coreutils (uutils) ที่เขียนด้วย Rust
• พบบั๊กนี้ใน แพ็กเกจ rust-coreutils เวอร์ชัน 0.2.2-0ubuntu2 หรือต่ำกว่า และได้รับการแก้ไขแล้วใน เวอร์ชัน 0.2.2-0ubuntu2.1 ขึ้นไป
• ปัญหานี้ส่งผลต่อทั้ง การติดตั้งบนคลาวด์, อิมเมจคอนเทนเนอร์, เดสก์ท็อป และเซิร์ฟเวอร์ แต่ ไม่กระทบการอัปเดตแบบแมนนวล ผ่านคำสั่ง apt
• Ubuntu กำลังทดสอบการเปลี่ยนผ่านไปใช้ ยูทิลิตีที่พัฒนาด้วย Rust (uutils, sudo-rs) ในรีลีสนี้ เพื่อประเมินความเป็นไปได้ในการนำไปใช้กับ เวอร์ชันระยะยาว (LTS) ในปีหน้า
• เหตุการณ์ครั้งนี้สะท้อนให้เห็นถึง ความจำเป็นของการตรวจสอบเสถียรภาพในกระบวนการเปลี่ยนผ่านสู่ Rust และให้ข้อสังเกตสำคัญต่อกลยุทธ์ด้านความปลอดภัยและการบำรุงรักษาของดิสทริบิวชันในอนาคต

---

ภาพรวมของปัญหาการอัปเดตอัตโนมัติใน Ubuntu 25.10

• โครงการ Ubuntu ประกาศอย่างเป็นทางการว่ามีปัญหาที่ทำให้บางระบบไม่สามารถตรวจสอบการอัปเดตโดยอัตโนมัติได้ เนื่องจาก บั๊กในคำสั่ง date ของ uutils ที่พัฒนาด้วย Rust
  • ระบบที่ได้รับผลกระทบรวมถึง สภาพแวดล้อมการติดตั้งบนคลาวด์, อิมเมจคอนเทนเนอร์, ชุดติดตั้ง Ubuntu Desktop และ Server
  • เมื่อการตรวจสอบอัปเดตอัตโนมัติล้มเหลว จึงมี ความเสี่ยงที่แพตช์ความปลอดภัยและการอัปเดตซอฟต์แวร์จะล่าช้า
• ทีมความปลอดภัยของ Ubuntu ได้เผยแพร่ประกาศพร้อม วิธีแก้ไข (remediation instructions)
  • ผู้ใช้ต้อง อัปเดตแพ็กเกจ rust-coreutils เป็นเวอร์ชัน 0.2.2-0ubuntu2.1 ขึ้นไป จึงจะแก้ปัญหาได้
  • บั๊กนี้ ส่งผลเฉพาะกับกระบวนการอัปเดตอัตโนมัติเท่านั้น และไม่กระทบคำสั่ง apt หรือเครื่องมืออัปเดตแบบแมนนวลอื่น ๆ

สาเหตุของบั๊กและขอบเขตผลกระทบ

• มีการวิเคราะห์ว่าสาเหตุของปัญหามาจากคำสั่ง date ใน coreutils (uutils) ที่ถูกเขียนใหม่ด้วย Rust ซึ่ง ทำให้เกิดข้อผิดพลาดระหว่างกระบวนการจัดการเวลาของระบบ
  • ส่งผลให้ตัวตั้งเวลาอัปเดตอัตโนมัติ คำนวณวันที่ได้ไม่ถูกต้อง และขั้นตอนตรวจสอบอัปเดตหยุดทำงาน
• ขอบเขตผลกระทบครอบคลุม ทุกรูปแบบการแจกจ่ายของ Ubuntu 25.10 โดยเฉพาะ สภาพแวดล้อมเซิร์ฟเวอร์อัตโนมัติและอินสแตนซ์บนคลาวด์ ที่อาจเสี่ยงต่อการหยุดชะงักของการดำเนินงาน
• Ubuntu รับรู้จากปัญหาครั้งนี้ถึง ความจำเป็นในการเพิ่มความเข้มงวดของกระบวนการตรวจสอบเสถียรภาพของยูทิลิตีระบบที่พัฒนาด้วย Rust

การเปลี่ยนผ่านสู่ยูทิลิตีที่พัฒนาด้วย Rust (โครงการ “Oxidize”)

• Ubuntu กำลังผลักดัน โครงการ “oxidize” ในรีลีส 25.10 โดยทดลองแทนที่ coreutils แบบเดิมที่พัฒนาด้วย C ด้วย uutils ที่พัฒนาด้วย Rust
  • พร้อมกันนั้นยังนำ sudo เวอร์ชัน Rust (sudo-rs) มาใช้ด้วย โดยมีเป้าหมายเพื่อเพิ่มความปลอดภัยและความปลอดภัยของหน่วยความจำ
• โครงการนี้เป็นขั้นตอนทดสอบเพื่อประเมินว่าสามารถรวมยูทิลิตีที่พัฒนาด้วย Rust เข้าไว้ใน รีลีส LTS ที่มีกำหนดในเดือนเมษายน 2026 ได้หรือไม่
• LWN เคยกล่าวถึงโครงการนี้มาแล้วในเดือนมีนาคม 2025 และวิเคราะห์ว่า การนำ Rust มาใช้อาจส่งผลอย่างไรต่อเสถียรภาพเชิงโครงสร้างของดิสทริบิวชันลินุกซ์

เวอร์ชันที่แก้ไขแล้วและแนวทางรับมือ

• ตามประกาศด้านความปลอดภัยของ Ubuntu พบว่าปัญหานี้มีอยู่ใน rust-coreutils เวอร์ชัน 0.2.2-0ubuntu2 หรือต่ำกว่า
  • เมื่ออัปเดตเป็น เวอร์ชัน 0.2.2-0ubuntu2.1 ขึ้นไป บั๊กจะได้รับการแก้ไข
• ผู้ใช้สามารถอัปเดตแพ็กเกจแบบแมนนวลได้ด้วยคำสั่ง apt update && apt upgrade
  • จนกว่าฟังก์ชันอัปเดตอัตโนมัติจะกลับมาทำงานได้ตามปกติ จึงแนะนำให้ ตรวจสอบและอัปเดตด้วยตนเองเป็นประจำ

นัยสำคัญและแนวโน้มในอนาคต

• เหตุการณ์ครั้งนี้ถูกมองว่าเป็นตัวอย่างของ ความไม่เสถียรในระยะแรกของกระบวนการเปลี่ยนผ่านสู่ Rust
  • สะท้อนว่า การนำ Rust มาใช้เพื่อเพิ่มความปลอดภัยของหน่วยความจำและความมั่นคงปลอดภัยนั้น ต้องดำเนินควบคู่ไปกับ การตรวจสอบเสถียรภาพเชิงการทำงาน
• การทดลองของ Ubuntu อาจเร่งให้เกิด กระแสการนำ Rust มาใช้ในดิสทริบิวชันลินุกซ์โดยรวม
• หากยูทิลิตีที่พัฒนาด้วย Rust สามารถถูกรวมเข้ากับรีลีส LTS ในอนาคตได้อย่างเสถียร ก็มีแนวโน้มว่าจะช่วย ยกระดับความปลอดภัยของระบบและประสิทธิภาพในการบำรุงรักษา

[GN⁺]

ความคิดเห็นจาก Hacker News

• ฉันคิดว่าการพบปัญหาได้ตั้งแต่เนิ่นๆแบบนี้ก็โอเค
  ถ้าจัดการให้เรียบร้อยก่อนออก LTS ก็ไม่มีปัญหา

  • ในฐานะผู้ใช้ Ubuntu ทั่วไป ฉันก็ไม่แน่ใจว่านี่โอเคจริงไหม
    ดูจากกราฟความเข้ากันได้ของชุดทดสอบของ uutils/coreutils ก็ยังไม่สมบูรณ์
    โดยเฉพาะ date ผ่านการทดสอบแค่ 2 รายการ ข้ามไป 3 และผิดพลาด 3
    สภาพแบบนี้ฉันไม่คิดว่าจะเรียกว่าพร้อมใช้งานจริงในโปรดักชันได้
  • พอคุณดูแลหลายระบบ ก็จะมีบางองค์ประกอบที่คุณเชื่อใจมากจนเวลามีปัญหาก็แทบไม่สงสัยมันเลย
    บั๊กแบบนี้อาจดูเล็กน้อยสำหรับผู้ใช้รายบุคคล แต่ในสภาพแวดล้อมขนาดใหญ่ถือว่าร้ายแรง
    วันนี้ฉันเสียเวลาทั้งวันไปกับการดีบัก จนสุดท้ายพบว่าระบบกำลังส่งข้อมูลไปยังที่ที่ถูกห้ามไว้อย่างชัดเจน
    ผลคือทั้งระบบหยุดชะงัก และเมื่อเครื่องมือที่พึ่งพาอยู่พัง การจัดการมันยากมากจริงๆ
    ถ้าไม่ใช่ Rust นักพัฒนาคงโดนวิจารณ์อย่างหนักไปแล้ว
  • ถ้ายูทิลิตีแกนหลักถูกแทนที่ด้วยเวอร์ชันเขียนใหม่โดยไม่มีเหตุผลชัดเจน และมันไม่เสถียรจนดิสโทรสายเสถียรอัปเดตไม่ได้ แบบนี้จะบอกว่าโอเคไม่ได้
  • คำพูดว่า “นี่แหละวิธีหา issue” ฟังดูเหมือนเป็นการรับมือแบบMicrosoftเลย /s

• สงสัยว่า coreutils เดิมมีปัญหามากจนต้องปรับปรุงหรือเปล่า

  • น่าจะเป็นไปได้ว่าเพราะปัญหาเรื่องไลเซนส์ ก่อนหน้านี้ก็มีการคาดเดาแบบนั้นในคอมเมนต์นี้
  • จากมุมมองของผู้ดูแล OpenBSD การจะตัดสินว่าภาษาใดเหมาะจะเป็นภาษาระดับระบบหรือไม่ จำเป็นต้องลองทำ coreutils ด้วยภาษานั้น
    บทความที่เกี่ยวข้อง: เมลลิงลิสต์ OpenBSD
  • อาจเป็นเพราะประเด็นด้านความปลอดภัยอย่าง CVE-2015-4042
  • ดูเหมือนว่าปัญหาคือมันไม่ได้เขียนด้วย Rust แต่ก็สงสัยว่าทำไม borrow checker ถึงจับบั๊กใน date ไม่ได้
  • ถ้าอยากรู้เบื้องหลัง ลองดูโพสต์ทางการของ Ubuntu: Carefully but purposefully oxidising Ubuntu

• อยากหาลิงก์แพตช์ใน uutils

  • มีอธิบายไว้ในบทความ LWN
    บั๊กหลักคือยังไม่ได้ implement การรองรับ date -r <file> แต่ Ubuntu ดันรวมเวอร์ชันนั้นเข้าไปแล้ว
    คำสั่งดังกล่าวเมินออปชัน -r แบบเงียบๆ และไม่ทำอะไรเลย
    issue ที่เกี่ยวข้อง: #8621, PR #8630
  • บั๊กรายงานของ Ubuntu อยู่ที่นี่
  • ฉันคิดว่าต้นตอของปัญหาคือการมีอยู่ของโครงการเขียนใหม่ด้วย Rustนั่นเอง
  • น่าเสียดายที่คำอธิบายปัญหาจริงยังไม่ชัดพอ
    คอมมิตล่าสุด(ลิงก์) เป็นการแก้ให้การ parse date ตรงกับ GNU แต่ดูจากคอมเมนต์อื่นๆ สาเหตุอาจไม่ใช่อันนั้น

• คอมเมนต์บนสุดตลกดี — บอกว่า Ubuntu รุ่นถัดไปจะชื่อ Grateful Guinea-Pig

• ดูจาก changelog ของ Ubuntu บั๊กนี้เกี่ยวกับ date -r
  เมื่อดูที่ changelog, บั๊กรายงาน, issue, PR
  date -r ควรจะแสดงเวลาที่ไฟล์ถูกแก้ไข แต่เวอร์ชัน Rust กลับเมินมันไปเฉยๆ
  การขาดพฤติกรรมพื้นฐานแบบนี้น่าผิดหวังสำหรับโครงการที่อ้างตัวว่าเป็น “ตัวแทนที่ปลอดภัย”

  • ถ้าเวอร์ชันนี้ผ่านชุดทดสอบทางการของ coreutils ได้ ก็อาจแปลว่าชุดทดสอบเองไม่สมบูรณ์
  • แต่อย่างน้อยก็ไม่มีbuffer overflow!

• ประกาศความปลอดภัยของ Ubuntu — ดูเหมือนเป็นกรณีตัวอย่างเลย

• รู้สึกว่า Ubuntu 25.10 ใช้งานไม่ได้ถึงขั้นรับไม่ไหว นี่เป็นครั้งแรกที่พูดแบบนี้กับรุ่นที่ไม่ใช่ LTS

  • อยากรู้ว่ามีจุดไหนที่ร้ายแรงขนาดนั้น ช่วยอธิบายให้ชัดเจนได้ไหม

• เห็นด้วยกับคำพูดที่ว่า “การเขียนยูทิลิตี C ที่ผ่านการพิสูจน์มาหลายทศวรรษใหม่ด้วย Rust อาจดีในระยะยาว แต่ปัญหาระยะสั้นนั้นคาดการณ์ได้อยู่แล้ว”
  แต่ก็สงสัยว่า “ระยะยาว” หมายถึงนานแค่ไหน
  ในงาน FOSDEM นักพัฒนา uutils ยังอ้างว่าประสิทธิภาพดีกว่าจากเบนช์มาร์กที่ผิดพลาด ซึ่งจริงๆ แล้วเป็นเพราะยังไม่รองรับ locale นี่ก็เป็นปัญหาเหมือนกัน
  ลิงก์ที่เกี่ยวข้อง: งานนำเสนอ FOSDEM, เธรด1, เธรด2

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

• อยากรู้เกี่ยวกับ guided state-space exploration หรือเทคนิคใหม่ๆ ของ fuzzing
  ถ้ามี implementation เดิมอยู่แล้ว ก็ดูเหมือนว่า fuzzer น่าจะเทียบพฤติกรรมของสองเวอร์ชันเพื่อทำการตรวจสอบแบบ white-boxได้

  • สำหรับกรณีแบบนี้ property testing น่าจะเหมาะมาก
    การเขียน proptest ให้ครอบคลุม input space ทั้งหมดคงต้องใช้แรงเยอะ แต่ถ้าอาร์กิวเมนต์ของ CLI ค่อนข้างเสถียรก็พอเป็นไปได้
    อาจสร้างอัตโนมัติจากเอกสารอย่าง man page ได้ด้วย
    ใน Rust ก็น่าจะใช้ crate proptest ส่วนการตรวจความต่างของ CLI ใช้ Hypothesis ของ Python ผ่านการเรียกภายนอกก็น่าจะดี