Currently, we report relative x and y coordinates when receiving data
from the pointing stick. We try to divide each value by 16, since the
raw values are very large, and send the pointer flying across the
screen. Currently we try to do this by shifting the relative
coordinates for the pointing sti
On Mon, Sep 9, 2013 at 6:48 AM, Benjamin Tissoires
wrote:
> On Wed, Sep 4, 2013 at 6:37 PM, Kees Cook wrote:
>> These patches introduce a validation function for HID devices that do
>> direct report value accesses, solving a number of heap smashing flaws.
>>
>> This version changes to using an fi
Hi Tommy,
On Thu, Sep 05, 2013 at 05:50:55AM +, yunkang.t...@cn.alps.com wrote:
>
> - Add the macro definition for v5 device.
>
> --- linux-3.11/drivers/input/mouse/alps.h.orig 2013-09-04 19:51:33.837135870
> +0800
> +++ linux-3.11/drivers/input/mouse/alps.h 2013-09-05 21:01:57.074314890 +0
Hi Tom
On Mon, Sep 9, 2013 at 5:43 PM, Tom Gundersen wrote:
> Hi Marcel,
>
> The above commit (60cbd53 in mainline) doesn't appear to work for me.
> I.e., depmod does not create an entry in modules.devname and hence no
> device node is created on boot.
>
> If I understand correctly, you'd also ne
Hi Tommy,
On Thu, Sep 05, 2013 at 05:50:48AM +, yunkang.t...@cn.alps.com wrote:
>
> - Calculate the device's dimension in alps_identify().
> - Change the logic of packet decoding.
> - Add the new data process logic.
It appears that your mailer damaged the patch converting all tabs to
single
udev has this nice feature of creating "dead" /dev/ device-nodes if
it finds a devnode: modalias. Once the node is accessed, the kernel
automatically loads the module that provides the node. However, this
requires udev to know the major:minor code to use for the node. This
feature was introduced by
On Mon, Sep 9, 2013 at 6:33 PM, David Herrmann wrote:
> udev has this nice feature of creating "dead" /dev/ device-nodes if
> it finds a devnode: modalias. Once the node is accessed, the kernel
> automatically loads the module that provides the node. However, this
> requires udev to know the major
On Sun, Sep 08, 2013 at 12:29:26PM +0100, Jonathan Cameron wrote:
> On 09/01/13 12:17, Zubair Lutfullah wrote:
> > Enable shared IRQ to allow ADC to share IRQ line from
> > parent MFD core. Only FIFO0 IRQs are for TSC and handled
> > on the TSC side.
> >
> > Step mask would be updated from cached
Hi Marcel,
The above commit (60cbd53 in mainline) doesn't appear to work for me.
I.e., depmod does not create an entry in modules.devname and hence no
device node is created on boot.
If I understand correctly, you'd also need to create the correct
"char-major--" alias (which I don't think you can
HI Benjamin,
You can still try to use my backport available here:
https://github.com/bentiss/hid-multitouch
Great - thanks for that! It may be a solution.
it _should_ work on a 3.2. You only have to add your VID/PID in
hid-multitouch to make it work.
Unfortunately not. It seems that writes
On Mon, Sep 9, 2013 at 4:01 PM, Breton M. Saunders wrote:
> On 09/09/13 14:12, Benjamin Tissoires wrote:
>>
>> Hi,
>>
>> On Mon, Sep 9, 2013 at 2:56 PM, Breton M. Saunders
>> wrote:
>>>
>>> Hello,
>>>
>>>I've written a USB device which supports multiple input devices:
>>> * A touch surfa
On 09/09/13 14:12, Benjamin Tissoires wrote:
Hi,
On Mon, Sep 9, 2013 at 2:56 PM, Breton M. Saunders wrote:
Hello,
I've written a USB device which supports multiple input devices:
* A touch surface digitizer (following Microsoft's specification)
* A pen surface digitizer
* A
On Wed, Sep 4, 2013 at 6:31 PM, Kees Cook wrote:
> On Fri, Aug 30, 2013 at 11:27 AM, Kees Cook wrote:
>> On Fri, Aug 30, 2013 at 8:27 AM, Benjamin Tissoires
>> wrote:
>>> On Thu, Aug 29, 2013 at 9:41 PM, Kees Cook wrote:
On Thu, Aug 29, 2013 at 1:59 AM, Benjamin Tissoires
wrote:
On Wed, Sep 4, 2013 at 6:37 PM, Kees Cook wrote:
> These patches introduce a validation function for HID devices that do
> direct report value accesses, solving a number of heap smashing flaws.
>
> This version changes to using an field-index-based checker for the new
> "hid_validate_values()" whi
On 04/09/13 18:37, Kees Cook wrote:
> A HID device could send a malicious output report that would cause the
> logitech-dj HID driver to leak kernel memory contents to the device, or
> trigger a NULL dereference during initialization:
>
> [ 304.424553] usb 1-1: New USB device found, idVendor=046d
On Wed, Sep 4, 2013 at 6:37 PM, Kees Cook wrote:
> A HID device could send a malicious output report that would cause the
> lenovo-tpkbd HID driver to write just beyond the output report allocation
> during initialization, causing a heap overflow:
>
> [ 76.109807] usb 1-1: New USB device found,
On Wed, Sep 4, 2013 at 6:37 PM, Kees Cook wrote:
> A HID device could send a malicious output report that would cause the
> lg, lg3, and lg4 HID drivers to write beyond the output report allocation
> during an event, causing a heap overflow:
>
> [ 325.245240] usb 1-1: New USB device found, idVend
Hi,
On Mon, Sep 9, 2013 at 2:56 PM, Breton M. Saunders wrote:
> Hello,
>
> I've written a USB device which supports multiple input devices:
> * A touch surface digitizer (following Microsoft's specification)
> * A pen surface digitizer
> * A mouse emulator
>
> In windows each of t
On Mon, 9 Sep 2013, android wrote:
> I am a software engineer from GeneralTouch Technology Co., Ltd.
>
> I want to add some driver patches to the linux kernel .
>
> I do these jobs in hid-ids.h and hid-multitouch.c
Adding Henrik and Benjamon to CC for the hid-multitouch driver.
> The main cha
On Wed, Sep 4, 2013 at 6:37 PM, Kees Cook wrote:
> A HID device could send a malicious output report that would cause the
> steelseries HID driver to write beyond the output report allocation
> during initialization, causing a heap overflow:
>
> [ 167.981534] usb 1-1: New USB device found, idVend
Hello,
I've written a USB device which supports multiple input devices:
* A touch surface digitizer (following Microsoft's specification)
* A pen surface digitizer
* A mouse emulator
In windows each of these interfaces are exposed as a separate top
level collection, e.g.:
Usa
On Wed, Sep 4, 2013 at 6:37 PM, Kees Cook wrote:
> This driver must validate the availability of the HID output report and
> its size before it can write LED states via buzz_set_leds(). This stops
> a heap overflow that is possible if a device provides a malicious HID
> output report:
>
> [ 108.1
On Wed, Sep 4, 2013 at 6:37 PM, Kees Cook wrote:
> The zeroplus HID driver was not checking the size of allocated values
> in fields it used. A HID device could send a malicious output report
> that would cause the driver to write beyond the output report allocation
> during initialization, causin
On Wed, Sep 4, 2013 at 6:37 PM, Kees Cook wrote:
> Many drivers need to validate the characteristics of their HID report
> during initialization to avoid misusing the reports. This adds a common
> helper to perform validation of the report exisitng, the field existing,
> and the expected number of
From: Oliver Neukum
Some systems although they have firmware class 'M', which usually
needs a work around to not crash, must not be subjected to the
work around because the work around crashes them. They cannot be
told apart by their own device descriptor, but as they are part
of compound devices
Hi
On Mon, Sep 9, 2013 at 10:25 AM, Florian Echtler wrote:
> On 06.09.2013 15:25, Benjamin Tissoires wrote:
>> Some generic comments:
>> - please always inline the code in the message, it is *much* easier to
>> review and comment it
>> - please directly use a patch format: if the code is good, D
On 06.09.2013 15:25, Benjamin Tissoires wrote:
> Some generic comments:
> - please always inline the code in the message, it is *much* easier to review
> and comment it
> - please directly use a patch format: if the code is good, Dmitry can take it
> directly through his tree
> - add the followin
27 matches
Mail list logo
