[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CADvbK_c2zqQ76kzPmTovWqpRdN2ad7duHsCs9fW9oVNCLdd-Xw@mail.gmail.com>
Date: Thu, 23 Oct 2025 12:56:02 -0400
From: Xin Long <lucien.xin@...il.com>
To: Ranganath V N <vnranganath.20@...il.com>
Cc: Marcelo Ricardo Leitner <marcelo.leitner@...il.com>, "David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Simon Horman <horms@...nel.org>, linux-sctp@...r.kernel.org, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, syzkaller-bugs@...glegroups.com,
syzbot+d101e12bccd4095460e7@...kaller.appspotmail.com
Subject: Re: [PATCH] net: sctp: fix KMSAN uninit-value in sctp_inq_pop
On Thu, Oct 23, 2025 at 5:52 AM Ranganath V N <vnranganath.20@...il.com> wrote:
>
> Fix an issue detected by syzbot:
>
> KMSAN reported an uninitialized-value access in sctp_inq_pop
Hi, Ranganath,
The issue is actually caused by skb trimming via sk_filter() in sctp_rcv().
In the reproducer, skb->len becomes 1 after sk_filter(), which bypassed the
original check:
if (skb->len < sizeof(struct sctphdr) + sizeof(struct sctp_chunkhdr) +
skb_transport_offset(skb))
(TBH, I didn't expect it would allow BPF to trim skb in sk_filter().)
To handle this safely, a new check should be performed after sk_filter() like:
+ if (sk_filter(sk, skb) || skb->len < sizeof(struct sctp_chunkhdr))
goto discard_release;
Could you please proceed with this change in sctp_rcv()?
Thanks.
Powered by blists - more mailing lists