public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Nick Alcock <nick.alcock@oracle.com>
To: binutils@sourceware.org
Cc: Nick Clifton <nickc@redhat.com>
Subject: Re: [PATCH 2.40 v2 3/3] libctf: ctf-link outdated input check faulty
Date: Wed, 11 Jan 2023 17:21:15 +0000	[thread overview]
Message-ID: <87r0w1oulw.fsf_-_@esperi.org.uk> (raw)
In-Reply-To: <20230110130050.366404-4-nick.alcock@oracle.com> (Nick Alcock via Binutils's message of "Tue, 10 Jan 2023 13:00:50 +0000")

Is this patch alone OK for 2.40? (After I push this series to master.
Tomorrow, not today... all tests passed, crash on i686-pc-linux-gnu
fixed, valgrind-clean, asan-clean.)

(I plan to backport it all the way back to 2.36.)

On 10 Jan 2023, Nick Alcock via Binutils spake thusly:

> This check has a pair of faults which, combined, can lead to memory
> corruption.  Firstly, it assumes that the values of the ctf_link_inputs
> hash are ctf_dict_t's: they are not, they are ctf_link_input_t's, a much
> shorter structure.  So the flags check which is the core of this is
> faulty (but happens, by chance, to give the right output on most
> architectures, since usually we happen to get a 0 here, so the test that
> checks this usually passes).  Worse, the warning that is emitted when
> the test fails is added to the wrong dict -- it's added to the input
> dict, whose warning list is never consumed, rendering the whole check
> useless.  But the dict it adds to is still the wrong type, so we end up
> overwriting something deep in memory (or, much more likely,
> dereferencing a garbage pointer and crashing).
>
> Fixing both reveals another problem: the link input is an *archive*
> consisting of multiple members, so we have to consider whether to check
> all of them for the outdated-func-info thing we are checking here.
> However, no compiler exists that emits a mixture of members with this
> flag on and members with it off, and the linker always reserializes (and
> upgrades) such things when it sees them: so all members in a given
> archive must have the same value of the flag, so we only need to check
> one member per input archive.
>
> libctf/
> 	PR libctf/29983
> 	* ctf-link.c (ctf_link_warn_outdated_inputs): Get the types of
>         members of ctf_link_inputs right, fixing a possible spurious
>         tesst failure / wild pointer deref / overwrite.  Emit the
>         warning message into the right dict.
> ---
>  libctf/ctf-link.c | 35 +++++++++++++++++++++++++++++------
>  1 file changed, 29 insertions(+), 6 deletions(-)
>
> diff --git a/libctf/ctf-link.c b/libctf/ctf-link.c
> index 2837168b2a6..df8fa3b9d9b 100644
> --- a/libctf/ctf-link.c
> +++ b/libctf/ctf-link.c
> @@ -1848,19 +1848,42 @@ ctf_link_warn_outdated_inputs (ctf_dict_t *fp)
>  {
>    ctf_next_t *i = NULL;
>    void *name_;
> -  void *ifp_;
> +  void *input_;
>    int err;
>  
> -  while ((err = ctf_dynhash_next (fp->ctf_link_inputs, &i, &name_, &ifp_)) == 0)
> +  while ((err = ctf_dynhash_next (fp->ctf_link_inputs, &i, &name_, &input_)) == 0)
>      {
>        const char *name = (const char *) name_;
> -      ctf_dict_t *ifp = (ctf_dict_t *) ifp_;
> +      ctf_link_input_t *input = (ctf_link_input_t *) input_;
> +      ctf_next_t *j = NULL;
> +      ctf_dict_t *ifp;
> +      int err;
> +
> +      /* We only care about CTF archives by this point: lazy-opened archives
> +         have always been opened by this point, and short-circuited entries have
> +         a matching corresponding archive member. Entries with NULL clin_arc can
> +         exist, and constitute old entries renamed via a name changer: the
> +         renamed entries exist elsewhere in the list, so we can just skip
> +         those.  */
> +
> +      if (!input->clin_arc)
> +        continue;
> +
> +      /* All entries in the archive will necessarily contain the same
> +         CTF_F_NEWFUNCINFO flag, so we only need to check the first. We don't
> +         even need to do that if we can't open it for any reason at all: the
> +         link will fail later on regardless, since an input can't be opened. */
> +
> +      ifp = ctf_archive_next (input->clin_arc, &j, NULL, 0, &err);
> +      if (!ifp)
> +        continue;
> +      ctf_next_destroy (j);
>  
>        if (!(ifp->ctf_header->cth_flags & CTF_F_NEWFUNCINFO)
>  	  && (ifp->ctf_header->cth_varoff - ifp->ctf_header->cth_funcoff) > 0)
> -	ctf_err_warn (ifp, 1, 0, _("linker input %s has CTF func info but uses "
> -				   "an old, unreleased func info format: "
> -				   "this func info section will be dropped."),
> +	ctf_err_warn (fp, 1, 0, _("linker input %s has CTF func info but uses "
> +                                  "an old, unreleased func info format: "
> +                                  "this func info section will be dropped."),
>  		      name);
>      }
>    if (err != ECTF_NEXT_END)

-- 
NULL && (void)

  reply	other threads:[~2023-01-11 17:21 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-10 13:00 [PATCH v2 0/3] A few backlogged fixes, and a crash bug Nick Alcock
2023-01-10 13:00 ` [PATCH v2 1/3] ctf: fix various dreadful typos in the ctf_archive format comments Nick Alcock
2023-01-10 13:00 ` [PATCH v2 2/3] libctf: skip the testsuite from inside dejagnu Nick Alcock
2023-01-10 13:00 ` [PATCH v2 3/3] libctf: ctf-link outdated input check faulty Nick Alcock
2023-01-11 17:21   ` Nick Alcock [this message]
2023-01-12 13:43     ` [PATCH 2.40 " Nick Clifton
2023-01-12 14:46       ` Nick Alcock
2023-01-12 15:39         ` Nick Alcock
2023-01-13 11:14           ` Nick Clifton

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=87r0w1oulw.fsf_-_@esperi.org.uk \
    --to=nick.alcock@oracle.com \
    --cc=binutils@sourceware.org \
    --cc=nickc@redhat.com \
    /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 read-only IMAP folder(s) and NNTP newsgroup(s).