ทีมงานจากมหาวิทยาลัยมินนิโซตาได้เปิดเผยรายละเอียดเกี่ยวกับการเปลี่ยนแปลงที่เป็นอันตรายที่ถูกส่งไป

หลังจากจดหมายเปิดผนึกขอโทษ กลุ่มนักวิจัยจากมหาวิทยาลัยมินนิโซตา ซึ่งการยอมรับการเปลี่ยนแปลงเคอร์เนล Linux ถูกบล็อกโดย Greg Croah-Hartman ได้เปิดเผยข้อมูลโดยละเอียดเกี่ยวกับแพตช์ที่ส่งไปยังผู้พัฒนาเคอร์เนลและการติดต่อกับผู้ดูแล ที่เกี่ยวข้องกับแพทช์เหล่านี้

เป็นที่น่าสังเกตว่าแพตช์ที่มีปัญหาทั้งหมดถูกปฏิเสธตามความคิดริเริ่มของผู้ดูแล ไม่ใช่แพตช์เดียวที่ได้รับการอนุมัติ ข้อเท็จจริงนี้ทำให้ชัดเจนว่าเหตุใด Greg Croah-Hartman จึงกระทำการที่รุนแรง เนื่องจากยังไม่ชัดเจนว่านักวิจัยจะทำอย่างไรหากแผ่นแปะได้รับการอนุมัติจากผู้ดูแล เมื่อมองย้อนกลับไป พวกเขาอ้างว่าตั้งใจที่จะรายงานข้อผิดพลาดและจะไม่อนุญาตให้แพตช์ไปที่ Git แต่ก็ไม่ชัดเจนว่าพวกเขาจะทำอะไรจริงๆ และไปได้ไกลแค่ไหน

รวมในเดือนสิงหาคม 2020 จากที่อยู่ที่ไม่ระบุชื่อ [ป้องกันอีเมล] и [ป้องกันอีเมล] (จดหมายจากเจมส์ บอนด์) มีการส่งแพทช์ห้ารายการ: สองรายการที่ถูกต้อง (1, 2) และสามรายการที่มีข้อผิดพลาดที่ซ่อนอยู่ (1, 2, 3) ทำให้เกิดเงื่อนไขสำหรับช่องโหว่ แต่ละแพตช์มีโค้ดเพียง 1-4 บรรทัด แนวคิดหลักเบื้องหลังแพตช์ที่ผิดพลาดคือการแก้ไขหน่วยความจำรั่วอาจสร้างสภาวะช่องโหว่ที่ว่างเป็นสองเท่า หนึ่งสัปดาห์ต่อมา ข้อมูลถูกส่งไปยังนักพัฒนาเคอร์เนลพร้อมข้อเสนอเพื่อหารือเกี่ยวกับความเป็นไปได้ในการส่งเสริมช่องโหว่ภายใต้หน้ากากของการแก้ไขเล็กน้อยสำหรับหน่วยความจำรั่ว แต่ไม่มีการพูดถึงความพยายามครั้งก่อนในการส่งแพตช์ที่เป็นอันตราย

แพตช์ที่มีปัญหาครั้งแรกได้แก้ไขหน่วยความจำรั่วโดยเพิ่มการเรียกไปที่ kfree() ก่อนที่จะส่งคืนการควบคุมในกรณีที่เกิดข้อผิดพลาด แต่สร้างเงื่อนไขสำหรับการเข้าถึงพื้นที่หน่วยความจำหลังจากที่ถูกปล่อยให้ว่าง (ใช้งานหลังเลิกใช้งาน) แพทช์นี้ถูกปฏิเสธโดยผู้ดูแล (Jiri Slaby) ซึ่งระบุปัญหาและชี้ให้เห็นว่าเมื่อปีที่แล้วมีคนพยายามเสนอการเปลี่ยนแปลงที่คล้ายกันและได้รับการยอมรับในตอนแรก แต่ถูกละทิ้งไปหลังจากระบุเงื่อนไขสำหรับช่องโหว่ > p2 = p1[n] = kmalloc_array(64, ขนาดของ(u16), GFP_KERNEL); > - ถ้า (!p2) ส่งคืน -ENOMEM; > + ถ้า (!p2) { > + kfree(p1); > + กลับ -ENOMEM; > + }

แพตช์ที่สองยังมีเงื่อนไขสำหรับปัญหาการใช้งานหลังใช้งานฟรี ผู้ดูแลไม่ยอมรับแพตช์ที่ระบุ (แดน คาร์เพนเตอร์) ซึ่งปฏิเสธแพตช์เนื่องจากปัญหาอื่นกับ list_add_tail แต่ไม่ได้สังเกตว่าตัวชี้ "chdev" สามารถปล่อยได้ในฟังก์ชัน put_device ซึ่งใช้ด้านล่างในการเรียก dev_err(&chdev ->dev..) อย่างไรก็ตาม แพตช์ดังกล่าวไม่ได้รับการยอมรับ แม้ว่าด้วยเหตุผลที่ไม่เกี่ยวข้องกับช่องโหว่ก็ตาม ถ้า (ret < 0) { + put_device(&chdev->dev); dev_err(&chdev->dev, DRV_NAME ": kfifo_alloc ล้มเหลว\n"); ret = -ENOMEM; ไปที่ err_fifo;

แพตช์ที่สามก็ไม่ได้รับการยอมรับจากผู้ดูแล (Miquel Raynal) เนื่องจากข้อผิดพลาดอื่นที่ไม่เกี่ยวข้องกับช่องโหว่ (การเรียกสองครั้งเพื่อใส่ pdev) if (!window->virt) { printk(KERN_ERR MOD_NAME ": ioremap(%08lx, %08lx) failed\n", window->phys, window->size); + pci_dev_put(pdev); ออกไป; } ... ถ้า (!map) { printk(KERN_ERR MOD_NAME ": kmalloc failed"); + pci_dev_put(pdev); ออกไป; } memset(แผนที่, 0, ขนาดของ(*แผนที่)); ... ถ้า (mtd_device_register(map->mtd, NULL, 0)) { map_destroy(map->mtd); แผนที่->mtd = NULL; + pci_dev_put(pdev); ออกไป; }

สิ่งที่น่าสนใจคือ ในตอนแรกสันนิษฐานว่าแพตช์ 4 จาก 5 มีปัญหา แต่นักวิจัยเองก็ทำผิดพลาด และในแพตช์เดียวที่เป็นปัญหา ในความเห็นของพวกเขา มีการเสนอการแก้ไขที่ถูกต้อง โดยไม่มีเงื่อนไขที่คาดหวังสำหรับการใช้หน่วยความจำหลังจากเกิดว่างขึ้น ข้อผิดพลาด = pci_request_mem_regions (pdev, nitrox_driver_name); ถ้า (ผิดพลาด) { pci_disable_device(pdev); + dev_err(&pdev->dev, “ไม่สามารถขอขอบเขต mem!\n”); กลับผิดพลาด; }

ที่มา: opennet.ru