From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-186.mta1.migadu.com (out-186.mta1.migadu.com [95.215.58.186]) (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 C659D35202C for ; Fri, 19 Jun 2026 06:35:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.186 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781850934; cv=none; b=fty6PUQpKhfda58VCUkLLKfmjJjkbEHPO8iVHZY7KbY2t7ysxl7p0m6296BcRHcZI/cmKF5SX7qEiOMg8Sp4+351A5GpBThxMI0Ed/qEL0OsmXHxNBzyLKt0qWQWQPfSZE3q0EPgUEcoR/syi+H0W8T4raG49pkZjaZFChPENfU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781850934; c=relaxed/simple; bh=RNjabRwXK1Z7FZ9lk2kM6y2NStALK3Vm+iaCUMQeBWE=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=DgfTTfh9Gg4wDtgg10dcCkkggNyj4YQvxAXJinTkRjkvD/aUpkVuckBCn59G1QUqeWum2JFToSlGwMaLBM710dGmD0WuCuWVnLyDqWIbwYQwmKioe2YA4mQnGseYN28P9QnTN/uS0qEa/EgtsXQ53cdPQQvG0NxSSjl//RDnKyU= 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=J4eR327p; arc=none smtp.client-ip=95.215.58.186 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="J4eR327p" Message-ID: <28f794e5-2fe8-4594-a19c-d4c936350cb5@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1781850930; 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=Vw5G3TGXS5qxXLkjU6JHXsllZyv22COyQsCV1sVQgss=; b=J4eR327paA+7AvoqSL7vpQ3TXaGM0kVFEpRCU5gyUrEK1Ytj+yBIAM5KhgKBdNXh1jBH4g zI1Gf7J23TZFCy5ir2QTywJ1WW895bSEuNw4GI+1iGnSiUhmY1vixlSBgntAyJRXFUr7IX X+8uKsRA3MyoZOA/8qzCT6reRSLBIJQ= Date: Fri, 19 Jun 2026 14:35:20 +0800 Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH bpf v4 2/3] bpf, sockmap: reject a packet-modifying SK_SKB stream parser To: Sechang Lim , Alexei Starovoitov , Andrii Nakryiko , Daniel Borkmann , Eduard Zingerman , Kumar Kartikeya Dwivedi , John Fastabend , Jakub Sitnicki , "David S . Miller" , Jakub Kicinski , Eric Dumazet , Paolo Abeni , Kuniyuki Iwashima , Willem de Bruijn , Shuah Khan Cc: Jiri Olsa , Martin KaFai Lau , Song Liu , Yonghong Song , Simon Horman , Bobby Eshleman , Jiayuan Chen , bpf@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org References: <20260619062959.3277612-1-rhkrqnwk98@gmail.com> <20260619062959.3277612-3-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: <20260619062959.3277612-3-rhkrqnwk98@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT On 6/19/26 2:29 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); > > The parser is only meant to inspect the skb, but the program may call > bpf_skb_change_tail() -- or the sibling bpf_skb_pull_data(), > bpf_skb_change_head(), bpf_skb_adjust_room(), all allowed for SK_SKB. > Once the head carries a frag_list these go > > ... -> skb_ensure_writable -> pskb_may_pull -> __pskb_pull_tail > > and __pskb_pull_tail() frees the frag_list skbs that strparser still > tracks through skb_nextp: > > while ((list = skb_shinfo(skb)->frag_list) != insp) { > skb_shinfo(skb)->frag_list = list->next; > consume_skb(list); > } > > strp->skb_nextp now points into a freed sk_buff. The next segment of > the same message arrives in __strp_recv(), which links it with > *strp->skb_nextp = skb, an 8-byte write into the freed skb. The free > and the write happen in different __strp_recv() calls, so the message > has to span at least three segments before it triggers. > > BUG: KASAN: slab-use-after-free in __strp_recv+0x447/0xda0 > Write of size 8 at addr ffff88810db86140 by task repro/349 > > Call Trace: > > __strp_recv+0x447/0xda0 > __tcp_read_sock+0x13d/0x590 > tcp_bpf_strp_read_sock+0x195/0x320 > strp_data_ready+0x267/0x340 > sk_psock_strp_data_ready+0x1ce/0x350 > tcp_data_queue+0x1364/0x2fd0 > tcp_rcv_established+0xe07/0x1640 > [...] > > Allocated by task 349: > skb_clone+0x17b/0x210 > __strp_recv+0x2c3/0xda0 > __tcp_read_sock+0x13d/0x590 > [...] > > Freed by task 349: > kmem_cache_free+0x150/0x570 > __pskb_pull_tail+0x57b/0xc20 > skb_ensure_writable+0x236/0x260 > __bpf_skb_change_tail+0x1d4/0x590 > sk_skb_change_tail+0x2a/0x40 > bpf_prog_1b285dcd6c41373e+0x27/0x30 > bpf_prog_run_pin_on_cpu+0xf3/0x260 > sk_psock_strp_parse+0x118/0x1e0 > __strp_recv+0x4f6/0xda0 > [...] > > The same resize also leaves the head's length inconsistent with its > frags, so a later __pskb_pull_tail() can instead hit the > BUG_ON(skb_copy_bits(...)) in net/core/skbuff.c. > > A stream parser is only meant to measure the next message, not to modify > the packet. Reject a parser whose program can change packet data > (prog->aux->changes_pkt_data) at attach time. The check is shared by > sock_map_prog_update() and sock_map_link_update_prog(), which between them > cover prog attach, link create and link update. Verdict programs are > unaffected and may still modify the skb. > > Signed-off-by: Sechang Lim Reviewed-by: Jiayuan Chen