From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dl1-f50.google.com (mail-dl1-f50.google.com [74.125.82.50]) (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 84FBD23B63E for ; Tue, 9 Jun 2026 01:00:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780966825; cv=none; b=JOty/MGD0nNKbdAv/10LSfhRAKuWncHR+8zjF6ViM+9nwr0KhK4PvR8SuMfXteOuLxAArguD3b1JyuTf15ILGqXU4AdYgFWQkrERZiFK2osIaeYCKcjgs/1pHhfIHgCnKLSZqhfa5nZex4sgCYbenoJHp1/3IbkBTZu3xVPTodA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780966825; c=relaxed/simple; bh=t5728f3Chfb/jjMBuAwjgeGcYpzLWw+39I0b3183X2c=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=atCFdHZZ6xvJYLtEnKxIt3w+zwweDGfQCzC5NhYl6X0Rhqv4d2xdGuyuvod0dZn5zdoLJ5Ozpq/HqtutnwZ5KV2uKrDbuEObTvwDO6hamUlc6wm52MP+TwHtuj2u2uW3JrOhQb49T4tWpzOo78W/I5zMcWVJl3IJCElb8KHZUQQ= 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=LTfLC0sP; arc=none smtp.client-ip=74.125.82.50 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="LTfLC0sP" Received: by mail-dl1-f50.google.com with SMTP id a92af1059eb24-13807d2f898so3833389c88.0 for ; Mon, 08 Jun 2026 18:00:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780966821; x=1781571621; darn=vger.kernel.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=OQBrQS5EmHHWgpL0VJev95gvg3IajG0SEO/xcU/cGJM=; b=LTfLC0sPCvtsURkinAIZEheNzDOF96RrmY8WLy5Vi2IsBQ5eimZ8hzfDScd4vgmdC7 lEppxE/Hb1XWbVOwByuurRGYHQ807AOrHHTbVbSfg1Jq1K1DMwY+dRxXYq8FsL2P6QSB WPkDXtK3EfY4sBOyT7WjBspnsKIWVLKAz2FtFkyFMMdmwVTeUD/KhjcU4l9AAvd4/app EZNr52sooMr2rnTyn6Thl+X8t87tG1pM47ciZsCcvQRBpHyKbKeLlsnamnkKEhj0D9qX X1oP3pTYCVy30bBmOl3m5Vt4685pNbSLqQ07LTcFW96Ifwk6WY7LEABYBeIUJvei16ku 8Grg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780966821; x=1781571621; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=OQBrQS5EmHHWgpL0VJev95gvg3IajG0SEO/xcU/cGJM=; b=Gy0wtXFcK7SJzouiGZPgvXot35tSv2rb4JyZwX7xPSMxfF5vRwlhYFSKSKTWEskrw7 9lWmJEWAlcQ4VWDWrntTtdxA+8MnwORZFs83YWwZYYTUzcERO3NXVz7emqNESEvyXxQI k0GEOitTkGvk9uMXF1xpoKlzAGNCqjlVlZ6BqvJOLqe8A20co5PezKPwzMQS1Qo7JI9/ l2LqV1gL2dVY69rME20q52YkRoJBHGDf30C4fAA3UQvV2mU5L2m1SIg+B7iFzRsJku4o V+BXtwZgUm9vINExSx2/MSQ/a0WkFaV9yxhTy5DQlsImz0ZZbC14ngA6kFcyaASChYOm YjNw== X-Forwarded-Encrypted: i=1; AFNElJ8IHgVdCYQQbsBzPo4XRvHKfGZmsaE40XA2f2GX9WUwOCf42J1i1w+1IjcsplwkpEq0PkhdfjW+uzzFKQY=@vger.kernel.org X-Gm-Message-State: AOJu0YyHeLATPZ1n64ycvM7tEPw0shVpdoow9Zbo//k6xtYxYQpWhvDk WS6cBc747e0rPSsR6iIPD9Sl+309U196gV6EsobwyFDkRA8UBlCjBNk2N+S5i2E3 X-Gm-Gg: Acq92OEaSc2bmXKSxedRKE8+ZCuahs8RKWTlMGzI3ScayptEzDME5Qgr9ZKZlo2VCCw 7UL8VjWnugTUnfupGQkwhHodBiKmOoLkckIFNRt7dEtvpQ27Pk1X+TYrprQSZrLpQRRdWE23JiV JEY3VXMpzkV6b1assB2RMK37w09fWS/3eeyc1TW5oiVe/CC0sKN7qOQl3IclVCe16A/bYp0C6je uODQkCpgy5j81byYAw6yzDYEeMpJHD8J4ZprJXDL6iF7oVeihU8dYv1YJgwV9jCY0MASm4R51WA GUGeRla1vYCwl09Hn+8rY2/EuJz12hqyS96g5rF7lwleduQjx3tnLoFEITOB1uZZZctE5iT6Qwq YVVku4wfIv5SZ6XNfb8r3xqsKDRG/mPTaBcjwmUbBC2WExXlef/gjrlakV8b5JksBCkLDbYsInA GmXeSHmphrUWu0e0ddIBnoveY5Tape2RvJEh6cn9tEegZguQkvvfXkWASQMZaLyG77snrTqoEwH ALImZKneilk+SNVVmo= X-Received: by 2002:a05:693c:6390:10b0:304:db3a:3919 with SMTP id 5a478bee46e88-3077af0e961mr5388593eec.6.1780966821204; Mon, 08 Jun 2026 18:00:21 -0700 (PDT) Received: from ?IPv6:2a03:83e0:115c:1:cde6:fb53:a1a3:a385? ([2620:10d:c090:500::3:b685]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-3078c1ac378sm11412698eec.1.2026.06.08.18.00.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jun 2026 18:00:20 -0700 (PDT) Message-ID: <49c36dc0f52bd05d0f8c055e3d3e96992ae716a6.camel@gmail.com> Subject: Re: [PATCH bpf v5 1/2] bpf: Fix kfunc implicit arg inject type detection to prevent invalid pointer deref From: Eduard Zingerman To: Ihor Solodrai , chenyuan_fl@163.com Cc: andrii@kernel.org, ast@kernel.org, bot+bpf-ci@kernel.org, bpf@vger.kernel.org, chenyuan@kylinos.cn, clm@meta.com, daniel@iogearbox.net, jolsa@kernel.org, linux-kernel@vger.kernel.org, martin.lau@kernel.org, martin.lau@linux.dev, memxor@gmail.com, song@kernel.org, yonghong.song@linux.dev Date: Mon, 08 Jun 2026 18:00:18 -0700 In-Reply-To: References: <20260602093836.2632714-1-chenyuan_fl@163.com> <20260608142618.3064380-1-chenyuan_fl@163.com> <20260608142618.3064380-2-chenyuan_fl@163.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.60.1 (3.60.1-1.fc44) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Mon, 2026-06-08 at 17:54 -0700, Ihor Solodrai wrote: > On 6/8/26 7:26 AM, chenyuan_fl@163.com wrote: > > From: Yuan Chen > >=20 > > When a module kfunc declares an implicit struct bpf_prog_aux * argument= , > > the verifier must identify it so the kernel injects env->prog->aux into > > the correct register at runtime. The original check used > > is_kfunc_arg_prog_aux() which calls btf_types_are_same() to compare the > > module BTF type against vmlinux. > >=20 > > Root Cause > >=20 > > This issue was triggered by pahole 1.30 generating module BTF with > > incorrect type information, which caused the kernel's distilled base > > BTF deduplication for modules to fail. As a result, the module retaine= d > > its own copy of struct bpf_prog_aux with a different BTF ID than > > vmlinux's definition. While pahole 1.31 fixed the BTF generation issue= , > > the kernel must be robust against such inconsistencies: a BTF mismatch > > should result in a clean rejection, not a kernel crash or information > > disclosure. > >=20 > > When the distilled base dedup fails and btf_types_are_same() cannot > > match the module's bpf_prog_aux type against vmlinux's, > > is_kfunc_arg_prog_aux() returned false and the code fell through > > silently without setting arg_prog. The kfunc then received whatever > > value was in the argument register and dereferenced it as a > > bpf_prog_aux pointer, leading to: > >=20 > > BUG: kernel invalid pointer dereference, address: 00000000000009e2 > > RIP: bpf_prog_get_assoc_struct_ops+0xa/0xc0 > > RDI: 0x000000000000046d (stale register value) > >=20 > > In the observed crash the stale value was the process PID, causing a > > dereference within the unmapped NULL page. However, an attacker able > > to control the register value -- for example by writing a BPF program > > that explicitly sets R2 before calling a KF_IMPLICIT_ARGS kfunc -- > > could redirect the dereference to arbitrary kernel memory, turning > > this into an information disclosure. The fix ensures the verifier > > either validates and injects the correct bpf_prog_aux pointer, or > > rejects the program outright -- no silent fallthrough that could > > be exploited. > >=20 > > Crash Stack Trace > >=20 > > PID: 1133 TASK: ffff8881057d3900 CPU: 3 COMMAND: "test_progs" > > #0 machine_kexec at ffffffff812f6e26 > > #1 __crash_kexec at ffffffff8145a788 > > #2 crash_kexec at ffffffff8145ac24 > > #3 oops_end at ffffffff812bb67c > > #4 page_fault_oops at ffffffff813053a1 > > #5 exc_page_fault at ffffffff828e60a1 > > #6 asm_exc_page_fault at ffffffff810012a6 > > [exception RIP: bpf_prog_get_assoc_struct_ops+10] > > RIP: ffffffff815c024a RSP: ffffc90001b57e48 RFLAGS: 00010283 > > RAX: ffff8881057d3900 RBX: ffffc90001b57e68 RCX: ffff8881057d39= 00 > > RDX: 0000607d4d1768b8 RSI: 000000000000046d RDI: 00000000000004= 6d > > #7 bpf_kfunc_multi_st_ops_test_1_assoc at ffffffffc0013a85 [bpf_test= mod] > > #8 bpf_trace_run2 at ffffffff814f8332 > > #9 __traceiter_sys_enter at ffffffff81415f45 > > #10 trace_syscall_enter at ffffffff81416735 > > #11 do_syscall_64 at ffffffff828e06a1 > >=20 > > Fix > >=20 > > Split the combined is_kfunc_arg_ignore() || is_kfunc_arg_implicit() > > check in check_kfunc_args() so that an implicit argument reaching > > is_kfunc_arg_implicit() without being handled by a prior handler is > > rejected with -EFAULT, instead of silently skipped. Existing implicit > > args in bpf_fixup_kfunc_call() (obj_new, percpu_obj_new, obj_drop= , > > percpu_obj_drop, refcount_acquire, list_push, rbtree_add) are > > explicitly allowed. > >=20 > > Suggested-by: Eduard Zingerman > > Fixes: 64e1360524b9 ("bpf: Verifier support for KF_IMPLICIT_ARGS") > > Signed-off-by: Yuan Chen > > --- > > kernel/bpf/verifier.c | 20 +++++++++++++++++++- > > 1 file changed, 19 insertions(+), 1 deletion(-) > >=20 > > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c > > index 8ed484cb1a8a..91aaed7a5eeb 100644 > > --- a/kernel/bpf/verifier.c > > +++ b/kernel/bpf/verifier.c > > @@ -11885,9 +11885,27 @@ static int check_kfunc_args(struct bpf_verifie= r_env *env, struct bpf_kfunc_call_ > > continue; > > } > > =20 > > - if (is_kfunc_arg_ignore(btf, &args[i]) || is_kfunc_arg_implicit(meta= , i)) > > + if (is_kfunc_arg_ignore(btf, &args[i])) > > continue; > > =20 > > + if (is_kfunc_arg_implicit(meta, i)) { > > + /* kfuncs with implicit args (e.g. 'off' parameter) > > + * handled during verification in bpf_fixup_kfunc_call(): > > + * obj_new, percpu_obj_new, obj_drop, percpu_obj_drop, > > + * refcount_acquire, list_push, rbtree_add. Don't flag them. */ > > + if (is_bpf_obj_new_kfunc(meta->func_id) || > > + is_bpf_percpu_obj_new_kfunc(meta->func_id) || > > + is_bpf_obj_drop_kfunc(meta->func_id) || > > + is_bpf_percpu_obj_drop_kfunc(meta->func_id) || > > + is_bpf_refcount_acquire_kfunc(meta->func_id) || > > + is_bpf_list_push_kfunc(meta->func_id) || > > + is_bpf_rbtree_add_kfunc(meta->func_id)) >=20 > Is the goal here to have a nice error message? >=20 > I think this will fail for other functions like bpf_wq_set_callback(). > For a proper check, the list must include every single kfunc with KF_IMPL= ICIT_ARGS, no? >=20 > If we go this route, then the list of flagged kfuncs can be collected aut= omatically. > I'm not sure we actually want to do this. The calls to functions with implicit arguments are patched by bpf_fixup_kfunc_call(). As far as I understand, this function: - handles functions with implicit bpf_prog_aux generically - handles the functions listed above on a case-by-case basis. The goal is not to have a nice error message, but to prevent runtime from reading garbage from a register. >=20 > > + continue; > > + verbose(env, "%s unrecognized implicit argument, possible BTF misma= tch\n", > > + reg_arg_name(env, argno)); > > + return -EFAULT; > > + } > > + > > t =3D btf_type_skip_modifiers(btf, args[i].type, NULL); > > =20 > > if (btf_type_is_scalar(t)) {