Re: [PATCH 1/7] greybus: connection: Export gb_connection_get() and gb_connection_put()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Exporting `gb_connection_get/put` allows connections to outlive their parent objects, causing a Use-After-Free in tracepoints.
--

--- Patch [1]: [PATCH 1/7] greybus: connection: Export gb_connection_get() and gb_connection_put() ---
commit d7d6f3dcc2daeb414806a0f2b9dbabd440f8ec1e
Author: Ayush Singh <ayush@beagleboard.org>

greybus: connection: Export gb_connection_get() and gb_connection_put()

This commit exports gb_connection_get() and gb_connection_put() to allow
modular drivers to manage connection references. It changes them to non-static
and adds EXPORT_SYMBOL_GPL declarations.

> diff --git a/drivers/greybus/connection.c b/drivers/greybus/connection.c
> index bd04485decb3d..f8fda22bc4667 100644
> --- a/drivers/greybus/connection.c
> +++ b/drivers/greybus/connection.c

[ ... ]

> -static void gb_connection_get(struct gb_connection *connection)
> +void gb_connection_get(struct gb_connection *connection)
>  {
>  	kref_get(&connection->kref);
>  
>  	trace_gb_connection_get(connection);
>  }
> +EXPORT_SYMBOL_GPL(gb_connection_get);
>  
> -static void gb_connection_put(struct gb_connection *connection)
> +void gb_connection_put(struct gb_connection *connection)
>  {
>  	trace_gb_connection_put(connection);
>  
>  	kref_put(&connection->kref, gb_connection_kref_release);
>  }
> +EXPORT_SYMBOL_GPL(gb_connection_put);

[Severity: High]
Does exporting this function introduce a regression where a connection can
outlive its parent host device or bundle, potentially causing a use-after-free
in the tracepoints?

If an external module caches a connection reference and drops it asynchronously
after the Greybus core has torn down and freed the gb_bundle and
gb_host_device, calling gb_connection_put() will trigger
trace_gb_connection_put() and potentially trace_gb_connection_release().

These trace events rely on a shared TP_fast_assign block in
drivers/greybus/greybus_trace.h that unconditionally dereferences the parent
objects:

drivers/greybus/greybus_trace.h:gb_connection() {
    TP_fast_assign(
        __entry->hd_bus_id = connection->hd->bus_id;
        __entry->bundle_id = connection->bundle ?
                connection->bundle->id : BUNDLE_ID_NONE;
    ...
}

If the parent hd or bundle has already been freed, will these tracepoints
dereference freed memory?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260820-gb-uart-transport-v1-0-282da14ab7b7@beagleboard.org?part=1