linux-kernel - RE: [PATCH] hyper-v: Check for ring buffer in hv_get_bytes_to

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-prev] [day] [month] [year] [list]

Date:   Thu, 7 Mar 2019 19:34:53 +0000
From:   Michael Kelley <mikelley@...rosoft.com>
To:     "mgamal@...hat.com" <mgamal@...hat.com>,
        "linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
        kimbrownkd <kimbrownkd@...il.com>,
        Haiyang Zhang <haiyangz@...rosoft.com>,
        Stephen Hemminger <sthemmin@...rosoft.com>
CC:     Sasha Levin <Alexander.Levin@...rosoft.com>,
        Dexuan Cui <decui@...rosoft.com>,
        Long Li <longli@...rosoft.com>,
        KY Srinivasan <kys@...rosoft.com>,
        vkuznets <vkuznets@...hat.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] hyper-v: Check for ring buffer in
 hv_get_bytes_to_read/write

From: Mohammed Gamal <mgamal@...hat.com>  Sent: Thursday, March 7, 2019 10:32 AM
> >
> > Could you elaborate on the code paths where
> > hv_get_bytes_to_read/write() could be called when the ring buffer
> > isn't yet allocated?  My sense is that Kim Brown's patch will address
> > all of the code paths that involved sysfs access from outside the
> > driver.  And within a driver, the ring buffer should never be
> > accessed
> > unless it is already allocated.  Is there another code path we're not
> > aware of?  I'm wondering if these changes are really needed once
> > Kim Brown's patch is finished.
> >
> > Michael
> 
> I've seen one instance of the race in the netvsc driver when running
> traffic through it with iperf3 while continuously changing the channel
> settings.
> 
> The following code path deallocates the ring buffer:
> netvsc_set_channels() -> netvsc_detach() ->
> rndis_filter_device_remove() -> netvsc_device_remove() -> vmbus_close()
> -> vmbus_free_ring() -> hv_ringbuffer_cleanup().
> 
> netvsc_send_pkt() -> hv_get_bytes_to_write() might get called
> concurrently after vmbus_close() and before vmbus_open() returns and
> sets up the new ring buffer.
> 
> The race is fairly hard to reproduce on recent upstream kernels, but I
> still managed to reproduce it.

My thought is that a race like the above needs to be addressed in the
netvsc driver.  The race may have other problems beyond just
accessing the ring buffer before it is (re)allocated.  While adding the tests
in hv_get_bytes_to_read/write() isn't harmful, doing so has the potential
to mask the real problem.  These routines are also somewhat performance
sensitive so we don't want any unnecessary overhead.

Michael