Patch "bpf: fix filed access without lock" has been added to the 6.11-stable tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This is a note to let you know that I've just added the patch titled

    bpf: fix filed access without lock

to the 6.11-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     bpf-fix-filed-access-without-lock.patch
and it can be found in the queue-6.11 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit d1544aa48a318cbfa0b3f03c128857a9aa0d82b1
Author: Jiayuan Chen <mrpre@xxxxxxx>
Date:   Mon Oct 28 14:52:26 2024 +0800

    bpf: fix filed access without lock
    
    [ Upstream commit a32aee8f0d987a7cba7fcc28002553361a392048 ]
    
    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@xxxxxxx>
    Link: https://lore.kernel.org/r/20241028065226.35568-1-mrpre@xxxxxxx
    Signed-off-by: Martin KaFai Lau <martin.lau@xxxxxxxxxx>
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/net/ipv4/tcp_bpf.c b/net/ipv4/tcp_bpf.c
index fe6178715ba05..915286c3615a2 100644
--- a/net/ipv4/tcp_bpf.c
+++ b/net/ipv4/tcp_bpf.c
@@ -221,11 +221,11 @@ static int tcp_bpf_recvmsg_parser(struct sock *sk,
 				  int flags,
 				  int *addr_len)
 {
-	struct tcp_sock *tcp = tcp_sk(sk);
 	int peek = flags & MSG_PEEK;
-	u32 seq = tcp->copied_seq;
 	struct sk_psock *psock;
+	struct tcp_sock *tcp;
 	int copied = 0;
+	u32 seq;
 
 	if (unlikely(flags & MSG_ERRQUEUE))
 		return inet_recv_error(sk, msg, len, addr_len);
@@ -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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux