greybus-dev

greybus-dev@lists.linaro.org

25 participants
744 discussions

[PATCH] staging: greybus: use after free in gb_audio_manager_remove_all()

by Dan Carpenter

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

6 years, 1 month

[PATCH] staging: greybus: bootrom: fix uninitialized variables

by Saurav Girepunje

fix uninitialized variables issue found using static code analysis tool (error) Uninitialized variable: offset (error) Uninitialized variable: size Signed-off-by: Saurav Girepunje <saurav.girepunje(a)gmail.com> --- drivers/staging/greybus/bootrom.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/greybus/bootrom.c b/drivers/staging/greybus/bootrom.c index a8efb86..9eabeb3 100644 --- a/drivers/staging/greybus/bootrom.c +++ b/drivers/staging/greybus/bootrom.c @@ -245,7 +245,7 @@ static int gb_bootrom_get_firmware(struct gb_operation *op) struct gb_bootrom_get_firmware_request *firmware_request; struct gb_bootrom_get_firmware_response *firmware_response; struct device *dev = &op->connection->bundle->dev; - unsigned int offset, size; + unsigned int offset = 0, size = 0; enum next_request_type next_request; int ret = 0; -- 1.9.1

6 years, 1 month

[PATCH] staging: greybus: fix fw is NULL but dereferenced.

by Saurav Girepunje

Fix the warning reported by cocci check. Changes: In queue_work fw dereference before it actually get assigned. move queue_work before gb_bootrom_set_timeout. As gb_bootrom_get_firmware () return NEXT_REQ_READY_TO_BOOT only when there is no error and offset + size is actually equal to fw->size. So initialized next_request to NEXT_REQ_GET_FIRMWARE for return in other case. Signed-off-by: Saurav Girepunje <saurav.girepunje(a)gmail.com> --- drivers/staging/greybus/bootrom.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/staging/greybus/bootrom.c b/drivers/staging/greybus/bootrom.c index a8efb86..f54514e 100644 --- a/drivers/staging/greybus/bootrom.c +++ b/drivers/staging/greybus/bootrom.c @@ -246,7 +246,7 @@ static int gb_bootrom_get_firmware(struct gb_operation *op) struct gb_bootrom_get_firmware_response *firmware_response; struct device *dev = &op->connection->bundle->dev; unsigned int offset, size; - enum next_request_type next_request; + enum next_request_type next_request = NEXT_REQ_GET_FIRMWARE; int ret = 0; /* Disable timeouts */ @@ -296,13 +296,11 @@ static int gb_bootrom_get_firmware(struct gb_operation *op) unlock: mutex_unlock(&bootrom->mutex); -queue_work: /* Refresh timeout */ if (!ret && (offset + size == fw->size)) next_request = NEXT_REQ_READY_TO_BOOT; - else - next_request = NEXT_REQ_GET_FIRMWARE; +queue_work: gb_bootrom_set_timeout(bootrom, next_request, NEXT_REQ_TIMEOUT_MS); return ret; -- 1.9.1

6 years, 1 month

[PATCH AUTOSEL 4.9 193/251] staging: greybus: light: fix a couple double frees

by Sasha Levin

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

6 years, 2 months

[PATCH AUTOSEL 4.14 283/371] staging: greybus: light: fix a couple double frees

by Sasha Levin

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

6 years, 2 months

[PATCH AUTOSEL 4.19 518/671] staging: greybus: light: fix a couple double frees

by Sasha Levin

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 010ae1e9c7fb..40680eaf3974 100644 --- a/drivers/staging/greybus/light.c +++ b/drivers/staging/greybus/light.c @@ -1098,21 +1098,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

6 years, 2 months

Potential memory leak in greybus/svc.c

by Navid Emamdoost

Hello, It seems to me there is a memory leak in the implementation of gb_svc_create(). In the error handling path (labeled as err_put_device) the code correctly puts svc->dev, but I am suspicious that svc->wq is leaking. The allocated svc->wq needs a release via destroy_workqueue() in the error handling path. Am I missing something? Thank you, -- Navid.

6 years, 3 months

[PATCH] staging: greybus: add blank line after declarations

by Gabriela Bittencourt

Fix CHECK: add blank line after declarations Signed-off-by: Gabriela Bittencourt <gabrielabittencourt00(a)gmail.com> --- drivers/staging/greybus/control.h | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/staging/greybus/control.h b/drivers/staging/greybus/control.h index 3a29ec05f631..5a45d55349a1 100644 --- a/drivers/staging/greybus/control.h +++ b/drivers/staging/greybus/control.h @@ -24,6 +24,7 @@ struct gb_control { char *vendor_string; char *product_string; }; + #define to_gb_control(d) container_of(d, struct gb_control, dev) struct gb_control *gb_control_create(struct gb_interface *intf); -- 2.20.1

6 years, 5 months

[PATCH] greybus: remove excessive check in gb_connection_hd_cport_quiesce()

by Denis Efremov

Function pointer "hd->driver->cport_quiesce" is already checked at the beginning of gb_connection_hd_cport_quiesce(). Thus, the second check can be removed. Signed-off-by: Denis Efremov <efremov(a)linux.com> --- drivers/greybus/connection.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/greybus/connection.c b/drivers/greybus/connection.c index fc8f57f97ce6..e3799a53a193 100644 --- a/drivers/greybus/connection.c +++ b/drivers/greybus/connection.c @@ -361,9 +361,6 @@ static int gb_connection_hd_cport_quiesce(struct gb_connection *connection) if (connection->mode_switch) peer_space += sizeof(struct gb_operation_msg_hdr); - if (!hd->driver->cport_quiesce) - return 0; - ret = hd->driver->cport_quiesce(hd, connection->hd_cport_id, peer_space, GB_CONNECTION_CPORT_QUIESCE_TIMEOUT); -- 2.21.0

6 years, 5 months

[PATCH v2] staging: greybus: loopback_test: Adding missing brackets into if..else block

by Julio Faracco

Inside a block of if..else conditional, else structure does not contain brackets. This is not following regular policies of kernel coding style. All parts of this conditional blocks should respect brackets inclusion. This commit removes some blank spaces that are not following brackets policies too. Signed-off-by: Julio Faracco <jcfaracco(a)gmail.com> --- Changes from v1: - fixing patch description - including more cases that brackets does not fill kernel code policies. --- --- drivers/staging/greybus/tools/loopback_test.c | 14 +++----------- 1 file changed, 3 insertions(+), 11 deletions(-) diff --git a/drivers/staging/greybus/tools/loopback_test.c b/drivers/staging/greybus/tools/loopback_test.c index ba6f905f2..22e79f197 100644 --- a/drivers/staging/greybus/tools/loopback_test.c +++ b/drivers/staging/greybus/tools/loopback_test.c @@ -238,7 +238,6 @@ static void show_loopback_devices(struct loopback_test *t) for (i = 0; i < t->device_count; i++) printf("device[%d] = %s\n", i, t->devices[i].name); - } int open_sysfs(const char *sys_pfx, const char *node, int flags) @@ -273,7 +272,6 @@ float read_sysfs_float_fd(int fd, const char *sys_pfx, const char *node) char buf[SYSFS_MAX_INT]; if (read(fd, buf, sizeof(buf)) < 0) { - fprintf(stderr, "unable to read from %s%s %s\n", sys_pfx, node, strerror(errno)); close(fd); @@ -366,7 +364,6 @@ static int get_results(struct loopback_test *t) r->apbridge_unipro_latency_max - r->apbridge_unipro_latency_min; r->gbphy_firmware_latency_jitter = r->gbphy_firmware_latency_max - r->gbphy_firmware_latency_min; - } /*calculate the aggregate results of all enabled devices */ @@ -406,7 +403,6 @@ static int get_results(struct loopback_test *t) r->apbridge_unipro_latency_max - r->apbridge_unipro_latency_min; r->gbphy_firmware_latency_jitter = r->gbphy_firmware_latency_max - r->gbphy_firmware_latency_min; - } return 0; @@ -535,8 +531,8 @@ static int log_results(struct loopback_test *t) fprintf(stderr, "unable to open %s for appendation\n", file_name); abort(); } - } + for (i = 0; i < t->device_count; i++) { if (!device_enabled(t, i)) continue; @@ -549,10 +545,8 @@ static int log_results(struct loopback_test *t) if (ret == -1) fprintf(stderr, "unable to write %d bytes to csv.\n", len); } - } - if (t->aggregate_output) { len = format_output(t, &t->aggregate_results, "aggregate", data, sizeof(data), &tm); @@ -739,7 +733,6 @@ static int wait_for_complete(struct loopback_test *t) ts = &t->poll_timeout; while (1) { - ret = ppoll(t->fds, t->poll_count, ts, &mask_old); if (ret <= 0) { stop_tests(t); @@ -801,8 +794,9 @@ static void prepare_devices(struct loopback_test *t) write_sysfs_val(t->devices[i].sysfs_entry, "outstanding_operations_max", t->async_outstanding_operations); - } else + } else { write_sysfs_val(t->devices[i].sysfs_entry, "async", 0); + } } } @@ -879,10 +873,8 @@ static int sanity_check(struct loopback_test *t) fprintf(stderr, "Bad device mask %x\n", (1 << i)); return -1; } - } - return 0; } -- 2.20.1

6 years, 6 months

← Newer
1
...
54
55
56
57
58
59
60
...
75
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

greybus-dev