linux-kernel - Re: [PATCH] libbpf: checking the btf_type kind when fixing variable offsets

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Mon, 17 Jun 2024 13:00:48 -0700
From: Eduard Zingerman <eddyz87@...il.com>
To: Alan Maguire <alan.maguire@...cle.com>, Donglin Peng
	 <dolinux.peng@...il.com>, ast@...nel.org
Cc: daniel@...earbox.net, song@...nel.org, andrii@...nel.org,
 haoluo@...gle.com,  yonghong.song@...ux.dev, bpf@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] libbpf: checking the btf_type kind when fixing variable
 offsets

On Mon, 2024-06-17 at 12:29 +0100, Alan Maguire wrote:

[...]

> The only thing I could come up with is we were usually lucky; when we
> misinterpreted the func as a var and looked its type up, we got
> 
> 		int var_linkage = btf_var(vt)->linkage;
> 
> ...and were lucky it never equalled 1 (BTF_VAR_GLOBAL_ALLOCATED):
> 	
> 		/* no need to patch up static or extern vars */
>                 if (var_linkage != BTF_VAR_GLOBAL_ALLOCATED)
> 			continue;
> 
> In the case of a function, the above btf_var(vt) would really be
> pointing at the struct btf_type immediately after the relevant
> function's struct btf_type (since unlike variables, functions don't have
> metadata following them). So the only way we'd trip this bug would be if
> the struct btf_type following the func was had a name_off value that
> happened to equal 1 (BTF_VAR_GLOBAL_ALLOCATED).
> 
> So maybe the sorting changes to BTF order resulted in us tripping on
> this bug, but regardless the fix seems right to me.

I've added the following debug logging:
 
                        sym = find_sym_by_name(obj, sec->sec_idx, STT_OBJECT, var_name);
                        if (!sym) {
+                               const struct btf_type *nt;
                                pr_warn("failed to find symbol for variable '%s' in section '%s'\n", var_name, sec_name);
+                               nt = btf__type_by_id(obj->btf, vi->type + 1);
+                               pr_warn("  vi->type == %d\n", vi->type);
+                               pr_warn("  next id %d kind '%s', name '%s' off %d\n",
+                                       vi->type + 1,
+                                       btf_kind_str(nt),
+                                       btf__str_by_offset(obj->btf, nt->name_off), nt->name_off);
                                return -ENOENT;
                        }

The output is as follows:

  libbpf: failed to find symbol for variable 'bpf_dynptr_slice' in section '.ksyms'
  libbpf:   vi->type == 17
  libbpf:   next id 18 kind 'struct', name 'bpf_nf_ctx' off 1

This matches your analysis and hits the unlikely situation when
name_off of the next type is 1.