[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240112131554.10352-1-n.zhandarovich@fintech.ru>
Date: Fri, 12 Jan 2024 05:15:54 -0800
From: Nikita Zhandarovich <n.zhandarovich@...tech.ru>
To: Alexander Aring <aahringo@...hat.com>
CC: Nikita Zhandarovich <n.zhandarovich@...tech.ru>, Zhang Shurong
<zhang_shurong@...mail.com>, <alex.aring@...il.com>,
<stefan@...enfreihafen.org>, <davem@...emloft.net>, <edumazet@...gle.com>,
<kuba@...nel.org>, <pabeni@...hat.com>, <linux-wpan@...r.kernel.org>,
<netdev@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<harperchen1110@...il.com>
Subject: Re: [PATCH RESEND] mac802154: Fix uninit-value access in ieee802154_hdr_push_sechdr
>> > >
>> > > BUG: KMSAN: uninit-value in ieee802154_hdr_push_sechdr net/ieee802154=
> /header_ops.c:54 [inline]
>> > > BUG: KMSAN: uninit-value in ieee802154_hdr_push+0x971/0xb90 net/ieee8=
> 02154/header_ops.c:108
>> > > ieee802154_hdr_push_sechdr net/ieee802154/header_ops.c:54 [inline]
>> > > ieee802154_hdr_push+0x971/0xb90 net/ieee802154/header_ops.c:108
>> > > ieee802154_header_create+0x9c0/0xc00 net/mac802154/iface.c:396
>> > > wpan_dev_hard_header include/net/cfg802154.h:494 [inline]
>> > > dgram_sendmsg+0xd1d/0x1500 net/ieee802154/socket.c:677
>> > > ieee802154_sock_sendmsg+0x91/0xc0 net/ieee802154/socket.c:96
>> > > sock_sendmsg_nosec net/socket.c:725 [inline]
>> > > sock_sendmsg net/socket.c:748 [inline]
>> > > ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2494
>> > > ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2548
>> > > __sys_sendmsg+0x225/0x3c0 net/socket.c:2577
>> > > __compat_sys_sendmsg net/compat.c:346 [inline]
>> > > __do_compat_sys_sendmsg net/compat.c:353 [inline]
>> > > __se_compat_sys_sendmsg net/compat.c:350 [inline]
>> > >
>> > > We found hdr->key_id_mode is uninitialized in mac802154_set_header_se=
> curity()
>> > > which indicates hdr.fc.security_enabled should be 0. However, it is s=
> et to be cb->secen before.
>> > > Later, ieee802154_hdr_push_sechdr is invoked, causing KMSAN complains=
> uninit-value issue.
>> >
>> > I am not too deeply involved in the security header but for me it feels
>> > like your patch does the opposite of what's needed. We should maybe
>> > initialize hdr->key_id_mode based on the value in cb->secen, no? (maybe
>> > Alexander will have a better understanding than I have).
>>
>> I can't help yet with a better answer why syzkaller reports it but it
>> will break things as we using skb->cb to pass additional parameters
>> through header_ops->create()... in this case it is some sockopts of
>> af802154, I guess.
>>
>
> Maybe we just need to init some "more" defaults in [0]
>
> - Alex
>
> [0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree=
> /net/ieee802154/socket.c?h=3Dv6.7-rc5#n474
Hello,
I was looking into the same issue (now present in syzbot [1]) and since it has a
C-repro, the error is easy to recreate. Apparently, despite cb->secen (and
hdr.fc.security_enabled accordingly) being equal 1, mac802154_set_header_security()
finishes with 0 in:
if (!params.enabled ||
(cb->secen_override && !cb->secen) ||
!params.out_level)
return 0;
Not presuming to understand the issue fully but if we do end up leaving
mac802154_set_header_security() early, should we init hdr->key_id_mode
with IEEE802154_SCF_KEY_IMPLICIT before returning with 0?
I imagine that reseting hdr.fc.security_enabled to 0 ourselves in this
case is a wrong way to go too.
[1] https://syzkaller.appspot.com/bug?extid=60a66d44892b66b56545
Hoping not to have spewed too much nonsense here...
With regards,
Nikita
Powered by blists - more mailing lists