consumer_add() publishes a consumer on uprobe->consumers
before assigning its session ID. handler_chain() traverses the consumer
list under the trace RCU read-side critical section and can therefore
observe the new consumer while uc->id still contains its initial value.
The race is reachable when an uprobe at the same inode:offset is already
active and a task hits its entry breakpoint while another CPU registers a
second session consumer. handler_chain() may store the stale ID in the
return_instance consumer array. By the time the function returns,
uc->id has been assigned a nonzero value, so return_consumer_find() fails
to match the saved ID and the session ret_handler is incorrectly skipped.
consumer_rwsem does not close this window because handler_chain() is an RCU
reader and does not take that rwsem. Assign the ID before list_add_rcu()
publishes the consumer; the release publish of the list node then orders
the initialized ID before readers that traverse the list.
Found during a static-analysis-assisted audit: candidate sites were
surfaced by a Coccinelle rule, and the reader/writer paths were
confirmed by LLM-assisted (GLM-5.3) code inspection. The issue was
not observed at runtime; it is identified by code inspection only.
Fixes: 4d756095d399 ("uprobe: Add support for session consumer")
Signed-off-by: Binbin Deng <[email protected]>
---
kernel/events/uprobes.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index 7709ea882477..83e6aef61181 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -1032,8 +1032,8 @@ static void consumer_add(struct uprobe *uprobe, struct
uprobe_consumer *uc)
static atomic64_t id;
down_write(&uprobe->consumer_rwsem);
- list_add_rcu(&uc->cons_node, &uprobe->consumers);
uc->id = (__u64) atomic64_inc_return(&id);
+ list_add_rcu(&uc->cons_node, &uprobe->consumers);
up_write(&uprobe->consumer_rwsem);
}
--
2.43.0
