Skip to content

GitLab

Switch branch/tag
  1. 05 Feb, 2021 1 commit
  3. 03 Feb, 2021 4 commits
  5. 02 Feb, 2021 10 commits
  7. 30 Jan, 2021 1 commit
  9. 29 Jan, 2021 16 commits
  11. 28 Jan, 2021 4 commits
  13. 27 Jan, 2021 4 commits
    • Lauren Wehrmeister's avatar
      Merge "cert-tool: avoid duplicates in extension stack" into integration · 42ea70e8
      Lauren Wehrmeister authored
      42ea70e8
    • Nikos Nikoleris's avatar
      fdts: Fix stdout-path in various platforms · fcb0ea19
      Nikos Nikoleris authored 
      

The value of stdout-path is a string and as a result, we can't use a
label as a reference to the serial0 node. This change fixes the
stdout-path property for N1SDP, Morello and TC0 by pointing to the
right alias.
Signed-off-by: default avatarNikos Nikoleris <nikos.nikoleris@arm.com>
Change-Id: I3d403389a424569be56327fab4140fec06f96d37
      fcb0ea19
    • Madhukar Pappireddy's avatar
      Merge changes from topic "scmi-msg" into integration · 26dccba6
      Madhukar Pappireddy authored 
      * changes:
  doc: maintainers: add scmi server
  drivers: move scmi-msg out of st
      26dccba6
    • Jimmy Brisson's avatar
      cert-tool: avoid duplicates in extension stack · 1ed941c0
      Jimmy Brisson authored 
      

This bug manifests itself as a segfault triggered by a double-free.

I noticed that right before the double-free, the sk list contained 2
elements with the same address.

    (gdb) p sk_X509_EXTENSION_value(sk, 1)
    $34 = (X509_EXTENSION *) 0x431ad0
    (gdb) p sk_X509_EXTENSION_value(sk, 0)
    $35 = (X509_EXTENSION *) 0x431ad0
    (gdb) p sk_X509_EXTENSION_num(sk)
    $36 = 2

This caused confusion; this should never happen.

I figured that this was caused by a ext_new_xxxx function freeing
something before it is added to the list, so I put a breakpoint on
each of them to step through. I was suprised to find that none of my
breakpoints triggered for the second element of the iteration through
the outer loop just before the double-free.

Looking through the code, I noticed that it's possible to avoid doing
a ext_new_xxxx, when either:
   * ext->type == NVCOUNTER and ext->arg == NULL
   * ext->type == HASH and ext->arg == NULL and ext->optional == false
So I put a breakpoint on both.

It turns out that it was the HASH version, but I added a fix for both.
The fix for the Hash case is simple, as it was a mistake. The fix for
the NVCOUNTER case, however, is a bit more subtle. The NVCOUNTER may
be optional, and when it's optional we can skip it. The other case,
when the NVCOUNTER is required (not optinal), the `check_cmd_params`
function has already verified that the `ext->arg` must be non-NULL.
We assert that before processing it to covert any possible segfaults
into more descriptive errors.

This should no longer cause double-frees by adding the same ext twice.

Change-Id: Idae2a24ecd964b0a3929e6193c7f85ec769f6470
Signed-off-by: default avatarJimmy Brisson <jimmy.brisson@arm.com>
      1ed941c0