linux-kernel - [REPORT] net: 3com: 3c59x: Possible data races

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