CVE-2026-53237

What it actually does

This is a Linux kernel NULL pointer dereference in the Marvell EBU GPIO driver suspend/resume path. During system suspend or resume, the driver calls PWM-related suspend/resume logic for every GPIO bank, even when a bank has no PWM capability and its mvpwm pointer is NULL. On affected Marvell Armada/EBU-based systems, this can dereference a NULL pointer while accessing the PWM blink_select register path, causing a kernel oops/panic and denial of service. The impact is availability-focused; the available information does not indicate code execution, privilege escalation, or data disclosure.

Why it matters to the business

Affected embedded, appliance, networking, storage, industrial, or IoT systems using vulnerable Linux kernels on Marvell Armada/EBU hardware may crash during suspend or resume operations. This can cause service outages, device reboots, failed power-management workflows, loss of connectivity, and operational disruption, particularly for unattended or remotely managed devices. The vulnerability is not listed in CISA KEV, has no known exploit maturity, and has a low EPSS score, so broad internet-scale exploitation is currently unlikely; however, environments that rely on suspend/resume or expose power-management controls should treat it as an availability reliability issue.

How an attack unfolds

An attacker first needs a way to trigger a suspend or resume transition on an affected Linux system, such as local shell access with permission to write to power-management interfaces, access to a management function that initiates sleep/resume, or control over software that invokes system suspend. When the system enters the suspend/resume device power-management flow, the kernel iterates over GPIO banks and invokes the Marvell EBU GPIO suspend handler. For GPIO banks without PWM support, the driver still reaches PWM suspend/resume handling with a NULL mvpwm structure. The kernel then attempts to access a field through that NULL pointer, producing an oops or panic. The result is a denial of service through system crash, reboot, or failed power-state transition.

How to fix it

Apply a Linux kernel update from the operating system, appliance, board-support-package, or device vendor that includes the mvebu GPIO fix adding a NULL check before PWM suspend/resume handling. If no packaged fixed version is available, backport the upstream kernel patch for the mvebu GPIO driver that checks mvchip->mvpwm before calling mvebu_pwm_suspend() or mvebu_pwm_resume(). As interim mitigation, restrict who can trigger suspend/resume, disable unnecessary suspend states on affected devices, remove or lock down exposed power-management controls, and avoid operational workflows that put affected systems into suspend until patched. For embedded products, update firmware images and validate the fix against the exact hardware device tree and GPIO bank configuration.

How to confirm the fix worked

Confirm the running kernel or firmware contains the patched mvebu GPIO driver logic that skips PWM suspend/resume operations when mvchip->mvpwm is NULL. Validate by reviewing vendor advisories, package changelogs, kernel commit history, or source code for the added NULL check. On representative affected hardware, perform controlled suspend and resume testing while monitoring the console, dmesg, and persistent kernel logs for oops/panic output. A fixed system should complete suspend/resume without NULL pointer dereference messages referencing mvebu_gpio_suspend, mvebu_pwm_suspend, regmap_read, or regmap_mmio_read. Also confirm that unprivileged users and remote management paths cannot trigger suspend unless explicitly required.

Typical attack path

1. Identify or gain access to a Linux system running an affected kernel on Marvell Armada/EBU hardware using the mvebu GPIO driver.
2. Obtain the ability to initiate suspend or resume, either through local privileges, exposed management functionality, or an application/service that can request system sleep.
3. Trigger a suspend operation, commonly through Linux power-management interfaces such as /sys/power/state or an equivalent system management API.
4. During device suspend or resume, the vulnerable mvebu GPIO path processes a GPIO bank without PWM support.
5. The kernel dereferences a NULL mvpwm pointer while accessing PWM state, causing a kernel oops/panic.
6. The device becomes unavailable, reboots, or requires manual recovery depending on kernel panic and watchdog configuration.

How to detect it

Look for evidence of kernel crashes or oops events occurring during suspend or resume on Marvell Armada/EBU systems. Relevant log sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, serial console logs, pstore/ramoops records, crash dumps, watchdog reset logs, and device-management event logs. Search for NULL pointer dereference messages that include mvebu GPIO suspend/resume functions, regmap reads, or writes to /sys/power/state shortly before the crash. Correlate events where a user, script, management daemon, or remote-management service initiated suspend with immediate kernel oops/panic output. Because this flaw produces a kernel availability failure rather than a persistent implant, detection is primarily based on crash artifacts, power-state transition logs, and reboot/reset timing rather than malware indicators.

• Unable to handle kernel NULL pointer dereference at virtual address 00000020
• Internal error: Oops: 815
• PC is at regmap_mmio_read
• LR is at regmap_mmio_read
• regmap_mmio_read from _regmap_bus_reg_read
• _regmap_read from regmap_read
• regmap_read from mvebu_gpio_suspend
• mvebu_gpio_suspend from dpm_run_callback
• dpm_suspend_start from suspend_devices_and_enter
• suspend_devices_and_enter from pm_suspend
• pm_suspend from state_store
• state_store from kernfs_fop_write_iter
• /sys/power/state
• mvebu_gpio_suspend
• mvebu_pwm_suspend
• mvebu_pwm_resume
• Hardware name: Marvell Armada 370/XP

What your security team should do

• Inventory Linux-based devices using Marvell Armada/EBU platforms or the mvebu GPIO driver, especially embedded appliances and custom firmware builds.
• Prioritize patching systems that use suspend/resume, are remotely managed, or provide any interface that could trigger power-state transitions.
• Obtain vendor kernel, firmware, or BSP updates containing the mvebu GPIO NULL-check fix; if unavailable, request a vendor hotfix or backport the upstream patch.
• Until patched, restrict access to /sys/power/state, system suspend commands, and remote management functions that can initiate sleep or resume operations.
• Review kernel logs for historical crashes around suspend/resume to determine whether the issue has already caused outages.
• For appliances and embedded products, add suspend/resume regression testing to release validation for all supported hardware variants.
• Ensure watchdog and remote recovery mechanisms are configured so affected devices can recover automatically from kernel panic or failed resume events.