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

i18nextifyは、ソースコードを変更することなくスクリプトタグを介してウェブサイトの国際化を追加するJavaScriptライブラリです。バージョン4.0.8以前では、srcおよびhref属性の値内の{{key}}補間トークンを、i18next.t()が返す生の文字列に置き換えます。src/localize.js内の置換ロジック（replaceInsideハンドラー）は、重複したhttp://起点のプレフィックスに対してのみ保護しており、置換された値のURLスキームを検証していません。翻訳ファイルの内容や翻訳バックエンドのレスポンスを攻撃者が操作できる場合（例えば、破損した翻訳CDN、ユーザー投稿ロケール、平文HTTPのバックエンドに対するMITM攻撃、または翻訳JSONへの書き込み権限によって）、javascript:alert(1)やdata:text/html,script.../scriptのような翻訳済み値が変更されずにライブDOM属性に適用される可能性があります。この問題はバージョン4.0.8で修正されました。

任意のHTMLを解析し、その後Renderを使用してレンダリングすると、予期しないHTMLツリーが生成される可能性があります。これは、入力HTMLをレンダリング前にサニタイズしようとするアプリケーションでXSS攻撃を実行するために悪用される可能性がある問題です。

任意のHTMLを解析し、その後Renderを使用してレンダリングすると、予期しないHTMLツリーが生成される可能性があります。これは、レンダリング前に入力HTMLのサニタイズを試みるアプリケーションでXSS攻撃が実行される可能性があるため、悪用される恐れがあります。

Synology SSL VPN Client バージョン 1.4.5-0684 未満には、外部の第三者がアクセス可能なファイルやディレクトリに脆弱性があります。ループバックインターフェースにバインドされたローカルHTTPサーバーを介して、リモート攻撃者がインストールディレクトリ内のファイルにアクセスできる可能性があります。攻撃者は細工されたウェブページを用いたユーザーの操作を利用し、設定ファイル、証明書、ログなどの機密ファイルを取得して情報漏えいを引き起こす場合があります。

Apache Ignite REST APIにおける相対パストラバーサルの脆弱性です。認証済みのREST APIユーザーは、「cmd=log」コマンドおよび特定の方法で作成されたログパスを使用して、サーバー上の任意のファイルを読み取ることが可能です。この問題はApache Igniteのバージョン2.0.0から2.17.0までに影響を与えます。ユーザーは、この問題を修正したバージョン2.18.0へアップグレードすることを推奨します。

148.0.7778.216以前のGoogle Chromeのパスワード機能において、信頼されていない入力が十分に検証されていなかったため、リモートの攻撃者が細工されたHTMLページを介してUIスプーフィングを実行できる可能性がありました。

Google Chrome 148.0.7778.216 未満のバージョンの ANGLE における整数オーバーフローの脆弱性により、リモートの攻撃者が細工された HTML ページを介してプロセスメモリから潜在的に機密性の高い情報を取得できる可能性がありました。

Samsungアカウントのバージョン15.5.01.1以前において、URLリダイレクションの脆弱性により、ローカルの攻撃者がアクセストークンを取得できる可能性があります。

Linuxカーネルのnet: liquidioにおける脆弱性が修正されました。setup_nic_devices()関数内で、netdevポインタはnetif_set_real_num_rx_queues()およびnetif_set_real_num_tx_queues()の呼び出し後に初めて初期化されますが、これらの呼び出しが失敗した場合に割り当てられたnetdevが解放されず、メモリリークが発生していました。この脆弱性は、キュー設定前にnetdevポインタを初期化することで修正されています。

Linuxカーネルにおいて、io_uringの読み書きリクエスト処理でキャッシュのputに失敗した際に割り当てられたiovecが正しく解放されない可能性がある問題が修正されました。io_req_rw_cleanup()を経由する読み書きリクエストは割り当てられたiovecを持っており、rw_cacheへのputに失敗した場合に未処理のiovecポインタが残ることがあります。これを防ぐために、io_rw_recycle()がリクエストのリサイクル状況を返し、その結果に応じてiovecの解放を適切に行うようにしました。

Linuxカーネルにおいて、以下の脆弱性が修正されました。regmapのmapleにおいて、mas_store_gfp()が失敗した場合にエントリが解放されず、メモリリークが発生する問題です。regcache_maple_write()は隣接する範囲をマージするために新しいブロック（「entry」）を割り当て、その後mas_store_gfp()で格納します。mas_store_gfp()が失敗した場合は、新しい「entry」が解放されずに残ってしまいます。今回の修正では、失敗時の処理経路で「entry」を確実に解放し、成功時には置き換えられた隣接ブロック（「lower」「upper」）の解放を継続しています。

Linuxカーネルに存在する脆弱性は、特定のPCIeサブシステムにおいてASPMが有効かどうかを誤って確認する問題に関連しています。この問題により、特定のAMD GPU構成でシステムがクラッシュする原因となっていました。本修正では、誤って再適用されたコミットを取り消すことで問題を解決しています。

Linuxカーネルにおいて、以下の脆弱性が解決されました：f2fsの{read,write}_end_ioにおけるノードフッターの整合性チェックの修正です。 -----------[ ここから切り取り ]------------ kernel BUG at fs/f2fs/data.c:358! コールトレース: IRQ blk_update_request+0x5eb/0xe70 block/blk-mq.c:987 blk_mq_end_request+0x3e/0x70 block/blk-mq.c:1149 blk_complete_reqs block/blk-mq.c:1224 [inline] blk_done_softirq+0x107/0x160 block/blk-mq.c:1229 handle_softirqs+0x283/0x870 kernel/softirq.c:579 __do_softirq kernel/softirq.c:613 [inline] invoke_softirq kernel/softirq.c:453 [inline] __irq_exit_rcu+0xca/0x1f0 kernel/softirq.c:680 irq_exit_rcu+0x9/0x30 kernel/softirq.c:696 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1050 [inline] sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1050 /IRQ f2fs_write_end_io()において、ノードページのインデックス(nid)とノードページのfooter.nidとの間に不整合が検出されます。もしfuzzされたイメージ内のノードページのフッターが破損している場合、非同期メソッド（例: f2fs_ra_node_pages()やf2fs_ra_node_page()）で破損したノードページをロードしてしまいます。この場合、ノードフッターの整合性チェックが行われません。ノードページがダーティになると、ノードページの書き戻し後に本バグが発生します。

Linuxカーネルのfbdevのrivafbドライバにはnv3_arb()関数でゼロ除算エラーを引き起こす脆弱性が存在しました。ユーザ空間のプログラムは/dev/fb*に対してFBIOPUT_VSCREENINFO ioctlを呼び出すことでRIVA NV3のアービトレーションコードをトリガーできます。ドライバはnv3_arb()内で状態state-mclk_khzを除数として検証せずに使用していました。通常、state-mclk_khzはゼロではありませんが、攻撃者が偽のPCIデバイスなどを作成するとstate-mclk_khzがゼロになる場合があります。これにより、nv3_get_param()呼び出し時に除算エラーが発生し、カーネルがクラッシュしました。本脆弱性はstate-mclk_khzがゼロかどうかをチェックして除算を回避することで修正されました。

Linuxカーネルにおいて、以下の脆弱性が修正されました。f2fsにおいて、同時に行われるアトミックコミットおよびチェックポイント書き込みによって引き起こされるIS_CHECKPOINTEDフラグの不整合問題を修正しました。SPOテスト中に、F2FSのマウント時にf2fs_recover_inode_pageから-EINVALエラーが返される問題が発生しました。この問題は以下のシナリオで発生しました。スレッドAとスレッドBの動作が関係します。スレッドAはf2fs_ioc_commit_atomic_writeからf2fs_do_sync_file（atomic = true）、f2fs_fsync_node_pages、そして最後のfolioのロック前にスケジュールされ、f2fs_write_checkpointがblock_operationsを介して最後のfolioを書き戻します。f2fs_flush_nat_entriesの前にスケジュールされ、set_fsync_mark(last_folio, 1)、set_dentry_mark(last_folio, 1)、folio_mark_dirty(last_folio)を実行し、続いて__write_node_folio(last_folio)、f2fs_down_read(&sbi-node_write)でブロックします。f2fs_flush_nat_entriesで{struct nat_entry}-flagにBIT(IS_CHECKPOINTED)が設定され、その後にf2fs_up_write(&sbi-node_write)でアンブロックされます。f2fs_write_checkpointはf2fs_do_write_node_page()を返し、f2fs_ioc_commit_atomic_writeが返却されます。スレッドAはf2fs_need_dentry_mark(sbi, ino)を呼び出し、last_folioはすでに一度書き込まれていますが、{struct nat_entry}-flagにはIS_CHECKPOINTEDが設定されておらず、スレッドBがf2fs_write_checkpointを完了した後にset_dentry_mark(last_folio, 1)と最後のfolioの再書き込みが発生しました。SPOおよび再起動後、{struct node_info}-blk_addrがNULL_ADDRでないことが検出され、これはスレッドBが正常にチェックポイントを書き込んだことを示しています。この問題はアトミック書き込みのシナリオでのみ発生します。通常のファイルfsync操作ではfolioは必ずダーティ状態であり、block_operations-f2fs_sync_node_pagesが正常にfolio書き込みを送信すればこのパスは実行されません。そうでない場合、f2fs_write_checkpointはfolio書き込み送信の完了を待つ必要があり、sbi-nr_pages[F2FS_DIRTY_NODES]が0より大きくなります。したがって、f2fs_need_dentry_markは{struct nat_entry}-flagにIS_CHECKPOINTEDフラグがないことを確認しましたが、folio書き込みがすでに送信されている状況は発生しません。よって、アトミックファイルfsyncのために、IS_CHECKPOINTEDフラグがチェックポイント書き込み完了を正しく示すように、sbi-node_writeは__write_node_folioを通じて取得する必要があります。

Linuxカーネルにおいて、以下の脆弱性が修正されました。atm: lec: lec_arp_clear_vccsにおけるnullポインタ逆参照を修正しました。syzkallerによってlec_arp_clear_vccs()内のnullポインタ逆参照が報告され、この問題はsyzkallerの再現ツールを使って簡単に再現できます。ATM LANE（LANエミュレーション）モジュールでは、同じatm_vccが複数のlec_arp_tableエントリ（例: entry-vccやentry-recv_vcc）で共有されることがあります。基盤となるVCCが閉じられると、lec_vcc_close()はすべてのARPエントリを順に処理し、対応するエントリごとにlec_arp_clear_vccs()を呼び出します。例えば、lec_vcc_close()がpriv-lec_arp_empty_onesや他のARPテーブルのハッシュリストを繰り返し処理する際、1. 最初の繰り返しで、VCCを共有する最初のARPエントリに対して、lec_arp_clear_vccs()は関連付けられたvpriv（vcc-user_back）を開放し、vcc-user_backをNULLに設定します。2. 2回目の繰り返しで、同じVCCを共有する次のARPエントリに対して再度lec_arp_clear_vccs()が呼ばれます。この時、vcc-user_back（LEC_VCC_PRIV(vcc)経由）からNULLのvprivを取得し、`vcc-pop = vpriv-old_pop`を実行しようとしてnullポインタ逆参照のクラッシュが発生します。この問題は、vprivを逆参照する前にNULLチェックを追加することで修正しました。もしvprivがすでにNULLであれば、それはVCCが前回の呼び出しでクリアされたことを示すため、クリーンアップはスキップし、そのエントリのvcc/recv_vccポインタだけを安全にクリアします。vprivがNULLの場合は、VCCがすでに前の繰り返しで完全に解放されているため、vcc_release_async()を含むクリーンアップ全体のブロックをvprivのガード内に配置しました。これにより、すでに終了処理中のソケットに対してフラグが重複設定されたりコールバックが繰り返し発生することを防止します。Fixesタグはentry-vccパスに脆弱性がオリジナルのコードから存在したため、最初のコミットを指しています。entry-recv_vccパスは後にコミット8d9f73c0ad2f（「atm: fix a memory leak of vcc-user_back」）で同様のパターンが追加されましたが、両方のパスを今回修正しました。

Linuxカーネルにおいて、以下の脆弱性が修正されました。irqchip/sifive-plicにおいて、アフィニティ設定による割り込みのフリーズ問題を修正しました。PLICは、無効化された割り込みに対する割り込み完了メッセージを仕様により無視します。PLICは割り込みハンドラの実行完了を、クレームから受け取った割り込みIDをクレーム／コンプリートレジスタに書き込むことで通知します。PLICは完了IDが対象の最後のクレームIDと同じかどうかを確認しません。完了IDが現在対象で有効な割り込みソースと一致しない場合、完了メッセージは無視されます。これにより、割り込みが処理中に無効化された場合でも問題が発生し、plic_irq_eoi()は効果を持ちませんでした。この問題は、割り込みが無効化されているかをチェックし、もし無効であれば完了メッセージ送信前に有効化することで修正されました。そのチェックはirdq_irq_disabled()で行われます。しかしこれは不十分であり、処理中のハートの有効ビットが0であってもirdq_irq_disabled(d)がfalseとなる場合があります。これはハートが割り込み処理中にアフィニティ設定が変更された場合に発生します。この問題は、大きなファイルをUARTにダンプし大量の割り込みを発生させた状態でUART割り込みのアフィニティ設定を続けて変更することで簡単に再現できます。UARTポートはほぼ瞬時にフリーズします。この問題はirdq_irq_disabled()ではなくPLICの有効ビットをチェックすることで修正されました。

Linuxカーネルにおいて、次の脆弱性が修正されました：IB/mthcaのmthca_create_srq()関数に対して、見落とされていたmthca_unmap_user_db()の追加を行いました。これにより、システムコール失敗時にユーザーが引き起こす可能性のあるリークを修正しました。

Linuxカーネルにおいて、以下の脆弱性が修正されました。net: usb: pegasus: USBエンドポイントの検証に関して、pegasusドライバーはバインドする前にプローブしているデバイスが期待される正しい数と種類のUSBエンドポイントを持っているかを検証する必要があります。悪意のあるデバイスが同じURBを持っていない場合、ドライバーがこれらのエンドポイントに盲目的にアクセスすると後でクラッシュが発生します。

Linuxカーネルのnfc: pn533ドライバに脆弱性があり、デバイス切断時にUSBインターフェイスの参照カウントが適切に解放されず、リソースリークを引き起こしていました。この問題が修正されました。

Linuxカーネルにおいて、IPv6が無効化されている場合にnd_tblのNULL参照が発生する脆弱性が修正されました。この問題は、'ipv6.disable=1'パラメータで起動した環境でinet6_init()がndisc_init()を呼び出す前に終了し、nd_tblが初期化されないために発生します。結果として、IPv6パケットがインターフェースに注入されるとroute_shortcircuit()が呼び出され、neigh_lookup()でNULLポインタ参照が発生してシステムがクラッシュする可能性があります。この脆弱性は、protocolがETH_P_IPV6の場合にroute_shortcircuit()で早期チェックを追加することで修正されました。

Linuxカーネルにおいて、accel/amdxdnaのサスペンドおよびレジューム時に発生するデッドロックの脆弱性が修正されました。自動サスペンド実行中にクエリIOCTLを発行すると、dev_lockを保持したままpm_runtime_resume_and_get()が呼び出され、この関数は進行中のサスペンド完了を待機します。一方でサスペンドコールバックはdev_lockの取得を試みてブロックし、その結果としてデッドロックが発生します。この問題は、pm_runtime_resume_and_get()呼び出し前にdev_lockを解放し、呼び出し後に再取得する手法により修正されました。

Linuxカーネルに存在した脆弱性は、nfsd_nl_threads_set_doit()関数内でのcred参照リークに関するものです。この関数は、get_current_cred()を使って取得したcredを適切に解放せず、その結果、メモリリークが発生していました。具体的には、credの参照カウントの所有権がどこにも正しく転送されず、リークが生じていました。この問題は、current_cred()の使用に変更することで修正されました。

Linuxカーネルにおいて、以下の脆弱性が修正されました：can: ucanにおける長さ0のメッセージによる無限ループの問題です。壊れたucanデバイスがメッセージ長フィールドを0に設定したメッセージを受け取ると、ドライバはucan_read_bulk_callback()関数内で無限ループに陥り、システムがハングします。長さが0の場合は、そのメッセージをスキップして次のメッセージに進むように修正しました。この問題は、過去にkvaser_usbドライバのコミット0c73772cd2b8（"can: kvaser_usb: leaf: コマンドパーサの無限ループの可能性を修正"）で修正されているため、このような壊れたデバイスがどこかに存在している可能性があります。

Linuxカーネルにおいて、以下の脆弱性が修正されました。Bluetoothのソケットデストラクタでのエラーキューの消去に関する問題です。SO_TIMESTAMPINGを介してTXタイムスタンプが有効になっている場合、SKBがsk_error_queueにキューイングされ、消費されるまでそこに留まる可能性があります。ユーザー空間がタイムスタンプを読み取らなかったり、コントローラが予期せず取り外された場合、これらのSKBがリークしてしまいます。影響を受けるBluetoothのデストラクタに対して、sk_error_queueに対するskb_queue_purge()呼び出しを追加することでこの問題を修正しました。なお、RFCOMMは現在sk_error_queueを使用していません。

Mattermostプラグインのバージョン=11.5、11.1.5、10.13.11、11.3.4.0には、Gitlabプラグインでコマンドを処理する際に権限を適切に確認しない脆弱性があり、通常のユーザーが{{gitlab instance {option}}}または{{/gitlab webhook {option}}}コマンドを使用してインスタンスをアンインストールしたりWebhook接続の設定を変更したりすることが可能です。MattermostアドバイザリーID：MMSA-2026-00600。

Kibanaにおけるリソースの有効期限切れや終了後の操作（CWE-672）は、不正な情報漏えいを引き起こす可能性があります。有効期限のタイムスタンプを検証する方法に論理的な誤りがあり、時間制限付きアクセストークンが本来の有効期限を過ぎても使用可能なままになります。そのため、認証されていない攻撃者がそのトークンを所持している場合、有効期限切れ後でも関連するコンテンツを取得できます。

Kibanaにおける制御されていないリソース消費（CWE-400）は、過剰割り当て（CAPEC-130）を介してサービス拒否を引き起こす可能性があります。低権限の認証ユーザーが特別に細工された大きすぎるペイロードを内部のKibana APIに送信すると、Kibanaプロセスが利用可能なリソースを使い果たし、サービスが回復するか再起動されるまで、全ユーザーに対して応答不能になることがあります。

GPACのコミットv391dc7f4d234988ea0bc3cc294eb725eddf8f702以前に存在するバッファオーバーフローの脆弱性により、攻撃者はsrc/scenegraph/svg_attributes.cのsvg_parse_strings()およびgf_svg_parse_attribute()を介してサービス拒否を引き起こす可能性があります。

DeviseはWardenに基づくRails用の認証ソリューションです。バージョン5.0.3以下では、TimeoutableモジュールがDeviseで有効になっている場合、FailureApp#redirect_urlメソッドがリクエストのリファラ（HTTP Refererヘッダーであり攻撃者が制御可能）を検証なしに返してしまいます。これはセッションタイムアウトが発生した非GETリクエストに対して起こります。攻撃者が自動送信するクロスオリジンフォームをホストしたページを用意すると、有効期限切れのDeviseセッションを持つ被害者を任意の外部URLへリダイレクトさせることが可能です。これはGETタイムアウトのパス（サーバー側のattempted_pathを使用）やDevise独自のstore_location_forメカニズム（extract_path_from_locationによって外部ホストを除去）と対照的であり、これらは保護されていますが、非GETタイムアウトリダイレクトパスのみが保護されていません。有効期限切れのセッションを持つユーザーは信頼されたアプリドメインから攻撃者制御のURLへ静かにリダイレクトされます。そのため、フィッシングやマルウェア配布がブラウザ警告を回避して可能になります。注意点として、Railsの組み込みのオープンリダイレクト保護はこの問題を軽減しません。Devise::FailureAppは独自の関連リダイレクト構成のコピーを持つActionController::Metalアプリであるため、config.action_controller.action_on_open_redirect = :raise（および古いraise_on_open_redirects設定）は影響を及ぼしません。この問題はバージョン5.0.4で修正されました。

BentoMLは、AIアプリケーションやモデル推論に最適化されたオンラインサービングシステムを構築するためのPythonライブラリです。バージョン1.4.38およびそれ以前では、ビルドパッケージングのワークフローがビルドコンテキスト内の攻撃者が制御するシンボリックリンクをたどり、参照されたファイルの内容を生成されたBentoアーティファクトにコピーしてしまいます。被害者が信頼できないリポジトリや攻撃者が提供したビルドコンテキストをビルドすると、攻撃者はloot.txt - /tmp/outside-marker.txtのようなシンボリックリンクや、より機密性の高いローカルファイルへのリンクを配置できます。bentoml buildが実行されると、BentoMLはシンボリックリンクを参照し、そのターゲットファイルの内容をBentoにパッケージします。漏えいしたファイルはその後、エクスポート、プッシュ、またはコンテナ化のワークフローを通じてさらに拡散する可能性があります。攻撃者はビルドホストのローカルファイルをBentoアーティファクトに抽出して、クラウド認証情報、SSHキー、APIトークン、環境ファイル、その他の機密ローカル構成情報などの秘密情報を露出させることができます。Bentoアーティファクトは一般的にビルド後にエクスポート、アップロード、保存、コンテナ化されるため、漏えいしたファイルの内容が元のビルドマシンの範囲を超えて拡散する可能性があります。この問題はバージョン1.4.39で修正されています。

Apache Artemisには、STOMPプロトコルを使用し、アドレスに対してconsumeまたはsendの権限を持つセキュリティ資格情報を用いるアプリケーションにおいて、該当ユーザーが特定のアドレスに対するcreateAddress権限を持っていなくても、そのアドレスがサポートするルーティングタイプを拡張できてしまうという脆弱性があります。ユーザーは、本来拒否されるべきルーティングタイプの変更権限を持たないにもかかわらず、対応するアドレスがサポートしないルーティングタイプでメッセージを送信したり、キューからメッセージを消費したりすることが可能です。送信および／または消費の権限が付与されている場合でも、createAddress権限なしにアドレスのルーティングタイプを拡張してはなりません。この問題は、Apache Artemisバージョン2.50.0から2.53.0まで、およびApache ActiveMQ Artemisバージョン2.0.0から2.44.0までに影響を及ぼします。ユーザーはこの問題を修正したバージョン2.54.0へアップグレードすることを推奨します。

KibanaにおけるWebページ生成時の入力の不適切な無害化（CWE-79）が、格納型HTMLインジェクションを引き起こす可能性があります。Elasticsearchインデックスへの書き込み権限を持つユーザーが巧妙に作成したマークアップを永続化でき、それが影響を受けるKibanaビューによって別のユーザーによりレンダリングされる際に、十分にサニタイズされませんでした。これが悪用されると、不正なUI操作が行われたり、閲覧ユーザーのブラウザーセッションから外向きネットワークリクエストが送信されたりする可能性があります。

Linuxカーネルにおいて、以下の脆弱性が修正されました。serial: 8250におけるDMA使用時のTXデッドロックの問題を修正しました。`dmaengine_terminate_async`は`__dma_tx_complete`コールバックが必ず実行されることを保証しません。このコールバックは現在、`dma-tx_running`がクリアされる唯一の場所です。トランザクションがキャンセルされてコールバックが実行されない場合、`dma-tx_running`はクリアされず、新しいTX DMAトランザクションが再スケジュールされなくなります。この変更により、DMAトランザクションを終了した後に`dma-tx_running`をクリアするようにしました。これは「安全」である理由は、`serial8250_tx_dma_flush`がUARTポートロックを保持しており、コールバックも最初にUARTポートロックを取得するため、`dma-tx_running`へのアクセスが直列化されているからです。

Linuxカーネルにおいて、以下の脆弱性が修正されました。dmaengineのidxdにおいて、.release()関数でワークキューを解放しない問題がありました。また、DSA/IAAデバイスに関連付けられたワークキューがオブジェクト解放時に解放されないという問題も存在していました。

Linuxカーネルにおいて、以下の脆弱性が修正されました。ext4のext4_mb_release()関数で、常にキューに入ったdiscard作業を排出する問題です。最近のext4パッチ[1]のレビュー中に、Sashikoは以下の懸念を示しました[2]。最初にdiscardオプション付きでファイルシステムがマウントされた場合、ファイル削除はsbi-s_discard_listを更新し、s_discard_workをキューに入れます。その後、nodiscardオプションで再マウントすると、EXT4_MOUNT_DISCARDフラグはクリアされますが、保留中のs_discard_workはキャンセルも排出もされません。[1] https://lore.kernel.org/r/20260319094545.19291-1-qiang.zhang@linux.dev/ [2] https://sashiko.dev/#/patchset/20260319094545.19291-1-qiang.zhang%40linux.dev この懸念は妥当でしたが、パッチ[1]自体には関係ありませんでした。Sashikoの現状（初期）形態の問題の一つは、既存の問題を検出し、それをレビュー中のパッチの問題として報告してしまう点にあります。実際には、意図的に再現するのは難しいです（悪意あるsyzkallerファザーでない限り）。なぜなら、-o discard付きでファイルシステムをマウントして大量のファイルを削除し、その後-o nodiscardで再マウントし、キューに入ったdiscard作業が自身で排出される前にファイルシステムをすぐにアンマウントしなければならないからです。これは実際のバグであるため修正され、将来mballoc.cのパッチ解析時にSashikoがこの懸念を再度指摘することを回避します。

Linuxカーネルにおいて、以下の脆弱性が修正されました。ext4におけるext4_fc_replay_inode()のエラーパスで発生していたiloc.bhリークを修正しました。コードレビュー中にJosephは、ext4_fc_replay_inode()がinodeの位置を取得するためにext4_get_fc_inode_loc()を呼び出し、これがbrelse()で解放されるべきiloc.bhの参照を保持していることを発見しました。しかし、いくつかのエラーパスでiloc.bhを解放せずに'out'ラベルにジャンプしていました。具体的には、ext4_handle_dirty_metadata()、sync_dirty_buffer()、ext4_mark_inode_used()、ext4_iget()の失敗時です。これを修正するために、既存の'out'ラベルの直前に'iloc.bh'を必ず解放する'out_brelse'ラベルを導入しました。加えて、ext4_fc_replay_inode()が常に0を返すのではなく、エラーを適切に伝播させるようにしました。

Linuxカーネルにおいて、以下の脆弱性が修正されました：Bluetoothのhci_llにおけるエラーパスでのファームウェアリーク問題です。Smatchの報告によると、drivers/bluetooth/hci_ll.cのdownload_firmware()関数内で、request_firmware()から取得した'fw'が行544で解放されていませんでした。download_firmware()は、request_firmware()が成功したにもかかわらず、返されたファームウェアの内容が無効（データなしまたはサイズ0）の場合に、ファームウェアを解放せずに関数から戻るため、リソースリークが発生していました。これを修正するために、request_firmware()が成功したがファームウェアの内容が無効な場合でも、戻る前にrelease_firmware()を呼び出すようにしました。

Linuxカーネルにおいて、以下の脆弱性が修正されました：drm/vc4のplatform_get_irq_byname()関数はint型の値を返します。platform_get_irq_byname()関数はエラーが発生した場合に負の値を返すため、その返り値を適切にチェックし、すべてが正常であることを確認してからdevm_request_threaded_irq()に渡す必要があります。

Nautobotはネットワークの情報源およびネットワーク自動化プラットフォームです。2.4.33および3.1.2より前のバージョンでは、GenericForeignKeyを介したオブジェクト間の参照（これは、オブジェクトが複数の異なる「コンテンツタイプ」またはデータベーステーブルのいずれかに属する別のオブジェクトを参照できるパターンです）において、GenericForeignKeyを含むオブジェクトの作成または更新時に、NautobotのREST APIが対象オブジェクトの「閲覧」権限を適切に適用せず、その参照が有効であるかどうかを検証できない問題がありました。この脆弱性は2.4.33および3.1.2で修正されています。