BPF List
 help / color / mirror / Atom feed
* [PATCH bpf-next] bpf: Reject struct_ops registration that uses module ptr and the module btf_id is missing
@ 2024-12-20 20:18 Martin KaFai Lau
  2025-01-03  6:14 ` Eduard Zingerman
  2025-01-03 18:20 ` patchwork-bot+netdevbpf
  0 siblings, 2 replies; 4+ messages in thread
From: Martin KaFai Lau @ 2024-12-20 20:18 UTC (permalink / raw)
  To: bpf
  Cc: Alexei Starovoitov, Andrii Nakryiko, Daniel Borkmann, kernel-team,
	Robert Morris

From: Martin KaFai Lau <martin.lau@kernel.org>

There is a UAF report in the bpf_struct_ops when CONFIG_MODULES=n.
In particular, the report is on tcp_congestion_ops that has
a "struct module *owner" member.

For struct_ops that has a "struct module *owner" member,
it can be extended either by the regular kernel module or
by the bpf_struct_ops. bpf_try_module_get() will be used
to do the refcounting and different refcount is done
based on the owner pointer. When CONFIG_MODULES=n,
the btf_id of the "struct module" is missing:

WARN: resolve_btfids: unresolved symbol module

Thus, the bpf_try_module_get() cannot do the correct refcounting.

Not all subsystem's struct_ops requires the "struct module *owner" member.
e.g. the recent sched_ext_ops.

This patch is to disable bpf_struct_ops registration if
the struct_ops has the "struct module *" member and the
"struct module" btf_id is missing. The btf_type_is_fwd() helper
is moved to the btf.h header file for this test.

This has happened since the beginning of bpf_struct_ops which has gone
through many changes. The Fixes tag is set to a recent commit that this
patch can apply cleanly. Considering CONFIG_MODULES=n is not
common and the age of the issue, targeting for bpf-next also.

Fixes: 1611603537a4 ("bpf: Create argument information for nullable arguments.")
Reported-by: Robert Morris <rtm@csail.mit.edu>
Closes: https://lore.kernel.org/bpf/74665.1733669976@localhost/
Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
---
 include/linux/btf.h         |  5 +++++
 kernel/bpf/bpf_struct_ops.c | 21 +++++++++++++++++++++
 kernel/bpf/btf.c            |  5 -----
 3 files changed, 26 insertions(+), 5 deletions(-)

diff --git a/include/linux/btf.h b/include/linux/btf.h
index 4214e76c9168..2a08a2b55592 100644
--- a/include/linux/btf.h
+++ b/include/linux/btf.h
@@ -353,6 +353,11 @@ static inline bool btf_type_is_scalar(const struct btf_type *t)
 	return btf_type_is_int(t) || btf_type_is_enum(t);
 }
 
+static inline bool btf_type_is_fwd(const struct btf_type *t)
+{
+	return BTF_INFO_KIND(t->info) == BTF_KIND_FWD;
+}
+
 static inline bool btf_type_is_typedef(const struct btf_type *t)
 {
 	return BTF_INFO_KIND(t->info) == BTF_KIND_TYPEDEF;
diff --git a/kernel/bpf/bpf_struct_ops.c b/kernel/bpf/bpf_struct_ops.c
index 606efe32485a..040fb1cd840b 100644
--- a/kernel/bpf/bpf_struct_ops.c
+++ b/kernel/bpf/bpf_struct_ops.c
@@ -310,6 +310,20 @@ void bpf_struct_ops_desc_release(struct bpf_struct_ops_desc *st_ops_desc)
 	kfree(arg_info);
 }
 
+static bool is_module_member(const struct btf *btf, u32 id)
+{
+	const struct btf_type *t;
+
+	t = btf_type_resolve_ptr(btf, id, NULL);
+	if (!t)
+		return false;
+
+	if (!__btf_type_is_struct(t) && !btf_type_is_fwd(t))
+		return false;
+
+	return !strcmp(btf_name_by_offset(btf, t->name_off), "module");
+}
+
 int bpf_struct_ops_desc_init(struct bpf_struct_ops_desc *st_ops_desc,
 			     struct btf *btf,
 			     struct bpf_verifier_log *log)
@@ -389,6 +403,13 @@ int bpf_struct_ops_desc_init(struct bpf_struct_ops_desc *st_ops_desc,
 			goto errout;
 		}
 
+		if (!st_ops_ids[IDX_MODULE_ID] && is_module_member(btf, member->type)) {
+			pr_warn("'struct module' btf id not found. Is CONFIG_MODULES enabled? bpf_struct_ops '%s' needs module support.\n",
+				st_ops->name);
+			err = -EOPNOTSUPP;
+			goto errout;
+		}
+
 		func_proto = btf_type_resolve_func_ptr(btf,
 						       member->type,
 						       NULL);
diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
index 28246c59e12e..8396ce1d0fba 100644
--- a/kernel/bpf/btf.c
+++ b/kernel/bpf/btf.c
@@ -498,11 +498,6 @@ bool btf_type_is_void(const struct btf_type *t)
 	return t == &btf_void;
 }
 
-static bool btf_type_is_fwd(const struct btf_type *t)
-{
-	return BTF_INFO_KIND(t->info) == BTF_KIND_FWD;
-}
-
 static bool btf_type_is_datasec(const struct btf_type *t)
 {
 	return BTF_INFO_KIND(t->info) == BTF_KIND_DATASEC;
-- 
2.43.5


^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH bpf-next] bpf: Reject struct_ops registration that uses module ptr and the module btf_id is missing
  2024-12-20 20:18 [PATCH bpf-next] bpf: Reject struct_ops registration that uses module ptr and the module btf_id is missing Martin KaFai Lau
@ 2025-01-03  6:14 ` Eduard Zingerman
  2025-01-07  0:34   ` Martin KaFai Lau
  2025-01-03 18:20 ` patchwork-bot+netdevbpf
  1 sibling, 1 reply; 4+ messages in thread
From: Eduard Zingerman @ 2025-01-03  6:14 UTC (permalink / raw)
  To: Martin KaFai Lau, bpf
  Cc: Alexei Starovoitov, Andrii Nakryiko, Daniel Borkmann, kernel-team,
	Robert Morris

On Fri, 2024-12-20 at 12:18 -0800, Martin KaFai Lau wrote:
> From: Martin KaFai Lau <martin.lau@kernel.org>
> 
> There is a UAF report in the bpf_struct_ops when CONFIG_MODULES=n.
> In particular, the report is on tcp_congestion_ops that has
> a "struct module *owner" member.
> 
> For struct_ops that has a "struct module *owner" member,
> it can be extended either by the regular kernel module or
> by the bpf_struct_ops. bpf_try_module_get() will be used
> to do the refcounting and different refcount is done
> based on the owner pointer. When CONFIG_MODULES=n,
> the btf_id of the "struct module" is missing:
> 
> WARN: resolve_btfids: unresolved symbol module
> 
> Thus, the bpf_try_module_get() cannot do the correct refcounting.
> 
> Not all subsystem's struct_ops requires the "struct module *owner" member.
> e.g. the recent sched_ext_ops.
> 
> This patch is to disable bpf_struct_ops registration if
> the struct_ops has the "struct module *" member and the
> "struct module" btf_id is missing. The btf_type_is_fwd() helper
> is moved to the btf.h header file for this test.
> 
> This has happened since the beginning of bpf_struct_ops which has gone
> through many changes. The Fixes tag is set to a recent commit that this
> patch can apply cleanly. Considering CONFIG_MODULES=n is not
> common and the age of the issue, targeting for bpf-next also.
> 
> Fixes: 1611603537a4 ("bpf: Create argument information for nullable arguments.")
> Reported-by: Robert Morris <rtm@csail.mit.edu>
> Closes: https://lore.kernel.org/bpf/74665.1733669976@localhost/
> Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
> ---

Looks like this fix had not landed yet.
I tried it and id does fix the error reported in the "closes" link.

Tested-by: Eduard Zingerman <eddyz87@gmail.com>

It was a bit hard for me to figure out what went wrong from the description,
could you please double-check my understanding below?
- when struct_ops program is attached,
  bpf_struct_ops_map_update_elem() scans every member of specific
  struct_ops type (e.g. struct tcp_congestion_ops) looking for fields
  with type 'struct module *';
- to find these fields BTF id of 'struct module' is used, this id does
  not exist when CONFIG_MODULES=n, bpf_struct_ops_map_update_elem()
  does not check if 'struct module' BTF id is non-zero;
- bpf_struct_ops_map_update_elem() initializes 'struct module *'
  fields using a magic value BPF_MODULE_OWNER, this initialization
  would not happen if fields are not found;
- later bpf_try_module_get() is called by code specific to particular
  struct_ops, e.g. from tcp_cong.c:tcp_assign_congestion_control();
- the bpf_try_module_get() is implemented as follows:

    static inline bool bpf_try_module_get(const void *data, struct module *owner)
    {
    	if (owner == BPF_MODULE_OWNER)
    		return bpf_struct_ops_get(data);
    	else
    		return try_module_get(owner);
    }

  if 'struct module *' fields are not correctly initialized as BPF_MODULE_OWNER
  the bpf_try_module_get() executes try_module_get() passing a bogus pointer to it.

Assuming the above is correct, the fix lgtm.

Acked-by: Eduard Zingerman <eddyz87@gmail.com>

[...]



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH bpf-next] bpf: Reject struct_ops registration that uses module ptr and the module btf_id is missing
  2024-12-20 20:18 [PATCH bpf-next] bpf: Reject struct_ops registration that uses module ptr and the module btf_id is missing Martin KaFai Lau
  2025-01-03  6:14 ` Eduard Zingerman
@ 2025-01-03 18:20 ` patchwork-bot+netdevbpf
  1 sibling, 0 replies; 4+ messages in thread
From: patchwork-bot+netdevbpf @ 2025-01-03 18:20 UTC (permalink / raw)
  To: Martin KaFai Lau; +Cc: bpf, ast, andrii, daniel, kernel-team, rtm

Hello:

This patch was applied to bpf/bpf-next.git (master)
by Alexei Starovoitov <ast@kernel.org>:

On Fri, 20 Dec 2024 12:18:18 -0800 you wrote:
> From: Martin KaFai Lau <martin.lau@kernel.org>
> 
> There is a UAF report in the bpf_struct_ops when CONFIG_MODULES=n.
> In particular, the report is on tcp_congestion_ops that has
> a "struct module *owner" member.
> 
> For struct_ops that has a "struct module *owner" member,
> it can be extended either by the regular kernel module or
> by the bpf_struct_ops. bpf_try_module_get() will be used
> to do the refcounting and different refcount is done
> based on the owner pointer. When CONFIG_MODULES=n,
> the btf_id of the "struct module" is missing:
> 
> [...]

Here is the summary with links:
  - [bpf-next] bpf: Reject struct_ops registration that uses module ptr and the module btf_id is missing
    https://git.kernel.org/bpf/bpf-next/c/96ea081ed52b

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH bpf-next] bpf: Reject struct_ops registration that uses module ptr and the module btf_id is missing
  2025-01-03  6:14 ` Eduard Zingerman
@ 2025-01-07  0:34   ` Martin KaFai Lau
  0 siblings, 0 replies; 4+ messages in thread
From: Martin KaFai Lau @ 2025-01-07  0:34 UTC (permalink / raw)
  To: Eduard Zingerman
  Cc: bpf, Alexei Starovoitov, Andrii Nakryiko, Daniel Borkmann,
	kernel-team, Robert Morris

On 1/2/25 10:14 PM, Eduard Zingerman wrote:
> It was a bit hard for me to figure out what went wrong from the description,
> could you please double-check my understanding below?
> - when struct_ops program is attached,
>    bpf_struct_ops_map_update_elem() scans every member of specific
>    struct_ops type (e.g. struct tcp_congestion_ops) looking for fields
>    with type 'struct module *';
> - to find these fields BTF id of 'struct module' is used, this id does
>    not exist when CONFIG_MODULES=n, bpf_struct_ops_map_update_elem()
>    does not check if 'struct module' BTF id is non-zero;
> - bpf_struct_ops_map_update_elem() initializes 'struct module *'
>    fields using a magic value BPF_MODULE_OWNER, this initialization
>    would not happen if fields are not found;

Thanks for reviewing and testing it!

Yes, the understanding is correct. These are pretty much the only two places 
where st_ops_ids[IDX_MODULE_ID] and BPF_MODULE_OWNER are used.


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2025-01-07  0:34 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-12-20 20:18 [PATCH bpf-next] bpf: Reject struct_ops registration that uses module ptr and the module btf_id is missing Martin KaFai Lau
2025-01-03  6:14 ` Eduard Zingerman
2025-01-07  0:34   ` Martin KaFai Lau
2025-01-03 18:20 ` patchwork-bot+netdevbpf

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox