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 for Android: free password hash cracker in your pocket
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <7c9bb278-5042-3bdc-9598-95a10e42f78d@gmail.com>
Date:   Tue, 8 Feb 2022 19:13:15 +0800
From:   Jia-Ju Bai <baijiaju1990@...il.com>
To:     pontus.fuchs@...il.com, Kalle Valo <kvalo@...eaurora.org>
Cc:     linux-wireless@...r.kernel.org, netdev@...r.kernel.org,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: [BUG] ar5523: possible deadlocks involving locking and waiting
 operations

Hello,

My static analysis tool reports two possible deadlocks in the ar5523 
driver in Linux 5.16:

#BUG 1
ar5523_hwconfig()
   mutex_lock(&ar->mutex); --> Line 1135 (Lock A)
   ar5523_flush_tx()
     wait_event_timeout(ar->tx_flush_waitq, ...) --> Line 926 (Wait X)

ar5523_tx_work()
   mutex_lock(&ar->mutex); --> Line 888 (Lock A)
   ar5523_tx_work_locked()
     ar5523_data_tx_pkt_put()
       wake_up(&ar->tx_flush_waitq); --> Line 727 (Wake X)

#BUG 2
ar5523_configure_filter()
   mutex_lock(&ar->mutex); --> Line 1331 (Lock A)
   ar5523_flush_tx()
     wait_event_timeout(ar->tx_flush_waitq, ...) --> Line 926 (Wait X)

ar5523_tx_work()
   mutex_lock(&ar->mutex); --> Line 888 (Lock A)
   ar5523_tx_work_locked()
     ar5523_data_tx_pkt_put()
       wake_up(&ar->tx_flush_waitq); --> Line 727 (Wake X)

When ar5523_hwconfig()/ar5523_configure_filter() is executed, "Wait X" 
is performed by holding "Lock A". If ar5523_tx_work() is executed at 
this time, "Wake X" cannot be performed to wake up "Wait X", because 
"Lock A" has been already held, causing possible deadlock.
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ