CVE-2026-46285

What it actually does

This is a Linux kernel use-after-free flaw in the MTD DiskOnChip G3 driver. During docg3_release(), the driver saves a pointer to a docg3 structure, calls cleanup routines that free that structure, and then dereferences the freed pointer afterward. In practical terms, triggering the vulnerable release path can cause kernel memory corruption, most likely resulting in a kernel crash or denial of service. Depending on kernel configuration, heap behavior, hardware presence, and attacker control over adjacent allocations, privilege escalation may be theoretically possible, but no public exploit maturity is currently indicated and EPSS is very low.

Why it matters to the business

Systems that load or use the affected Linux kernel docg3 MTD driver could experience crashes or instability if the vulnerable cleanup path is triggered. The most likely business consequence is service interruption on specialized Linux or embedded systems that use DiskOnChip G3 flash hardware or include the driver in custom kernels. This vulnerability is not listed in CISA KEV, is not currently associated with ransomware use, and has low predicted exploitation likelihood, so remediation should be handled through normal kernel patching unless the driver is enabled on critical production or embedded devices.

How an attack unfolds

An attacker would first need access to a system where the affected Linux kernel includes and exposes the docg3 MTD driver. They would then need a way to cause the driver release path to run, such as device removal, driver unload, or another operation that invokes docg3_release(). The vulnerable code frees the docg3 object while cleaning up device floors, then later accesses the same freed object through docg3->cascade->bch. If the freed memory has not been reused, this may produce an immediate kernel fault; if memory has been reallocated in a favorable way, it could create memory corruption conditions. In most realistic scenarios, exploitation would manifest as a local denial of service rather than reliable remote code execution.

How to fix it

Apply a Linux kernel update that includes the upstream fix for the docg3_release() use-after-free. If fixed package versions are provided by the Linux distribution or appliance vendor, upgrade to those versions or later. Where immediate patching is not possible, reduce exposure by disabling or removing the docg3 MTD driver if it is not required, preventing untrusted users from loading or unloading kernel modules, and restricting access to MTD device management operations. For custom kernels, backport the patch that replaces the post-free docg3->cascade->bch access with direct use of the existing cascade->bch reference in drivers/mtd/devices/docg3.c.

How to confirm the fix worked

Confirm the running kernel contains the vendor or upstream patch for drivers/mtd/devices/docg3.c. Validate exposure by checking whether the docg3 driver is built into the kernel or available as a module, and whether it is loaded at runtime. On Linux systems, review kernel package changelogs, vendor advisories, or source diffs for the docg3_release() fix. If the module is not required, confirm it is absent, unloaded, or blocklisted. After remediation, reboot into the patched kernel and verify the active kernel version with uname -r, package manager metadata, and module information rather than only confirming that packages were installed.

Typical attack path

1. Identify a Linux system running a kernel build that includes the MTD DiskOnChip G3 docg3 driver.
2. Confirm the driver is loaded, reachable, or associated with present/emulated MTD hardware.
3. Obtain local access or sufficient privileges to trigger driver teardown, device release, module unload, or an equivalent cleanup path.
4. Trigger docg3_release() so the driver frees the docg3 structure during floor cleanup.
5. Cause the kernel to dereference the freed pointer after cleanup, resulting in a crash or memory corruption condition.
6. Optionally attempt heap shaping before the release path to influence reuse of the freed kernel allocation, if pursuing advanced exploitation.

How to detect it

To determine whether this was already triggered, review kernel logs, crash dumps, pstore records, systemd journal entries, netconsole output, and centralized syslog for crashes or memory-safety reports involving the docg3 MTD driver. Useful sources include /var/log/kern.log, /var/log/messages, /var/log/syslog, journalctl -k output, /sys/fs/pstore contents, kdump vmcore files, and kernel panic/oops records. Look for KASAN use-after-free reports, general protection faults, null or invalid pointer dereferences, call traces containing docg3_release() or doc_release_device(), and crashes occurring during MTD device removal, module unload, shutdown, or reboot. Because no public exploit indicators or threat actors are currently associated with this issue, detection should focus on kernel crash artifacts and suspicious local administrative actions such as unexpected module unloads, device removal operations, or repeated attempts to manipulate MTD devices.

• BUG: KASAN: use-after-free
• use-after-free in docg3_release
• docg3_release
• doc_release_device
• drivers/mtd/devices/docg3.c
• docg3
• MTD DiskOnChip G3
• Unable to handle kernel paging request
• general protection fault
• kernel BUG at drivers/mtd/devices/docg3.c
• Call Trace:
• /sys/fs/pstore
• /var/crash
• /proc/modules
• modprobe docg3
• rmmod docg3

What your security team should do

• Prioritize patching systems that use MTD flash storage, embedded Linux builds, custom kernels, or hardware platforms that may load the docg3 driver.
• Inventory kernels where CONFIG_MTD_DOCG3 is enabled or where a docg3 kernel module is present.
• If the driver is unnecessary, disable, remove, or blocklist it as a compensating control.
• Restrict module loading and device-management privileges to trusted administrators only.
• Monitor kernel logs for use-after-free, KASAN, oops, panic, or crash messages referencing docg3, docg3_release, or doc_release_device.
• For embedded or appliance fleets, request fixed firmware or kernel builds from the vendor if direct kernel patching is not operationally feasible.
• Treat unexpected kernel crashes involving MTD or docg3 code as potential exploitation or reliability incidents and preserve crash dumps for analysis.