From: Kees Cook <keescook@chromium.org>
To: Rick Edgecombe <rick.p.edgecombe@intel.com>
Cc: dave.hansen@intel.com, len.brown@intel.com, tony.luck@intel.com,
rafael.j.wysocki@intel.com, reinette.chatre@intel.com,
dan.j.williams@intel.com, viro@zeniv.linux.org.uk,
ebiederm@xmission.com, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, Yu-cheng Yu <yu-cheng.yu@intel.com>
Subject: Re: [PATCH v2 3/3] elf: Don't write past end of notes for regset gap
Date: Thu, 17 Mar 2022 14:26:33 -0700 [thread overview]
Message-ID: <202203171425.565EB773FD@keescook> (raw)
In-Reply-To: <20220317192013.13655-4-rick.p.edgecombe@intel.com>
On Thu, Mar 17, 2022 at 12:20:13PM -0700, Rick Edgecombe wrote:
> In fill_thread_core_info() the ptrace accessible registers are collected
> to be written out as notes in a core file. The note array is allocated
> from a size calculated by iterating the user regset view, and counting the
> regsets that have a non-zero core_note_type. However, this only allows for
> there to be non-zero core_note_type at the end of the regset view. If
> there are any gaps in the middle, fill_thread_core_info() will overflow the
> note allocation, as it iterates over the size of the view and the
> allocation would be smaller than that.
>
> There doesn't appear to be any arch that has gaps such that they exceed
> the notes allocation, but the code is brittle and tries to support
> something it doesn't. It could be fixed by increasing the allocation size,
> but instead just have the note collecting code utilize the array better.
> This way the allocation can stay smaller.
>
> Even in the case of no arch's that have gaps in their regset views, this
> introduces a change in the resulting indicies of t->notes. It does not
> introduce any changes to the core file itself, because any blank notes are
> skipped in write_note_info().
>
> In case, the allocation logic between fill_note_info() and
> fill_thread_core_info() ever diverges from the usage logic, warn and skip
> writing any notes that would overflow the array.
>
> This fix is derrived from an earlier one[0] by Yu-cheng Yu.
>
> [0] https://lore.kernel.org/lkml/20180717162502.32274-1-yu-cheng.yu@intel.com/
>
> Co-developed-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
> Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
> Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
>
> ---
>
> v2:
> - Warn and break out of the note collecting loop if the allocation would
> overflow. Note: I tweaked it slightly to do break instead of continue
> and to do it before SET_PR_FPVALID(). (Kees)
This looks great; thank you for the tweak. :)
Acked-by: Kees Cook <keescook@chromium.org>
Shall I take this separately into the for-next/execve tree, or would you
rather is stay in this series?
-Kees
--
Kees Cook
next prev parent reply other threads:[~2022-03-17 21:26 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-17 19:20 [PATCH v2 0/3] Regset cleanups Rick Edgecombe
2022-03-17 19:20 ` [PATCH v2 1/3] x86: Separate out x86_regset for 32 and 64 bit Rick Edgecombe
2022-03-17 21:33 ` Kees Cook
2022-03-17 21:54 ` Edgecombe, Rick P
2022-03-17 19:20 ` [PATCH v2 2/3] x86: Improve formatting of user_regset arrays Rick Edgecombe
2022-03-17 19:20 ` [PATCH v2 3/3] elf: Don't write past end of notes for regset gap Rick Edgecombe
2022-03-17 21:26 ` Kees Cook [this message]
2022-03-17 21:53 ` Edgecombe, Rick P
2022-03-18 17:18 ` (subset) " Kees Cook
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=202203171425.565EB773FD@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.