[PATCH] mtd: gpmi: Fix NULL pointer dereference

Brian Norris computersforpeace at gmail.com
Mon Nov 11 23:24:32 EST 2013


On Mon, Nov 11, 2013 at 7:44 PM, Fabio Estevam <festevam at gmail.com> wrote:
> On Tue, Nov 12, 2013 at 12:47 AM, Huang Shijie <b32955 at freescale.com> wrote:
>> 于 2013年11月12日 02:23, Brian Norris 写道:
>
>> For imx23, the work flow is like this:
>> [1] first check the fingerprint, if we can find it, we will return
>> immediately.
>> [2] if [1] failed, such as you erase all the partitions, the gpmi will call
>> mx23_write_transcription_stamp() to write the fingerprint.
>>
>> So the @chip->buffer is not only used by the
>> mx23_check_transcription_stamp(),
>> but _also_ used by the mx23_write_transcription_stamp() when the gpmi
>> can not find any
>> fingerprint in the NAND page.
>>
>>
>> That's why i use the NAND_OWN_BUFFERS, the buffer can be used by both
>> the mx23_check_transcription_stamp()
>> and mx23_write_transcription_stamp().
>
> Understood.
>
> What if we just allocate the 4-byte buffer once on probe?
>
> Like this:
>
> diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> index a9830ff..647da1b 100644
> --- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> +++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
...
> @@ -1728,6 +1726,10 @@ static int gpmi_nand_probe(struct platform_device *pdev)
>          return -ENOMEM;
>      }
>
> +    this->buffer = devm_kzalloc(&pdev->dev, strlen(fingerprint), GFP_KERNEL);
> +    if (!this->buffer)
> +        return -ENOMEM;
> +
>      platform_set_drvdata(pdev, this);
>      this->pdev  = pdev;
>      this->dev   = &pdev->dev;
...

As Huang noted, this approach is still very fragile. I think it's best
if we rework GPMI's init sequence so that we don't have to do these
kind of fragile dodges any more; just do all the BBT scanning after
nand_scan_tail(). Let's wait for Huang's version of my suggestion.

Brian



More information about the linux-mtd mailing list