linux-kernel - [PATCH] scsi: be2iscsi: Fix a possible null-pointer dereference in beiscsi_alloc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20251215092509.4035061-1-islituo@gmail.com>
Date: Mon, 15 Dec 2025 17:25:09 +0800
From: Tuo Li <islituo@...il.com>
To: ketan.mukadam@...adcom.com,
	James.Bottomley@...senPartnership.com,
	martin.petersen@...cle.com
Cc: linux-scsi@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Tuo Li <islituo@...il.com>
Subject: [PATCH] scsi: be2iscsi: Fix a possible null-pointer dereference in beiscsi_alloc_mem()

There appears to be a potential null-pointer dereference in the
error-handling path. Consider the following scenario:

1. One or more mem_descr->mem_array objects have been allocated
successfully, so i is non-zero.
2. In the i-th iteration, DMA memory allocation succeeds, resulting in a
non-zero j.
3. A subsequent kmalloc_array() call fails, leaving mem_descr->mem_array as
NULL and transferring control to the free_mem label.

Under these conditions, the cleanup code may dereference
mem_descr->mem_array while freeing DMA memory, as shown below:

  dma_free_coherent(&phba->pcidev->dev,
    mem_descr->mem_array[j - 1].size,
	mem_descr->mem_array[j - 1].
	virtual_address,
	(unsigned long)mem_descr->
	mem_array[j - 1].
	bus_address.u.a64.address);

To reduce the risk of such a null-pointer dereference, it may be preferable
to separate the cleanup of resources associated with a failed
mem_descr->mem_array allocation from the cleanup of previously initialized
descriptors. Likewise, DMA memory allocated prior to a failed
mem_arr->virtual_address allocation could be released independently, rather
than being handled by the shared while loop under the free_mem label.

Signed-off-by: Tuo Li <islituo@...il.com>
---
 drivers/scsi/be2iscsi/be_main.c | 20 +++++++++++++-------
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/drivers/scsi/be2iscsi/be_main.c b/drivers/scsi/be2iscsi/be_main.c
index a0e794ffc980..1a22871843a0 100644
--- a/drivers/scsi/be2iscsi/be_main.c
+++ b/drivers/scsi/be2iscsi/be_main.c
@@ -2554,8 +2554,18 @@ static int beiscsi_alloc_mem(struct beiscsi_hba *phba)
 	kfree(mem_arr_orig);
 	return 0;
 free_mem:
-	mem_descr->num_elements = j;
-	while ((i) || (j)) {
+	while (j) {
+		j--;
+		mem_arr--;
+		dma_free_coherent(&phba->pcidev->dev,
+					    mem_arr->size,
+					    mem_arr->virtual_address,
+					    (unsigned long)mem_arr->
+					    bus_address.u.a64.address);
+	}
+	while (i) {
+		i--;
+		mem_descr--;
 		for (j = mem_descr->num_elements; j > 0; j--) {
 			dma_free_coherent(&phba->pcidev->dev,
 					    mem_descr->mem_array[j - 1].size,
@@ -2565,11 +2575,7 @@ static int beiscsi_alloc_mem(struct beiscsi_hba *phba)
 					    mem_array[j - 1].
 					    bus_address.u.a64.address);
 		}
-		if (i) {
-			i--;
-			kfree(mem_descr->mem_array);
-			mem_descr--;
-		}
+		kfree(mem_descr->mem_array);
 	}
 	kfree(mem_arr_orig);
 	kfree(phba->init_mem);
-- 
2.43.0