Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [High] Missing module reference counting for RV reactors leads to a Use-After-Free if a reactor module is unloaded while still assigned to a monitor. -- commit ad2a08e6decf463e8a9bfc030b93a95b3cf6f3b1 Author: Wen Yang <[email protected]> rv/reactors: add KUnit tests for reactor registration and dispatch Add KUnit tests covering the reactor register/unregister lifecycle (including duplicate and name-length rejection) and rv_react() dispatch (a no-op without a callback, exactly one invocation with one). > diff --git a/kernel/trace/rv/rv_reactors_kunit.c > b/kernel/trace/rv/rv_reactors_kunit.c > new file mode 100644 > index 0000000000000..3850c6dda288f > --- /dev/null > +++ b/kernel/trace/rv/rv_reactors_kunit.c [ ... ] > +static void reactor_teardown(void *arg) > +{ > + rv_unregister_reactor(&test_reactor); [Severity: High] This is a pre-existing issue, but could rv_unregister_reactor() leave dangling pointers if a dynamically loaded reactor module is unloaded while still assigned to a monitor? Looking at rv_unregister_reactor() in kernel/trace/rv/rv_reactors.c, it removes the reactor from the global list but does not appear to iterate over active monitors to detach it. Furthermore, in monitor_swap_reactors_single(), the reactor is assigned to the monitor without taking a module reference count via try_module_get(): kernel/trace/rv/rv_reactors.c:monitor_swap_reactors_single() { ... mon->reactor = reactor; mon->react = reactor->react; ... } If a user with tracefs access assigns a dynamically loaded reactor (e.g., reactor_printk.ko) to an RV monitor and then unloads the reactor module, when the monitor's tracepoint fires, rv_react() would invoke the dangling monitor->react function pointer. Could this jump into the unmapped memory of the unloaded module and cause a use-after-free? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=4
