[PATCH] regmap: irq: Fix possible ZERO_SIZE_PTR pointer dereferencing error.

[PATCH] regmap: irq: Fix possible ZERO_SIZE_PTR pointer dereferencing error.

[Xiubo Li]

Since we cannot make sure the 'chip->num_regs' will always be none zero
from the users, and then if 'chip->num_regs' equals to zero by mistake
or other reasons, the kzalloc() will return ZERO_SIZE_PTR, which equals
to ((void *)16).

So this patch fix this with just checking the 'chip->num_regs' before
calling kzalloc().

This also sorts the header files in alphabetical order at the same time.

Signed-off-by: Xiubo Li <Li.Xiubo@freescale.com>
---
 drivers/base/regmap/regmap-irq.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/base/regmap/regmap-irq.c b/drivers/base/regmap/regmap-irq.c
index edf88f2..6299a50 100644
--- a/drivers/base/regmap/regmap-irq.c
+++ b/drivers/base/regmap/regmap-irq.c
@@ -10,13 +10,13 @@
  * published by the Free Software Foundation.
  */
 
-#include <linux/export.h>
 #include <linux/device.h>
-#include <linux/regmap.h>
-#include <linux/irq.h>
+#include <linux/export.h>
 #include <linux/interrupt.h>
+#include <linux/irq.h>
 #include <linux/irqdomain.h>
 #include <linux/pm_runtime.h>
+#include <linux/regmap.h>
 #include <linux/slab.h>
 
 #include "internal.h"
@@ -347,6 +347,9 @@ int regmap_add_irq_chip(struct regmap *map, int irq, int irq_flags,
 	int ret = -ENOMEM;
 	u32 reg;
 
+	if (chip->num_regs <= 0)
+		return -EINVAL;
+
 	for (i = 0; i < chip->num_irqs; i++) {
 		if (chip->irqs[i].reg_offset % map->reg_stride)
 			return -EINVAL;
-- 
1.8.4

Re: [PATCH] regmap: irq: Fix possible ZERO_SIZE_PTR pointer dereferencing error.

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 626 bytes --]

On Mon, May 19, 2014 at 03:13:45PM +0800, Xiubo Li wrote:
> Since we cannot make sure the 'chip->num_regs' will always be none zero
> from the users, and then if 'chip->num_regs' equals to zero by mistake
> or other reasons, the kzalloc() will return ZERO_SIZE_PTR, which equals
> to ((void *)16).
> 
> So this patch fix this with just checking the 'chip->num_regs' before
> calling kzalloc().

Where is the actual dereference that's being protected against here?

> This also sorts the header files in alphabetical order at the same time.

No, don't do things like this.  It just makes things harder to review.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

RE: [PATCH] regmap: irq: Fix possible ZERO_SIZE_PTR pointer dereferencing error.

[Li.Xiubo]

> Subject: Re: [PATCH] regmap: irq: Fix possible ZERO_SIZE_PTR pointer
> dereferencing error.
> 
> On Mon, May 19, 2014 at 03:13:45PM +0800, Xiubo Li wrote:
> > Since we cannot make sure the 'chip->num_regs' will always be none zero
> > from the users, and then if 'chip->num_regs' equals to zero by mistake
> > or other reasons, the kzalloc() will return ZERO_SIZE_PTR, which equals
> > to ((void *)16).
> >
> > So this patch fix this with just checking the 'chip->num_regs' before
> > calling kzalloc().
> 
> Where is the actual dereference that's being protected against here?
> 

Such as:
        d->mask_buf = kzalloc(sizeof(unsigned int) * chip->num_regs,
                              GFP_KERNEL);
        if (!d->mask_buf)
                goto err_alloc;

And then:
        d->mask_buf[irq_data->reg_offset / map->reg_stride] |= irq_data->mask;



> > This also sorts the header files in alphabetical order at the same time.
> 
> No, don't do things like this.  It just makes things harder to review.

Okay, I'll follow your advice.

Thanks,

BRs
Xiubo

Re: [PATCH] regmap: irq: Fix possible ZERO_SIZE_PTR pointer dereferencing error.

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 316 bytes --]

On Mon, May 19, 2014 at 03:13:45PM +0800, Xiubo Li wrote:
> Since we cannot make sure the 'chip->num_regs' will always be none zero
> from the users, and then if 'chip->num_regs' equals to zero by mistake
> or other reasons, the kzalloc() will return ZERO_SIZE_PTR, which equals
> to ((void *)16).

Applied, thanks.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]