CVE-2026-53296

What it actually does

This is a Linux kernel use-after-free condition in the mailbox-test driver’s probe error path. If the driver obtains one or more mailbox channels and then later fails during probing, previously acquired channels were not released before the devm-managed client structure was removed. That can leave mailbox channel state referencing freed client memory, creating a potential kernel use-after-free if the stale channel/client reference is accessed afterward. Depending on kernel configuration, hardware/platform exposure, and attacker ability to trigger probe failure and subsequent mailbox activity, impact could range from resource leakage and kernel instability to denial of service or, in less likely scenarios, privilege escalation through kernel memory corruption.

Why it matters to the business

The most likely operational impact is instability or crashes on Linux systems that include and exercise the mailbox-test driver, particularly embedded, SoC, development, or test platforms using mailbox infrastructure. Exploitation is not currently known in the wild, it is not listed in CISA KEV, and the EPSS score is very low, so broad internet-scale risk is limited. However, kernel memory-safety issues should still be remediated through normal kernel update cycles because a successful exploit could disrupt systems or potentially compromise host integrity.

How an attack unfolds

An attacker would first need access to a system where the vulnerable Linux kernel includes the mailbox-test driver and where the driver can be caused to bind, probe, fail partway through initialization, and leave previously acquired mailbox channels behind. The attacker would attempt to trigger or influence a probe error after one or more channels have been obtained. Because the client object is devm-managed, the client structure is then removed while mailbox channel state may still reference it. The attacker would then try to cause later mailbox activity, driver cleanup, rebinding, or channel operations that dereference the stale client pointer. In a practical attack, this is more likely to produce a kernel crash or warning than reliable code execution, especially without a known public exploit or predictable heap-shaping primitive. Exploitation is expected to require local, privileged, or platform-specific access rather than remote unauthenticated access.

How to fix it

Apply a Linux kernel update that includes the upstream fix for the mailbox-test probe error path, which releases previously obtained mailbox channels when probe fails. Because no specific downstream package or fixed version was provided, use the fixed kernel version supplied by the operating system, appliance, SoC vendor, or kernel distribution maintainer. Where immediate patching is not possible, reduce exposure by disabling or not loading the mailbox-test driver if it is not required, removing it from custom kernel builds, restricting privileged users who can bind/unbind platform drivers or manipulate debug/test interfaces, and limiting access to debugfs/sysfs controls that could influence driver probing. Production systems should generally avoid enabling test-only kernel drivers unless explicitly required.

How to confirm the fix worked

Confirm the running kernel includes the vendor or upstream patch for the mailbox-test channel cleanup issue. Validate package status with the operating system’s kernel package manager and confirm the active booted kernel is the updated version, not merely installed. On custom kernels, review the mailbox-test driver source or patch history to confirm the probe error path frees any previously obtained mailbox channels before the devm-managed client is released. Check whether the module is present or loaded using commands such as `lsmod`, `modinfo mailbox-test`, and kernel configuration review for mailbox test driver support. After remediation, exercise relevant platform boot/probe paths and confirm there are no kernel warnings, KASAN reports, mailbox-test probe cleanup errors, or crashes in `dmesg` or system journal logs.

Typical attack path

1. Identify a Linux system running a vulnerable kernel build with the mailbox-test driver available or loaded.
2. Determine whether mailbox-test can be bound, unbound, reprobed, or influenced through platform device configuration, debug/test interfaces, or privileged local control paths.
3. Trigger a driver probe sequence that successfully obtains mailbox channels and then fails before probe completion.
4. Allow the devm-managed client structure to be freed while mailbox channel state still references it.
5. Trigger subsequent mailbox activity, cleanup, rebinding, or channel access that dereferences the stale client pointer.
6. Attempt to turn the resulting use-after-free into a kernel crash, denial of service, or potentially controlled kernel memory corruption.

How to detect it

There are no public, vulnerability-specific exploitation indicators and exploitation is not known to be active. Detection should focus on signs that the vulnerable driver was present and that the relevant failure path may have been exercised. Review kernel logs from `dmesg`, `journalctl -k`, persistent syslog, crash dumps, and EDR kernel telemetry for mailbox-test probe failures, repeated driver bind/unbind activity, KASAN or KFENCE use-after-free reports, kernel Oops messages, panics, soft lockups, or unexplained reboots. On systems with debug or test interfaces enabled, review administrative command history and audit logs for module loading/unloading, writes to `/sys/bus/platform/drivers/*/bind` or `/sys/bus/platform/drivers/*/unbind`, mounting or use of debugfs, and manipulation of mailbox-related platform devices. Because likely exploitation is local or platform-specific, correlate kernel instability with privileged local activity, recent kernel module operations, device-tree changes, or test automation that exercises mailbox devices.

• mailbox-test
• mailbox_test
• KASAN: use-after-free
• BUG: KASAN: use-after-free
• KFENCE: use-after-free
• kernel BUG at drivers/mailbox/mailbox-test.c
• drivers/mailbox/mailbox-test.c
• Oops:
• Kernel panic - not syncing
• /sys/bus/platform/drivers
• /sys/bus/platform/drivers/*/bind
• /sys/bus/platform/drivers/*/unbind
• /sys/kernel/debug
• modprobe mailbox-test
• insmod mailbox-test
• rmmod mailbox-test

What your security team should do

• Prioritize remediation through the next scheduled Linux kernel update cycle; accelerate if the affected systems are embedded/SoC platforms, development boards, or test environments that actively use mailbox-test.
• Inventory systems and firmware images that include the mailbox-test driver, especially custom kernels and vendor BSP kernels.
• Disable or remove the mailbox-test driver from production kernels unless it is explicitly required.
• Restrict administrative access to sysfs, debugfs, module loading, driver binding, and device-tree/platform-device manipulation paths that could be used to trigger reprobe or error conditions.
• Monitor kernel logs for mailbox-test probe failures, KASAN use-after-free reports, kernel BUG/Oops events, and unexpected reboots on systems where the driver is present.
• For high-assurance environments, run patched kernels with kernel hardening options such as KASAN in test, slab freelist hardening, module signing, lockdown, and reduced debugfs exposure where operationally feasible.