On 8/29/23 13:27, Xin Long wrote:
> On Tue, Aug 29, 2023 at 3:14 AM Nikita Zhandarovich
> <n.zhandarovich@xxxxxxxxxx> wrote:
>>
>> Syzbot identified a case [1] of uninitialized memory usage in
>> sctp_inq_pop(), specifically in 'ch->length'.
>>
>> Fix the issue by ensuring that 'ch->length' reflects the size of
>> 'sctp_chunkhdr *ch' before accessing it.
>>
>> [1]
>> BUG: KMSAN: uninit-value in sctp_inq_pop+0x1597/0x1910 net/sctp/inqueue.c:205
>> sctp_inq_pop+0x1597/0x1910 net/sctp/inqueue.c:205
>> sctp_assoc_bh_rcv+0x1a7/0xc50 net/sctp/associola.c:997
>> sctp_inq_push+0x23e/0x2b0 net/sctp/inqueue.c:80
>> sctp_backlog_rcv+0x394/0xd80 net/sctp/input.c:331
>> sk_backlog_rcv include/net/sock.h:1115 [inline]
>> __release_sock+0x207/0x570 net/core/sock.c:2911
>> release_sock+0x6b/0x1e0 net/core/sock.c:3478
>> sctp_wait_for_connect+0x486/0x810 net/sctp/socket.c:9325
>> sctp_sendmsg_to_asoc+0x1ea7/0x1ee0 net/sctp/socket.c:1884
>> ...
>>
>> Uninit was stored to memory at:
>> sctp_inq_pop+0x151a/0x1910 net/sctp/inqueue.c:201
>> sctp_assoc_bh_rcv+0x1a7/0xc50 net/sctp/associola.c:997
>> sctp_inq_push+0x23e/0x2b0 net/sctp/inqueue.c:80
>> sctp_backlog_rcv+0x394/0xd80 net/sctp/input.c:331
>> sk_backlog_rcv include/net/sock.h:1115 [inline]
>> __release_sock+0x207/0x570 net/core/sock.c:2911
>> release_sock+0x6b/0x1e0 net/core/sock.c:3478
>> sctp_wait_for_connect+0x486/0x810 net/sctp/socket.c:9325
>> sctp_sendmsg_to_asoc+0x1ea7/0x1ee0 net/sctp/socket.c:1884
>> ...
>>
>> Uninit was created at:
>> slab_post_alloc_hook+0x12d/0xb60 mm/slab.h:716
>> slab_alloc_node mm/slub.c:3451 [inline]
>> __kmem_cache_alloc_node+0x4ff/0x8b0 mm/slub.c:3490
>> __do_kmalloc_node mm/slab_common.c:965 [inline]
>> __kmalloc_node_track_caller+0x118/0x3c0 mm/slab_common.c:986
>> kmalloc_reserve+0x248/0x470 net/core/skbuff.c:585
>> __alloc_skb+0x318/0x740 net/core/skbuff.c:654
>> alloc_skb include/linux/skbuff.h:1288 [inline]
>> sctp_packet_pack net/sctp/output.c:472 [inline]
>> sctp_packet_transmit+0x1729/0x4150 net/sctp/output.c:621
>> sctp_outq_flush_transports net/sctp/outqueue.c:1173 [inline]
>> ...
>>
>> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
>> Reported-and-tested-by: syzbot+70a42f45e76bede082be@xxxxxxxxxxxxxxxxxxxxxxxxx
>> Closes: https://syzkaller.appspot.com/bug?extid=70a42f45e76bede082be
>> Signed-off-by: Nikita Zhandarovich <n.zhandarovich@xxxxxxxxxx>
>> ---
>> net/sctp/inqueue.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/net/sctp/inqueue.c b/net/sctp/inqueue.c
>> index 7182c5a450fb..98ce9524c87c 100644
>> --- a/net/sctp/inqueue.c
>> +++ b/net/sctp/inqueue.c
>> @@ -197,6 +197,7 @@ struct sctp_chunk *sctp_inq_pop(struct sctp_inq *queue)
>> }
>> }
>>
>> + ch->length = htons(sizeof(*ch));
>> chunk->chunk_hdr = ch;
>> chunk->chunk_end = ((__u8 *)ch) + SCTP_PAD4(ntohs(ch->length));
>> skb_pull(chunk->skb, sizeof(*ch));
>> --
>> 2.25.1
>>
> Hi, Nikita
>
> You can't just overwrite "ch->length", "ch" is the header of the received chunk.
> if it says ch->length is Uninit, it means either the chunk parsing in
> the receiver
> is overflow or the format of the chunk created in the sender is incorrect.
>
> If you can reproduce it stably, I suggest you start from sctp_inq_pop() and
> print out the skb info and data in there, and see if it's a normal chunk.
>
> Thanks.
Thank you for your feedback, I'll follow your advice and try to narrow
the problem down.
With regards,
Nikita
