Copy Fail – CVE-2026-31431

 (copy.fail)
9 คะแนน โดย GN⁺ 2026-04-30 | 5 ความคิดเห็น | แชร์ทาง WhatsApp
  • ช่องโหว่ยกระดับสิทธิ์แบบหลบหนีคอนเทนเนอร์ที่สามารถ ยึดสิทธิ์ root ได้บนลินุกซ์ดิสทริบิวชันทั้งหมด นับตั้งแต่ปี 2017
  • อาศัย ข้อบกพร่องเชิงตรรกะที่เรียบง่าย ในโมดูลเข้ารหัสของลินุกซ์เคอร์เนล (authencesn) และสามารถรันได้ด้วย สคริปต์ Python ขนาด 732 ไบต์เพียงไฟล์เดียว โดยไม่ต้องอาศัยการจับจังหวะซับซ้อน (race condition) หรือการปรับแต่งตามเวอร์ชันเคอร์เนล
  • หลักการสำคัญคือการ แก้ไขแคชในหน่วยความจำ (page cache) ที่ลินุกซ์ใช้อ้างอิงเมื่อรันไฟล์ โดยเชื่อม AF_ALG (kernel crypto socket) กับ splice() (data-copy system call) เพื่อ เขียนทับ 4 ไบต์ลงในสำเนาแคชของ setuid binary
    • ไฟล์บนดิสก์จริงจะไม่ถูกเปลี่ยนแปลง จึงเป็น การโจมตีแบบลอบเร้นที่ไม่ทิ้งร่องรอยไว้ใน forensic disk image
    • เมื่อรีบูตหรือหน่วยความจำถูกคืน แคชจะกลับเป็นต้นฉบับ ทำให้การตรวจจับย้อนหลังด้วยการตรวจสอบความสมบูรณ์ของไฟล์แบบดั้งเดิมทำได้ยาก
  • เนื่องจาก page cache ถูกแชร์ทั้งโฮสต์ ในสภาพแวดล้อม Kubernetes หากพ็อดหนึ่งใช้ช่องโหว่นี้ ก็สามารถยึดโฮสต์โหนดและ หลบหนีคอนเทนเนอร์ไปยังคอนเทนเนอร์ของผู้เช่ารายอื่น ได้
  • มีการยืนยันโดยตรงบน Ubuntu 24.04, Amazon Linux 2023, RHEL 10.1 และ SUSE 16 และหากมีเพียงบัญชีผู้ใช้ภายในเครื่องที่ไม่มีสิทธิ์พิเศษก็สามารถทำงานได้ทันที โดยไม่ต้องเข้าถึงเครือข่ายหรือใช้ฟังก์ชันดีบักเคอร์เนล
  • ช่องโหว่ยกระดับสิทธิ์บนลินุกซ์ (LPE) ที่มีอยู่เดิมมักมีอัตราสำเร็จต่อครั้งเพียง 30~80% และใช้ได้เฉพาะกับเคอร์เนลบางช่วง แต่ Copy Fail มี อัตราสำเร็จ 100% ในการลองครั้งเดียว ครอบคลุมทุกดิสทริบิวชันตลอด 9 ปี (2017~2026)
  • ต่างจากช่องโหว่ตระกูลแก้ไข page cache แบบเดียวกันอย่าง Dirty Pipe (อาศัย pipe buffer flag) และ Dirty Cow (ต้องมี race condition) ตรงที่ไม่มี race condition, ไม่มี offset เฉพาะดิสทริบิวชัน และไม่ต้องคอมไพล์ใหม่ จึงทั้งเรียบง่ายและทรงพลังกว่ามาก
  • กลุ่มที่เร่งด่วนที่สุด: ลินุกซ์โฮสต์แบบ multi-tenant, คลัสเตอร์ Kubernetes/คอนเทนเนอร์, CI runner (GitHub Actions แบบ self-hosted, GitLab runner เป็นต้น), cloud SaaS ที่รันโค้ดของผู้ใช้ — ทุกสภาพแวดล้อมที่โค้ดไม่น่าเชื่อถือทำงานอยู่บนเคอร์เนลที่ใช้ร่วมกัน
  • มาตรการที่สำคัญที่สุดคือแพตช์เคอร์เนล (mainline commit a664bf3d603d) — ย้อนการเพิ่มประสิทธิภาพแบบ in-place ของโมดูลเข้ารหัสที่ถูกนำเข้าในปี 2017 เพื่อไม่ให้ page cache page ถูกรวมเป็นเป้าหมายการเขียนของการทำงานเข้ารหัส
  • มาตรการชั่วคราวก่อนแพตช์คือปิดใช้งานโมดูล algif_aead ได้ และจะ ไม่กระทบ ต่อความสามารถเข้ารหัสทั่วไปอย่าง dm-crypt/LUKS, kTLS, IPsec และ SSH
  • สำหรับสภาพแวดล้อมเวิร์กโหลดที่ไม่น่าเชื่อถือ เช่น คอนเทนเนอร์, แซนด์บ็อกซ์, CI runner แนะนำให้ บล็อกการสร้าง socket แบบ AF_ALG ด้วย seccomp ไม่ว่าจะติดตั้งแพตช์แล้วหรือไม่ก็ตาม
  • Taeyang Lee แห่ง Xint ได้ข้อสังเกตตั้งต้นว่า “โครงสร้างที่ splice() ส่ง page cache page ไปยังระบบย่อยการเข้ารหัสเป็นคลาสบั๊กที่ยังไม่ถูกสำรวจ” และ Xint Code ก็ใช้การสแกนอัตโนมัติกับเคอร์เนลซับซิสเต็ม crypto/ จนค้นพบได้ภายในราว 1 ชั่วโมง เป็นกรณีตัวอย่างของ การตรวจหาช่องโหว่แบบมี AI ช่วย

บทความที่เกี่ยวข้อง

5 ความคิดเห็น

 
popopo 2026-05-04

ดูเหมือนว่า Rocky Linux ยังไม่มีแพตช์ออกมานะครับ

RHEL

AlmaLinux

Rocky Linux

กำลังใช้งาน Rocky Linux อยู่ และถ้ารีบูตไม่ได้ การบล็อกด้วย bpftool จาก https://github.com/wgnet/wg.copyfail.patch ก็ยังใช้ได้ผลครับ
 
popopo 2026-05-04

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

มีแพตช์ก็จริง แต่ให้เฉพาะในคลังแพ็กเกจของบริการสมัครสมาชิกเท่านั้น เวอร์ชัน CE ยังไม่ได้รับแพตช์ (ตรวจสอบแล้วใน 9.7, 10.1)
 
popopo 29 일 전

มีแพตช์ออกมาแล้วเมื่อ 2026-05-05

มีตัวเลือกด้านความปลอดภัยใหม่เมื่อ 2026-05-10
https://forums.rockylinux.org/t/…

sudo dnf --enablerepo=security update

หากเพิ่มคลังแพ็กเกจความปลอดภัย ดูเหมือนว่าจะสามารถดำเนินมาตรการด้านความปลอดภัยได้แยกต่างหากจากการสะท้อนซอร์สของ RHEL
 
sukso96100 2026-05-02

สำหรับผู้ที่ใช้งาน Ubuntu น่าจะมีคู่มือวิธีรับมือออกมาแล้ว ลองอ้างอิงกันได้ครับ

https://discourse.ubuntu.com/t/…
 
GN⁺ 2026-04-30
ความเห็นจาก Hacker News

  • ในมุมของคนที่ทำงานกับโค้ด crypto ของเคอร์เนล Linux ช่องโหว่ AF_ALG exploit ที่โผล่มาเป็นระยะนี่ชวนหงุดหงิดมาก
    AF_ALG ถูกใส่เข้ามาในเคอร์เนลตั้งนานแล้วโดยแทบไม่ได้รับการรีวิวมากพอ โครงสร้างก็ซับซ้อนเกินไป แถมยังเปิดพื้นผิวการโจมตีขนาดใหญ่ให้กับโปรแกรม userspace ที่ไม่มีสิทธิพิเศษ
    ยิ่งไปกว่านั้นมันแทบไม่จำเป็นเลย เพราะฝั่ง userspace ก็มีโค้ดเข้ารหัสของตัวเองอยู่แล้ว และโค้ด crypto ในเคอร์เนลเดิมทีก็มีไว้สำหรับการใช้งานภายในเคอร์เนลอย่าง dm-crypt
    แม้แต่ authencesn ใน exploit ครั้งนี้เอง ก็เป็นรายละเอียดการติดตั้งใช้งานภายในของ IPsec เป็นหลัก การเอาสิ่งนี้มาเปิดเป็น API เข้ารหัส/ถอดรหัสทั่วไปสำหรับ userspace ตั้งแต่แรกจึงดูเป็นการตัดสินใจที่ผิด
    ถ้าคุณเป็นคนดูแลการตั้งค่าเคอร์เนล Linux ขอแนะนำอย่างยิ่งให้ปิดทุกตัวเลือก CONFIG_CRYPTO_USER_API_*
    ถ้าทำแค่นั้น ไม่ใช่แค่บั๊กครั้งนี้ แต่บั๊ก AF_ALG จำนวนมากทั้งในอดีตและอนาคตก็คงถูกนำไปใช้โจมตีไม่ได้
    ถ้ามีโปรแกรม userspace พัง ก็ควรช่วยย้ายมันไปใช้โค้ด crypto ฝั่ง userspace แทน ซึ่งในความเป็นจริงหลายตัวก็เปลี่ยนไปแบบนั้นแล้ว
    ตั้งแต่แรก AF_ALG ก็แทบไม่มีประโยชน์ใช้นอกจากเป็นช่องให้ exploit
    เมื่อก่อน API สำหรับ userspace แบบนี้อาจพอทนรับได้ แต่ในยุคที่มี syzbot และ การตรวจจับบั๊กด้วย LLM แบบตอนนี้ มันคงอยู่ต่อได้ยากแล้ว

    • ฉันไม่รู้ว่า AF_ALG คืออะไรเลยไปค้นดู แล้วเจอ https://www.chronox.de/libkcapi/html/ch01s02.html ซึ่งก็มีการอธิบายเหตุผลการมีอยู่ของมันไว้พอสมควร
      เหตุผลที่ยกมาคือ ช่วยให้ userspace ใช้ ตัวเร่งฮาร์ดแวร์ ที่เข้าถึงได้เฉพาะในโหมดเคอร์เนลได้, ส่งคีย์เข้าเคอร์เนลโดยไม่ต้องปล่อยให้ค้างอยู่ในหน่วยความจำของแอปนาน ๆ, และลด footprint ได้เมื่อเทียบกับไลบรารี crypto ฝั่ง userspace ในสภาพแวดล้อมที่หน่วยความจำจำกัดอย่างระบบ embedded
      จะถือว่าเป็นเหตุผลที่ดีพอหรือไม่ฉันยังตัดสินไม่ได้ แต่อย่างน้อยก็พอมีเหตุผลรองรับอยู่
    • ชวนสงสัยว่า มันเข้าไปอยู่ในเคอร์เนลได้ยังไง
      ปกติ Linus ขึ้นชื่อว่าเข้มมากเรื่องจะรับอะไรเข้าเคอร์เนล เรื่องเบื้องหลังของ API แบบนี้น่าจะน่าสนใจทีเดียว
    • AF_ALG คือ socket interface ของ Linux ที่เปิดเผย kernel crypto API ผ่าน file descriptor
      ทำให้จัดการ hash และการเข้ารหัสผ่านการเรียก read(2)/write(2) แบบทั่วไปได้
    • สิ่งที่ฉันอยากรู้ที่สุดคือ ถ้าปิดตัวเลือกเคอร์เนลนี้แล้ว ซอฟต์แวร์ตัวไหนจะพังบ้าง

  • ดูเหมือนว่าระหว่างกระบวนการเปิดเผยข้อมูลจะมี ความสับสน อยู่พอสมควร
    ผู้ขายหลายรายดูจะไม่ได้ให้ความสำคัญกับช่องโหว่นี้มากนัก และเพราะแบบนั้นหลายดิสโทรจึงยังคงอยู่ในสถานะที่ยังไม่แพตช์
    https://access.redhat.com/security/cve/cve-2026-31431 ระบุว่า "Moderate severity", "Fix deferred" และหน้าติดตามของ Debian, Ubuntu, SUSE ก็ดูคล้ายกัน

    • ตั้งแต่ตอนที่แพตช์เข้าเคอร์เนล มันก็กลายเป็นสิ่งที่ผู้โจมตีหรือผู้สังเกตการณ์รับรู้ได้โดยพฤตินัยมาหลายสัปดาห์แล้ว
      แต่ฝั่ง upstream ไม่ได้สื่อสารอย่างชัดเจนว่านี่คือ ช่องโหว่ และ Linus กับ Greg เองก็ไม่ได้ให้ความสำคัญเชิงแนวคิดกับการจัดหมวดแบบนั้นมากนัก
    • เหตุผลที่หลายดิสโทรมองว่าเป็น ความเสี่ยงระดับปานกลาง น่าจะเพราะมันไม่ใช่การรันโค้ดจากระยะไกล แต่ต้องอาศัย การเข้าถึงในเครื่อง
      ถึงอย่างนั้น เมื่อมันยกระดับสิทธิ์เป็น root ได้จากภายในเครื่อง โดยทั่วไปก็ควรถือว่าเป็นเรื่องที่มีลำดับความสำคัญสูง
      https://ubuntu.com/security/cves/about#priority
    • ตอนนี้ RedHat เปลี่ยนเป็น Important severity และ Affected แล้ว
    • ถ้าดูตามแนวทางของ Ubuntu เอง เรื่องนี้ก็ดูควรจัดเป็น high priority แต่การระบุจริงกลับเป็น medium เลยดูไม่ค่อยสอดคล้องกัน

  • น่าเสียดายที่ในบทความไม่ได้บอกตรง ๆ ว่า เคอร์เนลเวอร์ชัน ไหนได้รับผลกระทบ และเวอร์ชันไหนแพตช์แล้ว
    ยิ่งแย่ไปอีกเพราะอันนี้เป็นโมดูลแบบ builtin จึงเอาออกง่าย ๆ ด้วย rmmod ไม่ได้
    ตอนตามหาว่า kernel 6.19.14 ของ Fedora 44 เปราะบางหรือไม่ ฉันไปเจอโพสต์ในเมลลิงลิสต์ linux-cve-announce https://lore.kernel.org/linux-cve-announce/2026042214-CVE-2026-31431-3d65@gregkh/T/#u
    ข้างในระบุว่าได้แก้ผ่านคอมมิตนั้นใน 6.18.22, 6.19.12, และ 7.0 ตามลำดับ จึงพอใช้อ้างอิงได้

  • ถ้าคุณอยากตรวจสอบว่าได้ใช้มาตรการบรรเทาที่แนะนำด้วยการบล็อกเคอร์เนลโมดูล algif_aead ผ่านการตั้งค่า modprobe แล้วหรือยัง ก็ไม่จำเป็นต้องรันเชลล์โค้ดที่ทำให้อ่านยากทั้งก้อน
    ใช้ Python ไม่กี่บรรทัดด้านล่างเพื่อตรวจแบบอ่านง่าย ๆ ว่าโมดูลถูกโหลดจริงหรือไม่ก็ได้
    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")'
    ถ้ามาตรการบรรเทาทำงานถูกต้อง modprobe algif_aead ก็ควรล้มเหลวพร้อม error เช่นกัน

  • คงไม่มีใครรัน AI agent อัตโนมัติเต็มรูปแบบ ด้วยสิทธิ์ผู้ใช้ทั่วไปบนระบบปฏิบัติการที่ได้รับผลกระทบหรอกใช่ไหม
    ถ้าจับคู่กับ zero-day prompt injection มันอาจกลายเป็นหายนะได้เลย

    • agent ของฉันรันเป็น root อยู่แล้ว เลยไม่เห็นปัญหาอะไร
    • โชคดีที่เราไม่ได้ทำให้การติดตั้งแบบ curl | sh กลายเป็นมาตรฐานอุตสาหกรรม

  • LPE ย่อมาจาก local privilege escalation
    วงการความปลอดภัยมีตัวย่อเยอะเกินไป แม้จะเดาจากบริบทได้ แต่ก็คงดีถ้าเขียนเต็มให้ตั้งแต่แรก

    • LPE เป็นตัวย่อที่รู้จักกันค่อนข้างแพร่หลายในชุมชนความปลอดภัย จึงอาจไม่ถึงกับแย่มากที่ไม่ได้เขียนเต็ม
      แต่ถ้าเป็นบทความที่เขียนให้ผู้อ่านวงกว้าง ก็เห็นด้วยว่าควรนิยามให้ชัดเจน
      ยิ่งไปกว่านั้น บทความทั้งชิ้นยังดูเหมือน งานที่สร้างโดย AI ด้วย
    • ถ้าเขียนเพื่อผู้อ่านวงกว้าง การเขียนคำเต็มก่อนตัวย่อเป็นเรื่องพื้นฐาน แต่พวก LLM มักไม่ค่อยทำตามแนวทางนี้

  • อันนี้ค่อนข้างขำ
    หน้าเว็บเขียนว่าทำงานบน RHEL 14.3 ได้ แต่เวอร์ชันแบบนั้นไม่มีอยู่จริง
    ตอนนี้ RHEL อยู่ที่ 10.x เลยเหมือนหลุดเข้า TARDIS ไปยังไงไม่รู้

    • 14.3 น่าจะไม่ได้หมายถึงเวอร์ชันของ RHEL แต่เป็น เลขเวอร์ชัน GCC ฝั่ง Red Hat มากกว่า
      บางครั้งจะแสดงเป็น gcc (GCC) 14.3.1 20250617 (Red Hat 14.3.1-2) และในตัวอย่างด้านล่างก็เห็นร่องรอยคล้ายกัน
      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
    • ในบรรทัดเดียวกันยังมี 6.12.0-124.45.1.el10_1 อยู่ด้วย ซึ่งชัดเจนว่าเป็นเคอร์เนลของ RHEL 10
      ความผิดพลาดแนวนี้กลับเป็นสิ่งที่คนมักพลาดกันเอง
      เลขยาว ๆ ที่คัดลอกมามักถูกต้อง แต่เลขง่าย ๆ กลับพิมพ์มือแล้วผิด
    • ขอโทษด้วย เรื่องนั้นจะถูกแก้ไข
      ตอนนั้นมีการเร่งรวบรวมข้อมูลเพื่ออธิบายประเด็นนี้ และก็จริง มันมีมุมทางการตลาดอยู่ด้วย
      เลยมีข้อผิดพลาดเล็ก ๆ หลุดเข้ามาบ้าง ขอบคุณที่ช่วยชี้ให้เห็น
    • ใช่ พอเห็นคำว่า "ดิสโทรที่ยืนยันแล้วโดยตรง: RHEL 14.3" ฉันก็รู้สึกทันทีว่าอย่างน้อยหน้าปล่อยข้อมูลนี้ก็ดูเป็น AI slop
      https://access.redhat.com/articles/red-hat-enterprise-linux-release-dates
      พอเลื่อนลงไปเห็น "Talk to our security experts" ที่ท้ายหน้า ก็เริ่มรู้สึกว่า expert คนนั้นจะชื่อ Claude หรือเปล่า

  • บน RHEL 9/10 นั้น algif_aead ไม่ได้เป็นโมดูล แต่เป็น builtin จึง unload ไม่ได้
    ดังนั้นเราจึงหาวิธีรองลงมาคือ บล็อก AF_ALG ผ่าน systemd และต้องมี drop-in แยกตามแต่ละ service ที่เปิดให้ใช้งาน
    ยังมี Ansible playbook สำหรับจัดการตัวหลักอย่าง sshd และ user@ ด้วย
    https://gist.github.com/m3nu/c19269ef4fd6fa53b03eb388f77464da

    • บน RHEL 9/10 ยังใช้วิธีใส่ initcall_blacklist=algif_aead_init ในตัวเลือกบูตของเคอร์เนลแล้วรีบูตได้ด้วย
      ทำแบบนั้นแล้ว exploit ใช้งานไม่ได้อีกต่อไป
    • ฉันก็คิดแนวทางคล้ายกัน แต่การบล็อกทีละ service มันให้ความรู้สึกเหมือน ตีตัวตุ่น
      ยังน่ากังวลว่าจะมีเส้นทางรันอื่นอย่าง cronjob, slurmjob หรือเปล่า และถ้าพอมีวิธีทำให้ systemd ส่งต่อข้อจำกัดนี้ไปยังทุกโปรเซสทั้งระบบแทนการตั้งราย service ได้ก็คงดีกว่า

  • ดูเหมือน exploit นี้จะใช้วิธีสลับแทนที่ SUID binary เพื่อให้รันด้วย PID 0
    แต่ตัวเว็บไซต์กลับอ้างว่าสามารถหนีจาก Kubernetes / container clusters, CI runners & build farms ได้ ทั้งที่ยังไม่เห็นคำอธิบายที่รองรับเรื่องการหนีออกจากคอนเทนเนอร์ หรือโดยเฉพาะ user namespace escape เลย
    ฉันทดสอบบน rootless Podman แล้วก็เป็นไปตามคาด คือยังหนีออกจากคอนเทนเนอร์ไม่ได้
    อีกทั้งยังอ้างว่า "ทำให้ทุก Linux distribution ที่ออกหลังปี 2017 กลายเป็น root ได้" แต่การทดสอบจริงมีแค่สี่ตัว และบน Alpine ก็ใช้ไม่ได้

    • ฝั่งเว็บไซต์ก็บอกเองว่าคำอธิบายละเอียดจะตามมาเร็ว ๆ นี้ ดังนั้นน่าจะมีขั้นตอนเพิ่มหรือการแก้ไขบางอย่างใน part 2
      มีการเกริ่นไว้ว่า "Next: "From Pod to Host," how Copy Fail escapes every major cloud Kubernetes platform."
    • ช่องโหว่นี้สามารถเขียนทับไบต์ในหน่วยความจำของไฟล์ที่อ่านได้ จึงพอจินตนาการได้เลยว่ามันอาจใช้หนีออกจากสภาพแวดล้อมได้หลายแบบ
    • คำกล่าวอ้างว่า ทุกดิสโทรหลังปี 2017 น่าจะอิงกับข้อเท็จจริงว่าช่องโหว่นี้ถูกเพิ่มเข้ามาโดยคอมมิตช่วงครึ่งหลังของปี 2017
      https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=72548b093ee3
      แต่ความสามารถในการนำไปใช้โจมตีจริงย่อมต่างกันไปตามว่าเป็นเมเจอร์รีลีสล่าสุด หรือเป็นเคอร์เนลสายบำรุงรักษาของสาขาเก่า
    • บทความนี้ทำลายความน่าเชื่อถือของตัวเองไปมากพอสมควร
      ถึงอย่างนั้น เมื่อฉันลองรัน PoC บนอินสแตนซ์ 24.04 เอง ช่องโหว่นี้ก็ดูเป็นของจริงและใหญ่พอตัว
      เพียงแต่จำนวนดิสโทรที่ได้รับผลกระทบดูน้อยกว่าที่อ้างไว้มาก และห่างไกลจากคำว่า ทุกดิสโทรหลังปี 2017
      ตัวอย่างเช่น ถ้าฉันตีความไม่ผิด Ubuntu แม้แต่ 16.04 EOL ก็ยังโดนเล็กน้อย และผลกระทบหลักจริง ๆ น่าจะอยู่ที่ vendor kernel ที่เพิ่งเริ่มแจกจ่ายไม่นานอย่าง linux-gcp, linux-oracle-6.7 ซึ่งอยู่ในสาย 6.17 มากกว่า
    • ต่อให้ยังอยู่ในคอนเทนเนอร์แบบ rootless ถ้าสามารถไต่ขึ้นไปถึง UID 0 จริง ได้ การหนีออกหลังจากนั้นก็ยังเป็นไปได้
      เพียงแต่ต้องมีขั้นตอนเพิ่มเติม และกรณีของ Alpine ก็อาจแค่ต้องปรับสคริปต์ ไม่ได้แปลว่าไม่มีช่องโหว่พื้นฐาน
      สุดท้ายแล้วนี่ไม่ใช่ exploit อเนกประสงค์ที่สมบูรณ์ แต่เป็น PoC

  • ตัวหน้าเว็บเองดู vibecoded หน่อย ๆ และมีกลิ่นโฆษณา แต่ช่องโหว่นั้นเป็นของจริงและระดับความเสี่ยงก็ดูสูง
    อย่างน้อยมันก็อธิบายได้ว่าทำไมวันนี้ถึงมีอัปเดตความปลอดภัยก้อนใหญ่เข้ามา ดังนั้นคงต้องยกระดับความสำคัญของการอัปเดตแล้ว

    • มันเป็น โฆษณา ที่ค่อนข้างตรงไปตรงมาจริง แต่ส่วนตัวฉันมองว่าไม่ใช่โฆษณาที่แย่
      พวกเขาหาบั๊กจริง แพตช์จริง และสร้าง คุณูปการที่มีความหมายต่อ ecosystem ของ OSS ไปพร้อมกับขายเครื่องมือความปลอดภัยของตัวเอง
    • ต่อให้ไม่มีโฆษณา คนกลุ่มนี้ก็น่าจะงานล้นมืออยู่แล้ว
      แต่ก็อดคิดไม่ได้ว่าเดี๋ยวนี้ใครจะมานั่งทำหน้าเว็บด้วยมือตัวเองทีละหน้า โดยเฉพาะถ้าเป็น นักพัฒนาเคอร์เนล ก็ยิ่งน่าเป็นไปได้