From: Tim Gardner <tim.gardner(a)canonical.com>
[ Upstream commit 37a1a2e6eeeb101285cd34e12e48a881524701aa ]
Coverity complains of a possible buffer overflow. However,
given the 'static' scope of nvidia_setup_i2c_bus() it looks
like that can't happen after examiniing the call sites.
CID 19036 (#1 of 1): Copy into fixed size buffer (STRING_OVERFLOW)
1. fixed_size_dest: You might overrun the 48-character fixed-size string
chan->adapter.name by copying name without checking the length.
2. parameter_as_source: Note: This defect has an elevated risk because the
source argument is a parameter of the current function.
89 strcpy(chan->adapter.name, name);
Fix this warning by using strscpy() which will silence the warning and
prevent any future buffer overflows should the names used to identify the
channel become much longer.
Cc: Antonino Daplas <adaplas(a)gmail.com>
Cc: linux-fbdev(a)vger.kernel.org
Cc: dri-devel(a)lists.freedesktop.org
Cc: linux-kernel(a)vger.kernel.org
Signed-off-by: Tim Gardner <tim.gardner(a)canonical.com>
Signed-off-by: Helge Deller <deller(a)gmx.de>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
drivers/video/fbdev/nvidia/nv_i2c.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/nvidia/nv_i2c.c b/drivers/video/fbdev/nvidia/nv_i2c.c
index d7994a173245..0b48965a6420 100644
--- a/drivers/video/fbdev/nvidia/nv_i2c.c
+++ b/drivers/video/fbdev/nvidia/nv_i2c.c
@@ -86,7 +86,7 @@ static int nvidia_setup_i2c_bus(struct nvidia_i2c_chan *chan, const char *name,
{
int rc;
- strcpy(chan->adapter.name, name);
+ strscpy(chan->adapter.name, name, sizeof(chan->adapter.name));
chan->adapter.owner = THIS_MODULE;
chan->adapter.class = i2c_class;
chan->adapter.algo_data = &chan->algo;
--
2.34.1
From: Ranjani Sridharan <ranjani.sridharan(a)linux.intel.com>
[ Upstream commit 2ce0d008dcc59f9c01f43277b9f9743af7b01dad ]
The limitation to assign a link DMA channel for a BE iff the
corresponding host DMA channel is assigned to a connected FE is only
applicable if the PROCEN_FMT_QUIRK is set. So, remove it for platforms
that do not enable the quirk.
Complements: a792bfc1c2bc ("ASoC: SOF: Intel: hda-stream: limit PROCEN workaround")
Signed-off-by: Ranjani Sridharan <ranjani.sridharan(a)linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com>
Reviewed-by: Rander Wang <rander.wang(a)intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen(a)linux.intel.com>
Reviewed-by: Peter Ujfalusi <peter.ujfalusi(a)linux.intel.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)linux.intel.com>
Link: https://lore.kernel.org/r/20220128130017.28508-1-peter.ujfalusi@linux.intel…
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
sound/soc/sof/intel/hda-dai.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/sound/soc/sof/intel/hda-dai.c b/sound/soc/sof/intel/hda-dai.c
index b3cdd10c83ae..80e3a02e629f 100644
--- a/sound/soc/sof/intel/hda-dai.c
+++ b/sound/soc/sof/intel/hda-dai.c
@@ -57,6 +57,8 @@ static struct hdac_ext_stream *
{
struct snd_soc_pcm_runtime *rtd = substream->private_data;
struct sof_intel_hda_stream *hda_stream;
+ const struct sof_intel_dsp_desc *chip;
+ struct snd_sof_dev *sdev;
struct hdac_ext_stream *res = NULL;
struct hdac_stream *stream = NULL;
@@ -75,9 +77,20 @@ static struct hdac_ext_stream *
continue;
hda_stream = hstream_to_sof_hda_stream(hstream);
+ sdev = hda_stream->sdev;
+ chip = get_chip_info(sdev->pdata);
/* check if link is available */
if (!hstream->link_locked) {
+ /*
+ * choose the first available link for platforms that do not have the
+ * PROCEN_FMT_QUIRK set.
+ */
+ if (!(chip->quirks & SOF_INTEL_PROCEN_FMT_QUIRK)) {
+ res = hstream;
+ break;
+ }
+
if (stream->opened) {
/*
* check if the stream tag matches the stream
--
2.34.1
On Wed, Mar 30, 2022 at 06:28:33AM -0400, Joshua Freedman wrote:
> I'm a mortgage broker but I can figure this out.
>
> Am I doing this:
> git clone git://
> git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-stable
>
> and then git good and bad for for 5.16.11 and 5.16.12 and putting that to a
> log file that you can use?
Yes, that is exactly right!
thanks,
greg k-h