1. 06 Aug, 2019 3 commits
  2. 05 Aug, 2019 18 commits
  3. 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
  4. 02 Aug, 2019 4 commits
  5. 01 Aug, 2019 8 commits