脆弱性情報（JVN）検索・一覧

Concrete CMS 9.5.0 およびそれ以前のバージョンでは、local_available_update.php のビューで CSRF トークン ($token-output('do_update')) が生成されますが、concrete/controllers/single_page/dashboard/system/update/update.php の対応する do_update() メソッドでは、$this-token-validate('do_update') が呼び出されていません。フォームは POST フォームとしてレンダリングされるためトークンはブラウザに到達しますが、コントローラーが検証せずに破棄してしまいます。そのため、攻撃者はクロスサイト POST を作成し、コア CMS のアップデートを攻撃者指定のバージョン文字列にトリガーすることが可能です。脆弱であるためには、被害者が canUpgrade() を通過し、有効なアップデートバージョンが DIR_CORE_UPDATES 配下に存在している必要があります。Concrete CMS セキュリティチームは、この脆弱性に対して CVSS v.4.0 スコア 7.5（ベクター CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N）を付与しました。報告者 https://github.com/maru1009 に感謝します。

Concrete CMS 9のバージョン9.5.0未満には、concrete/controllers/backend/file star()においてクロスサイトリクエストフォージェリ（CSRF）の脆弱性が存在します。Concrete CMSのセキュリティチームは、この脆弱性に対してCVSS v4.0のスコア2.3（ベクター：CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N）を付与しました。報告者のYonatan Drori（Tenzai）に感謝しています。

Concrete CMS 9のバージョン9.5.0未満には、concrete/controllers/backend/fileのrescan()においてクロスサイトリクエストフォージェリ（CSRF）の脆弱性が存在します。Concrete CMSのセキュリティチームは、この脆弱性に対してCVSS v4.0で2.3のスコアを付けており、ベクターはCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:N/VI:L/VA:N/SC:N/SI:N/SA:Nです。報告者はYonatan Drori（Tenzai）に感謝しています。

Concrete CMS 9のバージョン9.5.0未満には、concrete/controllers/backend/fileのrescanMultiple()にクロスサイトリクエストフォージェリ（CSRF）の脆弱性があります。Concrete CMSのセキュリティチームは、この脆弱性に対してCVSS v.4.0スコア2.3（ベクター：CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N）を付与しました。報告者はYonatan Drori（Tenzai）です。

IBM HTTP Server 8.5および9.0にはバッファオーバーフローの脆弱性があります。管理サーバーに認証された特権ユーザーはこの脆弱性を悪用してリモートコードを実行したりサービス拒否を引き起こしたりする可能性があります。

IBM HTTP Server 8.5および9.0には無効なポインタ参照に関する脆弱性があります。管理サーバーに認証された特権ユーザーは、この脆弱性を悪用して機密情報を露呈させたり、サービス拒否（DoS）を引き起こしたりする可能性があります。

IBM HTTP Server 8.5および9.0には、オプションモジュールmod_ibm_uploadを介してサービス拒否を引き起こす脆弱性があります。

IBM HTTP Server 8.5および9.0には、オプションモジュールであるmod_fastcgiを介してサービス拒否が発生する脆弱性があります。

IBM HTTP Server 8.5および9.0には、オプションのモジュールmod_mem_cacheを介してサービス拒否が発生する脆弱性があります。

22.8R6以前のIvanti Secure Access Clientには、不適切な証明書検証の脆弱性があります。この脆弱性により、リモートの未認証攻撃者が任意のコードを実行できる可能性があります。

Devolutions Serverの多要素認証管理機能における要素キー状態の不適切な処理により、ユーザーのパスワードを知っている攻撃者が、ユーザーが要素を再設定した後でもそのユーザーの多要素認証を回避できる可能性があります。この問題はDevolutions Serverのバージョン2026.1.6.0から2026.1.16.0までに影響を及ぼします。

ConnectWise Automate エージェントは、プラグインの読み込みおよび自己更新操作中に取得したコンポーネントの真正性を完全に検証していません。この問題は Automate 2026.5 で修正されました。

Dell PowerFlex Manager バージョン4.6.2以前にはオープンリダイレクトの脆弱性が存在します。認証されていない攻撃者がこの脆弱性を悪用する可能性があり、対象のアプリケーションユーザーが任意のウェブURLにリダイレクトされる恐れがあります。この脆弱性によって、攻撃者はフィッシング攻撃を実行し、ユーザーから機密情報を引き出すことが可能です。

Dell PowerFlex Manager バージョン 4.6.2 以下には、不適切な権限割り当てに関する脆弱性があります。ローカルアクセス権を持つ低権限の攻撃者がこの脆弱性を悪用できる可能性があり、権限を昇格させる恐れがあります。

Dell PowerFlex Managerのバージョン4.6.2以下には、ディレクトリリスティングを通じて情報漏洩が発生する脆弱性があります。認証されていないリモートからアクセス可能な攻撃者がこの脆弱性を悪用する可能性があり、情報漏洩を引き起こすおそれがあります。

NVIDIA TensorRTには、攻撃者が境界外書き込みを引き起こす可能性がある脆弱性が存在しています。この脆弱性を悪用すると、データが改ざんされるおそれがあります。

gleam-wisp の wisp におけるリソース割り当てに制限や制御がない脆弱性により、マルチパートフォームの本文解析を介してサービス拒否（DoS）が発生する可能性があります。multipart_body 関数は設定された max_body_size および max_files_size の制限を回避します。マルチパート境界がチャンクに存在しない場合、パーサは MoreRequiredForBody パスを取り、チャンクを出力に追加しますが、クォータは再帰呼び出しに対して変更されません。境界を含む最終チャンクのみが decrement_quota によってカウントされます。同様のパターンは multipart_headers にも存在し、MoreRequiredForHeaders は decrement_body_quota を呼び出さずに再帰します。認証されていない攻撃者は、単一の HTTP リクエストで任意に大きなマルチパートフォーム送信を送ることで、サーバのメモリまたはディスクのリソースを枯渇させる可能性があります。この問題は wisp のバージョン 0.2.0 から 2.2.2 より前のバージョンに影響を与えます。

elixir-plugのplug_cowboyにおいて、リソースの割り当てに関する制限やスロットリングがない脆弱性が存在します。この脆弱性により、認証されていないリモートからのサービス拒否攻撃がアトムテーブルの枯渇を通じて可能になります。lib/plug/cowboy/conn.exのPlug.Cowboy.Conn.conn/1は、:cowboy_req.scheme/1から返される値に対してString.to_atom/1を呼び出します。HTTP/2接続の場合、cowlibはクライアントから送信された:scheme疑似ヘッダー値を検証せずにそのまま渡します。各ユニークな値はBEAMのアトムテーブル内に永久的に新しいエントリを割り当てます。アトムはガベージコレクションされず、アトムテーブルには固定の上限（デフォルト1,048,576）があります。したがって、認証されていない攻撃者がHTTP/2リクエストでユニークな:scheme値を送り続けることでテーブルを枯渇させ、Erlang VMがsystem_limitのため異常終了し、ノード全体が停止する可能性があります。この脆弱性は、cowboyがクライアントからのヘッダーではなくリスナーの種類からスキームを派生させるHTTP/1.1には影響しません。この問題はplug_cowboyの2.0.0から2.8.1未満のバージョンに影響を及ぼします。

KittyはクロスプラットフォームのGPUベース端末です。バージョン0.46.2およびそれ以下には、load_image_data()にヒープバッファオーバーフローの脆弱性があり、端末の標準入力に書き込み可能な任意のプロセスがkittyを即座にクラッシュさせる可能性があります。この脆弱性はPNGフォーマット宣言(f=100)を持つ単一のAPCグラフィックスプロトコルコマンドによって引き起こされ、そのペイロードが初期バッファ容量の2倍を超えています。オーバーフローの長さと内容の両方は攻撃者によって制御可能であり、DoSを引き起こすほか、潜在的にRCEへの権限昇格をもたらす可能性があります。この問題はバージョン0.47.0で修正されました。

ngtcp2はIETFのQUICプロトコルのC言語による実装です。バージョン1.22.1より前のバージョンでは、ngtcp2_qlog_parameters_set_transport_params()関数がピアのトランスポートパラメータを境界チェックなしに固定長1024バイトのスタックバッファにシリアライズしていました。qlogが有効な場合、リモートピアはQUICハンドシェイク中に十分に大きなトランスポートパラメータを送信することで、バッファ境界を超える書き込みを引き起こし、スタックバッファオーバーフローを発生させる可能性があります。この問題はqlogコールバックを有効にし、信頼できないピアのトランスポートパラメータを処理するデプロイ環境に影響を与えます。本問題はバージョン1.22.1で修正されています。開発者がすぐにアップグレードできない場合は、クライアント側でqlogを無効化することが可能です。

OpenTelemetry.Exporter.OpenTelemetryProtocolはOTLP（OpenTelemetryプロトコル）エクスポーターの実装です。バージョン1.8.0から1.15.2までの間、OpenTelemetry.Exporter.OpenTelemetryProtocolのOTLPディスクリトライ機能は、OTEL_DOTNET_EXPERIMENTAL_OTLP_RETRY=diskが設定されていてもOTEL_DOTNET_EXPERIMENTAL_OTLP_DISK_RETRY_DIRECTORY_PATHが構成されていない場合に、静かにPath.GetTempPath()にフォールバックしていました。エクスポーターは共有された一時ルートパスの下にある固定された信号名付きのサブディレクトリ（traces、metrics、logs）に*.blobファイルを保存および読み込みしていました。複数ユーザーが利用するシステムで一時ディレクトリが他のローカルアカウントからアクセス可能な場合、攻撃者は細工された*.blobファイルを書き込んだり、エクスポート失敗の間にアプリケーションが書き込んだ*.blobファイルを読み取ったり、多数または過大なサイズのblobファイルを配置してリトライループの性能を低下させたり、ディスクスペースを消費させたりする可能性があります。この脆弱性はバージョン1.15.3で修正されました。

absinthe-graphqlのabsintheにおけるリソース制限やスロットリングなしの割り当ての脆弱性により、攻撃者が制御するGraphQL SDLの解析時にアトムテーブルが枯渇し、認証なしでサービス拒否が可能になります。AbsintheのSDL言語モジュールにある複数のBlueprint.Draft.convert/2の実装は、解析されたGraphQL SDLドキュメント内のディレクティブ名、フィールド名、型名、引数名など、攻撃者が制御する名前に対してString.to_atom/1を呼び出します。アトムはガベージコレクションされず、BEAMのアトムテーブルには固定された上限（デフォルト1,048,576）があるため、各ユニークな名前は永久に1つのスロットを消費します。攻撃者は十分な数のユニーク名を含むSDLドキュメントを送信することでアトムテーブルを枯渇させ、Erlang VMがsystem_limitエラーで中断し、ノード全体がダウンします。この問題は、攻撃者が制御するGraphQL SDLをAbsintheのパーサに通すすべてのアプリケーションに影響を与えます。例として、スキーマアップロードエンドポイント、リモートSDLを取り込むフェデレーションゲートウェイ、ユーザー提供ドキュメントに対してパーサを実行する開発者ツールなどが挙げられます。この問題はabsintheのバージョン1.5.0から1.10.2未満に影響があります。

absinthe-graphqlのabsintheにおける非効率なアルゴリズム複雑度の脆弱性により、認証なしで二次的なフラグメント名の一意性検証を通じてサービス拒否が可能です。'Elixir.Absinthe.Phase.Document.Validation.UniqueFragmentNames':run/2はすべてのフラグメントを走査し、各フラグメントに対してduplicate?/2を呼び出します。この関数はEnum.count(fragments, &(&1.name == name))を評価してフラグメントリストを線形走査します。その結果、文書あたりO(N^2)の比較が発生します。ここでNは呼び出し元が提供したフラグメント定義の数を表します。input.fragmentsはGraphQLクエリ本文から直接構築されるため、Nは攻撃者が完全に制御可能です。最小サイズのフラグメント定義は約16バイトであり、約1MBの文書には約60,000のフラグメントが含まれています。この単一の検証フェーズで約36億回の比較が強制されます。認証、スキーマ知識、または特別な設定は不要です。この問題はabsintheの1.2.0から1.10.2未満のバージョンに影響します。

スマートコントラクトMarginal v1は安全でないダウンキャストを実行しています。これにより、攻撃者はごくわずかな資産コストで大きな負債ポジションを決済することが可能になります。

Jupyter Development Teamが提供するJupyter Serverには、次の脆弱性が存在します。 ・オープンリダイレクト（CWE-601）- CVE-2025-61669 この脆弱性情報は、情報セキュリティ早期警戒パートナーシップに基づき下記の方がIPAと開発者へ報告し、JPCERT/CCが開発者と公表の調整を行いました。 報告者：株式会社サイバーディフェンス研究所 岩崎 徳明 氏

Linuxカーネルにおいて、以下の脆弱性が修正されました。nsfsのnsイテレーションioctlにおける権限チェックを強化しました。特権サービスであっても、他の特権サービスの名前空間を必ずしも閲覧できるわけではなく、それによって情報漏洩を防ぎます。nstreeの適応が完了するまで、このポリシーを一元管理するためにmay_see_all_namespaces()ヘルパーを使用します。

Linuxカーネルにおいて、以下の脆弱性が修正されました。libcephのceph_monmap_decode()関数内で非負値に対してu32型を使用する問題がありました。このパッチは、ceph_monmap_decode()内でblob_lenおよびnum_monの符号を不必要に変更する暗黙の型変換を修正します。現在、blob_lenとnum_monは符号付きのint型変数ですが、これらは常に非負の値を保持し、u32値を割り当てることを目的としたceph_decode_32_safe()で設定されています。両変数はその後、符号なしの値として使用され、num_monの値はさらにu32型のmonmap-num_monに割り当てられます。したがって、両変数はu32型であるべきです。特にnum_monについては重要です。受信メッセージから読み取られた値が非常に大きい場合、それは負の値として解釈され、num_mon CEPH_MAX_MONのチェックを通過してしまいます。これによりmonmap用に非常に大きなメモリを確保しようとし、通常は失敗します。この場合、不必要なメモリ確保の試みが行われ、-EINVALではなく-ENOMEMが返されます。

Linuxカーネルにおいて、ceph_path_info構造体の初期化不備によりceph_mdsc_free_path_info()がクラッシュする脆弱性が修正されました。ceph_mdsc_build_path()関数はゼロ初期化されたceph_path_infoパラメータで呼び出す必要があり、そうでない場合にクラッシュする可能性があります。特にLinux 6.18.12カーネルでこの問題が報告されており、悪用されると権限昇格などの重大な影響を及ぼす恐れがあります。本件の修正では全ての呼び出し元でceph_path_infoを適切に初期化することで安全性を確保しています。

Linuxカーネルにおいて、以下の脆弱性が修正されました。ALSAのpcmに関するもので、snd_pcm_drain()のリンクされたストリームのruntimeに対するuse-after-freeの問題です。ドレインループ内で、ローカル変数'runtime'がリンクされたストリームのruntime（2157行目のruntime = s-runtime）に再代入されます。その後、2169行目でストリームロックを解放した後に、コードはruntime-no_period_wakeup、runtime-rate、およびruntime-buffer_size（2170-2178行目）にアクセスします。これらのフィールドはすべて、ロックや参照カウントによってその寿命が保護されていないリンクされたストリームのruntimeを参照していました。リンクされたストリームのファイルディスクリプタに対する同時のclose()操作によって、snd_pcm_release_substream() → snd_pcm_drop() → pcm_release_private() → snd_pcm_unlink() → snd_pcm_detach_substream() → kfree(runtime)が呼ばれます。同期機構が存在しないため、drainパスが古いポインタを参照している間にkfree(runtime)が完了してしまいました。修正は、ストリームロックを保持している間に必要なruntimeのフィールド（no_period_wakeup、rate、buffer_size）をローカル変数にキャッシュし、ロック解放後はキャッシュされた値を使用する方法によって行われました。

Linuxカーネルにおいて、以下の脆弱性が修正されました。sched_extのscx_cgroup_init()内にある冗長なcss_put()の削除が行われました。css_for_each_descendant_pre()イテレータはcgroup_lock()の下でcgroup階層を走査しますが、yieldされるcss構造体の参照カウントを増加させません。cgroupのドキュメントによると、css_put()はcss_get()またはcss_tryget_online()で取得した参照を解放する場合にのみ使用すべきです。イテレータはこれらを使用して参照を取得していないため、scx_cgroup_init()のエラーパスでcss_put()を呼び出すと参照カウントのアンダーフローを引き起こします。不均衡なcss_put()を削除することで、潜在的なUse-After-Free(UAF)脆弱性を防止しています。

Linuxカーネルにおいて、以下の脆弱性が修正されました。net/manaでは、セットアップエラー時にservice_wqをNULLに設定し、二重破壊を防止します。mana_gd_setup()のエラーパスでは、mana_gd_cleanup()のクリーンアップに合わせてdestroy_workqueue()実行後にgc-service_wqをNULLに設定します。これにより、セットアップ失敗後にworkqueueポインタがチェックされた場合のuse-after-freeを防止します。

Linuxカーネルにおいて、以下の脆弱性が修正されました。net: bondingに関する問題で、IPv6が無効化されている場合にnd_tblのNULL参照が発生する問題です。'ipv6.disable=1'パラメータで起動すると、inet6_init()はndisc_init()が呼ばれる前に終了し、その結果nd_tblが初期化されません。bondingのARP/NS検証が有効になっている場合、IPv6のNS/NAパケットがスレーブで受信されるとbond_validate_na()に到達し、bond_has_this_ip6()が呼び出されます。その過程でipv6_chk_addr()が呼ばれ、__ipv6_chk_addr_and_flags()でクラッシュが発生する可能性があります。修正としては、IPv6パケットをbond_na_rcv()に送る前にipv6_mod_enabled()をチェックし、IPv6が無効の場合はbond_rcv_validate()から早期にリターンすることでipv6_chk_addr()への経路を回避するようにしました。

Linuxカーネルにおいて、以下の脆弱性が修正されました。io_uringのSQE_MIXEDにおける128バイト操作に対する物理SQE境界チェックの問題です。IORING_SETUP_SQE_MIXEDがIORING_SETUP_NO_SQARRAYなしで使用される場合、io_init_req()内の128バイトSQE操作の境界チェックは物理的なSQEインデックスではなく論理的なSQヘッド位置を検証していました。既存のチェックである !(ctx-cached_sq_head & (ctx-sq_entries - 1)) は、論理的位置がリングの末尾にないことを保証しており、これは物理と論理が同一のNO_SQARRAYリングでは正しい動作です。しかし、sq_arrayが存在する場合、非特権ユーザは任意の論理位置をsq_arrayを介して任意の物理インデックスに再マップできます。sq_array[N]をsq_entries - 1に設定すると、128バイト操作が最後の物理SQEスロットに配置され、io_uring_cmd_sqe_copy()内での128バイトのmemcpyがSQE配列の末尾を64バイト超えて読み取ってしまいます。そこで、cached_sq_headのアライメントチェックを物理的SQEインデックスの直接検証に置き換え、sq_arrayとNO_SQARRAYの両方の場合を正しく処理するように修正しました。

Linuxカーネルにおいて、以下の脆弱性が修正されました。iavfではリセット中のPTPのuse-after-freeの問題が修正されました。コミット7c01dbfc8a1c5f（"iavf: periodically cache PHC time"）はPHC時間をキャッシュするワーカーを導入しましたが、リセットまたは無効化時にこれを停止できていませんでした。これにより、`iavf_reset_task()`または`iavf_disable_vf()`がアダプターリソース（AQ）を解放している間もワーカーがまだ動作している競合状態が発生します。リソース解放時にワーカーが`iavf_queue_ptp_cmd()`を呼び出すと、解放済みのメモリやロックにアクセスし、クラッシュを引き起こします。この問題はアダプターを破棄する前に`iavf_ptp_release()`を呼び出すことで修正されました。これにより、`ptp_clock_unregister()`がワーカーを同期的にキャンセルし、破棄される前にchardevをクリーンアップすることが保証されます。

Linuxカーネルにおいて、以下の脆弱性が修正されました。nvme-pciのnvme_dbbuf_set関数内で発生していたスラブ境界外アクセスの問題を修正しました。dev-online_queuesはnvme_init_queue関数内でインクリメントされるカウントであり、有効なインデックスは0からdev-online_queues−1までです。本パッチはループ条件を修正し、インデックスが有効範囲内に収まるようにしました。インデックス0は管理キューのため除外されています。KASANエラーの内容は、nvme_dbbuf_free関数の377行目とnvme_dbbuf_set関数の404行目でスラブ境界外アクセスが検出されたことです。サイズ2の読み込みがタスクkworker/u8:5によって行われました。問題のアドレスは、サイズ2048のkmalloc-2kキャッシュ内の領域[ffff88800592a000, ffff88800592a480)の1152バイト割り当て範囲の右244バイト外に位置していました。この問題はnvme_pciドライバのオンラインキュー管理におけるインデックス計算の不備によって発生しました。パッチにより正しい範囲チェックが追加され、不正アクセスが防止されました。

Linuxカーネルにおいて、次の脆弱性が修正されました。netfilterのnfnetlink_cthelperにあるnfnl_cthelper_dump_table()関数内で範囲外読み取り（OOB読み取り）が発生する問題が解決されました。nfnl_cthelper_dump_table()関数にはforループ本体内のラベルへ飛ぶ「goto restart」が存在します。cb-args[1]に保存された「last」ヘルパーがダンプラウンド間で削除されると、すべてのエントリが(cur != last)チェックに失敗し、cb-args[1]がクリアされません。forループはcb-args[0]がnf_ct_helper_hsizeと等しい状態で終了し、「goto restart」は境界チェックをバイパスしてループ本体に戻るため、nf_ct_helper_hash[nf_ct_helper_hsize]に対して8バイトの範囲外読み取りが発生します。この「goto restart」ブロックは、「last」が見つからなくなったときに現在のバケットを再度走査するためのものでしたが、forループの外に配置されていました。修正により、このブロックはforループ内に移動され、cb-args[0]が範囲内にある場合にのみ再起動が発生するようになりました。BUG: KASANによりnfnl_cthelper_dump_table+0x9f/0x1b0でslab-out-of-boundsが検出されました。サイズ8の読み取りがaddr ffff888104ca3000でtask poc_cthelper/131によって実行されました。コールトレースはnfnl_cthelper_dump_table+0x9f/0x1b0、netlink_dump+0x333/0x880、netlink_recvmsg+0x3e2/0x4b0、sock_recvmsg+0xde/0xf0、__sys_recvfrom+0x150/0x200、__x64_sys_recvfrom+0x76/0x90、do_syscall_64+0xc3/0x6e0の順です。タスク1は__kvmalloc_node_noprof+0x21b/0x700、nf_ct_alloc_hashtable+0x65/0xd0、nf_conntrack_helper_init+0x21/0x60、nf_conntrack_init_start+0x18d/0x300、nf_conntrack_standalone_init+0x12/0xc0で確保されました。

Linuxカーネルにおいて、以下の脆弱性が修正されました。netfilterのx_tablesにおいて、ガードオプションのウォーカーが1バイトの末尾読み出しを防止できない問題が存在しました。オプションの最後のバイトが単一バイトではないオプション種の場合、i += op[i + 1] ? : 1で進むウォーカーがオプション領域の終端を超えてop[i + 1]を読み取ってしまう可能性がありました。xt_tcpudpおよびxt_dccpのオプションウォーカー内で、op[i + 1]を参照する前に、明確にi == optlen - 1というチェックを追加して問題を修正しました。

Linuxカーネルにおいて、以下の脆弱性が修正されました：netfilterのnft_set_pipapoサブシステム内に存在したpipapo_drop()関数におけるスタックの境界外読み取りの問題です。pipapo_drop()はすべての反復でrulemap[i + 1].nをpipapo_unmap()のto_offset引数として渡していました。最後の反復（i == m-field_count - 1）も含まれていました。これにより、スタック上に確保されたrulemap配列（rulemap[NFT_PIPAPO_MAX_FIELDS]として宣言され、NFT_PIPAPO_MAX_FIELDSは16です）を1要素分超えて読み込むことが発生していました。pipapo_unmap()はis_lastがtrueの場合、to_offset値を使用せずに早期リターンしますが、引数は関数本体が実行される前に呼び出し元で評価されるため、本物のスタックの境界外読み取りとなっており、KASANによって検出されました。具体的には、BUG: KASAN: stack-out-of-bounds in pipapo_drop+0x50c/0x57c [nf_tables]、サイズ4の読み取りがアドレスffff8000810e71a4で発生しました。このフレームには1つのオブジェクトがあり、その範囲は[32, 160)の'rulemap'です。バグのあるアドレスはオフセット164で、rulemap配列の末尾を正確に4バイト超えています。問題を解決するために、最終反復時にはrulemap[i + 1].nの代わりに0を渡すことで境界外読み取りを回避しました。

Linuxカーネルにおいて、以下の脆弱性が修正されました。serial: caif: ldisc_openおよびser_releaseでtty-linkの参照を保持します。再現手順は、caif_serialのTXパスがtty_write_room()を呼び出す際にpty_write_room()でKASANのスラブ使用後解放（use-after-free）を引き起こします。問題のアクセスはtty-link-portに対するものです。caif_serialラインディシプリンのライフタイム中にtty-linkに対して追加のkrefを保持します。ldisc_open()で取得し、ser_release()で解放し、さらにldisc_open()のエラーパスでも解放します。この変更を適用することで、私のテストでは再現手順によるUAFは発生しなくなりました。

Linuxカーネルにおいて、以下の脆弱性が修正されました。ASoC: soc-coreにて、DAIおよびウィジェットを削除する前に遅延ワークをフラッシュする問題です。PCMストリームが開いている間にサウンドカードがバインド解除されると、close_delayed_workワークキューのハンドラから呼び出されるsnd_soc_dapm_stream_event()でuse-after-freeが発生する可能性がありました。バインド解除時にsnd_soc_unbind_card()は遅延ワークをフラッシュし、その後soc_cleanup_card_resources()を呼び出します。クリーンアップ内でsnd_card_disconnect_sync()はすべてのPCMファイルディスクリプタを解放し、その結果のPCMクローズパスはsnd_soc_dapm_stream_stop()を呼び出すことがあります。この関数はpmdown_timeタイマー遅延付きの新しい遅延ワークをスケジュールしますが、これはsnd_soc_unbind_card()のフラッシュ後に発生するため、新しいワークはキャッチされません。soc_remove_link_components()はその後、このワークが起動する前にDAPMウィジェットを解放し、use-after-freeを引き起こしていました。soc_free_pcm_runtime()にある既存のフラッシュも、soc_remove_link_components()がすでにウィジェットを解放した後に実行されるため有効ではありません。そこで、snd_card_disconnect_sync()の後（新しいPCMクローズがさらなる遅延ワークをスケジュールできないタイミング）で、soc_remove_link_dais()およびsoc_remove_link_components()（遅延ワークがアクセスする構造体を解体する前）より前に、soc_cleanup_card_resources()内でフラッシュ処理を追加しました。