技術解説とコード分析：CVE-2024-26585: Linux Kernel TLS Subsystem Use-After-Free Teardown

vulnerabilidade に関する技術的なソースコード解析と堅牢化対策：脆弱性の根本原因と安全な実装パッチの詳細。

💡 わかりやすい解説 (ELI5)

直感的な物理的アナロジー解説：Imagine you order a meal for delivery. The chef starts cooking, but you call and cancel the order. Because the kitchen staff wasn't notified properly, the delivery driver picks up an empty plate, drives to a new customer's house, and serves them whatever was left on the counter, contaminating the new customer's food.

主要な概念と専門用語

Kernel TLS (kTLS): Linux kernel facility to perform symmetric TLS encryption/decryption directly inside the network socket layer for maximum throughput.
Zero-Copy Networking: Transmitting data directly from application buffers to the network card without intermediate CPU memory copying.
Asynchronous Crypto (aead_request): Offloading cryptographic AES-GCM operations to asynchronous hardware accelerators.
Slab Corruption: Corrupting Linux kernel slab cache structures (kmalloc-512), destabilizing kernel execution.

根本原因の分析 (Root Cause)

根本原因は、オープンソースシステムにおける未検証の境界パラメータに起因し、状態の非同期化とセキュリティ制御の迂回を可能にします。

ステップ・バイ・ステップの攻撃フロー

Step 1

攻撃フェーズ：Open kTLS Socket

技術的な脆弱性悪用メカニズムと実行フローの詳細：The attacker creates a TLS socket and enables kernel encryption offload via setsockopt(TCP_ULP, "tls").

Step 2

攻撃フェーズ：Submit Asynchronous Zero-Copy Payload

技術的な脆弱性悪用メカニズムと実行フローの詳細：The attacker sends data using MSG_ZEROCOPY, queuing pages for hardware crypto.

Step 3

攻撃フェーズ：Abrupt Socket Teardown

技術的な脆弱性悪用メカニズムと実行フローの詳細：The attacker closes the socket before the crypto accelerator completes its async callback.

Step 4

メモリ破壊（Kernel Memory Corruption）

技術的な脆弱性悪用メカニズムと実行フローの詳細：The cleanup handler frees memory pages that the delayed hardware callback subsequently overwrites.

ソースコード比較：脆弱 vs 堅牢化

脆弱な実装

// VULNERABLE: net/tls/tls_sw.c before patch
static void tls_encrypt_done(void *data, int err) {
    struct tls_context *ctx = data;
    struct tls_sw_context_tx *ctx_tx = tls_sw_ctx_tx(ctx);

    // ROOT CAUSE:
    // Asynchronous completion callback assumes socket context is still locked!
    // If the socket was closed while crypto was in flight, ctx_tx is already freed!
    clear_bit(TLS_TX_SYNC_MORE, &ctx_tx->tx_bitmask);
    tls_free_open_rec(ctx);
}

堅牢化されたセキュアパッチ

// SECURE: net/tls/tls_sw.c patch
static void tls_encrypt_done(void *data, int err) {
    struct tls_context *ctx = data;
    
    // 1. Verify context reference counter before dereferencing context pointers
    if (!refcount_inc_not_zero(&ctx->refcount)) {
        return; // Socket is already dying, abort callback safely!
    }
    
    struct tls_sw_context_tx *ctx_tx = tls_sw_ctx_tx(ctx);
    clear_bit(TLS_TX_SYNC_MORE, &ctx_tx->tx_bitmask);
    tls_free_open_rec(ctx);
    
    // 2. Drop reference cleanly
    refcount_dec(&ctx->refcount);
}

エンジニアリング＆システム堅牢化チェックリスト

✓常に refcount_inc_not_zero() on shared context handles inside asynchronous completion handlers を使用してください。
✓推奨されるセキュリティ対策：Synchronously drain or cancel all in-flight asynchronous hardware crypto jobs before releasing socket memory。
✓thread-safety and lock ownership inside callback routines を厳格に検証してください。
✓zero-copy socket implementations for lifetime and reference races を詳細に監査してください。