CVE-2025-38332

What it actually does

Incorrect strlcat() usage on BIOSVersion buffer in lpfc driver triggers FORTIFY_SOURCE runtime panic despite valid size argument; resolved by replacing memset+strlcat sequence with memcpy() plus explicit NULL termination to satisfy lpfc_printf_log() expectations.

Why it matters to the business

Linux systems with Emulex/Broadcom lpfc Fibre Channel adapters experience kernel panics during driver load or logging, causing unplanned downtime; affects many distributions and container-optimized OS deployments using the listed affected kernels.

How an attack unfolds

An attacker triggers lpfc driver initialization or log paths that invoke BIOS version string handling; FORTIFY detects apparent overflow and panics the kernel. Listed threat actors involved in Linux kernel privilege escalation and container-focused campaigns may chain this with other kernel flaws for denial of service or further exploitation.

How to fix it

Upgrade to linux-lts 6.6.58-r0 or apply commit ac7bfaa099ec3e4d7dfd0ab9726fc3bc7911365d (and equivalent stable backports) in the Linux kernel tree; reboot after update on systems exposing lpfc hardware.

How to confirm the fix worked

Confirm running kernel contains the fix commit or version 6.6.58-r0+; inspect lpfc source for memcpy() + explicit NUL termination of BIOSVersion buffer and absence of the original strlcat pattern.

Typical attack path

1. Gain local or container access to trigger lpfc module load or SCSI operations
2. Reach lpfc BIOS version string construction code path
3. Invoke strlcat() under FORTIFY to induce panic
4. Escalate impact via listed kernel privilege-escalation techniques

How to detect it

Search dmesg, syslog, and kernel logs for lpfc driver messages containing FORTIFY, strlcat, or BIOSVersion buffer operations around panic timestamps; correlate with container runtime or privilege-escalation attempts noted by listed threat actors.

• lpfc.*FORTIFY
• BIOSVersion
• strlcat.*overflow

What your security team should do

• Apply kernel updates immediately on any host with lpfc adapters given 474 days since publication and rising EPSS trend
• Prioritize patching in container-optimized and high-availability environments
• Add kernel oops monitoring for lpfc-related panics until fleet is updated