All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Garrett <mjg59@google.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: bugzilla-daemon@bugzilla.kernel.org,
	linux-efi <linux-efi@vger.kernel.org>
Subject: Re: [Bug 203761] New: efivar_ssdt_iter is subject to stack corruption when the input name_size is 0
Date: Fri, 31 May 2019 12:44:17 -0700	[thread overview]
Message-ID: <CACdnJuvJoyV-OnDuUPb1PNt4RUw2PzyA41P9DFhaYnD0ArCeGw@mail.gmail.com> (raw)
In-Reply-To: <CAKv+Gu8vuTLGX6h2T=d_EnzQx-XirD+yTV5AX_zA9vdtP1qU7A@mail.gmail.com>

On Fri, May 31, 2019 at 2:03 AM Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:

> > The input of name_size is signed long, gets compared against an unsigned long
> > of a fixed size, then stored as a signed int (this is mostly okay because of
> > the known max size), but it then gets passed to a function takes unsigned long
> > without checking the range.
> >
> > Here, the input name_size is 0, limit also is 0, but limit - 1 = -1, and then
> > casts to ULONGMAX to ucs2_as_utf8 and corrupts the stack storage with a size of
> > only EFIVAR_SSDT_NAME_MAX.

This is a legitimate bug, but anyone in a position to trigger this is
also in a position to inject an arbitrary SSDT which then means
arbitrary code execution in the kernel, so I don't think there's any
security-relevant impact.

      reply	other threads:[~2019-05-31 19:44 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-203761-199677@https.bugzilla.kernel.org/>
2019-05-31  9:02 ` [Bug 203761] New: efivar_ssdt_iter is subject to stack corruption when the input name_size is 0 Ard Biesheuvel
2019-05-31 19:44   ` Matthew Garrett [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=CACdnJuvJoyV-OnDuUPb1PNt4RUw2PzyA41P9DFhaYnD0ArCeGw@mail.gmail.com \
    --to=mjg59@google.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=bugzilla-daemon@bugzilla.kernel.org \
    --cc=linux-efi@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.