From: "Alexei Starovoitov" <alexei.starovoitov@gmail.com>
To: <sashiko-reviews@lists.linux.dev>, <bpf@vger.kernel.org>
Subject: Re: [PATCH bpf-next v3 11/16] bpf: Refuse the prologue for an extension that cannot take it
Date: Sun, 18 Oct 2026 00:35:15 +0000 [thread overview]
Message-ID: <DM7JJW2KF0F9.20SESIVIYNMYU@gmail.com> (raw)
In-Reply-To: <sashiko-outbox-175849@kernel.org>
On Sat, Oct 17, 2026 at 04:29 PM sashiko-bot@kernel.org <sashiko-bot@kernel.org> wrote:
> Could this cause a use-after-free in the caller after the extension returns,
Yes, for a target that only reads the packet. It's an old bug, not from
this patch. Reproduced on bpf-next without the series:
BUG: KASAN: slab-use-after-free in bpf_prog_769e8c14b3a52c7a_t_read+0x386/0x404
Read of size 1 at addr ffff888104c61e3c by task tt11/102
Freed by task 113:
kfree+0x161/0x500
skb_release_data+0x2dc/0x340
consume_skb+0xa6/0x1c0
packet_recvmsg+0x4b3/0xa20
Two corrections though:
> skb_ensure_writable() -> pskb_expand_head(), which reallocates and frees
> skb->head while the caller still holds pointers into the old skb->head.
For a cloned skb it only drops a reference. The old head goes when the
other clone is freed, so another cpu has to do that while the caller is
still running. And the caller can only read: a target that writes
to the packet has its own prologue.
> If the target tc, lwt_xmit, or sk_skb program only reads packet data (or
> clones the skb via bpf_clone_redirect() and reloads skb->data) and calls a
bpf_clone_redirect() unclones the skb before it returns.
> and should an extension receiving a prologue also require the target function
> to have changes_pkt_data set (and set prog->aux->changes_pkt_data for
> subsequent BPF_LINK_CREATE attachments)?
That alone is too strict. It would refuse
freplace/test_pkt_write_access_subprog in fexit_bpf2bpf, which is fine:
the target writes to the packet, so the skb is uncloned at entry and
the prologue of the extension does nothing.
Will send a follow-up: refuse such an extension unless the target function
changes packet data or the target prog has the prologue, at load
and at BPF_LINK_CREATE.
next prev parent reply other threads:[~2026-10-18 0:35 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-17 23:09 [PATCH bpf-next v3 00/16] bpf: Memory safety, lifetime and locking fixes (followups) Alexei Starovoitov
2026-10-17 23:09 ` [PATCH bpf-next v3 01/16] bpf: Don't take a program with a target program for an iterator Alexei Starovoitov
2026-10-17 23:09 ` [PATCH bpf-next v3 02/16] bpf: Don't let an extension reach further into the context than its target Alexei Starovoitov
2026-10-17 23:09 ` [PATCH bpf-next v3 03/16] bpf: Keep values of a dead owner for sleepable programs Alexei Starovoitov
2026-10-17 23:09 ` [PATCH bpf-next v3 04/16] bpf: Don't take an extension for a function that runs sleepable Alexei Starovoitov
2026-10-17 23:09 ` [PATCH bpf-next v3 05/16] bpf: Keep the symbols of a program until it has ended Alexei Starovoitov
2026-10-17 23:09 ` [PATCH bpf-next v3 06/16] bpf: Use the socket of a sk_lookup test run under RCU Alexei Starovoitov
2026-10-17 23:09 ` [PATCH bpf-next v3 07/16] bpf, cpumap: Hold the device of frames in the queue Alexei Starovoitov
2026-10-17 23:09 ` [PATCH bpf-next v3 08/16] bpf: Drop packet pointers behind kfuncs writing an skb Alexei Starovoitov
2026-10-17 23:09 ` [PATCH bpf-next v3 09/16] bpf: Let bpf_dynptr_write() mark a global function Alexei Starovoitov
2026-10-17 23:09 ` [PATCH bpf-next v3 10/16] bpf: Don't take a dynptr argument for a local dynptr Alexei Starovoitov
2026-10-17 23:09 ` [PATCH bpf-next v3 11/16] bpf: Refuse the prologue for an extension that cannot take it Alexei Starovoitov
2026-10-17 23:29 ` sashiko-bot
2026-10-18 0:35 ` Alexei Starovoitov [this message]
2026-10-17 23:41 ` bot+bpf-ci
2026-10-17 23:09 ` [PATCH bpf-next v3 12/16] bpf: Unclone the skb for kfuncs that write through a dynptr Alexei Starovoitov
2026-10-17 23:09 ` [PATCH bpf-next v3 13/16] bpf: Follow the head if an skb is written from a slice Alexei Starovoitov
2026-10-17 23:09 ` [PATCH bpf-next v3 14/16] bpf: Use memmove() to store bytes in an skb Alexei Starovoitov
2026-10-17 23:09 ` [PATCH bpf-next v3 15/16] bpf: Use memmove() to store bytes in an xdp_buff Alexei Starovoitov
2026-10-17 23:09 ` [PATCH bpf-next v3 16/16] bpf: Refuse packet slices for packet-changing helpers Alexei Starovoitov
2026-10-18 0:50 ` [PATCH bpf-next v3 00/16] bpf: Memory safety, lifetime and locking fixes (followups) patchwork-bot+netdevbpf
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=DM7JJW2KF0F9.20SESIVIYNMYU@gmail.com \
--to=alexei.starovoitov@gmail.com \
--cc=bpf@vger.kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.