1. 14 4月, 2016 7 次提交
  2. 07 4月, 2016 3 次提交
  3. 06 4月, 2016 3 次提交
  4. 05 4月, 2016 1 次提交
    • K
      mm, fs: get rid of PAGE_CACHE_* and page_cache_{get,release} macros · 09cbfeaf
      Kirill A. Shutemov 提交于
      PAGE_CACHE_{SIZE,SHIFT,MASK,ALIGN} macros were introduced *long* time
      ago with promise that one day it will be possible to implement page
      cache with bigger chunks than PAGE_SIZE.
      
      This promise never materialized.  And unlikely will.
      
      We have many places where PAGE_CACHE_SIZE assumed to be equal to
      PAGE_SIZE.  And it's constant source of confusion on whether
      PAGE_CACHE_* or PAGE_* constant should be used in a particular case,
      especially on the border between fs and mm.
      
      Global switching to PAGE_CACHE_SIZE != PAGE_SIZE would cause to much
      breakage to be doable.
      
      Let's stop pretending that pages in page cache are special.  They are
      not.
      
      The changes are pretty straight-forward:
      
       - <foo> << (PAGE_CACHE_SHIFT - PAGE_SHIFT) -> <foo>;
      
       - <foo> >> (PAGE_CACHE_SHIFT - PAGE_SHIFT) -> <foo>;
      
       - PAGE_CACHE_{SIZE,SHIFT,MASK,ALIGN} -> PAGE_{SIZE,SHIFT,MASK,ALIGN};
      
       - page_cache_get() -> get_page();
      
       - page_cache_release() -> put_page();
      
      This patch contains automated changes generated with coccinelle using
      script below.  For some reason, coccinelle doesn't patch header files.
      I've called spatch for them manually.
      
      The only adjustment after coccinelle is revert of changes to
      PAGE_CAHCE_ALIGN definition: we are going to drop it later.
      
      There are few places in the code where coccinelle didn't reach.  I'll
      fix them manually in a separate patch.  Comments and documentation also
      will be addressed with the separate patch.
      
      virtual patch
      
      @@
      expression E;
      @@
      - E << (PAGE_CACHE_SHIFT - PAGE_SHIFT)
      + E
      
      @@
      expression E;
      @@
      - E >> (PAGE_CACHE_SHIFT - PAGE_SHIFT)
      + E
      
      @@
      @@
      - PAGE_CACHE_SHIFT
      + PAGE_SHIFT
      
      @@
      @@
      - PAGE_CACHE_SIZE
      + PAGE_SIZE
      
      @@
      @@
      - PAGE_CACHE_MASK
      + PAGE_MASK
      
      @@
      expression E;
      @@
      - PAGE_CACHE_ALIGN(E)
      + PAGE_ALIGN(E)
      
      @@
      expression E;
      @@
      - page_cache_get(E)
      + get_page(E)
      
      @@
      expression E;
      @@
      - page_cache_release(E)
      + put_page(E)
      Signed-off-by: NKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Acked-by: NMichal Hocko <mhocko@suse.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      09cbfeaf
  5. 04 4月, 2016 3 次提交
  6. 01 4月, 2016 3 次提交
  7. 31 3月, 2016 2 次提交
    • M
      usb: fix regression in SuperSpeed endpoint descriptor parsing · 59b9023c
      Mathias Nyman 提交于
      commit b37d83a6 ("usb: Parse the new USB 3.1 SuperSpeedPlus Isoc
      endpoint companion descriptor") caused a regression in 4.6-rc1 and fails
      to parse SuperSpeed endpoint companion descriptors.
      
      The new SuperSpeedPlus Isoc endpoint companion parsing code incorrectly
      decreased the the remaining buffer size before comparing the size with the
      expected length of the descriptor.
      
      This lead to possible failure in reading the SuperSpeed endpoint companion
      descriptor of the last endpoint, displaying a message like:
      
      "No SuperSpeed endpoint companion for config 1 interface 0 altsetting 0
       ep 129: using minimum values"
      
      Fix it by decreasing the size after comparing it.
      Also finish all the SS endpoint companion parsing before calling SSP isoc
      endpoint parsing function.
      
      Fixes: b37d83a6Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      59b9023c
    • I
      USB: usbip: fix potential out-of-bounds write · b348d7dd
      Ignat Korchagin 提交于
      Fix potential out-of-bounds write to urb->transfer_buffer
      usbip handles network communication directly in the kernel. When receiving a
      packet from its peer, usbip code parses headers according to protocol. As
      part of this parsing urb->actual_length is filled. Since the input for
      urb->actual_length comes from the network, it should be treated as untrusted.
      Any entity controlling the network may put any value in the input and the
      preallocated urb->transfer_buffer may not be large enough to hold the data.
      Thus, the malicious entity is able to write arbitrary data to kernel memory.
      Signed-off-by: NIgnat Korchagin <ignat.korchagin@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b348d7dd
  8. 30 3月, 2016 4 次提交
    • Y
      usb: renesas_usbhs: disable TX IRQ before starting TX DMAC transfer · 6490865c
      Yoshihiro Shimoda 提交于
      This patch adds a code to surely disable TX IRQ of the pipe before
      starting TX DMAC transfer. Otherwise, a lot of unnecessary TX IRQs
      may happen in rare cases when DMAC is used.
      
      Fixes: e73a9891 ("usb: renesas_usbhs: add DMAEngine support")
      Cc: <stable@vger.kernel.org> # v3.1+
      Signed-off-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      6490865c
    • Y
      usb: renesas_usbhs: avoid NULL pointer derefernce in usbhsf_pkt_handler() · 894f2fc4
      Yoshihiro Shimoda 提交于
      When unexpected situation happened (e.g. tx/rx irq happened while
      DMAC is used), the usbhsf_pkt_handler() was possible to cause NULL
      pointer dereference like the followings:
      
      Unable to handle kernel NULL pointer dereference at virtual address 00000000
      pgd = c0004000
      [00000000] *pgd=00000000
      Internal error: Oops: 80000007 [#1] SMP ARM
      Modules linked in: usb_f_acm u_serial g_serial libcomposite
      CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.5.0-rc6-00842-gac57066-dirty #63
      Hardware name: Generic R8A7790 (Flattened Device Tree)
      task: c0729c00 ti: c0724000 task.ti: c0724000
      PC is at 0x0
      LR is at usbhsf_pkt_handler+0xac/0x118
      pc : [<00000000>]    lr : [<c03257e0>]    psr: 60000193
      sp : c0725db8  ip : 00000000  fp : c0725df4
      r10: 00000001  r9 : 00000193  r8 : ef3ccab4
      r7 : ef3cca10  r6 : eea4586c  r5 : 00000000  r4 : ef19ceb4
      r3 : 00000000  r2 : 0000009c  r1 : c0725dc4  r0 : ef19ceb4
      
      This patch adds a condition to avoid the dereference.
      
      Fixes: e73a9891 ("usb: renesas_usbhs: add DMAEngine support")
      Cc: <stable@vger.kernel.org> # v3.1+
      Signed-off-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      894f2fc4
    • F
      usb: gadget: f_midi: Fixed a bug when buflen was smaller than wMaxPacketSize · 03d27ade
      Felipe F. Tonello 提交于
      buflen by default (256) is smaller than wMaxPacketSize (512) in high-speed
      devices.
      
      That caused the OUT endpoint to freeze if the host send any data packet of
      length greater than 256 bytes.
      
      This is an example dump of what happended on that enpoint:
      HOST:   [DATA][Length=260][...]
      DEVICE: [NAK]
      HOST:   [PING]
      DEVICE: [NAK]
      HOST:   [PING]
      DEVICE: [NAK]
      ...
      HOST:   [PING]
      DEVICE: [NAK]
      
      This patch fixes this problem by setting the minimum usb_request's buffer size
      for the OUT endpoint as its wMaxPacketSize.
      Acked-by: NMichal Nazarewicz <mina86@mina86.com>
      Signed-off-by: NFelipe F. Tonello <eu@felipetonello.com>
      Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      03d27ade
    • A
      usb: phy: qcom-8x16: fix regulator API abuse · 7e8ac87a
      Arnd Bergmann 提交于
      gcc warns about the use of regulators in phy_8x16_probe:
      
          drivers/usb/phy/phy-qcom-8x16-usb.c: In function 'phy_8x16_probe':
          drivers/usb/phy/phy-qcom-8x16-usb.c:284:13: error: 'regs[0].consumer' may be used uninitialized in this function [-Werror=maybe-uninitialized]
          drivers/usb/phy/phy-qcom-8x16-usb.c:285:13: error: 'regs[1].consumer' may be used uninitialized in this function [-Werror=maybe-uninitialized]
          drivers/usb/phy/phy-qcom-8x16-usb.c:286:12: error: 'regs[2].consumer' may be used uninitialized in this function [-Werror=maybe-uninitialized]
      
      According to Mark Brown, this is the result of various abuses
      of the PHY interfaces [1], so let's fix the driver instead.
      
      This puts the regulator bulk data into the device structure so it
      gets properly initialized and lets us call regulator_bulk_enable()
      and regulator_bulk_disable() rather than open-coding them.
      
      Setting the voltages the way the driver does is rather pointless
      because for each regulator there is only one valid voltage
      range, so that can just get set up in the DT. As there doesn't
      seem to be any user of the newly added driver yet, we can simply
      make sure the DTs are setting this up right when they get added.
      
      I'm also fixing the handling of regulator_bulk_enable() failure.
      Right now, the driver just ignores any failure, which doesn't make
      sense, so I'm changing it to loudly complain (in case we actually
      had a bug here) and error out.
      
      Doing a fly-by review of the driver, I notice a couple of other
      problems that I'm not addressing here:
      
      - It really should not have been written as a USB PHY driver, but
        instead should use the PHY subsystem.
      
      - The DT compatible string does not follow the usual conventions,
        and it should have a proper identifier in it rather than a wildcard.
      
      - The example in the devicetree binding lists a register address
        that is the same as the actual EHCI host controller in the SoC
        as well as the otg-snps and the ci-hdrc device, which indicates
        that these are probably not even distinct devices (or all but
        one of them are wrong), and if more than one of them tries to
        request the resources correctly, they fail.
      
      [1] https://lkml.org/lkml/2016/1/26/267Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      7e8ac87a
  9. 29 3月, 2016 6 次提交
  10. 19 3月, 2016 5 次提交
    • H
      USB: uas: Reduce can_queue to MAX_CMNDS · 55ff8cfb
      Hans de Goede 提交于
      The uas driver can never queue more then MAX_CMNDS (- 1) tags and tags
      are shared between luns, so there is no need to claim that we can_queue
      some random large number.
      
      Not claiming that we can_queue 65536 commands, fixes the uas driver
      failing to initialize while allocating the tag map with a "Page allocation
      failure (order 7)" error on systems which have been running for a while
      and thus have fragmented memory.
      
      Cc: stable@vger.kernel.org
      Reported-and-tested-by: NYves-Alexis Perez <corsac@corsac.net>
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      55ff8cfb
    • O
      USB: cdc-acm: more sanity checking · 8835ba4a
      Oliver Neukum 提交于
      An attack has become available which pretends to be a quirky
      device circumventing normal sanity checks and crashes the kernel
      by an insufficient number of interfaces. This patch adds a check
      to the code path for quirky devices.
      Signed-off-by: NOliver Neukum <ONeukum@suse.com>
      CC: stable@vger.kernel.org
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8835ba4a
    • O
      USB: usb_driver_claim_interface: add sanity checking · 0b818e39
      Oliver Neukum 提交于
      Attacks that trick drivers into passing a NULL pointer
      to usb_driver_claim_interface() using forged descriptors are
      known. This thwarts them by sanity checking.
      Signed-off-by: NOliver Neukum <ONeukum@suse.com>
      CC: stable@vger.kernel.org
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0b818e39
    • N
      usb/core: usb_alloc_dev(): fix setting of ->portnum · 7222c832
      Nicolai Stange 提交于
      With commit 69bec725 ("USB: core: let USB device know device node"),
      the port1 argument of usb_alloc_dev() gets overwritten as follows:
      
        ... usb_alloc_dev(..., unsigned port1)
        {
          ...
          if (!parent->parent) {
            port1 = usb_hcd_find_raw_port_number(..., port1);
          }
          ...
        }
      
      Later on, this now overwritten port1 gets assigned to ->portnum:
      
        dev->portnum = port1;
      
      However, since xhci_find_raw_port_number() isn't idempotent, the
      aforementioned commit causes a number of KASAN splats like the following:
      
        BUG: KASAN: slab-out-of-bounds in xhci_find_raw_port_number+0x98/0x170
                                             at addr ffff8801d9311670
        Read of size 8 by task kworker/2:1/87
        [...]
        Workqueue: usb_hub_wq hub_event
         0000000000000188 000000005814b877 ffff8800cba17588 ffffffff8191447e
         0000000041b58ab3 ffffffff82a03209 ffffffff819143a2 ffffffff82a252f4
         ffff8801d93115e0 0000000000000188 ffff8801d9311628 ffff8800cba17588
        Call Trace:
         [<ffffffff8191447e>] dump_stack+0xdc/0x15e
         [<ffffffff819143a2>] ? _atomic_dec_and_lock+0xa2/0xa2
         [<ffffffff814e2cd1>] ? print_section+0x61/0xb0
         [<ffffffff814e4939>] print_trailer+0x179/0x2c0
         [<ffffffff814f0d84>] object_err+0x34/0x40
         [<ffffffff814f4388>] kasan_report_error+0x2f8/0x8b0
         [<ffffffff814eb91e>] ? __slab_alloc+0x5e/0x90
         [<ffffffff812178c0>] ? __lock_is_held+0x90/0x130
         [<ffffffff814f5091>] kasan_report+0x71/0xa0
         [<ffffffff814ec082>] ? kmem_cache_alloc_trace+0x212/0x560
         [<ffffffff81d99468>] ? xhci_find_raw_port_number+0x98/0x170
         [<ffffffff814f33d4>] __asan_load8+0x64/0x70
         [<ffffffff81d99468>] xhci_find_raw_port_number+0x98/0x170
         [<ffffffff81db0105>] xhci_setup_addressable_virt_dev+0x235/0xa10
         [<ffffffff81d9ea51>] xhci_setup_device+0x3c1/0x1430
         [<ffffffff8121cddd>] ? trace_hardirqs_on+0xd/0x10
         [<ffffffff81d9fac0>] ? xhci_setup_device+0x1430/0x1430
         [<ffffffff81d9fad3>] xhci_address_device+0x13/0x20
         [<ffffffff81d2081a>] hub_port_init+0x55a/0x1550
         [<ffffffff81d28705>] hub_event+0xef5/0x24d0
         [<ffffffff81d27810>] ? hub_port_debounce+0x2f0/0x2f0
         [<ffffffff8195e1ee>] ? debug_object_deactivate+0x1be/0x270
         [<ffffffff81210203>] ? print_rt_rq+0x53/0x2d0
         [<ffffffff8121657d>] ? trace_hardirqs_off+0xd/0x10
         [<ffffffff8226acfb>] ? _raw_spin_unlock_irqrestore+0x5b/0x60
         [<ffffffff81250000>] ? irq_domain_set_hwirq_and_chip+0x30/0xb0
         [<ffffffff81256339>] ? debug_lockdep_rcu_enabled+0x39/0x40
         [<ffffffff812178c0>] ? __lock_is_held+0x90/0x130
         [<ffffffff81196877>] process_one_work+0x567/0xec0
        [...]
      
      Afterwards, xhci reports some functional errors:
      
        xhci_hcd 0000:00:14.0: ERROR: unexpected setup address command completion
                                      code 0x11.
        xhci_hcd 0000:00:14.0: ERROR: unexpected setup address command completion
                                      code 0x11.
        usb 4-3: device not accepting address 2, error -22
      
      Fix this by not overwriting the port1 argument in usb_alloc_dev(), but
      storing the raw port number as required by OF in an additional variable,
      raw_port.
      
      Fixes: 69bec725 ("USB: core: let USB device know device node")
      Signed-off-by: NNicolai Stange <nicstange@gmail.com>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7222c832
    • J
      USB: iowarrior: fix oops with malicious USB descriptors · 4ec0ef3a
      Josh Boyer 提交于
      The iowarrior driver expects at least one valid endpoint.  If given
      malicious descriptors that specify 0 for the number of endpoints,
      it will crash in the probe function.  Ensure there is at least
      one endpoint on the interface before using it.
      
      The full report of this issue can be found here:
      http://seclists.org/bugtraq/2016/Mar/87Reported-by: NRalf Spenneberg <ralf@spenneberg.net>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NJosh Boyer <jwboyer@fedoraproject.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4ec0ef3a
  11. 18 3月, 2016 1 次提交
  12. 15 3月, 2016 1 次提交
  13. 11 3月, 2016 1 次提交