From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ot1-f47.google.com (mail-ot1-f47.google.com [209.85.210.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BF16A3DE45A for ; Tue, 16 Jun 2026 19:36:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.47 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781638598; cv=none; b=uW1Ji45ZVajHlqV/nq/tf5H6fqQ3C+lmnfrqR8s237wGy1TbDEo1wo4YZWRZtOnsRIhVl2Dx3xlagzAJn0GvuRCNOv+vvJrrt0biaD40H77bC00PsIISuuFC6etYEvVAqsxPJBNXosZ3oxyOoruGFC1SIyC6iNuOel+C1J43lJI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781638598; c=relaxed/simple; bh=x4vuvjMjK3Siqy6TliGJe8+jhWlv6O6RxnFPsOmVF7A=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:Subject:From:To: References:In-Reply-To; b=e13aoDZZZvxoCUsGoi/K0Ggdh+H3MNUjwidJu8nJzjmY0dU2hZHCKi8e4jf6qquU481C4G7MuTLLY8MHbkCvAq/JjAbQMPMBoVvMMNLKEilLVsVkDsncqf8toEdYJghtfr+YF0w6lba8azZuhUn5BLtGuy/0MidtgAcRt0P7r74= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=GC8Anh5V; arc=none smtp.client-ip=209.85.210.47 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="GC8Anh5V" Received: by mail-ot1-f47.google.com with SMTP id 46e09a7af769-7e6b5737bb2so4284428a34.1 for ; Tue, 16 Jun 2026 12:36:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1781638596; x=1782243396; darn=vger.kernel.org; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-transfer-encoding:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=8EO/9z4OOJVGQlHYYaBZaNw8VQwWazXkqSJi3LxEM90=; b=GC8Anh5VfSrdFDAjBCA+t3VBlW9IQNj5CS2020mtctSOl0TPtqgqnGjyN+MItcjWCE R0j+pM5rZJAV44nYdGQv7jC3qjGRKFk5ryfZPJP6ggkny9bOvT5PsAWDBqNcZnOUDHzW 55at24VAlGj21mPIJaKOSHd4NigWRARptROZhFH3vPAFtWHmD3Dcc2orE/BzygvegpF8 MYKIXU7AGLmA1BXhbVVUIyvaoI5TvJOVe0/vMdnU4AZCkGAi3uDlSMlvfvJARjsCEL6h eT6d5OdfnVWITLk0Pho0d6JAb83fB8Ys9lco4IUXjCHAL6DfOFBC6BEmxTmI4sb3ZPRt MAjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781638596; x=1782243396; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-transfer-encoding:mime-version:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=8EO/9z4OOJVGQlHYYaBZaNw8VQwWazXkqSJi3LxEM90=; b=henmJjYAsdfNwlrudThskQm2mzh1I5rMxlb7wOruU4AZta5hOd8DQ3QKFW+Sf1badG g/vIGz3K+eCDNbBUdZvvDW3osKd8hk0leW7bUAng0U/T6xUaLdI3LE76WIlxQ9408HOl 9hrWn6+KDWwDtyzyuDwLzLbW+cdjJZF80zjuJGGpqhDvmFAaowCwAEkVQH2CcmmE9x/S SH2RidzPWTt24OKPsajgjx/Phoewvo5LdsK9C2Ue25QsU/uwKvp8jQcu161Z9k4gkBnq ddWh74cqbjgcI7ISsvOhW5XrTyOAK3SQcXa7psGJNdsFTNyEW6sWfY41PI1Mp8i6G5JB l01w== X-Forwarded-Encrypted: i=1; AFNElJ9yDXB6gKgjTM5O5NRhkwDoZpyk8vRuTSgOaNKInlBIDAB/URQKs1hZjWEC6lX7V8qFyjYTAFiB1BiGqSc=@vger.kernel.org X-Gm-Message-State: AOJu0YxPKyinLhyB38CDYjRVsDcJRF+Iw+7w4cOGJWIrGcXV36LHp2ux TSpnt2cVjFLYUMHkaOfESV9t/m2KZ7sHi6Ud+zHh4/61aRLrdFC6qCv0 X-Gm-Gg: Acq92OFIWmaJK4Nricv8BUQ2hViOglRK6FL2R9fbVvQlvXVjOvJcE/TPTzQ6swbMvAL obMxWvlBHzMIq2syLEq2UxSQzX8qvXEOOpSsO776Po46GA0qDtQI2GYgzS+085E84UEeu9ujTIe Ufz6swWkzJNx+8zI4Np4sdOw5ooPHalhXK6hyHK4OBLPRBNXD2jF2JoPZHnAxMgsglONDPptevB yeJ/lsBkH4fO6H7I311Dg2CKOpFarcNGvx5TH66Z27DWlKGR9WUpoxsskquytC53g8pbcPy6nK2 +ThChj1Z/Xua+QFj5xqG5osFU+0eSw1ur1JQ2NewTe5l1buvC7PXM3yCip49Tt59hYYdlrY9fqX 1REP8asWygrVPoafshhOAM4xyWol6LRqaiS7TlWt8vXPhA9JVdqir+vjdEVL7JekwmZpT6k/+VK dWrxhcV93CKFrnF93pjpdqsaz+ZpONUakO1XvuGbrjuI1I9RjQ4f3rBOaN1VC+2sOiyn/xuQz2Q r4WAg/PZR2qAZax9Q== X-Received: by 2002:a05:6808:1b28:b0:479:faf5:ef4c with SMTP id 5614622812f47-48944641750mr389992b6e.32.1781638595545; Tue, 16 Jun 2026 12:36:35 -0700 (PDT) Received: from localhost ([2a03:2880:10ff:53::]) by smtp.gmail.com with ESMTPSA id 5614622812f47-4875ddda6b6sm4881214b6e.8.2026.06.16.12.36.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 16 Jun 2026 12:36:34 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Tue, 16 Jun 2026 12:36:31 -0700 Message-Id: Cc: , , , , , , , , , , , , , , , , , , , , , , , Subject: Re: [PATCH bpf-next 1/2] bpf: Guard conntrack opts error writes From: "Alexei Starovoitov" To: "Yiyang Chen" , , X-Mailer: aerc References: <70aeec0ab762aebe65129cf6052e132c7329edc2.1781586477.git.chenyy23@mails.tsinghua.edu.cn> In-Reply-To: <70aeec0ab762aebe65129cf6052e132c7329edc2.1781586477.git.chenyy23@mails.tsinghua.edu.cn> On Mon Jun 15, 2026 at 10:42 PM PDT, Yiyang Chen wrote: > The conntrack lookup and allocation kfuncs take an opts pointer > together with an opts__sz argument. The verifier checks only the memory > range described by opts__sz, but the wrappers unconditionally write > opts->error whenever the internal lookup or allocation helper returns an > error. > > For an invalid size smaller than the end of opts->error, that write can > land outside the verifier-checked range. Keep returning NULL for invalid > arguments, but only report the error through opts->error when the > supplied size includes the field. > > This preserves error reporting for the supported 12-byte and 16-byte > layouts, and for other invalid sizes that still include opts->error. > > Fixes: b4c2b9593a1c ("net/netfilter: Add unstable CT lookup helpers for X= DP and TC-BPF") > Fixes: d7e79c97c00c ("net: netfilter: Add kfuncs to allocate and insert C= T") > Signed-off-by: Yiyang Chen > --- > net/netfilter/nf_conntrack_bpf.c | 17 +++++++++++++---- > 1 file changed, 13 insertions(+), 4 deletions(-) > > diff --git a/net/netfilter/nf_conntrack_bpf.c b/net/netfilter/nf_conntrac= k_bpf.c > index 40c261cd0af38..3c182024ec509 100644 > --- a/net/netfilter/nf_conntrack_bpf.c > +++ b/net/netfilter/nf_conntrack_bpf.c > @@ -65,6 +65,11 @@ enum { > NF_BPF_CT_OPTS_SZ =3D 16, > }; > =20 > +static bool bpf_ct_opts_has_error(u32 opts_len) > +{ > + return opts_len >=3D offsetofend(struct bpf_ct_opts, error); > +} > + > static int bpf_nf_ct_tuple_parse(struct bpf_sock_tuple *bpf_tuple, > u32 tuple_len, u8 protonum, u8 dir, > struct nf_conntrack_tuple *tuple) > @@ -298,7 +303,8 @@ bpf_xdp_ct_alloc(struct xdp_md *xdp_ctx, struct bpf_s= ock_tuple *bpf_tuple, > nfct =3D __bpf_nf_ct_alloc_entry(dev_net(ctx->rxq->dev), bpf_tuple, tup= le__sz, > opts, opts__sz, 10); > if (IS_ERR(nfct)) { > - opts->error =3D PTR_ERR(nfct); > + if (bpf_ct_opts_has_error(opts__sz)) > + opts->error =3D PTR_ERR(nfct); LLMs have no taste. Above two lines could have been one helper bpf_ct_opts_set_error(opts, opts__sz, PTR_ERR(nfct)); Or we can do a step further and simplify the code more. Turn this: if (IS_ERR(nfct)) { opts->error =3D PTR_ERR(nfct); return NULL; } return (struct nf_conn___init *)nfct; into: return (struct nf_conn___init *)bpf_ct_opts_result(opts, opts__sz, nfct)= ; static void *bpf_ct_opts_result(struct bpf_ct_opts *opts, u32 opts__sz, voi= d *ret) { if (!IS_ERR(ret)) return ret; if (opts__sz >=3D offsetofend(struct bpf_ct_opts, error)) opts->error =3D PTR_ERR(ret); return NULL; } This kind of small improvements should be obvious to any human developer. Please do NOT send us patches straight out of LLM. Review it first and think how to improve it. pw-bot: cr