linux-kernel - Re: [PATCH 4.19 19/57] Bluetooth: hidp: Let hidp_send

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:   Tue, 10 Sep 2019 10:29:05 +0100
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Fabian Henneke <fabian.henneke@...il.com>
Cc:     Pavel Machek <pavel@...x.de>, linux-kernel@...r.kernel.org,
        stable@...r.kernel.org, Marcel Holtmann <marcel@...tmann.org>,
        Sasha Levin <sashal@...nel.org>
Subject: Re: [PATCH 4.19 19/57] Bluetooth: hidp: Let hidp_send_message return
 number of queued bytes

On Tue, Sep 10, 2019 at 08:27:10AM +0200, Fabian Henneke wrote:
> 
> 
> On 10.09.19 00:59, Greg Kroah-Hartman wrote:
> > On Mon, Sep 09, 2019 at 03:00:46PM +0200, Fabian Henneke wrote:
> >> Hi,
> >>
> >> On Mon, Sep 9, 2019 at 2:15 PM Pavel Machek <pavel@...x.de> wrote:
> >>
> >>> Hi!
> >>>
> >>>> [ Upstream commit 48d9cc9d85dde37c87abb7ac9bbec6598ba44b56 ]
> >>>>
> >>>> Let hidp_send_message return the number of successfully queued bytes
> >>>> instead of an unconditional 0.
> >>>>
> >>>> With the return value fixed to 0, other drivers relying on hidp, such as
> >>>> hidraw, can not return meaningful values from their respective
> >>>> implementations of write(). In particular, with the current behavior, a
> >>>> hidraw device's write() will have different return values depending on
> >>>> whether the device is connected via USB or Bluetooth, which makes it
> >>>> harder to abstract away the transport layer.
> >>>
> >>> So, does this change any actual behaviour?
> >>>
> >>> Is it fixing a bug, or is it just preparation for a patch that is not
> >>> going to make it to stable?
> >>>
> >>
> >> I created this patch specifically in order to ensure that user space
> >> applications can use HID devices with hidraw without needing to care about
> >> whether the transport is USB or Bluetooth. Without the patch, every
> >> hidraw-backed Bluetooth device needs to be treated specially as its write()
> >> violates the usual return value contract, which could be viewed as a bug.
> >>
> >> Please note that a later patch (
> >> https://www.spinics.net/lists/linux-input/msg63291.html) fixes some
> >> important error checks that were relying on the old behavior (and were
> >> unfortunately missed by me).
> > 
> > As that patch doesn't seem to be in Linus's tree yet, we should postpone
> > taking this one in the stable tree right now, correct?
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> Yes, please wait for the other patch if it's not in his tree yet and apply the two together.

Ok, will move it out and wait for the fixup patch to hit Linus's tree,
thanks!

greg k-h