CVE-2021-47198

What it actually does

Use-after-free in lpfc_unreg_rpi() when NLP_REG_LOGIN_SEND flag is not cleared after login completion, allowing a second call to index rpi_ids with LPFC_RPI_ALLOW_ERROR value on freed memory.

Why it matters to the business

Local attackers on systems using the lpfc driver can trigger kernel crashes or escalate privileges; high CVSS and 923 days of exposure increase risk of exploitation on unpatched Linux hosts with Emulex/Broadcom Fibre Channel adapters.

How an attack unfolds

An attacker with local access triggers lpfc_reg_fab_ctrl_node() to set NLP_REG_LOGIN_SEND, then causes or waits for driver unload paths that invoke lpfc_unreg_rpi() twice without clearing the flag in lpfc_mbx_cmpl_fc_reg_login(), resulting in use-after-free access to the rpi_ids array.

How to fix it

Upgrade affected packages to the listed fixed versions: thunderbird (Debian:11) to 1:91.4.1-1~deb11u1, thunderbird (Debian:12/13) to 1:91.3.0-1, firefox-esr (Debian:11) to 91.4.1esr-1~deb11u1, firefox-esr (Debian:12/13) to 91.3.0esr-1. Reboot after kernel or driver updates and verify flag-clearing logic is present.

How to confirm the fix worked

Confirm the lpfc_mbx_cmpl_fc_reg_login() function clears NLP_REG_LOGIN_SEND before returning; run KASAN-enabled kernel and attempt driver unload under load; check dmesg for absence of use-after-free reports in lpfc_unreg_rpi().

Typical attack path

1. Obtain local shell on affected Linux system with lpfc driver loaded
2. Trigger fabric controller node registration to set NLP_REG_LOGIN_SEND flag
3. Force driver unload or repeated login/unregister sequences
4. Second lpfc_unreg_rpi() call uses stale LPFC_RPI_ALLOW_ERROR value as array index on freed memory
5. Achieve kernel memory corruption leading to crash or privilege escalation

How to detect it

Search kernel logs and audit trails for repeated lpfc driver load/unload events followed by KASAN use-after-free reports citing lpfc_unreg_rpi; inspect crash dumps for rpi_ids array accesses after free.

What your security team should do

• Prioritize patching systems with lpfc hardware within 30 days given public fix availability
• Restrict local user access on multi-tenant systems until updated
• Monitor for kernel oops or KASAN reports mentioning lpfc_unreg_rpi during driver unload
• Test updated kernels in staging before broad deployment