1. 14 Aug, 2019 1 commit
  2. 13 Aug, 2019 1 commit
    • Dirk Morris's avatar
      netfilter: conntrack: Use consistent ct id hash calculation · 656c8e9c
      Dirk Morris authored
      Change ct id hash calculation to only use invariants.
      
      Currently the ct id hash calculation is based on some fields that can
      change in the lifetime on a conntrack entry in some corner cases. The
      current hash uses the whole tuple which contains an hlist pointer which
      will change when the conntrack is placed on the dying list resulting in
      a ct id change.
      
      This patch also removes the reply-side tuple and extension pointer from
      the hash calculation so that the ct id will will not change from
      initialization until confirmation.
      
      Fixes: 3c791076 ("netfilter: ctnetlink: don't use conntrack/expect object addresses as id")
      Signed-off-by: default avatarDirk Morris <dmorris@metaloft.com>
      Acked-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      656c8e9c
  3. 09 Aug, 2019 3 commits
    • Pablo Neira Ayuso's avatar
      netfilter: nf_flow_table: teardown flow timeout race · 1e5b2471
      Pablo Neira Ayuso authored
      Flows that are in teardown state (due to RST / FIN TCP packet) still
      have their offload flag set on. Hence, the conntrack garbage collector
      may race to undo the timeout adjustment that the fixup routine performs,
      leaving the conntrack entry in place with the internal offload timeout
      (one day).
      
      Update teardown flow state to ESTABLISHED and set tracking to liberal,
      then once the offload bit is cleared, adjust timeout if it is more than
      the default fixup timeout (conntrack might already have set a lower
      timeout from the packet path).
      
      Fixes: da5984e5 ("netfilter: nf_flow_table: add support for sending flows back to the slow path")
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      1e5b2471
    • Pablo Neira Ayuso's avatar
      netfilter: nf_flow_table: conntrack picks up expired flows · 3e68db2f
      Pablo Neira Ayuso authored
      Update conntrack entry to pick up expired flows, otherwise the conntrack
      entry gets stuck with the internal offload timeout (one day). The TCP
      state also needs to be adjusted to ESTABLISHED state and tracking is set
      to liberal mode in order to give conntrack a chance to pick up the
      expired flow.
      
      Fixes: ac2a6666 ("netfilter: add generic flow table infrastructure")
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      3e68db2f
    • Pablo Neira Ayuso's avatar
      netfilter: nf_tables: use-after-free in failing rule with bound set · 6a0a8d10
      Pablo Neira Ayuso authored
      If a rule that has already a bound anonymous set fails to be added, the
      preparation phase releases the rule and the bound set. However, the
      transaction object from the abort path still has a reference to the set
      object that is stale, leading to a use-after-free when checking for the
      set->bound field. Add a new field to the transaction that specifies if
      the set is bound, so the abort path can skip releasing it since the rule
      command owns it and it takes care of releasing it. After this update,
      the set->bound field is removed.
      
      [   24.649883] Unable to handle kernel paging request at virtual address 0000000000040434
      [   24.657858] Mem abort info:
      [   24.660686]   ESR = 0x96000004
      [   24.663769]   Exception class = DABT (current EL), IL = 32 bits
      [   24.669725]   SET = 0, FnV = 0
      [   24.672804]   EA = 0, S1PTW = 0
      [   24.675975] Data abort info:
      [   24.678880]   ISV = 0, ISS = 0x00000004
      [   24.682743]   CM = 0, WnR = 0
      [   24.685723] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000428952000
      [   24.692207] [0000000000040434] pgd=0000000000000000
      [   24.697119] Internal error: Oops: 96000004 [#1] SMP
      [...]
      [   24.889414] Call trace:
      [   24.891870]  __nf_tables_abort+0x3f0/0x7a0
      [   24.895984]  nf_tables_abort+0x20/0x40
      [   24.899750]  nfnetlink_rcv_batch+0x17c/0x588
      [   24.904037]  nfnetlink_rcv+0x13c/0x190
      [   24.907803]  netlink_unicast+0x18c/0x208
      [   24.911742]  netlink_sendmsg+0x1b0/0x350
      [   24.915682]  sock_sendmsg+0x4c/0x68
      [   24.919185]  ___sys_sendmsg+0x288/0x2c8
      [   24.923037]  __sys_sendmsg+0x7c/0xd0
      [   24.926628]  __arm64_sys_sendmsg+0x2c/0x38
      [   24.930744]  el0_svc_common.constprop.0+0x94/0x158
      [   24.935556]  el0_svc_handler+0x34/0x90
      [   24.939322]  el0_svc+0x8/0xc
      [   24.942216] Code: 37280300 f9404023 91014262 aa1703e0 (f9401863)
      [   24.948336] ---[ end trace cebbb9dcbed3b56f ]---
      
      Fixes: f6ac8585 ("netfilter: nf_tables: unbind set in rule from commit path")
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      6a0a8d10
  4. 05 Aug, 2019 2 commits
    • Florian Westphal's avatar
      netfilter: nf_flow_table: fix offload for flows that are subject to xfrm · 589b474a
      Florian Westphal authored
      This makes the previously added 'encap test' pass.
      Because its possible that the xfrm dst entry becomes stale while such
      a flow is offloaded, we need to call dst_check() -- the notifier that
      handles this for non-tunneled traffic isn't sufficient, because SA or
      or policies might have changed.
      
      If dst becomes stale the flow offload entry will be tagged for teardown
      and packets will be passed to 'classic' forwarding path.
      
      Removing the entry right away is problematic, as this would
      introduce a race condition with the gc worker.
      
      In case flow is long-lived, it could eventually be offloaded again
      once the gc worker removes the entry from the flow table.
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      589b474a
    • Florian Westphal's avatar
      selftests: netfilter: extend flowtable test script for ipsec · 0ca1bbb7
      Florian Westphal authored
      'flow offload' expression should not offload flows that will be subject
      to ipsec, but it does.
      
      This results in a connectivity blackhole for the affected flows -- first
      packets will go through (offload happens after established state is
      reached), but all remaining ones bypass ipsec encryption and are thus
      discarded by the peer.
      
      This can be worked around by adding "rt ipsec exists accept"
      before the 'flow offload' rule matches.
      
      This test case will fail, support for such flows is added in
      next patch.
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      0ca1bbb7
  5. 03 Aug, 2019 7 commits
    • Qian Cai's avatar
      net/socket: fix GCC8+ Wpacked-not-aligned warnings · 5e5412c3
      Qian Cai authored
      There are a lot of those warnings with GCC8+ 64-bit,
      
      In file included from ./include/linux/sctp.h:42,
                       from net/core/skbuff.c:47:
      ./include/uapi/linux/sctp.h:395:1: warning: alignment 4 of 'struct
      sctp_paddr_change' is less than 8 [-Wpacked-not-aligned]
       } __attribute__((packed, aligned(4)));
       ^
      ./include/uapi/linux/sctp.h:728:1: warning: alignment 4 of 'struct
      sctp_setpeerprim' is less than 8 [-Wpacked-not-aligned]
       } __attribute__((packed, aligned(4)));
       ^
      ./include/uapi/linux/sctp.h:727:26: warning: 'sspp_addr' offset 4 in
      'struct sctp_setpeerprim' isn't aligned to 8 [-Wpacked-not-aligned]
        struct sockaddr_storage sspp_addr;
                                ^~~~~~~~~
      ./include/uapi/linux/sctp.h:741:1: warning: alignment 4 of 'struct
      sctp_prim' is less than 8 [-Wpacked-not-aligned]
       } __attribute__((packed, aligned(4)));
       ^
      ./include/uapi/linux/sctp.h:740:26: warning: 'ssp_addr' offset 4 in
      'struct sctp_prim' isn't aligned to 8 [-Wpacked-not-aligned]
        struct sockaddr_storage ssp_addr;
                                ^~~~~~~~
      ./include/uapi/linux/sctp.h:792:1: warning: alignment 4 of 'struct
      sctp_paddrparams' is less than 8 [-Wpacked-not-aligned]
       } __attribute__((packed, aligned(4)));
       ^
      ./include/uapi/linux/sctp.h:784:26: warning: 'spp_address' offset 4 in
      'struct sctp_paddrparams' isn't aligned to 8 [-Wpacked-not-aligned]
        struct sockaddr_storage spp_address;
                                ^~~~~~~~~~~
      ./include/uapi/linux/sctp.h:905:1: warning: alignment 4 of 'struct
      sctp_paddrinfo' is less than 8 [-Wpacked-not-aligned]
       } __attribute__((packed, aligned(4)));
       ^
      ./include/uapi/linux/sctp.h:899:26: warning: 'spinfo_address' offset 4
      in 'struct sctp_paddrinfo' isn't aligned to 8 [-Wpacked-not-aligned]
        struct sockaddr_storage spinfo_address;
                                ^~~~~~~~~~~~~~
      
      This is because the commit 20c9c825 ("[SCTP] Fix SCTP socket options
      to work with 32-bit apps on 64-bit kernels.") added "packed, aligned(4)"
      GCC attributes to some structures but one of the members, i.e, "struct
      sockaddr_storage" in those structures has the attribute,
      "aligned(__alignof__ (struct sockaddr *)" which is 8-byte on 64-bit
      systems, so the commit overwrites the designed alignments for
      "sockaddr_storage".
      
      To fix this, "struct sockaddr_storage" needs to be aligned to 4-byte as
      it is only used in those packed sctp structure which is part of UAPI,
      and "struct __kernel_sockaddr_storage" is used in some other
      places of UAPI that need not to change alignments in order to not
      breaking userspace.
      
      Use an implicit alignment for "struct __kernel_sockaddr_storage" so it
      can keep the same alignments as a member in both packed and un-packed
      structures without breaking UAPI.
      Suggested-by: default avatarDavid Laight <David.Laight@ACULAB.COM>
      Signed-off-by: default avatarQian Cai <cai@lca.pw>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5e5412c3
    • Kevin Lo's avatar
      r8152: fix typo in register name · 59c0b47a
      Kevin Lo authored
      It is likely that PAL_BDC_CR should be PLA_BDC_CR.
      Signed-off-by: default avatarKevin Lo <kevlo@kevlo.org>
      Acked-by: default avatarHayes Wang <hayeswang@realtek.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      59c0b47a
    • Heiner Kallweit's avatar
      net: phy: fix race in genphy_update_link · aa6b1956
      Heiner Kallweit authored
      In phy_start_aneg() autoneg is started, and immediately after that
      link and autoneg status are read. As reported in [0] it can happen that
      at time of this read the PHY has reset the "aneg complete" bit but not
      yet the "link up" bit, what can result in a false link-up detection.
      To fix this don't report link as up if we're in aneg mode and PHY
      doesn't signal "aneg complete".
      
      [0] https://marc.info/?t=156413509900003&r=1&w=2
      
      Fixes: 4950c2ba ("net: phy: fix autoneg mismatch case in genphy_read_status")
      Reported-by: default avatarliuyonglong <liuyonglong@huawei.com>
      Tested-by: default avatarliuyonglong <liuyonglong@huawei.com>
      Signed-off-by: default avatarHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      aa6b1956
    • YueHaibing's avatar
      enetc: Select PHYLIB while CONFIG_FSL_ENETC_VF is set · 2802d2cf
      YueHaibing authored
      Like FSL_ENETC, when CONFIG_FSL_ENETC_VF is set,
      we should select PHYLIB, otherwise building still fails:
      
      drivers/net/ethernet/freescale/enetc/enetc.o: In function `enetc_open':
      enetc.c:(.text+0x2744): undefined reference to `phy_start'
      enetc.c:(.text+0x282c): undefined reference to `phy_disconnect'
      drivers/net/ethernet/freescale/enetc/enetc.o: In function `enetc_close':
      enetc.c:(.text+0x28f8): undefined reference to `phy_stop'
      enetc.c:(.text+0x2904): undefined reference to `phy_disconnect'
      drivers/net/ethernet/freescale/enetc/enetc_ethtool.o:(.rodata+0x3f8): undefined reference to `phy_ethtool_get_link_ksettings'
      drivers/net/ethernet/freescale/enetc/enetc_ethtool.o:(.rodata+0x400): undefined reference to `phy_ethtool_set_link_ksettings'
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Fixes: d4fd0404 ("enetc: Introduce basic PF and VF ENETC ethernet drivers")
      Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2802d2cf
    • Wang Xiayang's avatar
      net/ethernet/qlogic/qed: force the string buffer NULL-terminated · 3690c8c9
      Wang Xiayang authored
      strncpy() does not ensure NULL-termination when the input string
      size equals to the destination buffer size 30.
      The output string is passed to qed_int_deassertion_aeu_bit()
      which calls DP_INFO() and relies NULL-termination.
      
      Use strlcpy instead. The other conditional branch above strncpy()
      needs no fix as snprintf() ensures NULL-termination.
      
      This issue is identified by a Coccinelle script.
      Signed-off-by: default avatarWang Xiayang <xywang.sjtu@sjtu.edu.cn>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3690c8c9
    • Gustavo A. R. Silva's avatar
      atm: iphase: Fix Spectre v1 vulnerability · ea443e5e
      Gustavo A. R. Silva authored
      board is controlled by user-space, hence leading to a potential
      exploitation of the Spectre variant 1 vulnerability.
      
      This issue was detected with the help of Smatch:
      
      drivers/atm/iphase.c:2765 ia_ioctl() warn: potential spectre issue 'ia_dev' [r] (local cap)
      drivers/atm/iphase.c:2774 ia_ioctl() warn: possible spectre second half.  'iadev'
      drivers/atm/iphase.c:2782 ia_ioctl() warn: possible spectre second half.  'iadev'
      drivers/atm/iphase.c:2816 ia_ioctl() warn: possible spectre second half.  'iadev'
      drivers/atm/iphase.c:2823 ia_ioctl() warn: possible spectre second half.  'iadev'
      drivers/atm/iphase.c:2830 ia_ioctl() warn: potential spectre issue '_ia_dev' [r] (local cap)
      drivers/atm/iphase.c:2845 ia_ioctl() warn: possible spectre second half.  'iadev'
      drivers/atm/iphase.c:2856 ia_ioctl() warn: possible spectre second half.  'iadev'
      
      Fix this by sanitizing board before using it to index ia_dev and _ia_dev
      
      Notice that given that speculation windows are large, the policy is
      to kill the speculation on the first load and not worry if it can be
      completed with a dependent load/store [1].
      
      [1] https://lore.kernel.org/lkml/20180423164740.GY17484@dhcp22.suse.cz/Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ea443e5e
    • Dexuan Cui's avatar
      hv_sock: Fix hang when a connection is closed · 685703b4
      Dexuan Cui authored
      There is a race condition for an established connection that is being closed
      by the guest: the refcnt is 4 at the end of hvs_release() (Note: here the
      'remove_sock' is false):
      
      1 for the initial value;
      1 for the sk being in the bound list;
      1 for the sk being in the connected list;
      1 for the delayed close_work.
      
      After hvs_release() finishes, __vsock_release() -> sock_put(sk) *may*
      decrease the refcnt to 3.
      
      Concurrently, hvs_close_connection() runs in another thread:
        calls vsock_remove_sock() to decrease the refcnt by 2;
        call sock_put() to decrease the refcnt to 0, and free the sk;
        next, the "release_sock(sk)" may hang due to use-after-free.
      
      In the above, after hvs_release() finishes, if hvs_close_connection() runs
      faster than "__vsock_release() -> sock_put(sk)", then there is not any issue,
      because at the beginning of hvs_close_connection(), the refcnt is still 4.
      
      The issue can be resolved if an extra reference is taken when the
      connection is established.
      
      Fixes: a9eeb998 ("hv_sock: Add support for delayed close")
      Signed-off-by: default avatarDexuan Cui <decui@microsoft.com>
      Reviewed-by: default avatarSunil Muthuswamy <sunilmut@microsoft.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      685703b4
  6. 01 Aug, 2019 12 commits
  7. 31 Jul, 2019 14 commits