Project

General

Profile

Actions

Bug #64545

open

crimson: OrderedConcurrentPhase::ExitBarrier::exit() does not guarrantee that phase survives

Added by Samuel Just 2 months ago. Updated 2 months ago.

Status:
New
Priority:
Normal
Assignee:
Category:
-
Target version:
-
% Done:

0%

Source:
Tags:
Backport:
Regression:
No
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
Pull request ID:
Crash signature (v1):
Crash signature (v2):

Description

    void exit() final {
      if (barrier) {
        assert(phase);
        assert(phase->core == seastar::this_shard_id());
        std::ignore = std::move(*barrier
        ).then([phase=this->phase] {
          phase->mutex.unlock();
        });
        barrier = std::nullopt;
        phase = nullptr;
      } else if (phase) {
        assert(phase->core == seastar::this_shard_id());
        phase->mutex.unlock();
        phase = nullptr;
      }
    }

phase->mutex.unlock() can occur significantly after exit() finishes. *phase will generally be embedded in a PG or a Connection, so it's often but not always safe.

https://tracker.ceph.com/issues/63647 was a more dangerous variant because *phase was part of the operation itself.


Related issues 1 (1 open0 closed)

Related to crimson - Bug #63647: SnapTrimEvent AddressSanitizer: heap-use-after-freeIn Progress

Actions
Actions #1

Updated by Samuel Just 2 months ago

  • Related to Bug #64513: crimson: stack-use-after-free in build_incremental_map_msg added
Actions #2

Updated by Samuel Just 2 months ago

  • Description updated (diff)
Actions #3

Updated by Samuel Just 2 months ago

  • Related to deleted (Bug #64513: crimson: stack-use-after-free in build_incremental_map_msg)
Actions #4

Updated by Samuel Just 2 months ago

  • Related to Bug #63647: SnapTrimEvent AddressSanitizer: heap-use-after-free added
Actions #5

Updated by Samuel Just 2 months ago

  • Description updated (diff)
Actions

Also available in: Atom PDF