[PATCH] scsi: message: fusion: Fix a possible data race in mpt_ioc_reset()

[PATCH] scsi: message: fusion: Fix a possible data race in mpt_ioc_reset()

[Tuo Li]

The variable ioc->taskmgmt_quiesce_io is often protected by the lock
ioc->taskmgmt_lock when is accessed. Here is an example in 
mpt_SoftResetHandler():

  spin_lock_irqsave(&ioc->taskmgmt_lock, flags);
  ...
  ioc->taskmgmt_quiesce_io = 0;
  ...
  spin_unlock_irqrestore(&ioc->taskmgmt_lock, flags);

However, ioc->taskmgmt_quiesce_io is set to 1 without holding the lock
ioc->taskmgmt_lock in mpt_ioc_reset():

  case MPT_IOC_SETUP_RESET:
    ioc->taskmgmt_quiesce_io = 1;

In my opinion, this may be a harmful race, because the value of
ioc->taskmgmt_quiesce_io can be rewritten by mpt_ioc_reset() when
another thread is accessing it.

To fix this possible data race, a lock and unlock pair is added when
accessing the variable ioc->taskmgmt_quiesce_io.

Reported-by: BassCheck <bass@buaa.edu.cn>
Signed-off-by: Tuo Li <islituo@gmail.com>
---
 drivers/message/fusion/mptbase.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/message/fusion/mptbase.c b/drivers/message/fusion/mptbase.c
index 4bf669c55649..86d7b4defeb0 100644
--- a/drivers/message/fusion/mptbase.c
+++ b/drivers/message/fusion/mptbase.c
@@ -6561,9 +6561,12 @@ mpt_config(MPT_ADAPTER *ioc, CONFIGPARMS *pCfg)
 static int
 mpt_ioc_reset(MPT_ADAPTER *ioc, int reset_phase)
 {
+	unsigned long flags;
 	switch (reset_phase) {
 	case MPT_IOC_SETUP_RESET:
+		spin_lock_irqsave(&ioc->taskmgmt_lock, flags);
 		ioc->taskmgmt_quiesce_io = 1;
+		spin_unlock_irqrestore(&ioc->taskmgmt_lock, flags);
 		dtmprintk(ioc, printk(MYIOC_s_DEBUG_FMT
 		    "%s: MPT_IOC_SETUP_RESET\n", ioc->name, __func__));
 		break;
-- 
2.34.1

Re: [PATCH] scsi: message: fusion: Fix a possible data race in mpt_ioc_reset()

[Bart Van Assche]

On 10/24/23 00:27, Tuo Li wrote:
> In my opinion, this may be a harmful race, because the value of
> ioc->taskmgmt_quiesce_io can be rewritten by mpt_ioc_reset() when
> another thread is accessing it.

It is a common pattern in the Linux kernel that a variable is set from
one thread without using locking and is read by another thread that is
holding a lock. It should be sufficient here to use WRITE_ONCE(). I
don't think that acquiring and releasing the spin lock is required.

Thanks,

Bart.

[PATCH] scsi: message: fusion: Fix a possible data race in mpt_ioc_reset()

[Tuo Li]

The variable ioc->taskmgmt_quiesce_io is often protected by the lock
ioc->taskmgmt_lock when is accessed. Here is an example in 
mpt_SoftResetHandler():

  spin_lock_irqsave(&ioc->taskmgmt_lock, flags);
  ...
  ioc->taskmgmt_quiesce_io = 0;
  ...
  spin_unlock_irqrestore(&ioc->taskmgmt_lock, flags);

However, ioc->taskmgmt_quiesce_io is set to 1 without holding the lock
ioc->taskmgmt_lock in mpt_ioc_reset():

  case MPT_IOC_SETUP_RESET:
    ioc->taskmgmt_quiesce_io = 1;

In my opinion, this may be a harmful race, because the value of 
ioc->taskmgmt_quiesce_io can be rewritten by mpt_ioc_reset() when another
thread is accessing it.

To fix this possible data race, a lock and unlock pair is added when
accessing the variable ioc->taskmgmt_quiesce_io.

Reported-by: BassCheck <bass@buaa.edu.cn>
Signed-off-by: Tuo Li <islituo@gmail.com>
---
 drivers/message/fusion/mptbase.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/message/fusion/mptbase.c b/drivers/message/fusion/mptbase.c
index 4bf669c55649..560057daf4ee 100644
--- a/drivers/message/fusion/mptbase.c
+++ b/drivers/message/fusion/mptbase.c
@@ -6561,9 +6561,13 @@ mpt_config(MPT_ADAPTER *ioc, CONFIGPARMS *pCfg)
 static int
 mpt_ioc_reset(MPT_ADAPTER *ioc, int reset_phase)
 {
+	unsigned long	 flags;
+
 	switch (reset_phase) {
 	case MPT_IOC_SETUP_RESET:
+		spin_lock_irqsave(&ioc->taskmgmt_lock, flags);
 		ioc->taskmgmt_quiesce_io = 1;
+		spin_unlock_irqrestore(&ioc->taskmgmt_lock, flags);
 		dtmprintk(ioc, printk(MYIOC_s_DEBUG_FMT
 		    "%s: MPT_IOC_SETUP_RESET\n", ioc->name, __func__));
 		break;
-- 
2.34.1