1. 29 7月, 2014 1 次提交
  2. 26 7月, 2014 1 次提交
    • B
      Input: wacom - switch from an USB driver to a HID driver · 29b47391
      Benjamin Tissoires 提交于
      All USB Wacom tablets are actually HID devices.
      For historical reasons, they are handled as plain USB devices.
      The current code makes more and more reference to the HID subsystem
      like implementing its own HID report descriptor parser to handle new
      devices.
      
      From the user point of view, we can transparently switch from this state
      to a driver handled in the HID subsystem and clean up a lot of USB specific
      code in the wacom.ko driver.
      
      The other benefit once the USB dependecies have been removed is that we can
      use a tool like uhid to make regression tests and allow further cleanup or
      new implementations without risking breaking current behaviors.
      
      To match the current handling of devices in wacom_wac.c, we rely on the
      hid_type set by usbhid. usbhid sets the hid_type to HID_TYPE_USBMOUSE when
      it sees a USB boot mouse protocol declared and HID_TYPE_USBNONE when the
      device is plain HID. There is thus a one to one matching between the list
      of supported devices before and after the switch from USB to HID.
      Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Reviewed-by: NJason Gerecke <killertofu@gmail.com>
      Tested-by: NJason Gerecke <killertofu@gmail.com>
      Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      29b47391
  3. 03 6月, 2014 1 次提交
  4. 22 5月, 2014 1 次提交
  5. 09 4月, 2014 1 次提交
  6. 14 3月, 2014 2 次提交
  7. 05 3月, 2014 1 次提交
  8. 25 2月, 2014 1 次提交
  9. 17 2月, 2014 6 次提交
  10. 29 1月, 2014 1 次提交
  11. 13 9月, 2013 1 次提交
  12. 04 9月, 2013 1 次提交
  13. 29 8月, 2013 1 次提交
    • K
      HID: validate HID report id size · 43622021
      Kees Cook 提交于
      The "Report ID" field of a HID report is used to build indexes of
      reports. The kernel's index of these is limited to 256 entries, so any
      malicious device that sets a Report ID greater than 255 will trigger
      memory corruption on the host:
      
      [ 1347.156239] BUG: unable to handle kernel paging request at ffff88094958a878
      [ 1347.156261] IP: [<ffffffff813e4da0>] hid_register_report+0x2a/0x8b
      
      CVE-2013-2888
      Signed-off-by: NKees Cook <keescook@chromium.org>
      Cc: stable@kernel.org
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      43622021
  14. 27 8月, 2013 2 次提交
  15. 31 7月, 2013 2 次提交
  16. 22 7月, 2013 1 次提交
    • J
      HID: fix data access in implement() · 27ce4050
      Jiri Kosina 提交于
      implement() is setting bytes in LE data stream. In case the data is not
      aligned to 64bits, it reads past the allocated buffer. It doesn't really
      change any value there (it's properly bitmasked), but in case that this
      read past the boundary hits a page boundary, pagefault happens when
      accessing 64bits of 'x' in implement(), and kernel oopses.
      
      This happens much more often when numbered reports are in use, as the
      initial 8bit skip in the buffer makes the whole process work on values
      which are not aligned to 64bits.
      
      This problem dates back to attempts in 2005 and 2006 to make implement()
      and extract() as generic as possible, and even back then the problem
      was realized by Adam Kroperlin, but falsely assumed to be impossible
      to cause any harm:
      
        http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg47690.html
      
      I have made several attempts at fixing it "on the spot" directly in
      implement(), but the results were horrible; the special casing for processing
      last 64bit chunk and switching to different math makes it unreadable mess.
      
      I therefore took a path to allocate a few bytes more which will never make
      it into final report, but are there as a cushion for all the 64bit math
      operations happening in implement() and extract().
      
      All callers of hid_output_report() are converted at the same time to allocate
      the buffer by newly introduced hid_alloc_report_buf() helper.
      
      Bruno noticed that the whole raw_size test can be dropped as well, as
      hid_alloc_report_buf() makes sure that the buffer is always of a proper
      size.
      Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Acked-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      27ce4050
  17. 06 5月, 2013 1 次提交
    • J
      HID: debug: fix RCU preemption issue · 1deb9d34
      Jiri Kosina 提交于
      Commit 2353f2be ("HID: protect hid_debug_list") introduced mutex
      locking around debug_list access to prevent SMP races when debugfs
      nodes are being operated upon by multiple userspace processess.
      
      mutex is not a proper synchronization primitive though, as the hid-debug
      callbacks are being called from atomic contexts.
      
      We also have to be careful about disabling IRQs when taking the lock
      to prevent deadlock against IRQ handlers.
      
      Benjamin reports this has also been reported in RH bugzilla as bug #958935.
      
       ===============================
       [ INFO: suspicious RCU usage. ]
       3.9.0+ #94 Not tainted
       -------------------------------
       include/linux/rcupdate.h:476 Illegal context switch in RCU read-side critical section!
      
       other info that might help us debug this:
      
       rcu_scheduler_active = 1, debug_locks = 0
       4 locks held by Xorg/5502:
        #0:  (&evdev->mutex){+.+...}, at: [<ffffffff81512c3d>] evdev_write+0x6d/0x160
        #1:  (&(&dev->event_lock)->rlock#2){-.-...}, at: [<ffffffff8150dd9b>] input_inject_event+0x5b/0x230
        #2:  (rcu_read_lock){.+.+..}, at: [<ffffffff8150dd82>] input_inject_event+0x42/0x230
        #3:  (&(&usbhid->lock)->rlock){-.....}, at: [<ffffffff81565289>] usb_hidinput_input_event+0x89/0x120
      
       stack backtrace:
       CPU: 0 PID: 5502 Comm: Xorg Not tainted 3.9.0+ #94
       Hardware name: Dell Inc. OptiPlex 390/0M5DCD, BIOS A09 07/24/2012
        0000000000000001 ffff8800689c7c38 ffffffff816f249f ffff8800689c7c68
        ffffffff810acb1d 0000000000000000 ffffffff81a03ac7 000000000000019d
        0000000000000000 ffff8800689c7c90 ffffffff8107cda7 0000000000000000
       Call Trace:
        [<ffffffff816f249f>] dump_stack+0x19/0x1b
        [<ffffffff810acb1d>] lockdep_rcu_suspicious+0xfd/0x130
        [<ffffffff8107cda7>] __might_sleep+0xc7/0x230
        [<ffffffff816f7770>] mutex_lock_nested+0x40/0x3a0
        [<ffffffff81312ac4>] ? vsnprintf+0x354/0x640
        [<ffffffff81553cc4>] hid_debug_event+0x34/0x100
        [<ffffffff81554197>] hid_dump_input+0x67/0xa0
        [<ffffffff81556430>] hid_set_field+0x50/0x120
        [<ffffffff8156529a>] usb_hidinput_input_event+0x9a/0x120
        [<ffffffff8150d89e>] input_handle_event+0x8e/0x530
        [<ffffffff8150df10>] input_inject_event+0x1d0/0x230
        [<ffffffff8150dd82>] ? input_inject_event+0x42/0x230
        [<ffffffff81512cae>] evdev_write+0xde/0x160
        [<ffffffff81185038>] vfs_write+0xc8/0x1f0
        [<ffffffff81185535>] SyS_write+0x55/0xa0
        [<ffffffff81704482>] system_call_fastpath+0x16/0x1b
       BUG: sleeping function called from invalid context at kernel/mutex.c:413
       in_atomic(): 1, irqs_disabled(): 1, pid: 5502, name: Xorg
       INFO: lockdep is turned off.
       irq event stamp: 1098574
       hardirqs last  enabled at (1098573): [<ffffffff816fb53f>] _raw_spin_unlock_irqrestore+0x3f/0x70
       hardirqs last disabled at (1098574): [<ffffffff816faaf5>] _raw_spin_lock_irqsave+0x25/0xa0
       softirqs last  enabled at (1098306): [<ffffffff8104971f>] __do_softirq+0x18f/0x3c0
       softirqs last disabled at (1097867): [<ffffffff81049ad5>] irq_exit+0xa5/0xb0
       CPU: 0 PID: 5502 Comm: Xorg Not tainted 3.9.0+ #94
       Hardware name: Dell Inc. OptiPlex 390/0M5DCD, BIOS A09 07/24/2012
        ffffffff81a03ac7 ffff8800689c7c68 ffffffff816f249f ffff8800689c7c90
        ffffffff8107ce60 0000000000000000 ffff8800689c7fd8 ffff88006a62c800
        ffff8800689c7d10 ffffffff816f7770 ffff8800689c7d00 ffffffff81312ac4
       Call Trace:
        [<ffffffff816f249f>] dump_stack+0x19/0x1b
        [<ffffffff8107ce60>] __might_sleep+0x180/0x230
        [<ffffffff816f7770>] mutex_lock_nested+0x40/0x3a0
        [<ffffffff81312ac4>] ? vsnprintf+0x354/0x640
        [<ffffffff81553cc4>] hid_debug_event+0x34/0x100
        [<ffffffff81554197>] hid_dump_input+0x67/0xa0
        [<ffffffff81556430>] hid_set_field+0x50/0x120
        [<ffffffff8156529a>] usb_hidinput_input_event+0x9a/0x120
        [<ffffffff8150d89e>] input_handle_event+0x8e/0x530
        [<ffffffff8150df10>] input_inject_event+0x1d0/0x230
        [<ffffffff8150dd82>] ? input_inject_event+0x42/0x230
        [<ffffffff81512cae>] evdev_write+0xde/0x160
        [<ffffffff81185038>] vfs_write+0xc8/0x1f0
        [<ffffffff81185535>] SyS_write+0x55/0xa0
        [<ffffffff81704482>] system_call_fastpath+0x16/0x1b
      Reported-by: Nmajianpeng <majianpeng@gmail.com>
      Reported-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
      Reviewed-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      1deb9d34
  18. 30 4月, 2013 1 次提交
    • J
      HID: protect hid_debug_list · 2353f2be
      Jiri Kosina 提交于
      Accesses to hid_device->hid_debug_list are not serialized properly, which
      could result in SMP concurrency issues when HID debugfs events are accessesed
      by multiple userspace processess.
      
      Serialize all the list operations by a mutex.
      
      Spotted by Al Viro.
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      2353f2be
  19. 27 3月, 2013 1 次提交
  20. 07 3月, 2013 1 次提交
  21. 01 3月, 2013 1 次提交
    • A
      HID: Separate struct hid_device's driver_lock into two locks. · c849a614
      Andrew de los Reyes 提交于
      This patch separates struct hid_device's driver_lock into two. The
      goal is to allow hid device drivers to receive input during their
      probe() or remove() function calls. This is necessary because some
      drivers need to communicate with the device to determine parameters
      needed during probe (e.g., size of a multi-touch surface), and if
      possible, may perfer to communicate with a device on host-initiated
      disconnect (e.g., to put it into a low-power state).
      
      Historically, three functions used driver_lock:
      
      - hid_device_probe: blocks to acquire lock
      - hid_device_remove: blocks to acquire lock
      - hid_input_report: if locked returns -EBUSY, else acquires lock
      
      This patch adds another lock (driver_input_lock) which is used to
      block input from occurring. The lock behavior is now:
      
      - hid_device_probe: blocks to acq. driver_lock, then driver_input_lock
      - hid_device_remove: blocks to acq. driver_lock, then driver_input_lock
      - hid_input_report: if driver_input_lock locked returns -EBUSY, else
        acquires driver_input_lock
      
      This patch also adds two helper functions to be called during probe()
      or remove(): hid_device_io_start() and hid_device_io_stop(). These
      functions lock and unlock, respectively, driver_input_lock; they also
      make a note of whether they did so that hid-core knows if a driver has
      changed the lock state.
      
      This patch results in no behavior change for existing devices and
      drivers. However, during a probe() or remove() function call in a
      driver, that driver may now selectively call hid_device_io_start() to
      let input events come through, then optionally call
      hid_device_io_stop() to stop them.
      Signed-off-by: NAndrew de los Reyes <adlr@chromium.org>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      c849a614
  22. 25 2月, 2013 2 次提交
  23. 05 2月, 2013 1 次提交
  24. 03 1月, 2013 2 次提交
  25. 12 12月, 2012 1 次提交
  26. 07 12月, 2012 1 次提交
  27. 15 11月, 2012 3 次提交
  28. 13 10月, 2012 1 次提交