linux-kernel - Re: [BUG] net: tg3: two 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>] [day] [month] [year] [list]

Message-ID: <CAMet4B6zN2Arm+RSctSmkdmhhOtnjUpiCbBgK0NPwaQoC+NGxA@mail.gmail.com>
Date:   Wed, 27 Jun 2018 20:16:08 +0530
From:   Siva Reddy Kallam <siva.kallam@...adcom.com>
To:     Jia-Ju Bai <baijiaju1990@...il.com>
Cc:     Prashant Sreedharan <prashant@...adcom.com>,
        Michael Chan <mchan@...adcom.com>,
        Linux Netdev List <netdev@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [BUG] net: tg3: two possible data races

On Wed, Jun 27, 2018 at 7:17 AM, Jia-Ju Bai <baijiaju1990@...il.com> wrote:
> The call paths in Linux 4.16.7 that may raise the first data race:
>
> CPU0:
> tg3_open
>     tg3_start
>         line 11611: spin_lock_bh()
>         tg3_enable_ints
>             line 1023: tp->tnapi->last_tag [READ]
>
> CPU1:
> tg3_poll
>     line 7341: tnapi->last_tag [WRITE]
>
> The READ operation in CPU0 is performed with holding a spinlock (line
> 11611), but the WRITE operation in CPU1 is performed without holding this
> spinlock, so it may cause a data race here.
> A possible fix may be to add spin_lock_bh() in tg3_poll().
>
> -----------------------------------------------------------------------
>
> The call paths in Linux 4.16.7 that may raise the second data race:
>
> CPU0:
> tg3_open
>     tg3_start
>         line 11611: spin_lock_bh()
>         tg3_enable_ints
>             line 1023: tp->irq_sync [WRITE]
>
> CPU1:
> tg3_interrupt_tagged
>     tg3_irq_sync
>         line 7341: tp->irq_sync [READ]
>
> The WRITE operation in CPU0 is performed with holding a spinlock (line
> 11611), but the READ operation in CPU1 is performed without holding this
> spinlock, so it may cause a data race here.
> A possible fix may be to add spin_lock_bh() in tg3_irq_sync().
>
> I am not sure that whether the possible fixes are correct, so I only report
> the data races.
>
>
> Best wishes,
> Jia-Ju Bai
>
>
We will evaluate this and provide an update on this.