Re: [PATCH net 2/2] tcp_bpf: fix copied value in tcp_bpf_sendmsg

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

 



On 2024-12-09 15:02, John Fastabend wrote:
Levi Zim via B4 Relay wrote:
From: Levi Zim <rsworktech@xxxxxxxxxxx>

bpf kselftest sockhash::test_txmsg_cork_hangs in test_sockmap.c triggers a
kernel NULL pointer dereference:
Is it just the cork test that causes issue?
Yes. More specifically only "sockhash::test_txmsg_cork_hangs" but not "sockmap::test_txmsg_cork_hangs"

BUG: kernel NULL pointer dereference, address: 0000000000000008
  ? __die_body+0x6e/0xb0
  ? __die+0x8b/0xa0
  ? page_fault_oops+0x358/0x3c0
  ? local_clock+0x19/0x30
  ? lock_release+0x11b/0x440
  ? kernelmode_fixup_or_oops+0x54/0x60
  ? __bad_area_nosemaphore+0x4f/0x210
  ? mmap_read_unlock+0x13/0x30
  ? bad_area_nosemaphore+0x16/0x20
  ? do_user_addr_fault+0x6fd/0x740
  ? prb_read_valid+0x1d/0x30
  ? exc_page_fault+0x55/0xd0
  ? asm_exc_page_fault+0x2b/0x30
  ? splice_to_socket+0x52e/0x630
  ? shmem_file_splice_read+0x2b1/0x310
  direct_splice_actor+0x47/0x70
  splice_direct_to_actor+0x133/0x300
  ? do_splice_direct+0x90/0x90
  do_splice_direct+0x64/0x90
  ? __ia32_sys_tee+0x30/0x30
  do_sendfile+0x214/0x300
  __se_sys_sendfile64+0x8e/0xb0
  __x64_sys_sendfile64+0x25/0x30
  x64_sys_call+0xb82/0x2840
  do_syscall_64+0x75/0x110
  entry_SYSCALL_64_after_hwframe+0x4b/0x53

This is caused by tcp_bpf_sendmsg() returning a larger value(12289) than
size (8192), which causes the while loop in splice_to_socket() to release
an uninitialized pipe buf.

The underlying cause is that this code assumes sk_msg_memcopy_from_iter()
will copy all bytes upon success but it actually might only copy part of
it.
The intent was to ensure we allocate a buffer large enough to fit the
data. I guess the cork + send here is not allocating enough bytes?
I am not familiar enough with neither this part of code nor tcp with bpf in general and just hit this bug when trying to run the bpf kselftests. Then I decided to debug it.

In my perspective the buffer(8192) is large enough to hold the data(8192),
but tcp_bpf_sendmsg returns 12289 which is a little surprising for me.

Could you further elaborate why 8192 bytes are not enough? Thanks!

This commit changes it to use the real copied bytes.

Signed-off-by: Levi Zim <rsworktech@xxxxxxxxxxx>
---
  net/ipv4/tcp_bpf.c | 8 ++++----
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/net/ipv4/tcp_bpf.c b/net/ipv4/tcp_bpf.c
index 370993c03d31363c0f82a003d9e5b0ca3bbed721..8e46c4d618cbbff0d120fe4cd917624e5d5cae15 100644
--- a/net/ipv4/tcp_bpf.c
+++ b/net/ipv4/tcp_bpf.c
@@ -496,7 +496,7 @@ static int tcp_bpf_send_verdict(struct sock *sk, struct sk_psock *psock,
  static int tcp_bpf_sendmsg(struct sock *sk, struct msghdr *msg, size_t size)
  {
  	struct sk_msg tmp, *msg_tx = NULL;
-	int copied = 0, err = 0;
+	int copied = 0, err = 0, ret = 0;
  	struct sk_psock *psock;
  	long timeo;
  	int flags;
@@ -539,14 +539,14 @@ static int tcp_bpf_sendmsg(struct sock *sk, struct msghdr *msg, size_t size)
  			copy = msg_tx->sg.size - osize;
  		}
- err = sk_msg_memcopy_from_iter(sk, &msg->msg_iter, msg_tx,
+		ret = sk_msg_memcopy_from_iter(sk, &msg->msg_iter, msg_tx,
  					       copy);
-		if (err < 0) {
+		if (ret < 0) {
  			sk_msg_trim(sk, msg_tx, osize);
  			goto out_err;
  		}
- copied += copy;
+		copied += ret;
  		if (psock->cork_bytes) {
  			if (size > psock->cork_bytes)
  				psock->cork_bytes = 0;

--
2.47.1







[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux