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

fusefsファイルシステムが拡張属性を実装している場合、カーネルは特定のファイルの拡張属性リストを取得するためにユーザースペースのデーモンにFUSE_LISTXATTRメッセージを送信します。FUSEプロトコルでは、デーモンがNUL終端文字列でパックされたリストを返す必要があります。しかし、fusefsカーネルモジュールは、このデーモンから提供されたバッファ全体がNUL終端されていることを事前に検証せずにstrlen()を呼び出します。悪意のあるデーモンがNUL終端されていないリストを送信した場合、fusefsカーネルモジュールはヒープ上に割り当てられたバッファの終端を越えて読み取りを行い、さらに2番目のバッファの終端を越えて書き込みを行う可能性があります。これにより、悪意のあるデーモンは最大253バイトのカーネルヒープメモリを漏洩させるか、最大250バイトの攻撃者制御下のデータを未割り当てのカーネルヒープ領域に注入できます。

cap_netサービスの場合、古い制限に存在していたキーが新しい制限から省略された場合、省略されたキーは拒否されるのではなく「すべて許可」として扱われていました。特定のシナリオでは、以前にネットワーク操作のサブセットを制限していたアプリケーションが、プロセスの権限を拡張するために新しい制限を要求することがありました。

WebAssembly Binaryen バージョン117までに脆弱性が検出されました。この問題は、コンポーネントBrOn Parserのファイルsrc/wasm/wasm-ir-builder.cpp内の関数IRBuilder::makeBrOnに影響します。この操作を行うと到達可能なアサーションが発生します。攻撃はローカルで行う必要があります。この脆弱性のエクスプロイトは既に公開されており、悪用される可能性があります。この問題に対処するために、1251efbc1ea471c1311d2726b2bbe061ff2a291cという名前のパッチを適用することが推奨されます。

Windows向けGoogle Chromeのバージョン148.0.7778.168より前に存在したIFrameサンドボックスのポリシー強制の不備により、リモートの攻撃者が細工されたHTMLページを介してナビゲーション制限を回避できる可能性がありました。

AndroidおよびMacのGoogle Chromeバージョン148.0.7778.168以前のダウンロードにおいて、不正なセキュリティUIにより、リモートの攻撃者が巧妙に作成されたHTMLページを介してUIスプーフィングを実行する可能性がありました。

148.0.7778.168以前のMac用Google ChromeのDownloadsにおける不適切な実装により、攻撃者は悪意のある拡張機能のインストールをユーザーに促すことができ、巧妙に作成されたChrome拡張機能を通じてUIスプーフィングを実行する可能性があります。

LinuxおよびChromeOS上のGoogle Chromeのバージョン148.0.7778.168より前に存在したCORSの不適切な実装により、リモートの攻撃者が細工されたHTMLページを通じてクロスオリジンデータを漏洩させる可能性がありました。

Windows用Google Chromeの148.0.7778.179以前のバージョンにおいて、UIの不適切な実装により、レンダラープロセスが侵害される問題がありました。これにより、リモート攻撃者が細工されたHTMLページを介してUIスプーフィングを行うことが可能となっていました。

MacのGoogle Chrome148.0.7778.179より前のバージョンにおいて、GPUの境界外読み取りの脆弱性が存在し、リモート攻撃者が細工されたHTMLページを介して境界外メモリの読み取りを実行できる可能性がありました。

Google Chromeのバージョン148.0.7778.179以前のService Workerにおけるポリシー強制が不十分であったため、リモート攻撃者が細工されたHTMLページを通じて同一生成元ポリシーを回避できる可能性がありました。

Google Chromeの148.0.7778.179以前のバージョンにおいて、ServiceWorkerのポリシー施行が不十分であったため、リモートの攻撃者が細工されたHTMLページを介してクロスオリジンデータを漏洩させる可能性がありました。

Linuxカーネルにおいて、以下の脆弱性が修正されました：sunrpcのcache_releaseにおけるcache_requestメモリリークの修正です。読み取り中にファイルディスクリプタが閉じられた場合（rp-offset != 0）、cache_release()はリクエストのreadersカウントをデクリメントしますが、リクエストを解放すべきかどうかを確認しません。cache_read()では、readersが0になり、かつCACHE_PENDINGがクリアされている場合、cache_requestはキューから削除され、バッファおよびcache_head参照と共に解放されますが、cache_release()にはこのクリーンアップ処理が欠けていました。readersが0のリクエストを解放するもう一つの経路はcache_dequeue()ですが、これはCACHE_PENDINGがセットからクリアに遷移したときのみ実行されます。もしその遷移がreadersが非ゼロの間に起きていた場合、cache_dequeue()はそのリクエストをスキップし、以降の呼び出しでもクリーンアップされません。これを解決するために、cache_release()にcache_read()のクリーンアップロジックを追加しました。readersをデクリメントした後、readersが0かつCACHE_PENDINGがクリアされているかをチェックし、条件を満たせばcache_requestをキューから外して解放します。

Linuxカーネルにおいて、以下の脆弱性が修正されました：ksmbdはFS_OBJECT_ID_INFORMATIONでボリュームUUIDを使用します。主に適切なボリューム識別子としてsb-s_uuidを使用します。UUIDを提供しないファイルシステムの場合は、vfs_statfs()から取得したstfs.f_fsidを用いて識別します。

LinuxカーネルにおけるATMネットワークの脆弱性を修正する内容です。sigd_send()関数が未検証のvccポインタを直接使用していたため、悪意のあるユーザーがクラッシュを引き起こす可能性がありました。この脆弱性は、ユーザー空間から偽造されたポインタが送信されることで悪用され、カーネルが不正なポインタを逆参照してしまうものでした。修正では、vcc_hash上のポインタを検索し検証するfind_get_vcc()を導入し、参照カウントを管理するsock_hold()を使用して無効なポインタの使用を防止しています。これにより、カーネルのメモリ安全性が確保され、任意のポインタによるクラッシュを防止します。

Linuxカーネルにおいて、以下の脆弱性が修正されました。usb: gadget: f_mass_storageにおけるcheck_command_size_in_blocks()関数での潜在的な整数オーバーフローの問題です。`check_command_size_in_blocks()`関数は、`common-data_size_from_cmnd`をブロックサイズ（`common-curlun-blkbits`）分だけ左シフトしてデータサイズ（バイト単位）を計算します。しかし、このシフト操作によって整数オーバーフローが発生するかどうかの検証が行われていませんでした。ブロックサイズは`fsg_lun_open()`で設定され、`common-data_size_from_cmnd`は`do_scsi_command()`で設定されます。初期化時にはこれら二つの変数間での整数オーバーフローの確認が行われていませんでした。そのため、悪意のあるUSBホストが大量のデータを要求するSCSI READまたはWRITEコマンド（`common-data_size_from_cmnd`）を送信すると、左シフト操作がオーバーフローしデータサイズが切り詰められて境界チェックを回避できる可能性がありました。これにより、メモリ破損や範囲外アクセスが発生する恐れがありました。この問題は、check_shl_overflow()マクロを用いて安全にシフトを行い、オーバーフローを検出することで修正されました。

Linuxカーネルにおいて、次の脆弱性が修正されました：ipv6のip6_datagram_send_ctl()におけるオーバーフローを回避する問題です。イーミン・チアン氏より報告されました。IPv6のsendmsg補助データパスにてローカルでトリガ可能なカーネルバグが発見されました。これによりskb_under_panic()を介してカーネルパニックが発生し（ローカルDoS）、システムが停止します。根本原因は16ビット長のアキュムレータ（struct ipv6_txoptions::opt_flen、型__u16）と最後の宛先オプションヘッダーを指すポインタ（opt-dst1opt）との不整合にあります。複数のIPV6_DSTOPTS制御メッセージ（cmsg）が渡された際にこの問題が発生します。include/net/ipv6.hにおいてstruct ipv6_txoptions::opt_flenは__u16型であり、ラップの可能性があります（291-307行、特に298行）。net/ipv6/datagram.cのip6_datagram_send_ctl()関数では繰り返されるIPV6_DSTOPTSを受け入れopt_flenを加算しますが、重複は排除されません（909-933行）。net/ipv6/ip6_output.cの__ip6_append_data()関数はopt-opt_flen+opt-opt_nflenでヘッダーサイズやヘッドルームを計算しています（1448-1466行、特に1463-1465行）。__ip6_make_skb()はopt-opt_flenが非ゼロの場合にipv6_push_frag_opts()を呼び出します（1930-1934行）。ipv6_push_frag_opts()やipv6_push_exthdr()はdst1optに基づくipv6_optlen(opt-dst1opt)でプッシュサイズを決定しています（1179-1185行および1206-1211行）。問題点は次の通りです。1. opt_flenは16ビットのアキュムレータであること（include/net/ipv6.hの298行で定義）。2. ip6_datagram_send_ctl()は繰り返しのIPV6_DSTOPTS cmsgを受け入れ、毎回opt_flenを加算していますが、重複排除措置がありません（net/ipv6/datagram.cの909-933行）。大量の大きなIPV6_DSTOPTS cmsgを提供するとopt_flenはラップしますが、dst1optは依然として大きな（2048バイトの）宛先オプションヘッダーを指し続けます。PoC(poc.c)では32個のhdrlen=255のcmsg（長さ2048バイト）と1個のhdrlen=0のcmsg（長さ8バイト）を送り、合計65544バイト加算してopt_flenは16ビットのため8にラップし、一方でdst1optは2048バイトの最後のcmsgを指します。3. 送信パスはラップしたopt_flenに基づきヘッダーサイズを計算するため（net/ipv6/ip6_output.cの1463-1465行）、実際にプッシュされる長さを過小評価します。4. skbを構築するときはdst1optの長さに基づいてプッシュされるため、opt_flenのラップは制限になりません（net/ipv6/ip6_output.cの1930-1934行、net/ipv6/exthdrs.cの1179-1185および1206-1211行）。ヘッドルームが不足してskb_push()がアンダーフローするとskb_under_panic()を引き起こしBUG()となり、それによりカーネルパニックが発生します。IPV6_DSTOPTS cmsg経路は対象のネットワーク名前空間にCAP_NET_RAW権限を要求します。ルートまたはCAP_NET_RAW権限を持つ任意のプロセスがこの脆弱性を発動可能であり、ユーザー名前空間が有効な場合は権限のないuid=1000のユーザでも名前空間CAP_NET_RAWを取得してトリガ可能です。影響はローカルDoSであり、カーネルのBUGパニックやクラッシュを引き起こします。

Linuxカーネルにおいて、以下の脆弱性が修正されました。netfilterのnfnetlink_logで、netlinkヘッダーサイズを考慮する必要があります。これは以前のバグ修正のフォローアップであり、NLMSG_DONEは属性サイズだけでなくnetlinkヘッダーサイズも考慮しなければなりません。この問題によりWARNスプラットが発生し、netlinkメッセージが破棄されることがありますが、それ以外に悪影響はありません。

Linuxカーネルにおいて、以下の脆弱性が修正されました。netfilterのipsetに関する問題で、mtype_del関数で論理的に空のバケットを破棄する際の誤りがありました。mtype_del()はk内のn-pos以下の空スロットをカウントしますが、バケットを破棄するのはn-posとkの両方がゼロの場合のみでした。そのため、n-posが削除されたスロットを超えて指している間にライブエントリがすべて削除されたバケットを見逃していました。現在はn-pos以下のすべての位置が未使用の場合、そのバケットを空として扱い、縮小するのではなく直接解放するように修正されています。

Linuxカーネルにおける脆弱性で、bridgeサブシステムのmrpがゼロのテスト間隔を受け入れてしまい、これによりシステムのメモリを使い果たしてOOMパニックを引き起こす問題が修正されました。具体的には、br_mrp_start_test()とbr_mrp_start_in_test()がゼロの間隔値を検証せずに受け入れ、遅延作業をゼロ遅延で再スケジュールし続けるため、system_percpu_wq上でタイトなループが形成され、最大速度でテストフレームを送信し続けてしまいます。この問題は、nla_policyテーブルのIFLA_BRIDGE_MRP_START_TEST_INTERVALおよびIFLA_BRIDGE_MRP_START_IN_TEST_INTERVALに範囲制約を加えることで解決されています。

Linuxカーネルにおいて、以下の脆弱性が修正されました。net/sched: cls_fw における共有ブロックでのNULLポインタ参照の問題を修正しました。fw_classify()の旧方式パスはtcf_block_q()を呼び出し、q-handleを参照します。しかし、共有ブロックではblock-qがNULLになるため、空のcls_fwフィルタが共有ブロックにアタッチされ、かつ非ゼロのmajor skbマークを持つパケットが分類される際にNULL参照が発生します。fw_change()で旧方式（TCA_OPTIONSなし）が共有ブロックに使用された場合は設定を拒否します。これはfw_classify()の旧方式パスが共有ブロックでNULLのblock-qを必要とするためです。修正されたNULLポインタ参照呼び出しスタックは以下の通りです。KASAN: NULLポインタ参照範囲[0x0000000000000038-0x000000000000003f]、RIP: 0010:fw_classify(net/sched/cls_fw.c:81)。呼び出しトレースは、tcf_classify(./include/net/tc_wrapper.h:197、net/sched/cls_api.c:1764、net/sched/cls_api.c:1860)、tc_run(net/core/dev.c:4401)、__dev_queue_xmit(net/core/dev.c:4535、net/core/dev.c:4790)です。

Linuxカーネルにおいて、共有ブロックでNULLポインタ参照の脆弱性が修正されました。flow_change()関数はtcf_block_q()を呼び出し、q-handleを参照してデフォルトのbaseclassを求めますが、共有ブロックではblock-qがNULLになります。そのため、共有ブロック上で完全に修飾されたbaseclassを持たないフローフィルタが作成されたときにNULL参照が発生していました。この問題は、block-qにアクセスする前にtcf_block_shared()で共有ブロックかどうかを検査し、共有ブロックの場合は-EINVALを返すことで解決されました。

Linuxカーネルにおいて、以下の脆弱性が修正されました。net/schedのsch_hfscサブシステムにあるrtsc_min()関数におけるゼロ除算の問題です。m2sm()関数はu32のスロープをu64のスケール値に変換します。大きな入力（例：m1=4000000000）の場合、結果が2^32に達することがあります。rtsc_min()関数は、そのような2つのu64値の差をu32変数であるdsmに格納し、このdsmを除数として使用します。差がちょうど2^32の場合、切り捨てによりdsmがゼロとなり、凹型曲線の交差パスでゼロ除算エラーが発生しました。エラー内容は「divide error: 0000RIP: 0010:rtsc_min (net/sched/sch_hfsc.c:601)」で、コールトレースにはinit_ed (net/sched/sch_hfsc.c:629)、hfsc_enqueue (net/sched/sch_hfsc.c:1569)などが含まれています。この問題を解決するために、dsmをu64に拡張し、元のdo_div()関数をdiv64_u64()に置き換えて差分全体を保持するように修正しました。

Linuxカーネルにおいて、以下の脆弱性が修正されました：netfilterのx_tablesにおけるNFPROTO_ARPに対するxt_check_matchおよびxt_check_target拡張機能の制限問題です。Weiming Shiによると、NFPROTO_UNSPECで登録されたxt_matchおよびxt_target構造体はnft_compatを通じて任意のプロトコルファミリでロード可能でした。このようなマッチやターゲットが特定のフックでのみ動作を制限するために.hooksを設定した場合、そのビットマスクはNF_INET_*定数を使用します。しかしこれはIPv4、IPv6、INET、ブリッジのようにNF_INET_*のフック配置に一致するファミリにのみ正しく適用され、ARPはIN=0、OUT=1、FORWARD=2の3つの異なるフックを持ち、意味も異なります。NF_ARP_OUTは1であり、NF_INET_LOCAL_INと等しいため、.hooksの検証は誤った理由で静かに通過します。その結果、フックの仮定（例：入力フックでstate-inがセットされること）が成り立たないARPチェイン上でマッチが実行されてしまいます。これによりNULLポインタ参照が発生し、xt_devgroupが具体的な例となりました。このエラーは「Oops: general protection fault, probably for non-canonical address 0xdffffc0000000044」やKASANのNULLポインタ逆参照として現れます。修正内容は、arptablesをNFPROTO_ARP拡張のみ使用可能に制限することです。なお、arptables-legacyは明示的にNFPROTO_ARPのマッチおよびターゲット宣言を提供する以下のもののみ対応しています：arpt_CLASSIFY、arpt_mangle、arpt_MARKです。

Linuxカーネルにおいて、以下の脆弱性が修正されました：rds: ib: IB接続が確立される前のFRMR登録を拒否します。rds_ib_get_mr()はconn-c_transport_dataからrds_ib_connectionを抽出し、FRWRメモリ登録のためにrds_ib_reg_frmr()に渡します。新規の発信接続では、接続ワーカーがまだrdma_cm_idを作成するrds_ib_conn_path_connect()を呼んでいないため、icはrds_ib_conn_alloc()内でi_cm_idがNULLとして割り当てられます。この状態でRDS_CMSG_RDMA_MAPを指定したsendmsg()が呼ばれると、送信パスは接続確立前に制御メッセージを解析し、rds_ib_post_reg_frmr()がic-i_cm_id-qpを逆参照してカーネルをクラッシュさせます。既存のrds_ib_reg_frmr()のガードは!icしかチェックしておらず(commit 9e630bcb7701で追加)、icは接続オブジェクトが存在すると常にNULLでないため、このケースは検知できません。KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:rds_ib_post_reg_frmr+0x50e/0x920 Call Trace: rds_ib_post_reg_frmr (net/rds/ib_frmr.c:167) rds_ib_map_frmr (net/rds/ib_frmr.c:252) rds_ib_reg_frmr (net/rds/ib_frmr.c:430) rds_ib_get_mr (net/rds/ib_rdma.c:615) __rds_rdma_map (net/rds/rdma.c:295) rds_cmsg_rdma_map (net/rds/rdma.c:860) rds_sendmsg (net/rds/send.c:1363) ____sys_sendmsg do_syscall_64 rds_ib_get_mr()にic、i_cm_id、およびqpがすべてNULLでないことを確認するチェックを追加し、FRMR登録を進める前にこれを検証するようにしました。これは既にrds_ib_post_inv()に存在するガードに合わせたものです。接続が準備できていない場合は-ENODEVを返し、rds_cmsg_send()の既存のエラーハンドリングでユーザースペースがリトライ可能な-EAGAINに変換され、rds_conn_connect_if_down()が接続ワーカーを起動する仕組みになっています。

Linuxカーネルにおいて、以下の脆弱性が修正されました。netfilterのnf_conntrack_sipにあるprocess_sdp関数内で、初期化されていないrtp_addrが使用されていた問題を修正しました。process_sdp()は、スタック上にunion nf_inet_addr型のrtp_addrを宣言し、SDPのメディア記述を解析した後、nf_nat_sipのsdp_sessionフックに渡します。しかし、rtp_addrは非ゼロポートの認識されたメディアタイプが見つかった場合にのみ、メディアループ内で初期化されていました。SDPの本文にm=行がない場合、非アクティブなメディアセクション（m=audio 0 ...のようなもの）のみ、または認識されないメディアタイプのみの場合、rtp_addrには一度も値が代入されません。それでも関数は&rtp_addrを引数にhooks-sdp_session()を呼び出し、nf_nat_sdp_session()がスタックに残った古い値をIPアドレスとしてフォーマットし、SDPのセッション所有者や接続行をそのアドレスで書き換えてしまいます。CONFIG_INIT_STACK_ALL_ZERO（ほとんどのディストリビューションでデフォルト）設定の場合、セッションレベルのo=およびc=アドレスは非アクティブなSDPセッションで0.0.0.0に書き換えられます。スタックの自動初期化がない場合は、書き換えられるアドレスにスタックにあった任意の値が使用されてしまいます。この問題は、利用可能な場合にはrtp_addrをセッションレベルの接続アドレス（caddr）で事前に初期化し、有効なアドレスが確立されたかどうかをhave_rtp_addrフラグで追跡することで修正されました。有効なアドレスが存在しない場合は、sdp_sessionフックの呼び出しを完全にスキップする処理が追加されました。

Linuxカーネルにおいて、以下の脆弱性が修正されました：netfilterのnfnetlink_logにおけるNFULA_PAYLOAD内の未初期化パディング情報漏えいの問題です。__build_packet_message()関数はskb_put()およびskb_copy_bits()を使用して手動でNFULA_PAYLOADのnetlink属性を構築しており、標準のnla_reserve()/nla_put()ヘルパーを回避していました。nla_total_size(data_len)バイト（NLAアラインメントパディングを含む）が割り当てられているにもかかわらず、実際のパケットデータはdata_lenバイトのみコピーされていました。data_lenが4バイト境界に揃っていない場合、後続のnla_padlen(data_len)バイト（1〜3バイト）が初期化されず、古いヒープ内容がNFLOG netlinkソケットを介してユーザースペースに漏えいしていました。手動による属性構築をnla_reserve()に置き換えました。これにより、__nla_reserve()で余白チェック、ヘッダー設定、パディングのゼロクリアが適切に処理されます。その後、skb_copy_bits()は正しく初期化された属性の上にペイロードデータを填充します。

Linuxカーネルにおいて、以下の脆弱性が修正されました。net: skbにおけるKFENCEで割り当てられたskbヘッドのクロスキャッシュ解放の問題が修正されています。SKB_SMALL_HEAD_CACHE_SIZEは、一般的なkmallocバケットサイズと衝突を避けるために意図的に2の累乗ではない値（例えばx86_64では704）に設定されています。この設定により、skb_kfree_head()はskb_end_offsetを使用し、skb_small_head_cacheから割り当てられたskbヘッドと一般的なkmallocキャッシュから割り当てられたskbヘッドを確実に区別できるようになっています。しかし、KFENCEが有効な場合、kfence_ksize()はスラブバケットサイズではなく正確な要求サイズを返します。呼び出し元（例えばbpf_test_init）がkzalloc()を使ってskbヘッドデータを割り当て、要求サイズがSKB_SMALL_HEAD_CACHE_SIZEと一致した場合、slab_build_skb() - ksize()はその正確な値を返します。skb_shared_infoのオーバーヘッドを差し引くとskb_end_offsetがSKB_SMALL_HEAD_HEADROOMと一致し、skb_kfree_head()が誤ってオブジェクトを元のkmallocキャッシュではなくskb_small_head_cacheに解放します。このためスラブのクロスキャッシュ解放が発生します。現象の例として、kmem_cache_free(skbuff_small_head): Wrong slab cache. Expected skbuff_small_head but got kmalloc-1kというエラーが発生します。この問題はskb_kfree_head()で常にkfree(head)を呼び出すことで修正されました。これにより解放パスは汎用的になり、KFENCEオブジェクトに対するアロケータ固有の誤分類を回避できます。

Linuxカーネルにおいて、以下の脆弱性が修正されました。btrfs: sub-group space_infoのkobject名のリークを修正しました。create_space_info_sub_group()がspace_info-sub_group[]の要素を割り当てる際、btrfs_sysfs_add_space_info_type()を通じて各要素に対してkobject_init_and_add()が呼ばれます。しかし、check_removing_space_info()がこれらの要素を解放するとき、btrfs_sysfs_remove_space_info()を呼び出していません。その結果、kobject_put()が呼ばれず、関連するkobj-nameオブジェクトがリークします。このメモリリークは、CONFIG_DEBUG_KMEMLEAKを有効にしてビルドしたカーネルでblktestsのzbd/009テストケースを実行することで再現します。kmemleak機能は以下のエラーを報告します。未参照オブジェクト0xffff888112877d40（サイズ16）： comm "mount"、pid 1244、jiffies 4294996972 16バイトの16進ダンプ： 64 61 74 61 2d 72 65 6c 6f 63 00 c4 c6 a7 cb 7f バックトレース（crc 53ffde4d）： __kmalloc_node_track_caller_noprof+0x619/0x870 kstrdup+0x42/0xc0 kobject_set_name_vargs+0x44/0x110 kobject_init_and_add+0xcf/0x150 btrfs_sysfs_add_space_info_type+0xfc/0x210 [btrfs] create_space_info_sub_group.constprop.0+0xfb/0x1b0 [btrfs] create_space_info+0x211/0x320 [btrfs] btrfs_init_space_info+0x15a/0x1b0 [btrfs] open_ctree+0x33c7/0x4a50 [btrfs] btrfs_get_tree.cold+0x9f/0x1ee [btrfs] vfs_get_tree+0x87/0x2f0 vfs_cmd_create+0xbd/0x280 __do_sys_fsconfig+0x3df/0x990 do_syscall_64+0x136/0x1540 entry_SYSCALL_64_after_hwframe+0x76/0x7e リークを防ぐため、要素の解放時にはkfree()の代わりにbtrfs_sysfs_remove_space_info()を呼び出す必要があります。

libheifはHEIFおよびAVIFファイルフォーマットのデコーダおよびエンコーダです。バージョン1.21.2およびそれ以前のバージョンでは、stscボックス内のsamples_per_chunkが0に設定された細工された792バイトのHEIFシーケンスファイルが、Chunkコンストラクタ内で符号なし整数のアンダーフローを引き起こします（m_last_sample = 0 + 0 - 1 = UINT32_MAX）。これにより、すべてのサンプルが空のチャンクにマッピングされ、サービス拒否（DoS）が発生します。任意のサンプルにアクセスすると、ライブラリは空のstd::vectorのインデックス0から読み取ろうとし、確実にSEGV（ヌルページ読み取り）を引き起こします。ファイルはエラーを生成せずに正常に解析されますが、クラッシュは最初のフレームアクセス時に発生します。この問題はバージョン1.22.0で修正されました。

libheifはHEIFおよびAVIFファイルフォーマットのデコーダーおよびエンコーダーです。バージョン1.21.2以下において、細工された800バイトのHEIFシーケンスファイルがBox_stts::get_sample_duration()内で無限ループを引き起こし、CPUを100％消費し続けて進捗が全くなく、DoS（サービス拒否）を引き起こします。このループには反復回数の制限やタイムアウトがなく、ファイルのオープン（解析）時にトリガーされ、ユーザーの操作や画像のデコード前に発生します。プロセスは異常終了せず（クラッシュやエラーも記録されません）存続するため、クラッシュに基づく監視では検知されません。この問題はバージョン1.22.0で修正されています。

Adobe Commerce バージョン 2.4.9-beta1、2.4.8-p4、2.4.7-p9、2.4.6-p14、2.4.5-p16、2.4.4-p17 およびそれ以前のバージョンは、脆弱なサードパーティコンポーネントへの依存が原因で脆弱性の影響を受けます。この脆弱性により、アプリケーションでサービス拒否が発生する可能性があります。攻撃者はこの脆弱性を悪用してアプリケーションをクラッシュさせ、サービス拒否状態を引き起こせます。この問題を悪用するためにユーザーの操作は必要ありません。

Adobe Commerce のバージョン 2.4.9-beta1、2.4.8-p4、2.4.7-p9、2.4.6-p14、2.4.5-p16、2.4.4-p17 およびそれ以前のバージョンは、ストアドクロスサイトスクリプティング（XSS）脆弱性の影響を受けます。この脆弱性により、高権限の攻撃者は悪意のあるスクリプトを脆弱なフォームフィールドに注入できる可能性があります。被害者が脆弱なフィールドを含むページを閲覧すると、悪意のある JavaScript が被害者のブラウザ上で実行される可能性があります。影響範囲が変更されました。

Adobe Commerce バージョン 2.4.9-beta1、2.4.8-p4、2.4.7-p9、2.4.6-p14、2.4.5-p16、2.4.4-p17 およびそれ以前のバージョンは、不適切な認可の脆弱性の影響を受ける可能性があり、これによりセキュリティ機能を回避されるおそれがあります。攻撃者はこの脆弱性を悪用してセキュリティ措置を回避し、不正な書き込みアクセスを取得できます。この問題を悪用するには、被害者が悪意を持って細工された URL を訪問するか、改ざんされたウェブページと対話するなどのユーザー操作が必要です。

Adobe Commerceのバージョン2.4.9-beta1、2.4.8-p4、2.4.7-p9、2.4.6-p14、2.4.5-p16、2.4.4-p17およびそれ以前のバージョンは、ストアドクロスサイトスクリプティング（XSS）脆弱性の影響を受けます。この脆弱性は、高権限の攻撃者が脆弱なフォームフィールドに悪意のあるスクリプトを注入するために悪用される可能性があります。被害者が脆弱なフィールドを含むページを閲覧すると、悪意のあるJavaScriptが被害者のブラウザで実行される恐れがあります。なお、スコープが変更されました。

Linuxカーネルにおいて、以下の脆弱性が修正されました。ext4の関数ext4_mb_find_by_goal()で、破損したグループからブロックを割り当てる問題があるためです。ログ解析によると、破損したブロックグループから常にブロックが要求される事象が発生しています。この問題は、ext4_mb_find_by_goal → ext4_mb_load_buddy → ext4_mb_load_buddy_gfp → ext4_mb_init_cache → ext4_read_block_bitmap_nowait → ext4_wait_block_bitmap → ext4_validate_block_bitmapの流れで起こる可能性があります。具体的には、grpがNULLまたはEXT4_MB_GRP_BBITMAP_CORRUPT(grp)が真の場合、-EFSCORRUPTEDを返しますが、ログは記録されません。エラーがあればそのまま返されますが、ext4_lock_group(ac-ac_sb, group)内のEXT4_MB_GRP_BBITMAP_CORRUPT(e4b-bd_info)は通常到達できません。commit 9008a58e5dce（"ext4: make the bitmap read routines return real error codes"）の導入後、commit 163a203ddb36（"ext4: mark block group as corrupt on block bitmap error"）は、破損したブロックグループからのブロック割り当てを根本的に解決するものではありません。なぜなら、EXT4_MB_GRP_BBITMAP_CORRUPT(e4b-bd_info)が真の場合、ext4_mb_load_buddy()はエラーを返す可能性があり、それによってブロック割り当てが失敗するからです。したがって、ext4_mb_load_buddy()がエラーを返した場合は、ブロックグループが破損していないかを確認する必要があります。

Linuxカーネルにおいて、次の脆弱性が修正されました：crypto: algif_aead - 復号処理時の最小受信サイズチェックを修正しました。復号時の最小受信バッファサイズのチェックはタグサイズを考慮していなかったため、必要な追加長を加えてこれを修正しました。

LinuxカーネルのUSBガジェットドライバであるf_tcmにおいて、Nexus処理が完全に確立される前にUSBホストが不正なリクエストを送信した場合、NULLポインタ参照が発生してカーネルパニックを引き起こす脆弱性が存在しました。この問題は、tpg-tpg_nexusポインタがNULLである可能性を考慮せずにアクセスしていたために発生し、該当箇所にNULLチェックを追加することで修正されました。これにより、悪意あるUSBホストによるサービス拒否攻撃（DoS）を防止できます。

Linuxカーネルにおいて、usb: image: mdc800のタイムアウト時にダウンロードURBを停止する問題が修正されました。mdc800_device_read()はdownload_urbを送信し完了を待ちますが、タイムアウト時にURBを停止せず、URBがアクティブなままとなっていました。このため、その後のread()でURBを再送信すると「URB submitted while active」という警告が発生していました。wait_event_timeout()の戻り値を確認し、タイムアウトの場合はURBを停止して状態を確認することで、URBを正しく管理することを保証します。関連する修正として、usb: yurexおよびmedia: rc: iguanairのタイムアウト処理も含まれています。

Linuxカーネルにおいて、以下の脆弱性が修正されました。USBコアのusbcoreにあるusb_control_msg()、usb_bulk_msg()、およびusb_interrupt_msg() APIは、以前は無制限の同期タイムアウト期間を許容していました。また、これらのAPIは割り込み不能な待機を使用しているため、対象デバイスの接続を解除しない限り、タスクが無期限にハングし続ける可能性がありました。この問題を防止するため、終了不可のタイムアウトの長さに最大制限を設けました。ここで設定された制限は任意で60秒です。多くのシステム（すべてではありませんが）では、これはカーネルのハングタスク検出器の発動を回避するのに十分短い時間です。加えて、負のタイムアウト値の曖昧さを解消し、それらを0と同様に扱い、最大許容タイムアウトを使用する仕様に変更しました。

Linuxカーネルにおいて、以下の脆弱性が修正されました。USBのusbtmcドライバーは、ユーザーが指定したタイムアウト値を使ってusb_bulk_msg_killable()を呼び出すように変更されました。これにより、ioctlコマンドでユーザーが設定した任意の長さのタイムアウト値が、usb_bulk_msg()の一部呼び出しで使用されます。以前はusb_bulk_msg()が殺せない（停止不可の）待機を使用していたため、ユーザーがカーネルスレッドを無期限にハングさせる可能性がありましたが、この修正によりその問題が回避されます。