1. 08 Feb, 2017 1 commit
    • Andrey Ryabinin's avatar
      module: fix types of device tables aliases · af93ebdd
      Andrey Ryabinin authored
      commit 6301939d upstream.
      
      MODULE_DEVICE_TABLE() macro used to create aliases to device tables.
      Normally alias should have the same type as aliased symbol.
      
      Device tables are arrays, so they have 'struct type##_device_id[x]'
      types. Alias created by MODULE_DEVICE_TABLE() will have non-array type -
      	'struct type##_device_id'.
      
      This inconsistency confuses compiler, it could make a wrong assumption
      about variable's size which leads KASan to produce a false positive report
      about out of bounds access.
      
      For every global variable compiler calls __asan_register_globals() passing
      information about global variable (address, size, size with redzone, name
      ...) __asan_register_globals() poison symbols redzone to detect possible
      out of bounds accesses.
      
      When symbol has an alias __asan_register_globals() will be called as for
      symbol so for alias.  Compiler determines size of variable by size of
      variable's type.  Alias and symbol have the same address, so if alias have
      the wrong size part of memory that actually belongs to the symbol could be
      poisoned as redzone of alias symbol.
      
      By fixing type of alias symbol we will fix size of it, so
      __asan_register_globals() will not poison valid memory.
      Signed-off-by: default avatarAndrey Ryabinin <a.ryabinin@samsung.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: Konstantin Serebryany <kcc@google.com>
      Cc: Dmitry Chernenkov <dmitryc@google.com>
      Signed-off-by: default avatarAndrey Konovalov <adech.fo@gmail.com>
      Cc: Yuri Gribov <tetra2005@gmail.com>
      Cc: Konstantin Khlebnikov <koct9i@gmail.com>
      Cc: Sasha Levin <sasha.levin@oracle.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: David Rientjes <rientjes@google.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 avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      af93ebdd
  2. 18 Jan, 2017 1 commit
  3. 15 Jan, 2017 38 commits
    • Alexander Duyck's avatar
      gro: Allow tunnel stacking in the case of FOU/GUE · f087000a
      Alexander Duyck authored
      [ Upstream commit c3483384 ]
      
      This patch should fix the issues seen with a recent fix to prevent
      tunnel-in-tunnel frames from being generated with GRO.  The fix itself is
      correct for now as long as we do not add any devices that support
      NETIF_F_GSO_GRE_CSUM.  When such a device is added it could have the
      potential to mess things up due to the fact that the outer transport header
      points to the outer UDP header and not the GRE header as would be expected.
      
      Fixes: fac8e0f5 ("tunnels: Don't apply GRO to multiple layers of encapsulation.")
      Signed-off-by: default avatarAlexander Duyck <aduyck@mirantis.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      f087000a
    • Jesse Gross's avatar
      tunnels: Don't apply GRO to multiple layers of encapsulation. · dd4fff23
      Jesse Gross authored
      [ Upstream commit fac8e0f5 ]
      
      When drivers express support for TSO of encapsulated packets, they
      only mean that they can do it for one layer of encapsulation.
      Supporting additional levels would mean updating, at a minimum,
      more IP length fields and they are unaware of this.
      
      No encapsulation device expresses support for handling offloaded
      encapsulated packets, so we won't generate these types of frames
      in the transmit path. However, GRO doesn't have a check for
      multiple levels of encapsulation and will attempt to build them.
      
      UDP tunnel GRO actually does prevent this situation but it only
      handles multiple UDP tunnels stacked on top of each other. This
      generalizes that solution to prevent any kind of tunnel stacking
      that would cause problems.
      
      Fixes: bf5a755f ("net-gre-gro: Add GRE support to the GRO stack")
      Signed-off-by: default avatarJesse Gross <jesse@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      dd4fff23
    • Tom Herbert's avatar
      net: Use more bit fields in napi_gro_cb · 218e207f
      Tom Herbert authored
      [ Upstream commit baa32ff4 ]
      
      This patch moves the free and same_flow fields to be bit fields
      (2 and 1 bit sized respectively). This frees up some space for u16's.
      Signed-off-by: default avatarTom Herbert <therbert@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      218e207f
    • Deepa Dinamani's avatar
      net: ipv4: Convert IP network timestamps to be y2038 safe · 59aabf34
      Deepa Dinamani authored
      [ Upstream commit 822c8685 ]
      
      ICMP timestamp messages and IP source route options require
      timestamps to be in milliseconds modulo 24 hours from
      midnight UT format.
      
      Add inet_current_timestamp() function to support this. The function
      returns the required timestamp in network byte order.
      
      Timestamp calculation is also changed to call ktime_get_real_ts64()
      which uses struct timespec64. struct timespec64 is y2038 safe.
      Previously it called getnstimeofday() which uses struct timespec.
      struct timespec is not y2038 safe.
      Signed-off-by: default avatarDeepa Dinamani <deepa.kernel@gmail.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
      Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
      Cc: James Morris <jmorris@namei.org>
      Cc: Patrick McHardy <kaber@trash.net>
      Acked-by: default avatarYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      59aabf34
    • Jesse Gross's avatar
      ipip: Properly mark ipip GRO packets as encapsulated. · bd73bf40
      Jesse Gross authored
      [ Upstream commit b8cba75b ]
      
      ipip encapsulated packets can be merged together by GRO but the result
      does not have the proper GSO type set or even marked as being
      encapsulated at all. Later retransmission of these packets will likely
      fail if the device does not support ipip offloads. This is similar to
      the issue resolved in IPv6 sit in feec0cb3
      ("ipv6: gro: support sit protocol").
      Reported-by: default avatarPatrick Boutilier <boutilpj@ednet.ns.ca>
      Fixes: 9667e9bb ("ipip: Add gro callbacks to ipip offload")
      Tested-by: default avatarPatrick Boutilier <boutilpj@ednet.ns.ca>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarJesse Gross <jesse@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      bd73bf40
    • Al Viro's avatar
      sg_write()/bsg_write() is not fit to be called under KERNEL_DS · a861b921
      Al Viro authored
      [ Upstream commit 128394ef ]
      
      Both damn things interpret userland pointers embedded into the payload;
      worse, they are actually traversing those.  Leaving aside the bad
      API design, this is very much _not_ safe to call with KERNEL_DS.
      Bail out early if that happens.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      a861b921
    • Aleksa Sarai's avatar
      fs: exec: apply CLOEXEC before changing dumpable task flags · 77e36d73
      Aleksa Sarai authored
      [ Upstream commit 613cc2b6 ]
      
      If you have a process that has set itself to be non-dumpable, and it
      then undergoes exec(2), any CLOEXEC file descriptors it has open are
      "exposed" during a race window between the dumpable flags of the process
      being reset for exec(2) and CLOEXEC being applied to the file
      descriptors. This can be exploited by a process by attempting to access
      /proc/<pid>/fd/... during this window, without requiring CAP_SYS_PTRACE.
      
      The race in question is after set_dumpable has been (for get_link,
      though the trace is basically the same for readlink):
      
      [vfs]
      -> proc_pid_link_inode_operations.get_link
         -> proc_pid_get_link
            -> proc_fd_access_allowed
               -> ptrace_may_access(task, PTRACE_MODE_READ_FSCREDS);
      
      Which will return 0, during the race window and CLOEXEC file descriptors
      will still be open during this window because do_close_on_exec has not
      been called yet. As a result, the ordering of these calls should be
      reversed to avoid this race window.
      
      This is of particular concern to container runtimes, where joining a
      PID namespace with file descriptors referring to the host filesystem
      can result in security issues (since PRCTL_SET_DUMPABLE doesn't protect
      against access of CLOEXEC file descriptors -- file descriptors which may
      reference filesystem objects the container shouldn't have access to).
      
      Cc: dev@opencontainers.org
      Cc: <stable@vger.kernel.org> # v3.2+
      Reported-by: default avatarMichael Crosby <crosbymichael@gmail.com>
      Signed-off-by: default avatarAleksa Sarai <asarai@suse.de>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      77e36d73
    • Bart Van Assche's avatar
      IB/cma: Fix a race condition in iboe_addr_get_sgid() · 59e6ec3d
      Bart Van Assche authored
      [ Upstream commit fba332b0 ]
      
      Code that dereferences the struct net_device ip_ptr member must be
      protected with an in_dev_get() / in_dev_put() pair. Hence insert
      calls to these functions.
      
      Fixes: commit 7b85627b ("IB/cma: IBoE (RoCE) IP-based GID addressing")
      Signed-off-by: default avatarBart Van Assche <bart.vanassche@sandisk.com>
      Reviewed-by: default avatarMoni Shoua <monis@mellanox.com>
      Cc: Or Gerlitz <ogerlitz@mellanox.com>
      Cc: Roland Dreier <roland@purestorage.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      59e6ec3d
    • Takashi Iwai's avatar
      Revert "ALSA: usb-audio: Fix race at stopping the stream" · c318c814
      Takashi Iwai authored
      [ Upstream commit f8114f85 ]
      
      This reverts commit 16200948.
      
      The commit was intended to cover the race condition, but it introduced
      yet another regression for devices with the implicit feedback, leading
      to a kernel panic due to NULL-dereference in an irq context.
      
      As the race condition that was addressed by the commit is very rare
      and the regression is much worse, let's revert the commit for rc1, and
      fix the issue properly in a later patch.
      
      Fixes: 16200948 ("ALSA: usb-audio: Fix race at stopping the stream")
      Reported-by: default avatarIoan-Adrian Ratiu <adi@adirat.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      c318c814
    • Russell Currey's avatar
      drivers/gpu/drm/ast: Fix infinite loop if read fails · 1eb7f3ea
      Russell Currey authored
      [ Upstream commit 298360af ]
      
      ast_get_dram_info() configures a window in order to access BMC memory.
      A BMC register can be configured to disallow this, and if so, causes
      an infinite loop in the ast driver which renders the system unusable.
      
      Fix this by erroring out if an error is detected.  On powerpc systems with
      EEH, this leads to the device being fenced and the system continuing to
      operate.
      
      Cc: <stable@vger.kernel.org> # 3.10+
      Signed-off-by: default avatarRussell Currey <ruscur@russell.cc>
      Reviewed-by: default avatarJoel Stanley <joel@jms.id.au>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/20161215051241.20815-1-ruscur@russell.ccSigned-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      1eb7f3ea
    • Andy Grover's avatar
      target/user: Fix use-after-free of tcmu_cmds if they are expired · fcc5da2c
      Andy Grover authored
      [ Upstream commit d0905ca7 ]
      
      Don't free the cmd in tcmu_check_expired_cmd, it's still referenced by
      an entry in our cmd_id->cmd idr. If userspace ever resumes processing,
      tcmu_handle_completions() will use the now-invalid cmd pointer.
      
      Instead, don't free cmd. It will be freed by tcmu_handle_completion() if
      userspace ever recovers, or tcmu_free_device if not.
      
      Cc: stable@vger.kernel.org
      Reported-by: default avatarBryant G Ly <bgly@us.ibm.com>
      Tested-by: default avatarBryant G Ly <bgly@us.ibm.com>
      Signed-off-by: default avatarAndy Grover <agrover@redhat.com>
      Signed-off-by: default avatarBart Van Assche <bart.vanassche@sandisk.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      fcc5da2c
    • Wei Fang's avatar
      scsi: avoid a permanent stop of the scsi device's request queue · 3386c47b
      Wei Fang authored
      [ Upstream commit d2a14525 ]
      
      A race between scanning and fc_remote_port_delete() may result in a
      permanent stop if the device gets blocked before scsi_sysfs_add_sdev()
      and unblocked after.  The reason is that blocking a device sets both the
      SDEV_BLOCKED state and the QUEUE_FLAG_STOPPED.  However,
      scsi_sysfs_add_sdev() unconditionally sets SDEV_RUNNING which causes the
      device to be ignored by scsi_target_unblock() and thus never have its
      QUEUE_FLAG_STOPPED cleared leading to a device which is apparently
      running but has a stopped queue.
      
      We actually have two places where SDEV_RUNNING is set: once in
      scsi_add_lun() which respects the blocked flag and once in
      scsi_sysfs_add_sdev() which doesn't.  Since the second set is entirely
      spurious, simply remove it to fix the problem.
      
      Cc: <stable@vger.kernel.org>
      Reported-by: default avatarZengxi Chen <chenzengxi@huawei.com>
      Signed-off-by: default avatarWei Fang <fangwei1@huawei.com>
      Reviewed-by: default avatarEwan D. Milne <emilne@redhat.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      3386c47b
    • Bart Van Assche's avatar
      IPoIB: Avoid reading an uninitialized member variable · 8dcd21b3
      Bart Van Assche authored
      [ Upstream commit 11b642b8 ]
      
      This patch avoids that Coverity reports the following:
      
          Using uninitialized value port_attr.state when calling printk
      
      Fixes: commit 94232d9c ("IPoIB: Start multicast join process only on active ports")
      Signed-off-by: default avatarBart Van Assche <bart.vanassche@sandisk.com>
      Cc: Erez Shitrit <erezsh@mellanox.com>
      Cc: <stable@vger.kernel.org>
      Reviewed-by: default avatarLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      8dcd21b3
    • NeilBrown's avatar
      block_dev: don't test bdev->bd_contains when it is not stable · 9cdff4fe
      NeilBrown authored
      [ Upstream commit bcc7f5b4 ]
      
      bdev->bd_contains is not stable before calling __blkdev_get().
      When __blkdev_get() is called on a parition with ->bd_openers == 0
      it sets
        bdev->bd_contains = bdev;
      which is not correct for a partition.
      After a call to __blkdev_get() succeeds, ->bd_openers will be > 0
      and then ->bd_contains is stable.
      
      When FMODE_EXCL is used, blkdev_get() calls
         bd_start_claiming() ->  bd_prepare_to_claim() -> bd_may_claim()
      
      This call happens before __blkdev_get() is called, so ->bd_contains
      is not stable.  So bd_may_claim() cannot safely use ->bd_contains.
      It currently tries to use it, and this can lead to a BUG_ON().
      
      This happens when a whole device is already open with a bd_holder (in
      use by dm in my particular example) and two threads race to open a
      partition of that device for the first time, one opening with O_EXCL and
      one without.
      
      The thread that doesn't use O_EXCL gets through blkdev_get() to
      __blkdev_get(), gains the ->bd_mutex, and sets bdev->bd_contains = bdev;
      
      Immediately thereafter the other thread, using FMODE_EXCL, calls
      bd_start_claiming() from blkdev_get().  This should fail because the
      whole device has a holder, but because bdev->bd_contains == bdev
      bd_may_claim() incorrectly reports success.
      This thread continues and blocks on bd_mutex.
      
      The first thread then sets bdev->bd_contains correctly and drops the mutex.
      The thread using FMODE_EXCL then continues and when it calls bd_may_claim()
      again in:
      			BUG_ON(!bd_may_claim(bdev, whole, holder));
      The BUG_ON fires.
      
      Fix this by removing the dependency on ->bd_contains in
      bd_may_claim().  As bd_may_claim() has direct access to the whole
      device, it can simply test if the target bdev is the whole device.
      
      Fixes: 6b4517a7 ("block: implement bd_claiming and claiming block")
      Cc: stable@vger.kernel.org (v2.6.35+)
      Signed-off-by: default avatarNeilBrown <neilb@suse.com>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      9cdff4fe
    • Jingkui Wang's avatar
      Input: drv260x - fix input device's parent assignment · ad6be98a
      Jingkui Wang authored
      [ Upstream commit 5a8a6b89 ]
      
      We were assigning I2C bus controller instead of client as parent device.
      Besides being logically wrong, it messed up with devm handling of input
      device. As a result we were leaving input device and event node behind
      after rmmod-ing the driver, which lead to a kernel oops if one were to
      access the event node later.
      
      Let's remove the assignment and rely on devm_input_allocate_device() to
      set it up properly for us.
      Signed-off-by: default avatarJingkui Wang <jkwang@google.com>
      Fixes: 7132fe4f ("Input: drv260x - add TI drv260x haptics driver")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      ad6be98a
    • Ilya Dryomov's avatar
      libceph: verify authorize reply on connect · 2eb056b5
      Ilya Dryomov authored
      [ Upstream commit 5c056fdc ]
      
      After sending an authorizer (ceph_x_authorize_a + ceph_x_authorize_b),
      the client gets back a ceph_x_authorize_reply, which it is supposed to
      verify to ensure the authenticity and protect against replay attacks.
      The code for doing this is there (ceph_x_verify_authorizer_reply(),
      ceph_auth_verify_authorizer_reply() + plumbing), but it is never
      invoked by the the messenger.
      
      AFAICT this goes back to 2009, when ceph authentication protocols
      support was added to the kernel client in 4e7a5dcd ("ceph:
      negotiate authentication protocol; implement AUTH_NONE protocol").
      
      The second param of ceph_connection_operations::verify_authorizer_reply
      is unused all the way down.  Pass 0 to facilitate backporting, and kill
      it in the next commit.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      Reviewed-by: default avatarSage Weil <sage@redhat.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      2eb056b5
    • Jussi Laako's avatar
      ALSA: hiface: Fix M2Tech hiFace driver sampling rate change · 91a34ab0
      Jussi Laako authored
      [ Upstream commit 995c6a7f ]
      
      Sampling rate changes after first set one are not reflected to the
      hardware, while driver and ALSA think the rate has been changed.
      
      Fix the problem by properly stopping the interface at the beginning of
      prepare call, allowing new rate to be set to the hardware. This keeps
      the hardware in sync with the driver.
      Signed-off-by: default avatarJussi Laako <jussi@sonarnerd.net>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      91a34ab0
    • Gerald Schaefer's avatar
      s390/vmlogrdr: fix IUCV buffer allocation · 81aaf3cb
      Gerald Schaefer authored
      [ Upstream commit 5457e03d ]
      
      The buffer for iucv_message_receive() needs to be below 2 GB. In
      __iucv_message_receive(), the buffer address is casted to an u32, which
      would result in either memory corruption or an addressing exception when
      using addresses >= 2 GB.
      
      Fix this by using GFP_DMA for the buffer allocation.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGerald Schaefer <gerald.schaefer@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      81aaf3cb
    • Ben Hutchings's avatar
      kconfig/nconf: Fix hang when editing symbol with a long prompt · 023a7e06
      Ben Hutchings authored
      [ Upstream commit 79e51b5c ]
      
      Currently it is impossible to edit the value of a config symbol with a
      prompt longer than (terminal width - 2) characters.  dialog_inputbox()
      calculates a negative x-offset for the input window and newwin() fails
      as this is invalid.  It also doesn't check for this failure, so it
      busy-loops calling wgetch(NULL) which immediately returns -1.
      
      The additions in the offset calculations also don't match the intended
      size of the window.
      
      Limit the window size and calculate the offset similarly to
      show_scroll_win().
      
      Cc: stable <stable@vger.kernel.org>
      Fixes: 692d97c3 ("kconfig: new configuration interface (nconfig)")
      Signed-off-by: default avatarBen Hutchings <ben.hutchings@codethink.co.uk>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      023a7e06
    • NeilBrown's avatar
      SUNRPC: fix refcounting problems with auth_gss messages. · 6fc6cae4
      NeilBrown authored
      [ Upstream commit 1cded9d2 ]
      
      There are two problems with refcounting of auth_gss messages.
      
      First, the reference on the pipe->pipe list (taken by a call
      to rpc_queue_upcall()) is not counted.  It seems to be
      assumed that a message in pipe->pipe will always also be in
      pipe->in_downcall, where it is correctly reference counted.
      
      However there is no guaranty of this.  I have a report of a
      NULL dereferences in rpc_pipe_read() which suggests a msg
      that has been freed is still on the pipe->pipe list.
      
      One way I imagine this might happen is:
      - message is queued for uid=U and auth->service=S1
      - rpc.gssd reads this message and starts processing.
        This removes the message from pipe->pipe
      - message is queued for uid=U and auth->service=S2
      - rpc.gssd replies to the first message. gss_pipe_downcall()
        calls __gss_find_upcall(pipe, U, NULL) and it finds the
        *second* message, as new messages are placed at the head
        of ->in_downcall, and the service type is not checked.
      - This second message is removed from ->in_downcall and freed
        by gss_release_msg() (even though it is still on pipe->pipe)
      - rpc.gssd tries to read another message, and dereferences a pointer
        to this message that has just been freed.
      
      I fix this by incrementing the reference count before calling
      rpc_queue_upcall(), and decrementing it if that fails, or normally in
      gss_pipe_destroy_msg().
      
      It seems strange that the reply doesn't target the message more
      precisely, but I don't know all the details.  In any case, I think the
      reference counting irregularity became a measureable bug when the
      extra arg was added to __gss_find_upcall(), hence the Fixes: line
      below.
      
      The second problem is that if rpc_queue_upcall() fails, the new
      message is not freed. gss_alloc_msg() set the ->count to 1,
      gss_add_msg() increments this to 2, gss_unhash_msg() decrements to 1,
      then the pointer is discarded so the memory never gets freed.
      
      Fixes: 9130b8db ("SUNRPC: allow for upcalls for same uid but different gss service")
      Cc: stable@vger.kernel.org
      Link: https://bugzilla.opensuse.org/show_bug.cgi?id=1011250Signed-off-by: default avatarNeilBrown <neilb@suse.com>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      6fc6cae4
    • Dan Carpenter's avatar
      ext4: return -ENOMEM instead of success · 0d39ae1e
      Dan Carpenter authored
      [ Upstream commit 578620f4 ]
      
      We should set the error code if kzalloc() fails.
      
      Fixes: 67cf5b09 ("ext4: add the basic function for inline data support")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      0d39ae1e
    • Al Viro's avatar
      nfs_write_end(): fix handling of short copies · 79762247
      Al Viro authored
      [ Upstream commit c0cf3ef5 ]
      
      What matters when deciding if we should make a page uptodate is
      not how much we _wanted_ to copy, but how much we actually have
      copied.  As it is, on architectures that do not zero tail on
      short copy we can leave uninitialized data in page marked uptodate.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      79762247
    • Steven Rostedt (Red Hat)'s avatar
      fgraph: Handle a case where a tracer ignores set_graph_notrace · 1a1f89b3
      Steven Rostedt (Red Hat) authored
      [ Upstream commit 794de08a ]
      
      Both the wakeup and irqsoff tracers can use the function graph tracer when
      the display-graph option is set. The problem is that they ignore the notrace
      file, and record the entry of functions that would be ignored by the
      function_graph tracer. This causes the trace->depth to be recorded into the
      ring buffer. The set_graph_notrace uses a trick by adding a large negative
      number to the trace->depth when a graph function is to be ignored.
      
      On trace output, the graph function uses the depth to record a stack of
      functions. But since the depth is negative, it accesses the array with a
      negative number and causes an out of bounds access that can cause a kernel
      oops or corrupt data.
      
      Have the print functions handle cases where a tracer still records functions
      even when they are in set_graph_notrace.
      
      Also add warnings if the depth is below zero before accessing the array.
      
      Note, the function graph logic will still prevent the return of these
      functions from being recorded, which means that they will be left hanging
      without a return. For example:
      
         # echo '*spin*' > set_graph_notrace
         # echo 1 > options/display-graph
         # echo wakeup > current_tracer
         # cat trace
         [...]
            _raw_spin_lock() {
              preempt_count_add() {
              do_raw_spin_lock() {
            update_rq_clock();
      
      Where it should look like:
      
            _raw_spin_lock() {
              preempt_count_add();
              do_raw_spin_lock();
            }
            update_rq_clock();
      
      Cc: stable@vger.kernel.org
      Cc: Namhyung Kim <namhyung.kim@lge.com>
      Fixes: 29ad23b0 ("ftrace: Add set_graph_notrace filter")
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      1a1f89b3
    • Giuseppe Lippolis's avatar
      USB: serial: option: add dlink dwm-158 · 3e6eb9d1
      Giuseppe Lippolis authored
      [ Upstream commit d8a12b71 ]
      
      Adding registration for 3G modem DWM-158 in usb-serial-option
      Signed-off-by: default avatarGiuseppe Lippolis <giu.lippolis@gmail.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      3e6eb9d1
    • Daniele Palmas's avatar
      USB: serial: option: add support for Telit LE922A PIDs 0x1040, 0x1041 · 53453ed7
      Daniele Palmas authored
      [ Upstream commit 5b09eff0 ]
      
      This patch adds support for PIDs 0x1040, 0x1041 of Telit LE922A.
      
      Since the interface positions are the same than the ones used
      for other Telit compositions, previous defined blacklists are used.
      Signed-off-by: default avatarDaniele Palmas <dnlplm@gmail.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      53453ed7
    • Con Kolivas's avatar
      ALSA: usb-audio: Add QuickCam Communicate Deluxe/S7500 to volume_control_quirks · 9eb0316c
      Con Kolivas authored
      [ Upstream commit 82ffb6fc ]
      
      The Logitech QuickCam Communicate Deluxe/S7500 microphone fails with the
      following warning.
      
      [    6.778995] usb 2-1.2.2.2: Warning! Unlikely big volume range (=3072),
      cval->res is probably wrong.
      [    6.778996] usb 2-1.2.2.2: [5] FU [Mic Capture Volume] ch = 1, val =
      4608/7680/1
      
      Adding it to the list of devices in volume_control_quirks makes it work
      properly, fixing related typo.
      Signed-off-by: default avatarCon Kolivas <kernel@kolivas.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      9eb0316c
    • Benjamin Marzinski's avatar
      dm space map metadata: fix 'struct sm_metadata' leak on failed create · 4aedc0b0
      Benjamin Marzinski authored
      [ Upstream commit 314c25c5 ]
      
      In dm_sm_metadata_create() we temporarily change the dm_space_map
      operations from 'ops' (whose .destroy function deallocates the
      sm_metadata) to 'bootstrap_ops' (whose .destroy function doesn't).
      
      If dm_sm_metadata_create() fails in sm_ll_new_metadata() or
      sm_ll_extend(), it exits back to dm_tm_create_internal(), which calls
      dm_sm_destroy() with the intention of freeing the sm_metadata, but it
      doesn't (because the dm_space_map operations is still set to
      'bootstrap_ops').
      
      Fix this by setting the dm_space_map operations back to 'ops' if
      dm_sm_metadata_create() fails when it is set to 'bootstrap_ops'.
      Signed-off-by: default avatarBenjamin Marzinski <bmarzins@redhat.com>
      Acked-by: default avatarJoe Thornber <ejt@redhat.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      4aedc0b0
    • Julien Grall's avatar
      arm/xen: Use alloc_percpu rather than __alloc_percpu · 16691059
      Julien Grall authored
      [ Upstream commit 24d5373d ]
      
      The function xen_guest_init is using __alloc_percpu with an alignment
      which are not power of two.
      
      However, the percpu allocator never supported alignments which are not power
      of two and has always behaved incorectly in thise case.
      
      Commit 3ca45a46 "percpu: ensure requested alignment is power of two"
      introduced a check which trigger a warning [1] when booting linux-next
      on Xen. But in reality this bug was always present.
      
      This can be fixed by replacing the call to __alloc_percpu with
      alloc_percpu. The latter will use an alignment which are a power of two.
      
      [1]
      
      [    0.023921] illegal size (48) or align (48) for percpu allocation
      [    0.024167] ------------[ cut here ]------------
      [    0.024344] WARNING: CPU: 0 PID: 1 at linux/mm/percpu.c:892 pcpu_alloc+0x88/0x6c0
      [    0.024584] Modules linked in:
      [    0.024708]
      [    0.024804] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
      4.9.0-rc7-next-20161128 #473
      [    0.025012] Hardware name: Foundation-v8A (DT)
      [    0.025162] task: ffff80003d870000 task.stack: ffff80003d844000
      [    0.025351] PC is at pcpu_alloc+0x88/0x6c0
      [    0.025490] LR is at pcpu_alloc+0x88/0x6c0
      [    0.025624] pc : [<ffff00000818e678>] lr : [<ffff00000818e678>]
      pstate: 60000045
      [    0.025830] sp : ffff80003d847cd0
      [    0.025946] x29: ffff80003d847cd0 x28: 0000000000000000
      [    0.026147] x27: 0000000000000000 x26: 0000000000000000
      [    0.026348] x25: 0000000000000000 x24: 0000000000000000
      [    0.026549] x23: 0000000000000000 x22: 00000000024000c0
      [    0.026752] x21: ffff000008e97000 x20: 0000000000000000
      [    0.026953] x19: 0000000000000030 x18: 0000000000000010
      [    0.027155] x17: 0000000000000a3f x16: 00000000deadbeef
      [    0.027357] x15: 0000000000000006 x14: ffff000088f79c3f
      [    0.027573] x13: ffff000008f79c4d x12: 0000000000000041
      [    0.027782] x11: 0000000000000006 x10: 0000000000000042
      [    0.027995] x9 : ffff80003d847a40 x8 : 6f697461636f6c6c
      [    0.028208] x7 : 6120757063726570 x6 : ffff000008f79c84
      [    0.028419] x5 : 0000000000000005 x4 : 0000000000000000
      [    0.028628] x3 : 0000000000000000 x2 : 000000000000017f
      [    0.028840] x1 : ffff80003d870000 x0 : 0000000000000035
      [    0.029056]
      [    0.029152] ---[ end trace 0000000000000000 ]---
      [    0.029297] Call trace:
      [    0.029403] Exception stack(0xffff80003d847b00 to
                                     0xffff80003d847c30)
      [    0.029621] 7b00: 0000000000000030 0001000000000000
      ffff80003d847cd0 ffff00000818e678
      [    0.029901] 7b20: 0000000000000002 0000000000000004
      ffff000008f7c060 0000000000000035
      [    0.030153] 7b40: ffff000008f79000 ffff000008c4cd88
      ffff80003d847bf0 ffff000008101778
      [    0.030402] 7b60: 0000000000000030 0000000000000000
      ffff000008e97000 00000000024000c0
      [    0.030647] 7b80: 0000000000000000 0000000000000000
      0000000000000000 0000000000000000
      [    0.030895] 7ba0: 0000000000000035 ffff80003d870000
      000000000000017f 0000000000000000
      [    0.031144] 7bc0: 0000000000000000 0000000000000005
      ffff000008f79c84 6120757063726570
      [    0.031394] 7be0: 6f697461636f6c6c ffff80003d847a40
      0000000000000042 0000000000000006
      [    0.031643] 7c00: 0000000000000041 ffff000008f79c4d
      ffff000088f79c3f 0000000000000006
      [    0.031877] 7c20: 00000000deadbeef 0000000000000a3f
      [    0.032051] [<ffff00000818e678>] pcpu_alloc+0x88/0x6c0
      [    0.032229] [<ffff00000818ece8>] __alloc_percpu+0x18/0x20
      [    0.032409] [<ffff000008d9606c>] xen_guest_init+0x174/0x2f4
      [    0.032591] [<ffff0000080830f8>] do_one_initcall+0x38/0x130
      [    0.032783] [<ffff000008d90c34>] kernel_init_freeable+0xe0/0x248
      [    0.032995] [<ffff00000899a890>] kernel_init+0x10/0x100
      [    0.033172] [<ffff000008082ec0>] ret_from_fork+0x10/0x50
      Reported-by: default avatarWei Chen <wei.chen@arm.com>
      Link: https://lkml.org/lkml/2016/11/28/669Signed-off-by: default avatarJulien Grall <julien.grall@arm.com>
      Signed-off-by: default avatarStefano Stabellini <sstabellini@kernel.org>
      Reviewed-by: default avatarStefano Stabellini <sstabellini@kernel.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      16691059
    • Alex Deucher's avatar
      drm/radeon: add additional pci revision to dpm workaround · 580d23f5
      Alex Deucher authored
      [ Upstream commit 8729675c ]
      
      New variant.
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      580d23f5
    • Pavel Shilovsky's avatar
      CIFS: Fix a possible memory corruption during reconnect · d0d2a4c8
      Pavel Shilovsky authored
      [ Upstream commit 53e0e11e ]
      
      We can not unlock/lock cifs_tcp_ses_lock while walking through ses
      and tcon lists because it can corrupt list iterator pointers and
      a tcon structure can be released if we don't hold an extra reference.
      Fix it by moving a reconnect process to a separate delayed work
      and acquiring a reference to every tcon that needs to be reconnected.
      Also do not send an echo request on newly established connections.
      
      CC: Stable <stable@vger.kernel.org>
      Signed-off-by: default avatarPavel Shilovsky <pshilov@microsoft.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      d0d2a4c8
    • Pavel Shilovsky's avatar
      CIFS: Fix a possible memory corruption in push locks · be79af5f
      Pavel Shilovsky authored
      [ Upstream commit e3d240e9 ]
      
      If maxBuf is not 0 but less than a size of SMB2 lock structure
      we can end up with a memory corruption.
      
      Cc: Stable <stable@vger.kernel.org>
      Signed-off-by: default avatarPavel Shilovsky <pshilov@microsoft.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      be79af5f
    • Pavel Shilovsky's avatar
      CIFS: Fix missing nls unload in smb2_reconnect() · 6ec5ca62
      Pavel Shilovsky authored
      [ Upstream commit 4772c795 ]
      
      Cc: Stable <stable@vger.kernel.org>
      Acked-by: default avatarSachin Prabhu <sprabhu@redhat.com>
      Signed-off-by: default avatarPavel Shilovsky <pshilov@microsoft.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      6ec5ca62
    • Nathaniel Quillin's avatar
      USB: cdc-acm: add device id for GW Instek AFG-125 · 707d28d3
      Nathaniel Quillin authored
      [ Upstream commit 30121604 ]
      
      Add device-id entry for GW Instek AFG-125, which has a byte swapped
      bInterfaceSubClass (0x20).
      Signed-off-by: default avatarNathaniel Quillin <ndq@google.com>
      Acked-by: default avatarOliver Neukum <oneukum@suse.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      707d28d3
    • Adrian Hunter's avatar
      mmc: sdhci: Fix recovery from tuning timeout · 6fe58456
      Adrian Hunter authored
      [ Upstream commit 61e53bd0 ]
      
      Clearing the tuning bits should reset the tuning circuit. However there is
      more to do. Reset the command and data lines for good measure, and then
      for eMMC ensure the card is not still trying to process a tuning command by
      sending a stop command.
      
      Note the JEDEC eMMC specification says the stop command (CMD12) can be used
      to stop a tuning command (CMD21) whereas the SD specification is silent on
      the subject with respect to the SD tuning command (CMD19). Considering that
      CMD12 is not a valid SDIO command, the stop command is sent only when the
      tuning command is CMD21 i.e. for eMMC. That addresses cases seen so far
      which have been on eMMC.
      
      Note that this replaces the commit fe5fb2e3 ("mmc: sdhci: Reset cmd and
      data circuits after tuning failure") which is being reverted for v4.9+.
      Signed-off-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Tested-by: default avatarDan O'Donovan <dan@emutex.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      6fe58456
    • Takashi Iwai's avatar
      ALSA: usb-audio: Fix race at stopping the stream · 74a1a07c
      Takashi Iwai authored
      [ Upstream commit 16200948 ]
      
      We've got a kernel crash report showing like:
      
        Unable to handle kernel NULL pointer dereference at virtual address 00000008 pgd = a1d7c000
        [00000008] *pgd=31c93831, *pte=00000000, *ppte=00000000
        Internal error: Oops: 17 [#1] PREEMPT SMP ARM
        CPU: 0 PID: 250 Comm: dbus-daemon Not tainted 3.14.51-03479-gf50bdf4 #1
        task: a3ae61c0 ti: a08c8000 task.ti: a08c8000
        PC is at retire_capture_urb+0x10/0x1f4 [snd_usb_audio]
        LR is at snd_complete_urb+0x140/0x1f0 [snd_usb_audio]
        pc : [<7f0eb22c>]    lr : [<7f0e57fc>]    psr: 200e0193
        sp : a08c9c98  ip : a08c9ce8  fp : a08c9ce4
        r10: 0000000a  r9 : 00000102  r8 : 94cb3000
        r7 : 94cb3000  r6 : 94d0f000  r5 : 94d0e8e8  r4 : 94d0e000
        r3 : 7f0eb21c  r2 : 00000000  r1 : 94cb3000  r0 : 00000000
        Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
        Control: 10c5387d  Table: 31d7c04a  DAC: 00000015
        Process dbus-daemon (pid: 250, stack limit = 0xa08c8238)
        Stack: (0xa08c9c98 to 0xa08ca000)
        ...
        Backtrace:
        [<7f0eb21c>] (retire_capture_urb [snd_usb_audio]) from [<7f0e57fc>] (snd_complete_urb+0x140/0x1f0 [snd_usb_audio])
        [<7f0e56bc>] (snd_complete_urb [snd_usb_audio]) from [<80371118>] (__usb_hcd_giveback_urb+0x78/0xf4)
        [<803710a0>] (__usb_hcd_giveback_urb) from [<80371514>] (usb_giveback_urb_bh+0x8c/0xc0)
        [<80371488>] (usb_giveback_urb_bh) from [<80028e3c>] (tasklet_hi_action+0xc4/0x148)
        [<80028d78>] (tasklet_hi_action) from [<80028358>] (__do_softirq+0x190/0x380)
        [<800281c8>] (__do_softirq) from [<80028858>] (irq_exit+0x8c/0xfc)
        [<800287cc>] (irq_exit) from [<8000ea88>] (handle_IRQ+0x8c/0xc8)
        [<8000e9fc>] (handle_IRQ) from [<800085e8>] (gic_handle_irq+0xbc/0xf8)
        [<8000852c>] (gic_handle_irq) from [<80509044>] (__irq_svc+0x44/0x78)
        [<80508820>] (_raw_spin_unlock_irq) from [<8004b880>] (finish_task_switch+0x5c/0x100)
        [<8004b824>] (finish_task_switch) from [<805052f0>] (__schedule+0x48c/0x6d8)
        [<80504e64>] (__schedule) from [<805055d4>] (schedule+0x98/0x9c)
        [<8050553c>] (schedule) from [<800116c8>] (do_work_pending+0x30/0xd0)
        [<80011698>] (do_work_pending) from [<8000e160>] (work_pending+0xc/0x20)
        Code: e1a0c00d e92ddff0 e24cb004 e24dd024 (e5902008)
        Kernel panic - not syncing: Fatal exception in interrupt
      
      There is a race between retire_capture_urb() and stop_endpoints().
      The latter is called at stopping the stream and it sets some endpoint
      fields to NULL.  But its call is asynchronous, thus the pending
      complete callback might get called after these NULL clears, and it
      leads the NULL dereference like the above.
      
      The fix is to move the NULL clearance after the synchronization,
      i.e. wait_clear_urbs().  This is called at prepare and hw_free
      callbacks, so it's assured to be called before the restart of the
      stream or the release of the stream.
      
      Also, while we're at it, put the EP_FLAG_RUNNING flag check at the
      beginning of snd_complete_urb() to skip the pending complete after the
      stream is stopped.
      
      Fixes: b2eb950d ("ALSA: usb-audio: stop both data and sync...")
      Reported-by: default avatarJiada Wang <jiada_wang@mentor.com>
      Reported-by: default avatarMark Craske <Mark_Craske@mentor.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      74a1a07c
    • Eric Sandeen's avatar
      xfs: set AGI buffer type in xlog_recover_clear_agi_bucket · b5820655
      Eric Sandeen authored
      [ Upstream commit 6b10b23c ]
      
      xlog_recover_clear_agi_bucket didn't set the
      type to XFS_BLFT_AGI_BUF, so we got a warning during log
      replay (or an ASSERT on a debug build).
      
          XFS (md0): Unknown buffer type 0!
          XFS (md0): _xfs_buf_ioapply: no ops on block 0xaea8802/0x1
      
      Fix this, as was done in f19b872b for 2 other locations
      with the same problem.
      
      cc: <stable@vger.kernel.org> # 3.10 to current
      Signed-off-by: default avatarEric Sandeen <sandeen@redhat.com>
      Reviewed-by: default avatarBrian Foster <bfoster@redhat.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      b5820655
    • Rabin Vincent's avatar
      block: protect iterate_bdevs() against concurrent close · d0cfefba
      Rabin Vincent authored
      [ Upstream commit af309226 ]
      
      If a block device is closed while iterate_bdevs() is handling it, the
      following NULL pointer dereference occurs because bdev->b_disk is NULL
      in bdev_get_queue(), which is called from blk_get_backing_dev_info() (in
      turn called by the mapping_cap_writeback_dirty() call in
      __filemap_fdatawrite_range()):
      
       BUG: unable to handle kernel NULL pointer dereference at 0000000000000508
       IP: [<ffffffff81314790>] blk_get_backing_dev_info+0x10/0x20
       PGD 9e62067 PUD 9ee8067 PMD 0
       Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
       Modules linked in:
       CPU: 1 PID: 2422 Comm: sync Not tainted 4.5.0-rc7+ #400
       Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
       task: ffff880009f4d700 ti: ffff880009f5c000 task.ti: ffff880009f5c000
       RIP: 0010:[<ffffffff81314790>]  [<ffffffff81314790>] blk_get_backing_dev_info+0x10/0x20
       RSP: 0018:ffff880009f5fe68  EFLAGS: 00010246
       RAX: 0000000000000000 RBX: ffff88000ec17a38 RCX: ffffffff81a4e940
       RDX: 7fffffffffffffff RSI: 0000000000000000 RDI: ffff88000ec176c0
       RBP: ffff880009f5fe68 R08: 0000000000000000 R09: 0000000000000000
       R10: 0000000000000001 R11: 0000000000000000 R12: ffff88000ec17860
       R13: ffffffff811b25c0 R14: ffff88000ec178e0 R15: ffff88000ec17a38
       FS:  00007faee505d700(0000) GS:ffff88000fb00000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
       CR2: 0000000000000508 CR3: 0000000009e8a000 CR4: 00000000000006e0
       Stack:
        ffff880009f5feb8 ffffffff8112e7f5 0000000000000000 7fffffffffffffff
        0000000000000000 0000000000000000 7fffffffffffffff 0000000000000001
        ffff88000ec178e0 ffff88000ec17860 ffff880009f5fec8 ffffffff8112e81f
       Call Trace:
        [<ffffffff8112e7f5>] __filemap_fdatawrite_range+0x85/0x90
        [<ffffffff8112e81f>] filemap_fdatawrite+0x1f/0x30
        [<ffffffff811b25d6>] fdatawrite_one_bdev+0x16/0x20
        [<ffffffff811bc402>] iterate_bdevs+0xf2/0x130
        [<ffffffff811b2763>] sys_sync+0x63/0x90
        [<ffffffff815d4272>] entry_SYSCALL_64_fastpath+0x12/0x76
       Code: 0f 1f 44 00 00 48 8b 87 f0 00 00 00 55 48 89 e5 <48> 8b 80 08 05 00 00 5d
       RIP  [<ffffffff81314790>] blk_get_backing_dev_info+0x10/0x20
        RSP <ffff880009f5fe68>
       CR2: 0000000000000508
       ---[ end trace 2487336ceb3de62d ]---
      
      The crash is easily reproducible by running the following command, if an
      msleep(100) is inserted before the call to func() in iterate_devs():
      
       while :; do head -c1 /dev/nullb0; done > /dev/null & while :; do sync; done
      
      Fix it by holding the bd_mutex across the func() call and only calling
      func() if the bdev is opened.
      
      Cc: stable@vger.kernel.org
      Fixes: 5c0d6b60 ("vfs: Create function for iterating over block devices")
      Reported-and-tested-by: default avatarWei Fang <fangwei1@huawei.com>
      Signed-off-by: default avatarRabin Vincent <rabinv@axis.com>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      d0cfefba
    • Robbie Ko's avatar
      Btrfs: fix tree search logic when replaying directory entry deletes · 5ccc9afa
      Robbie Ko authored
      [ Upstream commit 2a7bf53f ]
      
      If a log tree has a layout like the following:
      
      leaf N:
              ...
              item 240 key (282 DIR_LOG_ITEM 0) itemoff 8189 itemsize 8
                      dir log end 1275809046
      leaf N + 1:
              item 0 key (282 DIR_LOG_ITEM 3936149215) itemoff 16275 itemsize 8
                      dir log end 18446744073709551615
              ...
      
      When we pass the value 1275809046 + 1 as the parameter start_ret to the
      function tree-log.c:find_dir_range() (done by replay_dir_deletes()), we
      end up with path->slots[0] having the value 239 (points to the last item
      of leaf N, item 240). Because the dir log item in that position has an
      offset value smaller than *start_ret (1275809046 + 1) we need to move on
      to the next leaf, however the logic for that is wrong since it compares
      the current slot to the number of items in the leaf, which is smaller
      and therefore we don't lookup for the next leaf but instead we set the
      slot to point to an item that does not exist, at slot 240, and we later
      operate on that slot which has unexpected content or in the worst case
      can result in an invalid memory access (accessing beyond the last page
      of leaf N's extent buffer).
      
      So fix the logic that checks when we need to lookup at the next leaf
      by first incrementing the slot and only after to check if that slot
      is beyond the last item of the current leaf.
      Signed-off-by: default avatarRobbie Ko <robbieko@synology.com>
      Reviewed-by: default avatarFilipe Manana <fdmanana@suse.com>
      Fixes: e02119d5 (Btrfs: Add a write ahead tree log to optimize synchronous operations)
      Cc: stable@vger.kernel.org  # 2.6.29+
      Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
      [Modified changelog for clarity and correctness]
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      5ccc9afa