libsmb2 ก่อน 6.3 มี CVE-2026-115505: คำตอบ SMB share อาจทำให้หน่วยความจำเสียหาย

libsmb2 ก่อน 6.3 เสี่ยงอ่านหรือเขียนหน่วยความจำเกินขอบเขตเมื่อไคลเอนต์เรียกรายชื่อ SMB share

โครงการ libsmb2 ออกรีลีสความปลอดภัย 6.3 เมื่อ 21 ตุลาคม 2026 เวลา 22:10 UTC เพื่อแก้ปัญหาในตัวถอดรหัส DCE/RPC NDR และจุดประมวลผล SMB อื่น ๆ หนึ่งในปัญหานั้นได้เลข CVE-2026-115505 โดยระเบียน CVE เผยแพร่ครั้งแรกวันที่ 22 ตุลาคม 2026 เวลา 19:14 UTC รายงานต้นทางใน GitHub issue #496 เปิดต่อสาธารณะวันที่ 21 ตุลาคม เวลา 13:26 UTC จึงผ่านเงื่อนไขความสดทั้งวันเปิดเผยครั้งแรกและวันเผยแพร่ระเบียน ไม่ใช่การหยิบแพตช์เก่ามาเขียนเป็นข่าวใหม่

ประเด็นสำคัญของข่าวคือ ไคลเอนต์ที่ใช้ smb2_share_enum_async() เพื่อเรียกรายชื่อ share จาก SMB server อาจได้รับคำตอบ NetrShareEnum ที่มีตัวนับขนาดผิดปกติ หากเซิร์ฟเวอร์เป็นอันตราย หรือมีผู้โจมตีแก้ข้อมูลระหว่างทางบนการเชื่อมต่อที่ไม่ได้ลงลายเซ็น ตัวถอดรหัสในรุ่นก่อน 6.3 อาจคำนวณขนาดแบบ 32 บิตแล้วเกิด integer overflow ส่งผลให้เกิดการอ่านหรือเขียนนอกขอบเขตหน่วยความจำของโปรเซสไคลเอนต์ ความเสี่ยงนี้เป็นเรื่องของไลบรารีฝั่งที่รับและแปลคำตอบ ไม่ได้หมายความว่า Windows SMB Server ทุกเครื่องมีช่องโหว่นี้

เส้นทางที่ทำให้เกิดปัญหา

libsmb2 เป็นไลบรารีสำหรับเข้าถึงหรือให้บริการ SMB2/SMB3 ใน userspace และมีทั้ง API ระดับสูงกับ API แบบ asynchronous การเรียกรายชื่อ share เป็นฟังก์ชันที่แอปใช้ค้นหาทรัพยากรบนเซิร์ฟเวอร์ เช่น file browser, ระบบสำรองข้อมูล หรือเครื่องมือที่ตรวจคลังแชร์ก่อนเลือกปลายทาง แม้แอปจะไม่เปิดหน้าเว็บสาธารณะ ก็ยังควรตรวจว่ามันรับชื่อเซิร์ฟเวอร์ SMB จากผู้ใช้หรือเชื่อมต่อกับเซิร์ฟเวอร์นอกเขตความไว้วางใจหรือไม่

ตามคำอธิบายในแพตช์ ผู้ส่งคำตอบควบคุมค่า count ใน DCE/RPC ได้สองจุด จุดแรกคือการอ่านสตริง UTF-16: การตรวจ actual_count * 2 ด้วยเลขขนาด 32 บิตอาจวนกลับเป็นค่าที่ดูเล็กกว่าความจริง ทำให้การตรวจขนาดผ่าน แต่ขั้นตอนแปลงข้อความอ่านเลยท้ายข้อมูล จุดที่สองคือการจองหน่วยความจำให้ conformant array: max_count * elem_size อาจวนกลับจนจองบัฟเฟอร์เล็กเกินกว่าจำนวนสมาชิกที่จะเขียน โค้ดแก้ไขใช้การตรวจขนาดที่ไม่ปล่อยให้การคูณล้น และปฏิเสธ count ที่มากกว่าข้อมูลใน reply ก่อนจองบัฟเฟอร์

ระเบียน CVE ระบุผลเป็น heap out-of-bounds read และ write ซึ่งอาจทำให้โปรเซสล่มหรือข้อมูลในหน่วยความจำเสียหาย อย่างไรก็ดี ผู้รายงานระบุว่าเป็นผลจากการตรวจซอร์สโค้ดและ ไม่ได้พัฒนา runtime exploit จึงไม่ควรนำข่าวนี้ไปสรุปว่ามีการรันโค้ดจากระยะไกลที่พิสูจน์ได้แล้ว ขอบเขตการโจมตีขึ้นกับว่าใครควบคุม SMB server ที่แอปเชื่อมต่อ และการเชื่อมต่อนั้นป้องกันการแก้ข้อความระหว่างทางอย่างไร

รุ่นที่กระทบและแพตช์

ระเบียน CVE ระบุว่า libsmb2 ทุกรุ่นก่อน 6.3 อยู่ในช่วงที่กระทบสำหรับประเด็นนี้ ผู้พัฒนาปล่อย 6.3 เป็น security release ต่อจาก 6.2 และระบุว่าคง API, ABI และ soname เดิม จึงออกแบบให้แทนที่รุ่น 6.2 ได้โดยไม่ต้องเปลี่ยนอินเทอร์เฟซของแอป แต่การใช้งานจริงยังต้องทดสอบการเชื่อมต่อ การเรียกรายชื่อ share และแพ็กเกจที่ฝังไลบรารีไว้ในตัว โดยเฉพาะ container หรือโปรแกรมที่ไม่ได้ใช้ไลบรารีจากระบบปฏิบัติการ

หน้า release notes ของ 6.3 ยังระบุการแก้ปัญหาหน่วยความจำและความเสถียรอื่นอีกหลายจุด เช่น ความยาวและ offset ที่ไม่น่าเชื่อถือในตัวถอดรหัส PDU, คำตอบ query directory ที่ทำให้ free ซ้ำ และคำตอบชั่วคราวที่สั้นผิดปกติ แต่ CVE-2026-115505 อ้างถึง integer overflow ใน DCE/RPC conformant string/array decoder ที่เข้าถึงผ่านการเรียกรายชื่อ share โดยเฉพาะ ไม่ควรเหมาว่ารายการแก้อื่นทั้งหมดเป็นเลข CVE เดียวกัน

ผู้ดูแลควรตรวจอะไร

เริ่มจากสำรวจว่าโปรแกรมใดลิงก์ libsmb2 รุ่นก่อน 6.3 ทั้งแบบ shared library และแบบ static หากเป็นแอปที่แสดงรายชื่อแชร์ ให้ค้นการเรียก smb2_share_enum_async() หรือฟังก์ชัน synchronous ที่ทำงานเดียวกัน แล้วตรวจที่มาของ SMB server ที่แอปยอมเชื่อมต่อ เซิร์ฟเวอร์ที่ผู้ใช้เพิ่มเอง, อุปกรณ์ NAS ของบุคคลภายนอก และเครือข่ายที่ไม่ควบคุมร่วมกันเป็นจุดที่ควรให้ความสำคัญมากกว่าการเชื่อมต่อกับปลายทางที่องค์กรดูแลและตรวจสอบได้

อัปเกรด libsmb2 เป็น 6.3 หรือใหม่กว่า ในสภาพแวดล้อมทดสอบก่อน แล้วตรวจเวอร์ชันที่โปรเซสโหลดจริงหลัง deploy ไม่ใช่ดูเพียงเวอร์ชันแพ็กเกจในไฟล์ manifest ทดสอบการเชื่อมต่อ SMB2/SMB3 ปกติ การพิสูจน์ตัวตน และการอ่านรายชื่อ share ให้ครอบคลุมเซิร์ฟเวอร์หลายชนิด หากแพ็กเกจของดิสทริบิวชัน backport แพตช์มายังเวอร์ชันชื่อเดิม ให้ยืนยันจากประกาศของผู้ดูแลแพ็กเกจนั้นโดยตรงก่อนสรุปว่าแก้แล้ว

ระหว่างรออัปเกรด ลดการเชื่อมต่อไปยัง SMB server ที่ไม่ไว้วางใจและหลีกเลี่ยงการเรียกรายชื่อ share จาก URL หรือชื่อ host ที่ผู้ใช้ทั่วไปกำหนดได้ การบังคับใช้การลงลายเซ็น SMB ตามความสามารถของระบบช่วยลดโอกาสแก้คำตอบระหว่างทาง แต่ไม่แทนแพตช์ เพราะเซิร์ฟเวอร์ปลายทางที่เป็นอันตรายยังส่งคำตอบที่ผิดรูปแบบได้ หากบริการล่มเมื่อเรียกรายชื่อ share ให้เก็บเวอร์ชันไลบรารี ปลายทาง เวลา และ crash log เพื่อเทียบกับเหตุการณ์อื่น อย่าใช้เพียงอาการล่มเป็นหลักฐานว่าถูกใช้ CVE นี้

แหล่งต้นทาง: รายงาน GitHub issue #496, libsmb2 6.3 release notes, คอมมิตแก้ในตัวถอดรหัส และ ระเบียน CVE-2026-115505