1. 27 Sep, 2016 8 commits
    • Yotam Gigi's avatar
      act_ife: Fix false encoding · c006da0b
      Yotam Gigi authored
      On ife encode side, the action stores the different tlvs inside the ife
      header, where each tlv length field should refer to the length of the
      whole tlv (without additional padding) and not just the data length.
      
      On ife decode side, the action iterates over the tlvs in the ife header
      and parses them one by one, where in each iteration the current pointer is
      advanced according to the tlv size.
      
      Before, the encoding encoded only the data length inside the tlv, which led
      to false parsing of ife the header. In addition, due to the fact that the
      loop counter was unsigned, it could lead to infinite parsing loop.
      
      This fix changes the loop counter to be signed and fixes the encoding to
      take into account the tlv type and size.
      
      Fixes: 28a10c42 ("net sched: fix encoding to use real length")
      Acked-by: default avatarJamal Hadi Salim <jhs@mojatatu.com>
      Signed-off-by: default avatarYotam Gigi <yotamg@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c006da0b
    • Yotam Gigi's avatar
      act_ife: Fix external mac header on encode · 4b1d488a
      Yotam Gigi authored
      On ife encode side, external mac header is copied from the original packet
      and may be overridden if the user requests. Before, the mac header copy
      was done from memory region that might not be accessible anymore, as
      skb_cow_head might free it and copy the packet. This led to random values
      in the external mac header once the values were not set by user.
      
      This fix takes the internal mac header from the packet, after the call to
      skb_cow_head.
      
      Fixes: ef6980b6 ("net sched: introduce IFE action")
      Acked-by: default avatarJamal Hadi Salim <jhs@mojatatu.com>
      Signed-off-by: default avatarYotam Gigi <yotamg@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4b1d488a
    • Jorgen Hansen's avatar
      VSOCK: Don't dec ack backlog twice for rejected connections · 1190cfdb
      Jorgen Hansen authored
      If a pending socket is marked as rejected, we will decrease the
      sk_ack_backlog twice. So don't decrement it for rejected sockets
      in vsock_pending_work().
      
      Testing of the rejected socket path was done through code
      modifications.
      Reported-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      Signed-off-by: default avatarJorgen Hansen <jhansen@vmware.com>
      Reviewed-by: default avatarAdit Ranadive <aditr@vmware.com>
      Reviewed-by: default avatarAditya Sarwade <asarwade@vmware.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1190cfdb
    • Florian Fainelli's avatar
      Revert "net: ethernet: bcmgenet: use phydev from struct net_device" · bf1a85a8
      Florian Fainelli authored
      This reverts commit 62469c76 ("net: ethernet: bcmgenet: use phydev
      from struct net_device") because it causes GENETv1/2/3 adapters to
      expose the following behavior after an ifconfig down/up sequence:
      
      PING fainelli-linux (10.112.156.244): 56 data bytes
      64 bytes from 10.112.156.244: seq=1 ttl=61 time=1.352 ms
      64 bytes from 10.112.156.244: seq=1 ttl=61 time=1.472 ms (DUP!)
      64 bytes from 10.112.156.244: seq=1 ttl=61 time=1.496 ms (DUP!)
      64 bytes from 10.112.156.244: seq=1 ttl=61 time=1.517 ms (DUP!)
      64 bytes from 10.112.156.244: seq=1 ttl=61 time=1.536 ms (DUP!)
      64 bytes from 10.112.156.244: seq=1 ttl=61 time=1.557 ms (DUP!)
      64 bytes from 10.112.156.244: seq=1 ttl=61 time=752.448 ms (DUP!)
      
      This was previously fixed by commit 5dbebbb4 ("net: bcmgenet:
      Software reset EPHY after power on") but the commit we are reverting was
      essentially making this previous commit void, here is why.
      
      Without commit 62469c76 we would have the following scenario after
      an ifconfig down then up sequence:
      
      - bcmgenet_open() calls bcmgenet_power_up() to make sure the PHY is
        initialized *before* we get to initialize the UniMAC, this is
        critical to ensure the PHY is in a correct state, priv->phydev is
        valid, this code executes fine
      
      - second time from bcmgenet_mii_probe(), through the normal
        phy_init_hw() call (which arguably could be optimized out)
      
      Everything is fine in that case. With commit 62469c76, we would have
      the following scenario to happen after an ifconfig down then up
      sequence:
      
      - bcmgenet_close() calls phy_disonnect() which makes dev->phydev become
        NULL
      
      - when bcmgenet_open() executes again and calls bcmgenet_mii_reset() from
        bcmgenet_power_up() to initialize the internal PHY, the NULL check
        becomes true, so we do not reset the PHY, yet we keep going on and
        initialize the UniMAC, causing MAC activity to occur
      
      - we call bcmgenet_mii_reset() from bcmgenet_mii_probe(), but this is
        too late, the PHY is botched, and causes the above bogus pings/packets
        transmission/reception to occur
      Reported-by: default avatarJaedon Shin <jaedon.shin@gmail.com>
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bf1a85a8
    • David S. Miller's avatar
      Merge branch 'fec-align' · 6c1394f3
      David S. Miller authored
      Eric Nelson says:
      
      ====================
      net: fec: updates to align IP header
      
      This patch series is the outcome of investigation into very high
      numbers of alignment faults on kernel 4.1.33 from the linux-fslc
      tree:
          https://github.com/freescale/linux-fslc/tree/4.1-1.0.x-imx
      
      The first two patches remove support for the receive accelerator (RACC) from
      the i.MX25 and i.MX27 SoCs which don't support the function.
      
      The third patch enables hardware alignment of the ethernet packet payload
      (and especially the IP header) to prevent alignment faults in the IP stack.
      
      Testing on i.MX6UL on the 4.1.33 kernel showed that this patch removed
      on the order of 70k alignment faults during a 100MiB transfer using
      wget.
      
      Testing on an i.MX6Q (SABRE Lite) board on net-next (4.8.0-rc7) showed
      a much more modest improvement from 10's of faults, and it's not clear
      why that's the case.
      ====================
      Acked-by: default avatarFugang Duan <fugang.duan@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6c1394f3
    • Eric Nelson's avatar
      net: fec: align IP header in hardware · 3ac72b7b
      Eric Nelson authored
      The FEC receive accelerator (RACC) supports shifting the data payload of
      received packets by 16-bits, which aligns the payload (IP header) on a
      4-byte boundary, which is, if not required, at least strongly suggested
      by the Linux networking layer.
      
      Without this patch, a huge number of alignment faults will be taken by the
      IP stack, as seen in /proc/cpu/alignment:
      
      	~/$ cat /proc/cpu/alignment
      	User:		0
      	System:		72645 (inet_gro_receive+0x104/0x27c)
      	Skipped:	0
      	Half:		0
      	Word:		0
      	DWord:		0
      	Multi:		72645
      	User faults:	3 (fixup+warn)
      
      This patch was suggested by Andrew Lunn in this message to linux-netdev:
      	http://marc.info/?l=linux-arm-kernel&m=147465452108384&w=2
      
      and adapted from a patch by Russell King from 2014:
      	http://git.arm.linux.org.uk/cgit/linux-arm.git/commit/?id=70d8a8aSigned-off-by: default avatarEric Nelson <eric@nelint.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3ac72b7b
    • Eric Nelson's avatar
      net: fec: remove QUIRK_HAS_RACC from i.mx27 · 97dc499c
      Eric Nelson authored
      According to the i.MX27 reference manual, this SoC does not have support
      for the receive accelerator (RACC) register at offset 0x1C4.
      
      	http://cache.nxp.com/files/32bit/doc/ref_manual/MCIMX27RM.pdfSigned-off-by: default avatarEric Nelson <eric@nelint.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      97dc499c
    • Eric Nelson's avatar
      net: fec: remove QUIRK_HAS_RACC from i.mx25 · 653d37d8
      Eric Nelson authored
      According to the i.MX25 reference manual, this SoC does not have support
      for the receive accelerator (RACC) register at offset 0x1C4.
      
      http://www.nxp.com/files/dsp/doc/ref_manual/IMX25RM.pdfSigned-off-by: default avatarEric Nelson <eric@nelint.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      653d37d8
  2. 26 Sep, 2016 1 commit
    • Nikolay Aleksandrov's avatar
      ipmr, ip6mr: fix scheduling while atomic and a deadlock with ipmr_get_route · 2cf75070
      Nikolay Aleksandrov authored
      Since the commit below the ipmr/ip6mr rtnl_unicast() code uses the portid
      instead of the previous dst_pid which was copied from in_skb's portid.
      Since the skb is new the portid is 0 at that point so the packets are sent
      to the kernel and we get scheduling while atomic or a deadlock (depending
      on where it happens) by trying to acquire rtnl two times.
      Also since this is RTM_GETROUTE, it can be triggered by a normal user.
      
      Here's the sleeping while atomic trace:
      [ 7858.212557] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:620
      [ 7858.212748] in_atomic(): 1, irqs_disabled(): 0, pid: 0, name: swapper/0
      [ 7858.212881] 2 locks held by swapper/0/0:
      [ 7858.213013]  #0:  (((&mrt->ipmr_expire_timer))){+.-...}, at: [<ffffffff810fbbf5>] call_timer_fn+0x5/0x350
      [ 7858.213422]  #1:  (mfc_unres_lock){+.....}, at: [<ffffffff8161e005>] ipmr_expire_process+0x25/0x130
      [ 7858.213807] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.8.0-rc7+ #179
      [ 7858.213934] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
      [ 7858.214108]  0000000000000000 ffff88005b403c50 ffffffff813a7804 0000000000000000
      [ 7858.214412]  ffffffff81a1338e ffff88005b403c78 ffffffff810a4a72 ffffffff81a1338e
      [ 7858.214716]  000000000000026c 0000000000000000 ffff88005b403ca8 ffffffff810a4b9f
      [ 7858.215251] Call Trace:
      [ 7858.215412]  <IRQ>  [<ffffffff813a7804>] dump_stack+0x85/0xc1
      [ 7858.215662]  [<ffffffff810a4a72>] ___might_sleep+0x192/0x250
      [ 7858.215868]  [<ffffffff810a4b9f>] __might_sleep+0x6f/0x100
      [ 7858.216072]  [<ffffffff8165bea3>] mutex_lock_nested+0x33/0x4d0
      [ 7858.216279]  [<ffffffff815a7a5f>] ? netlink_lookup+0x25f/0x460
      [ 7858.216487]  [<ffffffff8157474b>] rtnetlink_rcv+0x1b/0x40
      [ 7858.216687]  [<ffffffff815a9a0c>] netlink_unicast+0x19c/0x260
      [ 7858.216900]  [<ffffffff81573c70>] rtnl_unicast+0x20/0x30
      [ 7858.217128]  [<ffffffff8161cd39>] ipmr_destroy_unres+0xa9/0xf0
      [ 7858.217351]  [<ffffffff8161e06f>] ipmr_expire_process+0x8f/0x130
      [ 7858.217581]  [<ffffffff8161dfe0>] ? ipmr_net_init+0x180/0x180
      [ 7858.217785]  [<ffffffff8161dfe0>] ? ipmr_net_init+0x180/0x180
      [ 7858.217990]  [<ffffffff810fbc95>] call_timer_fn+0xa5/0x350
      [ 7858.218192]  [<ffffffff810fbbf5>] ? call_timer_fn+0x5/0x350
      [ 7858.218415]  [<ffffffff8161dfe0>] ? ipmr_net_init+0x180/0x180
      [ 7858.218656]  [<ffffffff810fde10>] run_timer_softirq+0x260/0x640
      [ 7858.218865]  [<ffffffff8166379b>] ? __do_softirq+0xbb/0x54f
      [ 7858.219068]  [<ffffffff816637c8>] __do_softirq+0xe8/0x54f
      [ 7858.219269]  [<ffffffff8107a948>] irq_exit+0xb8/0xc0
      [ 7858.219463]  [<ffffffff81663452>] smp_apic_timer_interrupt+0x42/0x50
      [ 7858.219678]  [<ffffffff816625bc>] apic_timer_interrupt+0x8c/0xa0
      [ 7858.219897]  <EOI>  [<ffffffff81055f16>] ? native_safe_halt+0x6/0x10
      [ 7858.220165]  [<ffffffff810d64dd>] ? trace_hardirqs_on+0xd/0x10
      [ 7858.220373]  [<ffffffff810298e3>] default_idle+0x23/0x190
      [ 7858.220574]  [<ffffffff8102a20f>] arch_cpu_idle+0xf/0x20
      [ 7858.220790]  [<ffffffff810c9f8c>] default_idle_call+0x4c/0x60
      [ 7858.221016]  [<ffffffff810ca33b>] cpu_startup_entry+0x39b/0x4d0
      [ 7858.221257]  [<ffffffff8164f995>] rest_init+0x135/0x140
      [ 7858.221469]  [<ffffffff81f83014>] start_kernel+0x50e/0x51b
      [ 7858.221670]  [<ffffffff81f82120>] ? early_idt_handler_array+0x120/0x120
      [ 7858.221894]  [<ffffffff81f8243f>] x86_64_start_reservations+0x2a/0x2c
      [ 7858.222113]  [<ffffffff81f8257c>] x86_64_start_kernel+0x13b/0x14a
      
      Fixes: 2942e900 ("[RTNETLINK]: Use rtnl_unicast() for rtnetlink unicasts")
      Signed-off-by: default avatarNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2cf75070
  3. 24 Sep, 2016 1 commit
  4. 23 Sep, 2016 5 commits
  5. 22 Sep, 2016 11 commits
  6. 21 Sep, 2016 12 commits
  7. 20 Sep, 2016 2 commits
    • Al Viro's avatar
      fix fault_in_multipages_...() on architectures with no-op access_ok() · e23d4159
      Al Viro authored
      Switching iov_iter fault-in to multipages variants has exposed an old
      bug in underlying fault_in_multipages_...(); they break if the range
      passed to them wraps around.  Normally access_ok() done by callers will
      prevent such (and it's a guaranteed EFAULT - ERR_PTR() values fall into
      such a range and they should not point to any valid objects).
      
      However, on architectures where userland and kernel live in different
      MMU contexts (e.g. s390) access_ok() is a no-op and on those a range
      with a wraparound can reach fault_in_multipages_...().
      
      Since any wraparound means EFAULT there, the fix is trivial - turn
      those
      
          while (uaddr <= end)
      	    ...
      into
      
          if (unlikely(uaddr > end))
      	    return -EFAULT;
          do
      	    ...
          while (uaddr <= end);
      Reported-by: default avatarJan Stancek <jstancek@redhat.com>
      Tested-by: default avatarJan Stancek <jstancek@redhat.com>
      Cc: stable@vger.kernel.org # v3.5+
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      e23d4159
    • Laura Abbott's avatar
      mm: usercopy: Check for module addresses · aa4f0601
      Laura Abbott authored
      While running a compile on arm64, I hit a memory exposure
      
      usercopy: kernel memory exposure attempt detected from fffffc0000f3b1a8 (buffer_head) (1 bytes)
      ------------[ cut here ]------------
      kernel BUG at mm/usercopy.c:75!
      Internal error: Oops - BUG: 0 [#1] SMP
      Modules linked in: ip6t_rpfilter ip6t_REJECT
      nf_reject_ipv6 xt_conntrack ip_set nfnetlink ebtable_broute bridge stp
      llc ebtable_nat ip6table_security ip6table_raw ip6table_nat
      nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle
      iptable_security iptable_raw iptable_nat nf_conntrack_ipv4
      nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle
      ebtable_filter ebtables ip6table_filter ip6_tables vfat fat xgene_edac
      xgene_enet edac_core i2c_xgene_slimpro i2c_core at803x realtek xgene_dma
      mdio_xgene gpio_dwapb gpio_xgene_sb xgene_rng mailbox_xgene_slimpro nfsd
      auth_rpcgss nfs_acl lockd grace sunrpc xfs libcrc32c sdhci_of_arasan
      sdhci_pltfm sdhci mmc_core xhci_plat_hcd gpio_keys
      CPU: 0 PID: 19744 Comm: updatedb Tainted: G        W 4.8.0-rc3-threadinfo+ #1
      Hardware name: AppliedMicro X-Gene Mustang Board/X-Gene Mustang Board, BIOS 3.06.12 Aug 12 2016
      task: fffffe03df944c00 task.stack: fffffe00d128c000
      PC is at __check_object_size+0x70/0x3f0
      LR is at __check_object_size+0x70/0x3f0
      ...
      [<fffffc00082b4280>] __check_object_size+0x70/0x3f0
      [<fffffc00082cdc30>] filldir64+0x158/0x1a0
      [<fffffc0000f327e8>] __fat_readdir+0x4a0/0x558 [fat]
      [<fffffc0000f328d4>] fat_readdir+0x34/0x40 [fat]
      [<fffffc00082cd8f8>] iterate_dir+0x190/0x1e0
      [<fffffc00082cde58>] SyS_getdents64+0x88/0x120
      [<fffffc0008082c70>] el0_svc_naked+0x24/0x28
      
      fffffc0000f3b1a8 is a module address. Modules may have compiled in
      strings which could get copied to userspace. In this instance, it
      looks like "." which matches with a size of 1 byte. Extend the
      is_vmalloc_addr check to be is_vmalloc_or_module_addr to cover
      all possible cases.
      Signed-off-by: default avatarLaura Abbott <labbott@redhat.com>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      aa4f0601