From: Tomasz Figa <tomasz.figa@gmail.com>
To: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>,
Mark Brown <broonie@kernel.org>
Cc: Ben Dooks <ben-linux@fluff.org>,
Kukjin Kim <kgene.kim@samsung.com>,
Sangbeom Kim <sbkim73@samsung.com>,
Liam Girdwood <lgirdwood@gmail.com>,
Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.de>,
linux-arm-kernel@lists.infradead.org,
linux-samsung-soc@vger.kernel.org, alsa-devel@alsa-project.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Fix for possible null pointer dereference in dma.c
Date: Tue, 20 May 2014 21:16:59 +0200 [thread overview]
Message-ID: <537BAA2B.9090906@gmail.com> (raw)
In-Reply-To: <CAFo99gZ3kVGn04we5OtRtbkceYRs6SiHXRyoX1Gb-SknJH=z=w@mail.gmail.com>
Hi Rickard,
On 20.05.2014 21:12, Rickard Strandqvist wrote:
> Hi Tomasz
>
> What I based my patch on is really because of this line:
> if (substream)
> snd_pcm_period_elapsed(substream);
>
> Boojin Kim thought that this was needed, if this is true anymore..? I
> have not been able to immerse myself so much in all patches.
> I'm working on about 100 similar patches.
To me having NULL as either data argument of buffer done callback or
private_data would be a serious driver bug and IMHO it's better to let
it crash with a NULL pointer dereference to let someone notice than mask
it by adding a condition.
Still, I'm not too experienced with ALSA and ASoC, so I might be wrong.
Mark, what do you think about this?
Best regards,
Tomasz
>
> 344b4c48 sound/soc/samsung/dma.c (Boojin Kim 2011-09-02
> 09:44:43 +0900 123) prtd->dma_pos += prtd->dma_period;
> 344b4c48 sound/soc/samsung/dma.c (Boojin Kim 2011-09-02
> 09:44:43 +0900 124) if (prtd->dma_pos >= prtd->dma_end)
> 344b4c48 sound/soc/samsung/dma.c (Boojin Kim 2011-09-02
> 09:44:43 +0900 125) prtd->dma_pos =
> prtd->dma_start;
> 5111c075 sound/soc/s3c24xx/s3c24xx-pcm.c (Mark Brown 2008-04-30
> 17:19:32 +0200 126)
> 344b4c48 sound/soc/samsung/dma.c (Boojin Kim 2011-09-02
> 09:44:43 +0900 127) if (substream)
> 344b4c48 sound/soc/samsung/dma.c (Boojin Kim 2011-09-02
> 09:44:43 +0900 128)
> snd_pcm_period_elapsed(substream);
> c0f41bb1 sound/soc/s3c24xx/s3c24xx-pcm.c (Ben Dooks 2007-02-14
> 13:20:03 +0100 129)
> 344b4c48 sound/soc/samsung/dma.c (Boojin Kim 2011-09-02
> 09:44:43 +0900 130) spin_lock(&prtd->lock);
>
>
> Best regards
> Rickard Strandqvist
>
>
> 2014-05-19 12:52 GMT+02:00 Tomasz Figa <tomasz.figa@gmail.com>:
>> Hi Rickard,
>>
>> On 15.05.2014 23:57, Rickard Strandqvist wrote:
>>> There is otherwise a risk of a possible null pointer dereference.
>>>
>>> Was largely found by using a static code analysis program called cppcheck.
>>>
>>> Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
>>> ---
>>> sound/soc/samsung/dma.c | 10 ++++++----
>>> 1 fil ändrad, 6 tillägg(+), 4 borttagningar(-)
>>>
>>> diff --git a/sound/soc/samsung/dma.c b/sound/soc/samsung/dma.c
>>> index dc09b71..b1f6757 100644
>>> --- a/sound/soc/samsung/dma.c
>>> +++ b/sound/soc/samsung/dma.c
>>> @@ -115,17 +115,19 @@ static void dma_enqueue(struct snd_pcm_substream *substream)
>>> static void audio_buffdone(void *data)
>>> {
>>> struct snd_pcm_substream *substream = data;
>>> - struct runtime_data *prtd = substream->runtime->private_data;
>>> + struct runtime_data *prtd = NULL;
>>>
>>> pr_debug("Entered %s\n", __func__);
>>>
>>> - if (prtd->state & ST_RUNNING) {
>>> + if(substream)
>>> + prtd = substream->runtime->private_data;
>>> +
>>> + if (prtd && prtd->state & ST_RUNNING) {
>>> prtd->dma_pos += prtd->dma_period;
>>> if (prtd->dma_pos >= prtd->dma_end)
>>> prtd->dma_pos = prtd->dma_start;
>>>
>>> - if (substream)
>>> - snd_pcm_period_elapsed(substream);
>>> + snd_pcm_period_elapsed(substream);
>>>
>>> spin_lock(&prtd->lock);
>>> if (!samsung_dma_has_circular()) {
>>>
>>
>> Can you find a path (or use case, if possible) on which any of affected
>> pointers will be NULL?
>>
>> Best regards,
>> Tomasz
WARNING: multiple messages have this Message-ID (diff)
From: tomasz.figa@gmail.com (Tomasz Figa)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] Fix for possible null pointer dereference in dma.c
Date: Tue, 20 May 2014 21:16:59 +0200 [thread overview]
Message-ID: <537BAA2B.9090906@gmail.com> (raw)
In-Reply-To: <CAFo99gZ3kVGn04we5OtRtbkceYRs6SiHXRyoX1Gb-SknJH=z=w@mail.gmail.com>
Hi Rickard,
On 20.05.2014 21:12, Rickard Strandqvist wrote:
> Hi Tomasz
>
> What I based my patch on is really because of this line:
> if (substream)
> snd_pcm_period_elapsed(substream);
>
> Boojin Kim thought that this was needed, if this is true anymore..? I
> have not been able to immerse myself so much in all patches.
> I'm working on about 100 similar patches.
To me having NULL as either data argument of buffer done callback or
private_data would be a serious driver bug and IMHO it's better to let
it crash with a NULL pointer dereference to let someone notice than mask
it by adding a condition.
Still, I'm not too experienced with ALSA and ASoC, so I might be wrong.
Mark, what do you think about this?
Best regards,
Tomasz
>
> 344b4c48 sound/soc/samsung/dma.c (Boojin Kim 2011-09-02
> 09:44:43 +0900 123) prtd->dma_pos += prtd->dma_period;
> 344b4c48 sound/soc/samsung/dma.c (Boojin Kim 2011-09-02
> 09:44:43 +0900 124) if (prtd->dma_pos >= prtd->dma_end)
> 344b4c48 sound/soc/samsung/dma.c (Boojin Kim 2011-09-02
> 09:44:43 +0900 125) prtd->dma_pos =
> prtd->dma_start;
> 5111c075 sound/soc/s3c24xx/s3c24xx-pcm.c (Mark Brown 2008-04-30
> 17:19:32 +0200 126)
> 344b4c48 sound/soc/samsung/dma.c (Boojin Kim 2011-09-02
> 09:44:43 +0900 127) if (substream)
> 344b4c48 sound/soc/samsung/dma.c (Boojin Kim 2011-09-02
> 09:44:43 +0900 128)
> snd_pcm_period_elapsed(substream);
> c0f41bb1 sound/soc/s3c24xx/s3c24xx-pcm.c (Ben Dooks 2007-02-14
> 13:20:03 +0100 129)
> 344b4c48 sound/soc/samsung/dma.c (Boojin Kim 2011-09-02
> 09:44:43 +0900 130) spin_lock(&prtd->lock);
>
>
> Best regards
> Rickard Strandqvist
>
>
> 2014-05-19 12:52 GMT+02:00 Tomasz Figa <tomasz.figa@gmail.com>:
>> Hi Rickard,
>>
>> On 15.05.2014 23:57, Rickard Strandqvist wrote:
>>> There is otherwise a risk of a possible null pointer dereference.
>>>
>>> Was largely found by using a static code analysis program called cppcheck.
>>>
>>> Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
>>> ---
>>> sound/soc/samsung/dma.c | 10 ++++++----
>>> 1 fil ?ndrad, 6 till?gg(+), 4 borttagningar(-)
>>>
>>> diff --git a/sound/soc/samsung/dma.c b/sound/soc/samsung/dma.c
>>> index dc09b71..b1f6757 100644
>>> --- a/sound/soc/samsung/dma.c
>>> +++ b/sound/soc/samsung/dma.c
>>> @@ -115,17 +115,19 @@ static void dma_enqueue(struct snd_pcm_substream *substream)
>>> static void audio_buffdone(void *data)
>>> {
>>> struct snd_pcm_substream *substream = data;
>>> - struct runtime_data *prtd = substream->runtime->private_data;
>>> + struct runtime_data *prtd = NULL;
>>>
>>> pr_debug("Entered %s\n", __func__);
>>>
>>> - if (prtd->state & ST_RUNNING) {
>>> + if(substream)
>>> + prtd = substream->runtime->private_data;
>>> +
>>> + if (prtd && prtd->state & ST_RUNNING) {
>>> prtd->dma_pos += prtd->dma_period;
>>> if (prtd->dma_pos >= prtd->dma_end)
>>> prtd->dma_pos = prtd->dma_start;
>>>
>>> - if (substream)
>>> - snd_pcm_period_elapsed(substream);
>>> + snd_pcm_period_elapsed(substream);
>>>
>>> spin_lock(&prtd->lock);
>>> if (!samsung_dma_has_circular()) {
>>>
>>
>> Can you find a path (or use case, if possible) on which any of affected
>> pointers will be NULL?
>>
>> Best regards,
>> Tomasz
next prev parent reply other threads:[~2014-05-20 19:16 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-15 21:57 [PATCH] Fix for possible null pointer dereference in dma.c Rickard Strandqvist
2014-05-15 21:57 ` Rickard Strandqvist
2014-05-19 5:39 ` Lothar Waßmann
2014-05-19 5:39 ` Lothar Waßmann
2014-05-19 10:52 ` Tomasz Figa
2014-05-19 10:52 ` Tomasz Figa
2014-05-20 19:12 ` Rickard Strandqvist
2014-05-20 19:12 ` Rickard Strandqvist
2014-05-20 19:16 ` Tomasz Figa [this message]
2014-05-20 19:16 ` Tomasz Figa
2014-05-20 19:29 ` Andrew Eikum
2014-05-20 19:29 ` [alsa-devel] " Andrew Eikum
2014-05-20 19:29 ` Andrew Eikum
2014-05-20 19:31 ` Tomasz Figa
2014-05-20 19:31 ` Tomasz Figa
2014-05-20 21:21 ` Lars-Peter Clausen
2014-05-20 21:21 ` Lars-Peter Clausen
2014-05-20 21:58 ` Mark Brown
2014-05-20 21:58 ` Mark Brown
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=537BAA2B.9090906@gmail.com \
--to=tomasz.figa@gmail.com \
--cc=alsa-devel@alsa-project.org \
--cc=ben-linux@fluff.org \
--cc=broonie@kernel.org \
--cc=kgene.kim@samsung.com \
--cc=lgirdwood@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=perex@perex.cz \
--cc=rickard_strandqvist@spectrumdigital.se \
--cc=sbkim73@samsung.com \
--cc=tiwai@suse.de \
/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.