[PATCH v2] bpf: allow BPF_LOG_KERNEL from kernel space

[PATCH v2] bpf: allow BPF_LOG_KERNEL from kernel space

[Siddharth Nayyar]

When loading a BPF program or BTF from kernel space (e.g. using a
light skeleton generated loader module), the kernel module may want
to output verifier logs to dmesg by setting attr->log_level =
BPF_LOG_KERNEL (16).

Currently, any attempt to do this through the standard syscall path
(kern_sys_bpf -> bpf_vlog_init) fails with -EINVAL because
bpf_verifier_log_attr_valid() rejects any log_level bit outside
BPF_LOG_MASK. This prevents in-kernel loaders from successfully
using BPF_LOG_KERNEL, causing silent failures if the BPF object
is rejected by the verifier.

This patch modifies bpf_verifier_log_attr_valid() to accept
BPF_LOG_KERNEL unconditionally. To prevent userspace from exploiting
this to spam the kernel log, the patch enforces a strict privilege
check at the syscall boundary points (btf_parse, bpf_log_attr_init,
bpf_log_attr_create_vlog), ensuring BPF_LOG_KERNEL is only permitted
when uattr.is_kernel is true.

Signed-off-by: Siddharth Nayyar <sidnayyar@google.com>
---
To: Alexei Starovoitov <ast@kernel.org>
To: Daniel Borkmann <daniel@iogearbox.net>
To: Andrii Nakryiko <andrii@kernel.org>
To: Eduard Zingerman <eddyz87@gmail.com>
To: Kumar Kartikeya Dwivedi <memxor@gmail.com>
To: Martin KaFai Lau <martin.lau@linux.dev>
To: Song Liu <song@kernel.org>
To: Yonghong Song <yonghong.song@linux.dev>
To: Jiri Olsa <jolsa@kernel.org>
To: Emil Tsalapatis <emil@etsalapatis.com>
To: John Fastabend <john.fastabend@gmail.com>
Cc: bpf@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Giuliano Procida <gprocida@google.com>
Cc: Matthias Maennich <maennich@google.com>
Cc: Tiffany Yang <ynaffit@google.com>
Cc: Neill Kapron <nkapron@google.com>
Signed-off-by: Siddharth Nayyar <sidnayyar@google.com>

--- Changes in v2:
- Refactored BPF_LOG_KERNEL validation to check uattr.is_kernel at
  syscall boundary points (btf_parse, bpf_log_attr_init, etc.) rather
  than plumbing an is_kernel boolean through the verifier log
  initialization functions.
- Link to v1:
  https://lore.kernel.org/r/20260623-bpf-lskel-fixes-v1-1-90600b40e7cb@google.com
---
 kernel/bpf/btf.c |  3 +++
 kernel/bpf/log.c | 17 +++++++++++++++++
 2 files changed, 20 insertions(+)

diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
index 15ae7c43f594..4a0c18112ad3 100644
--- a/kernel/bpf/btf.c
+++ b/kernel/bpf/btf.c
@@ -5919,6 +5919,9 @@ static struct btf *btf_parse(const union bpf_attr *attr, bpfptr_t uattr,
 	if (attr->btf_size > BTF_MAX_SIZE)
 		return ERR_PTR(-E2BIG);
 
+	if (attr_log->level == BPF_LOG_KERNEL && !uattr.is_kernel)
+		return ERR_PTR(-EINVAL);
+
 	env = kzalloc_obj(*env, GFP_KERNEL | __GFP_NOWARN);
 	if (!env)
 		return ERR_PTR(-ENOMEM);
diff --git a/kernel/bpf/log.c b/kernel/bpf/log.c
index b740fa73ee26..25a9f8340980 100644
--- a/kernel/bpf/log.c
+++ b/kernel/bpf/log.c
@@ -21,6 +21,15 @@ static bool bpf_verifier_log_attr_valid(u32 log_level, char __user *log_buf, u32
 	/* log buf without log_level is meaningless */
 	if (log_buf && log_level == 0)
 		return false;
+
+	/* BPF_LOG_KERNEL is an exclusive internal mode, not a bit flag.
+	 * It must be checked via strict equality to prevent it from being
+	 * combined with userspace flags, which would cause the verifier
+	 * to fallback to userspace logging and copy_to_user() failures.
+	 */
+	if (log_level == BPF_LOG_KERNEL)
+		return true;
+
 	if (log_level & ~BPF_LOG_MASK)
 		return false;
 	if (log_size > UINT_MAX >> 2)
@@ -831,6 +840,11 @@ int bpf_log_attr_init(struct bpf_log_attr *log, u64 log_buf, u32 log_size, u32 l
 	char __user *ubuf_common = u64_to_user_ptr(common->log_buf);
 	char __user *ubuf = u64_to_user_ptr(log_buf);
 
+	if (common->log_level == BPF_LOG_KERNEL && !uattr_common.is_kernel)
+		return -EINVAL;
+	if (log_level == BPF_LOG_KERNEL && !uattr.is_kernel)
+		return -EINVAL;
+
 	if (!bpf_verifier_log_attr_valid(common->log_level, ubuf_common, common->log_size) ||
 	    !bpf_verifier_log_attr_valid(log_level, ubuf, log_size))
 		return -EINVAL;
@@ -873,6 +887,9 @@ struct bpf_verifier_log *bpf_log_attr_create_vlog(struct bpf_log_attr *attr_log,
 	if (!size)
 		return NULL;
 
+	if (common->log_level == BPF_LOG_KERNEL && !uattr.is_kernel)
+		return ERR_PTR(-EINVAL);
+
 	log = kzalloc_obj(*log, GFP_KERNEL);
 	if (!log)
 		return ERR_PTR(-ENOMEM);

---
base-commit: 502d801f0ab03e4f32f9a33d203154ce84887921
change-id: 20260622-bpf-lskel-fixes-cafd1a83dec2

Best regards,
-- 
Siddharth Nayyar <sidnayyar@google.com>

Re: [PATCH v2] bpf: allow BPF_LOG_KERNEL from kernel space

[bot+bpf-ci]

[-- Attachment #1: Type: text/plain, Size: 1338 bytes --]

> diff --git a/kernel/bpf/log.c b/kernel/bpf/log.c
> index b740fa73ee26..25a9f8340980 100644
> --- a/kernel/bpf/log.c
> +++ b/kernel/bpf/log.c
> @@ -21,6 +21,15 @@ static bool bpf_verifier_log_attr_valid(u32 log_level, char __user *log_buf, u32
>  	/* log buf without log_level is meaningless */
>  	if (log_buf && log_level == 0)
>  		return false;
> +
> +	/* BPF_LOG_KERNEL is an exclusive internal mode, not a bit flag.
> +	 * It must be checked via strict equality to prevent it from being
> +	 * combined with userspace flags, which would cause the verifier
> +	 * to fallback to userspace logging and copy_to_user() failures.
> +	 */

This isn't a bug, but would it read more in line with the BPF multi-line
comment style to put the opening /* on its own line here?  The text
currently starts on the same line as the opening /*:

	/* BPF_LOG_KERNEL is an exclusive internal mode, not a bit flag.
	 * It must be checked via strict equality ...

> +	if (log_level == BPF_LOG_KERNEL)
> +		return true;
> +
>  	if (log_level & ~BPF_LOG_MASK)
>  		return false;
>  	if (log_size > UINT_MAX >> 2)


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/28121265957

Re: [PATCH v2] bpf: allow BPF_LOG_KERNEL from kernel space

[Alexei Starovoitov]

On Wed, Jun 24, 2026 at 11:19 AM Siddharth Nayyar <sidnayyar@google.com> wrote:
>
> When loading a BPF program or BTF from kernel space (e.g. using a
> light skeleton generated loader module), the kernel module may want
> to output verifier logs to dmesg by setting attr->log_level =
> BPF_LOG_KERNEL (16).
>
> Currently, any attempt to do this through the standard syscall path
> (kern_sys_bpf -> bpf_vlog_init) fails with -EINVAL because
> bpf_verifier_log_attr_valid() rejects any log_level bit outside
> BPF_LOG_MASK. This prevents in-kernel loaders from successfully
> using BPF_LOG_KERNEL, causing silent failures if the BPF object
> is rejected by the verifier.
>
> This patch modifies bpf_verifier_log_attr_valid() to accept
> BPF_LOG_KERNEL unconditionally. To prevent userspace from exploiting
> this to spam the kernel log, the patch enforces a strict privilege
> check at the syscall boundary points (btf_parse, bpf_log_attr_init,
> bpf_log_attr_create_vlog), ensuring BPF_LOG_KERNEL is only permitted
> when uattr.is_kernel is true.

I don't think it's a good idea.
BPF_LOG_KERNEL prints to dmesg and it's there for cases
where BTF is corrupted in vmlinux or in the module.
The verifier log can be large. It's never suitable for dmesg.

Let's step back and discuss the end goal.
Not just this patch, but overall.
You're sending a bunch of patches for various lskel things.
Please explain the full picture.

pw-bot: cr

Re: [PATCH v2] bpf: allow BPF_LOG_KERNEL from kernel space

[Sid Nayyar]

On Thu, Jun 25, 2026 at 9:02 PM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> I don't think it's a good idea.
> BPF_LOG_KERNEL prints to dmesg and it's there for cases
> where BTF is corrupted in vmlinux or in the module.
> The verifier log can be large. It's never suitable for dmesg.
>
> Let's step back and discuss the end goal.
> Not just this patch, but overall.
> You're sending a bunch of patches for various lskel things.
> Please explain the full picture.
>
> pw-bot: cr

I am trying to enable support for STRUCT_OPS maps in light skeletons.
The idea is to enable loading sched_ext eBPF programs using in-kernel
loaders, such as a kernel module. I am preparing to send a patch
series for the same.

The changes I have been sending fix bugs I found along the way, for
example poisoning unresolved weak kfuncs and fixing a typo in
struct_ops map FD generation.

This change, however, is not a bug fix but just a quality-of-life
improvement. Having the ability to enable BPF logs in dmesg for
in-kernel loaders has been helpful for debugging. Therefore I sent
this change upstream. I agree that enabling dmesg logs for loaders in
production is a bad idea, but in-kernel loaders can use this option
during development to ease debugging.

That said, I am happy to drop this change since it is merely a quality
of life improvement and doesn't deliver any crucial functionality.

Regards,
Siddharth Nayyar