dwarves.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: "Thomas Weißschuh" <thomas@t-8ch.de>
Cc: dwarves@vger.kernel.org
Subject: Re: [PATCH] dwarves: Initialize cu->priv explicitly
Date: Wed, 28 Jul 2021 15:11:47 -0300	[thread overview]
Message-ID: <YQGd4x5hVyw8Epxt@kernel.org> (raw)
In-Reply-To: <20210728175459.143265-1-thomas@t-8ch.de>

Em Wed, Jul 28, 2021 at 07:54:59PM +0200, Thomas Weißschuh escreveu:
> Otherweise ->priv may contain garbage data.
> This triggers a bug where the BTF loader thinks that the private data
> has been set and wants to free it, crashing the program.
> 
> The bug is not reproducible with all binaries. A test file is
> /usr/lib/libevdev.so.2.3.0 from
> https://archive.archlinux.org/packages/l/libevdev/libevdev-1.11.0-1-x86_64.pkg.tar.zst
> 
> Stacktrace:
>  Program terminated with signal SIGSEGV, Segmentation fault.
>  #0  0x00007f0c4cacfc49 in btf__free (btf=0x20) at lib/bpf/src/btf.c:729
>  729		if (btf->fd >= 0)
>  #1  0x00007f0c4cac2d20 in btf__cu_delete (cu=0x555d89203670) at btf_loader.c:536
>  #2  0x00007f0c4caaca44 in cu__delete (cu=0x555d89203670) at dwarves.c:630
>  #3  0x00007f0c4cac2f4d in cus__load_btf (cus=0x555d89203140, conf=0x555d8863f360 <conf_load>,
>      filename=0x7fff8fb8327e "/usr/lib/libevdev.so.2.3.0") at btf_loader.c:595
>  #4  0x00007f0c4caafc18 in cus__load_file (cus=0x555d89203140, conf=0x555d8863f360 <conf_load>,
>      filename=0x7fff8fb8327e "/usr/lib/libevdev.so.2.3.0") at dwarves.c:1993
>  #5  0x00007f0c4cab0988 in cus__load_files (cus=0x555d89203140, conf=0x555d8863f360 <conf_load>,
>      filenames=0x7fff8fb815f0) at dwarves.c:2352
>  #6  0x0000555d88638d6d in main (argc=2, argv=0x7fff8fb815e8) at pahole.c:2842
> 
> Fixes: 7fb31d787d3deec191527ca010c74888f4acd765 btf_loader: Stop using libbtf.h and the btf_elf class
> Signed-off-by: Thomas Weißschuh <thomas@t-8ch.de>
> ---
>  dwarves.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/dwarves.c b/dwarves.c
> index 34f581d..ed0037d 100644
> --- a/dwarves.c
> +++ b/dwarves.c
> @@ -576,6 +576,8 @@ struct cu *cu__new(const char *name, uint8_t addr_size,
>  		if (cu->filename == NULL)
>  			goto out_free_name;
>  
> +		cu->priv = NULL;
> +
>  		ptr_table__init(&cu->tags_table);
>  		ptr_table__init(&cu->types_table);
>  		ptr_table__init(&cu->functions_table);
> 
> base-commit: 3ec54ee72ff7c5b169252972f69007b54e2f9211
> -- 

Yeah, I noticed it and fixed it in the 'next' (also named 'tmp.master')
branch, will cherry-pick it into master and add an Reported-by: you:

⬢[acme@toolbox pahole]$ git show e9f3028efbeff225d8ced3c0bfa9fe82857b0a14
commit e9f3028efbeff225d8ced3c0bfa9fe82857b0a14
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date:   Fri Jun 25 16:56:35 2021 -0300

    core: Initialize cu->priv in cu__new()

    cus__load_btf() may bail out if btf__parse_split() fails, for instance
    when processing a malformed detached BTF file, and then call
    cu__delete(cu) that in turn calls btf__cu_delete(cu->priv), and as
    cu->priv wasn't initialized, a segfault ensues.

    Fix it by initializing cu->priv in cu__new().

    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

diff --git a/dwarves.c b/dwarves.c
index f1135c5980b416af..7d693b6805585238 100644
--- a/dwarves.c
+++ b/dwarves.c
@@ -623,6 +623,7 @@ struct cu *cu__new(const char *name, uint8_t addr_size,
                cu->build_id_len           = build_id_len;
                if (build_id_len > 0)
                        memcpy(cu->build_id, build_id, build_id_len);
+               cu->priv = NULL;
        }

        return cu;
⬢[acme@toolbox pahole]$

      reply	other threads:[~2021-07-28 18:11 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-28 17:54 [PATCH] dwarves: Initialize cu->priv explicitly Thomas Weißschuh
2021-07-28 18:11 ` Arnaldo Carvalho de Melo [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YQGd4x5hVyw8Epxt@kernel.org \
    --to=acme@kernel.org \
    --cc=dwarves@vger.kernel.org \
    --cc=thomas@t-8ch.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).