1. 29 Nov, 2013 29 commits
  2. 20 Nov, 2013 11 commits
    • Greg Kroah-Hartman's avatar
      Linux 3.12.1 · 6beb1be0
      Greg Kroah-Hartman authored
      6beb1be0
    • Xenia Ragiadakou's avatar
      usbcore: set lpm_capable field for LPM capable root hubs · 60e102ac
      Xenia Ragiadakou authored
      commit 9df89d85 upstream.
      
      This patch sets the lpm_capable field for root hubs with LPM capabilities.
      Signed-off-by: default avatarXenia Ragiadakou <burzalodowa@gmail.com>
      Reported-by: default avatarMartin MOKREJS <mmokrejs@gmail.com>
      Suggested-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      60e102ac
    • Johan Hovold's avatar
      backlight: atmel-pwm-bl: fix deferred probe from __init · beb92943
      Johan Hovold authored
      commit 9d3fde86 upstream.
      
      Move probe out of __init section and don't use platform_driver_probe
      which cannot be used with deferred probing.
      
      Since commit e9354576 ("gpiolib: Defer failed gpio requests by default")
      this driver might return -EPROBE_DEFER if a gpio_request fails.
      
      Cc: Richard Purdie <rpurdie@rpsys.net>
      Cc: Jingoo Han <jg1.han@samsung.com>
      Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
      Signed-off-by: default avatarJohan Hovold <jhovold@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      beb92943
    • Johan Hovold's avatar
      misc: atmel_pwm: add deferred-probing support · 0fe6a2bc
      Johan Hovold authored
      commit 5c6d6fd1 upstream.
      
      Two drivers (atmel-pwm-bl and leds-atmel-pwm) currently depend on the
      atmel_pwm driver to have bound to any pwm-device before their devices
      are probed.
      
      Support deferred probing of such devices by making sure to return
      -EPROBE_DEFER from pwm_channel_alloc when no pwm-device has yet been
      bound.
      Signed-off-by: default avatarJohan Hovold <jhovold@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0fe6a2bc
    • Steven Rostedt's avatar
      tracing: Fix potential out-of-bounds in trace_get_user() · a80d0c3c
      Steven Rostedt authored
      commit 057db848 upstream.
      
      Andrey reported the following report:
      
      ERROR: AddressSanitizer: heap-buffer-overflow on address ffff8800359c99f3
      ffff8800359c99f3 is located 0 bytes to the right of 243-byte region [ffff8800359c9900, ffff8800359c99f3)
      Accessed by thread T13003:
        #0 ffffffff810dd2da (asan_report_error+0x32a/0x440)
        #1 ffffffff810dc6b0 (asan_check_region+0x30/0x40)
        #2 ffffffff810dd4d3 (__tsan_write1+0x13/0x20)
        #3 ffffffff811cd19e (ftrace_regex_release+0x1be/0x260)
        #4 ffffffff812a1065 (__fput+0x155/0x360)
        #5 ffffffff812a12de (____fput+0x1e/0x30)
        #6 ffffffff8111708d (task_work_run+0x10d/0x140)
        #7 ffffffff810ea043 (do_exit+0x433/0x11f0)
        #8 ffffffff810eaee4 (do_group_exit+0x84/0x130)
        #9 ffffffff810eafb1 (SyS_exit_group+0x21/0x30)
        #10 ffffffff81928782 (system_call_fastpath+0x16/0x1b)
      
      Allocated by thread T5167:
        #0 ffffffff810dc778 (asan_slab_alloc+0x48/0xc0)
        #1 ffffffff8128337c (__kmalloc+0xbc/0x500)
        #2 ffffffff811d9d54 (trace_parser_get_init+0x34/0x90)
        #3 ffffffff811cd7b3 (ftrace_regex_open+0x83/0x2e0)
        #4 ffffffff811cda7d (ftrace_filter_open+0x2d/0x40)
        #5 ffffffff8129b4ff (do_dentry_open+0x32f/0x430)
        #6 ffffffff8129b668 (finish_open+0x68/0xa0)
        #7 ffffffff812b66ac (do_last+0xb8c/0x1710)
        #8 ffffffff812b7350 (path_openat+0x120/0xb50)
        #9 ffffffff812b8884 (do_filp_open+0x54/0xb0)
        #10 ffffffff8129d36c (do_sys_open+0x1ac/0x2c0)
        #11 ffffffff8129d4b7 (SyS_open+0x37/0x50)
        #12 ffffffff81928782 (system_call_fastpath+0x16/0x1b)
      
      Shadow bytes around the buggy address:
        ffff8800359c9700: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
        ffff8800359c9780: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa
        ffff8800359c9800: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
        ffff8800359c9880: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
        ffff8800359c9900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      =>ffff8800359c9980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00[03]fb
        ffff8800359c9a00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
        ffff8800359c9a80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
        ffff8800359c9b00: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
        ffff8800359c9b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        ffff8800359c9c00: 00 00 00 00 00 00 00 00 fa fa fa fa fa fa fa fa
      Shadow byte legend (one shadow byte represents 8 application bytes):
        Addressable:           00
        Partially addressable: 01 02 03 04 05 06 07
        Heap redzone:          fa
        Heap kmalloc redzone:  fb
        Freed heap region:     fd
        Shadow gap:            fe
      
      The out-of-bounds access happens on 'parser->buffer[parser->idx] = 0;'
      
      Although the crash happened in ftrace_regex_open() the real bug
      occurred in trace_get_user() where there's an incrementation to
      parser->idx without a check against the size. The way it is triggered
      is if userspace sends in 128 characters (EVENT_BUF_SIZE + 1), the loop
      that reads the last character stores it and then breaks out because
      there is no more characters. Then the last character is read to determine
      what to do next, and the index is incremented without checking size.
      
      Then the caller of trace_get_user() usually nulls out the last character
      with a zero, but since the index is equal to the size, it writes a nul
      character after the allocated space, which can corrupt memory.
      
      Luckily, only root user has write access to this file.
      
      Link: http://lkml.kernel.org/r/20131009222323.04fd1a0d@gandalf.local.homeReported-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a80d0c3c
    • Anssi Hannula's avatar
      ALSA: hda - hdmi: Fix reported channel map on common default layouts · 7e6d47e2
      Anssi Hannula authored
      commit 56cac413 upstream.
      
      hdmi_setup_fake_chmap() is supposed to set the reported channel map when
      the channel map is not specified by the user.
      
      However, the function indexes channel_allocations[] with a wrong value
      and extracts the wrong nibble from hdmi_channel_mapping[], causing wrong
      channel maps to be shown.
      
      Fix those issues.
      
      Tested on Intel HDMI to correctly generate various channel maps, for
      example 3,4,14,15,7,8,5,6 (instead of incorrect 3,4,8,7,5,6,14,0) for
      standard 7.1 channel audio. (Note that the side and rear channels are
      reported as RL/RR and RLC/RRC, respectively, as per the CEA-861
      standard, instead of the more traditional SL/SR and RL/RR.)
      
      Note that this only fixes the layouts that only contain traditional 7.1
      speakers (2.0, 2.1, 4.0, 5.1, 7.1, etc.). E.g. the rear center of 6.1
      is still being shown wrongly due to an issue with from_cea_slot()
      which will be fixed in a later patch.
      Signed-off-by: default avatarAnssi Hannula <anssi.hannula@iki.fi>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7e6d47e2
    • Rui li's avatar
      USB: add new zte 3g-dongle's pid to option.c · eef0a125
      Rui li authored
      commit 0636fc50 upstream.
      Signed-off-by: default avatarRui li <li.rui27@zte.com.cn>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      eef0a125
    • Gerd Hoffmann's avatar
      hyperv-fb: add pci stub · 65c27e27
      Gerd Hoffmann authored
      commit 7ad96847 upstream.
      
      This patch adds a pci stub driver to hyper-fb.  The hyperv framebuffer
      driver will bind to the pci device then, so linux kernel and userspace
      know there is a proper kernel driver for the device active.  lspci shows
      this for example:
      
      [root@dhcp231 ~]# lspci -vs8
      00:08.0 VGA compatible controller: Microsoft Corporation Hyper-V virtual
      VGA (prog-if 00 [VGA controller])
              Flags: bus master, fast devsel, latency 0, IRQ 11
              Memory at f8000000 (32-bit, non-prefetchable) [size=64M]
              Expansion ROM at <unassigned> [disabled]
              Kernel driver in use: hyperv_fb
      
      Another effect is that the xorg vesa driver will not attach to the
      device and thus the Xorg server will automatically use the fbdev
      driver instead.
      Signed-off-by: default avatarGerd Hoffmann <kraxel@redhat.com>
      Acked-by: default avatarHaiyang Zhang <haiyangz@microsoft.com>
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      65c27e27
    • Hannes Frederic Sowa's avatar
      ipv6: reset dst.expires value when clearing expire flag · f5fa9283
      Hannes Frederic Sowa authored
      [ Upstream commit 01ba16d6 ]
      
      On receiving a packet too big icmp error we update the expire value by
      calling rt6_update_expires. This function uses dst_set_expires which is
      implemented that it can only reduce the expiration value of the dst entry.
      
      If we insert new routing non-expiry information into the ipv6 fib where
      we already have a matching rt6_info we only clear the RTF_EXPIRES flag
      in rt6i_flags and leave the dst.expires value as is.
      
      When new mtu information arrives for that cached dst_entry we again
      call dst_set_expires. This time it won't update the dst.expire value
      because we left the dst.expire value intact from the last update. So
      dst_set_expires won't touch dst.expires.
      
      Fix this by resetting dst.expires when clearing the RTF_EXPIRE flag.
      dst_set_expires checks for a zero expiration and updates the
      dst.expires.
      
      In the past this (not updating dst.expires) was necessary because
      dst.expire was placed in a union with the dst_entry *from reference
      and rt6_clean_expires did assign NULL to it. This split happend in
      ecd98837 ("ipv6: fix race condition
      regarding dst->expires and dst->from").
      Reported-by: default avatarSteinar H. Gunderson <sgunderson@bigfoot.com>
      Reported-by: default avatarValentijn Sessink <valentyn@blub.net>
      Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Tested-by: default avatarValentijn Sessink <valentyn@blub.net>
      Signed-off-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f5fa9283
    • Hannes Frederic Sowa's avatar
      ipv6: ip6_dst_check needs to check for expired dst_entries · f3e0e136
      Hannes Frederic Sowa authored
      [ Upstream commit e3bc10bd ]
      
      On receiving a packet too big icmp error we check if our current cached
      dst_entry in the socket is still valid. This validation check did not
      care about the expiration of the (cached) route.
      
      The error path I traced down:
      The socket receives a packet too big mtu notification. It still has a
      valid dst_entry and thus issues the ip6_rt_pmtu_update on this dst_entry,
      setting RTF_EXPIRE and updates the dst.expiration value (which could
      fail because of not up-to-date expiration values, see previous patch).
      
      In some seldom cases we race with a) the ip6_fib gc or b) another routing
      lookup which would result in a recreation of the cached rt6_info from its
      parent non-cached rt6_info. While copying the rt6_info we reinitialize the
      metrics store by copying it over from the parent thus invalidating the
      just installed pmtu update (both dsts use the same key to the inetpeer
      storage). The dst_entry with the just invalidated metrics data would
      just get its RTF_EXPIRES flag cleared and would continue to stay valid
      for the socket.
      
      We should have not issued the pmtu update on the already expired dst_entry
      in the first placed. By checking the expiration on the dst entry and
      doing a relookup in case it is out of date we close the race because
      we would install a new rt6_info into the fib before we issue the pmtu
      update, thus closing this race.
      
      Not reliably updating the dst.expire value was fixed by the patch "ipv6:
      reset dst.expires value when clearing expire flag".
      Reported-by: default avatarSteinar H. Gunderson <sgunderson@bigfoot.com>
      Reported-by: default avatarValentijn Sessink <valentyn@blub.net>
      Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Tested-by: default avatarValentijn Sessink <valentyn@blub.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f3e0e136
    • Yuchung Cheng's avatar
      tcp: do not rearm RTO when future data are sacked · f22ede93
      Yuchung Cheng authored
      [ Upstream commit 2f715c1d ]
      
      Patch ed08495c "tcp: use RTT from SACK for RTO" always re-arms RTO upon
      obtaining a RTT sample from newly sacked data.
      
      But technically RTO should only be re-armed when the data sent before
      the last (re)transmission of write queue head are (s)acked. Otherwise
      the RTO may continue to extend during loss recovery on data sent
      in the future.
      
      Note that RTTs from ACK or timestamps do not have this problem, as the RTT
      source must be from data sent before.
      
      The new RTO re-arm policy is
      1) Always re-arm RTO if SND.UNA is advanced
      2) Re-arm RTO if sack RTT is available, provided the sacked data was
         sent before the last time write_queue_head was sent.
      Signed-off-by: default avatarLarry Brakmo <brakmo@google.com>
      Signed-off-by: default avatarYuchung Cheng <ycheng@google.com>
      Acked-by: default avatarNeal Cardwell <ncardwell@google.com>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f22ede93