#1151377 linux: lpfc boot hang since 6.1.178 - use-after-free of mboxq in lpfc_sli4_driver_resource_setup() backport

#1151377#5
Date:
2026-10-20 10:10:10 UTC
From:
To:
Dear Maintainer,
Since linux-image-6.1.0-52-amd64 (6.1.180-1), my Debian 12 server hangs
early during boot. The last working kernel is linux-image-6.1.0-51-amd64
(6.1.177-1). 6.1.0-53 (6.1.187-1) and 6.1.0-54 (6.1.190-1) hang in the
same way.

Hardware:
Emulex Corporation LPe31000/LPe32000 Series 16Gb/32Gb Fibre Channel Adapter
11:00.0 Fibre Channel [0c04]: Emulex Corporation LPe31000/LPe32000
Series 16Gb/32Gb Fibre Channel Adapter [10df:e300] (rev 01)

HBA firmware: 14.4.322.17, sli-4:2:c
lpfc driver version: 14.2.0.7

The HBA is connected by fibre to an external RAID storage. The root
filesystem is NOT on the FC storage.

On the working kernel, lpfc initializes about 2 seconds into boot. On
the newer kernels, the system hangs at about the same point, before any
filesystems are mounted.

Probable cause:
6.1.178 includes the stable backport of "scsi: lpfc: Fix memory leak in
lpfc_sli4_driver_resource_setup()" (upstream commit
1bd28625e25be549ee7c47532e7c3ef91c682410, CVE-2026-72087).

Upstream, the new mempool_free(mboxq, ...) is placed after the call to
lpfc_get_sli4_parameters(phba, mboxq) and its error check. In the 6.1.y
backport it was placed before that call. In
drivers/scsi/lpfc/lpfc_init.c of v6.1.178:

8178:  mempool_free(mboxq, phba->mbox_mem_pool);
8187:  rc = lpfc_get_sli4_parameters(phba, mboxq);
8200:  mempool_free(mboxq, phba->mbox_mem_pool);   (error path)
8207:  mempool_free(mboxq, phba->mbox_mem_pool);   (error path)

So mboxq is freed, then used for a mailbox command to the HBA
(use-after-free), and can be freed again in the error paths (double free).
This happens on every SLI-4 HBA probe, which matches the boot hang.

The fix should be to move the mempool_free() at line 8178 to after the
lpfc_get_sli4_parameters() call and its error handling, as in the
mainline version of the patch.

I have pinned 6.1.0-51 for now. This is a production server, so I can
only test during maintenance windows, but I can test a fixed kernel or
a patched module when one is available.

Kernel on the running system:
Linux mx 6.1.0-51-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.177-1
(2026-07-16) x86_64 GNU/Linux


Alexander Antonakakis

#1151377#14
Date:
2026-10-20 11:39:57 UTC
From:
To:
Hi Alexander,

This looks like the same issue I came across. A patch doing exactly
that is already queued for the next 6.1.y release:

https://lore.kernel.org/r/20261008184328.2857037-1-andrey.misyrov@gmail.com

Regards,
Andrey

#1151377#19
Date:
2026-10-20 11:44:52 UTC
From:
To:
A fix for this is queued for the next upstream 6.1.y release:
https://lore.kernel.org/r/20261008184328.2857037-1-andrey.misyrov@gmail.com

It may be worth applying it to the Debian bookworm kernel before the
next stable rebase.

#1151377#24
Date:
2026-10-20 11:45:47 UTC
From:
To: