CVE-2021-47567

What it actually does

On 32-bit PowerPC, a vmap stack overflow triggers a hard lockup because emergency_ctx remains referenced by virtual address after the data MMU is disabled, preventing proper exception handling.

Why it matters to the business

Systems may experience sudden unrecoverable hangs requiring manual reboot, leading to unplanned downtime and potential loss of in-progress workloads on affected hardware.

How an attack unfolds

An attacker with the ability to trigger deep kernel stack usage on a vulnerable 32-bit PowerPC system can force a stack overflow, resulting in the system entering a hard lockup state instead of recovering gracefully.

How to fix it

Apply the upstream kernel commit that addresses emergency_ctx with its physical address on 32-bit PowerPC, or update to a kernel release containing the fix for this vmap stack overflow handling issue.

How to confirm the fix worked

Confirm the presence of the corrected emergency_ctx physical address handling in the running kernel source or binary; test stack overflow scenarios in a controlled environment to verify graceful recovery instead of lockup.

Typical attack path

1. Identify or craft workload that causes excessive kernel stack consumption on 32-bit PowerPC
2. Trigger vmap stack overflow condition
3. Observe MMU deactivation without switching to physical emergency_ctx address
4. Induce hard lockup and system unresponsiveness

How to detect it

Examine kernel logs for hard lockup messages on 32-bit PowerPC systems; correlate with stack overflow indicators in oops or panic traces, though no specific post-exploitation artifacts are typically left behind.

What your security team should do

• Prioritize kernel updates for any 32-bit PowerPC deployments running vulnerable versions
• Monitor for upstream backports to distribution kernels and apply promptly
• Review workloads for excessive stack usage that could trigger the condition