CVE-2026-46190

What it actually does

This is a local Linux kernel out-of-bounds read in the SPI NOR MTD debugfs code path. The vulnerable function passes the byte size of an array of string pointers instead of the number of array elements, causing the bounds check in the flag-printing helper to accept indexes beyond the real array length. If a SPI NOR flag bit maps to one of those out-of-range indexes, reading the relevant debugfs entry can cause the kernel to read adjacent memory as if it were a string pointer. Depending on memory layout and kernel hardening, this may disclose kernel memory through debugfs output or trigger a kernel fault, Oops, or denial of service. Exploitation requires local access and access to the relevant debugfs interface, and typically requires a system with SPI NOR/MTD support and exposed debugfs entries.

Why it matters to the business

The main operational risk is that a local user or compromised low-privilege process could crash affected Linux systems or potentially expose sensitive kernel memory. This is most relevant for embedded, appliance, industrial, IoT, and platform devices that use SPI NOR flash and expose debugfs for diagnostics. The issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has very low EPSS, and has no known public exploit maturity, so broad internet-scale exploitation is unlikely; however, systems with untrusted local users, shared access, or exposed diagnostic shells should treat it as a meaningful local privilege-adjacent stability and information-disclosure risk.

How an attack unfolds

An attacker first needs local code execution or shell access on an affected Linux system. They then determine whether debugfs is mounted, whether SPI NOR MTD debugfs entries exist, and whether their user context can read them. By reading the SPI NOR parameters debugfs file, the attacker triggers spi_nor_params_show(), which calls spi_nor_print_flags() with an inflated length for the names array. If the device flags include bits beyond the actual string-name array but within the incorrect byte-sized bound, the kernel reads past the end of the array. The resulting behavior depends on adjacent memory: the read may print unintended kernel data, dereference an invalid pointer and crash the kernel, or produce diagnostic errors under memory sanitizers. The attack is local and hardware/configuration-dependent, not a remote network attack.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix changing the array length calculation to use ARRAY_SIZE() for the SPI NOR flag-name array. No exact fixed package versions were provided, so use the relevant distribution, appliance vendor, or kernel-maintainer advisory for the corrected kernel version. Where immediate patching is not possible, reduce exposure by disabling or unmounting debugfs in production, building kernels without CONFIG_DEBUG_FS where feasible, restricting permissions on /sys/kernel/debug, preventing untrusted users or containers from accessing host debugfs, and limiting local shell access on devices using SPI NOR flash. Treat mitigation as temporary; the durable fix is a patched kernel.

How to confirm the fix worked

Confirm the running kernel is a vendor build containing the SPI NOR debugfs fix for spi_nor_params_show(). Validate using kernel package changelogs, distribution security advisories, or source inspection showing ARRAY_SIZE(snor_f_names) is used instead of sizeof(snor_f_names) when calling spi_nor_print_flags(). On production systems, also verify debugfs is not unnecessarily mounted or is inaccessible to untrusted users. For exposure validation, check for /sys/kernel/debug availability and SPI NOR debugfs entries, but avoid running untrusted proof-of-concept code on production devices because the failure mode can include kernel crashes.

Typical attack path

1. Gain local access to an affected Linux host, device, container with host debugfs access, or diagnostic shell.
2. Check whether debugfs is mounted, commonly under /sys/kernel/debug.
3. Identify SPI NOR MTD debugfs entries exposed by the kernel.
4. Read the SPI NOR parameters/debugfs output that invokes spi_nor_params_show().
5. Trigger an out-of-bounds read when SPI NOR flags reference indexes beyond the actual flag-name array.
6. Use the result to obtain unintended kernel memory disclosure or to cause a kernel Oops, panic, or device/service interruption.

How to detect it

There are no reliable network indicators for this local kernel issue. To determine whether exploitation may already have occurred, review kernel logs, crash dumps, and audit telemetry for reads of SPI NOR debugfs files followed by kernel Oops, panic, KASAN, slab-out-of-bounds, page fault, or general protection fault events. Useful log sources include journald, dmesg, /var/log/kern.log, /var/log/messages, auditd, eBPF/file-access telemetry, EDR Linux sensor events, and crash dump infrastructure such as kdump. If audit rules were in place, look for open/read activity under /sys/kernel/debug related to spi-nor or MTD by non-administrative users, service accounts, containers, or unexpected interactive sessions. Correlate suspicious debugfs access with local logins, privilege changes, shell history, container escapes, and device instability. Absence of logs does not prove absence of exploitation because debugfs reads are often not audited by default.

• /sys/kernel/debug/spi-nor/
• spi_nor_params_show
• spi_nor_print_flags
• BUG: KASAN: slab-out-of-bounds
• BUG: KASAN: global-out-of-bounds
• kernel BUG at drivers/mtd/spi-nor/debugfs.c
• general protection fault
• Unable to handle kernel paging request
• Oops:
• Kernel panic - not syncing

What your security team should do

• Prioritize patching Linux kernels on embedded, appliance, IoT, industrial, and platform devices that use SPI NOR flash or expose MTD debugfs diagnostics.
• Inventory systems where debugfs is mounted in production and restrict or remove it unless explicitly required.
• Ensure containers and low-privilege users cannot access host /sys/kernel/debug.
• Monitor kernel logs for Oops, panic, KASAN, or general protection fault messages involving SPI NOR debugfs functions.
• Ask vendors of managed appliances and firmware images for confirmation that their kernel includes the SPI NOR debugfs ARRAY_SIZE fix.
• Because KEV is false, ransomware usage is not reported, EPSS is very low, and exploit maturity is none, handle through normal kernel update cycles unless local untrusted access or exposed debug interfaces increase risk.