[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y1wsh66c7693OV/D@pop-os.localdomain>
Date: Fri, 28 Oct 2022 12:24:55 -0700
From: Cong Wang <xiyou.wangcong@...il.com>
To: Eric Dumazet <edumazet@...gle.com>
Cc: Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
Cong Wang <cong.wang@...edance.com>,
shaozhengchao <shaozhengchao@...wei.com>,
Paolo Abeni <pabeni@...hat.com>,
Tom Herbert <tom@...bertland.com>
Subject: Re: [Patch net] kcm: fix a race condition in kcm_recvmsg()
On Tue, Oct 25, 2022 at 04:49:48PM -0700, Eric Dumazet wrote:
> On Tue, Oct 25, 2022 at 4:02 PM Jakub Kicinski <kuba@...nel.org> wrote:
> >
> > On Sat, 22 Oct 2022 19:30:44 -0700 Cong Wang wrote:
> > > + spin_lock_bh(&mux->rx_lock);
> > > KCM_STATS_INCR(kcm->stats.rx_msgs);
> > > skb_unlink(skb, &sk->sk_receive_queue);
> > > + spin_unlock_bh(&mux->rx_lock);
> >
> > Why not switch to __skb_unlink() at the same time?
> > Abundance of caution?
> >
> > Adding Eric who was fixing KCM bugs recently.
>
> I think kcm_queue_rcv_skb() might have a similar problem if/when
> called from requeue_rx_msgs()
>
> (The mux->rx_lock spinlock is not acquired, and skb_queue_tail() is used)
rx_lock is acquired at least by 2 callers of it, requeue_rx_msgs() and
kcm_rcv_ready(). kcm_rcv_strparser() seems missing it, I can fix this in
a separate patch as no one actually reported a bug.
Thanks.
Powered by blists - more mailing lists