1. 12 May, 2022 7 commits
  2. 11 May, 2022 12 commits
  3. 10 May, 2022 9 commits
  4. 09 May, 2022 10 commits
  5. 06 May, 2022 2 commits
    • Kees Cook's avatar
      net: chelsio: cxgb4: Avoid potential negative array offset · 1c7ab9cd
      Kees Cook authored
      Using min_t(int, ...) as a potential array index implies to the compiler
      that negative offsets should be allowed. This is not the case, though.
      Replace "int" with "unsigned int". Fixes the following warning exposed
      under future CONFIG_FORTIFY_SOURCE improvements:
      
      In file included from include/linux/string.h:253,
                       from include/linux/bitmap.h:11,
                       from include/linux/cpumask.h:12,
                       from include/linux/smp.h:13,
                       from include/linux/lockdep.h:14,
                       from include/linux/rcupdate.h:29,
                       from include/linux/rculist.h:11,
                       from include/linux/pid.h:5,
                       from include/linux/sched.h:14,
                       from include/linux/delay.h:23,
                       from drivers/net/ethernet/chelsio/cxgb4/t4_hw.c:35:
      drivers/net/ethernet/chelsio/cxgb4/t4_hw.c: In function 't4_get_raw_vpd_params':
      include/linux/fortify-string.h:46:33: warning: '__builtin_memcpy' pointer overflow between offset 29 and size [2147483648, 4294967295] [-Warray-bounds]
         46 | #define __underlying_memcpy     __builtin_memcpy
            |                                 ^
      include/linux/fortify-string.h:388:9: note: in expansion of macro '__underlying_memcpy'
        388 |         __underlying_##op(p, q, __fortify_size);                        \
            |         ^~~~~~~~~~~~~
      include/linux/fortify-string.h:433:26: note: in expansion of macro '__fortify_memcpy_chk'
        433 | #define memcpy(p, q, s)  __fortify_memcpy_chk(p, q, s,                  \
            |                          ^~~~~~~~~~~~~~~~~~~~
      drivers/net/ethernet/chelsio/cxgb4/t4_hw.c:2796:9: note: in expansion of macro 'memcpy'
       2796 |         memcpy(p->id, vpd + id, min_t(int, id_len, ID_LEN));
            |         ^~~~~~
      include/linux/fortify-string.h:46:33: warning: '__builtin_memcpy' pointer overflow between offset 0 and size [2147483648, 4294967295] [-Warray-bounds]
         46 | #define __underlying_memcpy     __builtin_memcpy
            |                                 ^
      include/linux/fortify-string.h:388:9: note: in expansion of macro '__underlying_memcpy'
        388 |         __underlying_##op(p, q, __fortify_size);                        \
            |         ^~~~~~~~~~~~~
      include/linux/fortify-string.h:433:26: note: in expansion of macro '__fortify_memcpy_chk'
        433 | #define memcpy(p, q, s)  __fortify_memcpy_chk(p, q, s,                  \
            |                          ^~~~~~~~~~~~~~~~~~~~
      drivers/net/ethernet/chelsio/cxgb4/t4_hw.c:2798:9: note: in expansion of macro 'memcpy'
       2798 |         memcpy(p->sn, vpd + sn, min_t(int, sn_len, SERNUM_LEN));
            |         ^~~~~~
      
      Additionally remove needless cast from u8[] to char * in last strim()
      call.
      Reported-by: default avatarkernel test robot <lkp@intel.com>
      Link: https://lore.kernel.org/lkml/202205031926.FVP7epJM-lkp@intel.com
      Fixes: fc927929 ("cxgb4: Search VPD with pci_vpd_find_ro_info_keyword()")
      Fixes: 24c521f8 ("cxgb4: Use pci_vpd_find_id_string() to find VPD ID string")
      Cc: Raju Rangoju <rajur@chelsio.com>
      Cc: Eric Dumazet <edumazet@google.com>
      Cc: Paolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Link: https://lore.kernel.org/r/20220505233101.1224230-1-keescook@chromium.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      1c7ab9cd
    • Eric Dumazet's avatar
      netlink: do not reset transport header in netlink_recvmsg() · d5076fe4
      Eric Dumazet authored
      netlink_recvmsg() does not need to change transport header.
      
      If transport header was needed, it should have been reset
      by the producer (netlink_dump()), not the consumer(s).
      
      The following trace probably happened when multiple threads
      were using MSG_PEEK.
      
      BUG: KCSAN: data-race in netlink_recvmsg / netlink_recvmsg
      
      write to 0xffff88811e9f15b2 of 2 bytes by task 32012 on cpu 1:
       skb_reset_transport_header include/linux/skbuff.h:2760 [inline]
       netlink_recvmsg+0x1de/0x790 net/netlink/af_netlink.c:1978
       sock_recvmsg_nosec net/socket.c:948 [inline]
       sock_recvmsg net/socket.c:966 [inline]
       __sys_recvfrom+0x204/0x2c0 net/socket.c:2097
       __do_sys_recvfrom net/socket.c:2115 [inline]
       __se_sys_recvfrom net/socket.c:2111 [inline]
       __x64_sys_recvfrom+0x74/0x90 net/socket.c:2111
       do_syscall_x64 arch/x86/entry/common.c:50 [inline]
       do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80
       entry_SYSCALL_64_after_hwframe+0x44/0xae
      
      write to 0xffff88811e9f15b2 of 2 bytes by task 32005 on cpu 0:
       skb_reset_transport_header include/linux/skbuff.h:2760 [inline]
       netlink_recvmsg+0x1de/0x790 net/netlink/af_netlink.c:1978
       ____sys_recvmsg+0x162/0x2f0
       ___sys_recvmsg net/socket.c:2674 [inline]
       __sys_recvmsg+0x209/0x3f0 net/socket.c:2704
       __do_sys_recvmsg net/socket.c:2714 [inline]
       __se_sys_recvmsg net/socket.c:2711 [inline]
       __x64_sys_recvmsg+0x42/0x50 net/socket.c:2711
       do_syscall_x64 arch/x86/entry/common.c:50 [inline]
       do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80
       entry_SYSCALL_64_after_hwframe+0x44/0xae
      
      value changed: 0xffff -> 0x0000
      
      Reported by Kernel Concurrency Sanitizer on:
      CPU: 0 PID: 32005 Comm: syz-executor.4 Not tainted 5.18.0-rc1-syzkaller-00328-ge1f700eb-dirty #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Link: https://lore.kernel.org/r/20220505161946.2867638-1-eric.dumazet@gmail.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      d5076fe4