1. 16 Feb, 2017 11 commits
    • Lukáš Lalinský's avatar
      USB: Add quirk for WORLDE easykey.25 MIDI keyboard · 08226322
      Lukáš Lalinský authored
      commit d9b2997e upstream.
      
      Add a quirk for WORLDE easykey.25 MIDI keyboard (idVendor=0218,
      idProduct=0401). The device reports that it has config string
      descriptor at index 3, but when the system selects the configuration
      and tries to get the description, it returns a -EPROTO error,
      the communication restarts and this keeps repeating over and over again.
      Not requesting the string descriptor makes the device work correctly.
      
      Relevant info from Wireshark:
      
      [...]
      
      CONFIGURATION DESCRIPTOR
          bLength: 9
          bDescriptorType: 0x02 (CONFIGURATION)
          wTotalLength: 101
          bNumInterfaces: 2
          bConfigurationValue: 1
          iConfiguration: 3
          Configuration bmAttributes: 0xc0  SELF-POWERED  NO REMOTE-WAKEUP
              1... .... = Must be 1: Must be 1 for USB 1.1 and higher
              .1.. .... = Self-Powered: This device is SELF-POWERED
              ..0. .... = Remote Wakeup: This device does NOT support remote wakeup
          bMaxPower: 50  (100mA)
      
      [...]
      
           45 0.369104       host                  2.38.0                USB      64     GET DESCRIPTOR Request STRING
      
      [...]
      
      URB setup
          bmRequestType: 0x80
              1... .... = Direction: Device-to-host
              .00. .... = Type: Standard (0x00)
              ...0 0000 = Recipient: Device (0x00)
          bRequest: GET DESCRIPTOR (6)
          Descriptor Index: 0x03
          bDescriptorType: 0x03
          Language Id: English (United States) (0x0409)
          wLength: 255
      
           46 0.369255       2.38.0                host                  USB      64     GET DESCRIPTOR Response STRING[Malformed Packet]
      
      [...]
      
      Frame 46: 64 bytes on wire (512 bits), 64 bytes captured (512 bits) on interface 0
      USB URB
          [Source: 2.38.0]
          [Destination: host]
          URB id: 0xffff88021f62d480
          URB type: URB_COMPLETE ('C')
          URB transfer type: URB_CONTROL (0x02)
          Endpoint: 0x80, Direction: IN
          Device: 38
          URB bus id: 2
          Device setup request: not relevant ('-')
          Data: present (0)
          URB sec: 1484896277
          URB usec: 455031
          URB status: Protocol error (-EPROTO) (-71)
          URB length [bytes]: 0
          Data length [bytes]: 0
          [Request in: 45]
          [Time from request: 0.000151000 seconds]
          Unused Setup Header
          Interval: 0
          Start frame: 0
          Copy of Transfer Flags: 0x00000200
          Number of ISO descriptors: 0
      [Malformed Packet: USB]
          [Expert Info (Error/Malformed): Malformed Packet (Exception occurred)]
              [Malformed Packet (Exception occurred)]
              [Severity level: Error]
              [Group: Malformed]
      Signed-off-by: default avatarLukáš Lalinský <lukas@oxygene.sk>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      08226322
    • Marcel J.E. Mol's avatar
      USB: serial: pl2303: add ATEN device ID · 1da629f2
      Marcel J.E. Mol authored
      commit d07830db upstream.
      
      Seems that ATEN serial-to-usb devices using pl2303 exist with
      different device ids. This patch adds a missing device ID so it
      is recognised by the driver.
      Signed-off-by: default avatarMarcel J.E. Mol <marcel@mesa.nl>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      1da629f2
    • Aleksander Morgado's avatar
      USB: serial: qcserial: add Dell DW5570 QDL · 8a0cf3d9
      Aleksander Morgado authored
      commit 24d615a6 upstream.
      
      The Dell DW5570 is a re-branded Sierra Wireless MC8805 which will by
      default boot with vid 0x413c and pid 0x81a3. When triggered QDL download
      mode, the device switches to pid 0x81a6 and provides the standard TTY
      used for firmware upgrade.
      Signed-off-by: default avatarAleksander Morgado <aleksander@aleksander.es>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      8a0cf3d9
    • Oliver Hartkopp's avatar
      can: bcm: fix hrtimer/tasklet termination in bcm op removal · 192c10ab
      Oliver Hartkopp authored
      commit a06393ed upstream.
      
      When removing a bcm tx operation either a hrtimer or a tasklet might run.
      As the hrtimer triggers its associated tasklet and vice versa we need to
      take care to mutually terminate both handlers.
      Reported-by: default avatarMichael Josenhans <michael.josenhans@web.de>
      Signed-off-by: default avatarOliver Hartkopp <socketcan@hartkopp.net>
      Tested-by: default avatarMichael Josenhans <michael.josenhans@web.de>
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      192c10ab
    • Michal Hocko's avatar
      mm, fs: check for fatal signals in do_generic_file_read() · 32686879
      Michal Hocko authored
      commit 5abf186a upstream.
      
      do_generic_file_read() can be told to perform a large request from
      userspace.  If the system is under OOM and the reading task is the OOM
      victim then it has an access to memory reserves and finishing the full
      request can lead to the full memory depletion which is dangerous.  Make
      sure we rather go with a short read and allow the killed task to
      terminate.
      
      Link: http://lkml.kernel.org/r/20170201092706.9966-3-mhocko@kernel.orgSigned-off-by: default avatarMichal Hocko <mhocko@suse.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      32686879
    • Toshi Kani's avatar
      mm/memory_hotplug.c: check start_pfn in test_pages_in_a_zone() · 2a30945e
      Toshi Kani authored
      commit deb88a2a upstream.
      
      Patch series "fix a kernel oops when reading sysfs valid_zones", v2.
      
      A sysfs memory file is created for each 2GiB memory block on x86-64 when
      the system has 64GiB or more memory.  [1] When the start address of a
      memory block is not backed by struct page, i.e.  a memory range is not
      aligned by 2GiB, reading its 'valid_zones' attribute file leads to a
      kernel oops.  This issue was observed on multiple x86-64 systems with
      more than 64GiB of memory.  This patch-set fixes this issue.
      
      Patch 1 first fixes an issue in test_pages_in_a_zone(), which does not
      test the start section.
      
      Patch 2 then fixes the kernel oops by extending test_pages_in_a_zone()
      to return valid [start, end).
      
      Note for stable kernels: The memory block size change was made by commit
      bdee237c ("x86: mm: Use 2GB memory block size on large-memory x86-64
      systems"), which was accepted to 3.9.  However, this patch-set depends
      on (and fixes) the change to test_pages_in_a_zone() made by commit
      5f0f2887 ("mm/memory_hotplug.c: check for missing sections in
      test_pages_in_a_zone()"), which was accepted to 4.4.
      
      So, I recommend that we backport it up to 4.4.
      
      [1] 'Commit bdee237c ("x86: mm: Use 2GB memory block size on
          large-memory x86-64 systems")'
      
      This patch (of 2):
      
      test_pages_in_a_zone() does not check 'start_pfn' when it is aligned by
      section since 'sec_end_pfn' is set equal to 'pfn'.  Since this function
      is called for testing the range of a sysfs memory file, 'start_pfn' is
      always aligned by section.
      
      Fix it by properly setting 'sec_end_pfn' to the next section pfn.
      
      Also make sure that this function returns 1 only when the range belongs
      to a zone.
      
      Link: http://lkml.kernel.org/r/20170127222149.30893-2-toshi.kani@hpe.comSigned-off-by: default avatarToshi Kani <toshi.kani@hpe.com>
      Cc: Andrew Banman <abanman@sgi.com>
      Cc: Reza Arbab <arbab@linux.vnet.ibm.com>
      Cc: Greg KH <greg@kroah.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      2a30945e
    • Rabin Vincent's avatar
      cifs: initialize file_info_lock · a8740611
      Rabin Vincent authored
      commit 81ddd8c0 upstream.
      Reviewed-by: default avatarJeff Layton <jlayton@redhat.com>
      
      file_info_lock is not initalized in initiate_cifs_search(), leading to the
      following splat after a simple "mount.cifs ... dir && ls dir/":
      
       BUG: spinlock bad magic on CPU#0, ls/486
        lock: 0xffff880009301110, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
       CPU: 0 PID: 486 Comm: ls Not tainted 4.9.0 #27
       Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
        ffffc900042f3db0 ffffffff81327533 0000000000000000 ffff880009301110
        ffffc900042f3dd0 ffffffff810baf75 ffff880009301110 ffffffff817ae077
        ffffc900042f3df0 ffffffff810baff6 ffff880009301110 ffff880008d69900
       Call Trace:
        [<ffffffff81327533>] dump_stack+0x65/0x92
        [<ffffffff810baf75>] spin_dump+0x85/0xe0
        [<ffffffff810baff6>] spin_bug+0x26/0x30
        [<ffffffff810bb159>] do_raw_spin_lock+0xe9/0x130
        [<ffffffff8159ad2f>] _raw_spin_lock+0x1f/0x30
        [<ffffffff8127e50d>] cifs_closedir+0x4d/0x100
        [<ffffffff81181cfd>] __fput+0x5d/0x160
        [<ffffffff81181e3e>] ____fput+0xe/0x10
        [<ffffffff8109410e>] task_work_run+0x7e/0xa0
        [<ffffffff81002512>] exit_to_usermode_loop+0x92/0xa0
        [<ffffffff810026f9>] syscall_return_slowpath+0x49/0x50
        [<ffffffff8159b484>] entry_SYSCALL_64_fastpath+0xa7/0xa9
      
      Fixes: 3afca265 ("Clarify locking of cifs file and tcon structures and make more granular")
      Signed-off-by: default avatarRabin Vincent <rabinv@axis.com>
      Signed-off-by: default avatarSteve French <smfrench@gmail.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      a8740611
    • J. Bruce Fields's avatar
      svcrpc: fix oops in absence of krb5 module · 4b4584fd
      J. Bruce Fields authored
      commit 034dd34f upstream.
      
      Olga Kornievskaia says: "I ran into this oops in the nfsd (below)
      (4.10-rc3 kernel). To trigger this I had a client (unsuccessfully) try
      to mount the server with krb5 where the server doesn't have the
      rpcsec_gss_krb5 module built."
      
      The problem is that rsci.cred is copied from a svc_cred structure that
      gss_proxy didn't properly initialize.  Fix that.
      
      [120408.542387] general protection fault: 0000 [#1] SMP
      ...
      [120408.565724] CPU: 0 PID: 3601 Comm: nfsd Not tainted 4.10.0-rc3+ #16
      [120408.567037] Hardware name: VMware, Inc. VMware Virtual =
      Platform/440BX Desktop Reference Platform, BIOS 6.00 07/02/2015
      [120408.569225] task: ffff8800776f95c0 task.stack: ffffc90003d58000
      [120408.570483] RIP: 0010:gss_mech_put+0xb/0x20 [auth_rpcgss]
      ...
      [120408.584946]  ? rsc_free+0x55/0x90 [auth_rpcgss]
      [120408.585901]  gss_proxy_save_rsc+0xb2/0x2a0 [auth_rpcgss]
      [120408.587017]  svcauth_gss_proxy_init+0x3cc/0x520 [auth_rpcgss]
      [120408.588257]  ? __enqueue_entity+0x6c/0x70
      [120408.589101]  svcauth_gss_accept+0x391/0xb90 [auth_rpcgss]
      [120408.590212]  ? try_to_wake_up+0x4a/0x360
      [120408.591036]  ? wake_up_process+0x15/0x20
      [120408.592093]  ? svc_xprt_do_enqueue+0x12e/0x2d0 [sunrpc]
      [120408.593177]  svc_authenticate+0xe1/0x100 [sunrpc]
      [120408.594168]  svc_process_common+0x203/0x710 [sunrpc]
      [120408.595220]  svc_process+0x105/0x1c0 [sunrpc]
      [120408.596278]  nfsd+0xe9/0x160 [nfsd]
      [120408.597060]  kthread+0x101/0x140
      [120408.597734]  ? nfsd_destroy+0x60/0x60 [nfsd]
      [120408.598626]  ? kthread_park+0x90/0x90
      [120408.599448]  ret_from_fork+0x22/0x30
      
      Fixes: 1d658336 "SUNRPC: Add RPC based upcall mechanism for RPCGSS auth"
      Cc: Simo Sorce <simo@redhat.com>
      Reported-by: default avatarOlga Kornievskaia <kolga@netapp.com>
      Tested-by: default avatarOlga Kornievskaia <kolga@netapp.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      4b4584fd
    • Arvind Yadav's avatar
      ata: sata_mv:- Handle return value of devm_ioremap. · 731771e0
      Arvind Yadav authored
      commit 064c3db9 upstream.
      
      Here, If devm_ioremap will fail. It will return NULL.
      Then hpriv->base = NULL - 0x20000; Kernel can run into
      a NULL-pointer dereference. This error check will avoid
      NULL pointer dereference.
      Signed-off-by: default avatarArvind Yadav <arvind.yadav.cs@gmail.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      731771e0
    • Salvatore Benedetto's avatar
      crypto: api - Clear CRYPTO_ALG_DEAD bit before registering an alg · 913feded
      Salvatore Benedetto authored
      commit d6040764 upstream.
      
      Make sure CRYPTO_ALG_DEAD bit is cleared before proceeding with
      the algorithm registration. This fixes qat-dh registration when
      driver is restarted
      Signed-off-by: default avatarSalvatore Benedetto <salvatore.benedetto@intel.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      913feded
    • Ilia Mirkin's avatar
      drm/nouveau/nv1a,nv1f/disp: fix memory clock rate retrieval · 444642dc
      Ilia Mirkin authored
      commit 24bf7ae3 upstream.
      
      Based on the xf86-video-nv code, NFORCE (NV1A) and NFORCE2 (NV1F) have a
      different way of retrieving clocks. See the
      nv_hw.c:nForceUpdateArbitrationSettings function in the original code
      for how these clocks were accessed.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54587Signed-off-by: default avatarIlia Mirkin <imirkin@alum.mit.edu>
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      444642dc
  2. 15 Feb, 2017 22 commits
  3. 06 Feb, 2017 1 commit
  4. 30 Jan, 2017 2 commits
  5. 27 Jan, 2017 4 commits
    • Jiri Slaby's avatar
      Linux 3.12.70 · d7f41d3b
      Jiri Slaby authored
      d7f41d3b
    • Gu Zheng's avatar
      tmpfs: clear S_ISGID when setting posix ACLs · b0369e53
      Gu Zheng authored
      commit 497de07d upstream.
      
      This change was missed the tmpfs modification in In CVE-2016-7097
      commit 07393101 ("posix_acl: Clear SGID bit when setting
      file permissions")
      It can test by xfstest generic/375, which failed to clear
      setgid bit in the following test case on tmpfs:
      
        touch $testfile
        chown 100:100 $testfile
        chmod 2755 $testfile
        _runas -u 100 -g 101 -- setfacl -m u::rwx,g::rwx,o::rwx $testfile
      Signed-off-by: default avatarGu Zheng <guzheng1@huawei.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      b0369e53
    • Tariq Saeed's avatar
      ocfs2: fix BUG_ON() in ocfs2_ci_checkpointed() · ded56d6d
      Tariq Saeed authored
      commit 3d46a44a upstream.
      
      PID: 614    TASK: ffff882a739da580  CPU: 3   COMMAND: "ocfs2dc"
        #0 [ffff882ecc3759b0] machine_kexec at ffffffff8103b35d
        #1 [ffff882ecc375a20] crash_kexec at ffffffff810b95b5
        #2 [ffff882ecc375af0] oops_end at ffffffff815091d8
        #3 [ffff882ecc375b20] die at ffffffff8101868b
        #4 [ffff882ecc375b50] do_trap at ffffffff81508bb0
        #5 [ffff882ecc375ba0] do_invalid_op at ffffffff810165e5
        #6 [ffff882ecc375c40] invalid_op at ffffffff815116fb
           [exception RIP: ocfs2_ci_checkpointed+208]
           RIP: ffffffffa0a7e940  RSP: ffff882ecc375cf0  RFLAGS: 00010002
           RAX: 0000000000000001  RBX: 000000000000654b  RCX: ffff8812dc83f1f8
           RDX: 00000000000017d9  RSI: ffff8812dc83f1f8  RDI: ffffffffa0b2c318
           RBP: ffff882ecc375d20   R8: ffff882ef6ecfa60   R9: ffff88301f272200
           R10: 0000000000000000  R11: 0000000000000000  R12: ffffffffffffffff
           R13: ffff8812dc83f4f0  R14: 0000000000000000  R15: ffff8812dc83f1f8
           ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
        #7 [ffff882ecc375d28] ocfs2_check_meta_downconvert at ffffffffa0a7edbd [ocfs2]
        #8 [ffff882ecc375d38] ocfs2_unblock_lock at ffffffffa0a84af8 [ocfs2]
        #9 [ffff882ecc375dc8] ocfs2_process_blocked_lock at ffffffffa0a85285 [ocfs2]
      assert is tripped because the tran is not checkpointed and the lock level is PR.
      
      Some time ago, chmod command had been executed. As result, the following call
      chain left the inode cluster lock in PR state, latter on causing the assert.
      system_call_fastpath
        -> my_chmod
         -> sys_chmod
          -> sys_fchmodat
           -> notify_change
            -> ocfs2_setattr
             -> posix_acl_chmod
              -> ocfs2_iop_set_acl
               -> ocfs2_set_acl
                -> ocfs2_acl_set_mode
      Here is how.
      1119 int ocfs2_setattr(struct dentry *dentry, struct iattr *attr)
      1120 {
      1247         ocfs2_inode_unlock(inode, 1); <<< WRONG thing to do.
      ..
      1258         if (!status && attr->ia_valid & ATTR_MODE) {
      1259                 status =  posix_acl_chmod(inode, inode->i_mode);
      
      519 posix_acl_chmod(struct inode *inode, umode_t mode)
      520 {
      ..
      539         ret = inode->i_op->set_acl(inode, acl, ACL_TYPE_ACCESS);
      
      287 int ocfs2_iop_set_acl(struct inode *inode, struct posix_acl *acl, ...
      288 {
      289         return ocfs2_set_acl(NULL, inode, NULL, type, acl, NULL, NULL);
      
      224 int ocfs2_set_acl(handle_t *handle,
      225                          struct inode *inode, ...
      231 {
      ..
      252                                 ret = ocfs2_acl_set_mode(inode, di_bh,
      253                                                          handle, mode);
      
      168 static int ocfs2_acl_set_mode(struct inode *inode, struct buffer_head ...
      170 {
      183         if (handle == NULL) {
                          >>> BUG: inode lock not held in ex at this point <<<
      184                 handle = ocfs2_start_trans(OCFS2_SB(inode->i_sb),
      185                                            OCFS2_INODE_UPDATE_CREDITS);
      
      ocfs2_setattr.#1247 we unlock and at #1259 call posix_acl_chmod. When we reach
      ocfs2_acl_set_mode.#181 and do trans, the inode cluster lock is not held in EX
      mode (it should be). How this could have happended?
      
      We are the lock master, were holding lock EX and have released it in
      ocfs2_setattr.#1247.  Note that there are no holders of this lock at
      this point.  Another node needs the lock in PR, and we downconvert from
      EX to PR.  So the inode lock is PR when do the trans in
      ocfs2_acl_set_mode.#184.  The trans stays in core (not flushed to disc).
      Now another node want the lock in EX, downconvert thread gets kicked
      (the one that tripped assert abovt), finds an unflushed trans but the
      lock is not EX (it is PR).  If the lock was at EX, it would have flushed
      the trans ocfs2_ci_checkpointed -> ocfs2_start_checkpoint before
      downconverting (to NULL) for the request.
      
      ocfs2_setattr must not drop inode lock ex in this code path.  If it
      does, takes it again before the trans, say in ocfs2_set_acl, another
      cluster node can get in between, execute another setattr, overwriting
      the one in progress on this node, resulting in a mode acl size combo
      that is a mix of the two.
      
      Orabug: 20189959
      Signed-off-by: default avatarTariq Saeed <tariq.x.saeed@oracle.com>
      Reviewed-by: default avatarMark Fasheh <mfasheh@suse.de>
      Cc: Joel Becker <jlbec@evilplan.org>
      Cc: Joseph Qi <joseph.qi@huawei.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      ded56d6d
    • Mintz, Yuval's avatar
      bnx2x: Correct ringparam estimate when DOWN · 05dc5c8f
      Mintz, Yuval authored
      commit 65870fa7 upstream.
      
      Until interface is up [and assuming ringparams weren't explicitly
      configured] when queried for the size of its rings bnx2x would
      claim they're the maximal size by default.
      That is incorrect as by default the maximal number of buffers would
      be equally divided between the various rx rings.
      
      This prevents the user from actually setting the number of elements
      on each rx ring to be of maximal size prior to transitioning the
      interface into up state.
      
      To fix this, make a rough estimation about the number of buffers.
      It wouldn't always be accurate, but it would be much better than
      current estimation and would allow users to increase number of
      buffers during early initialization of the interface.
      Reported-by: default avatarSeymour, Shane <shane.seymour@hpe.com>
      Signed-off-by: default avatarYuval Mintz <Yuval.Mintz@cavium.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      05dc5c8f