CONCURDEP: Event-Guided Analysis of Dependency Invalidation in CPython Concurrency

• 원문: arXiv 2609.28608
• 저자: Baihong Chen, Hadley Westover, Wen Li
• 공개일: 2026-09-25
• 분야: CPython, Native Concurrency, Static Analysis, Memory Safety
• Tags: CPython, Concurrency, FreeThreading, MemorySafety, StaticAnalysis

본 글은 원 논문의 주요 기술적 내용을 이해하기 쉽게 요약·정리한 글입니다. 자세한 내용은 상단의 원문 링크를 참고하세요.

한눈에 보기

CONCURDEP은 CPython의 C 구현에서 객체 수명, borrowed reference, 내부 저장소 포인터, 컨테이너 순회 상태, buffer lease가 동시 실행이나 재진입으로 무효화되는 경로를 찾는 정적 분석기입니다. 단순히 같은 주소에 대한 read/write 충돌을 찾는 대신, 획득 시점의 owner–subject–storage 관계와 나중 사용에 필요한 보안 속성을 복원하고 그 사이에 해당 속성을 깨뜨릴 수 있는 event를 연결합니다.

CPython 3.13, 3.14, 3.15를 대상으로 4,273개의 고유 production fingerprint를 감사해 1,094개를 확인했고, 최종적으로 144개의 distinct root cause를 정리했습니다. 이 중 95개는 동일 native root에 대한 선행 공개 기록을 찾지 못했다고 보고합니다. 180개 matched conformance case는 모두 올바르게 분류했고, 릴리스별 5회 실행 중앙값은 22.13–27.66초, peak RSS는 670–784 MiB였습니다.

연구 배경

PEP 703의 free-threaded CPython은 GIL에 의존하던 암묵적 직렬화를 제거합니다. 그러나 문제는 전형적인 data race에 그치지 않습니다. 예를 들어 list가 빌려준 element, bytearray가 제공한 raw pointer, dictionary traversal cursor, memoryview가 유지한 buffer export는 acquisition과 use 사이의 다른 thread 또는 callback에 의해 취소될 수 있습니다.

강한 참조가 owner 객체를 살려 두더라도 내부 storage address가 resize 이후에도 유효하다는 뜻은 아닙니다. 한 번의 상태 점검도 이후 release를 막지 못합니다. 논문은 이처럼 “어떤 native use가 왜 유효한가”를 property-specific dependency로 나타내야 한다고 봅니다.

공격 모델 / 전제 조건

공격자는 세 가지 trigger class 중 하나를 사용합니다. ordinary-API trigger는 public Python API로 mutable object를 여러 thread에서 공유하고, callback-dependent trigger는 문서화된 Python callback·finalizer·descriptor·codec을 제어하며, native-harness trigger는 정상 C-API extension model 안에서 GIL release나 lifetime interaction을 재현합니다.

공격자가 CPython 내부를 임의 수정하거나 buffer protocol을 위반하는 exporter를 만들 필요는 없습니다. 대상은 documented API behavior와 native memory safety의 위반이며, static report는 가능성만 제시하고 source audit와 ASan·assertion·causal qualification이 실제 trigger와 결과를 확인합니다.

비판적 검토 / 아쉬운 점

가장 중요한 한계는 높은 production confirmation yield가 곧 자동 판정의 precision을 뜻하지 않는다는 점입니다. 4,273개 fingerprint 중 source audit로 1,094개를 확인했으므로 사람이 검토해야 하는 후보가 많습니다. 실제 운영 도입 시 subsystem, reachability, attacker control을 반영한 우선순위 모델이 필요합니다.

두 번째로 144개 root의 security severity가 균일하지 않습니다. ASan crash, assertion abort, impossible serialization state처럼 영향이 다양하고, 모든 root가 원격 코드 실행 가능성을 입증한 것은 아닙니다. 공개 CVE 수, upstream patch 상태, reachable product surface를 별도로 추적해야 위험도를 과장하지 않을 수 있습니다.

세 번째로 분석 정확도는 semantic catalog, points-to result, call graph, event model에 강하게 의존합니다. 연구진도 두 개 acquisition gap을 조사 과정에서 발견했습니다. catalog가 덜 성숙한 다른 C extension 생태계로 옮기면 같은 성능을 보장할 수 없으며, cross-project generalization 실험이 필요합니다.

네 번째로 conventional-GIL 결과는 “GIL이 무용하다”는 뜻이 아닙니다. 해당 모드에서는 callback, finalizer, foreign thread, blocking operation, explicit GIL release 같은 재진입 증거가 있어야 합니다. 따라서 free-threaded 병렬성 문제와 GIL build의 재진입 문제를 분리해 읽어야 합니다.

핵심 Root Cause

구조적 원인은 CPython C 코드가 C type system에 드러나지 않는 owner–subject–storage 계약에 의존하면서, mutation·release·reference drop·callback이 그 계약을 acquisition과 use 사이에 철회할 수 있다는 점입니다. 기존 race detector는 같은 주소의 충돌을 보고하고 lifecycle 분석은 개별 객체 상태를 추적하지만, “이 owner가 이 subject의 이 storage를 유효하게 유지해야 한다”는 관계와 later use를 충분히 연결하지 못합니다.

깨진 보안 불변조건은 “native use가 소비하는 속성은 acquisition부터 마지막 use까지 유지되거나, 동일 속성을 보존하는 interval protection으로 덮여야 한다”입니다. reference ownership, lease, address stability, representation, traversal coherence, callback-sensitive relation은 서로 다른 속성이므로 하나의 guard가 모든 속성을 보존한다고 가정할 수 없습니다.

핵심 공격 원리

CONCURDEP은 dependency D, invalidating event E, later use u를 연결합니다. E가 dependency live region 안에 있고, 같은 runtime target을 가리킬 수 있으며, parallel 또는 re-entrant context에서 overlap할 수 있고, 필요한 속성이 보호되지 않은 상태로 u에 도달하면 candidate를 냅니다.

분석기는 borrowed-object lifetime, storage generation, container traversal, view/lease lifetime, callback re-entry, reference-drop lifetime의 여섯 plugin을 사용합니다. 공통 core는 relation validity, owner·subject lifetime, refcount, storage address·representation, lease·resource state, version, lock depth, GIL state를 product lattice로 전파합니다.

공격 흐름

1. C operation, macro, API catalog에서 acquisition과 owner–subject–storage dependency를 복원합니다.
2. acquisition부터 relevant use까지 live region을 만듭니다.
3. interprocedural call·points-to·summary를 이용해 mutation, release, resize, drop, callback event를 수집합니다.
4. interval, target identity, overlap context가 모두 성립하는 dependency–event edge를 NCDG에 연결합니다.
5. property-specific state와 protection을 전파해 use 시점의 violated property를 찾습니다.
6. source audit와 targeted PoC로 한 concrete execution이 witness를 실현하는지 확인합니다.

성공 조건 / 실패 조건

성공하려면 acquisition과 later use 사이에 같은 target을 무효화하는 event가 실제로 실행 가능해야 합니다. 해당 event는 lifetime, relation, address, representation, traversal, lease, open state 중 use가 요구하는 속성을 깨뜨리고, full interval을 보호하는 lock·critical section·pin·active export·stable copy·version guard가 없어야 합니다.

별도 strong reference가 subject lifetime만 지키고 relation이나 interior pointer를 지키지 못하면 보고가 유지됩니다. 반대로 use 이전 promotion, atomic check-and-pin, complete critical section, immutable storage, no-reentry region, stabilizing reacquisition이 요구 속성을 보존하면 candidate가 사라집니다.

연구진의 실험 환경

프로토타입은 테스트를 제외하고 C++17 약 10.2K line이며 LLVM/Clang 14, CMake 3.20, compilation database를 사용합니다. CPython 3.13–3.15의 pinned revision과 versioned JSONL semantic catalog를 분석했고, 기본 points-to는 Andersen-style inclusion analysis입니다.

ConcurrBench는 matched positive·negative 180 case로 구성됐습니다. production 분석은 릴리스별 5회 실행으로 time과 memory 중앙값을 냈고, frozen candidate를 source audit한 뒤 GCC 13 debug assertion과 ASan, free-threaded·GIL control로 focused qualification을 수행했습니다.

주요 실험 결과

세 CPython release에서 dependency는 각각 5,674개, 6,061개, 6,240개였고 full configuration의 fingerprint는 1,546개, 1,459개, 1,502개였습니다. release-specific FT inventory에서 represented root는 115/121, 102/113, 92/95였습니다.

derived relation recovery를 제거하면 릴리스별 represented root 44개, 25개, 36개를 잃었습니다. cross-entry event를 제거하면 88개, 94개, 73개를 잃어 단순 local event 분석으로는 핵심 범위를 놓쳤습니다. witness bound를 16에서 64로 늘려도 semantic warning과 represented-root set은 변하지 않았고, 3.15의 alternative profile completeness만 2건 증가했습니다.

focused qualification 40회는 17건의 assertion 또는 ASan abort와 23건의 clean exit를 냈습니다. 전체 cross-mode inventory는 61개 logical component와 144개 unique root로 구성되며 library/extension 78개, built-in/core 39개, runtime/compiler 27개입니다.

실제 발견된 취약점 / 사례

pyexpat shared parser는 같은 native parser handle에 병렬 또는 재귀 Parse()가 들어가 heap state를 함께 바꿉니다. CPython 3.14 free-threaded ASan build에서 1 MiB allocation guard overwrite와 abort가 관찰됐고, GIL build에서도 handler 재진입으로 outer error state가 손상됐습니다.

object.__getstate__() 사례는 inline dictionary의 valid를 한 번 확인한 뒤 slot을 읽는 사이 peer가 representation을 바꿔 불가능한 empty state를 반환합니다. CPython 3.15 FT에서 3,182회 read 후 None이 나왔고 같은 GIL binary는 50,000 round를 완료했습니다.

module __dir__ 사례는 dictionary에서 borrowed callable을 얻은 뒤 peer가 entry를 교체해 drop-to-zero를 만들고 _PyObject_CallNoArgs가 freed object를 사용합니다. TextIOWrapper tell() 사례는 decoder callback이 seek(0)으로 snapshot을 지운 뒤 outer call이 reclaimed bytes를 계속 사용합니다.

저자 주장 vs 실제 증명 범위

owner–subject dependency와 event semantics를 명시하면 일반 race analysis가 놓치는 CPython native failure를 대규모로 찾을 수 있다는 주장은 conformance, production audit, ablation, ASan·assertion PoC가 뒷받침합니다. derived relation과 cross-entry connection의 기여도도 one-capability ablation으로 분리했습니다.

다만 “144개 취약점”을 동일 severity의 exploitable vulnerability로 읽으면 안 됩니다. 논문이 직접 증명한 것은 144개의 qualified causal root와 다양한 native 또는 semantic consequence이며, 각 root의 원격 도달 가능성·권한 경계·RCE 가능성·upstream acceptance는 별도입니다.

기존 공격 / 기존 점검 방식과의 차이

ThreadSanitizer류 dynamic detector는 실행된 same-address conflict에 강하지만 schedule coverage와 relation semantics가 제한됩니다. 일반 static race detector는 alias와 lockset을 연결하지만 owner–subject 계약, buffer lease, later use의 property를 중심 단위로 삼지 않습니다.

CPython lifecycle 분석은 refcount나 object state를 다루지만 storage generation과 traversal, callback re-entry를 하나의 dependency-invalidation witness로 묶지 못합니다. CONCURDEP의 차이는 acquisition → target-matched event → property-consuming use를 audit 가능한 형태로 보존한다는 점입니다.

연구의 한계와 주의해서 볼 부분

분석은 may-analysis이므로 false positive가 필연적이고, 실제 failure는 scheduler·allocator·callback timing에 의존할 수 있습니다. clean stress run은 안전 증명이 아니며, 논문도 SQLite가 primary run에서는 clean이었지만 isolated retry 5회 중 4회 abort한 사례를 제시합니다.

외부 event sequence는 한 지점에서 두 event 조합을 만들지 않으며, owned 또는 pinned borrowed subject에 대한 일부 relation-changing re-entry는 plugin selector의 known false-negative boundary입니다. catalog와 call graph 밖의 행위, native extension별 custom contract도 놓칠 수 있습니다.

공개 PoC / Exploit / Tool / Artifact 분석

논문은 analyzer, semantic catalog, ConcurrBench, production report, root-evidence ledger와 runnable PoC를 제공한다고 설명하지만, arXiv 본문과 공식 링크에서 논문 전용 공개 GitHub 저장소 URL을 확인하지 못했습니다. 따라서 현재 공개 재현 가능한 공식 PoC bundle로 단정할 수 없습니다.

CPython source와 문서 링크는 분석 배경 자료일 뿐 CONCURDEP 공식 artifact가 아닙니다. 공개 저장소가 확인되면 frozen commit, build dependency, catalog version, PoC 대상 revision을 함께 고정해야 재현성이 생깁니다.

레드팀 / 모의해킹에서 어떻게 활용할까

승인된 테스트 환경에서 C extension이나 embedded CPython component의 dependency lifetime을 검토하는 데 적합합니다. 먼저 borrowed reference, interior pointer, traversal cursor, buffer export, callback-retained state를 찾고, acquisition과 마지막 use 사이에 public API로 일으킬 수 있는 mutation·release·drop·re-entry를 연결합니다.

동적 검증은 pinned debug·ASan build와 synthetic object만 사용하고, crash가 확인되면 즉시 중단합니다. production service에서 scheduler stress나 memory corruption을 직접 유도하지 않습니다.

실제 점검 시 추가할 체크리스트

• borrowed reference를 callback이나 GIL release 구간 너머로 유지하는지 확인합니다.
• container size·cursor·entry를 저장한 뒤 peer mutation이 가능한지 확인합니다.
• raw pointer 취득 후 resize·reallocation·close가 가능한지 확인합니다.
• 상태 점검이 point check에 그치고 이후 event를 막지 못하는지 확인합니다.
• strong reference가 lifetime만 보장하고 relation·address를 보장하지 않는 경우를 분리합니다.
• per-object critical section이 callback re-entry까지 막는다고 가정하지 않습니다.
• free-threaded와 GIL build를 별도 threat model과 control로 시험합니다.
• CPython exact revision, compiler, sanitizer, repetition 수와 clean run을 기록합니다.
• crash뿐 아니라 impossible state, serialization omission, stale read도 관찰합니다.
• upstream patch에서 acquisition·protection interval이 실제로 바뀌었는지 확인합니다.

실무 가치 평가

CPython free-threading 전환기에 매우 높은 실무 가치가 있습니다. 특히 C extension, database driver, parser, I/O codec, container implementation처럼 Python object와 native state를 함께 다루는 코드에서 기존 race scan의 blind spot을 구체적인 review unit으로 바꿉니다.

다만 현 단계에서는 자동 취약점 판정기보다 고품질 triage 도구에 가깝습니다. semantic catalog 유지와 source audit 비용을 감수할 수 있는 runtime·platform 팀에 가장 적합합니다.

결론

CONCURDEP의 핵심 기여는 동시성 취약점을 “충돌한 주소”가 아니라 “나중 use에 필요한 dependency 속성이 중간 event로 무효화됨”으로 다시 정의한 점입니다. 이 모델은 free-threaded 병렬성뿐 아니라 GIL build의 callback·finalizer 재진입도 같은 분석 구조로 다룹니다.

실무에서는 borrowed lifetime, storage generation, traversal, lease, callback 관계를 별도 불변조건으로 점검해야 합니다. 보고된 144개 root는 중요한 경고이지만, exploitability와 제품 영향은 개별 root별로 추가 검증해야 합니다.