From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-172.mta0.migadu.com (out-172.mta0.migadu.com [91.218.175.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7911C3F23A3 for ; Thu, 18 Jun 2026 11:56:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781783820; cv=none; b=Wlp9S7mZ1UdM59QAk1DwOKQM09HxM7Une1K2iB+f53PoFR9XSPKa1oaomzL+ma8UWE7r25kZ25mGxFn6WMf8l2srpN+fGUZaeEqEPZ3MqfvaXX0MUv8k7vk+Az8zdRc6Oh8unE7zaxWtyWwJq3cUcTiAllEnXldF6aMeox8BNo4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781783820; c=relaxed/simple; bh=EmKLrmuw0L1SJA8xGx0is8Bar9U5MW7fs6K0yUE5+CQ=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=s4MKFrJEsILeQal3blZaJVRCvzEwlT1H08GE6rLfI6GYgFTbco6O33QdpFLBEwlO5y2nVVy3ZpHN1G4dcMzPT6DivoPa/dHjSkFlvbyyuhki/usTA7Z4E5IZgG8DLIu7hMBm5l9XUMzb4IUkFux7f1eiDPsjSmAgmsNRU8zks7o= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=b2kfGjID; arc=none smtp.client-ip=91.218.175.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="b2kfGjID" Message-ID: <34f330b8-60d2-4647-a6b4-a5b001c3715d@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1781783814; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=NIDgjJc0kDWVk21VQMDvaZz53upB9zqPpo8g1ntXG+I=; b=b2kfGjIDPXddkJPr1tI/nwGwhr8kHHcavSP+y/Rpez7K103Jrloy2+xgVctuso45fzDV/8 1hmzOfbHqTa21l0XQXO8QTBzXiICkx7Wh1jq/uy8yr3QvLJL7kJUz0rrniQFNyW4qDsFRj +LKi9n3VbYY4RyTbvnI+Wq1zQhgnX1A= Date: Thu, 18 Jun 2026 19:56:34 +0800 Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH bpf v3 1/2] bpf, sockmap: fix use-after-free when the stream parser resizes the skb To: John Fastabend Cc: netdev@vger.kernel.org, bpf@vger.kernel.org, linux-kernel@vger.kernel.org, Jakub Kicinski , Sechang Lim References: <20260618102718.2331468-1-rhkrqnwk98@gmail.com> <20260618102718.2331468-2-rhkrqnwk98@gmail.com> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Jiayuan Chen In-Reply-To: <20260618102718.2331468-2-rhkrqnwk98@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT On 6/18/26 6:27 PM, Sechang Lim wrote: > sk_psock_strp_parse() runs the BPF_PROG_TYPE_SK_SKB stream-parser program > to find the length of the next message. strparser assembles a message out > of several received skbs by chaining them onto the head's frag_list and > recording where to append the next one in strp->skb_nextp: > > *strp->skb_nextp = skb; > strp->skb_nextp = &skb->next; > > and then calls the parser on the head: > > len = (*strp->cb.parse_msg)(strp, head); [...] > unaffected and may still modify the skb. > > Fixes: 8a31db561566 ("bpf: add access to sock fields and pkt data from sk_skb programs") Is the Fixes tag correct ? Anyway, I don't think this patch is a fix; it's more of a hardening. So no Fixes tag needed, IMO. > Signed-off-by: Sechang Lim > --- > net/core/sock_map.c | 20 ++++++++++++++++++++ > 1 file changed, 20 insertions(+) > > diff --git a/net/core/sock_map.c b/net/core/sock_map.c > index 99e3789492a0..c60ba6d292f9 100644 > --- a/net/core/sock_map.c > +++ b/net/core/sock_map.c > @@ -1515,6 +1515,17 @@ static int sock_map_prog_link_lookup(struct bpf_map *map, struct bpf_prog ***ppr > return 0; > } > > +static int sock_map_prog_attach_check(enum bpf_attach_type attach_type, > + struct bpf_prog *prog) > +{ > + /* A stream parser must not modify the skb, only measure it. */ > + if (prog && attach_type == BPF_SK_SKB_STREAM_PARSER && > + prog->aux->changes_pkt_data) > + return -EINVAL; > + > + return 0; > +} > + > /* Handle the following four cases: > * prog_attach: prog != NULL, old == NULL, link == NULL > * prog_detach: prog == NULL, old != NULL, link == NULL > @@ -1533,6 +1544,10 @@ static int sock_map_prog_update(struct bpf_map *map, struct bpf_prog *prog, > if (ret) > return ret; > > + ret = sock_map_prog_attach_check(which, prog); > + if (ret) > + return ret; > + > /* for prog_attach/prog_detach/link_attach, return error if a bpf_link > * exists for that prog. > */ > @@ -1776,6 +1791,11 @@ static int sock_map_link_update_prog(struct bpf_link *link, > ret = -EINVAL; > goto out; > } > + > + ret = sock_map_prog_attach_check(link->attach_type, prog); > + if (ret) > + goto out; > + > if (!sockmap_link->map) { > ret = -ENOLINK; > goto out; CI failed: https://github.com/kernel-patches/bpf/actions/runs/27754218839/job/82113319982    Failed stream parser bpf prog attach Hi John I noticed that bpf_skb_pull_data was added to the skmsg test: https://github.com/torvalds/linux/commit/82a8616889d506cb690cfc0afb2ccadda120461d Can we drop bpf_skb_pull_data in parser prog(sockmap_parse_prog.c‎) ? And are there any scenarios where we need to modify skb len when using strparser ?