Keep WFP filter context alive through classify callback completion
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 18/100
- issue の種類
- バグ
- 明瞭さ
- おおむね明確
- 活発さ
- 活発
- 技術スタック
- cpp
- 領域
- networking
調査の方向性
Start with fwp_engine_t::test_callout in the usersim WFP simulation, where the filter is selected under the engine lock, rawContext is copied, and classifyFn is invoked after the lock is released. Read how filter deletion removes entries and how reference counting or locking is already used for other simulated objects. Done means a lifetime guard is held across the callback and released on every path, plus a concurrent classify-versus-delete stress test that passes without use-after-free.
索引モデルが issue の本文から書いたものです。
説明
Problem
fwp_engine_t::test_callout selects a simulated WFP filter under the engine lock, copies rawContext, releases the lock, and then invokes classifyFn. Concurrent filter deletion can remove the filter and allow the object referenced by rawContext to be freed before the classify callback has acquired its own protection.
A detach-versus-classify stress test can therefore trigger a usersim use-after-free even when the callout implementation is correct. Real WFP keeps the filter/callout context valid for an admitted classify callback.
Originating review: https://github.com/microsoft/ebpf-for-windows/pull/5623#discussion_r4458625343
Desired behavior
Once usersim admits a classify callback, the selected filter, callout, and raw context must remain valid until that callback returns. Filter deletion may prevent new classifications, but must wait for or otherwise preserve state used by callbacks already in progress.
Acceptance criteria
test_calloutacquires explicit lifetime protection before releasing the engine lock.- Concurrent filter deletion cannot free or invalidate
rawContextduringclassifyFn. - New classify attempts fail cleanly after filter deletion begins or completes.
- Lifetime protection is released after callback completion on every path.
- A stress test repeatedly overlaps classification and filter deletion without use-after-free or stale-pointer access.
- 主要言語
- C++
- スター
- 112
- フォーク
- 36
- 平均マージ
- 8日 10時間
- マージ済み PR（30日）
- 6
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
microsoft/usersim のほかの issue
-
難易度 4/5 3〜5日 初心者へのやさしさ 42/100
-
難易度 4/5 3〜5日 初心者へのやさしさ 35/100
-
Dependency Dashboardオープンtriaged
難易度 3/5 半日 初心者へのやさしさ 15/100
-
難易度 4/5 3〜5日 初心者へのやさしさ 35/100
-
難易度 5/5 1週間以上 初心者へのやさしさ 25/100
microsoft/usersim の issue をすべて見る
似ている issue
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 85/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
Niko1221/Strata#5560 · コメント 2 件 ·
メンテナーはふだん 4 日以内に返信
-
NVIDIA windows
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
メンテナーはふだん 1 日以内に返信
-
要トリアージ 辞書
難易度 1/5 1〜3時間 初心者へのやさしさ 86/100
yksr-melt/Meltype#1625 · リアクション 1 件 ·
メンテナーはふだん 1 日以内に返信
-
kind/bug priority/medium qa_automation
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
yugabyte/yugabyte-db#37324 ·
メンテナーはふだん 1 日以内に返信