CVE-2023-52449

What it actually does

NULL pointer dereference in gluebi_read() when ftl notifier triggers mtd block device registration without prior gluebi_get_device() initialization of gluebi->desc.

Why it matters to the business

Kernel panic or denial of service on Linux systems using UBI volumes with both ftl and gluebi modules loaded, disrupting storage or embedded device operations.

How an attack unfolds

Attacker loads ftl.ko and gluebi.ko, causes UBI volume enumeration to invoke the notifier chain, leading ftl_add_mtd to call mtd_read without gluebi device setup and triggering the dereference.

How to fix it

Update Linux kernel to commit aeba358bcc8ffddf9b4a9bd0e5ec9eb338d46022 or later stable release; avoid loading both ftl and gluebi modules together; run JFFS2 directly on UBI volumes without mtdblock.

How to confirm the fix worked

Verify kernel source contains the fix commit; reproduce by loading both modules and creating MTD_UBIVOLUME partition; confirm no crash occurs during ftl_add_mtd path.

Typical attack path

1. Load ftl.ko and gluebi.ko modules
2. Trigger UBI volume enumeration or MTD partition creation of type MTD_UBIVOLUME
3. ftl notifier calls scan_header which performs mtd_read
4. gluebi_read dereferences uninitialized gluebi->desc pointer
5. Kernel crashes with NULL pointer dereference

How to detect it

Search kernel logs and dmesg for NULL pointer dereference in gluebi_read or mtd paths involving ftl and gluebi; inspect module loading history for concurrent ftl.ko and gluebi.ko presence.

What your security team should do

• Apply the referenced kernel commit immediately on affected systems
• Audit module load configurations to prevent simultaneous ftl and gluebi usage
• Monitor kernel logs for mtd/gluebi related oops messages
• Test storage subsystem stability after patching