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>] [day] [month] [year] [list]
Date:   Sat, 6 Oct 2018 10:25:13 +0800
From:   Jia-Ju Bai <baijiaju1990@...il.com>
To:     sgruszka@...hat.com, kvalo@...eaurora.org, davem@...emloft.net
Cc:     linux-wireless@...r.kernel.org, netdev <netdev@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: [Report] net: wireless: iwlegacy: Several possible data races

****** Possible race 0 ******
CPU0:
il4965_mac_tx
     il4965_tx_skb
         line 1687: spin_lock_irqsave(&il->lock, flags)
         line 1894: q->write_ptr = il_queue_inc_wrap(...) [WRITE]

CPU1:
il4965_irq_tasklet
     il_txq_update_write_ptr
         line 2749: il_wr(..., txq->q.write_ptr); [READ]
         line 2757: _il_wr(..., txq->q.write_ptr); [READ]

CPU2:
il_bg_watchdog
     il_check_stuck_queue
         line 4817: if (q->read_ptr == q->write_ptr) [READ]

CPU3:
il4965_irq_tasklet
     il4965_rx_handle
         line 4827, function pointer: il->handlers[pkt->hdr.cmd] (il, rxb);
         il4965_hdl_tx
             il_queue_used
                 line 868: return q->write_ptr >= ... q->write_ptr ... 
[READ]

As for q->write_ptr, the WRITE operation in CPU0 is performed with holding
a spinlock il->lock, but the READ operations in CPU1, CPU2 and CPU3
are performed without holding this spinlock, so there may exist data races.

****** Possible race 1 ******
CPU0:
il4965_irq_tasklet
     il4965_rx_handle
         line 4827, function pointer: il->handlers[pkt->hdr.cmd] (il, rxb);
         il4965_hdl_tx
             line 2834: spin_lock_irqsave(&il->sta_lock, flags)
             il4965_tx_queue_reclaim
                 line 2490: q->read_ptr = ... [WRITE]

CPU1:
il_bg_watchdog
     il_check_stuck_queue
         line 4817: q->read_ptr == q->write_ptr [READ]

As for q->read_ptr, the WRITE operation in CPU0 is performed with
holding a spinlock il->sta_lock, but the READ operation in CPU1 is
performed without holding this spinlock, so there may exist a data race.

****** Possible race 2 ******
CPU0:
il4965_mac_tx
     il4965_tx_skb
         line 1687: spin_lock_irqsave(&il->lock, flags)
         line 1863: txq->need_update = 1 [WRITE]

CPU1:
il4965_irq_tasklet
     il_txq_update_write_ptr
         line 2731: if (txq->need_update == 0) [READ]

As for txq->need_update, the WRITE operation in CPU0 is performed with
holding a spinlock il->lock, but the READ operation in CPU1 is performed
without holding this spinlock, so there may exist a data race.

I do not find good ways to fix these possible data races, so I only 
report them.


Best wishes,
Jia-Ju Bai

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ