From: Kees Cook <keescook@chromium.org>
To: Elliott Mitchell <ehem+xen@m5p.com>
Cc: Justin Stitt <justinstitt@google.com>,
Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>,
Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>,
xen-devel@lists.xenproject.org, alsa-devel@alsa-project.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ALSA: xen-front: refactor deprecated strncpy
Date: Fri, 28 Jul 2023 11:38:09 -0700 [thread overview]
Message-ID: <202307281133.16D4305@keescook> (raw)
In-Reply-To: <ZMNILDgqHEGf8fNF@mattapan.m5p.com>
On Thu, Jul 27, 2023 at 09:46:36PM -0700, Elliott Mitchell wrote:
> On Thu, Jul 27, 2023 at 09:53:24PM +0000, Justin Stitt wrote:
> > Technically, my patch yields subtly different behavior. The original
> > implementation with `strncpy` would fill the entire destination buffer
> > with null bytes [3] while `strscpy` will leave the junk, uninitialized
> > bytes trailing after the _mandatory_ NUL-termination. So, if somehow
> > `pcm->name` or `card->driver/shortname/longname` require this
> > NUL-padding behavior then `strscpy_pad` should be used. My
> > interpretation, though, is that the aforementioned fields are just fine
> > as NUL-terminated strings. Please correct my assumptions if needed and
> > I'll send in a v2.
>
> "uninitialized bytes" => "leak of sensitive information" => "security hole"
For xen_snd_front_alsa_init(), "card" is already zero-initialized in
snd_card_new().
For new_pcm_instance(), "pcm" is already zero-initialized in
_snd_pcm_new().
So things look good to me!
Reviewed-by: Kees Cook <keescook@chromium.org>
--
Kees Cook
next prev parent reply other threads:[~2023-07-28 18:39 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-27 21:53 [PATCH] ALSA: xen-front: refactor deprecated strncpy Justin Stitt
2023-07-28 4:46 ` Elliott Mitchell
2023-07-28 18:38 ` Kees Cook [this message]
2023-07-29 12:00 ` Takashi Iwai
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=202307281133.16D4305@keescook \
--to=keescook@chromium.org \
--cc=alsa-devel@alsa-project.org \
--cc=ehem+xen@m5p.com \
--cc=justinstitt@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=oleksandr_andrushchenko@epam.com \
--cc=perex@perex.cz \
--cc=tiwai@suse.com \
--cc=xen-devel@lists.xenproject.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.