All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Carpenter <dan.carpenter@oracle.com>
To: david.henningsson@canonical.com
Cc: alsa-devel@alsa-project.org
Subject: Re: ALSA: hda - hdmi: Do not expose eld data when eld is invalid
Date: Fri, 5 Feb 2016 09:05:15 +0300	[thread overview]
Message-ID: <20160205060515.GA18705@mwanda> (raw)

Hello David Henningsson,

The patch 68e03de98507: "ALSA: hda - hdmi: Do not expose eld data
when eld is invalid" from Feb 19, 2013, leads to the following static
checker warning:

	sound/pci/hda/patch_hdmi.c:460 hdmi_eld_ctl_get()
	error: __memcpy() 'eld->eld_buffer' too small (256 vs 512)

sound/pci/hda/patch_hdmi.c
   437  static int hdmi_eld_ctl_get(struct snd_kcontrol *kcontrol,
   438                          struct snd_ctl_elem_value *ucontrol)
   439  {
   440          struct hda_codec *codec = snd_kcontrol_chip(kcontrol);
   441          struct hdmi_spec *spec = codec->spec;
   442          struct hdmi_spec_per_pin *per_pin;
   443          struct hdmi_eld *eld;
   444          int pin_idx;
   445  
   446          pin_idx = kcontrol->private_value;
   447          per_pin = get_pin(spec, pin_idx);
   448          eld = &per_pin->sink_eld;
   449  
   450          mutex_lock(&per_pin->lock);
   451          if (eld->eld_size > ARRAY_SIZE(ucontrol->value.bytes.data)) {

In the original code we always copied ELD_MAX_SIZE (256) bytes.  Now it
looks like we can copy up to 512 bytes which seems like an information
leak.  I don't know where eld->eld_size is set so I can't say if this is
a real issue or not.  Perhaps it's always a valid value.

   452                  mutex_unlock(&per_pin->lock);
   453                  snd_BUG();
   454                  return -EINVAL;
   455          }
   456  
   457          memset(ucontrol->value.bytes.data, 0,
   458                 ARRAY_SIZE(ucontrol->value.bytes.data));
   459          if (eld->eld_valid)
   460                  memcpy(ucontrol->value.bytes.data, eld->eld_buffer,
   461                         eld->eld_size);
   462          mutex_unlock(&per_pin->lock);
   463  
   464          return 0;
   465  }

regards,
dan carpenter

                 reply	other threads:[~2016-02-05  6:05 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20160205060515.GA18705@mwanda \
    --to=dan.carpenter@oracle.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=david.henningsson@canonical.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.