Re: [PATCH] staging: greybus: bootrom: fix potential NULL dereference

[Dan Carpenter <error27@gmail.com>]

You're using the word "potential" but the commit message correctly
explains why a NULL dereference is impossible.  Don't say potentially
for things which are impossible.

On Fri, Aug 21, 2026 at 07:35:40PM +0800, hanzhijian wrote:
> In gb_bootrom_get_firmware(), the queue_work label dereferences fw->size
> on a path where fw may have been set to NULL via the "if (!fw) goto
> unlock" path.  This is currently masked at runtime by the !ret
> short-circuit (ret is non-zero on every path where fw can be NULL), but
> it relies on an implicit invariant that is fragile and hard to follow.

A lot of people would argue that the original code is easy to follow.  In
your code, to see what is passed on error you have to scroll all the way
to the top of the function to see the "next_request =
NEXT_REQ_GET_FIRMWARE;" assignment.  In the existing code, it's clear,
this is what we pass on error, this is what we pass on success.

It's not really fragile either.  If we screwed up and forgot to set the
error code or something then Smatch would warn about that.

drivers/staging/greybus/bootrom.c:300 gb_bootrom_get_firmware() error: we previously assumed 'fw' could be null (see line 266)

Or on the earlier paths, we would get an uninitialized variable
warning.

regards,
dan carpenter