Dirty Frag: lỗ hổng LPE Linux phổ quát (leo thang đặc quyền cục bộ)

• Dirty Frag là lỗ hổng leo thang đặc quyền cục bộ phổ quát cho phép giành quyền root trên hầu hết các bản phân phối Linux lớn, và do lịch công bố có trách nhiệm cùng lệnh cấm công bố bị phá vỡ nên hiện vẫn chưa có bản vá và chưa có CVE
• Đây là phần mở rộng của cùng lớp lỗi với Dirty Pipe và Copy Fail; vì là lỗi logic mang tính quyết định, nên không cần race condition và tỷ lệ thành công rất cao
• Vòng đời hiệu lực của lỗ hổng vào khoảng 9 năm, đã được kiểm thử trên các bản phân phối lớn như Ubuntu, RHEL, Fedora, openSUSE
• Ngay cả trên các hệ thống đã áp dụng biện pháp giảm thiểu Copy Fail trước đây (blacklist algif_aead), chúng vẫn dễ bị ảnh hưởng bởi Dirty Frag
• Biện pháp giảm thiểu tạm thời được khuyến nghị là gỡ các mô-đun esp4, esp6, rxrpc gây ra lỗ hổng cho đến khi bản vá từ bản phân phối được phát hành

---

Tổng quan

• Đây là lớp lỗi làm nhiễm bẩn thành viên frag của cấu trúc sk_buff, là phần mở rộng của cùng lớp lỗi mà Dirty Pipe và Copy Fail cùng thuộc về
• Có thể xâu chuỗi lỗ hổng xfrm-ESP Page-Cache Write và RxRPC Page-Cache Write để giành quyền root trên các bản phân phối Linux lớn
• Là lỗi logic mang tính quyết định nên không phụ thuộc vào timing window, không cần race condition
• Ngay cả khi khai thác thất bại thì kernel panic cũng không xảy ra, và tỷ lệ thành công rất cao

Lý do xâu chuỗi hai lỗ hổng

• xfrm-ESP Page-Cache Write cung cấp primitive STORE 4 byte tùy ý mạnh, tương tự Copy Fail, và có trong hầu hết các bản phân phối, nhưng yêu cầu quyền tạo namespace
• Trên Ubuntu, trong một số môi trường chính sách AppArmor chặn việc tạo user namespace không đặc quyền, nên trong môi trường đó không thể kích hoạt xfrm-ESP Page-Cache Write
• RxRPC Page-Cache Write không cần quyền tạo namespace, nhưng bản thân mô-đun rxrpc.ko lại không có trong phần lớn các bản phân phối
  • Tuy vậy, trên Ubuntu mô-đun rxrpc.ko được nạp mặc định
• Khi xâu chuỗi hai lỗ hổng, có thể bù đắp điểm mù của nhau, nhờ đó giành quyền root trên mọi bản phân phối lớn

Quan hệ với Copy Fail

• Copy Fail là động lực khởi đầu nghiên cứu này
• xfrm-ESP Page-Cache Write dùng chung sink với Copy Fail, nhưng có thể được kích hoạt bất kể mô-đun algif_aead có sẵn hay không
• Ngay cả trên các hệ thống đã áp dụng biện pháp giảm thiểu Copy Fail được công bố (blacklist algif_aead), chúng vẫn dễ bị Dirty Frag ảnh hưởng

Phạm vi ảnh hưởng

• xfrm-ESP Page-Cache Write: từ commit cac2661c53f3 (2017-01-17) đến upstream hiện tại
• RxRPC Page-Cache Write: từ commit 2dc334f1a63a (2023-06) đến upstream hiện tại
• Vòng đời hiệu lực của lỗ hổng vào khoảng 9 năm
• Các phiên bản bản phân phối đã kiểm thử:
  • Ubuntu 24.04.4: 6.17.0-23-generic
  • RHEL 10.1: 6.12.0-124.49.1.el10_1.x86_64
  • openSUSE Tumbleweed: 7.0.2-1-default
  • CentOS Stream 10: 6.12.0-224.el10.x86_64
  • AlmaLinux 10: 6.12.0-124.52.3.el10_1.x86_64
  • Fedora 44: 6.19.14-300.fc44.x86_64

Biện pháp giảm thiểu

• Do lịch công bố có trách nhiệm và lệnh cấm công bố bị phá vỡ, chưa có bản vá cho bất kỳ bản phân phối nào
• Biện pháp giảm thiểu tạm thời là cung cấp lệnh gỡ các mô-đun gây ra lỗ hổng:

  sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"  
  

  • Đăng ký blacklist các mô-đun esp4, esp6, rxrpc trong /etc/modprobe.d/dirtyfrag.conf và gỡ chúng
• Sau khi từng bản phân phối backport bản vá, cần áp dụng bản cập nhật tương ứng

Quá trình công bố

• Sau khi trao đổi với các maintainer của [e-mail], tài liệu Dirty Frag được công bố theo yêu cầu của họ
• Lệnh cấm công bố đã bị phá vỡ bởi yếu tố bên ngoài, và hiện chưa có bản vá hay CVE
• PoC đã được công bố sau khi trao đổi với linux-distros nhằm cung cấp thông tin chính xác, và không được sử dụng trên các hệ thống không được phép

[xguru]

Từ Copy Fail đến cả Dirty Frag nữa, có vẻ các lỗ hổng đang ồ ạt xuất hiện.

Cả hai đều là leo thang đặc quyền cục bộ (LPE), nên nếu "mã của người khác chạy trên máy chủ của tôi" thì nhất định phải vá ngay. Host đa tenant, cụm k8s, máy chủ CI, các SaaS chạy mã người dùng.

Ngay cả chỉ là web server thì cũng có thể kết hợp với web RCE, nên khuyến nghị vá.

[GN⁺]

Ý kiến trên Hacker News

• Điều này có nguyên nhân gốc rễ và cách khai thác rất giống với Copy Fail
  Tôi cho rằng đây là một ví dụ cho thấy rất rõ thứ dễ bị mất đi khi giao quá nhiều việc cho LLM, tức là khả năng khám phá. Khi nghiên cứu lỗ hổng bằng AI, tôi có cảm giác tính sáng tạo bị hạn chế khá nhiều. Trong luồng làm việc mà cứ hỏi là có ngay câu trả lời, bạn sẽ không nhìn thấy những gì nằm xung quanh. Nó giống như thần đèn chỉ đưa đúng thứ bạn yêu cầu, không hơn
  Nhà nghiên cứu phát hiện ra Copy Fail đã dựa khá nhiều vào AI sau khi thấy điều gì đó đáng ngờ, nhưng nếu tự mình lục nhiều mã hơn thì có lẽ đã có nhiều cơ hội phát hiện ra những lỗi song sinh kiểu này. Đồng thời, nếu dùng prompt bớt mang tính chỉ thị hơn một chút, có lẽ các LLM hiện đại cũng đã tìm ra các lỗi này. Đây là một trường hợp hiệp lực âm khá đặc biệt, khi làm cùng nhau mà hiệu quả lại giảm

  • Nếu tôi không đọc nhầm thì không phải là tương tự mà là cùng một nguyên nhân gốc rễ. Đó là vấn đề upper 32 bit của Extended ESN trong IPsec == module/chế độ mã hóa authencesn
    Trong copy.fail, thứ được sửa lại là một thứ khác, và mọi người đã vội đổ lỗi cho AF_ALG
    [Chỉnh sửa: đúng vậy, đây là cùng vấn đề authencesn. Trong mã https://github.com/V4bel/dirtyfrag/blob/892d9a31d391b7f0fccb... thì authencesn chỉ xuất hiện trong chú thích, nhưng vẫn là cùng một vấn đề]
    [Chỉnh sửa 2: vấn đề RxRPC là riêng biệt, ở đây tôi đang nói về phía ESP]
  • Có thể dùng prompt tiếp theo kiểu “hãy tìm những lỗi cùng loại tương tự”. Sau khi một trường hợp thực tế đã được tổng kết, việc tìm lỗi tương tự không còn quá khó
    Tôi hiểu ý về tính sáng tạo. Với bất kỳ công cụ nào, AI đều có thể thu hẹp tầm nhìn. Thật khó để chỉ dùng nó như công cụ hỗ trợ mà không giao hẳn toàn bộ workflow cho nó
  • Tôi không hiểu. Ngay từ đầu chính LLM đã phát hiện ra các lỗi này. Thế mà lại có vẻ đang nói việc phát hiện đó là tín hiệu cho thấy LLM không tốt trong việc tìm lỗ hổng
  • Tôi tò mò không biết đây là nhận định có cơ sở hay chỉ là nói hứng
  • Với một lỗ hổng gốc tương tự cái AI đã phát hiện, nhưng không hoàn toàn giống, thì rất khó rút ra bài học rằng AI không thể khám phá
    Trừ trường hợp hai lỗ hổng được công bố cùng nhau như một, tôi muốn biết trong tình huống phản thực tế nào thì có thể xem là “đã khám phá đủ tốt”

• “Vì embargo đã bị phá vỡ nên hiện chưa có bản vá hay CVE nào cho các lỗ hổng này”
  Liên kết: https://github.com/V4bel/dirtyfrag
  Phân tích chi tiết: https://github.com/V4bel/dirtyfrag/blob/master/assets/write-...
  Phần quan trọng là: “Copy Fail là động lực khiến nghiên cứu này bắt đầu. Cụ thể, xfrm-ESP Page-Cache Write trong chuỗi lỗ hổng Dirty Frag chia sẻ cùng sink với Copy Fail. Tuy nhiên, nó được kích hoạt bất kể module algif_aead có khả dụng hay không. Nói cách khác, ngay cả trên các hệ thống đã áp dụng biện pháp giảm thiểu công khai cho Copy Fail là đưa algif_aead vào blacklist, Linux vẫn còn dễ bị Dirty Frag”
  Biện pháp giảm thiểu được đề xuất như sau, nhưng tôi chưa tự kiểm tra hay xác minh: “Do lịch trình công bố có trách nhiệm và embargo đã bị phá vỡ, chưa có bản vá cho bất kỳ bản phân phối nào. Hãy gỡ các module gây ra lỗ hổng bằng lệnh dưới đây”
  sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"
  Trong phần thảo luận về biện pháp giảm thiểu, có người nói cần khởi động lại, hoặc nếu máy đã bị khai thác thì sau lệnh trên phải chạy thêm: sudo echo 3 > /prox/sys/vm/drop_caches

  • Trong sudo echo 3 > /prox/sys/vm/drop_caches, sudo không có tác dụng. Vì sudo chỉ chạy echo, còn thao tác ghi thực tế thì không
    Và nếu máy đã bị khai thác thì làm vậy cũng đã quá muộn. Bất cứ thứ gì trên đĩa cũng có thể đã bị hỏng, nên phải tạo lại toàn bộ image đĩa
  • Không thể dùng sudo echo với chuyển hướng như vậy trong shell không chạy sudo
    echo 3 | sudo tee /proc/sys/vm/drop_caches
    hoặc
    sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
    Và tôi cũng đã sửa lỗi gõ nhầm /proc
  • Tham khảo thêm, echo 1 > ... cũng đủ để giảm thiểu. Không cần xóa hết, chỉ cần xóa page cache bằng 1 là đủ
    Tôi đã test cục bộ trên Ubuntu 26.04: chạy exploit để lấy quyền root, thiết lập biện pháp giảm thiểu, rồi chạy lại su không có đối số thì ngay lập tức vào root không cần mật khẩu. Sau đó xóa page cache thì su lại yêu cầu mật khẩu

• Cần có một cách dễ dàng để bảo đảm chỉ những kernel module nằm trong whitelist mới được nạp. Tôi mệt mỏi vì cứ phải tiếp tục blacklist các module mình chẳng cần dùng

• Tôi hỏi lại lần nữa, vì sao trong copy.fail algif_aead lại bị đổ mọi tội? Thứ ngu ngốc là authencesn cơ mà
  authencesn chưa được sửa, và giờ đây kết quả là như vậy. Hóa ra có thể truy cập cùng một, hoặc có lẽ là cùng kiểu ghi ngoài phạm vi đó thông qua một socket mạng bình thường
  Lẽ ra tôi nên nghĩ ra điều này, nhưng đã không làm được
  [Chỉnh sửa: tôi đang nói về vấn đề qua ESP. Vấn đề RxRPC, theo hiểu biết của tôi, là hoàn toàn riêng biệt]

• Nếu chuyện này thực sự hoạt động trên toàn bộ các bản phân phối lớn, tôi lại một lần nữa ngạc nhiên về mức độ vô trách nhiệm của các maintainer. Tại sao các tính năng kernel tùy chọn có lẽ chỉ hữu ích cho dưới 0,1% người dùng lại được bật sẵn như vậy?
  Nó gợi nhớ đến thói quen của các bản phân phối Linux năm 1999, khi cài mặc định hàng chục dịch vụ mạng lộ ra Internet. Nhưng bây giờ đâu còn là năm 1999 nữa

  • Việc maintainer của bản phân phối quyết định blacklist một số tính năng nào đó vì cho rằng “bạn sẽ không cần đến nó đâu (YAGNI)” là một yêu cầu khá lớn. Vì không ai biết người dùng đang dùng gì. Người dùng luôn có thể quay lại và điều chỉnh bản build theo đúng nhu cầu thực tế của mình
    Tôi nhớ thời Linux xưa, khi chạy make menuconfig để chọn chính xác những tính năng mình muốn trong kernel. Thành thật mà nói, tôi không muốn quay lại thời đó
    Tuy vậy, mục tiêu dễ cải thiện ở đây là RHEL. RHEL biên dịch nhiều thứ thẳng vào kernel thay vì để chúng thành module có thể nạp, nên các biện pháp giảm thiểu kiểu copy fail là bất khả thi. Có lẽ có thể giảm bớt điều đó đi một chút
  • Không có cách nào vừa vô hiệu các thành phần mà người dùng có thể không dùng, vừa không làm cho hệ thống trở nên cực kỳ khó sử dụng. Ngay cả tôi, đã dùng cái OS ngớ ngẩn này 25 năm rồi, mà vẫn không có cách nào biết phải bật tắt cái gì để làm một việc nào đó
    Các maintainer bản phân phối Linux là những maintainer phần mềm có trách nhiệm nhất trên hành tinh. Thực hành bảo mật của họ tốt hơn rất nhiều so với các package manager ngôn ngữ lập trình ngớ ngẩn, họ duy trì danh sách gói được tuyển chọn, xem xét thay đổi, vá lỗi, xử lý các vấn đề đóng gói phức tạp, backport các bản sửa, dùng phát hành theo giai đoạn, phân phối tệp qua các mirror trên toàn cầu, và xác minh mật mã cho mọi tệp. Chưa kể tất cả những việc đó đều được làm miễn phí
  • Không phải là bật sẵn theo mặc định. Đây là các module tùy chọn được nạp khi cần. Toàn bộ kiến trúc của kernel được thiết kế để những chức năng cốt lõi người dùng cần thì được biên dịch sẵn vào kernel, còn gần như mọi thứ khác sẽ được cung cấp dưới dạng module nạp khi cần
  • Ở nhiều khía cạnh, máy tính không phải di động vẫn đang mắc kẹt ở năm 1999. Android an toàn hơn nhiều so với các hệ Linux khác vì nó trẻ hơn rất nhiều và đã có cơ hội tích hợp kiểm soát truy cập bắt buộc trên toàn bộ stack
  • Để khai thác được chuyện này, bạn phải có quyền truy cập trực tiếp vào máy tính. Đó có thể là một thiết bị USB độc hại, một cuộc tấn công chuỗi cung ứng, hoặc khai thác phần mềm đã biết mà người dùng sẵn sàng hay tự động cài đặt. Hơn nữa, về thực chất bạn còn phải có khả năng chạy gần như lệnh terminal tùy ý, mà trong môi trường cô lập của phần mềm đó thì đã là một mức xâm phạm cực lớn rồi
    Nếu kẻ tấn công đã làm được hết chừng đó, thì tình hình vốn đã tệ. Việc leo thang lên root bằng cách này ở thời điểm đó chỉ là mối lo nhỏ hơn mà thôi
    Như người khác đã đăng bên dưới: https://xkcd.com/1200/
    Trước khi hoảng sợ, mọi người nên hiểu lỗ hổng này thực sự là gì

• Sau bao nhiêu năm, cuối cùng chúng ta cũng đạt đến trạng thái “đủ nhiều con mắt thì mọi lỗi đều nông”, mà thấy cũng không ổn lắm. Từ giờ có phải cập nhật kernel vài lần mỗi tuần không?

  • Ý bạn là sẽ có ai đó đột nhập vào nhà bạn, bằng cách nào đó lấy được thông tin xác thực mặc định, rồi còn giành được quyền root nữa sao?

• Tôi tò mò không biết embargo đã bị phá như thế nào. Là bị rò rỉ hay có bên thứ ba tự tìm ra độc lập?

  • Ngay từ đầu embargo đã không tồn tại, và cũng không thể tồn tại
    Linux là mã nguồn mở, nên mọi bản vá sửa lỗi bảo mật đều lập tức hiển thị cho tất cả mọi người. Với cách phát triển kernel hiện nay thì không có cách nào lách điều đó. Thứ mọi người gọi là “embargo” chỉ là một ý tưởng khá ngớ ngẩn rằng nếu không ghi trắng ra trong mô tả bản vá kiểu “THIS IS A LPE” và mọi người cùng im lặng, thì có thể giả vờ lỗ hổng chưa bị lộ cho đến khi thông báo “chính thức” được gửi lên mailing list
    Có thể trước đây cách này còn phần nào biện minh được, nhưng trong thời đại LLM thì nó không chỉ ngớ ngẩn mà còn nguy hiểm, vì bạn có thể cho một pipeline tự động đẩy diff từ mailing list vào các model mới nhất và yêu cầu chúng xác định xem đó có phải bản vá sửa vấn đề bảo mật hay không
  • Liên kết bản vá đã được ai đó đăng lên tài khoản X của họ, và người khác nhìn thấy rồi chưa đầy một giờ sau đã đăng exploit hoạt động được. Có thể nó được hỗ trợ bởi LLM, nhưng ngoài thời gian chuyển đổi cực nhanh thì đó không phải tuyên bố đã được chứng minh
    https://x.com/encrypted_past/status/2052409822998392962
  • Một bên thứ ba không liên quan đã đăng công khai nó

• Có ai biết Debian có bị ảnh hưởng không? Tôi đã thử exploit trên máy Debian 12 và Debian 13 nhưng chưa tự tái hiện được

  • Tôi đã tái hiện được trên kernel 6.12.57+deb13-amd64 của Debian 13, tức Trixie, nhưng không tái hiện được trên kernel 6.1.0-42-amd64 của Debian 12 Bookworm
    Với những ai trên Bookworm không dùng luồng cập nhật bảo mật gói Debian, kernel 6.1.0-42-amd64 thực tế miễn nhiễm với copy.fail. Việc nó dường như cũng miễn nhiễm với dirtyfrag là điều đáng ngạc nhiên. Nếu luồng bảo mật chưa vá, bạn có thể chọn phiên bản kernel giữ lại commit 2b8bbc64b5c2. Tôi nghĩ chính commit đó có thể cũng đang vô tình khiến một số phiên bản kernel Debian 12 an toàn trước dirtyfrag
  • Tôi vừa thử exploit trên một droplet Debian 13 mới của DigitalOcean và nó hoạt động
  • Tôi đã test trên Debian 13 được cập nhật hoàn toàn mới nhất và exploit hoạt động. Tôi cũng xác nhận biện pháp giảm thiểu có tác dụng

• Chạy trong container ubuntu:latest với người dùng mặc định mới
  git clone https://github.com/V4bel/dirtyfrag.git && cd dirtyfrag && gcc -O0 -Wall -o exp exp.c -lutil && ./exp
  Kết quả: dirtyfrag: failed (rc=3)
  Tin tốt đấy!

  • Tôi cũng nhận kết quả tương tự khi chạy trong container, nhưng khi chạy trực tiếp trên host thì lại lấy được shell. Điều đó chỉ cho thấy exploit không hoạt động trong container. Vì vậy hoặc là container không dễ bị ảnh hưởng, hoặc script cần được điều chỉnh để chạy trong container
    copy fail có thể dùng để thoát container (https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kuber...), nên tôi đoán chỉ cần chỉnh exploit một chút là được
  • Khó mà xem container là nền tảng đáng tin cậy cho kiểu kiểm tra này. Dù là bình thường hay không, có rất nhiều thứ sẽ thất bại trong container

[GN⁺]

Ý kiến trên Lobste.rs

• Đúng là một tuần quá dữ dội nếu phải quản trị máy chủ Linux dùng chung. Dù vậy, lần công bố này nói thẳng ngay vào trọng tâm nên cũng đáng khen
  Nhưng tôi không hiểu vì sao trong hướng dẫn giảm thiểu ai cũng che stderr đi
  Sửa: cái này được báo cáo vào ngày 30 tháng 4 sau khi lấy “cảm hứng” từ copy.fail, vậy là bị phát hiện chưa đầy một ngày sau đó sao? Ấn tượng thật
  Với tư cách là người có quyền sudo trên một máy chủ dùng chung khá lớn, tôi cũng tự hỏi liệu tự biên dịch kernel với số module ít nhất có thể có phải là ý hay không. Tôi chưa cân nhắc kỹ ưu nhược điểm, nhưng có vẻ như như vậy đã có thể tránh được cả hai lỗ hổng leo thang đặc quyền cục bộ trong tuần này
  Sửa 2:

   * 2. rxrpc path  (Ubuntu fallback): if AF_ALG is sandboxed and the ESP
   *    path can't reach the page cache, fall back to the rxrpc/rxkad
   *    nullok primitive that patches /etc/passwd's root entry empty.
   *    PAM nullok then accepts the empty password during `su -`.  
  

  Ồ, cái này không cần setuid. Thật tốt khi họ đã đưa nó vào

  • Tôi đang làm vậy trên hệ thống nhiều người dùng mà mình duy trì, và thực tế đã tránh được cả hai exploit root cục bộ trong tuần này

• Liệu có khả thi và hợp lý không nếu lấy danh sách module kernel đang được nạp trên một hệ thống đang chạy rồi dùng nó làm danh sách cho phép của modprobe cho chính hệ thống đó?
  Cả CopyFail lẫn DirtyFrag đều có vẻ khai thác các module kernel không được nạp trên bất kỳ hệ thống nào tôi đã kiểm tra. Nếu vậy thì việc chặn các module rõ ràng là không cần thiết có thể giúp giảm thiểu trước một số cuộc tấn công chăng?

• 2026-05-07: Detailed information and the exploit for this vulnerability were published publicly by an unrelated third party, breaking the embargo.
  Tôi không hiểu sao chuyện này lại có thể xảy ra. Việc thông tin ở quy mô như thế này lại nằm trong một môi trường khó có thể tin cậy như vậy thật sự quá vô lý

  • Tôi không chắc câu “một bên thứ ba không liên quan đã công bố” có phải đang nói đến trường hợp này không, nhưng để tham khảo thì Brad Spengler đã nhìn vào commit vá lỗi được đẩy lên trước và nhận ra lỗ hổng bảo mật được ám chỉ trong thông điệp commit, rồi trong phần trả lời có người dùng vibe coding để tạo exploit
    Bất kỳ bên thứ ba nào theo dõi các commit của Linux cũng có thể đã lần ra cùng những manh mối đó và tạo được exploit
  • Cách diễn đạt “bên thứ ba không liên quan” nghe như thể họ không biết bug đó đang trong thời gian embargo
    “Môi trường khó có thể tin cậy” ở đây là toàn bộ Internet, và thực tế gần như chẳng có gì có thể gọi là cách ly cả. Vốn dĩ trước giờ đã vậy, chỉ là bây giờ điều đó rõ ràng hơn thôi. Bài viết gần đây của Stefan Eissing về việc lỗi Apache httpd bị tái phát hiện đến hai lần trước khi được vá cũng đáng đọc

• Có cách nào để kiểm tra xem các module bị ảnh hưởng có thực sự không thể được nạp hay không?
  Lần CopyFail trước tôi đã mắc lỗi khi áp dụng biện pháp giảm thiểu ban đầu. Tên tệp trong /etc/modprobe.d/ của tôi không kết thúc bằng .conf, và tôi không nhận ra điều đó cho đến khi chạy lệnh kiểm tra ở https://news.ycombinator.com/item?id=47954159. Có lệnh tương tự nào cho các module esp4/esp6/rxrpc không?

  • Tôi đã thử nạp cả ba module bằng modprobe và gặp cùng lỗi như lần trước
    Cũng có đoạn mã chứng minh khái niệm được đính kèm, nhưng tôi vẫn chưa thử nó