CVE-2024-46706

What it actually does

The flaw permits the fsl_lpuart driver to enter runtime suspend via pm_runtime_put before uart_add_one_port completes and the normal console is ready, causing earlycon putchar to block indefinitely on UARTSTAT TRDE.

Why it matters to the business

Embedded Linux devices using this UART may fail to boot under common debug boot arguments, leading to deployment delays and manual recovery needs on affected hardware.

How an attack unfolds

No attacker action is required; the race occurs automatically during device_add and child serial_ctrl probe when earlycon initcall_debug=1 loglevel=8 are present, resulting in premature autosuspend before console handover.

How to fix it

Update the Linux kernel to commit 8eb92cfca6c2c5a15ab1773f3d18ab8d8f7dbb68 or an equivalent stable release that calls pm_runtime_mark_last_busy immediately after pm_runtime_enable.

How to confirm the fix worked

Confirm the fix commit is present in the tree, then boot with the triggering debug arguments and verify the system reaches a normal console without UART hang.

Typical attack path

1. Boot kernel with earlycon and initcall_debug enabled on fsl_lpuart hardware
2. serial_ctrl child device triggers pm_runtime_get_sync on parent during probe
3. Auto-suspend fires after 3000 ms delay before normal console initializes
4. Early console putchar hangs waiting for TRDE in UARTSTAT

How to detect it

Review early boot logs for UARTSTAT waits or runtime suspend messages preceding console handover; no persistent post-boot artifacts exist because the issue manifests only at initialization.

What your security team should do

• Apply the referenced kernel commit or newer stable release containing the fix
• Temporarily avoid earlycon + initcall_debug combinations on unpatched fsl_lpuart systems
• Monitor upstream stable branches for backports to distribution kernels