CVE-2023-52449

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mtd: Fix gluebi NULL pointer dereference caused by ftl notifier<br /> <br /> If both ftl.ko and gluebi.ko are loaded, the notifier of ftl<br /> triggers NULL pointer dereference when trying to access<br /> ‘gluebi-&gt;desc’ in gluebi_read().<br /> <br /> ubi_gluebi_init<br /> ubi_register_volume_notifier<br /> ubi_enumerate_volumes<br /> ubi_notify_all<br /> gluebi_notify nb-&gt;notifier_call()<br /> gluebi_create<br /> mtd_device_register<br /> mtd_device_parse_register<br /> add_mtd_device<br /> blktrans_notify_add not-&gt;add()<br /> ftl_add_mtd tr-&gt;add_mtd()<br /> scan_header<br /> mtd_read<br /> mtd_read_oob<br /> mtd_read_oob_std<br /> gluebi_read mtd-&gt;read()<br /> gluebi-&gt;desc - NULL<br /> <br /> Detailed reproduction information available at the Link [1],<br /> <br /> In the normal case, obtain gluebi-&gt;desc in the gluebi_get_device(),<br /> and access gluebi-&gt;desc in the gluebi_read(). However,<br /> gluebi_get_device() is not executed in advance in the<br /> ftl_add_mtd() process, which leads to NULL pointer dereference.<br /> <br /> The solution for the gluebi module is to run jffs2 on the UBI<br /> volume without considering working with ftl or mtdblock [2].<br /> Therefore, this problem can be avoided by preventing gluebi from<br /> creating the mtdblock device after creating mtd partition of the<br /> type MTD_UBIVOLUME.