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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 9 Sep 2019 15:00:46 +0200
From:   Fabian Henneke <fabian.henneke@...il.com>
To:     Pavel Machek <pavel@...x.de>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        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

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).

Best regards,
Fabian

>                                                         Pavel
>
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures)
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ