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:38 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox