Re: [PATCH] tipc: Fix uninit-value access in tipc_nl_node_reset_link_stats()

From: Shigeru Yoshida
Date: Tue Sep 26 2023 - 09:00:20 EST


On 9/26/23 20:19, Jon Maloy wrote:
>
>
> On 2023-09-24 02:03, Shigeru Yoshida wrote:
>> syzbot reported the following uninit-value access issue:
>>
>> =====================================================
>> BUG: KMSAN: uninit-value in strlen lib/string.c:418 [inline]
>> BUG: KMSAN: uninit-value in strstr+0xb8/0x2f0 lib/string.c:756
>>   strlen lib/string.c:418 [inline]
>>   strstr+0xb8/0x2f0 lib/string.c:756
>>   tipc_nl_node_reset_link_stats+0x3ea/0xb50 net/tipc/node.c:2595
>>   genl_family_rcv_msg_doit net/netlink/genetlink.c:971 [inline]
>>   genl_family_rcv_msg net/netlink/genetlink.c:1051 [inline]
>>   genl_rcv_msg+0x11ec/0x1290 net/netlink/genetlink.c:1066
>>   netlink_rcv_skb+0x371/0x650 net/netlink/af_netlink.c:2545
>>   genl_rcv+0x40/0x60 net/netlink/genetlink.c:1075
>>   netlink_unicast_kernel net/netlink/af_netlink.c:1342 [inline]
>>   netlink_unicast+0xf47/0x1250 net/netlink/af_netlink.c:1368
>>   netlink_sendmsg+0x1238/0x13d0 net/netlink/af_netlink.c:1910
>>   sock_sendmsg_nosec net/socket.c:730 [inline]
>>   sock_sendmsg net/socket.c:753 [inline]
>>   ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2541
>>   ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2595
>>   __sys_sendmsg net/socket.c:2624 [inline]
>>   __do_sys_sendmsg net/socket.c:2633 [inline]
>>   __se_sys_sendmsg net/socket.c:2631 [inline]
>>   __x64_sys_sendmsg+0x307/0x490 net/socket.c:2631
>>   do_syscall_x64 arch/x86/entry/common.c:50 [inline]
>>   do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
>>   entry_SYSCALL_64_after_hwframe+0x63/0xcd
>>
>> Uninit was created at:
>>   slab_post_alloc_hook+0x12f/0xb70 mm/slab.h:767
>>   slab_alloc_node mm/slub.c:3478 [inline]
>>   kmem_cache_alloc_node+0x577/0xa80 mm/slub.c:3523
>>   kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:559
>>   __alloc_skb+0x318/0x740 net/core/skbuff.c:650
>>   alloc_skb include/linux/skbuff.h:1286 [inline]
>>   netlink_alloc_large_skb net/netlink/af_netlink.c:1214 [inline]
>>   netlink_sendmsg+0xb34/0x13d0 net/netlink/af_netlink.c:1885
>>   sock_sendmsg_nosec net/socket.c:730 [inline]
>>   sock_sendmsg net/socket.c:753 [inline]
>>   ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2541
>>   ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2595
>>   __sys_sendmsg net/socket.c:2624 [inline]
>>   __do_sys_sendmsg net/socket.c:2633 [inline]
>>   __se_sys_sendmsg net/socket.c:2631 [inline]
>>   __x64_sys_sendmsg+0x307/0x490 net/socket.c:2631
>>   do_syscall_x64 arch/x86/entry/common.c:50 [inline]
>>   do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
>>   entry_SYSCALL_64_after_hwframe+0x63/0xcd
>>
>> Link names must be null-terminated strings. If a link name which is not
>> null-terminated is passed through netlink, strstr() and similar functions
>> can cause buffer overrun. This causes the above issue.
>>
>> This patch fixes this issue by returning -EINVAL if a non-null-terminated
>> link name is passed.
>>
>> Fixes: ae36342b50a9 ("tipc: add link stat reset to new netlink api")
>> Reported-and-tested-by: syzbot+5138ca807af9d2b42574@xxxxxxxxxxxxxxxxxxxxxxxxx
>> Closes: https://syzkaller.appspot.com/bug?extid=5138ca807af9d2b42574
>> Signed-off-by: Shigeru Yoshida <syoshida@xxxxxxxxxx>
>> ---
>>   net/tipc/node.c | 4 ++++
>>   1 file changed, 4 insertions(+)
>>
>> diff --git a/net/tipc/node.c b/net/tipc/node.c
>> index 3105abe97bb9..f167bdafc034 100644
>> --- a/net/tipc/node.c
>> +++ b/net/tipc/node.c
>> @@ -2586,6 +2586,10 @@ int tipc_nl_node_reset_link_stats(struct sk_buff *skb, struct genl_info *info)
>>         link_name = nla_data(attrs[TIPC_NLA_LINK_NAME]);
>>   +    if (link_name[strnlen(link_name,
>> +                  nla_len(attrs[TIPC_NLA_LINK_NAME]))] != '\0')
>> +        return -EINVAL;
>> +
>>       err = -EINVAL;
>>       if (!strcmp(link_name, tipc_bclink_name)) {
>>           err = tipc_bclink_reset_stats(net, tipc_bc_sndlink(net));
> Acked-by: Jon Maloy <jmaloy@xxxxxxxxxx>

Thanks! syzbot reported very similar issue regarding bearer name too.
I've sent a patch for that issue.

Thanks,
Shigeru