ช่องโหว่ Security Vulnerability — CVE-2026-87039 (CVSS 7.8)

📋 สรุปช่องโหว่

ช่องโหว่ Security Vulnerability ถูกค้นพบและรายงานใน NVD โดยมี CVSS Score 7.8 ระดับ "สูง"

รายละเอียดต้นฉบับ (EN): The user-mode syscall verifier z_vrfy_i2s_configure() in drivers/i2s/i2s_handlers.c copies the caller's struct i2s_config in from user memory and then, when cfg->frame_clk_freq is 0 (the API's "unconfigure the stream" request), jumps straight to z_impl_i2s_configure() without performing the K_SYSCAL

ผู้ดูแลระบบที่ใช้ซอฟต์แวร์ที่ได้รับผลกระทบควรตรวจสอบและอัพเดตโดยเร็ว

💥 ผลกระทบที่อาจเกิดขึ้น

ผลกระทบขึ้นอยู่กับประเภทและบริบทการใช้งาน:

• ระดับความรุนแรง CVSS 7.8 (สูง) บ่งชี้ว่าช่องโหว่นี้อาจส่งผลต่อความปลอดภัยของระบบในระดับสูง
• ผู้โจมตีอาจใช้ประโยชน์จากช่องโหว่นี้เพื่อเข้าถึง แก้ไข หรือทำลายข้อมูลในระบบ
• ดูรายละเอียดผลกระทบเฉพาะที่ https://nvd.nist.gov/vuln/detail/CVE-2026-87039

🖥️ ซอฟต์แวร์และระบบที่ได้รับผลกระทบ

ตรวจสอบเวอร์ชันที่ได้รับผลกระทบและข้อมูลเพิ่มเติมที่ https://nvd.nist.gov/vuln/detail/CVE-2026-87039

🔧 แนวทางการแก้ไขและป้องกัน

• ขั้นตอนแก้ไขทั่วไป:
• 1. ตรวจสอบ Vendor Advisory: เข้าไปที่เว็บไซต์ vendor หรือ https://nvd.nist.gov/vuln/detail/CVE-2026-87039 เพื่อดู patch อย่างเป็นทางการ
• 2. อัพเดตเป็นเวอร์ชันล่าสุด: ติดตั้งเวอร์ชันที่แก้ไขช่องโหว่แล้วทันที
• 3. ตรวจสอบ Logs: ดู system log และ access log หาร่องรอยการโจมตีที่อาจเกิดขึ้นแล้ว
• 4. ติดตั้ง Security Monitoring: ใช้ WAF หรือ IDS เพื่อ monitor การโจมตี
• 5. Backup ข้อมูล: สำรองข้อมูลสำคัญก่อนทำการเปลี่ยนแปลงใดๆ
• 6. แจ้งทีมงาน: แจ้งให้ทีม IT security ทราบเพื่อวางแผนรับมือ

📄 รายละเอียดต้นฉบับ (ภาษาอังกฤษ)

The user-mode syscall verifier z_vrfy_i2s_configure() in drivers/i2s/i2s_handlers.c copies the caller's struct i2s_config in from user memory and then, when cfg->frame_clk_freq is 0 (the API's "unconfigure the stream" request), jumps straight to z_impl_i2s_configure() without performing the K_SYSCALL_OBJ(config.mem_slab, K_OBJ_MEM_SLAB) ownership/type check or the block_size sanity check. The mem_slab field is a struct k_mem_slab *, so on that path a completely unvalidated, user-chosen pointer reaches driver code that is entitled to trust it as a real kernel object. Any thread running under CONFIG_USERSPACE that has access to an I2S device object can trigger this with a single i2s_configure() call. Most in-tree drivers special-case frame_clk_freq == 0 and never store the caller's structure, but drivers/i2s/i2s_litex.c does not: i2s_litex_configure() only logs a warning for a mismatched frame clock, then memcpy()s the caller's config into stream->cfg and marks the stream I2S_STATE_READY. A subsequent i2s_trigger() with I2S_TRIGGER_START enables the FIFO interrupt, and the interrupt handlers i2s_litex_isr_rx() / i2s_litex_isr_tx() then call k_mem_slab_alloc() and k_mem_slab_free() on the attacker-supplied pointer in supervisor context. The result is an arbitrary-pointer read/write primitive executed by the kernel on behalf of an unprivileged thread — k_mem_slab_alloc() takes a spinlock at slab->lock and reads and writes slab->free_list and the link word inside the returned "block" — which defeats the CONFIG_USERSPACE isolation boundary entirely. The same missing validation is a hazard for out-of-tree I2S drivers that retain the configuration on the unconfigure path. Builds without CONFIG_USERSPACE are unaffected, since the verifier is not used. The fix zeroes config.mem_slab and config.block_size on the unconfigure path so the driver can never receive an unvalidated pointer, while still allowing a stream to be unconfigured by a caller that does not own a memory slab, as the API documents.

🔗 แหล่งอ้างอิง