Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Mon, 21 Oct 2019 09:48:56 -0400
From:   Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To:     Johan Hovold <johan@kernel.org>
Cc:     Alan Stern <stern@rowland.harvard.edu>,
        Oliver Neukum <oneukum@suse.com>,
        "Paul E . McKenney" <paulmck@linux.vnet.ibm.com>,
        linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
        stable <stable@vger.kernel.org>
Subject: Re: [PATCH RFC v2 2/2] USB: ldusb: fix ring-buffer locking
Message-ID: <20191021134856.GA35072@kroah.com>
References: <20191018151955.25135-1-johan@kernel.org>
 <20191018151955.25135-3-johan@kernel.org>
 <20191018185458.GA1191145@kroah.com>
 <20191021085627.GD24768@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20191021085627.GD24768@localhost>
User-Agent: Mutt/1.12.2 (2019-09-21)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, Oct 21, 2019 at 10:56:27AM +0200, Johan Hovold wrote:
> On Fri, Oct 18, 2019 at 11:54:58AM -0700, Greg Kroah-Hartman wrote:
> > On Fri, Oct 18, 2019 at 05:19:55PM +0200, Johan Hovold wrote:
> > > The custom ring-buffer implementation was merged without any locking
> > > whatsoever, but a spinlock was later added by commit 9d33efd9a791
> > > ("USB: ldusb bugfix").
> > > 
> > > The lock did not cover the loads from the ring-buffer entry after
> > > determining the buffer was non-empty, nor the update of the tail index
> > > once the entry had been processed. The former could lead to stale data
> > > being returned, while the latter could lead to memory corruption on
> > > sufficiently weakly ordered architectures.
> > 
> > Ugh.
> > 
> > This almost looks sane, but what's the odds there is some other issue in
> > here as well?  Would it make sense to just convert the code to use the
> > "standard" ring buffer code instead?
> 
> Yeah, long term that may be the right thing to do, but I wanted a
> minimal fix addressing the issue at hand without having to reimplement
> the driver and fix all other (less-critical) issues in there...
> 
> For the ring-buffer corruption / info-leak issue, these two patches
> should be sufficient though.
> 
> Copying the ring-buffer entry to a temporary buffer while holding the
> lock might still be preferred to avoid having to deal with barrier
> subtleties. But unless someone speaks out against 2/2, I'd just go ahead
> and apply it.

Ok, feel free to resend this and I'll queue it up, it's gone from my
queue :(

thanks,

greg k-h