原文

Linuxカーネルにおいて、以下の脆弱性が修正されました。bpf: スリープ可能なBPFプログラムからのLPMマップアクセスを許可しています。trie_lookup_elem()は、rcu_dereference_check()の操作に対してrcu_read_lock_bh_held()のみを注釈しています。rcu_dereference_check(p, c)は「c || rcu_read_lock_held()」に展開されるため、これはXDP/NAPIおよび従来のRCUリーダーには適合しますが、__bpf_prog_enter_sleepable()経由で入りrcu_read_lock_trace()のみを保持するスリープ可能BPFプログラムでは失敗します。trie_update_elem()とtrie_delete_elem()も別の形で同様の問題を抱えており、trieの走査において単純なrcu_dereference()を使用しています。これはrcu_read_lock_held()を無条件にアサートしています。これらはbpf_map_update_elem / bpf_map_delete_elemヘルパー経由でスリープ可能BPFプログラムから、また従来のrcu_read_lock()下のシステムコールパスからも到達可能です。書き込みパスでは、trieは実際にはtrie-＞lock（走査中に取得されるrqspinlock）で保護されており、RCUのリードサイドロックでノードの生存を保証することには依存しません。したがって、スリープ可能なLSMフックがLPM trieにアクセスすると、デバッグカーネルにおいてlockdepが次のようにトリガーされます。 ============================= WARNING: suspicious RCU usage 7.1.0-... Tainted: G E ----------------------------- kernel/bpf/lpm_trie.c:249 suspicious rcu_dereference_check() usage! 1 lock held by net_tests/540: #0: (rcu_tasks_trace_srcu_struct){....}-{0:0}, at: __bpf_prog_enter_sleepable+0x26/0x280 Call Trace: dump_stack_lvl lockdep_rcu_suspicious trie_lookup_elem bpf_prog_..._enforce_security_socket_connect bpf_trampoline_... security_socket_connect __sys_connect do_syscall_64この警告はlockdep専用のものであり、Tasks Trace RCUがtrieのリクレイムパスとシリアライズしているためUse-After-Free（UAF）は発生しません。しかし、スリープ可能BPF LSMがLPM trieに触れる全てのデバッグカーネルにおいて、異なる呼び出し元ごとにコンソールにスパムが発生し、この状況はますます一般的になっています。ルックアップパスについては、rcu_dereference_check()の注釈をrcu_read_lock_bh_held()からbpf_rcu_lock_held()に切り替えました。これにより、古典的なRCU、BH、Tasks Traceの3つの文脈すべてを許容します。他のマップタイプはすでにこの規約に従っています。trie_update_elem()とtrie_delete_elem()については、走査をrcu_dereference_protected(*p, 1)として注釈付けしました。同ファイル内のtrie_free()と一致させています。trie-＞lockは走査中に保持されており、rqspinlockにはlockdep_mapが存在しないため、述語はlockdep_is_held(&trie-＞lock)ではなく『1』に退化します。つまり保護は実際に存在しますが、マシンが検証可能なものではありません。trie_get_next_key()も単純なrcu_dereference()を使用していますが、BPFシステムコールからのみ到達可能であり、ディスパッチ前に古典的なrcu_read_lock()を保持しているため、そのままにしています。