Copy Fail – CVE-2026-31431

 (copy.fail)
9 điểm bởi GN⁺ 2026-04-30 | 5 bình luận | Chia sẻ qua WhatsApp
  • Lỗ hổng leo thang đặc quyền và thoát container cho phép giành quyền root trên mọi bản phân phối Linux kể từ năm 2017
  • Khai thác một lỗi logic đơn giản trong mô-đun mã hóa của nhân Linux (authencesn), và có thể thực thi chỉ với một script Python dài 732 byte mà không cần canh thời điểm phức tạp (race condition) hay tinh chỉnh theo từng phiên bản kernel
  • Nguyên lý cốt lõi là can thiệp bộ nhớ đệm trong RAM (page cache) mà Linux tham chiếu khi thực thi tệp, bằng cách nối AF_ALG (socket mã hóa của kernel) với splice() (system call sao chép dữ liệu) để ghi đè 4 byte lên bản sao được cache của một binary setuid
    • Tệp trên đĩa thực tế không bị thay đổi, nên đây là kiểu tấn công ẩn mình không để lại dấu vết trong ảnh đĩa phục vụ pháp chứng
    • Sau khi khởi động lại hoặc khi bộ nhớ được giải phóng, cache sẽ trở về nội dung gốc, nên rất khó phát hiện hậu kiểm bằng các cơ chế kiểm tra toàn vẹn tệp truyền thống
  • Vì page cache được chia sẻ trên toàn bộ host, nên trong môi trường Kubernetes, chỉ cần một pod khai thác lỗ hổng này là có thể chiếm quyền node host và thoát container để xâm phạm cả container của tenant khác
  • Đã được xác minh trực tiếp trên Ubuntu 24.04, Amazon Linux 2023, RHEL 10.1 và SUSE 16; chỉ cần tài khoản người dùng cục bộ không đặc quyền là có thể khai thác ngay mà không cần truy cập mạng hay tính năng debug kernel
  • Các lỗ hổng leo thang đặc quyền trên Linux (LPE) trước đây thường chỉ có tỷ lệ thành công 30~80% mỗi lần thử và chỉ hoạt động trong một phạm vi kernel nhất định, nhưng Copy Fail nhắm tới mọi bản phân phối trong 9 năm (2017~2026) với tỷ lệ thành công 100% chỉ trong một lần thử
  • Không giống các lỗ hổng cùng họ can thiệp page cache như Dirty Pipe (lạm dụng cờ pipe buffer) hay Dirty Cow (cần cạnh tranh thời gian), nó đơn giản và mạnh hơn nhiều nhờ không có race condition, không cần offset riêng theo từng bản phân phối, và không cần biên dịch lại
  • Các mục tiêu cấp bách nhất: host Linux đa tenant, cụm Kubernetes/container, CI runner (GitHub Actions self-hosted, GitLab Runner, v.v.), SaaS đám mây chạy mã người dùng — mọi môi trường nơi mã không đáng tin cậy chạy trên một kernel dùng chung
  • Biện pháp ưu tiên cao nhất là vá kernel (mainline commit a664bf3d603d) — hoàn tác tối ưu hóa in-place của mô-đun mã hóa được đưa vào năm 2017, để các trang page cache không còn là đích ghi của phép toán mã hóa
  • Trước khi vá, có thể tạm thời vô hiệu hóa mô-đun algif_aead, và việc này không ảnh hưởng đến các chức năng mã hóa phổ biến như dm-crypt/LUKS, kTLS, IPsec hay SSH
  • Với các môi trường workload không đáng tin cậy như container, sandbox, CI runner, khuyến nghị chặn việc tạo socket AF_ALG bằng seccomp bất kể đã vá hay chưa
  • Taeyang Lee của Xint đã đưa ra nhận định ban đầu rằng cấu trúc splice() chuyển các trang page cache sang hệ con mã hóa là một lớp lỗi chưa từng được khai phá, và Xint Code đã tự động quét hệ con crypto/ của kernel trong khoảng 1 giờ để phát hiện ra đây là một trường hợp phát hiện lỗ hổng có hỗ trợ AI

Bài viết liên quan

5 bình luận

 
popopo 2026-05-04

Có vẻ Rocky Linux vẫn chưa có bản vá.

RHEL

AlmaLinux

Rocky Linux

Tôi đang dùng Rocky Linux, nếu không thể khởi động lại thì việc chặn bằng bpftool từ https://github.com/wgnet/wg.copyfail.patch là có hiệu lực.
 
popopo 2026-05-04

https://kb.ciq.com/article/rocky-linux/rl-cve-2026-31431-mitigation

Có bản vá, nhưng... chỉ được cung cấp qua kho của dịch vụ thuê bao. Bản CE không được vá. (đã kiểm tra 9.7, 10.1)
 
popopo 29 ngày trước

Bản vá đã ra vào ngày 2026-05-05.

Vào ngày 2026-05-10 có thêm một tùy chọn bảo mật mới.
https://forums.rockylinux.org/t/…

sudo dnf --enablerepo=security update

Có vẻ như nếu thêm kho lưu trữ bảo mật, thì có thể áp dụng các biện pháp bảo mật riêng, tách biệt với việc phản ánh nguồn RHEL.
 
sukso96100 2026-05-02

Những ai đang dùng Ubuntu thì đã có hướng dẫn cách xử lý, mọi người có thể tham khảo.

https://discourse.ubuntu.com/t/…
 
GN⁺ 2026-04-30
Ý kiến trên Hacker News

  • Với góc nhìn của người làm việc với mã crypto của kernel Linux, các vụ khai thác AF_ALG bùng lên định kỳ thực sự rất khó chịu
    AF_ALG đã được đưa vào kernel từ lâu mà không được rà soát đầy đủ, cấu trúc lại quá phức tạp, đồng thời mở ra một bề mặt tấn công khổng lồ cho các chương trình userspace không đặc quyền
    Hơn nữa nó gần như không cần thiết. userspace vốn đã có sẵn mã mật mã riêng, còn mã crypto của kernel ban đầu là để phục vụ các trường hợp dùng nội bộ trong kernel như dm-crypt
    authencesn trong vụ khai thác lần này thực chất cũng chỉ là chi tiết triển khai nội bộ của IPsec, nên việc phơi bày nó thành API mã hóa/giải mã userspace dùng chung ngay từ đầu đã là sai lầm
    Nếu bạn quản lý cấu hình kernel Linux, tôi rất khuyến nghị tắt toàn bộ các tùy chọn CONFIG_CRYPTO_USER_API_*
    Chỉ cần làm vậy thôi thì không chỉ lỗi lần này mà còn phần lớn lỗi AF_ALG trong quá khứ và tương lai đã không thể bị khai thác
    Nếu có chương trình userspace nào bị hỏng thì đúng hơn là nên hỗ trợ chuyển chúng sang mã crypto userspace, và thực tế cũng đã có trường hợp chuyển như vậy rồi
    Ngay từ đầu AF_ALG vốn cũng chẳng có mấy ứng dụng ngoài phục vụ khai thác
    Trước đây kiểu API userspace như vậy có thể còn tạm chấp nhận được, nhưng trong thời đại có syzbot và phát hiện lỗi có hỗ trợ bởi LLM thì giờ khó mà trụ nổi nữa

    • Tôi không biết AF_ALG là gì nên đã tra thử và thấy https://www.chronox.de/libkcapi/html/ch01s02.html, trong đó có nêu vài lý do tồn tại của nó
      Các lập luận được đưa ra gồm: cho phép userspace dùng được bộ tăng tốc phần cứng chỉ truy cập được ở chế độ kernel, có thể chuyển khóa vào kernel thay vì giữ lâu trong bộ nhớ ứng dụng, và trong môi trường thiếu RAM như embedded thì có thể giảm footprint so với thư viện crypto userspace
      Tôi không chắc như vậy đã là biện minh đủ mạnh hay chưa, nhưng ít nhất thì đúng là có lý do tồn tại
    • Tôi khá tò mò nó đã vào kernel bằng cách nào
      Linus vốn nổi tiếng là khá kén chọn về việc đưa gì vào kernel, nên bối cảnh đằng sau API này hẳn sẽ là một câu chuyện thú vị
    • AF_ALG là giao diện socket của Linux, phơi bày API crypto của kernel qua file descriptor
      Nó cho phép xử lý băm và mã hóa bằng các lệnh gọi read(2)/write(2) thông thường
    • Điều tôi tò mò nhất là phần mềm nào sẽ hỏng nếu tắt tùy chọn kernel này

  • Có vẻ đã có chút lộn xộn trong quá trình công bố
    Các vendor dường như không xem lỗ hổng này là đặc biệt nghiêm trọng, nên nhiều bản phân phối vẫn đang ở trạng thái chưa vá
    https://access.redhat.com/security/cve/cve-2026-31431 ghi là "Moderate severity", "Fix deferred", và các trang theo dõi của Debian, Ubuntu, SUSE cũng trông tương tự

    • Từ thời điểm bản vá được đưa vào kernel thì trong thực tế, giới tấn công hoặc người theo dõi đã biết về nó từ vài tuần trước rồi
      Nhưng upstream đã không truyền đạt rõ ràng rằng đây là một lỗ hổng, và Linus cùng Greg vốn cũng không quá coi trọng khái niệm phân loại như vậy trong kernel
    • Có lẽ các bản phân phối xem đây là rủi ro trung bình vì nó không phải thực thi mã từ xa mà cần truy cập cục bộ
      Dù vậy, vì có thể leo thang đặc quyền lên root từ local nên nhìn chung vẫn nên được xem là ưu tiên cao
      https://ubuntu.com/security/cves/about#priority
    • RedHat hiện đã đổi thành Important severity và Affected
    • Nếu xem theo chính hướng dẫn của Ubuntu thì cái này có vẻ nên được xếp high priority, nhưng nhãn thực tế lại là medium nên trông không nhất quán

  • Hơi đáng tiếc là bài gốc không ghi ngay phiên bản kernel nào bị ảnh hưởng và phiên bản nào đã vá
    Đặc biệt vì đây là module builtin nên cũng không thể dễ dàng gỡ bằng rmmod
    Trong lúc tìm xem kernel 6.19.14 của Fedora 44 có dễ tổn thương không, tôi đã tìm thấy bài trên mailing list linux-cve-announce https://lore.kernel.org/linux-cve-announce/2026042214-CVE-2026-31431-3d65@gregkh/T/#u
    Ở đó ghi rằng lỗi đã được sửa bằng commit tương ứng trong 6.18.22, 6.19.12, 7.0, nên khá hữu ích để tham khảo

  • Nếu muốn kiểm tra xem biện pháp giảm thiểu được khuyến nghị là chặn module kernel algif_aead bằng cấu hình modprobe đã được áp dụng hay chưa, thì không cần phải chạy nguyên một đoạn shell bị làm rối
    Chỉ với vài dòng Python như dưới đây là có thể kiểm tra dễ đọc xem module có thực sự được nạp hay không
    python3 -c 'import socket; s = socket.socket(socket.AF_ALG, socket.SOCK_SEQPACKET, 0); s.bind(("aead","authencesn(hmac(sha256),cbc(aes))")); print("algif_aead probably successfully loaded, mitigation not effective; remove again with: rmmod algif_aead")'
    Nếu biện pháp giảm thiểu đã áp dụng đúng thì modprobe algif_aead cũng phải thất bại với lỗi

  • Chắc là không ai chạy AI agent hoàn toàn tự trị trên một hệ điều hành bị ảnh hưởng với quyền người dùng thường đâu nhỉ
    Nếu kết hợp với prompt injection zero-day thì có thể thành thảm họa thật sự

    • Agent của tôi đã chạy bằng root rồi nên tôi không gặp vấn đề này
    • May là chúng ta chưa biến việc cài bằng curl | sh thành chuẩn mặc định của ngành

  • LPE nghĩa là local privilege escalation
    Mảng bảo mật có quá nhiều chữ viết tắt, và dù có thể đoán theo ngữ cảnh nhưng ban đầu vẫn nên viết đầy đủ ra

    • LPE là chữ viết tắt khá phổ biến trong cộng đồng bảo mật, nên việc không viết đầy đủ ra ngay từ đầu cũng không hẳn là quá tệ
      Tuy vậy, nếu bài viết hướng đến độc giả rộng hơn thì tôi đồng ý là nên định nghĩa rõ ràng
      Hơn nữa, cả bài này trông cũng giống nội dung do AI tạo ra
    • Khi viết cho độc giả đại chúng thì nguyên tắc cơ bản là phải viết đầy đủ chữ viết tắt trước, nhưng LLM thường không theo sát kiểu hướng dẫn đó

  • Cái này hơi buồn cười
    Trang đó ghi là chạy trên RHEL 14.3, nhưng phiên bản như vậy không hề tồn tại
    RHEL hiện đang ở 10.x, nên tôi còn tưởng họ đi TARDIS nữa chứ

    • 14.3 có vẻ không phải phiên bản RHEL mà xuất phát từ cách ghi phiên bản GCC của Red Hat
      Đôi khi nó hiện như gcc (GCC) 14.3.1 20250617 (Red Hat 14.3.1-2), và trong các ví dụ bên dưới cũng thấy dấu vết tương tự
      https://github.com/anthropics/claude-code/issues/40741
      https://docs.oracle.com/en/database/oracle/tuxedo/22/otxig/software-requirements-red-hat-enterprise-linux-10-64-bit.html
    • Trên cùng dòng còn có 6.12.0-124.45.1.el10_1, mà cái đó rõ ràng là kernel của RHEL 10
      Những lỗi gõ kiểu này ngược lại lại rất giống do người tạo ra
      Các chuỗi số dài copy-paste thì chính xác, còn mấy con số đơn giản lại gõ tay rồi sai
    • Xin lỗi, nhưng chỗ đó sẽ được sửa
      Đã có giai đoạn thu thập thông tin khá gấp để giải thích vấn đề này, và đúng vậy, cũng có yếu tố marketing
      Vì thế có lẫn vào vài lỗi nhỏ, và tôi xem việc bạn chỉ ra là rất đáng cảm ơn
    • Đúng vậy, ngay khoảnh khắc tôi thấy dòng "Bản phân phối đã tự xác minh: RHEL 14.3" thì ít nhất trang phát hành đã cho cảm giác như AI slop
      https://access.redhat.com/articles/red-hat-enterprise-linux-release-dates
      Đến lúc thấy cả dòng "Talk to our security experts" ở cuối trang, tôi còn thấy như thể chuyên gia bảo mật đó có khi tên là Claude

  • Trên RHEL 9/10, algif_aead không phải module mà là builtin nên không thể unload
    Vì vậy tôi đã tìm một cách thay thế là chặn AF_ALG bằng systemd, nhưng cách này cần drop-in cho từng dịch vụ bị phơi bày
    Cũng có sẵn playbook Ansible xử lý những chỗ quan trọng như sshd và user@
    https://gist.github.com/m3nu/c19269ef4fd6fa53b03eb388f77464da

    • Trên RHEL 9/10 cũng có thể dùng initcall_blacklist=algif_aead_init làm tham số boot kernel rồi khởi động lại
      Làm vậy thì khai thác không còn hoạt động nữa
    • Tôi cũng nghĩ theo hướng tương tự, nhưng việc chặn theo từng dịch vụ có cảm giác như đập chuột chũi
      Tôi lo về các đường thực thi khác như cronjob, slurmjob, và sẽ tốt hơn nếu có cách để mọi tiến trình đều kế thừa thiết lập này ở cấp systemd thay vì phải thêm cho từng dịch vụ riêng lẻ

  • Có vẻ khai thác này hoạt động bằng cách thay thế binary SUID để khiến nó chạy với PID 0
    Nhưng trong khi trang đó lại tuyên bố có thể thoát khỏi Kubernetes / container clusters và CI runners & build farms, thì tôi không thấy phần giải thích nào thực sự chứng minh việc thoát container hay đặc biệt là thoát user namespace
    Tôi đã thử trong rootless Podman và đúng như dự đoán là không thể thoát container
    Ngoài ra họ còn nói có thể "biến mọi bản phân phối Linux phát hành từ 2017 thành root", nhưng thực tế chỉ thử trên bốn bản và trên Alpine thì không chạy được

    • Phía trang đó cũng nói giải thích chi tiết sẽ sớm được đăng, nên có lẽ các bước bổ sung hoặc chỉnh sửa sẽ xuất hiện trong phần 2
      Họ đã nhá hàng "Next: "From Pod to Host," how Copy Fail escapes every major cloud Kubernetes platform."
    • Lỗ hổng này cho phép ghi đè các byte bộ nhớ của file có thể đọc được, nên hoàn toàn có thể hình dung ra khả năng thoát trong nhiều môi trường khác nhau
    • Tuyên bố mọi bản phân phối từ sau 2017 có vẻ dựa trên việc lỗ hổng này được đưa vào từ một commit nửa sau năm 2017
      https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=72548b093ee3
      Tuy vậy, khả năng khai thác thực tế sẽ khác nhau tùy đó là bản phát hành major mới hay kernel bảo trì của nhánh cũ
    • Bài này tự làm giảm độ tin cậy của chính nó khá nhiều
      Dù vậy, khi tôi trực tiếp chạy PoC trên một instance 24.04 thì lỗ hổng có vẻ là thật, và đủ lớn để đáng lo
      Chỉ là số lượng bản phân phối bị ảnh hưởng có vẻ ít hơn nhiều so với tuyên bố, và còn khá xa mới đến mức mọi bản phân phối từ sau 2017
      Ví dụ, nếu tôi hiểu đúng thì Ubuntu ngay cả 16.04 EOL cũng bị ảnh hưởng chút ít, còn tác động chính thực tế có vẻ nằm ở các kernel vendor mới được phân phối gần đây như linux-gcp, linux-oracle-6.7, tức nhánh 6.17
    • Ngay cả trong container rootless, nếu vẫn leo lên được UID 0 thực sự thì sau đó việc thoát ra là khả thi
      Dù vậy sẽ cần thêm bước khác, và Alpine có thể cũng dính lỗ hổng gốc nhưng chỉ là script cần chỉnh lại mà thôi
      Suy cho cùng đây không phải exploit đa dụng hoàn chỉnh mà là PoC

  • Bản thân trang này có vẻ hơi vibecoded và mang mùi quảng cáo, nhưng lỗ hổng thì là thật và mức độ nguy hiểm cũng có vẻ cao
    Giờ thì cũng hiểu vì sao hôm nay có một bản cập nhật bảo mật lớn, nên tôi sẽ tăng ưu tiên cập nhật lên

    • Đây đúng là một kiểu quảng cáo khá lộ liễu, nhưng cá nhân tôi thấy không hẳn là quảng cáo tệ
      Họ vừa đóng góp có ý nghĩa cho hệ sinh thái OSS bằng cách tìm ra lỗi thật và vá nó, đồng thời cũng bán công cụ bảo mật của mình
    • Có vẻ những người này dù không quảng cáo thì cũng đã thừa việc để làm rồi
      Chỉ là giờ còn ai tự tay làm từng trang web nữa đâu, nhất là nếu còn là kernel developer thì lại càng hợp lý hơn