* [PATCH] DSPBRIDGE: Fix memory corruption in DRV_ProcFreeDMMRes
@ 2010-02-15 15:36 Ameya Palande
2010-02-15 15:59 ` Felipe Contreras
0 siblings, 1 reply; 4+ messages in thread
From: Ameya Palande @ 2010-02-15 15:36 UTC (permalink / raw)
To: omar.ramirez; +Cc: nm, deepak.chitriki, linux-omap, felipe.contreras, x0095840
This patch fixes following issues:
1. pDMMRes was dereferenced and modified when it was already freed by
PROC_Ummap(). This results in memory corruption.
2.Instead of passing ulDSPAddr, ulDSPResAddr was passed to PROC_UnMap()
which will not retrieve correct DMMRes element.
Signed-off-by: Ameya Palande <ameya.palande@nokia.com>
---
drivers/dsp/bridge/rmgr/drv.c | 15 +++++----------
1 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/dsp/bridge/rmgr/drv.c b/drivers/dsp/bridge/rmgr/drv.c
index 9d5c077..747b34c 100644
--- a/drivers/dsp/bridge/rmgr/drv.c
+++ b/drivers/dsp/bridge/rmgr/drv.c
@@ -273,11 +273,14 @@ DSP_STATUS DRV_ProcFreeDMMRes(HANDLE hPCtxt)
pDMMList = pDMMList->next;
if (pDMMRes->dmmAllocated) {
status = PROC_UnMap(pDMMRes->hProcessor,
- (void *)pDMMRes->ulDSPResAddr, pCtxt);
+ (void *)pDMMRes->ulDSPAddr, pCtxt);
+ /*
+ * PROC_UnMap has freed pDMMRes pointer, so don't access
+ * it now
+ */
if (DSP_FAILED(status))
pr_debug("%s: PROC_UnMap failed! status ="
" 0x%xn", __func__, status);
- pDMMRes->dmmAllocated = 0;
}
}
return status;
@@ -288,17 +291,9 @@ DSP_STATUS DRV_RemoveAllDMMResElements(HANDLE hPCtxt)
{
struct PROCESS_CONTEXT *pCtxt = (struct PROCESS_CONTEXT *)hPCtxt;
DSP_STATUS status = DSP_SOK;
- struct DMM_MAP_OBJECT *pTempDMMRes2 = NULL;
- struct DMM_MAP_OBJECT *pTempDMMRes = NULL;
struct DMM_RSV_OBJECT *temp, *rsv_obj;
DRV_ProcFreeDMMRes(pCtxt);
- pTempDMMRes = pCtxt->dmm_map_list;
- while (pTempDMMRes != NULL) {
- pTempDMMRes2 = pTempDMMRes;
- pTempDMMRes = pTempDMMRes->next;
- kfree(pTempDMMRes2);
- }
pCtxt->dmm_map_list = NULL;
/* Free DMM reserved memory resources */
--
1.6.3.3
^ permalink raw reply related [flat|nested] 4+ messages in thread* Re: [PATCH] DSPBRIDGE: Fix memory corruption in DRV_ProcFreeDMMRes
2010-02-15 15:36 [PATCH] DSPBRIDGE: Fix memory corruption in DRV_ProcFreeDMMRes Ameya Palande
@ 2010-02-15 15:59 ` Felipe Contreras
2010-02-16 12:38 ` Ameya Palande
0 siblings, 1 reply; 4+ messages in thread
From: Felipe Contreras @ 2010-02-15 15:59 UTC (permalink / raw)
To: Ameya Palande
Cc: Omar Ramirez Luna, Nishanth Menon, deepak.chitriki@ti.com,
linux-omap, x0095840@ti.com
On Mon, Feb 15, 2010 at 04:36:31PM +0100, Ameya Palande wrote:
> This patch fixes following issues:
>
> 1. pDMMRes was dereferenced and modified when it was already freed by
> PROC_Ummap(). This results in memory corruption.
>
> 2.Instead of passing ulDSPAddr, ulDSPResAddr was passed to PROC_UnMap()
> which will not retrieve correct DMMRes element.
You forgot to mention that this patch applies on top of your previous
reserve resource cleanup patches.
> Signed-off-by: Ameya Palande <ameya.palande@nokia.com>
And:
Signed-off-by: Felipe Contreras <felipe.contreras@nokia.com>
> ---
> drivers/dsp/bridge/rmgr/drv.c | 15 +++++----------
> 1 files changed, 5 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/dsp/bridge/rmgr/drv.c b/drivers/dsp/bridge/rmgr/drv.c
> index 9d5c077..747b34c 100644
> --- a/drivers/dsp/bridge/rmgr/drv.c
> +++ b/drivers/dsp/bridge/rmgr/drv.c
> @@ -273,11 +273,14 @@ DSP_STATUS DRV_ProcFreeDMMRes(HANDLE hPCtxt)
> pDMMList = pDMMList->next;
> if (pDMMRes->dmmAllocated) {
> status = PROC_UnMap(pDMMRes->hProcessor,
> - (void *)pDMMRes->ulDSPResAddr, pCtxt);
> + (void *)pDMMRes->ulDSPAddr, pCtxt);
> + /*
> + * PROC_UnMap has freed pDMMRes pointer, so don't access
> + * it now
> + */
I don't see the need for this comment on the code.
Cheers.
--
Felipe Contreras
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [PATCH] DSPBRIDGE: Fix memory corruption in DRV_ProcFreeDMMRes
2010-02-15 15:59 ` Felipe Contreras
@ 2010-02-16 12:38 ` Ameya Palande
2010-02-16 17:47 ` Felipe Contreras
0 siblings, 1 reply; 4+ messages in thread
From: Ameya Palande @ 2010-02-16 12:38 UTC (permalink / raw)
To: Contreras Felipe (Nokia-D/Helsinki)
Cc: Omar Ramirez Luna, Nishanth Menon, deepak.chitriki@ti.com,
linux-omap, x0095840@ti.com
Hi Felipe,
On Mon, 2010-02-15 at 16:59 +0100, Contreras Felipe (Nokia-D/Helsinki)
wrote:
> On Mon, Feb 15, 2010 at 04:36:31PM +0100, Ameya Palande wrote:
> > This patch fixes following issues:
> >
> > 1. pDMMRes was dereferenced and modified when it was already freed by
> > PROC_Ummap(). This results in memory corruption.
> >
> > 2.Instead of passing ulDSPAddr, ulDSPResAddr was passed to PROC_UnMap()
> > which will not retrieve correct DMMRes element.
>
> You forgot to mention that this patch applies on top of your previous
> reserve resource cleanup patches.
>
> > Signed-off-by: Ameya Palande <ameya.palande@nokia.com>
>
> And:
> Signed-off-by: Felipe Contreras <felipe.contreras@nokia.com>
>
> > ---
> > drivers/dsp/bridge/rmgr/drv.c | 15 +++++----------
> > 1 files changed, 5 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/dsp/bridge/rmgr/drv.c b/drivers/dsp/bridge/rmgr/drv.c
> > index 9d5c077..747b34c 100644
> > --- a/drivers/dsp/bridge/rmgr/drv.c
> > +++ b/drivers/dsp/bridge/rmgr/drv.c
> > @@ -273,11 +273,14 @@ DSP_STATUS DRV_ProcFreeDMMRes(HANDLE hPCtxt)
> > pDMMList = pDMMList->next;
> > if (pDMMRes->dmmAllocated) {
> > status = PROC_UnMap(pDMMRes->hProcessor,
> > - (void *)pDMMRes->ulDSPResAddr, pCtxt);
> > + (void *)pDMMRes->ulDSPAddr, pCtxt);
> > + /*
> > + * PROC_UnMap has freed pDMMRes pointer, so don't access
> > + * it now
> > + */
>
> I don't see the need for this comment on the code.
In above code segment, just by looking at PROC_Unmap() it is not
apparent that it will deallocate "pDMMRes" thats why that comment is
present there! I guess this whole memory corruption could have been
easily avoided by presence of that comment ;)
Cheers,
Ameya.
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [PATCH] DSPBRIDGE: Fix memory corruption in DRV_ProcFreeDMMRes
2010-02-16 12:38 ` Ameya Palande
@ 2010-02-16 17:47 ` Felipe Contreras
0 siblings, 0 replies; 4+ messages in thread
From: Felipe Contreras @ 2010-02-16 17:47 UTC (permalink / raw)
To: Ameya Palande
Cc: Contreras Felipe (Nokia-D/Helsinki), Omar Ramirez Luna,
Nishanth Menon, deepak.chitriki@ti.com, linux-omap,
x0095840@ti.com
Hi,
On Tue, Feb 16, 2010 at 2:38 PM, Ameya Palande <ameya.palande@nokia.com> wrote:
> Hi Felipe,
>
> On Mon, 2010-02-15 at 16:59 +0100, Contreras Felipe (Nokia-D/Helsinki)
> wrote:
>> On Mon, Feb 15, 2010 at 04:36:31PM +0100, Ameya Palande wrote:
>> > --- a/drivers/dsp/bridge/rmgr/drv.c
>> > +++ b/drivers/dsp/bridge/rmgr/drv.c
>> > @@ -273,11 +273,14 @@ DSP_STATUS DRV_ProcFreeDMMRes(HANDLE hPCtxt)
>> > pDMMList = pDMMList->next;
>> > if (pDMMRes->dmmAllocated) {
>> > status = PROC_UnMap(pDMMRes->hProcessor,
>> > - (void *)pDMMRes->ulDSPResAddr, pCtxt);
>> > + (void *)pDMMRes->ulDSPAddr, pCtxt);
>> > + /*
>> > + * PROC_UnMap has freed pDMMRes pointer, so don't access
>> > + * it now
>> > + */
>>
>> I don't see the need for this comment on the code.
>
> In above code segment, just by looking at PROC_Unmap() it is not
> apparent that it will deallocate "pDMMRes" thats why that comment is
> present there! I guess this whole memory corruption could have been
> easily avoided by presence of that comment ;)
Then the comment should be on PROC_Unmap() I guess.
--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2010-02-16 17:47 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-02-15 15:36 [PATCH] DSPBRIDGE: Fix memory corruption in DRV_ProcFreeDMMRes Ameya Palande
2010-02-15 15:59 ` Felipe Contreras
2010-02-16 12:38 ` Ameya Palande
2010-02-16 17:47 ` Felipe Contreras
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox