1. 14 Dec, 2015 21 commits
  2. 13 Dec, 2015 19 commits
    • David Howells's avatar
      FS-Cache: Handle a write to the page immediately beyond the EOF marker · c8aedb3b
      David Howells authored
      commit 102f4d90 upstream.
      
      Handle a write being requested to the page immediately beyond the EOF
      marker on a cache object.  Currently this gets an assertion failure in
      CacheFiles because the EOF marker is used there to encode information about
      a partial page at the EOF - which could lead to an unknown blank spot in
      the file if we extend the file over it.
      
      The problem is actually in fscache where we check the index of the page
      being written against store_limit.  store_limit is set to the number of
      pages that we're allowed to store by fscache_set_store_limit() - which
      means it's one more than the index of the last page we're allowed to store.
      The problem is that we permit writing to a page with an index _equal_ to
      the store limit - when we should reject that case.
      
      Whilst we're at it, change the triggered assertion in CacheFiles to just
      return -ENOBUFS instead.
      
      The assertion failure looks something like this:
      
      CacheFiles: Assertion failed
      1000 < 7b1 is false
      ------------[ cut here ]------------
      kernel BUG at fs/cachefiles/rdwr.c:962!
      ...
      RIP: 0010:[<ffffffffa02c9e83>]  [<ffffffffa02c9e83>] cachefiles_write_page+0x273/0x2d0 [cachefiles]
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      [ kamal: backport to 3.13-stable: no __kernel_write(); thanks Ben H. ]
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      c8aedb3b
    • Mathias Krause's avatar
      printk: prevent userland from spoofing kernel messages · fd7060f6
      Mathias Krause authored
      commit 3824657c upstream.
      
      The following statement of ABI/testing/dev-kmsg is not quite right:
      
         It is not possible to inject messages from userspace with the
         facility number LOG_KERN (0), to make sure that the origin of the
         messages can always be reliably determined.
      
      Userland actually can inject messages with a facility of 0 by abusing the
      fact that the facility is stored in a u8 data type.  By using a facility
      which is a multiple of 256 the assignment of msg->facility in log_store()
      implicitly truncates it to 0, i.e.  LOG_KERN, allowing users of /dev/kmsg
      to spoof kernel messages as shown below:
      
      The following call...
         # printf '<%d>Kernel panic - not syncing: beer empty\n' 0 >/dev/kmsg
      ...leads to the following log entry (dmesg -x | tail -n 1):
         user  :emerg : [   66.137758] Kernel panic - not syncing: beer empty
      
      However, this call...
         # printf '<%d>Kernel panic - not syncing: beer empty\n' 0x800 >/dev/kmsg
      ...leads to the slightly different log entry (note the kernel facility):
         kern  :emerg : [   74.177343] Kernel panic - not syncing: beer empty
      
      Fix that by limiting the user provided facility to 8 bit right from the
      beginning and catch the truncation early.
      
      Fixes: 7ff9554b ("printk: convert byte-buffer to variable-length...")
      Signed-off-by: default avatarMathias Krause <minipli@googlemail.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Petr Mladek <pmladek@suse.cz>
      Cc: Alex Elder <elder@linaro.org>
      Cc: Joe Perches <joe@perches.com>
      Cc: Kay Sievers <kay@vrfy.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      [ kamal: backport to 3.13-stable: retain local 'int i' ]
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      fd7060f6
    • Takashi Iwai's avatar
      ALSA: hda - Disable 64bit address for Creative HDA controllers · cd21931f
      Takashi Iwai authored
      commit cadd16ea upstream.
      
      We've had many reports that some Creative sound cards with CA0132
      don't work well.  Some reported that it starts working after reloading
      the module, while some reported it starts working when a 32bit kernel
      is used.  All these facts seem implying that the chip fails to
      communicate when the buffer is located in 64bit address.
      
      This patch addresses these issues by just adding AZX_DCAPS_NO_64BIT
      flag to the corresponding PCI entries.  I casually had a chance to
      test an SB Recon3D board, and indeed this seems helping.
      
      Although this hasn't been tested on all Creative devices, it's safer
      to assume that this restriction applies to the rest of them, too.  So
      the flag is applied to all Creative entries.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      [ kamal: backport to 3.13-stable: context ]
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      cd21931f
    • Ingo Molnar's avatar
      fs/proc, core/debug: Don't expose absolute kernel addresses via wchan · a9ba345c
      Ingo Molnar authored
      commit b2f73922 upstream.
      
      So the /proc/PID/stat 'wchan' field (the 30th field, which contains
      the absolute kernel address of the kernel function a task is blocked in)
      leaks absolute kernel addresses to unprivileged user-space:
      
              seq_put_decimal_ull(m, ' ', wchan);
      
      The absolute address might also leak via /proc/PID/wchan as well, if
      KALLSYMS is turned off or if the symbol lookup fails for some reason:
      
      static int proc_pid_wchan(struct seq_file *m, struct pid_namespace *ns,
                                struct pid *pid, struct task_struct *task)
      {
              unsigned long wchan;
              char symname[KSYM_NAME_LEN];
      
              wchan = get_wchan(task);
      
              if (lookup_symbol_name(wchan, symname) < 0) {
                      if (!ptrace_may_access(task, PTRACE_MODE_READ))
                              return 0;
                      seq_printf(m, "%lu", wchan);
              } else {
                      seq_printf(m, "%s", symname);
              }
      
              return 0;
      }
      
      This isn't ideal, because for example it trivially leaks the KASLR offset
      to any local attacker:
      
        fomalhaut:~> printf "%016lx\n" $(cat /proc/$$/stat | cut -d' ' -f35)
        ffffffff8123b380
      
      Most real-life uses of wchan are symbolic:
      
        ps -eo pid:10,tid:10,wchan:30,comm
      
      and procps uses /proc/PID/wchan, not the absolute address in /proc/PID/stat:
      
        triton:~/tip> strace -f ps -eo pid:10,tid:10,wchan:30,comm 2>&1 | grep wchan | tail -1
        open("/proc/30833/wchan", O_RDONLY)     = 6
      
      There's one compatibility quirk here: procps relies on whether the
      absolute value is non-zero - and we can provide that functionality
      by outputing "0" or "1" depending on whether the task is blocked
      (whether there's a wchan address).
      
      These days there appears to be very little legitimate reason
      user-space would be interested in  the absolute address. The
      absolute address is mostly historic: from the days when we
      didn't have kallsyms and user-space procps had to do the
      decoding itself via the System.map.
      
      So this patch sets all numeric output to "0" or "1" and keeps only
      symbolic output, in /proc/PID/wchan.
      
      ( The absolute sleep address can generally still be profiled via
        perf, by tasks with sufficient privileges. )
      Reviewed-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Acked-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Alexander Potapenko <glider@google.com>
      Cc: Andrey Konovalov <andreyknvl@google.com>
      Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: Kostya Serebryany <kcc@google.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Sasha Levin <sasha.levin@oracle.com>
      Cc: kasan-dev <kasan-dev@googlegroups.com>
      Cc: linux-kernel@vger.kernel.org
      Link: http://lkml.kernel.org/r/20150930135917.GA3285@gmail.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      [ kamal: backport to 3.16-stable: proc_pid_wchan context ]
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      a9ba345c
    • Kosuke Tatsukawa's avatar
      tty: fix stall caused by missing memory barrier in drivers/tty/n_tty.c · b83c9091
      Kosuke Tatsukawa authored
      commit e81107d4 upstream.
      
      My colleague ran into a program stall on a x86_64 server, where
      n_tty_read() was waiting for data even if there was data in the buffer
      in the pty.  kernel stack for the stuck process looks like below.
       #0 [ffff88303d107b58] __schedule at ffffffff815c4b20
       #1 [ffff88303d107bd0] schedule at ffffffff815c513e
       #2 [ffff88303d107bf0] schedule_timeout at ffffffff815c7818
       #3 [ffff88303d107ca0] wait_woken at ffffffff81096bd2
       #4 [ffff88303d107ce0] n_tty_read at ffffffff8136fa23
       #5 [ffff88303d107dd0] tty_read at ffffffff81368013
       #6 [ffff88303d107e20] __vfs_read at ffffffff811a3704
       #7 [ffff88303d107ec0] vfs_read at ffffffff811a3a57
       #8 [ffff88303d107f00] sys_read at ffffffff811a4306
       #9 [ffff88303d107f50] entry_SYSCALL_64_fastpath at ffffffff815c86d7
      
      There seems to be two problems causing this issue.
      
      First, in drivers/tty/n_tty.c, __receive_buf() stores the data and
      updates ldata->commit_head using smp_store_release() and then checks
      the wait queue using waitqueue_active().  However, since there is no
      memory barrier, __receive_buf() could return without calling
      wake_up_interactive_poll(), and at the same time, n_tty_read() could
      start to wait in wait_woken() as in the following chart.
      
              __receive_buf()                         n_tty_read()
      ------------------------------------------------------------------------
      if (waitqueue_active(&tty->read_wait))
      /* Memory operations issued after the
         RELEASE may be completed before the
         RELEASE operation has completed */
                                              add_wait_queue(&tty->read_wait, &wait);
                                              ...
                                              if (!input_available_p(tty, 0)) {
      smp_store_release(&ldata->commit_head,
                        ldata->read_head);
                                              ...
                                              timeout = wait_woken(&wait,
                                                TASK_INTERRUPTIBLE, timeout);
      ------------------------------------------------------------------------
      
      The second problem is that n_tty_read() also lacks a memory barrier
      call and could also cause __receive_buf() to return without calling
      wake_up_interactive_poll(), and n_tty_read() to wait in wait_woken()
      as in the chart below.
      
              __receive_buf()                         n_tty_read()
      ------------------------------------------------------------------------
                                              spin_lock_irqsave(&q->lock, flags);
                                              /* from add_wait_queue() */
                                              ...
                                              if (!input_available_p(tty, 0)) {
                                              /* Memory operations issued after the
                                                 RELEASE may be completed before the
                                                 RELEASE operation has completed */
      smp_store_release(&ldata->commit_head,
                        ldata->read_head);
      if (waitqueue_active(&tty->read_wait))
                                              __add_wait_queue(q, wait);
                                              spin_unlock_irqrestore(&q->lock,flags);
                                              /* from add_wait_queue() */
                                              ...
                                              timeout = wait_woken(&wait,
                                                TASK_INTERRUPTIBLE, timeout);
      ------------------------------------------------------------------------
      
      There are also other places in drivers/tty/n_tty.c which have similar
      calls to waitqueue_active(), so instead of adding many memory barrier
      calls, this patch simply removes the call to waitqueue_active(),
      leaving just wake_up*() behind.
      
      This fixes both problems because, even though the memory access before
      or after the spinlocks in both wake_up*() and add_wait_queue() can
      sneak into the critical section, it cannot go past it and the critical
      section assures that they will be serialized (please see "INTER-CPU
      ACQUIRING BARRIER EFFECTS" in Documentation/memory-barriers.txt for a
      better explanation).  Moreover, the resulting code is much simpler.
      
      Latency measurement using a ping-pong test over a pty doesn't show any
      visible performance drop.
      Signed-off-by: default avatarKosuke Tatsukawa <tatsu@ab.jp.nec.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      [ luis: backported to 3.16:
        - always use wake_up_interruptible() instead of wake_up_interruptible_poll()
        - adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      b83c9091
    • Maxim Sheviakov's avatar
      775ea2c0
    • Alex Deucher's avatar
    • Maxim Sheviakov's avatar
      drm/radeon: add quirk for MSI R7 370 · b68505ea
      Maxim Sheviakov authored
      commit e7865479 upstream.
      
      Just adds the quirk for MSI R7 370 Armor 2X
      Bug:
      https://bugs.freedesktop.org/show_bug.cgi?id=91294Signed-off-by: default avatarMaxim Sheviakov <mrader3940@yandex.ru>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      b68505ea
    • NeilBrown's avatar
      md/raid0: apply base queue limits *before* disk_stack_limits · f4c9d9e8
      NeilBrown authored
      commit 66eefe5d upstream.
      
      Calling e.g. blk_queue_max_hw_sectors() after calls to
      disk_stack_limits() discards the settings determined by
      disk_stack_limits().
      So we need to make those calls first.
      
      Fixes: 199dc6ed ("md/raid0: update queue parameter in a safer location.")
      Reported-by: default avatarJes Sorensen <Jes.Sorensen@redhat.com>
      Signed-off-by: default avatarNeilBrown <neilb@suse.com>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      f4c9d9e8
    • NeilBrown's avatar
      md/raid0: update queue parameter in a safer location. · f2cbb1bf
      NeilBrown authored
      commit 199dc6ed upstream.
      
      When a (e.g.) RAID5 array is reshaped to RAID0, the updating
      of queue parameters (e.g. max number of sectors per bio) is
      done in the wrong place.
      It should be part of ->run, but it is actually part of ->takeover.
      This means it happens before level_store() calls:
      
      	blk_set_stacking_limits(&mddev->queue->limits);
      
      and so it ineffective.  This can lead to errors from underlying
      devices.
      
      So move all the relevant settings out of create_stripe_zones()
      and into raid0_run().
      
      As this can lead to a bug-on it is suitable for any -stable
      kernel which supports reshape to RAID0.  So 2.6.35 or later.
      As the bug has been present for five years there is no urgency,
      so no need to rush into -stable.
      
      Fixes: 9af204cf ("md: Add support for Raid5->Raid0 and Raid10->Raid0 takeover")
      Reported-by: default avatarYi Zhang <yizhan@redhat.com>
      Signed-off-by: default avatarNeilBrown <neilb@suse.com>
      [ luis: backported to 3.16:
        - raid0 isn't accessed from dm-raid so no conditional mddev->queue accesses
          (done with commit 753f2856 "md raid0: access mddev->queue (request
          queue member) conditionally because it is not set when accessed from
          dm-raid")
        - adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      f2cbb1bf
    • Max Filippov's avatar
      753cf4f4
    • Christophe JAILLET's avatar
      TPM: Avoid reference to potentially freed memory · 5ffa772f
      Christophe JAILLET authored
      commit eb8ed1eb upstream.
      
      Reference to the 'np' node is dropped before dereferencing the 'sizep' and
      'basep' pointers, which could by then point to junk if the node has been
      freed.
      
      Refactor code to call 'of_node_put' later.
      
      Fixes: c5df3926 ("drivers/char/tpm: Add securityfs support for event log")
      Signed-off-by: default avatarChristophe JAILLET <christophe.jaillet@wanadoo.fr>
      Reviewed-by: default avatarJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
      Signed-off-by: default avatarJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
      Acked-by: default avatarPeter Huewe <PeterHuewe@gmx.de>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      5ffa772f
    • Tero Kristo's avatar
      rtc: ds1307: Fix alarm programming for mcp794xx · 23d8e4e8
      Tero Kristo authored
      commit 62c8c20a upstream.
      
      mcp794xx alarm registers must be written in BCD format. However, the
      alarm programming logic neglected this by adding one to the value
      after bin2bcd conversion has been already done, writing bad values
      to month register in case the alarm being set is in October. In this
      case, the alarm month value becomes 0x0a instead of the expected 0x10.
      
      Fix by moving the +1 addition within the bin2bcd call also.
      
      Fixes: 1d1945d2 ("drivers/rtc/rtc-ds1307.c: add alarm support for mcp7941x chips")
      Signed-off-by: default avatarTero Kristo <t-kristo@ti.com>
      Acked-by: default avatarNishanth Menon <nm@ti.com>
      Signed-off-by: default avatarAlexandre Belloni <alexandre.belloni@free-electrons.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      23d8e4e8
    • Jay Vosburgh's avatar
      bonding: fix panic on non-ARPHRD_ETHER enslave failure · c444763e
      Jay Vosburgh authored
      commit 40baec22 upstream.
      
      Since commit 7d5cd2ce529b, when bond_enslave fails on devices that
      are not ARPHRD_ETHER, if needed, it resets the bonding device back to
      ARPHRD_ETHER by calling ether_setup.
      
      	Unfortunately, ether_setup clobbers dev->flags, clearing IFF_UP
      if the bond device is up, leaving it in a quasi-down state without
      having actually gone through dev_close.  For bonding, if any periodic
      work queue items are active (miimon, arp_interval, etc), those will
      remain running, as they are stopped by bond_close.  At this point, if
      the bonding module is unloaded or the bond is deleted, the system will
      panic when the work function is called.
      
      	This panic is resolved by calling dev_close on the bond itself
      prior to calling ether_setup.
      
      Cc: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: default avatarJay Vosburgh <jay.vosburgh@canonical.com>
      Fixes: 7d5cd2ce ("bonding: correctly handle bonding type change on enslave failure")
      Acked-by: default avatarNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      c444763e
    • Peter Feiner's avatar
      perf trace: Fix documentation for -i · c3c936da
      Peter Feiner authored
      commit 956959f6 upstream.
      
      The -i flag was incorrectly listed as a short flag for --no-inherit.  It
      should have only been listed as a short flag for --input.
      
      This documentation error has existed since the --input flag was
      introduced in 6810fc91 (perf trace: Add
      option to analyze events in a file versus live).
      Signed-off-by: default avatarPeter Feiner <pfeiner@google.com>
      Cc: David Ahern <dsahern@gmail.com>
      Link: http://lkml.kernel.org/r/1446657706-14518-1-git-send-email-pfeiner@google.com
      Fixes: 6810fc91 ("perf trace: Add option to analyze events in a file versus live")
      Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      c3c936da
    • Michal Kubeček's avatar
      ipv6: fix tunnel error handling · 9adf5827
      Michal Kubeček authored
      commit ebac62fe upstream.
      
      Both tunnel6_protocol and tunnel46_protocol share the same error
      handler, tunnel6_err(), which traverses through tunnel6_handlers list.
      For ipip6 tunnels, we need to traverse tunnel46_handlers as we do e.g.
      in tunnel46_rcv(). Current code can generate an ICMPv6 error message
      with an IPv4 packet embedded in it.
      
      Fixes: 73d605d1 ("[IPSEC]: changing API of xfrm6_tunnel_register")
      Signed-off-by: default avatarMichal Kubecek <mkubecek@suse.cz>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      9adf5827
    • Arnd Bergmann's avatar
      ceph: fix message length computation · b4c73482
      Arnd Bergmann authored
      commit 777d738a upstream.
      
      create_request_message() computes the maximum length of a message,
      but uses the wrong type for the time stamp: sizeof(struct timespec)
      may be 8 or 16 depending on the architecture, while sizeof(struct
      ceph_timespec) is always 8, and that is what gets put into the
      message.
      
      Found while auditing the uses of timespec for y2038 problems.
      
      Fixes: b8e69066 ("ceph: include time stamp in every MDS request")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarYan, Zheng <zyan@redhat.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      b4c73482
    • Chuck Lever's avatar
      xprtrdma: Re-arm after missed events · 09a61da1
      Chuck Lever authored
      commit 7b3d770c upstream.
      
      ib_req_notify_cq(IB_CQ_REPORT_MISSED_EVENTS) returns a positive
      value if WCs were added to a CQ after the last completion upcall
      but before the CQ has been re-armed.
      
      Commit 7f23f6f6 ("xprtrmda: Reduce lock contention in
      completion handlers") assumed that when ib_req_notify_cq() returned
      a positive RC, the CQ had also been successfully re-armed, making
      it safe to return control to the provider without losing any
      completion signals. That is an invalid assumption.
      
      Change both completion handlers to continue polling while
      ib_req_notify_cq() returns a positive value.
      
      Fixes: 7f23f6f6 ("xprtrmda: Reduce lock contention in ...")
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Reviewed-by: default avatarSagi Grimberg <sagig@mellanox.com>
      Reviewed-by: default avatarDevesh Sharma <devesh.sharma@avagotech.com>
      Tested-By: default avatarDevesh Sharma <devesh.sharma@avagotech.com>
      Signed-off-by: default avatarAnna Schumaker <Anna.Schumaker@Netapp.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      09a61da1
    • Florian Westphal's avatar
      netfilter: nfnetlink: don't probe module if it exists · c01bb4f0
      Florian Westphal authored
      commit dbc3617f upstream.
      
      nfnetlink_bind request_module()s all the time as nfnetlink_get_subsys()
      shifts the argument by 8 to obtain the subsys id.
      
      So using type instead of type << 8 always returns NULL.
      
      Fixes: 03292745 ("netlink: add nlk->netlink_bind hook for module auto-loading")
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      c01bb4f0