BPF List
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Chengfeng Ye" <nicoyip.dev@gmail.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH] bpf, sockmap: Fix cork use-after-free in tcp_bpf_sendmsg()
Date: Mon, 20 Jul 2026 16:17:02 +0000	[thread overview]
Message-ID: <20260720161702.E934F1F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260719161630.2901208-1-nicoyip.dev@gmail.com>

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:

Pre-existing issues:
- [High] Memory leak of stack-allocated `tmp` scatterlist pages when aborting via `goto out_err`.
- [High] Lost error code from `sk_msg_memcopy_from_iter` causes sendmsg to incorrectly return 0 instead of propagating -EFAULT.
- [High] Silent data loss on `__SK_REDIRECT` failure for corked messages due to masked error.
- [Medium] Overlapping `memcpy()` when corking an already-corked message.
--

--- Patch [1]: [PATCH] bpf, sockmap: Fix cork use-after-free in tcp_bpf_sendmsg() ---
commit ef0d38759a207a519b5d12273a55446155a7d5f4
Author: Chengfeng Ye <nicoyip.dev@gmail.com>

bpf, sockmap: Fix cork use-after-free in tcp_bpf_sendmsg()

tcp_bpf_sendmsg() keeps msg_tx across sk_stream_wait_memory(), which drops
and reacquires the socket lock. This commit fixes a use-after-free where a
stale cork could be mistaken for the local temporary message and freed again.
It tests for tmp directly instead of comparing with psock->cork.

> diff --git a/net/ipv4/tcp_bpf.c b/net/ipv4/tcp_bpf.c
> index cc0bd73f36b6d..b9f0366333653 100644
> --- a/net/ipv4/tcp_bpf.c
> +++ b/net/ipv4/tcp_bpf.c
> @@ -589,7 +589,7 @@ static int tcp_bpf_sendmsg(struct sock *sk, struct msghdr *msg, size_t size)
>  wait_for_memory:
>  		err = sk_stream_wait_memory(sk, &timeo);
>  		if (err) {
> -			if (msg_tx && msg_tx != psock->cork)
> +			if (msg_tx == &tmp)
>  				sk_msg_free(sk, msg_tx);

[Severity: High]
This isn't a bug introduced by this patch, but can this leak page references
or memory for the stack-allocated tmp?

If kzalloc_obj() for psock->cork fails in tcp_bpf_send_verdict(), returning
-ENOMEM but leaving psock->cork_bytes > 0, and userspace retries sendmsg(),
msg_tx defaults to the stack-allocated &tmp.

Data is copied into tmp, allocating pages. The code then hits:
if (psock->cork_bytes && !enospc)
    goto out_err;

And the out_err block returns without freeing tmp. Unprivileged userspace
could repeatedly trigger this state after a single induced -ENOMEM, leaking
pages on subsequent small sendmsg() calls.

>  			goto out_err;

[Severity: High]
This is a pre-existing issue, but does this goto out_err drop the
error code from sk_msg_memcopy_from_iter()?

Earlier in tcp_bpf_sendmsg():
ret = sk_msg_memcopy_from_iter(sk, &msg->msg_iter, msg_tx, copy);
if (ret < 0) {
    sk_msg_trim(sk, msg_tx, osize);
    goto out_err;
}

The out_err block returns err (which is initialized to 0), rather than ret.
If a local user passes a bad pointer, it will get a 0 return value instead
of -EFAULT, which usually causes userspace blocking socket writes to spin
endlessly.

>  		}

[Severity: Medium]
This isn't a bug introduced by this patch, but does tcp_bpf_send_verdict()
trigger an overlapping memory copy?

If a BPF program evaluates an already-corked message and assigns a new
cork_bytes threshold that exceeds the current size, tcp_bpf_send_verdict()
executes:

memcpy(psock->cork, msg, sizeof(*msg));

If msg is identical to psock->cork, this results in an overlapping memory
copy onto itself. This can violate the C standard and trigger UBSAN panics.

[Severity: High]
This is a pre-existing issue, but does tcp_bpf_send_verdict() silently
drop data on __SK_REDIRECT failure for corked messages?

If a redirected message is corked and tcp_bpf_sendmsg_redir() fails, the
code frees the message:

if (cork) {
    sk_msg_free(sk, msg);
    kfree(msg);
    msg = NULL;
    ret = 0;
}

This intentionally skips subtracting the freed bytes from *copied and
overwrites ret = 0. This causes tcp_bpf_sendmsg() to assume success,
continue processing the user's buffer, and return a positive byte count
to userspace despite dropping the corked data.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260719161630.2901208-1-nicoyip.dev@gmail.com?part=1

  reply	other threads:[~2026-07-20 16:17 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-19 16:16 [PATCH] bpf, sockmap: Fix cork use-after-free in tcp_bpf_sendmsg() Chengfeng Ye
2026-07-20 16:17 ` sashiko-bot [this message]
2026-07-20 20:12 ` Emil Tsalapatis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260720161702.E934F1F00A3A@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=nicoyip.dev@gmail.com \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox