All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Yu, Yu-cheng" <yu-cheng.yu@intel.com>,
	"viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>,
	"Williams, Dan J" <dan.j.williams@intel.com>,
	"Wysocki, Rafael J" <rafael.j.wysocki@intel.com>,
	"ebiederm@xmission.com" <ebiederm@xmission.com>,
	"Chatre, Reinette" <reinette.chatre@intel.com>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"Luck, Tony" <tony.luck@intel.com>,
	"Hansen, Dave" <dave.hansen@intel.com>,
	"Brown, Len" <len.brown@intel.com>
Subject: Re: [PATCH 3/3] elf: Don't write past end of notes for regset gap
Date: Tue, 15 Mar 2022 19:48:05 -0700	[thread overview]
Message-ID: <202203151946.0ECF6FC@keescook> (raw)
In-Reply-To: <983f20076ae02f0b33d4609b19cb22ab379174f1.camel@intel.com>

On Tue, Mar 15, 2022 at 09:48:29PM +0000, Edgecombe, Rick P wrote:
> On Tue, 2022-03-15 at 13:37 -0700, Kees Cook wrote:
> > >        /*
> > >         * Each other regset might generate a note too.  For each
> > > regset
> > > -      * that has no core_note_type or is inactive, we leave t-
> > > >notes[i]
> > > -      * all zero and we'll know to skip writing it later.
> > > +      * that has no core_note_type or is inactive, skip it.
> > >         */
> > > -     for (i = 1; i < view->n; ++i) {
> > > -             const struct user_regset *regset = &view->regsets[i];
> > > +     note_iter = 1;
> > > +     for (view_iter = 1; view_iter < view->n; ++view_iter) {
> > > +             const struct user_regset *regset = &view-
> > > >regsets[view_iter];
> > >                int note_type = regset->core_note_type;
> > >                bool is_fpreg = note_type == NT_PRFPREG;
> > >                void *data;
> > > @@ -1800,10 +1800,11 @@ static int fill_thread_core_info(struct
> > > elf_thread_core_info *t,
> > >                if (is_fpreg)
> > >                        SET_PR_FPVALID(&t->prstatus);
> > >   
> > 
> > info->thread_notes contains the count. Since fill_thread_core_info()
> > passes a info member by reference, it might make sense to just pass
> > info
> > itself, then the size can be written and a bounds-check can be added
> > here:
> > 
> >                 if (WARN_ON_ONCE(i >= info->thread_notes))
> >                         continue;
> 
> Hi Kees,
> 
> Thanks for the quick response.
> 
> Are you saying in addition to utilizing the allocation better, also
> catch if the allocation is still too small? Or do this check instead of
> the change in how to utilize the array, and then maintain the
> restriction on having gaps in the regsets?

What I want is to have writers of dynamically-sized arrays able to do
the bounds check in the same place the write happens, so passing "info"
makes sense to me.

-- 
Kees Cook

      reply	other threads:[~2022-03-16  2:48 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-15 20:17 [PATCH 0/3] Regset cleanups Rick Edgecombe
2022-03-15 20:17 ` [PATCH 1/3] x86: Separate out x86_regset for 32 and 64 bit Rick Edgecombe
2022-03-15 20:41   ` Kees Cook
2022-03-15 21:53     ` Edgecombe, Rick P
2022-03-16  2:48       ` Kees Cook
2022-03-16 19:06         ` Edgecombe, Rick P
2022-03-16 19:42           ` Edgecombe, Rick P
2022-03-16 19:43           ` Kees Cook
2022-03-15 23:01   ` Eric W. Biederman
2022-03-15 23:33     ` Edgecombe, Rick P
2022-03-15 20:17 ` [PATCH 2/3] x86: Improve formatting of user_regset arrays Rick Edgecombe
2022-03-15 20:38   ` Kees Cook
2022-03-15 21:48     ` Edgecombe, Rick P
2022-03-15 20:17 ` [PATCH 3/3] elf: Don't write past end of notes for regset gap Rick Edgecombe
2022-03-15 20:37   ` Kees Cook
2022-03-15 21:48     ` Edgecombe, Rick P
2022-03-16  2:48       ` Kees Cook [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=202203151946.0ECF6FC@keescook \
    --to=keescook@chromium.org \
    --cc=dan.j.williams@intel.com \
    --cc=dave.hansen@intel.com \
    --cc=ebiederm@xmission.com \
    --cc=len.brown@intel.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rafael.j.wysocki@intel.com \
    --cc=reinette.chatre@intel.com \
    --cc=rick.p.edgecombe@intel.com \
    --cc=tony.luck@intel.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=yu-cheng.yu@intel.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 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.