CVE-2021-47430

What it actually does

Failure to clear the SMAP CPU feature flag when SMAP support is disabled at compile time (CONFIG_X86_SMAP=n) causes kernel warnings to trigger erroneously on systems where the CPU supports SMAP but the feature is not compiled in or is disabled via the nosmap boot parameter.

Why it matters to the business

Produces unnecessary warning messages in kernel logs during user-mode entry operations, increasing diagnostic noise that can complicate troubleshooting without causing system instability, data loss, or direct security exposure.

How an attack unfolds

No attacker exploitation is possible; the issue stems from a kernel configuration inconsistency that surfaces only when running specific selftests such as syscall_nt on hardware that advertises SMAP while the compiled kernel does not enable it.

How to fix it

Rebuild or upgrade to a Linux kernel containing the fix that unconditionally clears X86_FEATURE_SMAP when !CONFIG_X86_SMAP; ensure boot parameters and kernel config remain consistent regarding SMAP.

How to confirm the fix worked

Confirm the warning from irqentry_enter_from_user_mode no longer occurs when executing the syscall_nt selftest on a CONFIG_X86_SMAP=n build; inspect kernel configuration and dmesg for the cleared feature flag.

How to detect it

Review kernel logs for repeated warnings originating from irqentry_enter_from_user_mode when AC is asserted on systems with SMAP disabled in config; correlate with selftest execution or nosmap boot usage.

• WARNING: CPU: .* PID: .* at irqentry_enter_from_user_mode
• irqentry_enter_from_user_mode.*X86_FEATURE_SMAP
• asm_exc_general_protection.*nosmap

What your security team should do

• Apply the upstream fix or a distribution kernel update that resolves the entry sanity-check condition.
• Audit kernel build configurations for SMAP consistency across fleets to prevent similar diagnostic mismatches.
• Monitor for any downstream dependents that inherit the same entry code paths.