Re: [PATCH] SCSI: mvsas: Fix NULL pointer dereference in mvs_slot_task_free

From: Johannes Thumshirn
Date: Wed Oct 21 2015 - 10:29:09 EST


On Wed, 2015-10-21 at 17:26 +0300, DÄvis MosÄns wrote:
> 2015-10-21 16:47 GMT+03:00 Johannes Thumshirn <jthumshirn@xxxxxxx>:
> > On Wed, 2015-10-21 at 16:18 +0300, DÄvis MosÄns wrote:
> > > 2015-10-21 10:33 GMT+03:00 Johannes Thumshirn <jthumshirn@xxxxxxx
> > > >:
> > > > On Tue, 2015-10-20 at 20:41 +0300, DÄvis MosÄns wrote:
> > > > > 2015-08-21 7:29 GMT+03:00 DÄvis MosÄns <davispuh@xxxxxxxxx>:
> > > > > > When pci_pool_alloc fails in mvs_task_prep then task-
> > > > > > >lldd_task
> > > > > > stays
> > > > > > NULL but it's later used in mvs_abort_task as slot which is
> > > > > > passed
> > > > > > to mvs_slot_task_free causing NULL pointer dereference.
> > > > > >
> > > > > > Just return from mvs_slot_task_free when passed with NULL
> > > > > > slot.
> > > > > >
> > > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=10189
> > > > > > 1
> > > > > > Signed-off-by: DÄvis MosÄns <davispuh@xxxxxxxxx>
> > > > > > ---
> > > > > > Âdrivers/scsi/mvsas/mv_sas.c | 2 ++
> > > > > > Â1 file changed, 2 insertions(+)
> > > > > >
> > > > > > diff --git a/drivers/scsi/mvsas/mv_sas.c
> > > > > > b/drivers/scsi/mvsas/mv_sas.c
> > > > > > index 454536c..9c78074 100644
> > > > > > --- a/drivers/scsi/mvsas/mv_sas.c
> > > > > > +++ b/drivers/scsi/mvsas/mv_sas.c
> > > > > > @@ -887,6 +887,8 @@ static void mvs_slot_free(struct
> > > > > > mvs_info
> > > > > > *mvi,
> > > > > > u32 rx_desc)
> > > > > > Âstatic void mvs_slot_task_free(struct mvs_info *mvi,
> > > > > > struct
> > > > > > sas_task *task,
> > > > > > ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂstruct mvs_slot_info *slot, u32
> > > > > > slot_idx)
> > > > > > Â{
> > > > > > +ÂÂÂÂÂÂÂif (!slot)
> > > > > > +ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂreturn;
> > > > > > ÂÂÂÂÂÂÂÂif (!slot->task)
> > > > > > ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂreturn;
> > > > > > ÂÂÂÂÂÂÂÂif (!sas_protocol_ata(task->task_proto))
> > > > > > --
> > > > > > 2.5.0
> > > > > >
> > > > >
> > > > > Can this get merged?
> > > > > So far since august it have saved me from several kernel
> > > > > crashes.
> > > >
> > > > If it saved you from several crashes, it probably should be
> > > > tagged
> > > > for
> > > > stable, shouldn't it?
> > > >
> > > > Reviewed-by: Johannes Thumshirn <jthumshirn@xxxxxxx>
> > > >
> > > >
> > >
> > > I don't really know how that works... this is my first patch so
> > > I'm
> > > not really concerned about in which version it gets in as long as
> > > it
> > > does.
> > > I've been compiling kernel with this patch for these months so
> > > for me
> > > it
> > > doesn't really make any difference.
> >
> > You can add
> > Cc: stable@xxxxxxxxxxxxxxx
> > somewhere around your Signed-off-by
> >
> > Documentation/stable_kernel_rules.txt has all the process
> > documentation.
>
> Should I add it together with review tags too and resend patch or
> reply to this
> thread with it edited or just leave it like it is now and whoever
> will see it
> will add it himself?

good question, but I think James can help here.

>
>
> also for stable requirements this line is a bit confusing
> "It or an equivalent fix must already exist in Linus' tree
> (upstream)."
>
> but then later seems it's not requirement for Option 1

yes, if you tag it with the Cc, it will get to stable review _after_ it
is applied to Linus' tree
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/