CVE-2026-53343

What it actually does

This Linux kernel issue affects 32-bit ARM systems built with CONFIG_KASAN_VMALLOC and CONFIG_VMAP_STACK. During context switching, the kernel performs a dummy read from KASAN VMAP stack shadow memory using a word load instruction even though KASAN shadow memory is byte-granular and may be unaligned. On ARMv5-class processors that fault on unaligned word loads, this can trigger an alignment exception in __switch_to(), causing a kernel crash or preventing the system from completing boot. The practical technical impact is denial of service on affected ARM configurations rather than privilege escalation or data exposure.

Why it matters to the business

Organizations running affected ARM Linux kernels on susceptible hardware may experience failed boots, kernel panics, or unstable systems after deploying a vulnerable kernel build or enabling the relevant hardening/debug options. This can disrupt embedded, appliance, industrial, lab, or legacy ARM deployments. The low EPSS score, lack of known exploitation, and absence from CISA KEV indicate low immediate threat of active attacker use, but operational risk remains for systems that match the affected configuration.

How an attack unfolds

This flaw is primarily triggered by kernel execution under a specific build and hardware configuration rather than by a conventional remote exploit. When an affected ARMv5 system boots or switches tasks, the kernel enters __switch_to() and attempts to touch the KASAN VMAP stack shadow mapping. Because the instruction uses an unaligned word load against byte-addressed shadow memory, processors that do not tolerate unaligned word loads raise an alignment exception. The exception can occur early enough to prevent init from running, resulting in a boot-time denial of service. An attacker would generally need a way to cause deployment or activation of the vulnerable kernel configuration on susceptible hardware; there is no indication of a standalone remote exploitation path.

How to fix it

Upgrade to a Linux kernel that includes the fix changing the KASAN VMAP stack shadow dummy access from a word load to a byte load. If a fixed kernel package is not yet available from the relevant vendor or distribution, apply the upstream patch associated with the ARM entry fix labeled 'ARM: 9475/1: entry: use byte load for KASAN VMAP stack shadow' or obtain a backported vendor kernel. As a temporary mitigation for non-production or specialized builds, avoid running susceptible ARMv5 systems with both CONFIG_KASAN_VMALLOC and CONFIG_VMAP_STACK enabled until the patch is applied. Production systems generally should not run KASAN-enabled kernels unless explicitly required for diagnostics or testing.

How to confirm the fix worked

Confirm that the running kernel includes the ARM entry fix that uses a byte load for KASAN VMAP stack shadow access. Validate package status through the operating system vendor's kernel changelog or source tree, and confirm that any custom kernels have the patched entry code. On affected ARM test hardware, boot the patched kernel with CONFIG_KASAN_VMALLOC and CONFIG_VMAP_STACK enabled and verify that the system reaches userspace without alignment exceptions in __switch_to(). Review kernel configuration using /proc/config.gz, boot config artifacts, or build metadata to determine whether CONFIG_KASAN_VMALLOC=y and CONFIG_VMAP_STACK=y are present.

Typical attack path

1. Identify a target running a 32-bit ARM Linux kernel on hardware that faults on unaligned word loads, such as ARMv5-class platforms.
2. Confirm or induce a kernel configuration with CONFIG_KASAN_VMALLOC and CONFIG_VMAP_STACK enabled.
3. Cause the affected kernel to boot or trigger normal task switching behavior.
4. The kernel executes __switch_to() and performs an unaligned word load from KASAN VMAP stack shadow memory.
5. The processor raises an alignment exception, leading to kernel panic, boot failure, or system denial of service.

How to detect it

Look for evidence of kernel crashes or boot failures on ARM systems after deployment of kernels with KASAN VMAP stack support. Primary log sources include serial console output, dmesg, journalctl kernel logs, persistent crash logs, pstore/ramoops, kdump/vmcore analysis, bootloader console captures, and embedded device watchdog reset records. Indicators include alignment exceptions, unhandled faults, kernel panics, or early boot failures referencing __switch_to(), KASAN VMAP stack shadow access, VMAP_STACK, or CONFIG_KASAN_VMALLOC. Because this issue is not known to have a conventional attacker-driven exploit path, detection should focus on operational artifacts of triggering rather than intrusion indicators. If systems unexpectedly reboot or fail after a kernel rollout, correlate the event time with kernel package changes, configuration changes, or enabling KASAN-related options.

• __switch_to()
• Alignment trap
• alignment exception
• Unhandled fault: alignment exception
• Internal error: Oops - undefined instruction
• Kernel panic - not syncing
• CONFIG_KASAN_VMALLOC=y
• CONFIG_VMAP_STACK=y
• KASAN VMAP stack shadow
• VMAP_STACK
• ARM: 9475/1: entry: use byte load for KASAN VMAP stack shadow
• ARM: 9430/1: entry: Do a dummy read from VMAP shadow
• /proc/config.gz
• /sys/fs/pstore/
• /var/crash/
• /var/log/kern.log
• journalctl -k

What your security team should do

• Prioritize remediation for 32-bit ARM or embedded systems using custom, test, debug, or KASAN-enabled kernels, especially ARMv5-class hardware.
• Inventory Linux kernel builds for CONFIG_KASAN_VMALLOC and CONFIG_VMAP_STACK on ARM platforms to determine real exposure.
• Obtain fixed kernels from the relevant distribution, appliance vendor, board support package maintainer, or upstream stable kernel tree when available.
• For custom kernel pipelines, ensure the ARM entry patch is backported before enabling KASAN VMAP stack testing on susceptible hardware.
• Monitor boot and kernel logs after kernel upgrades for alignment exceptions, kernel panics, or crashes referencing __switch_to().
• Treat this as primarily an operational reliability issue unless additional exploitability information emerges; current EPSS is low and it is not listed in CISA KEV.