Nothing outside of low level architecture code is supposed to look up
interrupt descriptors and fiddle with them.
Replace the open coded abuse by calling generic_handle_irq().
This still does not explain why and in which context this connection
magic is injecting interrupts in the first place and why this is correct
and safe, but at least the API abuse is gone.
Fixes: 036aad9d0224 ("greybus: gpio: add interrupt handling support")
Fixes: 2611ebef8322 ("greybus: gpio: don't call irq-flow handler directly")
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
---
drivers/staging/greybus/gpio.c | 15 ++++++---------
1 file changed, 6 insertions(+), 9 deletions(-)
--- a/drivers/staging/greybus/gpio.c
+++ b/drivers/staging/greybus/gpio.c
@@ -364,8 +364,7 @@ static int gb_gpio_request_handler(struc
struct gb_message *request;
struct gb_gpio_irq_event_request *event;
u8 type = op->type;
- int irq;
- struct irq_desc *desc;
+ int irq, ret;
if (type != GB_GPIO_TYPE_IRQ_EVENT) {
dev_err(dev, "unsupported unsolicited request: %u\n", type);
@@ -391,17 +390,15 @@ static int gb_gpio_request_handler(struc
dev_err(dev, "failed to find IRQ\n");
return -EINVAL;
}
- desc = irq_to_desc(irq);
- if (!desc) {
- dev_err(dev, "failed to look up irq\n");
- return -EINVAL;
- }
local_irq_disable();
- generic_handle_irq_desc(desc);
+ ret = generic_handle_irq(irq);
local_irq_enable();
- return 0;
+ if (ret)
+ dev_err(dev, "failed to invoke irq handler\n");
+
+ return ret;
}
static int gb_gpio_request(struct gpio_chip *chip, unsigned int offset)
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertenly introduced[3] to the codebase from now on.
This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavo(a)embeddedor.com>
---
drivers/staging/greybus/raw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/greybus/raw.c b/drivers/staging/greybus/raw.c
index 838acbe84ca0..2b301b2aa107 100644
--- a/drivers/staging/greybus/raw.c
+++ b/drivers/staging/greybus/raw.c
@@ -30,7 +30,7 @@ struct gb_raw {
struct raw_data {
struct list_head entry;
u32 len;
- u8 data[0];
+ u8 data[];
};
static struct class *raw_class;
--
2.25.0
When we call kobject_put() and it's the last reference to the kobject
then it calls gb_audio_module_release() and frees module. We dereference
"module" on the next line which is a use after free.
Fixes: c77f85bbc91a ("greybus: audio: Fix incorrect counting of 'ida'")
Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com>
---
drivers/staging/greybus/audio_manager.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/greybus/audio_manager.c b/drivers/staging/greybus/audio_manager.c
index 9b19ea9d3fa1..9a3f7c034ab4 100644
--- a/drivers/staging/greybus/audio_manager.c
+++ b/drivers/staging/greybus/audio_manager.c
@@ -92,8 +92,8 @@ void gb_audio_manager_remove_all(void)
list_for_each_entry_safe(module, next, &modules_list, list) {
list_del(&module->list);
- kobject_put(&module->kobj);
ida_simple_remove(&module_id, module->id);
+ kobject_put(&module->kobj);
}
is_empty = list_empty(&modules_list);
--
2.11.0
From: Dan Carpenter <dan.carpenter(a)oracle.com>
[ Upstream commit 329101244f214952606359d254ae883b7109e1a5 ]
The problem is in gb_lights_request_handler(). If we get a request to
change the config then we release the light with gb_lights_light_release()
and re-allocated it. However, if the allocation fails part way through
then we call gb_lights_light_release() again. This can lead to a couple
different double frees where we haven't cleared out the original values:
gb_lights_light_v4l2_unregister(light);
...
kfree(light->channels);
kfree(light->name);
I also made a small change to how we set "light->channels_count = 0;".
The original code handled this part fine and did not cause a use after
free but it was sort of complicated to read.
Fixes: 2870b52bae4c ("greybus: lights: add lights implementation")
Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Acked-by: Rui Miguel Silva <rmfrfs(a)gmail.com>
Link: https://lore.kernel.org/r/20190829122839.GA20116@mwanda
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
drivers/staging/greybus/light.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/greybus/light.c b/drivers/staging/greybus/light.c
index 9f01427f35f9..1cb82cc28aa7 100644
--- a/drivers/staging/greybus/light.c
+++ b/drivers/staging/greybus/light.c
@@ -1102,21 +1102,21 @@ static void gb_lights_channel_release(struct gb_channel *channel)
static void gb_lights_light_release(struct gb_light *light)
{
int i;
- int count;
light->ready = false;
- count = light->channels_count;
-
if (light->has_flash)
gb_lights_light_v4l2_unregister(light);
+ light->has_flash = false;
- for (i = 0; i < count; i++) {
+ for (i = 0; i < light->channels_count; i++)
gb_lights_channel_release(&light->channels[i]);
- light->channels_count--;
- }
+ light->channels_count = 0;
+
kfree(light->channels);
+ light->channels = NULL;
kfree(light->name);
+ light->name = NULL;
}
static void gb_lights_release(struct gb_lights *glights)
--
2.20.1
From: Dan Carpenter <dan.carpenter(a)oracle.com>
[ Upstream commit 329101244f214952606359d254ae883b7109e1a5 ]
The problem is in gb_lights_request_handler(). If we get a request to
change the config then we release the light with gb_lights_light_release()
and re-allocated it. However, if the allocation fails part way through
then we call gb_lights_light_release() again. This can lead to a couple
different double frees where we haven't cleared out the original values:
gb_lights_light_v4l2_unregister(light);
...
kfree(light->channels);
kfree(light->name);
I also made a small change to how we set "light->channels_count = 0;".
The original code handled this part fine and did not cause a use after
free but it was sort of complicated to read.
Fixes: 2870b52bae4c ("greybus: lights: add lights implementation")
Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Acked-by: Rui Miguel Silva <rmfrfs(a)gmail.com>
Link: https://lore.kernel.org/r/20190829122839.GA20116@mwanda
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
drivers/staging/greybus/light.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/greybus/light.c b/drivers/staging/greybus/light.c
index 0f538b8c3a07..4e7575147775 100644
--- a/drivers/staging/greybus/light.c
+++ b/drivers/staging/greybus/light.c
@@ -1103,21 +1103,21 @@ static void gb_lights_channel_release(struct gb_channel *channel)
static void gb_lights_light_release(struct gb_light *light)
{
int i;
- int count;
light->ready = false;
- count = light->channels_count;
-
if (light->has_flash)
gb_lights_light_v4l2_unregister(light);
+ light->has_flash = false;
- for (i = 0; i < count; i++) {
+ for (i = 0; i < light->channels_count; i++)
gb_lights_channel_release(&light->channels[i]);
- light->channels_count--;
- }
+ light->channels_count = 0;
+
kfree(light->channels);
+ light->channels = NULL;
kfree(light->name);
+ light->name = NULL;
}
static void gb_lights_release(struct gb_lights *glights)
--
2.20.1