A Linux kernel vulnerability has recently been addressed that could lead to unwanted consequences and system crashes due to improper handling of certain memory allocations in the Linux kernel mtd module. In an effort to ensure system security and stability, developers have implemented a fix for the NULL pointer dereference issue exhibited by gluebi, as detailed in the following explanatory text.

The specific issue that developers have addressed is a NULL pointer dereference that could be triggered by the ftl notifier when both the ftl.ko and gluebi.ko modules are loaded. This situation could result in a failure to access gluebi->desc in the gluebi_read() function, as outlined by the following code excerpt [1]:

ubi_gluebi_init
  ubi_register_volume_notifier
    ubi_enumerate_volumes
      ubi_notify_all
        gluebi_notify    nb->notifier_call()
          gluebi_create
            mtd_device_register
              mtd_device_parse_register
                add_mtd_device
                  blktrans_notify_add   not->add()
                    ftl_add_mtd         tr->add_mtd()
                      scan_header
                        mtd_read
                          mtd_read_oob
                            mtd_read_oob_std
                              gluebi_read   mtd->read()
                                gluebi->desc - NULL

Complete instructions for reproducing this issue can be found at Link [1].

In a normal operation, the gluebi->desc value would be obtained in the gluebi_get_device() function, and subsequently, the gluebi_read() function accesses gluebi->desc. However, the ftl_add_mtd() process does not execute gluebi_get_device() in advance, which leads to a NULL pointer dereference.

It is important to note that the primary purpose for the gluebi module is to run jffs2 on the UBI volume without considering interactions with the ftl or mtdblock modules [2]. As such, the problem can be circumvented by preventing gluebi from creating the mtdblock device after creating an mtd partition of the type MTD_UBIVOLUME.

With the application of this fix, Linux kernel systems will be better protected and more stable in handling memory resources, even when multiple modules are loaded simultaneously. This fix ensures that potential exploits and crashes are avoided, and system security remains intact.

For more details and the latest updates on this vulnerability and its corresponding fix, please refer to the original references:

[1]: Detailed Reproduction Information
[2]: Purpose of Gluebi Module

Timeline

Published on: 02/22/2024 17:15:08 UTC
Last modified on: 03/18/2024 18:38:16 UTC