1. 03 Mar, 2015 8 commits
  2. 02 Mar, 2015 32 commits
    • Hans de Goede's avatar
      ideapad-laptop: Change Lenovo Yoga 2 series rfkill handling · f58ad536
      Hans de Goede authored
      commit ce363c2b upstream.
      
      It seems that the same problems which lead to adding an rfkill blacklist and
      putting the Lenovo Yoga 2 11 on it are also present on the Lenovo Yoga 2 13
      and Lenovo Yoga 2 Pro too:
      https://bugzilla.redhat.com/show_bug.cgi?id=1021036
      https://forums.lenovo.com/t5/Linux-Discussion/Yoga-2-13-not-Pro-Linux-Warning/m-p/1517612
      
      Testing has shown that the firmware rfkill settings are persistent over
      reboots. So blacklisting the driver is not good enough, if the wifi is blocked
      at the firmware level the wifi needs to be explictly unblocked through the
      ideapad-laptop interface.
      
      And at least on the Lenovo Yoga 2 13 the VPCCMD_RF register which on devices
      with hardware kill switch reports the hardware switch state, needs to be
      explictly set to 1 (radio enabled / not blocked).
      
      So this patch does 3 things to get proper rfkill handling on these models:
      
      1) Instead of blacklisting the rfkill functionality, which means that people
      with a firmware blocked wifi get stuck in that situation, ignore the value
      reported by the not present hardware rfkill switch, as this is what is causing
      ideapad-laptop to wrongly report all radios as hardware blocks. But do register
      the rfkill interfaces so that the user can soft [un]block them.
      
      2) On models without a hardware rfkill switch, explictly set VPCCMD_RF to 1
      
      3) Drop the " 11" postfix from the dmi match string, as the entire Yoga 2
      series is affected.
      
      Yoga 2 11:
      Reported-and-tested-by: default avatarVincent Gerris <vgerris@gmail.com>
      
      Yoga 2 13:
      Tested-by: madls05 <http://ubuntuforums.org/showthread.php?t=2215044>
      
      Yoga 2 Pro:
      Reported-and-tested-by: default avatarPeter F. Patel-Schneider <pfpschneider@gmail.com>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarMatthew Garrett <matthew.garrett@nebula.com>
      Cc: Gaudenz Steinlin <gaudenz@debian.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      f58ad536
    • Daniel Borkmann's avatar
      ipv6: mld: fix add_grhead skb_over_panic for devs with large MTUs · c562e7c8
      Daniel Borkmann authored
      commit 4c672e4b upstream.
      
      It has been reported that generating an MLD listener report on
      devices with large MTUs (e.g. 9000) and a high number of IPv6
      addresses can trigger a skb_over_panic():
      
      skbuff: skb_over_panic: text:ffffffff80612a5d len:3776 put:20
      head:ffff88046d751000 data:ffff88046d751010 tail:0xed0 end:0xec0
      dev:port1
       ------------[ cut here ]------------
      kernel BUG at net/core/skbuff.c:100!
      invalid opcode: 0000 [#1] SMP
      Modules linked in: ixgbe(O)
      CPU: 3 PID: 0 Comm: swapper/3 Tainted: G O 3.14.23+ #4
      [...]
      Call Trace:
       <IRQ>
       [<ffffffff80578226>] ? skb_put+0x3a/0x3b
       [<ffffffff80612a5d>] ? add_grhead+0x45/0x8e
       [<ffffffff80612e3a>] ? add_grec+0x394/0x3d4
       [<ffffffff80613222>] ? mld_ifc_timer_expire+0x195/0x20d
       [<ffffffff8061308d>] ? mld_dad_timer_expire+0x45/0x45
       [<ffffffff80255b5d>] ? call_timer_fn.isra.29+0x12/0x68
       [<ffffffff80255d16>] ? run_timer_softirq+0x163/0x182
       [<ffffffff80250e6f>] ? __do_softirq+0xe0/0x21d
       [<ffffffff8025112b>] ? irq_exit+0x4e/0xd3
       [<ffffffff802214bb>] ? smp_apic_timer_interrupt+0x3b/0x46
       [<ffffffff8063f10a>] ? apic_timer_interrupt+0x6a/0x70
      
      mld_newpack() skb allocations are usually requested with dev->mtu
      in size, since commit 72e09ad1 ("ipv6: avoid high order allocations")
      we have changed the limit in order to be less likely to fail.
      
      However, in MLD/IGMP code, we have some rather ugly AVAILABLE(skb)
      macros, which determine if we may end up doing an skb_put() for
      adding another record. To avoid possible fragmentation, we check
      the skb's tailroom as skb->dev->mtu - skb->len, which is a wrong
      assumption as the actual max allocation size can be much smaller.
      
      The IGMP case doesn't have this issue as commit 57e1ab6e
      ("igmp: refine skb allocations") stores the allocation size in
      the cb[].
      
      Set a reserved_tailroom to make it fit into the MTU and use
      skb_availroom() helper instead. This also allows to get rid of
      igmp_skb_size().
      Reported-by: default avatarWei Liu <lw1a2.jing@gmail.com>
      Fixes: 72e09ad1 ("ipv6: avoid high order allocations")
      Signed-off-by: default avatarDaniel Borkmann <dborkman@redhat.com>
      Cc: Eric Dumazet <edumazet@google.com>
      Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
      Cc: David L Stevens <david.stevens@oracle.com>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Acked-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      c562e7c8
    • Johan Hovold's avatar
      gpio: sysfs: fix gpio attribute-creation race · 58409c4e
      Johan Hovold authored
      commit ebbeba12 upstream.
      
      Fix attribute-creation race with userspace by using the default group
      to create also the contingent gpio device attributes.
      
      Fixes: d8f388d8 ("gpio: sysfs interface")
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      [ luis: backported to 3.16:
        - all changes in drivers/gpio/gpiolib.c
        - adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      58409c4e
    • Daniel Borkmann's avatar
      net: sctp: fix race for one-to-many sockets in sendmsg's auto associate · 11fd056b
      Daniel Borkmann authored
      commit 2061dcd6 upstream.
      
      I.e. one-to-many sockets in SCTP are not required to explicitly
      call into connect(2) or sctp_connectx(2) prior to data exchange.
      Instead, they can directly invoke sendmsg(2) and the SCTP stack
      will automatically trigger connection establishment through 4WHS
      via sctp_primitive_ASSOCIATE(). However, this in its current
      implementation is racy: INIT is being sent out immediately (as
      it cannot be bundled anyway) and the rest of the DATA chunks are
      queued up for later xmit when connection is established, meaning
      sendmsg(2) will return successfully. This behaviour can result
      in an undesired side-effect that the kernel made the application
      think the data has already been transmitted, although none of it
      has actually left the machine, worst case even after close(2)'ing
      the socket.
      
      Instead, when the association from client side has been shut down
      e.g. first gracefully through SCTP_EOF and then close(2), the
      client could afterwards still receive the server's INIT_ACK due
      to a connection with higher latency. This INIT_ACK is then considered
      out of the blue and hence responded with ABORT as there was no
      alive assoc found anymore. This can be easily reproduced f.e.
      with sctp_test application from lksctp. One way to fix this race
      is to wait for the handshake to actually complete.
      
      The fix defers waiting after sctp_primitive_ASSOCIATE() and
      sctp_primitive_SEND() succeeded, so that DATA chunks cooked up
      from sctp_sendmsg() have already been placed into the output
      queue through the side-effect interpreter, and therefore can then
      be bundeled together with COOKIE_ECHO control chunks.
      
      strace from example application (shortened):
      
      socket(PF_INET, SOCK_SEQPACKET, IPPROTO_SCTP) = 3
      sendmsg(3, {msg_name(28)={sa_family=AF_INET, sin_port=htons(8888), sin_addr=inet_addr("192.168.1.115")},
                 msg_iov(1)=[{"hello", 5}], msg_controllen=0, msg_flags=0}, 0) = 5
      sendmsg(3, {msg_name(28)={sa_family=AF_INET, sin_port=htons(8888), sin_addr=inet_addr("192.168.1.115")},
                 msg_iov(1)=[{"hello", 5}], msg_controllen=0, msg_flags=0}, 0) = 5
      sendmsg(3, {msg_name(28)={sa_family=AF_INET, sin_port=htons(8888), sin_addr=inet_addr("192.168.1.115")},
                 msg_iov(1)=[{"hello", 5}], msg_controllen=0, msg_flags=0}, 0) = 5
      sendmsg(3, {msg_name(28)={sa_family=AF_INET, sin_port=htons(8888), sin_addr=inet_addr("192.168.1.115")},
                 msg_iov(1)=[{"hello", 5}], msg_controllen=0, msg_flags=0}, 0) = 5
      sendmsg(3, {msg_name(28)={sa_family=AF_INET, sin_port=htons(8888), sin_addr=inet_addr("192.168.1.115")},
                 msg_iov(0)=[], msg_controllen=48, {cmsg_len=48, cmsg_level=0x84 /* SOL_??? */, cmsg_type=, ...},
                 msg_flags=0}, 0) = 0 // graceful shutdown for SOCK_SEQPACKET via SCTP_EOF
      close(3) = 0
      
      tcpdump before patch (fooling the application):
      
      22:33:36.306142 IP 192.168.1.114.41462 > 192.168.1.115.8888: sctp (1) [INIT] [init tag: 3879023686] [rwnd: 106496] [OS: 10] [MIS: 65535] [init TSN: 3139201684]
      22:33:36.316619 IP 192.168.1.115.8888 > 192.168.1.114.41462: sctp (1) [INIT ACK] [init tag: 3345394793] [rwnd: 106496] [OS: 10] [MIS: 10] [init TSN: 3380109591]
      22:33:36.317600 IP 192.168.1.114.41462 > 192.168.1.115.8888: sctp (1) [ABORT]
      
      tcpdump after patch:
      
      14:28:58.884116 IP 192.168.1.114.35846 > 192.168.1.115.8888: sctp (1) [INIT] [init tag: 438593213] [rwnd: 106496] [OS: 10] [MIS: 65535] [init TSN: 3092969729]
      14:28:58.888414 IP 192.168.1.115.8888 > 192.168.1.114.35846: sctp (1) [INIT ACK] [init tag: 381429855] [rwnd: 106496] [OS: 10] [MIS: 10] [init TSN: 2141904492]
      14:28:58.888638 IP 192.168.1.114.35846 > 192.168.1.115.8888: sctp (1) [COOKIE ECHO] , (2) [DATA] (B)(E) [TSN: 3092969729] [...]
      14:28:58.893278 IP 192.168.1.115.8888 > 192.168.1.114.35846: sctp (1) [COOKIE ACK] , (2) [SACK] [cum ack 3092969729] [a_rwnd 106491] [#gap acks 0] [#dup tsns 0]
      14:28:58.893591 IP 192.168.1.114.35846 > 192.168.1.115.8888: sctp (1) [DATA] (B)(E) [TSN: 3092969730] [...]
      14:28:59.096963 IP 192.168.1.115.8888 > 192.168.1.114.35846: sctp (1) [SACK] [cum ack 3092969730] [a_rwnd 106496] [#gap acks 0] [#dup tsns 0]
      14:28:59.097086 IP 192.168.1.114.35846 > 192.168.1.115.8888: sctp (1) [DATA] (B)(E) [TSN: 3092969731] [...] , (2) [DATA] (B)(E) [TSN: 3092969732] [...]
      14:28:59.103218 IP 192.168.1.115.8888 > 192.168.1.114.35846: sctp (1) [SACK] [cum ack 3092969732] [a_rwnd 106486] [#gap acks 0] [#dup tsns 0]
      14:28:59.103330 IP 192.168.1.114.35846 > 192.168.1.115.8888: sctp (1) [SHUTDOWN]
      14:28:59.107793 IP 192.168.1.115.8888 > 192.168.1.114.35846: sctp (1) [SHUTDOWN ACK]
      14:28:59.107890 IP 192.168.1.114.35846 > 192.168.1.115.8888: sctp (1) [SHUTDOWN COMPLETE]
      
      Looks like this bug is from the pre-git history museum. ;)
      
      Fixes: 08707d54 ("lksctp-2_5_31-0_5_1.patch")
      Signed-off-by: default avatarDaniel Borkmann <dborkman@redhat.com>
      Acked-by: default avatarVlad Yasevich <vyasevich@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      11fd056b
    • Alexander Duyck's avatar
      fib_trie: Fix /proc/net/fib_trie when CONFIG_IP_MULTIPLE_TABLES is not defined · 952a63d1
      Alexander Duyck authored
      commit a5a519b2 upstream.
      
      In recent testing I had disabled CONFIG_IP_MULTIPLE_TABLES and as a result
      when I ran "cat /proc/net/fib_trie" the main trie was displayed multiple
      times.  I found that the problem line of code was in the function
      fib_trie_seq_next.  Specifically the line below caused the indexes to go in
      the opposite direction of our traversal:
      
      	h = tb->tb_id & (FIB_TABLE_HASHSZ - 1);
      
      This issue was that the RT tables are defined such that RT_TABLE_LOCAL is ID
      255, while it is located at TABLE_LOCAL_INDEX of 0, and RT_TABLE_MAIN is 254
      with a TABLE_MAIN_INDEX of 1.  This means that the above line will return 1
      for the local table and 0 for main.  The result is that fib_trie_seq_next
      will return NULL at the end of the local table, fib_trie_seq_start will
      return the start of the main table, and then fib_trie_seq_next will loop on
      main forever as h will always return 0.
      
      The fix for this is to reverse the ordering of the two tables.  It has the
      advantage of making it so that the tables now print in the same order
      regardless of if multiple tables are enabled or not.  In order to make the
      definition consistent with the multiple tables case I simply masked the to
      RT_TABLE_XXX values by (FIB_TABLE_HASHSZ - 1).  This way the two table
      layouts should always stay consistent.
      
      Fixes: 93456b6d ("[IPV4]: Unify access to the routing tables")
      Signed-off-by: default avatarAlexander Duyck <alexander.h.duyck@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      952a63d1
    • Seth Forshee's avatar
      HID: i2c-hid: Limit reads to wMaxInputLength bytes for input events · 06edf928
      Seth Forshee authored
      commit 6d00f37e upstream.
      
      d1c7e29e (HID: i2c-hid: prevent buffer overflow in early IRQ)
      changed hid_get_input() to read ihid->bufsize bytes, which can be
      more than wMaxInputLength. This is the case with the Dell XPS 13
      9343, and it is causing events to be missed. In some cases the
      missed events are releases, which can cause the cursor to jump or
      freeze, among other problems. Limit the number of bytes read to
      min(wMaxInputLength, ihid->bufsize) to prevent such problems.
      
      Fixes: d1c7e29e "HID: i2c-hid: prevent buffer overflow in early IRQ"
      Signed-off-by: default avatarSeth Forshee <seth.forshee@canonical.com>
      Reviewed-by: default avatarBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      06edf928
    • Sasha Levin's avatar
      net: rds: use correct size for max unacked packets and bytes · 065f3735
      Sasha Levin authored
      commit db27ebb1 upstream.
      
      Max unacked packets/bytes is an int while sizeof(long) was used in the
      sysctl table.
      
      This means that when they were getting read we'd also leak kernel memory
      to userspace along with the timeout values.
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Cc: Moritz Muehlenhoff <jmm@inutil.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      065f3735
    • Sasha Levin's avatar
      net: llc: use correct size for sysctl timeout entries · 42182789
      Sasha Levin authored
      commit 6b8d9117 upstream.
      
      The timeout entries are sizeof(int) rather than sizeof(long), which
      means that when they were getting read we'd also leak kernel memory
      to userspace along with the timeout values.
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Cc: Moritz Muehlenhoff <jmm@inutil.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      42182789
    • Andrew Elble's avatar
      GFS2: Fix crash during ACL deletion in acl max entry check in gfs2_set_acl() · 9e2feaeb
      Andrew Elble authored
      commit 27870207 upstream.
      
      Fixes: e01580bf ("gfs2: use generic posix ACL infrastructure")
      Reported-by: default avatarEric Meddaugh <etmsys@rit.edu>
      Tested-by: default avatarEric Meddaugh <etmsys@rit.edu>
      Signed-off-by: default avatarAndrew Elble <aweits@rit.edu>
      Signed-off-by: default avatarSteven Whitehouse <swhiteho@redhat.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      9e2feaeb
    • Dan Carpenter's avatar
      ALSA: off by one bug in snd_riptide_joystick_probe() · 3a87ac14
      Dan Carpenter authored
      commit e4940626 upstream.
      
      The problem here is that we check:
      
      	if (dev >= SNDRV_CARDS)
      
      Then we increment "dev".
      
             if (!joystick_port[dev++])
      
      Then we use it as an offset into a array with SNDRV_CARDS elements.
      
      	if (!request_region(joystick_port[dev], 8, "Riptide gameport")) {
      
      This has 3 effects:
      1) If you use the module option to specify the joystick port then it has
         to be shifted one space over.
      2) The wrong error message will be printed on failure if you have over
         32 cards.
      3) Static checkers will correctly complain that are off by one.
      
      Fixes: db1005ec ('ALSA: riptide - Fix joystick resource handling')
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      3a87ac14
    • Uwe Kleine-König's avatar
      pinctrl: pinctrl-imx: don't use invalid value of conf_reg · dd89ea7a
      Uwe Kleine-König authored
      commit 4ff0f034 upstream.
      
      The right check for conf_reg to be invalid it testing against -1 not 0
      as is done in the rest of the driver.
      
      This fixes an oops that can be triggered by:
      
      	cat /sys/kernel/debug/pinctrl/43fac000.iomuxc/*
      
      Fixes: ae75ff81 ("pinctrl: pinctrl-imx: add imx pinctrl core driver")
      Signed-off-by: default avatarUwe Kleine-König <u.kleine-koenig@pengutronix.de>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      [ luis: backported to 3.16:
        - file rename: drivers/pinctrl/freescale/pinctrl-imx.c ->
          drivers/pinctrl/pinctrl-imx.c ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      dd89ea7a
    • Gavin Shan's avatar
      powerpc/kernel: Avoid memory corruption at early stage · 79e43709
      Gavin Shan authored
      commit 6f20e7f2 upstream.
      
      When calling to early_setup(), we pick "boot_paca" up for the master CPU
      and initialize that with initialise_paca(). At that point, the SLB
      shadow buffer isn't populated yet. Updating the SLB shadow buffer should
      corrupt what we had in physical address 0 where the trap instruction is
      usually stored.
      
      This hasn't been observed to cause any trouble in practice, but is
      obviously fishy.
      
      Fixes: 6f4441ef ("powerpc: Dynamically allocate slb_shadow from memblock")
      Signed-off-by: default avatarGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      79e43709
    • Sergei Shtylyov's avatar
      clk-gate: fix bit # check in clk_register_gate() · e99423f7
      Sergei Shtylyov authored
      commit 2e9dcdae upstream.
      
      In case CLK_GATE_HIWORD_MASK flag is passed to clk_register_gate(), the bit #
      should be no higher than 15, however the corresponding check is obviously off-
      by-one.
      
      Fixes: 04577994 ("clk: gate: add CLK_GATE_HIWORD_MASK")
      Signed-off-by: default avatarSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Signed-off-by: default avatarMichael Turquette <mturquette@linaro.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      e99423f7
    • Dan Carpenter's avatar
      efi: Small leak on error in runtime map code · 89639edd
      Dan Carpenter authored
      commit 86d68a58 upstream.
      
      The "> 0" here should ">= 0" so we free map_entries[0].
      
      Fixes: 926172d4 ('efi: Export EFI runtime memory mapping to sysfs')
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Acked-by: default avatarDave Young <dyoung@redhat.com>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      89639edd
    • Geert Uytterhoeven's avatar
      gpio: rcar: Fix error path for devm_kzalloc() failure · 62503026
      Geert Uytterhoeven authored
      commit 7d82bf34 upstream.
      
      If the call to devm_kzalloc() fails, nothing must be cleant up.
      This was missed before because gpio_rcar_probe() had a "return"
      statement after the first "goto err0".
      Signed-off-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Fixes: df0c6c80 ("gpio: rcar: Add minimal runtime PM support")
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      62503026
    • Lars-Peter Clausen's avatar
      ASoC: mioa701_wm9713: Fix speaker event · 50992849
      Lars-Peter Clausen authored
      commit 7331ea47 upstream.
      
      Commit f6b2a045 ("ASoC: pxa: mioa701_wm9713: Convert to table based DAPM
      setup") converted the driver to register the board level DAPM elements with
      the card's DAPM context rather than the CODEC's DAPM context. The change
      overlooked that the speaker widget event callback accesses the widget's
      codec field which is only valid if the widget has been registered in a CODEC
      DAPM context. This patch modifies the callback to take an alternative route
      to get the CODEC.
      
      Fixes: f6b2a045 ("ASoC: pxa: mioa701_wm9713: Convert to table based DAPM
      setup")
      Signed-off-by: default avatarLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      50992849
    • Al Viro's avatar
      autofs4 copy_dev_ioctl(): keep the value of ->size we'd used for allocation · 2321de6e
      Al Viro authored
      commit 0a280962 upstream.
      
      X-Coverup: just ask spender
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      2321de6e
    • Al Viro's avatar
      procfs: fix race between symlink removals and traversals · 48a6aba3
      Al Viro authored
      commit 7e0e953b upstream.
      
      use_pde()/unuse_pde() in ->follow_link()/->put_link() resp.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      48a6aba3
    • Al Viro's avatar
      debugfs: leave freeing a symlink body until inode eviction · 67083b7b
      Al Viro authored
      commit 0db59e59 upstream.
      
      As it is, we have debugfs_remove() racing with symlink traversals.
      Supply ->evict_inode() and do freeing there - inode will remain
      pinned until we are done with the symlink body.
      
      And rip the idiocy with checking if dentry is positive right after
      we'd verified debugfs_positive(), which is a stronger check...
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      67083b7b
    • Thadeu Lima de Souza Cascardo's avatar
      blk-throttle: check stats_cpu before reading it from sysfs · ad9ea48d
      Thadeu Lima de Souza Cascardo authored
      commit 045c47ca upstream.
      
      When reading blkio.throttle.io_serviced in a recently created blkio
      cgroup, it's possible to race against the creation of a throttle policy,
      which delays the allocation of stats_cpu.
      
      Like other functions in the throttle code, just checking for a NULL
      stats_cpu prevents the following oops caused by that race.
      
      [ 1117.285199] Unable to handle kernel paging request for data at address 0x7fb4d0020
      [ 1117.285252] Faulting instruction address: 0xc0000000003efa2c
      [ 1137.733921] Oops: Kernel access of bad area, sig: 11 [#1]
      [ 1137.733945] SMP NR_CPUS=2048 NUMA PowerNV
      [ 1137.734025] Modules linked in: bridge stp llc kvm_hv kvm binfmt_misc autofs4
      [ 1137.734102] CPU: 3 PID: 5302 Comm: blkcgroup Not tainted 3.19.0 #5
      [ 1137.734132] task: c000000f1d188b00 ti: c000000f1d210000 task.ti: c000000f1d210000
      [ 1137.734167] NIP: c0000000003efa2c LR: c0000000003ef9f0 CTR: c0000000003ef980
      [ 1137.734202] REGS: c000000f1d213500 TRAP: 0300   Not tainted  (3.19.0)
      [ 1137.734230] MSR: 9000000000009032 <SF,HV,EE,ME,IR,DR,RI>  CR: 42008884  XER: 20000000
      [ 1137.734325] CFAR: 0000000000008458 DAR: 00000007fb4d0020 DSISR: 40000000 SOFTE: 0
      GPR00: c0000000003ed3a0 c000000f1d213780 c000000000c59538 0000000000000000
      GPR04: 0000000000000800 0000000000000000 0000000000000000 0000000000000000
      GPR08: ffffffffffffffff 00000007fb4d0020 00000007fb4d0000 c000000000780808
      GPR12: 0000000022000888 c00000000fdc0d80 0000000000000000 0000000000000000
      GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
      GPR20: 000001003e120200 c000000f1d5b0cc0 0000000000000200 0000000000000000
      GPR24: 0000000000000001 c000000000c269e0 0000000000000020 c000000f1d5b0c80
      GPR28: c000000000ca3a08 c000000000ca3dec c000000f1c667e00 c000000f1d213850
      [ 1137.734886] NIP [c0000000003efa2c] .tg_prfill_cpu_rwstat+0xac/0x180
      [ 1137.734915] LR [c0000000003ef9f0] .tg_prfill_cpu_rwstat+0x70/0x180
      [ 1137.734943] Call Trace:
      [ 1137.734952] [c000000f1d213780] [d000000005560520] 0xd000000005560520 (unreliable)
      [ 1137.734996] [c000000f1d2138a0] [c0000000003ed3a0] .blkcg_print_blkgs+0xe0/0x1a0
      [ 1137.735039] [c000000f1d213960] [c0000000003efb50] .tg_print_cpu_rwstat+0x50/0x70
      [ 1137.735082] [c000000f1d2139e0] [c000000000104b48] .cgroup_seqfile_show+0x58/0x150
      [ 1137.735125] [c000000f1d213a70] [c0000000002749dc] .kernfs_seq_show+0x3c/0x50
      [ 1137.735161] [c000000f1d213ae0] [c000000000218630] .seq_read+0xe0/0x510
      [ 1137.735197] [c000000f1d213bd0] [c000000000275b04] .kernfs_fop_read+0x164/0x200
      [ 1137.735240] [c000000f1d213c80] [c0000000001eb8e0] .__vfs_read+0x30/0x80
      [ 1137.735276] [c000000f1d213cf0] [c0000000001eb9c4] .vfs_read+0x94/0x1b0
      [ 1137.735312] [c000000f1d213d90] [c0000000001ebb38] .SyS_read+0x58/0x100
      [ 1137.735349] [c000000f1d213e30] [c000000000009218] syscall_exit+0x0/0x98
      [ 1137.735383] Instruction dump:
      [ 1137.735405] 7c6307b4 7f891800 409d00b8 60000000 60420000 3d420004 392a63b0 786a1f24
      [ 1137.735471] 7d49502a e93e01c8 7d495214 7d2ad214 <7cead02a> e9090008 e9490010 e9290018
      
      And here is one code that allows to easily reproduce this, although this
      has first been found by running docker.
      
      void run(pid_t pid)
      {
      	int n;
      	int status;
      	int fd;
      	char *buffer;
      	buffer = memalign(BUFFER_ALIGN, BUFFER_SIZE);
      	n = snprintf(buffer, BUFFER_SIZE, "%d\n", pid);
      	fd = open(CGPATH "/test/tasks", O_WRONLY);
      	write(fd, buffer, n);
      	close(fd);
      	if (fork() > 0) {
      		fd = open("/dev/sda", O_RDONLY | O_DIRECT);
      		read(fd, buffer, 512);
      		close(fd);
      		wait(&status);
      	} else {
      		fd = open(CGPATH "/test/blkio.throttle.io_serviced", O_RDONLY);
      		n = read(fd, buffer, BUFFER_SIZE);
      		close(fd);
      	}
      	free(buffer);
      	exit(0);
      }
      
      void test(void)
      {
      	int status;
      	mkdir(CGPATH "/test", 0666);
      	if (fork() > 0)
      		wait(&status);
      	else
      		run(getpid());
      	rmdir(CGPATH "/test");
      }
      
      int main(int argc, char **argv)
      {
      	int i;
      	for (i = 0; i < NR_TESTS; i++)
      		test();
      	return 0;
      }
      Reported-by: default avatarRicardo Marin Matinata <rmm@br.ibm.com>
      Signed-off-by: default avatarThadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      ad9ea48d
    • Jay Lan's avatar
      kdb: fix incorrect counts in KDB summary command output · 0b50c40c
      Jay Lan authored
      commit 14675592 upstream.
      
      The output of KDB 'summary' command should report MemTotal, MemFree
      and Buffers output in kB. Current codes report in unit of pages.
      
      A define of K(x) as
      is defined in the code, but not used.
      
      This patch would apply the define to convert the values to kB.
      Please include me on Cc on replies. I do not subscribe to linux-kernel.
      Signed-off-by: default avatarJay Lan <jlan@sgi.com>
      Signed-off-by: default avatarJason Wessel <jason.wessel@windriver.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      0b50c40c
    • James Hogan's avatar
      MIPS: Export MSA functions used by lose_fpu(1) for KVM · db99df36
      James Hogan authored
      commit ca5d2564 upstream.
      
      Export the _save_msa asm function used by the lose_fpu(1) macro to GPL
      modules so that KVM can make use of it when it is built as a module.
      
      This fixes the following build error when CONFIG_KVM=m and
      CONFIG_CPU_HAS_MSA=y due to commit f798217d ("KVM: MIPS: Don't leak
      FPU/DSP to guest"):
      
      ERROR: "_save_msa" [arch/mips/kvm/kvm.ko] undefined!
      
      Fixes: f798217d (KVM: MIPS: Don't leak FPU/DSP to guest)
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: Gleb Natapov <gleb@kernel.org>
      Cc: kvm@vger.kernel.org
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/9261/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      db99df36
    • James Hogan's avatar
      MIPS: Export FP functions used by lose_fpu(1) for KVM · 56fcf534
      James Hogan authored
      commit 3ce465e0 upstream.
      
      Export the _save_fp asm function used by the lose_fpu(1) macro to GPL
      modules so that KVM can make use of it when it is built as a module.
      
      This fixes the following build error when CONFIG_KVM=m due to commit
      f798217d ("KVM: MIPS: Don't leak FPU/DSP to guest"):
      
      ERROR: "_save_fp" [arch/mips/kvm/kvm.ko] undefined!
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Fixes: f798217d (KVM: MIPS: Don't leak FPU/DSP to guest)
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: Gleb Natapov <gleb@kernel.org>
      Cc: kvm@vger.kernel.org
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/9260/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      56fcf534
    • Ilya Dryomov's avatar
      libceph: fix double __remove_osd() problem · d27ae2c2
      Ilya Dryomov authored
      commit 7eb71e03 upstream.
      
      It turns out it's possible to get __remove_osd() called twice on the
      same OSD.  That doesn't sit well with rb_erase() - depending on the
      shape of the tree we can get a NULL dereference, a soft lockup or
      a random crash at some point in the future as we end up touching freed
      memory.  One scenario that I was able to reproduce is as follows:
      
                  <osd3 is idle, on the osd lru list>
      <con reset - osd3>
      con_fault_finish()
        osd_reset()
                                    <osdmap - osd3 down>
                                    ceph_osdc_handle_map()
                                      <takes map_sem>
                                      kick_requests()
                                        <takes request_mutex>
                                        reset_changed_osds()
                                          __reset_osd()
                                            __remove_osd()
                                        <releases request_mutex>
                                      <releases map_sem>
          <takes map_sem>
          <takes request_mutex>
          __kick_osd_requests()
            __reset_osd()
              __remove_osd() <-- !!!
      
      A case can be made that osd refcounting is imperfect and reworking it
      would be a proper resolution, but for now Sage and I decided to fix
      this by adding a safe guard around __remove_osd().
      
      Fixes: http://tracker.ceph.com/issues/8087
      
      Cc: Sage Weil <sage@redhat.com>
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      Reviewed-by: default avatarSage Weil <sage@redhat.com>
      Reviewed-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      d27ae2c2
    • Ilya Dryomov's avatar
      libceph: change from BUG to WARN for __remove_osd() asserts · fe654f5e
      Ilya Dryomov authored
      commit cc9f1f51 upstream.
      
      No reason to use BUG_ON for osd request list assertions.
      Signed-off-by: default avatarIlya Dryomov <idryomov@redhat.com>
      Reviewed-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      fe654f5e
    • Ilya Dryomov's avatar
      libceph: assert both regular and lingering lists in __remove_osd() · 1505d944
      Ilya Dryomov authored
      commit 7c6e6fc5 upstream.
      
      It is important that both regular and lingering requests lists are
      empty when the OSD is removed.
      Signed-off-by: default avatarIlya Dryomov <ilya.dryomov@inktank.com>
      Reviewed-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      1505d944
    • Hector Marco-Gisbert's avatar
      x86, mm/ASLR: Fix stack randomization on 64-bit systems · b515b1b0
      Hector Marco-Gisbert authored
      commit 4e7c22d4 upstream.
      
      The issue is that the stack for processes is not properly randomized on
      64 bit architectures due to an integer overflow.
      
      The affected function is randomize_stack_top() in file
      "fs/binfmt_elf.c":
      
        static unsigned long randomize_stack_top(unsigned long stack_top)
        {
                 unsigned int random_variable = 0;
      
                 if ((current->flags & PF_RANDOMIZE) &&
                         !(current->personality & ADDR_NO_RANDOMIZE)) {
                         random_variable = get_random_int() & STACK_RND_MASK;
                         random_variable <<= PAGE_SHIFT;
                 }
                 return PAGE_ALIGN(stack_top) + random_variable;
                 return PAGE_ALIGN(stack_top) - random_variable;
        }
      
      Note that, it declares the "random_variable" variable as "unsigned int".
      Since the result of the shifting operation between STACK_RND_MASK (which
      is 0x3fffff on x86_64, 22 bits) and PAGE_SHIFT (which is 12 on x86_64):
      
      	  random_variable <<= PAGE_SHIFT;
      
      then the two leftmost bits are dropped when storing the result in the
      "random_variable". This variable shall be at least 34 bits long to hold
      the (22+12) result.
      
      These two dropped bits have an impact on the entropy of process stack.
      Concretely, the total stack entropy is reduced by four: from 2^28 to
      2^30 (One fourth of expected entropy).
      
      This patch restores back the entropy by correcting the types involved
      in the operations in the functions randomize_stack_top() and
      stack_maxrandom_size().
      
      The successful fix can be tested with:
      
        $ for i in `seq 1 10`; do cat /proc/self/maps | grep stack; done
        7ffeda566000-7ffeda587000 rw-p 00000000 00:00 0                          [stack]
        7fff5a332000-7fff5a353000 rw-p 00000000 00:00 0                          [stack]
        7ffcdb7a1000-7ffcdb7c2000 rw-p 00000000 00:00 0                          [stack]
        7ffd5e2c4000-7ffd5e2e5000 rw-p 00000000 00:00 0                          [stack]
        ...
      
      Once corrected, the leading bytes should be between 7ffc and 7fff,
      rather than always being 7fff.
      Signed-off-by: default avatarHector Marco-Gisbert <hecmargi@upv.es>
      Signed-off-by: default avatarIsmael Ripoll <iripoll@upv.es>
      [ Rebased, fixed 80 char bugs, cleaned up commit message, added test example and CVE ]
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Fixes: CVE-2015-1593
      Link: http://lkml.kernel.org/r/20150214173350.GA18393@www.outflux.netSigned-off-by: default avatarBorislav Petkov <bp@suse.de>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      b515b1b0
    • Arnd Bergmann's avatar
      cpufreq: s3c: remove incorrect __init annotations · 22d44228
      Arnd Bergmann authored
      commit 61882b63 upstream.
      
      The two functions s3c2416_cpufreq_driver_init and s3c_cpufreq_register
      are marked init but are called from a context that might be run after
      the __init sections are discarded, as the compiler points out:
      
      WARNING: vmlinux.o(.data+0x1ad9dc): Section mismatch in reference from the variable s3c2416_cpufreq_driver to the function .init.text:s3c2416_cpufreq_driver_init()
      WARNING: drivers/built-in.o(.text+0x35b5dc): Section mismatch in reference from the function s3c2410a_cpufreq_add() to the function .init.text:s3c_cpufreq_register()
      
      This removes the __init markings.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      22d44228
    • Mikulas Patocka's avatar
      dm snapshot: fix a possible invalid memory access on unload · a0b50c39
      Mikulas Patocka authored
      commit 22aa66a3 upstream.
      
      When the snapshot target is unloaded, snapshot_dtr() waits until
      pending_exceptions_count drops to zero.  Then, it destroys the snapshot.
      Therefore, the function that decrements pending_exceptions_count
      should not touch the snapshot structure after the decrement.
      
      pending_complete() calls free_pending_exception(), which decrements
      pending_exceptions_count, and then it performs up_write(&s->lock) and it
      calls retry_origin_bios() which dereferences  s->origin.  These two
      memory accesses to the fields of the snapshot may touch the dm_snapshot
      struture after it is freed.
      
      This patch moves the call to free_pending_exception() to the end of
      pending_complete(), so that the snapshot will not be destroyed while
      pending_complete() is in progress.
      Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      a0b50c39
    • Mikulas Patocka's avatar
      dm: fix a race condition in dm_get_md · f51576b6
      Mikulas Patocka authored
      commit 2bec1f4a upstream.
      
      The function dm_get_md finds a device mapper device with a given dev_t,
      increases the reference count and returns the pointer.
      
      dm_get_md calls dm_find_md, dm_find_md takes _minor_lock, finds the
      device, tests that the device doesn't have DMF_DELETING or DMF_FREEING
      flag, drops _minor_lock and returns pointer to the device. dm_get_md then
      calls dm_get. dm_get calls BUG if the device has the DMF_FREEING flag,
      otherwise it increments the reference count.
      
      There is a possible race condition - after dm_find_md exits and before
      dm_get is called, there are no locks held, so the device may disappear or
      DMF_FREEING flag may be set, which results in BUG.
      
      To fix this bug, we need to call dm_get while we hold _minor_lock. This
      patch renames dm_find_md to dm_get_md and changes it so that it calls
      dm_get while holding the lock.
      Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      f51576b6
    • John Stultz's avatar
      ntp: Fixup adjtimex freq validation on 32-bit systems · 06246b44
      John Stultz authored
      commit 29183a70 upstream.
      
      Additional validation of adjtimex freq values to avoid
      potential multiplication overflows were added in commit
      5e5aeb43 (time: adjtimex: Validate the ADJ_FREQUENCY values)
      
      Unfortunately the patch used LONG_MAX/MIN instead of
      LLONG_MAX/MIN, which was fine on 64-bit systems, but being
      much smaller on 32-bit systems caused false positives
      resulting in most direct frequency adjustments to fail w/
      EINVAL.
      
      ntpd only does direct frequency adjustments at startup, so
      the issue was not as easily observed there, but other time
      sync applications like ptpd and chrony were more effected by
      the bug.
      
      See bugs:
      
        https://bugzilla.kernel.org/show_bug.cgi?id=92481
        https://bugzilla.redhat.com/show_bug.cgi?id=1188074
      
      This patch changes the checks to use LLONG_MAX for
      clarity, and additionally the checks are disabled
      on 32-bit systems since LLONG_MAX/PPM_SCALE is always
      larger then the 32-bit long freq value, so multiplication
      overflows aren't possible there.
      Reported-by: default avatarJosh Boyer <jwboyer@fedoraproject.org>
      Reported-by: default avatarGeorge Joseph <george.joseph@fairview5.com>
      Tested-by: default avatarGeorge Joseph <george.joseph@fairview5.com>
      Signed-off-by: default avatarJohn Stultz <john.stultz@linaro.org>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Sasha Levin <sasha.levin@oracle.com>
      Link: http://lkml.kernel.org/r/1423553436-29747-1-git-send-email-john.stultz@linaro.org
      [ Prettified the changelog and the comments a bit. ]
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      06246b44
    • Sasha Levin's avatar
      time: adjtimex: Validate the ADJ_FREQUENCY values · e74cd063
      Sasha Levin authored
      commit 5e5aeb43 upstream.
      
      Verify that the frequency value from userspace is valid and makes sense.
      
      Unverified values can cause overflows later on.
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      [jstultz: Fix up bug for negative values and drop redunent cap check]
      Signed-off-by: default avatarJohn Stultz <john.stultz@linaro.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      e74cd063