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.