1. 06 Aug, 2019 9 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 2 commits
    • Denis Kirjanov's avatar
      net: usb: pegasus: fix improper read if get_registers() fail · 224c0497
      Denis Kirjanov authored
      get_registers() may fail with -ENOMEM and in this
      case we can read a garbage from the status variable tmp.
      
      Reported-by: syzbot+3499a83b2d062ae409d4@syzkaller.appspotmail.com
      Signed-off-by: default avatarDenis Kirjanov <kda@linux-powerpc.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      224c0497
    • Taras Kondratiuk's avatar
      tipc: compat: allow tipc commands without arguments · 4da5f001
      Taras Kondratiuk authored
      Commit 2753ca5d ("tipc: fix uninit-value in tipc_nl_compat_doit")
      broke older tipc tools that use compat interface (e.g. tipc-config from
      tipcutils package):
      
      % tipc-config -p
      operation not supported
      
      The commit started to reject TIPC netlink compat messages that do not
      have attributes. It is too restrictive because some of such messages are
      valid (they don't need any arguments):
      
      % grep 'tx none' include/uapi/linux/tipc_config.h
      #define  TIPC_CMD_NOOP              0x0000    /* tx none, rx none */
      #define  TIPC_CMD_GET_MEDIA_NAMES   0x0002    /* tx none, rx media_name(s) */
      #define  TIPC_CMD_GET_BEARER_NAMES  0x0003    /* tx none, rx bearer_name(s) */
      #define  TIPC_CMD_SHOW_PORTS        0x0006    /* tx none, rx ultra_string */
      #define  TIPC_CMD_GET_REMOTE_MNG    0x4003    /* tx none, rx unsigned */
      #define  TIPC_CMD_GET_MAX_PORTS     0x4004    /* tx none, rx unsigned */
      #define  TIPC_CMD_GET_NETID         0x400B    /* tx none, rx unsigned */
      #define  TIPC_CMD_NOT_NET_ADMIN     0xC001    /* tx none, rx none */
      
      This patch relaxes the original fix and rejects messages without
      arguments only if such arguments are expected by a command (reg_type is
      non zero).
      
      Fixes: 2753ca5d ("tipc: fix uninit-value in tipc_nl_compat_doit")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarTaras Kondratiuk <takondra@cisco.com>
      Acked-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4da5f001