linux-kernel - [PATCH net 2/2] net/ethernet/chelsio: t4_handle_fw

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20230116152100.30094-3-davydov-max@yandex-team.ru>
Date:   Mon, 16 Jan 2023 18:21:00 +0300
From:   Maksim Davydov <davydov-max@...dex-team.ru>
To:     rajur@...lsio.com
Cc:     davydov-max@...dex-team.ru, davem@...emloft.net,
        edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com,
        anish@...lsio.com, hariprasad@...lsio.com, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: [PATCH net 2/2] net/ethernet/chelsio: t4_handle_fw_rpl fix NULL

After t4_hw.c:t4_prep_adapter() that is called in cxgb4_main.c:init_one()
adapter has it least 1 port for debug. Thus, for_each_port() usually has
at least 1 iteration, but this function can be called with wrong
configured adapter

Found by Linux Verification Center (linuxtesting.org) with the SVACE
static analysis tool.

Fixes: 23853a0a9a76 ("cxgb4: Don't assume FW_PORT_CMD reply is always
port info msg")

Signed-off-by: Maksim Davydov <davydov-max@...dex-team.ru>
---
 drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
index 8d719f82854a..2f7b49473f52 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
@@ -8864,7 +8864,8 @@ int t4_handle_fw_rpl(struct adapter *adap, const __be64 *rpl)
 				break;
 		}
 
-		t4_handle_get_port_info(pi, rpl);
+		if (pi)
+			t4_handle_get_port_info(pi, rpl);
 	} else {
 		dev_warn(adap->pdev_dev, "Unknown firmware reply %d\n",
 			 opcode);
-- 
2.25.1