[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z8DA8TqMEYNziiT9@pop-os.localdomain>
Date: Thu, 27 Feb 2025 11:45:53 -0800
From: Cong Wang <xiyou.wangcong@...il.com>
To: Jiayuan Chen <jiayuan.chen@...ux.dev>
Cc: cong.wang@...edance.com, john.fastabend@...il.com, jakub@...udflare.com,
davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
pabeni@...hat.com, horms@...nel.org, andrii@...nel.org,
eddyz87@...il.com, mykolal@...com, ast@...nel.org,
daniel@...earbox.net, martin.lau@...ux.dev, song@...nel.org,
yonghong.song@...ux.dev, kpsingh@...nel.org, sdf@...ichev.me,
haoluo@...gle.com, jolsa@...nel.org, shuah@...nel.org, mhal@...x.co,
sgarzare@...hat.com, netdev@...r.kernel.org, bpf@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org,
mrpre@....com,
syzbot+dd90a702f518e0eac072@...kaller.appspotmail.com
Subject: Re: [PATCH bpf-next v1 1/3] bpf, sockmap: avoid using sk_socket
after free
On Wed, Feb 26, 2025 at 09:22:40PM +0800, Jiayuan Chen wrote:
> Use RCU lock to protect sk_socket, preventing concurrent close and release
> by another thread.
>
> Because TCP/UDP are already within a relatively large critical section:
> '''
> ip_local_deliver_finish
> rcu_read_lock
> ip_protocol_deliver_rcu
> tcp_rcv/udp_rcv
> rcu_read_unlock
> '''
>
> Adding rcu_read_{un}lock() at the entrance and exit of sk_data_ready
> will not increase performance overhead.
>
> Reported-by: syzbot+dd90a702f518e0eac072@...kaller.appspotmail.com
> Closes: https://lore.kernel.org/bpf/6734c033.050a0220.2a2fcc.0015.GAE@google.com/
> Signed-off-by: Jiayuan Chen <jiayuan.chen@...ux.dev>
sock_def_readable() already acquires RCU read lock anyway.
Reviewed-by: Cong Wang <xiyou.wangcong@...il.com>
Thanks!
Powered by blists - more mailing lists