[<prev] [next>] [day] [month] [year] [list]
Message-ID: <491799be-ea2e-5b60-b14b-bbdfd516d7ac@canonical.com>
Date: Tue, 15 Dec 2020 00:31:52 +0000
From: Colin Ian King <colin.king@...onical.com>
To: Can Guo <cang@...eaurora.org>
Cc: "James E.J. Bottomley" <jejb@...ux.ibm.com>,
"Martin K. Petersen" <martin.petersen@...cle.com>,
"linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: re: scsi: ufs: Serialize eh_work with system PM events and async scan
Hi,
Static analysis on linux-next with Coverity had found a potential null
pointer dereference issue in the following commit:
commit 88a92d6ae4fe09b2b27781178c5c9432d27b1ffb
Author: Can Guo <cang@...eaurora.org>
Date: Wed Dec 2 04:04:01 2020 -0800
scsi: ufs: Serialize eh_work with system PM events and async scan
The analysis by Coverity is as follows:
8929 int ufshcd_system_suspend(struct ufs_hba *hba)
8930 {
8931 int ret = 0;
8932 ktime_t start = ktime_get();
8933
deref_ptr_in_call: Dereferencing pointer hba.
8934 down(&hba->eh_sem);
Dereference before null check (REVERSE_INULL)
check_after_deref: Null-checking hba suggests that it may be null, but
it has already been dereferenced on all paths leading to the check.
8935 if (!hba || !hba->is_powered)
8936 return 0;
Seeing that the down lock has been added by the commit it suggests the
commit overlooks the fact that hba may potentially be null. Not sure if
hba can be null, so I'm not sure if this is a real bug or a false positive.
Colin
Powered by blists - more mailing lists