Lỗi ngày tháng trong coreutils dựa trên Rust khiến cập nhật tự động trên Ubuntu 25.10 bị gián đoạn

• Trên Ubuntu 25.10, một lỗi trong lệnh date của coreutils (uutils) được viết bằng Rust đã khiến tính năng cập nhật tự động không hoạt động trên một số hệ thống
• Lỗi này được phát hiện trong gói rust-coreutils phiên bản 0.2.2-0ubuntu2 trở xuống và đã được sửa trong phiên bản 0.2.2-0ubuntu2.1 trở lên
• Sự cố ảnh hưởng đến triển khai đám mây, image container, môi trường cài đặt desktop và server nhưng không ảnh hưởng đến cập nhật thủ công thông qua lệnh apt
• Ubuntu đang thử nghiệm chuyển sang các tiện ích dựa trên Rust (uutils, sudo-rs) trong bản phát hành này, nhằm đánh giá khả năng áp dụng cho phiên bản hỗ trợ dài hạn (LTS) vào năm sau
• Vụ việc này cho thấy sự cần thiết phải kiểm chứng độ ổn định trong quá trình chuyển đổi sang Rust, đồng thời đưa ra hàm ý quan trọng cho chiến lược bảo mật và bảo trì của các bản phân phối trong tương lai

---

Tổng quan về sự cố cập nhật tự động trên Ubuntu 25.10

• Dự án Ubuntu đã chính thức thông báo rằng một lỗi trong lệnh date của uutils dựa trên Rust khiến một số hệ thống không thể tự động kiểm tra cập nhật
  • Các hệ thống bị ảnh hưởng bao gồm môi trường triển khai đám mây, image container, bản cài đặt Ubuntu Desktop và Server
  • Việc kiểm tra cập nhật tự động thất bại tạo ra nguy cơ chậm trễ vá bảo mật và cập nhật phần mềm
• Nhóm bảo mật Ubuntu đã cung cấp hướng dẫn khắc phục (remediation instructions) trong thông báo
  • Người dùng cần cập nhật gói rust-coreutils lên phiên bản 0.2.2-0ubuntu2.1 trở lên để giải quyết vấn đề
  • Lỗi này chỉ ảnh hưởng đến quy trình cập nhật tự động, không ảnh hưởng đến lệnh apt hay các công cụ cập nhật thủ công khác

Nguyên nhân lỗi và phạm vi ảnh hưởng

• Nguyên nhân của sự cố được phân tích là do lệnh date trong coreutils (uutils) được viết lại bằng Rust đã gây lỗi trong quá trình xử lý thời gian hệ thống
  • Điều này khiến trình lập lịch cập nhật tự động không tính toán được ngày tháng chính xác, làm gián đoạn quy trình kiểm tra cập nhật
• Phạm vi ảnh hưởng trải rộng trên mọi hình thức phân phối của Ubuntu 25.10, đặc biệt có khả năng gây gián đoạn vận hành trong môi trường máy chủ tự động hóa và các instance đám mây
• Thông qua sự cố này, Ubuntu đã nhận thức được sự cần thiết phải tăng cường quy trình kiểm chứng độ ổn định của các tiện ích hệ thống dựa trên Rust

Chuyển đổi sang tiện ích dựa trên Rust (dự án “Oxidize”)

• Trong bản phát hành 25.10, Ubuntu đang thúc đẩy dự án “oxidize”, thử nghiệm thay thế coreutils dựa trên C hiện tại bằng uutils dựa trên Rust
  • Đồng thời cũng đưa vào phiên bản Rust của lệnh sudo (sudo-rs) với mục tiêu cải thiện bảo mật và an toàn bộ nhớ
• Đây là giai đoạn thử nghiệm nhằm đánh giá liệu có thể đưa các tiện ích dựa trên Rust vào bản phát hành hỗ trợ dài hạn (LTS) dự kiến vào tháng 4 năm 2026 hay không
• LWN đã từng đề cập đến dự án này vào tháng 3 năm 2025 và phân tích tác động của việc đưa Rust vào đối với độ ổn định cấu trúc của các bản phân phối Linux

Phiên bản đã sửa và hướng dẫn ứng phó

• Theo thông báo bảo mật của Ubuntu, rust-coreutils phiên bản 0.2.2-0ubuntu2 trở xuống có chứa vấn đề
  • Cập nhật lên phiên bản 0.2.2-0ubuntu2.1 trở lên sẽ khắc phục lỗi
• Người dùng có thể thực hiện cập nhật gói thủ công thông qua lệnh apt update && apt upgrade
  • Cho đến khi tính năng cập nhật tự động được khôi phục, nên kiểm tra thủ công định kỳ

Hàm ý và triển vọng sắp tới

• Sự cố lần này được xem là một ví dụ cho thấy sự bất ổn ban đầu trong quá trình chuyển đổi sang Rust
  • Điều này cho thấy việc áp dụng Rust để cải thiện an toàn bộ nhớ và bảo mật cần phải đi song song với kiểm chứng độ ổn định chức năng
• Thử nghiệm của Ubuntu có thể thúc đẩy xu hướng chấp nhận Rust trên toàn bộ hệ sinh thái bản phân phối Linux
• Nếu các tiện ích dựa trên Rust được tích hợp ổn định trong các bản phát hành LTS sắp tới, có thể kỳ vọng nâng cao bảo mật hệ thống và hiệu quả bảo trì

[GN⁺]

Ý kiến trên Hacker News

• Tôi nghĩ việc phát hiện vấn đề sớm theo cách này cũng ổn
  Miễn là xử lý xong trước bản phát hành LTS thì không sao

  • Với tư cách là một người dùng Ubuntu bình thường, tôi không chắc điều này có thực sự ổn hay không
    Nhìn vào biểu đồ tương thích kiểm thử của uutils/coreutils thì vẫn chưa hoàn thiện
    Đặc biệt, date mới chỉ vượt qua 2 bài kiểm thử, bỏ qua 3 bài và lỗi 3 bài
    Tôi không nghĩ trạng thái như vậy có thể xem là sẵn sàng cho production
  • Khi vận hành nhiều hệ thống, có những thành phần được tin cậy đến mức khi xảy ra sự cố người ta thậm chí không nghi ngờ đến nó
    Với từng người dùng riêng lẻ thì lỗi kiểu này có thể nhỏ, nhưng trong môi trường quy mô lớn thì lại chí mạng
    Tôi đã debug cả ngày hôm nay rồi cuối cùng phát hiện hệ thống đang gửi dữ liệu tới một nơi bị cấm rõ ràng
    Kết quả là toàn bộ hệ thống dừng lại, và khi công cụ mà bạn phụ thuộc bị hỏng thì việc quản trị thực sự rất khó khăn
    Nếu đây không phải là Rust mà là một ngôn ngữ khác thì hẳn các lập trình viên đã bị chỉ trích dữ dội
  • Không thể gọi là ổn nếu các tiện ích cốt lõi bị thay bằng một phiên bản viết lại mà không có lý do rõ ràng, rồi nó lại bất ổn đến mức bản phân phối ổn định còn không thể cập nhật tử tế
  • Câu “đó là cách người ta tìm ra issue” nghe đúng kiểu cách phản ứng của Microsoft /s

• Tôi tự hỏi liệu coreutils hiện tại có vấn đề nghiêm trọng đến mức cần phải cải tiến hay không

  • Có lẽ là vì vấn đề giấy phép. Trước đây cũng từng có suy đoán như vậy trong bình luận này
  • Theo một người bảo trì OpenBSD, để đánh giá một ngôn ngữ có phù hợp làm ngôn ngữ hệ thống hay không thì việc triển khai coreutils bằng ngôn ngữ đó là điều bắt buộc
    Bài liên quan: mailing list OpenBSD
  • Cũng có thể là vì các vấn đề bảo mật như CVE-2015-4042
  • Có vẻ vấn đề là ở chỗ nó không được viết bằng Rust. Nhưng tôi thắc mắc vì sao borrow checker lại không bắt được lỗi của date
  • Nếu muốn biết bối cảnh, có thể đọc bài chính thức của Ubuntu: Carefully but purposefully oxidising Ubuntu

• Tôi muốn tìm liên kết bản vá bên phía uutils

  • Có giải thích trong bài viết của LWN
    Lỗi cốt lõi là hỗ trợ date -r <file> chưa được triển khai nhưng Ubuntu vẫn tích hợp phiên bản đó
    Lệnh đã âm thầm bỏ qua tùy chọn -r và không làm gì cả
    Issue liên quan: #8621, PR #8630
  • Báo cáo lỗi của Ubuntu ở đây
  • Tôi nghĩ gốc rễ của vấn đề là chính sự tồn tại của dự án viết lại bằng Rust
  • Đáng tiếc là phần mô tả vấn đề thực tế còn thiếu
    Commit cuối cùng (liên kết) là bản sửa để việc phân tích date khớp với GNU, nhưng đọc các bình luận khác thì có vẻ nguyên nhân không phải ở đó

• Bình luận top thấy khá buồn cười — rằng tên bản Ubuntu tiếp theo sẽ là Grateful Guinea-Pig

• Xem changelog của Ubuntu thì lỗi liên quan đến date -r
  Nếu xem changelog, báo cáo lỗi, issue và PR thì
  date -r lẽ ra phải in ra thời điểm sửa đổi của tệp, nhưng bản Rust lại đơn giản là bỏ qua nó
  Việc thiếu một hành vi cơ bản như vậy thật đáng thất vọng đối với một dự án tự nhận là “thay thế an toàn”

  • Nếu phiên bản này đã vượt qua được bộ kiểm thử chính thức của coreutils, thì ngược lại điều đó có thể có nghĩa là bộ test chưa đầy đủ
  • Nhưng ít nhất cũng không có buffer overflow!

• Thông báo bảo mật của Ubuntu — có vẻ là một trường hợp điển hình

• Tôi thấy Ubuntu 25.10 gần như không dùng được. Đây là lần đầu tiên tôi nói vậy về một bản không phải LTS

  • Tôi muốn biết cụ thể điều gì khiến nó tệ đến mức đó

• Tôi đồng ý với ý rằng “việc viết lại các tiện ích C đã được kiểm chứng hàng chục năm bằng Rust có thể tốt về dài hạn, nhưng các vấn đề ngắn hạn là điều có thể dự đoán được”
  Nhưng tôi vẫn thắc mắc “dài hạn” ở đây thực sự là bao lâu
  Trong bài trình bày ở FOSDEM, một nhà phát triển uutils đã khẳng định hiệu năng tốt hơn bằng benchmark sai, trong khi thực tế là do không hỗ trợ locale
  Liên kết liên quan: bài trình bày FOSDEM, thread 1, thread 2

  • Nhưng các công cụ cốt lõi này rốt cuộc cũng là kết quả của nhiều lần viết lại. Không cần nhìn nhận quá cực đoan
  • Sau khi xử lý locale được bổ sung, còn có bài của Phoronix cho thấy hiệu năng được cải thiện
  • Thay vì kiểu viết lại này, tôi nghĩ nếu dùng cùng lượng công sức để xây dựng một hệ thống kiểm chứng hình thức thì có lẽ sẽ tốt hơn cho bảo mật
  • Cũng có trường hợp các dự án mã nguồn mở bị dùng như công cụ để xây dựng danh tiếng cá nhân
    Vì việc viết mới các tiện ích cốt lõi là một điểm cộng rất lớn trong portfolio

• Tôi tò mò về guided state-space exploration hay các kỹ thuật fuzzing hiện đại
  Nếu đã có sẵn một triển khai cũ, có vẻ fuzzer có thể so sánh hành vi của hai phiên bản để xác minh kiểu white-box

  • Trong trường hợp này, có vẻ property testing sẽ rất phù hợp
    Việc viết proptest cho toàn bộ không gian đầu vào sẽ tốn nhiều công sức, nhưng nếu đối số CLI ổn định thì hoàn toàn khả thi
    Thậm chí có thể tự động tạo dựa trên tài liệu như man page
    Trong Rust thì có thể dùng crate proptest, còn để kiểm tra khác biệt CLI thì có vẻ hợp lý khi gọi bên ngoài bằng Hypothesis của Python