netdev - [BUG] ipw2100: possible deadlocks involving waiting and locking operations

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 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]

Date:   Mon, 7 Feb 2022 23:03:29 +0800
From:   Jia-Ju Bai <baijiaju1990@...il.com>
To:     stas.yakovlev@...il.com, kvalo@...nel.org, davem@...emloft.net,
        kuba@...nel.org
Cc:     linux-wireless@...r.kernel.org, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: [BUG] ipw2100: possible deadlocks involving waiting and locking
 operations

Hello,

My static analysis tool reports two possible deadlock in the ipw2100 
driver in Linux 5.16:

#BUG 1
ipw2100_wx_set_retry()
   mutex_lock(&priv->action_mutex); --> Line 7323 (Lock A)
   ipw2100_set_short_retry()
     ipw2100_hw_send_command()
       wait_event_interruptible_timeout(priv->wait_command_queue, ...) 
--> Line 793 (Wait X)

ipw_radio_kill_sw()
   mutex_lock(&priv->action_mutex); --> Line 4259 (Lock A)
   schedule_reset()
     wake_up_interruptible(&priv->wait_command_queue); --> Line 706 (Wake X)

#BUG 2
ipw2100_wx_set_scan()
   mutex_lock(&priv->action_mutex); --> Line 7393 (Lock A)
   ipw2100_start_scan()
     ipw2100_hw_send_command()
       wait_event_interruptible_timeout(priv->wait_command_queue, ...) 
--> Line 793 (Wait X)

ipw_radio_kill_sw()
   mutex_lock(&priv->action_mutex); --> Line 4259 (Lock A)
   schedule_reset()
     wake_up_interruptible(&priv->wait_command_queue); --> Line 706 (Wake X)

When ipw2100_wx_set_retry() or ipw2100_wx_set_scan() is executed, "Wait 
X" is performed by holding "Lock A". If ipw_radio_kill_sw() is executed 
at this time, "Wake X" cannot be performed to wake up "Wait X", because 
"Lock A" has been already hold, causing possible deadlocks.
I find that "Wait X" is performed with a timeout, to relieve the 
possible deadlocks; but I think this timeout can cause inefficient 
execution.

I am not quite sure whether these possible problems are real.
Any feedback would be appreciated, thanks :)

Best wishes,
Jia-Ju Bai