The Linux Kernel Mailing List
 help / color / mirror / Atom feed
* [PATCH v2] bpf: fix filed access without lock
  2024-10-21  1:37 [PATCH] " mrpre
@ 2024-10-28  6:23 ` mrpre
  0 siblings, 0 replies; 3+ messages in thread
From: mrpre @ 2024-10-28  6:23 UTC (permalink / raw)
  To: xiyou.wangcong
  Cc: edumazet, jakub, davem, dsahern, kuba, pabeni, netdev, bpf,
	linux-kernel, mrpre

The tcp_bpf_recvmsg_parser() function, running in user context,
retrieves seq_copied from tcp_sk without holding the socket lock, and
stores it in a local variable seq. However, the softirq context can
modify tcp_sk->seq_copied concurrently, for example, n tcp_read_sock().

As a result, the seq value is stale when it is assigned back to
tcp_sk->copied_seq at the end of tcp_bpf_recvmsg_parser(), leading to
incorrect behavior.

Due to concurrency, the copied_seq field in tcp_bpf_recvmsg_parser()
might be set to an incorrect value (less than the actual copied_seq) at
the end of function: 'WRITE_ONCE(tcp->copied_seq, seq)'. This causes the
'offset' to be negative in tcp_read_sock()->tcp_recv_skb() when
processing new incoming packets (sk->copied_seq - skb->seq becomes less
than 0), and all subsequent packets will be dropped.

Signed-off-by: Jiayuan Chen <mrpre@163.com>
---
V1 -> V2: add more commit message to describle the issue
---
 net/ipv4/tcp_bpf.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/net/ipv4/tcp_bpf.c b/net/ipv4/tcp_bpf.c
index e7658c5d6b79..7b44d4ece8b2 100644
--- a/net/ipv4/tcp_bpf.c
+++ b/net/ipv4/tcp_bpf.c
@@ -221,9 +221,9 @@ static int tcp_bpf_recvmsg_parser(struct sock *sk,
 				  int flags,
 				  int *addr_len)
 {
-	struct tcp_sock *tcp = tcp_sk(sk);
+	struct tcp_sock *tcp;
+	u32 seq;
 	int peek = flags & MSG_PEEK;
-	u32 seq = tcp->copied_seq;
 	struct sk_psock *psock;
 	int copied = 0;
 
@@ -238,7 +238,8 @@ static int tcp_bpf_recvmsg_parser(struct sock *sk,
 		return tcp_recvmsg(sk, msg, len, flags, addr_len);
 
 	lock_sock(sk);
-
+	tcp = tcp_sk(sk);
+	seq = tcp->copied_seq;
 	/* We may have received data on the sk_receive_queue pre-accept and
 	 * then we can not use read_skb in this context because we haven't
 	 * assigned a sk_socket yet so have no link to the ops. The work-around
-- 
2.43.5


^ permalink raw reply related	[flat|nested] 3+ messages in thread

* [PATCH v2] bpf: fix filed access without lock
@ 2024-10-28  6:52 mrpre
  2024-10-29 17:50 ` patchwork-bot+netdevbpf
  0 siblings, 1 reply; 3+ messages in thread
From: mrpre @ 2024-10-28  6:52 UTC (permalink / raw)
  To: xiyou.wangcong
  Cc: yonghong.song, john.fastabend, edumazet, jakub, davem, dsahern,
	kuba, pabeni, netdev, bpf, linux-kernel, mrpre

The tcp_bpf_recvmsg_parser() function, running in user context,
retrieves seq_copied from tcp_sk without holding the socket lock, and
stores it in a local variable seq. However, the softirq context can
modify tcp_sk->seq_copied concurrently, for example, n tcp_read_sock().

As a result, the seq value is stale when it is assigned back to
tcp_sk->copied_seq at the end of tcp_bpf_recvmsg_parser(), leading to
incorrect behavior.

Due to concurrency, the copied_seq field in tcp_bpf_recvmsg_parser()
might be set to an incorrect value (less than the actual copied_seq) at
the end of function: 'WRITE_ONCE(tcp->copied_seq, seq)'. This causes the
'offset' to be negative in tcp_read_sock()->tcp_recv_skb() when
processing new incoming packets (sk->copied_seq - skb->seq becomes less
than 0), and all subsequent packets will be dropped.

Signed-off-by: Jiayuan Chen <mrpre@163.com>
---
v1 -> v2: add more commit message to describle the issue
          v1: https://lore.kernel.org/bpf/Zx1S9vf2i7O+BNE+@pop-os.localdomain/T/
---
 net/ipv4/tcp_bpf.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/net/ipv4/tcp_bpf.c b/net/ipv4/tcp_bpf.c
index e7658c5d6b79..7b44d4ece8b2 100644
--- a/net/ipv4/tcp_bpf.c
+++ b/net/ipv4/tcp_bpf.c
@@ -221,9 +221,9 @@ static int tcp_bpf_recvmsg_parser(struct sock *sk,
 				  int flags,
 				  int *addr_len)
 {
-	struct tcp_sock *tcp = tcp_sk(sk);
+	struct tcp_sock *tcp;
+	u32 seq;
 	int peek = flags & MSG_PEEK;
-	u32 seq = tcp->copied_seq;
 	struct sk_psock *psock;
 	int copied = 0;
 
@@ -238,7 +238,8 @@ static int tcp_bpf_recvmsg_parser(struct sock *sk,
 		return tcp_recvmsg(sk, msg, len, flags, addr_len);
 
 	lock_sock(sk);
-
+	tcp = tcp_sk(sk);
+	seq = tcp->copied_seq;
 	/* We may have received data on the sk_receive_queue pre-accept and
 	 * then we can not use read_skb in this context because we haven't
 	 * assigned a sk_socket yet so have no link to the ops. The work-around
-- 
2.43.5


^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [PATCH v2] bpf: fix filed access without lock
  2024-10-28  6:52 [PATCH v2] bpf: fix filed access without lock mrpre
@ 2024-10-29 17:50 ` patchwork-bot+netdevbpf
  0 siblings, 0 replies; 3+ messages in thread
From: patchwork-bot+netdevbpf @ 2024-10-29 17:50 UTC (permalink / raw)
  To: mrpre
  Cc: xiyou.wangcong, yonghong.song, john.fastabend, edumazet, jakub,
	davem, dsahern, kuba, pabeni, netdev, bpf, linux-kernel

Hello:

This patch was applied to bpf/bpf.git (master)
by Martin KaFai Lau <martin.lau@kernel.org>:

On Mon, 28 Oct 2024 14:52:26 +0800 you wrote:
> The tcp_bpf_recvmsg_parser() function, running in user context,
> retrieves seq_copied from tcp_sk without holding the socket lock, and
> stores it in a local variable seq. However, the softirq context can
> modify tcp_sk->seq_copied concurrently, for example, n tcp_read_sock().
> 
> As a result, the seq value is stale when it is assigned back to
> tcp_sk->copied_seq at the end of tcp_bpf_recvmsg_parser(), leading to
> incorrect behavior.
> 
> [...]

Here is the summary with links:
  - [v2] bpf: fix filed access without lock
    https://git.kernel.org/bpf/bpf/c/2ce9abd6e1e1

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html



^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2024-10-29 17:50 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-10-28  6:52 [PATCH v2] bpf: fix filed access without lock mrpre
2024-10-29 17:50 ` patchwork-bot+netdevbpf
  -- strict thread matches above, loose matches on Subject: below --
2024-10-21  1:37 [PATCH] " mrpre
2024-10-28  6:23 ` [PATCH v2] " mrpre

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox