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>] [thread-next>] [day] [month] [year] [list]
Message-ID: <412162cd-8fab-104b-ce73-6f70f108218f@gmail.com>
Date:   Wed, 3 Oct 2018 21:52:14 +0800
From:   Jia-Ju Bai <baijiaju1990@...il.com>
To:     klassert@...nel.org, davem@...emloft.net, anna-maria@...utronix.de,
        bigeasy@...utronix.de, nhorman@...driver.com, keescook@...omium.org
Cc:     netdev@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: [REPORT] net: 3com: 3c59x: Possible data races

****** Possible race0 ******
CPU0:
vortex_boomerang_interrupt
     line 2510: spin_lock_irqsave()
     _boomerang_interrupt
         line 2432: vp->tx_skbuff[entry] [READ]
         line 2433: vp->tx_skbuff[entry] [READ]
         line 2453: vp->tx_skbuff[entry] = NULL [WRITE]

CPU1:
boomerang_start_xmit
     line 2145: vp->tx_skbuff[entry] = skb [WRITE]

As for vp->tx_skbuff[entry], the WRITE and READ operations in CPU0
are performed with holding a spinlock, but the WRITE operation in CPU1
is performed without holding this spinlock, so there may exist data races.

****** Possible race1 ******
CPU0:
vortex_boomerang_interrupt
     line 2510: spin_lock_irqsave()
     _boomerang_interrupt
         line 2421: vp->dirty_tx = dirty_tx [WRITE]

CPU1:
boomerang_start_xmit
     line 2137: vp->dirty_tx [READ]

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

****** Possible race2 ******
CPU0:
vortex_boomerang_interrupt
     line 2510: spin_lock_irqsave()
     _boomerang_interrupt
         line 2381: vp->handling_irq = 1 [WRITE]
         line 2498: vp->handling_irq = 0 [WRITE]

CPU1:
boomerang_start_xmit
     line 2134: vp->handling_irq [READ]

As for vp->handling_irq, the WRITE operations in CPU0 are performed
with holding a spinlock, but the READ operation in CPU1 is performed
without holding this spinlock, so there may exist data races.

****** Possible race3 ******
CPU0:
vortex_boomerang_interrupt
     line 2510: spin_lock_irqsave()
     _boomerang_interrupt
         boomerang_rx
             line 2669: skb->ip_summed = ... [WRITE]

CPU1:
boomerang_start_xmit
     line 2149: skb->ip_summed [READ]

As for skb->ip_summed, the WRITE operation in CPU0 is performed
with holding a spinlock, but the READ operation in CPU1 is performed
without holding this spinlock, so there may exist data races.


These possible races are detected by a runtime testing.
A possible fix of these races is protecting the code in 
boomerang_start_xmit()
using the spinlock in vortex_boomerang_interrupt().
But I am not sure whether this fix is correct, so I only report these races.


Best wishes,
Jia-Ju Bai

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ