CVE-2022-49888 in Linux
Resumen
por VulDB • 2026-05-20
Enabling `CONFIG_KPROBES` on ARM64 kernels that include the Cortex-A76 erratum 1463225 workaround causes a kernel panic due to a **kernel stack overflow**.
### Root Cause Analysis
1. **Erratum Workaround Implementation**: The Cortex-A76 erratum 1463225 requires a specific debug handler (`cortex_a76_erratum_1463225_debug_handler`) to be installed in the exception vector table. To ensure this handler is always available and to minimize overhead, the kernel code often inlines or tightly couples this handler with the generic debug exception entry point (`el1_dbg`).
2. **Kprobe Interaction**: When `CONFIG_KPROBES` is enabled, the kernel attempts to insert probes into functions. If a probe is placed on `el1_dbg` (or if the infrastructure tries to handle probes on the erratum handler), it modifies the instruction stream or sets up a breakpoint.
3. **Stack Overflow Mechanism**: * The erratum handler is executed in a very low-level context (EL1 debug exception). * If a kprobe is active on this path, the kprobe infrastructure may attempt to handle the probe, potentially leading to recursive exception handling or excessive stack usage within the limited kernel stack space allocated for exception contexts. * The call trace shows repeated calls to `el1h_64_sync_handler` and `cortex_a76_erratum_1463225_debug_handler`, indicating a loop or deep recursion that exhausts the kernel stack, resulting in `kernel panic - not syncing: kernel stack overflow`.
4. **Inlining Issue**: The patch mentioned in the log inlines `cortex_a76_erratum_1463225_debug_handler` into `el1_dbg`. This makes it impossible to probe the handler directly (`No such file or directory` when trying to probe it), but the underlying issue is that the *entry point* (`el1_dbg`) is now part of a critical, low-level exception path that cannot safely handle kprobe-induced modifications without risking stack corruption or infinite loops.
### Solution
To prevent this kernel panic, you must **disable kprobes for the ARM64 architecture** when the Cortex-A76 erratum 1463225 workaround is enabled. This is typically handled by the kernel configuration.
#### Recommended Fix: Disable `CONFIG_KPROBES` on ARM64
If you are building a custom kernel, ensure that `CONFIG_KPROBES` is **not** enabled for ARM64 systems that include the Cortex-A76 erratum fix.
In your kernel `.config` or menuconfig: ```bash # Disable kprobes for ARM64 CONFIG_KPROBES=n ```
Alternatively, if you need kprobes for other architectures but not ARM64, ensure the dependency is correctly handled. The kernel maintainers have addressed this by making `CONFIG_KPROBES` depend on `!ARM64_ERRATUM_1463225` or similar, but if you are using a kernel version where this dependency is missing or incorrectly configured, you must manually disable it.
#### Alternative: Disable the Erratum Workaround (Not Recommended)
If you are certain your CPU does not suffer from erratum 1463225, you can disable the workaround: ```bash CONFIG_ARM64_ERRATUM_1463225=n ``` However, this is **strongly discouraged** unless you have verified your CPU revision and are certain the erratum does not apply, as it can lead to silent data corruption or system instability.
### Verification
After disabling `CONFIG_KPROBES` for ARM64:
1. Rebuild and boot the kernel. 2. Verify that the kernel does not panic on startup. 3. Confirm that kprobes are not available on ARM64: ```bash # echo p do_sys_open > /sys/kernel/debug/tracing/kprobe_events sh: write error: Function 'do_sys_open' not found in ftrace function file ```
### Summary
The kernel panic is caused by a conflict between the ARM64 kprobe infrastructure and the Cortex-A76 erratum 1463225 debug handler, leading to a kernel stack overflow. The fix is to **disable `CONFIG_KPROBES`** for ARM64 in the kernel configuration.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.