[core][gcs] HandleReportAutoscalingState success callback reads a stack local after return (stack-use-after-return)

Open Beginner friendly
#66,333 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
78/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
cpp
Domain
distributed-systems

Research direction

Start in src/ray/gcs at GcsAutoscalerStateManager::HandleReportAutoscalingState and trace send_reply_callback through ServerCall::OnReplySent. Reproduce with an ASAN build using detect_stack_use_after_return enabled, then verify the success callback no longer reads a handler stack local and the infeasible-resource warning decision remains correct after the handler returns.

Written by the indexing model from the issue text.

Description

community-backlog core stability
What happened + What you expected to happen

GcsAutoscalerStateManager::HandleReportAutoscalingState built its success callback like this:

bool has_new_infeasible_requests = false;
std::function<void()> callback = [this, &has_new_infeasible_requests]() { ... };
// ... then the state-update branches set has_new_infeasible_requests ...
send_reply_callback(ray::Status::OK(), callback, nullptr);

The callback captures has_new_infeasible_requests, a stack local, by reference. It is passed to send_reply_callback and runs later from ServerCall::OnReplySent, after the handler's stack frame is gone. Reading the flag at that point is a stack-use-after-return.

The callback runs on the default configuration path (it decides whether to publish the "infeasible resource requests" error), so the dangling read is live in normal operation, not a corner case. Depending on what has overwritten the stack slot, the infeasible-requests warning is then published spuriously or dropped.

Expected: the success callback must not read stack locals of the handler frame.

Versions / Dependencies

master (674900c91f), all platforms. Observable under a build with detect_stack_use_after_return enabled (ASAN).

Reproduction script

Found by auditing src/ray/gcs for callbacks handed to send_reply_callback that capture handler stack locals by reference. Build with --config=asan and ASAN_OPTIONS=detect_stack_use_after_return=1, report an autoscaling state, and run the success callback after the handler returns: AddressSanitizer reports stack-use-after-return inside the handler's lambda.

Issue Severity

Medium: a stack-use-after-return on the default autoscaler-report path, corrupting the infeasible-request warning decision (read of a freed stack slot).

Dominant language
Python
Stars
43.9k
Forks
8.1k
Avg merge
4d 15h
Merged PRs (30d)
245

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from ray-project/ray

All issues in ray-project/ray

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.