From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-124.freemail.mail.aliyun.com (out30-124.freemail.mail.aliyun.com [115.124.30.124]) (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 868833BBFC2; Tue, 28 Jul 2026 09:54:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785232481; cv=none; b=ZDLmYCIrFAcIptWGfPAzmN4eiVqvNp/JKdC0SWlw5x8buH6iaHY8zGhJQdPgo4GkeOwe8j4IeOzgk9myPzZT7j7MEMNR16tdIT3wKNMuNzw3MWuQJKgjKNrO/zGV7o+k4fXvZAtQqtJi4JrwjtJt2FGk/UwitV/Sj/g79pfVxp0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785232481; c=relaxed/simple; bh=Sym6R+pWGQYYnF1PwB6i5riKZG2OxVHFnwJ8kF6S7Os=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=Q16cRP6gdd5474XUeCTPDQULdXkVIIxYGpLPSn6qMN7rCsuQThCDG/VDMT+7Zvr5DpPmJmJ6RhR5jaKcRpnzEbB9k8Y8bo+yExXaEG0wFdez6N2UKF1e3DT+EK+SQBg1NNaFv8UaMFDNpWEvbAI33vOiK9LyOCYj55T/ByHdObM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=ZYCTh1R5; arc=none smtp.client-ip=115.124.30.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="ZYCTh1R5" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1785232476; h=From:To:Subject:Date:Message-Id:MIME-Version; bh=islHuHQp3l4QW4GhF2VCHhIeu8amLI+tOc68Hlm4av0=; b=ZYCTh1R5yDbD14ZT/ULpR3MmqimdIZKzJ7X+gvXVmmSBrULwf9dydbqRwwis4mtF51Jp2e+xFJcK6EWGARhBY+O4/ikxTKYgyMXSceKn3Q85M6qwwYeoHOcrgzBUirYetWgJZEHVZwBrnxrNiZxCY6OcslEjgKPdBof3RoH6Sgo= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R991e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033045133197;MF=lulie@linux.alibaba.com;NM=1;PH=DS;RN=20;SR=0;TI=SMTPD_---0X8-NTRh_1785232475; Received: from localhost(mailfrom:lulie@linux.alibaba.com fp:SMTPD_---0X8-NTRh_1785232475 cluster:ay36) by smtp.aliyun-inc.com; Tue, 28 Jul 2026 17:54:35 +0800 From: Philo Lu To: stable@vger.kernel.org Cc: daniel@iogearbox.net, info@starlabs.sg, ast@kernel.org, lulie@linux.alibaba.com, john.fastabend@gmail.com, andrii@kernel.org, martin.lau@linux.dev, song@kernel.org, yonghong.song@linux.dev, kpsingh@kernel.org, sdf@google.com, haoluo@google.com, jolsa@kernel.org, bpf@vger.kernel.org, linux-kernel@vger.kernel.org, mykolal@fb.com, shuah@kernel.org, linux-kselftest@vger.kernel.org, dust.li@linux.alibaba.com Subject: [PATCH 5.10.y/5.15.y] bpf: Fix ld_{abs,ind} failure path analysis in subprogs Date: Tue, 28 Jul 2026 17:54:34 +0800 Message-Id: <20260728095435.115338-1-lulie@linux.alibaba.com> X-Mailer: git-send-email 2.32.0.3.g01195cf9f Precedence: bulk X-Mailing-List: bpf@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Daniel Borkmann commit ee861486e377edc55361c08dcbceab3f6b6577bd upstream. Usage of ld_{abs,ind} instructions got extended into subprogs some time ago via commit 09b28d76eac4 ("bpf: Add abnormal return checks."). These are only allowed in subprograms when the latter are BTF annotated and have scalar return types. The code generator in bpf_gen_ld_abs() has an abnormal exit path (r0=0 + exit) from legacy cBPF times. While the enforcement is on scalar return types, the verifier must also simulate the path of abnormal exit if the packet data load via ld_{abs,ind} failed. This is currently not the case. Fix it by having the verifier simulate both success and failure paths, and extend it in similar ways as we do for tail calls. The success path (r0=unknown, continue to next insn) is pushed onto stack for later validation and the r0=0 and return to the caller is done on the fall-through side. Fixes: 09b28d76eac4 ("bpf: Add abnormal return checks.") Reported-by: STAR Labs SG Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/r/20260408191242.526279-2-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov [ Dropped visit_abnormal_return_insn changes: depends on 7.0 symbols from e40f5a6bf88a ("bpf: correct stack liveness for tail calls"); Hunk1: adapted IS_ERR/PTR_ERR to !branch/-EFAULT to match push_stack() NULL-on-failure convention; Dropped mark_reg_scratched(), which only affects log verbosity, introduced by 0f55f9ed21f9 ("bpf: Only print scratched registers and stack slots to verifier logs.").] Signed-off-by: Philo Lu --- kernel/bpf/verifier.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c index ec447854f5345..5e71d58e4a300 100644 --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -9644,6 +9644,22 @@ static int check_ld_abs(struct bpf_verifier_env *env, struct bpf_insn *insn) mark_reg_unknown(env, regs, BPF_REG_0); /* ld_abs load up to 32-bit skb data. */ regs[BPF_REG_0].subreg_def = env->insn_idx + 1; + /* + * See bpf_gen_ld_abs() which emits a hidden BPF_EXIT with r0=0 + * which must be explored by the verifier when in a subprog. + */ + if (env->cur_state->curframe) { + struct bpf_verifier_state *branch; + + branch = push_stack(env, env->insn_idx + 1, env->insn_idx, false); + if (!branch) + return -EFAULT; + mark_reg_known_zero(env, regs, BPF_REG_0); + err = prepare_func_exit(env, &env->insn_idx); + if (err) + return err; + env->insn_idx--; + } return 0; } -- 2.47.3