CVE-2026-43281

What it actually does

This is a local Linux kernel memory-safety flaw in the mailbox framework. When a mailbox provider is described with an invalid or edge-case device-tree configuration such as `#mbox-cells = <0>;` and the controller does not provide custom `fw_xlate` or `of_xlate` callbacks, the default `fw_mbox_index_xlate()` path can access data out of bounds because it does not adequately validate the argument count before indexing. Depending on kernel build, hardware platform, and memory layout, this can result in kernel memory disclosure or a kernel crash/panic. The CVSS vector indicates local access with low attack complexity and low privileges, with high confidentiality and availability impact but no expected integrity impact.

Why it matters to the business

Affected Linux systems may be exposed to local denial-of-service or sensitive kernel memory disclosure, especially on embedded, ARM, appliance, IoT, or custom hardware platforms that rely heavily on device-tree mailbox definitions. Exploitation generally requires local access or the ability to influence device-tree/driver behavior, so internet-scale remote exploitation is unlikely. However, a successful exploit could destabilize devices, interrupt operations, or expose sensitive in-kernel data. The vulnerability is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS, and has no known public exploit maturity, so remediation should be prioritized based on platform exposure and use of affected mailbox/device-tree configurations rather than treated as an emergency remote-code-execution issue.

How an attack unfolds

An attacker first needs local execution capability on a vulnerable Linux-based system or another path to influence kernel device-tree/mailbox initialization. The vulnerable condition occurs when a mailbox controller is described with `#mbox-cells = <0>;` and does not implement its own translation callbacks, causing the kernel to fall back to `fw_mbox_index_xlate()`. By causing the kernel to parse or use that mailbox provider/consumer relationship, the attacker can trigger an out-of-bounds access in kernel context. Practical exploitation is platform-dependent: on some systems it may only cause an observable kernel oops or panic, while on others it may permit disclosure of adjacent kernel memory. There is no current indication of broad exploitation in the wild, and exploitation is most plausible on systems where local users can load overlays/modules, interact with relevant device drivers, or where vulnerable firmware/device-tree configurations are already present at boot.

How to fix it

Apply the vendor or distribution kernel update that includes the upstream fix for the mailbox framework bounds check in `fw_mbox_index_xlate()`. No specific fixed package versions were provided in the input, so use your Linux distribution, appliance vendor, or board-support-package advisory to identify the corrected kernel build. For custom kernels, backport the upstream Linux kernel patch that prevents out-of-bounds access in `fw_mbox_index_xlate()`. As defense-in-depth, audit device-tree sources and overlays for mailbox providers using `#mbox-cells = <0>;`; where possible, correct the device-tree binding to use a valid cell count or ensure the mailbox controller driver provides appropriate `fw_xlate`/`of_xlate` callbacks with bounds validation. Restrict the ability to load device-tree overlays, kernel modules, or untrusted firmware/device-tree blobs to trusted administrators only. Where immediate patching is not possible, reduce local user access on exposed systems and monitor for kernel oops/panic events involving the mailbox framework.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package or custom kernel source includes the fix for `fw_mbox_index_xlate()` bounds checking. On managed Linux systems, compare the installed kernel version against the relevant distribution or vendor advisory. On custom builds, inspect the patched source to ensure `fw_mbox_index_xlate()` validates the number of mailbox cells before indexing. Reboot into the patched kernel and verify with `uname -a` and package-manager metadata that the active kernel is the fixed build, not merely installed on disk. For exposure validation, search device-tree sources, compiled device-tree output, and overlays for mailbox definitions using `#mbox-cells = <0>;`, then identify whether the associated mailbox controller lacks custom translation callbacks. Review system logs after patching for absence of recurring kernel oops/panic traces referencing `fw_mbox_index_xlate`, mailbox probing, or device-tree mailbox parsing.

Typical attack path

1. Obtain local execution or low-privileged access on a Linux system using affected kernel code.
2. Identify that the system uses device-tree mailbox definitions and has a mailbox provider with `#mbox-cells = <0>;`.
3. Find or create a path that causes the kernel mailbox framework to resolve the affected mailbox entry using the default `fw_mbox_index_xlate()` function.
4. Trigger mailbox parsing/initialization through driver probing, device-tree overlay loading, module loading, or interaction with a dependent device driver.
5. Cause an out-of-bounds kernel memory access, potentially resulting in kernel memory disclosure or a crash/panic.
6. Use the crash for denial of service or attempt to recover exposed kernel memory depending on platform behavior and available primitives.

How to detect it

Because this issue is a local kernel memory-safety flaw and no public exploitation pattern is known, detection should focus on kernel crash evidence, device-tree manipulation, and suspicious attempts to exercise mailbox-related drivers. Review `dmesg`, system journal, kernel logs, crash dumps, pstore/ramoops, kdump, and hypervisor or appliance management logs for kernel oops/panic traces containing `fw_mbox_index_xlate`, mailbox framework functions, out-of-bounds access reports, or KASAN/UBSAN findings. Investigate recent changes to device-tree blobs, overlays, bootloader configuration, firmware images, kernel modules, or board-support-package files. On systems that permit overlays, review audit logs and shell history for commands that load or modify device-tree overlays. For forensic review, preserve `/var/crash`, `/sys/fs/pstore`, kernel ring buffer output, bootloader configuration, `/boot` contents, and relevant device-tree source/compiled blobs. Treat a kernel crash involving `fw_mbox_index_xlate()` shortly after driver probing, overlay loading, firmware update, or module insertion as suspicious, especially if it recurs or follows local user activity.

• fw_mbox_index_xlate
• mailbox: Prevent out-of-bounds access in fw_mbox_index_xlate()
• #mbox-cells = <0>
• Unable to handle kernel paging request
• BUG: KASAN: out-of-bounds
• BUG: KASAN: slab-out-of-bounds
• kernel BUG at drivers/mailbox
• drivers/mailbox
• OF: /
• of_xlate
• fw_xlate
• mailbox controller
• pstore:
• /sys/fs/pstore
• /var/crash
• /boot/*.dtb
• /boot/overlays
• /sys/kernel/config/device-tree/overlays

What your security team should do

• Inventory Linux systems that use device-tree-based hardware descriptions, prioritizing embedded devices, appliances, ARM platforms, custom board-support packages, and systems with mailbox-controller drivers.
• Patch affected kernels through vendor-supported updates or backport the upstream mailbox framework fix into custom kernels.
• Audit device-tree files and overlays for `#mbox-cells = <0>;` and remediate invalid or risky mailbox definitions where feasible.
• Restrict local capabilities that could trigger or modify kernel hardware description paths, including device-tree overlay loading, kernel module loading, and untrusted firmware updates.
• Monitor kernel logs for oops, panic, or KASAN reports involving `fw_mbox_index_xlate`, mailbox controllers, or device-tree mailbox parsing.
• Prioritize remediation according to local-access risk: multi-user systems, systems allowing container escape research surfaces, development boards, and remotely managed appliances should be addressed before single-purpose locked-down devices.
• Track Linux distribution, appliance vendor, and board-support-package advisories because exact fixed versions vary by kernel branch and downstream vendor.