[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240819180216.15865-1-kuniyu@amazon.com>
Date: Mon, 19 Aug 2024 11:02:16 -0700
From: Kuniyuki Iwashima <kuniyu@...zon.com>
To: <edumazet@...gle.com>
CC: <davem@...emloft.net>, <kuba@...nel.org>, <kuni1840@...il.com>,
<kuniyu@...zon.com>, <netdev@...r.kernel.org>, <pabeni@...hat.com>,
<syzbot+b72d86aa5df17ce74c60@...kaller.appspotmail.com>,
<tom@...bertland.com>
Subject: Re: [PATCH v1 net] kcm: Serialise kcm_sendmsg() for the same socket.
From: Eric Dumazet <edumazet@...gle.com>
Date: Mon, 19 Aug 2024 17:56:55 +0200
> On Fri, Aug 16, 2024 at 12:04 AM Kuniyuki Iwashima <kuniyu@...zon.com> wrote:
> >
> > syzkaller reported UAF in kcm_release(). [0]
> >
> > The scenario is
> >
> > 1. Thread A builds a skb with MSG_MORE and sets kcm->seq_skb.
> >
> > 2. Thread A resumes building skb from kcm->seq_skb but is blocked
> > by sk_stream_wait_memory()
> >
> > 3. Thread B calls sendmsg() concurrently, finishes building kcm->seq_skb
> > and puts the skb to the write queue
> >
> > 4. Thread A faces an error and finally frees skb that is already in the
> > write queue
> >
> > 5. kcm_release() does double-free the skb in the write queue
> >
> > When a thread is building a MSG_MORE skb, another thread must not touch it.
> >
> > Let's add a per-sk mutex and serialise kcm_sendmsg().
> >
> >
> > Fixes: ab7ac4eb9832 ("kcm: Kernel Connection Multiplexor module")
> > Reported-by: syzbot+b72d86aa5df17ce74c60@...kaller.appspotmail.com
> > Closes: https://syzkaller.appspot.com/bug?extid=b72d86aa5df17ce74c60
> > Tested-by: syzbot+b72d86aa5df17ce74c60@...kaller.appspotmail.com
> > Signed-off-by: Kuniyuki Iwashima <kuniyu@...zon.com>
> > ---
>
> Reviewed-by: Eric Dumazet <edumazet@...gle.com>
>
> I wonder if anyone is using KCM....
Same impression :)
Maybe it's time to remove KCM.
https://lore.kernel.org/netdev/CALx6S37hSfQWw3Rku8vsavn8ejk0fndRk+=-=73gU7G-RbnK8Q@mail.gmail.com/
Powered by blists - more mailing lists