Skip to content
Snippets Groups Projects
  1. Oct 05, 2019
    • Ben Hutchings's avatar
      Linux 3.16.75 · c508a924
      Ben Hutchings authored
      v3.16.75
      c508a924
    • Eric Biggers's avatar
      crypto: user - prevent operating on larval algorithms · 4d8a6e79
      Eric Biggers authored
      commit 21d4120e upstream.
      
      Michal Suchanek reported [1] that running the pcrypt_aead01 test from
      LTP [2] in a loop and holding Ctrl-C causes a NULL dereference of
      alg->cra_users.next in crypto_remove_spawns(), via crypto_del_alg().
      The test repeatedly uses CRYPTO_MSG_NEWALG and CRYPTO_MSG_DELALG.
      
      The crash occurs when the instance that CRYPTO_MSG_DELALG is trying to
      unregister isn't a real registered algorithm, but rather is a "test
      larval", which is a special "algorithm" added to the algorithms list
      while the real algorithm is still being tested.  Larvals don't have
      initialized cra_users, so that causes the crash.  Normally pcrypt_aead01
      doesn't trigger this because CRYPTO_MSG_NEWALG waits for the algorithm
      to be tested; however, CRYPTO_MSG_NEWALG returns early when interrupted.
      
      Everything else in the "crypto user configuration" API has this same bug
      too, i.e. it inappropriately allows operating on larval algorithms
      (though it doesn't look like the other cases can cause a crash).
      
      Fix this by making crypto_alg_match() exclude larval algorithms.
      
      [1] https://lkml.kernel.org/r/20190625071624.27039-1-msuchanek@suse.de
      [2] https://github.com/linux-test-project/ltp/blob/20190517/testcases/kernel/crypto/pcrypt_aead01.c
      
      
      
      Reported-by: default avatarMichal Suchanek <msuchanek@suse.de>
      Fixes: a38f7907 ("crypto: Add userspace configuration API")
      Cc: Steffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      [bwh: Backported to 3.16: adjust filename]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      4d8a6e79
    • Herbert Xu's avatar
      lib/mpi: Fix karactx leak in mpi_powm · 6880e073
      Herbert Xu authored
      
      commit c8ea9fce upstream.
      
      Sometimes mpi_powm will leak karactx because a memory allocation
      failure causes a bail-out that skips the freeing of karactx.  This
      patch moves the freeing of karactx to the end of the function like
      everything else so that it can't be skipped.
      
      Reported-by: default avatar <syzbot+f7baccc38dcc1e094e77@syzkaller.appspotmail.com>
      Fixes: cdec9cb5 ("crypto: GnuPG based MPI lib - source files...")
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Reviewed-by: default avatarEric Biggers <ebiggers@kernel.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      6880e073
    • Roman Bolshakov's avatar
      scsi: target/iblock: Fix overrun in WRITE SAME emulation · b1725163
      Roman Bolshakov authored
      
      commit 5676234f upstream.
      
      WRITE SAME corrupts data on the block device behind iblock if the command
      is emulated. The emulation code issues (M - 1) * N times more bios than
      requested, where M is the number of 512 blocks per real block size and N is
      the NUMBER OF LOGICAL BLOCKS specified in WRITE SAME command. So, for a
      device with 4k blocks, 7 * N more LBAs gets written after the requested
      range.
      
      The issue happens because the number of 512 byte sectors to be written is
      decreased one by one while the real bios are typically from 1 to 8 512 byte
      sectors per bio.
      
      Fixes: c66ac9db ("[SCSI] target: Add LIO target core v4.0.0-rc6")
      Signed-off-by: default avatarRoman Bolshakov <r.bolshakov@yadro.com>
      Reviewed-by: default avatarBart Van Assche <bvanassche@acm.org>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      [bwh: Backported to 3.16: use IBLOCK_LBA_SHIFT instead of SECTOR_SHIFT]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      b1725163
    • Eiichi Tsukata's avatar
      tracing/snapshot: Resize spare buffer if size changed · 0cc44ac6
      Eiichi Tsukata authored
      commit 46cc0b44 upstream.
      
      Current snapshot implementation swaps two ring_buffers even though their
      sizes are different from each other, that can cause an inconsistency
      between the contents of buffer_size_kb file and the current buffer size.
      
      For example:
      
        # cat buffer_size_kb
        7 (expanded: 1408)
        # echo 1 > events/enable
        # grep bytes per_cpu/cpu0/stats
        bytes: 1441020
        # echo 1 > snapshot             // current:1408, spare:1408
        # echo 123 > buffer_size_kb     // current:123,  spare:1408
        # echo 1 > snapshot             // current:1408, spare:123
        # grep bytes per_cpu/cpu0/stats
        bytes: 1443700
        # cat buffer_size_kb
        123                             // != current:1408
      
      And also, a similar per-cpu case hits the following WARNING:
      
      Reproducer:
      
        # echo 1 > per_cpu/cpu0/snapshot
        # echo 123 > buffer_size_kb
        # echo 1 > per_cpu/cpu0/snapshot
      
      WARNING:
      
        WARNING: CPU: 0 PID: 1946 at kernel/trace/trace.c:1607 update_max_tr_single.part.0+0x2b8/0x380
        Modules linked in:
        CPU: 0 PID: 1946 Comm: bash Not tainted 5.2.0-rc6 #20
        Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-2.fc30 04/01/2014
        RIP: 0010:update_max_tr_single.part.0+0x2b8/0x380
        Code: ff e8 dc da f9 ff 0f 0b e9 88 fe ff ff e8 d0 da f9 ff 44 89 ee bf f5 ff ff ff e8 33 dc f9 ff 41 83 fd f5 74 96 e8 b8 da f9 ff <0f> 0b eb 8d e8 af da f9 ff 0f 0b e9 bf fd ff ff e8 a3 da f9 ff 48
        RSP: 0018:ffff888063e4fca0 EFLAGS: 00010093
        RAX: ffff888066214380 RBX: ffffffff99850fe0 RCX: ffffffff964298a8
        RDX: 0000000000000000 RSI: 00000000fffffff5 RDI: 0000000000000005
        RBP: 1ffff1100c7c9f96 R08: ffff888066214380 R09: ffffed100c7c9f9b
        R10: ffffed100c7c9f9a R11: 0000000000000003 R12: 0000000000000000
        R13: 00000000ffffffea R14: ffff888066214380 R15: ffffffff99851060
        FS:  00007f9f8173c700(0000) GS:ffff88806d000000(0000) knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
        CR2: 0000000000714dc0 CR3: 0000000066fa6000 CR4: 00000000000006f0
        Call Trace:
         ? trace_array_printk_buf+0x140/0x140
         ? __mutex_lock_slowpath+0x10/0x10
         tracing_snapshot_write+0x4c8/0x7f0
         ? trace_printk_init_buffers+0x60/0x60
         ? selinux_file_permission+0x3b/0x540
         ? tracer_preempt_off+0x38/0x506
         ? trace_printk_init_buffers+0x60/0x60
         __vfs_write+0x81/0x100
         vfs_write+0x1e1/0x560
         ksys_write+0x126/0x250
         ? __ia32_sys_read+0xb0/0xb0
         ? do_syscall_64+0x1f/0x390
         do_syscall_64+0xc1/0x390
         entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      This patch adds resize_buffer_duplicate_size() to check if there is a
      difference between current/spare buffer sizes and resize a spare buffer
      if necessary.
      
      Link: http://lkml.kernel.org/r/20190625012910.13109-1-devel@etsukata.com
      
      
      
      Fixes: ad909e21 ("tracing: Add internal tracing_snapshot() functions")
      Signed-off-by: default avatarEiichi Tsukata <devel@etsukata.com>
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      0cc44ac6
    • Colin Ian King's avatar
      ALSA: seq: fix incorrect order of dest_client/dest_ports arguments · 78b60944
      Colin Ian King authored
      
      commit c3ea60c2 upstream.
      
      There are two occurrances of a call to snd_seq_oss_fill_addr where
      the dest_client and dest_port arguments are in the wrong order. Fix
      this by swapping them around.
      
      Addresses-Coverity: ("Arguments in wrong order")
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      78b60944
    • Xin Long's avatar
      sctp: change to hold sk after auth shkey is created successfully · b4b1f8ed
      Xin Long authored
      
      commit 25bff6d5 upstream.
      
      Now in sctp_endpoint_init(), it holds the sk then creates auth
      shkey. But when the creation fails, it doesn't release the sk,
      which causes a sk defcnf leak,
      
      Here to fix it by only holding the sk when auth shkey is created
      successfully.
      
      Fixes: a29a5bd4 ("[SCTP]: Implement SCTP-AUTH initializations.")
      Reported-by: default avatar <syzbot+afabda3890cc2f765041@syzkaller.appspotmail.com>
      Reported-by: default avatar <syzbot+276ca1c77a19977c0130@syzkaller.appspotmail.com>
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Acked-by: default avatarNeil Horman <nhorman@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      b4b1f8ed
    • YueHaibing's avatar
      bonding: Add vlan tx offload to hw_enc_features · 2489c9a5
      YueHaibing authored
      
      commit d595b03d upstream.
      
      As commit 30d8177e ("bonding: Always enable vlan tx offload")
      said, we should always enable bonding's vlan tx offload, pass the
      vlan packets to the slave devices with vlan tci, let them to handle
      vlan implementation.
      
      Now if encapsulation protocols like VXLAN is used, skb->encapsulation
      may be set, then the packet is passed to vlan device which based on
      bonding device. However in netif_skb_features(), the check of
      hw_enc_features:
      
      	 if (skb->encapsulation)
                       features &= dev->hw_enc_features;
      
      clears NETIF_F_HW_VLAN_CTAG_TX/NETIF_F_HW_VLAN_STAG_TX. This results
      in same issue in commit 30d8177e like this:
      
      vlan_dev_hard_start_xmit
        -->dev_queue_xmit
          -->validate_xmit_skb
            -->netif_skb_features //NETIF_F_HW_VLAN_CTAG_TX is cleared
            -->validate_xmit_vlan
              -->__vlan_hwaccel_push_inside //skb->tci is cleared
      ...
       --> bond_start_xmit
         --> bond_xmit_hash //BOND_XMIT_POLICY_ENCAP34
           --> __skb_flow_dissect // nhoff point to IP header
              -->  case htons(ETH_P_8021Q)
                   // skb_vlan_tag_present is false, so
                   vlan = __skb_header_pointer(skb, nhoff, sizeof(_vlan),
                   //vlan point to ip header wrongly
      
      Fixes: b2a103e6 ("bonding: convert to ndo_fix_features")
      Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
      Acked-by: default avatarJay Vosburgh <jay.vosburgh@canonical.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      2489c9a5
    • YueHaibing's avatar
      bonding: Always enable vlan tx offload · 8dc57ea2
      YueHaibing authored
      
      commit 30d8177e upstream.
      
      We build vlan on top of bonding interface, which vlan offload
      is off, bond mode is 802.3ad (LACP) and xmit_hash_policy is
      BOND_XMIT_POLICY_ENCAP34.
      
      Because vlan tx offload is off, vlan tci is cleared and skb push
      the vlan header in validate_xmit_vlan() while sending from vlan
      devices. Then in bond_xmit_hash, __skb_flow_dissect() fails to
      get information from protocol headers encapsulated within vlan,
      because 'nhoff' is points to IP header, so bond hashing is based
      on layer 2 info, which fails to distribute packets across slaves.
      
      This patch always enable bonding's vlan tx offload, pass the vlan
      packets to the slave devices with vlan tci, let them to handle
      vlan implementation.
      
      Fixes: 278339a4 ("bonding: propogate vlan_features to bonding master")
      Suggested-by: default avatarJiri Pirko <jiri@resnulli.us>
      Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
      Acked-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      8dc57ea2
    • Geert Uytterhoeven's avatar
      cpu/speculation: Warn on unsupported mitigations= parameter · 8b8e9088
      Geert Uytterhoeven authored
      
      commit 1bf72720 upstream.
      
      Currently, if the user specifies an unsupported mitigation strategy on the
      kernel command line, it will be ignored silently.  The code will fall back
      to the default strategy, possibly leaving the system more vulnerable than
      expected.
      
      This may happen due to e.g. a simple typo, or, for a stable kernel release,
      because not all mitigation strategies have been backported.
      
      Inform the user by printing a message.
      
      Fixes: 98af8452 ("cpu/speculation: Add 'mitigations=' cmdline option")
      Signed-off-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Acked-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Link: https://lkml.kernel.org/r/20190516070935.22546-1-geert@linux-m68k.org
      
      
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      8b8e9088
    • Alejandro Jimenez's avatar
      x86/speculation: Allow guests to use SSBD even if host does not · 8d9d7168
      Alejandro Jimenez authored
      
      commit c1f7fec1 upstream.
      
      The bits set in x86_spec_ctrl_mask are used to calculate the guest's value
      of SPEC_CTRL that is written to the MSR before VMENTRY, and control which
      mitigations the guest can enable.  In the case of SSBD, unless the host has
      enabled SSBD always on mode (by passing "spec_store_bypass_disable=on" in
      the kernel parameters), the SSBD bit is not set in the mask and the guest
      can not properly enable the SSBD always on mitigation mode.
      
      This has been confirmed by running the SSBD PoC on a guest using the SSBD
      always on mitigation mode (booted with kernel parameter
      "spec_store_bypass_disable=on"), and verifying that the guest is vulnerable
      unless the host is also using SSBD always on mode. In addition, the guest
      OS incorrectly reports the SSB vulnerability as mitigated.
      
      Always set the SSBD bit in x86_spec_ctrl_mask when the host CPU supports
      it, allowing the guest to use SSBD whether or not the host has chosen to
      enable the mitigation in any of its modes.
      
      Fixes: be6fcb54 ("x86/bugs: Rework spec_ctrl base and mask logic")
      Signed-off-by: default avatarAlejandro Jimenez <alejandro.j.jimenez@oracle.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: default avatarLiam Merwick <liam.merwick@oracle.com>
      Reviewed-by: default avatarMark Kanda <mark.kanda@oracle.com>
      Reviewed-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Cc: bp@alien8.de
      Cc: rkrcmar@redhat.com
      Cc: kvm@vger.kernel.org
      Link: https://lkml.kernel.org/r/1560187210-11054-1-git-send-email-alejandro.j.jimenez@oracle.com
      
      
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      8d9d7168
    • Dmitry Korotin's avatar
      MIPS: Add missing EHB in mtc0 -> mfc0 sequence. · 7ea4413f
      Dmitry Korotin authored
      
      commit 0b24cae4 upstream.
      
      Add a missing EHB (Execution Hazard Barrier) in mtc0 -> mfc0 sequence.
      Without this execution hazard barrier it's possible for the value read
      back from the KScratch register to be the value from before the mtc0.
      
      Reproducible on P5600 & P6600.
      
      The hazard is documented in the MIPS Architecture Reference Manual Vol.
      III: MIPS32/microMIPS32 Privileged Resource Architecture (MD00088), rev
      6.03 table 8.1 which includes:
      
         Producer | Consumer | Hazard
        ----------|----------|----------------------------
         mtc0     | mfc0     | any coprocessor 0 register
      
      Signed-off-by: default avatarDmitry Korotin <dkorotin@wavecomp.com>
      [paul.burton@mips.com:
        - Commit message tweaks.
        - Add Fixes tags.
        - Mark for stable back to v3.15 where P5600 support was introduced.]
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Fixes: 3d8bfdd0 ("MIPS: Use C0_KScratch (if present) to hold PGD pointer.")
      Fixes: 829dcc0a ("MIPS: Add MIPS P5600 probe support")
      Cc: linux-mips@vger.kernel.org
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      7ea4413f
    • Ravi Bangoria's avatar
      perf/ioctl: Add check for the sample_period value · 0d17e80f
      Ravi Bangoria authored
      
      commit 913a90bc upstream.
      
      perf_event_open() limits the sample_period to 63 bits. See:
      
        0819b2e3 ("perf: Limit perf_event_attr::sample_period to 63 bits")
      
      Make ioctl() consistent with it.
      
      Also on PowerPC, negative sample_period could cause a recursive
      PMIs leading to a hang (reported when running perf-fuzzer).
      
      Signed-off-by: default avatarRavi Bangoria <ravi.bangoria@linux.ibm.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Cc: acme@kernel.org
      Cc: linuxppc-dev@lists.ozlabs.org
      Cc: maddy@linux.vnet.ibm.com
      Cc: mpe@ellerman.id.au
      Fixes: 0819b2e3 ("perf: Limit perf_event_attr::sample_period to 63 bits")
      Link: https://lkml.kernel.org/r/20190604042953.914-1-ravi.bangoria@linux.ibm.com
      
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      0d17e80f
    • Petr Oros's avatar
      be2net: fix link failure after ethtool offline test · 32def9a8
      Petr Oros authored
      
      commit 2e5db6eb upstream.
      
      Certain cards in conjunction with certain switches need a little more
      time for link setup that results in ethtool link test failure after
      offline test. Patch adds a loop that waits for a link setup finish.
      
      Changes in v2:
      - added fixes header
      
      Fixes: 4276e47e ("be2net: Add link test to list of ethtool self tests.")
      Signed-off-by: default avatarPetr Oros <poros@redhat.com>
      Reviewed-by: default avatarIvan Vecera <ivecera@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      32def9a8
    • Colin Ian King's avatar
      x86/apic: Fix integer overflow on 10 bit left shift of cpu_khz · 04d31600
      Colin Ian King authored
      
      commit ea136a11 upstream.
      
      The left shift of unsigned int cpu_khz will overflow for large values of
      cpu_khz, so cast it to a long long before shifting it to avoid overvlow.
      For example, this can happen when cpu_khz is 4194305, i.e. ~4.2 GHz.
      
      Addresses-Coverity: ("Unintentional integer overflow")
      Fixes: 8c3ba8d0 ("x86, apic: ack all pending irqs when crashed/on kexec")
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: "H . Peter Anvin" <hpa@zytor.com>
      Cc: kernel-janitors@vger.kernel.org
      Link: https://lkml.kernel.org/r/20190619181446.13635-1-colin.king@canonical.com
      
      
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      04d31600
    • Jan Kara's avatar
      scsi: vmw_pscsi: Fix use-after-free in pvscsi_queue_lck() · a7b6e4f0
      Jan Kara authored
      
      commit 240b4cc8 upstream.
      
      Once we unlock adapter->hw_lock in pvscsi_queue_lck() nothing prevents just
      queued scsi_cmnd from completing and freeing the request. Thus cmd->cmnd[0]
      dereference can dereference already freed request leading to kernel crashes
      or other issues (which one of our customers observed). Store cmd->cmnd[0]
      in a local variable before unlocking adapter->hw_lock to fix the issue.
      
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Reviewed-by: default avatarEwan D. Milne <emilne@redhat.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      a7b6e4f0
    • Julian Wiedmann's avatar
      net/af_iucv: always register net_device notifier · b3975e64
      Julian Wiedmann authored
      
      commit 06996c1d upstream.
      
      Even when running as VM guest (ie pr_iucv != NULL), af_iucv can still
      open HiperTransport-based connections. For robust operation these
      connections require the af_iucv_netdev_notifier, so register it
      unconditionally.
      
      Also handle any error that register_netdevice_notifier() returns.
      
      Fixes: 9fbd87d4 ("af_iucv: handle netdev events")
      Signed-off-by: default avatarJulian Wiedmann <jwi@linux.ibm.com>
      Reviewed-by: default avatarUrsula Braun <ubraun@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      b3975e64
    • Julian Wiedmann's avatar
      net/af_iucv: remove GFP_DMA restriction for HiperTransport · 58e4e6bd
      Julian Wiedmann authored
      
      commit fdbf6326 upstream.
      
      af_iucv sockets over z/VM IUCV require that their skbs are allocated
      in DMA memory. This restriction doesn't apply to connections over
      HiperSockets. So only set this limit for z/VM IUCV sockets, thereby
      increasing the likelihood that the large (and linear!) allocations for
      HiperTransport messages succeed.
      
      Fixes: 3881ac44 ("af_iucv: add HiperSockets transport")
      Signed-off-by: default avatarJulian Wiedmann <jwi@linux.ibm.com>
      Reviewed-by: default avatarUrsula Braun <ubraun@linux.ibm.com>
      Reviewed-by: default avatarHendrik Brueckner <brueckner@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      58e4e6bd
    • Stanley Chu's avatar
      scsi: ufs: Avoid runtime suspend possibly being blocked forever · b71e15e2
      Stanley Chu authored
      
      commit 24e2e7a1 upstream.
      
      UFS runtime suspend can be triggered after pm_runtime_enable() is invoked
      in ufshcd_pltfrm_init(). However if the first runtime suspend is triggered
      before binding ufs_hba structure to ufs device structure via
      platform_set_drvdata(), then UFS runtime suspend will be no longer
      triggered in the future because its dev->power.runtime_error was set in the
      first triggering and does not have any chance to be cleared.
      
      To be more clear, dev->power.runtime_error is set if hba is NULL in
      ufshcd_runtime_suspend() which returns -EINVAL to rpm_callback() where
      dev->power.runtime_error is set as -EINVAL. In this case, any future
      rpm_suspend() for UFS device fails because rpm_check_suspend_allowed()
      fails due to non-zero
      dev->power.runtime_error.
      
      To resolve this issue, make sure the first UFS runtime suspend get valid
      "hba" in ufshcd_runtime_suspend(): Enable UFS runtime PM only after hba is
      successfully bound to UFS device structure.
      
      Fixes: 62694735 ([SCSI] ufs: Add runtime PM support for UFS host controller driver)
      Signed-off-by: default avatarStanley Chu <stanley.chu@mediatek.com>
      Reviewed-by: default avatarAvri Altman <avri.altman@wdc.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      [bwh: Backported to 3.16:
       - ufshcd_pltrfm_probe() doesn't allocate or free the host structure
       - Adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      b71e15e2
    • Jakub Kicinski's avatar
      net: netem: fix backlog accounting for corrupted GSO frames · 61763432
      Jakub Kicinski authored
      
      commit 177b8007 upstream.
      
      When GSO frame has to be corrupted netem uses skb_gso_segment()
      to produce the list of frames, and re-enqueues the segments one
      by one.  The backlog length has to be adjusted to account for
      new frames.
      
      The current calculation is incorrect, leading to wrong backlog
      lengths in the parent qdisc (both bytes and packets), and
      incorrect packet backlog count in netem itself.
      
      Parent backlog goes negative, netem's packet backlog counts
      all non-first segments twice (thus remaining non-zero even
      after qdisc is emptied).
      
      Move the variables used to count the adjustment into local
      scope to make 100% sure they aren't used at any stage in
      backports.
      
      Fixes: 6071bd1a ("netem: Segment GSO packets on enqueue")
      Signed-off-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Reviewed-by: default avatarDirk van der Merwe <dirk.vandermerwe@netronome.com>
      Acked-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      61763432
    • Jann Horn's avatar
      apparmor: enforce nullbyte at end of tag string · e17ce419
      Jann Horn authored
      
      commit 8404d7a6 upstream.
      
      A packed AppArmor policy contains null-terminated tag strings that are read
      by unpack_nameX(). However, unpack_nameX() uses string functions on them
      without ensuring that they are actually null-terminated, potentially
      leading to out-of-bounds accesses.
      
      Make sure that the tag string is null-terminated before passing it to
      strcmp().
      
      Fixes: 736ec752 ("AppArmor: policy routines for loading and unpacking policy")
      Signed-off-by: default avatarJann Horn <jannh@google.com>
      Signed-off-by: default avatarJohn Johansen <john.johansen@canonical.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      e17ce419
    • Steve French's avatar
      SMB3: retry on STATUS_INSUFFICIENT_RESOURCES instead of failing write · 1acd055f
      Steve French authored
      
      commit 8d526d62 upstream.
      
      Some servers such as Windows 10 will return STATUS_INSUFFICIENT_RESOURCES
      as the number of simultaneous SMB3 requests grows (even though the client
      has sufficient credits).  Return EAGAIN on STATUS_INSUFFICIENT_RESOURCES
      so that we can retry writes which fail with this status code.
      
      This (for example) fixes large file copies to Windows 10 on fast networks.
      
      Signed-off-by: default avatarSteve French <stfrench@microsoft.com>
      Reviewed-by: default avatarRonnie Sahlberg <lsahlber@redhat.com>
      Reviewed-by: default avatarPavel Shilovsky <pshilov@microsoft.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      1acd055f
    • Peter Zijlstra's avatar
      perf/core: Fix perf_sample_regs_user() mm check · aaeeb3e6
      Peter Zijlstra authored
      
      commit 085ebfe9 upstream.
      
      perf_sample_regs_user() uses 'current->mm' to test for the presence of
      userspace, but this is insufficient, consider use_mm().
      
      A better test is: '!(current->flags & PF_KTHREAD)', exec() clears
      PF_KTHREAD after it sets the new ->mm but before it drops to userspace
      for the first time.
      
      Possibly obsoletes: bf05fc25 ("powerpc/perf: Fix oops when kthread execs user process")
      
      Reported-by: default avatarRavi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
      Reported-by: default avatarYoung Xiao <92siuyang@gmail.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Fixes: 4018994f ("perf: Add ability to attach user level registers dump to sample")
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      aaeeb3e6
    • Eric Dumazet's avatar
      neigh: fix use-after-free read in pneigh_get_next · 1bad37d8
      Eric Dumazet authored
      
      commit f3e92cb8 upstream.
      
      Nine years ago, I added RCU handling to neighbours, not pneighbours.
      (pneigh are not commonly used)
      
      Unfortunately I missed that /proc dump operations would use a
      common entry and exit point : neigh_seq_start() and neigh_seq_stop()
      
      We need to read_lock(tbl->lock) or risk use-after-free while
      iterating the pneigh structures.
      
      We might later convert pneigh to RCU and revert this patch.
      
      sysbot reported :
      
      BUG: KASAN: use-after-free in pneigh_get_next.isra.0+0x24b/0x280 net/core/neighbour.c:3158
      Read of size 8 at addr ffff888097f2a700 by task syz-executor.0/9825
      
      CPU: 1 PID: 9825 Comm: syz-executor.0 Not tainted 5.2.0-rc4+ #32
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0x172/0x1f0 lib/dump_stack.c:113
       print_address_description.cold+0x7c/0x20d mm/kasan/report.c:188
       __kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
       kasan_report+0x12/0x20 mm/kasan/common.c:614
       __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:132
       pneigh_get_next.isra.0+0x24b/0x280 net/core/neighbour.c:3158
       neigh_seq_next+0xdb/0x210 net/core/neighbour.c:3240
       seq_read+0x9cf/0x1110 fs/seq_file.c:258
       proc_reg_read+0x1fc/0x2c0 fs/proc/inode.c:221
       do_loop_readv_writev fs/read_write.c:714 [inline]
       do_loop_readv_writev fs/read_write.c:701 [inline]
       do_iter_read+0x4a4/0x660 fs/read_write.c:935
       vfs_readv+0xf0/0x160 fs/read_write.c:997
       kernel_readv fs/splice.c:359 [inline]
       default_file_splice_read+0x475/0x890 fs/splice.c:414
       do_splice_to+0x127/0x180 fs/splice.c:877
       splice_direct_to_actor+0x2d2/0x970 fs/splice.c:954
       do_splice_direct+0x1da/0x2a0 fs/splice.c:1063
       do_sendfile+0x597/0xd00 fs/read_write.c:1464
       __do_sys_sendfile64 fs/read_write.c:1525 [inline]
       __se_sys_sendfile64 fs/read_write.c:1511 [inline]
       __x64_sys_sendfile64+0x1dd/0x220 fs/read_write.c:1511
       do_syscall_64+0xfd/0x680 arch/x86/entry/common.c:301
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x4592c9
      Code: fd b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 cb b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007f4aab51dc78 EFLAGS: 00000246 ORIG_RAX: 0000000000000028
      RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00000000004592c9
      RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000005
      RBP: 000000000075bf20 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000080000000 R11: 0000000000000246 R12: 00007f4aab51e6d4
      R13: 00000000004c689d R14: 00000000004db828 R15: 00000000ffffffff
      
      Allocated by task 9827:
       save_stack+0x23/0x90 mm/kasan/common.c:71
       set_track mm/kasan/common.c:79 [inline]
       __kasan_kmalloc mm/kasan/common.c:489 [inline]
       __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:462
       kasan_kmalloc+0x9/0x10 mm/kasan/common.c:503
       __do_kmalloc mm/slab.c:3660 [inline]
       __kmalloc+0x15c/0x740 mm/slab.c:3669
       kmalloc include/linux/slab.h:552 [inline]
       pneigh_lookup+0x19c/0x4a0 net/core/neighbour.c:731
       arp_req_set_public net/ipv4/arp.c:1010 [inline]
       arp_req_set+0x613/0x720 net/ipv4/arp.c:1026
       arp_ioctl+0x652/0x7f0 net/ipv4/arp.c:1226
       inet_ioctl+0x2a0/0x340 net/ipv4/af_inet.c:926
       sock_do_ioctl+0xd8/0x2f0 net/socket.c:1043
       sock_ioctl+0x3ed/0x780 net/socket.c:1194
       vfs_ioctl fs/ioctl.c:46 [inline]
       file_ioctl fs/ioctl.c:509 [inline]
       do_vfs_ioctl+0xd5f/0x1380 fs/ioctl.c:696
       ksys_ioctl+0xab/0xd0 fs/ioctl.c:713
       __do_sys_ioctl fs/ioctl.c:720 [inline]
       __se_sys_ioctl fs/ioctl.c:718 [inline]
       __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718
       do_syscall_64+0xfd/0x680 arch/x86/entry/common.c:301
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Freed by task 9824:
       save_stack+0x23/0x90 mm/kasan/common.c:71
       set_track mm/kasan/common.c:79 [inline]
       __kasan_slab_free+0x102/0x150 mm/kasan/common.c:451
       kasan_slab_free+0xe/0x10 mm/kasan/common.c:459
       __cache_free mm/slab.c:3432 [inline]
       kfree+0xcf/0x220 mm/slab.c:3755
       pneigh_ifdown_and_unlock net/core/neighbour.c:812 [inline]
       __neigh_ifdown+0x236/0x2f0 net/core/neighbour.c:356
       neigh_ifdown+0x20/0x30 net/core/neighbour.c:372
       arp_ifdown+0x1d/0x21 net/ipv4/arp.c:1274
       inetdev_destroy net/ipv4/devinet.c:319 [inline]
       inetdev_event+0xa14/0x11f0 net/ipv4/devinet.c:1544
       notifier_call_chain+0xc2/0x230 kernel/notifier.c:95
       __raw_notifier_call_chain kernel/notifier.c:396 [inline]
       raw_notifier_call_chain+0x2e/0x40 kernel/notifier.c:403
       call_netdevice_notifiers_info+0x3f/0x90 net/core/dev.c:1749
       call_netdevice_notifiers_extack net/core/dev.c:1761 [inline]
       call_netdevice_notifiers net/core/dev.c:1775 [inline]
       rollback_registered_many+0x9b9/0xfc0 net/core/dev.c:8178
       rollback_registered+0x109/0x1d0 net/core/dev.c:8220
       unregister_netdevice_queue net/core/dev.c:9267 [inline]
       unregister_netdevice_queue+0x1ee/0x2c0 net/core/dev.c:9260
       unregister_netdevice include/linux/netdevice.h:2631 [inline]
       __tun_detach+0xd8a/0x1040 drivers/net/tun.c:724
       tun_detach drivers/net/tun.c:741 [inline]
       tun_chr_close+0xe0/0x180 drivers/net/tun.c:3451
       __fput+0x2ff/0x890 fs/file_table.c:280
       ____fput+0x16/0x20 fs/file_table.c:313
       task_work_run+0x145/0x1c0 kernel/task_work.c:113
       tracehook_notify_resume include/linux/tracehook.h:185 [inline]
       exit_to_usermode_loop+0x273/0x2c0 arch/x86/entry/common.c:168
       prepare_exit_to_usermode arch/x86/entry/common.c:199 [inline]
       syscall_return_slowpath arch/x86/entry/common.c:279 [inline]
       do_syscall_64+0x58e/0x680 arch/x86/entry/common.c:304
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      The buggy address belongs to the object at ffff888097f2a700
       which belongs to the cache kmalloc-64 of size 64
      The buggy address is located 0 bytes inside of
       64-byte region [ffff888097f2a700, ffff888097f2a740)
      The buggy address belongs to the page:
      page:ffffea00025fca80 refcount:1 mapcount:0 mapping:ffff8880aa400340 index:0x0
      flags: 0x1fffc0000000200(slab)
      raw: 01fffc0000000200 ffffea000250d548 ffffea00025726c8 ffff8880aa400340
      raw: 0000000000000000 ffff888097f2a000 0000000100000020 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
       ffff888097f2a600: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
       ffff888097f2a680: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
      >ffff888097f2a700: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
                         ^
       ffff888097f2a780: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
       ffff888097f2a800: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
      
      Fixes: 767e97e1 ("neigh: RCU conversion of struct neighbour")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      1bad37d8
    • Ivan Vecera's avatar
      be2net: Fix number of Rx queues used for flow hashing · 1d279591
      Ivan Vecera authored
      
      commit 718f4a25 upstream.
      
      Number of Rx queues used for flow hashing returned by the driver is
      incorrect and this bug prevents user to use the last Rx queue in
      indirection table.
      
      Let's say we have a NIC with 6 combined queues:
      
      [root@sm-03 ~]# ethtool -l enp4s0f0
      Channel parameters for enp4s0f0:
      Pre-set maximums:
      RX:             5
      TX:             5
      Other:          0
      Combined:       6
      Current hardware settings:
      RX:             0
      TX:             0
      Other:          0
      Combined:       6
      
      Default indirection table maps all (6) queues equally but the driver
      reports only 5 rings available.
      
      [root@sm-03 ~]# ethtool -x enp4s0f0
      RX flow hash indirection table for enp4s0f0 with 5 RX ring(s):
          0:      0     1     2     3     4     5     0     1
          8:      2     3     4     5     0     1     2     3
         16:      4     5     0     1     2     3     4     5
         24:      0     1     2     3     4     5     0     1
      ...
      
      Now change indirection table somehow:
      
      [root@sm-03 ~]# ethtool -X enp4s0f0 weight 1 1
      [root@sm-03 ~]# ethtool -x enp4s0f0
      RX flow hash indirection table for enp4s0f0 with 6 RX ring(s):
          0:      0     0     0     0     0     0     0     0
      ...
         64:      1     1     1     1     1     1     1     1
      ...
      
      Now it is not possible to change mapping back to equal (default) state:
      
      [root@sm-03 ~]# ethtool -X enp4s0f0 equal 6
      Cannot set RX flow hash configuration: Invalid argument
      
      Fixes: 594ad54a ("be2net: Add support for setting and getting rx flow hash options")
      Reported-by: default avatarTianhao <tizhao@redhat.com>
      Signed-off-by: default avatarIvan Vecera <ivecera@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      1d279591
    • Naohiro Aota's avatar
      btrfs: start readahead also in seed devices · 2b1395f3
      Naohiro Aota authored
      
      commit c4e0540d upstream.
      
      Currently, btrfs does not consult seed devices to start readahead. As a
      result, if readahead zone is added to the seed devices, btrfs_reada_wait()
      indefinitely wait for the reada_ctl to finish.
      
      You can reproduce the hung by modifying btrfs/163 to have larger initial
      file size (e.g. xfs_io pwrite 4M instead of current 256K).
      
      Fixes: 7414a03f ("btrfs: initial readahead code and prototypes")
      Reviewed-by: default avatarFilipe Manana <fdmanana@suse.com>
      Signed-off-by: default avatarNaohiro Aota <naohiro.aota@wdc.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      2b1395f3
    • Filipe Manana's avatar
      Btrfs: fix race between readahead and device replace/removal · 328891dc
      Filipe Manana authored
      
      commit ce7791ff upstream.
      
      The list of devices is protected by the device_list_mutex and the device
      replace code, in its finishing phase correctly takes that mutex before
      removing the source device from that list. However the readahead code was
      iterating that list without acquiring the respective mutex leading to
      crashes later on due to invalid memory accesses:
      
      [125671.831036] general protection fault: 0000 [#1] PREEMPT SMP
      [125671.832129] Modules linked in: btrfs dm_flakey dm_mod crc32c_generic xor raid6_pq acpi_cpufreq tpm_tis tpm ppdev evdev parport_pc psmouse sg parport
      processor ser
      [125671.834973] CPU: 10 PID: 19603 Comm: kworker/u32:19 Tainted: G        W       4.6.0-rc7-btrfs-next-29+ #1
      [125671.834973] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS by qemu-project.org 04/01/2014
      [125671.834973] Workqueue: btrfs-readahead btrfs_readahead_helper [btrfs]
      [125671.834973] task: ffff8801ac520540 ti: ffff8801ac918000 task.ti: ffff8801ac918000
      [125671.834973] RIP: 0010:[<ffffffff81270479>]  [<ffffffff81270479>] __radix_tree_lookup+0x6a/0x105
      [125671.834973] RSP: 0018:ffff8801ac91bc28  EFLAGS: 00010206
      [125671.834973] RAX: 0000000000000000 RBX: 6b6b6b6b6b6b6b6a RCX: 0000000000000000
      [125671.834973] RDX: 0000000000000000 RSI: 00000000000c1bff RDI: ffff88002ebd62a8
      [125671.834973] RBP: ffff8801ac91bc70 R08: 0000000000000001 R09: 0000000000000000
      [125671.834973] R10: ffff8801ac91bc70 R11: 0000000000000000 R12: ffff88002ebd62a8
      [125671.834973] R13: 0000000000000000 R14: 0000000000000000 R15: 00000000000c1bff
      [125671.834973] FS:  0000000000000000(0000) GS:ffff88023fd40000(0000) knlGS:0000000000000000
      [125671.834973] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [125671.834973] CR2: 000000000073cae4 CR3: 00000000b7723000 CR4: 00000000000006e0
      [125671.834973] Stack:
      [125671.834973]  0000000000000000 ffff8801422d5600 ffff8802286bbc00 0000000000000000
      [125671.834973]  0000000000000001 ffff8802286bbc00 00000000000c1bff 0000000000000000
      [125671.834973]  ffff88002e639eb8 ffff8801ac91bc80 ffffffff81270541 ffff8801ac91bcb0
      [125671.834973] Call Trace:
      [125671.834973]  [<ffffffff81270541>] radix_tree_lookup+0xd/0xf
      [125671.834973]  [<ffffffffa04ae6a6>] reada_peer_zones_set_lock+0x3e/0x60 [btrfs]
      [125671.834973]  [<ffffffffa04ae8b9>] reada_pick_zone+0x29/0x103 [btrfs]
      [125671.834973]  [<ffffffffa04af42f>] reada_start_machine_worker+0x129/0x2d3 [btrfs]
      [125671.834973]  [<ffffffffa04880be>] btrfs_scrubparity_helper+0x185/0x3aa [btrfs]
      [125671.834973]  [<ffffffffa0488341>] btrfs_readahead_helper+0xe/0x10 [btrfs]
      [125671.834973]  [<ffffffff81069691>] process_one_work+0x271/0x4e9
      [125671.834973]  [<ffffffff81069dda>] worker_thread+0x1eb/0x2c9
      [125671.834973]  [<ffffffff81069bef>] ? rescuer_thread+0x2b3/0x2b3
      [125671.834973]  [<ffffffff8106f403>] kthread+0xd4/0xdc
      [125671.834973]  [<ffffffff8149e242>] ret_from_fork+0x22/0x40
      [125671.834973]  [<ffffffff8106f32f>] ? kthread_stop+0x286/0x286
      
      So fix this by taking the device_list_mutex in the readahead code. We
      can't use here the lighter approach of using a rcu_read_lock() and
      rcu_read_unlock() pair together with a list_for_each_entry_rcu() call
      because we end up doing calls to sleeping functions (kzalloc()) in the
      respective code path.
      
      Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
      Reviewed-by: default avatarJosef Bacik <jbacik@fb.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      328891dc
    • Eric Biggers's avatar
      cfg80211: fix memory leak of wiphy device name · 41c5fe03
      Eric Biggers authored
      
      commit 4f488fbc upstream.
      
      In wiphy_new_nm(), if an error occurs after dev_set_name() and
      device_initialize() have already been called, it's necessary to call
      put_device() (via wiphy_free()) to avoid a memory leak.
      
      Reported-by: default avatar <syzbot+7fddca22578bc67c3fe4@syzkaller.appspotmail.com>
      Fixes: 1f87f7d3 ("cfg80211: add rfkill support")
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      41c5fe03
    • Andrea Arcangeli's avatar
      coredump: fix race condition between collapse_huge_page() and core dumping · 2c82fc92
      Andrea Arcangeli authored
      commit 59ea6d06 upstream.
      
      When fixing the race conditions between the coredump and the mmap_sem
      holders outside the context of the process, we focused on
      mmget_not_zero()/get_task_mm() callers in 04f5866e ("coredump: fix
      race condition between mmget_not_zero()/get_task_mm() and core
      dumping"), but those aren't the only cases where the mmap_sem can be
      taken outside of the context of the process as Michal Hocko noticed
      while backporting that commit to older -stable kernels.
      
      If mmgrab() is called in the context of the process, but then the
      mm_count reference is transferred outside the context of the process,
      that can also be a problem if the mmap_sem has to be taken for writing
      through that mm_count reference.
      
      khugepaged registration calls mmgrab() in the context of the process,
      but the mmap_sem for writing is taken later in the context of the
      khugepaged kernel thread.
      
      collapse_huge_page() after taking the mmap_sem for writing doesn't
      modify any vma, so it's not obvious that it could cause a problem to the
      coredump, but it happens to modify the pmd in a way that breaks an
      invariant that pmd_trans_huge_lock() relies upon.  collapse_huge_page()
      needs the mmap_sem for writing just to block concurrent page faults that
      call pmd_trans_huge_lock().
      
      Specifically the invariant that "!pmd_trans_huge()" cannot become a
      "pmd_trans_huge()" doesn't hold while collapse_huge_page() runs.
      
      The coredump will call __get_user_pages() without mmap_sem for reading,
      which eventually can invoke a lockless page fault which will need a
      functional pmd_trans_huge_lock().
      
      So collapse_huge_page() needs to use mmget_still_valid() to check it's
      not running concurrently with the coredump...  as long as the coredump
      can invoke page faults without holding the mmap_sem for reading.
      
      This has "Fixes: khugepaged" to facilitate backporting, but in my view
      it's more a bug in the coredump code that will eventually have to be
      rewritten to stop invoking page faults without the mmap_sem for reading.
      So the long term plan is still to drop all mmget_still_valid().
      
      Link: http://lkml.kernel.org/r/20190607161558.32104-1-aarcange@redhat.com
      
      
      Fixes: ba76149f ("thp: khugepaged")
      Signed-off-by: default avatarAndrea Arcangeli <aarcange@redhat.com>
      Reported-by: default avatarMichal Hocko <mhocko@suse.com>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Acked-by: default avatarKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Jann Horn <jannh@google.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
      Cc: Mike Kravetz <mike.kravetz@oracle.com>
      Cc: Peter Xu <peterx@redhat.com>
      Cc: Jason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      [bwh: Backported to 3.16:
       - Don't set result variable; collapse_huge_range() returns void
       - Adjust filenames]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      2c82fc92
    • Wengang Wang's avatar
      fs/ocfs2: fix race in ocfs2_dentry_attach_lock() · 318c972b
      Wengang Wang authored
      commit be99ca27 upstream.
      
      ocfs2_dentry_attach_lock() can be executed in parallel threads against the
      same dentry.  Make that race safe.  The race is like this:
      
                  thread A                               thread B
      
      (A1) enter ocfs2_dentry_attach_lock,
      seeing dentry->d_fsdata is NULL,
      and no alias found by
      ocfs2_find_local_alias, so kmalloc
      a new ocfs2_dentry_lock structure
      to local variable "dl", dl1
      
                     .....
      
                                          (B1) enter ocfs2_dentry_attach_lock,
                                          seeing dentry->d_fsdata is NULL,
                                          and no alias found by
                                          ocfs2_find_local_alias so kmalloc
                                          a new ocfs2_dentry_lock structure
                                          to local variable "dl", dl2.
      
                                                         ......
      
      (A2) set dentry->d_fsdata with dl1,
      call ocfs2_dentry_lock() and increase
      dl1->dl_lockres.l_ro_holders to 1 on
      success.
                    ......
      
                                          (B2) set dentry->d_fsdata with dl2
                                          call ocfs2_dentry_lock() and increase
      				    dl2->dl_lockres.l_ro_holders to 1 on
      				    success.
      
                                                        ......
      
      (A3) call ocfs2_dentry_unlock()
      and decrease
      dl2->dl_lockres.l_ro_holders to 0
      on success.
                   ....
      
                                          (B3) call ocfs2_dentry_unlock(),
                                          decreasing
      				    dl2->dl_lockres.l_ro_holders, but
      				    see it's zero now, panic
      
      Link: http://lkml.kernel.org/r/20190529174636.22364-1-wen.gang.wang@oracle.com
      
      
      Signed-off-by: default avatarWengang Wang <wen.gang.wang@oracle.com>
      Reported-by: default avatarDaniel Sobe <daniel.sobe@nxp.com>
      Tested-by: default avatarDaniel Sobe <daniel.sobe@nxp.com>
      Reviewed-by: default avatarChangwei Ge <gechangwei@live.cn>
      Reviewed-by: default avatarJoseph Qi <joseph.qi@linux.alibaba.com>
      Cc: Mark Fasheh <mark@fasheh.com>
      Cc: Joel Becker <jlbec@evilplan.org>
      Cc: Junxiao Bi <junxiao.bi@oracle.com>
      Cc: Gang He <ghe@suse.com>
      Cc: Jun Piao <piaojun@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 avatarBen Hutchings <ben@decadent.org.uk>
      318c972b
    • Ronnie Sahlberg's avatar
      cifs: add spinlock for the openFileList to cifsInodeInfo · b252047f
      Ronnie Sahlberg authored
      
      commit 487317c9 upstream.
      
      We can not depend on the tcon->open_file_lock here since in multiuser mode
      we may have the same file/inode open via multiple different tcons.
      
      The current code is race prone and will crash if one user deletes a file
      at the same time a different user opens/create the file.
      
      To avoid this we need to have a spinlock attached to the inode and not the tcon.
      
      RHBZ:  1580165
      
      Signed-off-by: default avatarRonnie Sahlberg <lsahlber@redhat.com>
      Signed-off-by: default avatarSteve French <stfrench@microsoft.com>
      Reviewed-by: default avatarPavel Shilovsky <pshilov@microsoft.com>
      [bwh: Backported to 3.16: adjust context, indentation]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      b252047f
    • Hans de Goede's avatar
      libata: Extend quirks for the ST1000LM024 drives with NOLPM quirk · af782c2f
      Hans de Goede authored
      commit 31f6264e upstream.
      
      We've received a bugreport that using LPM with ST1000LM024 drives leads
      to system lockups. So it seems that these models are buggy in more then
      1 way. Add NOLPM quirk to the existing quirks entry for BROKEN_FPDMA_AA.
      
      BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1571330
      
      
      Reviewed-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      af782c2f
    • Coly Li's avatar
      bcache: fix stack corruption by PRECEDING_KEY() · b14685fc
      Coly Li authored
      
      commit 31b90956 upstream.
      
      Recently people report bcache code compiled with gcc9 is broken, one of
      the buggy behavior I observe is that two adjacent 4KB I/Os should merge
      into one but they don't. Finally it turns out to be a stack corruption
      caused by macro PRECEDING_KEY().
      
      See how PRECEDING_KEY() is defined in bset.h,
      437 #define PRECEDING_KEY(_k)                                       \
      438 ({                                                              \
      439         struct bkey *_ret = NULL;                               \
      440                                                                 \
      441         if (KEY_INODE(_k) || KEY_OFFSET(_k)) {                  \
      442                 _ret = &KEY(KEY_INODE(_k), KEY_OFFSET(_k), 0);  \
      443                                                                 \
      444                 if (!_ret->low)                                 \
      445                         _ret->high--;                           \
      446                 _ret->low--;                                    \
      447         }                                                       \
      448                                                                 \
      449         _ret;                                                   \
      450 })
      
      At line 442, _ret points to address of a on-stack variable combined by
      KEY(), the life range of this on-stack variable is in line 442-446,
      once _ret is returned to bch_btree_insert_key(), the returned address
      points to an invalid stack address and this address is overwritten in
      the following called bch_btree_iter_init(). Then argument 'search' of
      bch_btree_iter_init() points to some address inside stackframe of
      bch_btree_iter_init(), exact address depends on how the compiler
      allocates stack space. Now the stack is corrupted.
      
      Fixes: 0eacac22 ("bcache: PRECEDING_KEY()")
      Signed-off-by: default avatarColy Li <colyli@suse.de>
      Reviewed-by: default avatarRolf Fokkens <rolf@rolffokkens.nl>
      Reviewed-by: default avatarPierre JUHEN <pierre.juhen@orange.fr>
      Tested-by: default avatarShenghui Wang <shhuiw@foxmail.com>
      Tested-by: default avatarPierre JUHEN <pierre.juhen@orange.fr>
      Cc: Kent Overstreet <kent.overstreet@gmail.com>
      Cc: Nix <nix@esperi.org.uk>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      b14685fc
    • Dave Martin's avatar
      KVM: arm64: Filter out invalid core register IDs in KVM_GET_REG_LIST · 9c5ff7c4
      Dave Martin authored
      
      commit df205b5c upstream.
      
      Since commit d26c25a9 ("arm64: KVM: Tighten guest core register
      access from userspace"), KVM_{GET,SET}_ONE_REG rejects register IDs
      that do not correspond to a single underlying architectural register.
      
      KVM_GET_REG_LIST was not changed to match however: instead, it
      simply yields a list of 32-bit register IDs that together cover the
      whole kvm_regs struct.  This means that if userspace tries to use
      the resulting list of IDs directly to drive calls to KVM_*_ONE_REG,
      some of those calls will now fail.
      
      This was not the intention.  Instead, iterating KVM_*_ONE_REG over
      the list of IDs returned by KVM_GET_REG_LIST should be guaranteed
      to work.
      
      This patch fixes the problem by splitting validate_core_offset()
      into a backend core_reg_size_from_offset() which does all of the
      work except for checking that the size field in the register ID
      matches, and kvm_arm_copy_reg_indices() and num_core_regs() are
      converted to use this to enumerate the valid offsets.
      
      kvm_arm_copy_reg_indices() now also sets the register ID size field
      appropriately based on the value returned, so the register ID
      supplied to userspace is fully qualified for use with the register
      access ioctls.
      
      Fixes: d26c25a9 ("arm64: KVM: Tighten guest core register access from userspace")
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Reviewed-by: default avatarAndrew Jones <drjones@redhat.com>
      Tested-by: default avatarAndrew Jones <drjones@redhat.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      [bwh: Backported to 3.16:
       - Don't add unused vcpu parameter
       - Adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      9c5ff7c4
    • Russell King's avatar
      i2c: acorn: fix i2c warning · 0a90ef6e
      Russell King authored
      
      commit ca21f851 upstream.
      
      The Acorn i2c driver (for RiscPC) triggers the "i2c adapter has no name"
      warning in the I2C core driver, resulting in the RTC being inaccessible.
      Fix this.
      
      Fixes: 2236baa7 ("i2c: Sanity checks on adapter registration")
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      0a90ef6e
    • Jann Horn's avatar
      ptrace: restore smp_rmb() in __ptrace_may_access() · 74c41ea7
      Jann Horn authored
      
      commit f6581f5b upstream.
      
      Restore the read memory barrier in __ptrace_may_access() that was deleted
      a couple years ago. Also add comments on this barrier and the one it pairs
      with to explain why they're there (as far as I understand).
      
      Fixes: bfedb589 ("mm: Add a user_ns owner to mm_struct and fix ptrace permission checks")
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Acked-by: default avatarOleg Nesterov <oleg@redhat.com>
      Signed-off-by: default avatarJann Horn <jannh@google.com>
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      74c41ea7
    • Eric Dumazet's avatar
      ipv6: flowlabel: fl6_sock_lookup() must use atomic_inc_not_zero · c03cd575
      Eric Dumazet authored
      
      commit 65a3c497 upstream.
      
      Before taking a refcount, make sure the object is not already
      scheduled for deletion.
      
      Same fix is needed in ipv6_flowlabel_opt()
      
      Fixes: 18367681 ("ipv6 flowlabel: Convert np->ipv6_fl_list to RCU.")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Willem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      c03cd575
    • Willem de Bruijn's avatar
      can: purge socket error queue on sock destruct · fa1aeb54
      Willem de Bruijn authored
      
      commit fd704bd5 upstream.
      
      CAN supports software tx timestamps as of the below commit. Purge
      any queued timestamp packets on socket destroy.
      
      Fixes: 51f31cab ("ip: support for TX timestamps on UDP and RAW sockets")
      Reported-by: default avatar <syzbot+a90604060cb40f5bdd16@syzkaller.appspotmail.com>
      Signed-off-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      fa1aeb54
    • YueHaibing's avatar
      can: af_can: Fix error path of can_init() · 3d638d69
      YueHaibing authored
      
      commit c5a3aed1 upstream.
      
      This patch add error path for can_init() to avoid possible crash if some
      error occurs.
      
      Fixes: 0d66548a ("[CAN]: Add PF_CAN core module")
      Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
      Acked-by: default avatarOliver Hartkopp <socketcan@hartkopp.net>
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      [bwh: Backported to 3.16:
       - af_can doesn't register any pernet_operations
       - It does start a global timer and add procfs entries that need to be
         cleaned up on the error path]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      3d638d69
    • Joakim Zhang's avatar
      can: flexcan: fix timeout when set small bitrate · 58caee4b
      Joakim Zhang authored
      
      commit 247e5356 upstream.
      
      Current we can meet timeout issue when setting a small bitrate like
      10000 as follows on i.MX6UL EVK board (ipg clock = 66MHZ, per clock =
      30MHZ):
      
      | root@imx6ul7d:~# ip link set can0 up type can bitrate 10000
      
      A link change request failed with some changes committed already.
      Interface can0 may have been left with an inconsistent configuration,
      please check.
      
      | RTNETLINK answers: Connection timed out
      
      It is caused by calling of flexcan_chip_unfreeze() timeout.
      
      Originally the code is using usleep_range(10, 20) for unfreeze
      operation, but the patch (8badd65e can: flexcan: avoid calling
      usleep_range from interrupt context) changed it into udelay(10) which is
      only a half delay of before, there're also some other delay changes.
      
      After double to FLEXCAN_TIMEOUT_US to 100 can fix the issue.
      
      Meanwhile, Rasmus Villemoes reported that even with a timeout of 100,
      flexcan_probe() fails on the MPC8309, which requires a value of at least
      140 to work reliably. 250 works for everyone.
      
      Signed-off-by: default avatarJoakim Zhang <qiangqing.zhang@nxp.com>
      Reviewed-by: default avatarDong Aisheng <aisheng.dong@nxp.com>
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      58caee4b
Loading