Automated static analysis via Coccinelle uncovered a potential null pointer dereference and uninitialized stack pointer vulnerability inside gb_bootrom_get_firmware().
The routine evaluates whether a firmware transmission sequence is complete at its trailing 'queue_work:' label by checking if the transfer bounds match 'fw->size'. When this label is reached the 'fw' can be uninitialized or NULL. Both scenarios expose the kernel to critical memory faults or null pointer panics.
Fix these dual vulnerability paths by initializing the 'fw' pointer to NULL at its top-level definition block and introducing an explicit short-circuit guard condition to safely gate the trailing size evaluation.
Assisted-by: Gemini Signed-off-by: Marinela Tatiana Selseth marinela.selseth@firmwaredesign.org --- drivers/staging/greybus/bootrom.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/greybus/bootrom.c b/drivers/staging/greybus/bootrom.c index 83921d90c322..cead4b505f6c 100644 --- a/drivers/staging/greybus/bootrom.c +++ b/drivers/staging/greybus/bootrom.c @@ -241,7 +241,7 @@ static int gb_bootrom_firmware_size_request(struct gb_operation *op) static int gb_bootrom_get_firmware(struct gb_operation *op) { struct gb_bootrom *bootrom = gb_connection_get_data(op->connection); - const struct firmware *fw; + const struct firmware *fw = NULL; struct gb_bootrom_get_firmware_request *firmware_request; struct device *dev = &op->connection->bundle->dev; unsigned int offset, size; @@ -298,7 +298,7 @@ static int gb_bootrom_get_firmware(struct gb_operation *op)
queue_work: /* Refresh timeout */ - if (!ret && (offset + size == fw->size)) + if (fw && !ret && (offset + size == fw->size)) next_request = NEXT_REQ_READY_TO_BOOT; else next_request = NEXT_REQ_GET_FIRMWARE;