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

Linuxカーネルにおいて、dmドライバーがblk_should_fake_timeout()を適切に使用しないために、io-timeout-failエラー注入によりリクエストがリークして完了しなくなる問題がありました。この問題によりタスクが無限にハングする脆弱性が存在しており、これを修正しました。dmはネイティブなタイムアウト処理を持たないため、偽タイムアウトチェックを削除しました。

Linuxカーネルにおいて、以下の脆弱性が修正されました。KVMのnSVMに関するもので、nested_svm_load_cr3()が成功した際にユーザートリガ可能なWARNを削除しました。nested_svm_load_cr3()が失敗した場合のsvm_set_nested_state()内のWARNは、CR3のロード後にCPUIDを変更することでユーザースペースから簡単にトリガ可能であったため削除されました。例として、状態復元の自己テストを以下のように修正します。--- tools/testing/selftests/kvm/x86/state_test.c +++ tools/testing/selftests/kvm/x86/state_test.c @@ -280,7 +280,16 @@ int main(int argc, char *argv[]) /* 新しいVMで状態を復元します。*/ vcpu = vm_recreate_with_one_vcpu(vm); - vcpu_load_state(vcpu, state); + if (stage == 4) {+ state-sregs.cr3 = BIT(44); + vcpu_load_state(vcpu, state); + vcpu_set_cpuid_property(vcpu, X86_PROPERTY_MAX_PHY_ADDR, 36); + __vcpu_nested_state_set(vcpu, &state-nested); +} else {+ vcpu_load_state(vcpu, state); +} /* ダミーvCPUで最初はXSAVE状態を復元しません。*/ 以下のような警告が生成されます。WARNING: CPU: 30 PID: 938 at arch/x86/kvm/svm/nested.c:1877 svm_set_nested_state+0x34a/0x360 [kvm_amd] Modules linked in: kvm_amd kvm irqbypass [last unloaded: kvm] CPU: 30 UID: 1000 PID: 938 Comm: state_test Tainted: G W 6.18.0-rc7-58e10b63777d-next-vm Tainted: [W]=WARN Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:svm_set_nested_state+0x34a/0x360 [kvm_amd] Call Trace: TASK kvm_arch_vcpu_ioctl+0xf33/0x1700 [kvm] kvm_vcpu_ioctl+0x4e6/0x8f0 [kvm] __x64_sys_ioctl+0x8f/0xd0 do_syscall_64+0x61/0xad0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ユーザースペースがCR3に「不正な」状態を押し込むのを防ごうとする代わりに、このWARNを単純に削除しました。KVMのABIはユーザースペースがSREGSの後にCPUIDを設定すること及びその逆も許可しており、KVMはゲストCPUIDに関して非常に寛容です。つまり、CPUIDを設定する際、仮想CPUモデルの強制を試みるとユーザースペースを破壊する可能性があります。このWARNはKVMに対する意味のある保護やユーザースペースにとって利益を提供しないため、破壊の可能性はほとんどないものの単純に削除しました。余計な改行も機会があれば削除しています。

Linuxカーネルにおいて、media: solo6x10のchip_idに関する境界外チェックの脆弱性が修正されました。ClangコンパイラでCONFIG_UBSAN_SHIFT=yを有効にした場合、符号付き型のシフト演算が未定義動作と見なされる問題がありましたが、最大chip IDの境界チェックを追加することで回避しています。これにより、安全に動作することが確認できました。

Linuxカーネルにおいて、以下の脆弱性が修正されました：most: coreにおける早期登録失敗時のリソースリークが修正されました。最近のコミットで早期登録失敗時のリソースリークが修正されましたが、何らかの理由で最初のエラーパスが除外されていたため、インターフェースに関連するリソースが依然としてリークしていました。エラー発生時にインターフェースが常に解放されるよう、最初のエラーパスも修正しました。

Linuxカーネルにおいて、以下の脆弱性が解決されました。drm/amdgpuのamdgpu_dma_buf_move_notifyにおける同期処理が修正されました。dmabufを無効化すると、共有BOの他のユーザーに影響を与えます。プロセスAがBOを移動する場合、プロセスBに移動を通知し、プロセスBはページテーブルを更新する必要があります。このコミットはチケットの使用に起因する同期バグを修正しました。具体的には、amdgpu_vm_handle_movedがページテーブルを即座に更新することが正しいかのように動作していましたが、実際にはそうではありません。例として、P2P PCIがサポートされていないシステムでGPUが2台あり、GPU0でglxgearsが動作し、GPU1でXorgが動作しているシナリオがあります。glxgearsがGPU0からリニアバッファをエクスポートし、GPU1でインポートします。フレームレンダリングはGPU0に送信されます。また、タイルからリニアへのブリット送信も行われます。Xorgではリニアバッファのコピーが実行されます。ジョブの実行順序は以下の通りです。drm_sched_job_runでGPU0のフレームレンダリングが開始され、drm_sched_job_queueでGPU0のブリットがキューに追加されます。その後、drm_sched_job_doneでGPU0のフレームレンダリングが完了し、再びdrm_sched_job_runでGPU0のブリットが実行されます。GPU1がアクセスするためにリニアバッファが移動され、amdgpu_dma_buf_move_notifyでページテーブルが更新されます。この時点でGPU0のブリットジョブはまだ実行中であり、おそらくページフォルトを引き起こします。

Linuxカーネルにおいて、以下の脆弱性が修正されました：spi: spidevにおけるspi_lockとbuf_lock間のロック反転の修正です。spidevドライバーは以前、spi_lockとbuf_lockという2つのミューテックスを使用していましたが、コードパスによって取得順序が異なっていました。write()/read()ではbuf_lock - spi_lock、ioctl()ではspi_lock - buf_lockとなっていました。このAB-BAのロックパターンはlockdep警告を引き起こし、実際のデッドロックを招く可能性がありました。具体的には、spidev_ioctl()でmutex_lock(&spidev-buf_lock)、spidev_sync_write()でmutex_lock(&spidev-spi_lock)が呼ばれていました。この問題は、同一のspidevファイルディスクリプタ上でwrite()とSPI_IOC_WR_MAX_SPEED_HZ ioctl()呼び出しを別スレッドで行う単純なユーザースペースプログラムで再現可能でした。この問題はロックモデルの単純化とロック反転の完全除去により修正されました。具体的にはspidev_sync()はもはやロックを行わず、すべての呼び出し元はspi_lockを使用してアクセスの直列化を行うようになりました。buf_lockは機能が完全にspi_lockに包含されたため削除され、ロック順序の問題が排除されました。これによりロック反転が解消されデッドロックを防止できるようになりました。また、ユーザースペースのABIや動作に変更はありません。

Linuxカーネルのdrm/amd/displayに存在する脆弱性が修正されました。DSCおよびeDPの問題を解決するために、関数フックを使用する前にチェックを追加しました。

Linuxカーネルにおいて、以下の脆弱性が修正されました：sched/fairにおけるzero_vruntimeのトラッキングの修正です。Johnはstress-ng-yieldが自身のマシンに不具合を引き起こすことを報告し、その原因をコミットb3d99f43c72b（"sched/fair: Fix zero_vruntime tracking"）に特定しました。yield動作とこのコミットの組み合わせが特定のシナリオを示しています。2つの実行可能なタスクがあり、両方がyieldを行う場合、一方は実行資格を持ち、もう一方は持ちません。これは平均的な位置が2つのタスクの間にある必要があるためです。したがって、実行可能なタスクは実行資格を持ち、フルスライスの時間が割り当てられます（すべてのタスクは基本的にyieldを行っているだけです）。これにより、このタスクはもう一方のタスクを飛び越え、今度はもう一方のタスクが実行資格を持ち、現在のタスクは実行資格を持たなくなります。次にスケジューリングが行われます。実行可能なため、{de,en}queueは発生せず、{put_prev,set_next}_task()からの__{en,de}queue_entity()のみが存在します。しかし該当コミットによって、これら2つはzero_vruntimeを移動させなくなりました。zero_vruntimeを移動させるのはtickと完全な{de,en}queueのみです。つまり、2つのタスクがリープフロッグ状に動作し、1tickの時間内にオーバーフローポイントに到達する速度に達した場合、問題が発生します。さらに複数のcgroupが関与する場合、tickがすべてのcgroupにタイムリーに届く保証はありません。統計的には届きますが、統計が1つのcgroupが長期間tickを受け取れない可能性を除外するわけではありません。したがって、yield()の場合と同様に、各スライス終了時に強制的に更新を行います。これにより、更新が1スライスを超えて遅延することがなくなり、entity_key()に関するコメント通り、全体が2つの遅延境界内に収まるようになります。

Linuxカーネルにおいて、以下の脆弱性が修正されました。wifi: iwlwifi: mvmにおいて、サポートされていない場合に6E関連のコマンドを送信しないように変更されました。MCC_ALLOWED_AP_TYPE_CMDは6Eサポートに関連するコマンドです。デバイスが6Eをサポートしていない場合、このコマンドを送信してはいけません。ファームウェアは誤ってAX201のような6Eをサポートしないデバイスに対してもこのコマンドのサポートを宣伝しており、その結果ファームウェアがクラッシュしていました。

Linuxカーネルにおいて、以下の脆弱性が修正されました。sched_extでは、waitをbalanceコールバックに延期することでSCX_KICK_WAITのデッドロックを修正しました。SCX_KICK_WAITはkick_cpus_irq_workfn()内でsmp_cond_load_acquire()を用いてターゲットCPUのkick_syncが進行するのを忙待ちしていました。irq_workはhardirqコンテキストで実行されるため、待機中のCPUはリスケジュールできず、自身のkick_syncも進まなくなります。複数のCPUが待機サイクルを形成すると、すべてのCPUがデッドロックします。そこで、kick_cpus_irq_workfn()の忙待ちをresched_curr()に置き換え、CPUをdo_pick_task_scx()へ強制的に移行させ、waitを実行するバランスコールバックをキューに入れます。バランスコールバックはsched_core_balance()パターンに従いrqロックを解放しIRQを有効にするため、CPUは待機中にIPIを処理できます。ローカルCPUのkick_syncはdo_pick_task_scx()の開始時と待機中に継続的に進められ、待機を開始する任意のCPUが進行を認識し、循環依存関係を形成できないようにしています。

Linuxカーネルにおいて、以下の脆弱性が修正されました。USBのdummy-hcdにおけるロックや同期エラーが修正されています。Syzbotのテストにより、drivers/usb/gadgets/udc/core.c内のusb_gadget_udc_reset()ルーチンにおいて、2番目の「driver」引数がNULLで呼び出されたことに起因するアドレッシング例外とクラッシュが発生することが確認されました。問題の原因となった呼び出し元はdummy_hcd.cのset_link_state()であり、この問題はUSBリセットとドライバーのバインド解除の競合によって発生していました。これらの競合は本来発生してはならず、コミット7dbd8f4cabd9（「USB: dummy-hcd: 誤った同期変更の修正」）およびいくつかのフォローアップコミットはこれらの競合を防止するために書かれたものです。しかしながら、コードには少なくとも2つのエラーが残っており、本パッチはそのうちの1つを修正します。Syzbotのクラッシュの原因となったエラーは、stop_activity()ルーチンが時としてdum-lockスピンロックを一度解放してから再取得するために発生していました。emulated USBリセットを処理中にset_link_state()でstop_activity()が呼ばれますが、その呼び出しはdum-ints_enabledのテスト後でdum-callback_usageのインクリメント前に行われます。そのため、別スレッド（ドライバーのバインド解除を行う）がスピンロックを奪い、dum-ints_enabledとdum-driverをクリアする機会を得てしまいました。通常、この別スレッドはdum-callback_usageが0になるまで待機しなければdum-driverをクリアできませんが、今回はまだインクリメントされていなかったため待機する必要がありませんでした。修正としては、stop_activity()を呼ぶ前にdum-callback_usageをインクリメントする方法が取られました。これにより、バインド解除を行うスレッドはusb_gadget_udc_reset()が安全に戻れるようになり、dum-callback_usageが減算されるまではdum-driverをクリアしなくなります。

Linuxカーネルにおいて、次の脆弱性が解決されました。bpfでは、nullableなPTR_TO_BUFポインタへの直接アクセスを拒否するcheck_mem_access()が、base_type()を介してPTR_TO_BUFにマッチし、PTR_MAYBE_NULLを除去していたため、NULLチェックなしでの直接参照を許可していました。マップイテレータのctx-keyおよびctx-valueはPTR_TO_BUF | PTR_MAYBE_NULLであり、停止コールバック時にこれらがNULLとなり、カーネルでNULL参照が発生します。既存のPTR_TO_BTF_IDパターンに合わせて、PTR_TO_BUFブランチにtype_may_be_null()ガードを追加しました。

Linuxカーネルのインターコネクトサブシステムにおいて、SM8450プラットフォーム向けのicc_link_nodes()関数がNULLポインタ参照を引き起こす可能性のある脆弱性が修正されました。この問題は、動的IDへの変更に伴い2つのリンクが変換されていなかったために発生し、宛先インターコネクトへのポインタがNULLとなって実行時にカーネルパニックを引き起こしていました。本修正により、NULLポインタ参照の処理が適切に行われるようになりました。

Linuxカーネルのdrm/amd/displayにあるdcn401_init_hw()関数にNULLポインタ参照の脆弱性が存在しました。update_bw_bounding_box()関数が有効であることを前提に処理が行われますが、条件式が不適切でfreq_changedがtrueの場合にNULLのupdate_bw_bounding_box()が呼び出される可能性がありました。この問題は条件チェックを修正し、コールバックや関連パラメータのNULL確認を追加することで解決されました。

Linuxカーネルにおいて、btrfsのqgroup ioctlがトランザクションのために十分なスペースを予約していなかった脆弱性が修正されました。この問題により、遅延参照を含むクオータツリーの更新時にトランザクションが途中で中断され、グローバルブロックリザーブが乱用される可能性がありました。結果として、トランザクションが中断され、-ENOSPCエラーが発生し、システムの安定性やデータ整合性に影響を与える恐れがありました。この修正により、qgroup ioctlが適切にスペースを予約し、トランザクションの中断を防止します。

Linuxカーネルにおいて、comediの低レベルドライバにアタッチする際にdev-spinlockが再初期化される脆弱性が修正されました。struct comedi_deviceはCOMEDIデバイスを管理しており、そのspinlockは低レベルドライバによって共有されています。異なるドライバがアタッチされる際にspinlockのロックレベルの不一致が原因で不整合なロック状態が発生する可能性がありました。これを防ぐため、CONFIG_LOCKDEP設定が有効な場合にはattach関数の呼び出し前にspinlockが再初期化されるように修正されました。

Linuxカーネルにおいて、以下の脆弱性が解決されました。ice: ptp: 制御PFが利用できない場合にWARNを発生させないようにしました。VFIOパススルー設定では、ソースタイマーを所有しないPFのみをパススルーすることが可能です。その場合、PTP制御PF（adapter-ctrl_pf）はVM内で初期化されず、ice_get_ctrl_ptp()はNULLを返します。そして、ice_ptp_setup_pf()でWARN_ON()が発生しますが、この構成では想定された動作であるため、WARN_ON()を情報メッセージに置き換え、-EOPNOTSUPPを返すようにしました。

Linuxカーネルにおいて、以下の脆弱性が修正されました。mshv_vtlでのMAX_FOLIO_ORDERを超えるvmemmap_shiftの問題です。MSHV_ADD_VTL0_MEMORYを介してVTL0メモリを登録する際、カーネルはstart_pfnとlast_pfnのORの末尾のゼロの数をpgmap-vmemmap_shiftとして計算し、両端点が整列している最大の複合ページオーダーを使用しようとしていました。しかし、この値はMAX_FOLIO_ORDERで制限されていなかったため、十分に整列された範囲（例えば物理範囲[0x800000000000, 0x800080000000)で、start_pfn=0x800000000が35の末尾ゼロに対応）がmemremap_pages()が許容する値を超えるシフトを生じさせ、WARNを引き起こし-EINVALを返していました。警告例として、"WARNING: ... memremap_pages+0x512/0x650 requested folio size unsupported"があります。MAX_FOLIO_ORDERのチェックはcommit 646b67d57589（"mm/memremap: reject unreasonable folio/compound page sizes in memremap_pages()"）で追加されました。今回の修正では、vmemmap_shiftをMAX_FOLIO_ORDERに制限し、カーネルがサポートする最大のオーダーのみを常に要求するようにして、範囲外の値の発生を回避しています。また、エラー処理パスも修正し、devm_memremap_pages()からの実際のエラーコードを伝搬させ、真の-EINVAL戻り値を隠していた-EFAULTをハードコードする問題を解決しました。

Linuxカーネルにおいて、以下の脆弱性が修正されました。f2fsにおけるf2fs_sanity_check_node_footer関数内で初期化されていない値にアクセスする問題を回避するための修正です。syzbotにより、次のf2fsのバグが報告されました。BUG: KMSAN: uninit-value in f2fs_sanity_check_node_footer+0x374/0xa20 fs/f2fs/node.c:1520 などです。根本原因は、f2fs_finish_read_bio()関数内でデバイスからfolioへデータの読み込みに失敗した場合に、初期化されていないデータにアクセスしてしまう可能性がある点にあります。この問題を回避するためにチェック条件を追加しました。

Linuxカーネルでは、以下の脆弱性が修正されました。KVMのarm64において、vgic作成時にvgicのdistおよびredistを積極的に初期化します。vgic_allocate_private_irqs_locked()が何らかの理由で失敗した場合、kvm_vgic_create()が早期に終了し、dist-rd_regionsが初期化されない状態になります。その結果、kvm_vgic_dist_destroy()がRDの解放を試みた際に問題が発生します。この問題を解決するために、すべての静的初期化を早期に移動し、途中で失敗しても残りのクリーンアップが適切に実行できるようにしました。さらに、失敗時には念のためvgicモデルのリセットも行います。

Linuxカーネルにおいて、次の脆弱性が修正されました：iio: proximity: hx9023sにおけるset_samp_freq関数でのゼロ除算が防止されました。指定されていないサンプリング周波数によるゼロ除算を回避しています。

Linuxカーネルにおいて、以下の脆弱性が修正されました。iio: light: bh1780におけるエラーパスでのPMランタイムリークを修正しました。pm_runtime_put_autosuspend()をエラーチェックの前に移動し、読み取り操作が成功しても失敗しても、pm_runtime_get_sync()の後で常にPMランタイムの参照カウントが減少するようにしました。

Linuxカーネルにおいて、以下の脆弱性が修正されました。iio: imu: adis: adis_initにおけるNULLポインタ参照の問題を修正しました。adis_init()関数はadis-opsを参照して、個別の関数ポインタ（write、read、reset）がNULLかどうかをチェックしますが、最初にadis-ops自体がNULLであるかどうかをチェックしていませんでした。adis16480、adis16490、adis16545などのドライバはカスタムopsを設定せず、adis_init()がデフォルトを割り当てることに依存しています。struct adisはdevm_iio_device_alloc()によってゼロ初期化されるため、adis_init()呼び出し時にadis-opsはNULLとなり、NULLポインタ参照が発生しました。具体的には、以下のようなエラーが発生しました。カーネルのNULLポインタ参照を仮想アドレス0000000000000000で処理できません。pc : adis_init+0xc0/0x118。コールトレースは以下の通りです。adis_init+0xc0/0x118、adis16480_probe+0xe0/0x670。この問題は、adis-opsを参照する前にNULLかどうかをチェックし、その場合はデフォルトのopsを割り当てることで修正されました。

Linuxカーネルにおいて、pm_runtimeのエラー処理に関する脆弱性が修正されました。この脆弱性により、ドライバーがハードウェアアクセスに失敗しても適切にエラーを処理できず、使用カウントが誤って増加してしまう問題がありました。pm_runtime_resume_and_get()の使用によりエラー伝播が改善され、set_8khz_samplerate()の失敗時にはpm_runtime_put_autosuspend()が適切に呼び出されるようになりました。

Linuxカーネルにおいて、以下の脆弱性が修正されました。btrfsのtry_release_subpage_extent_buffer()関数のエラーパスで不足していたRCUのアンロック処理を追加しました。try_release_subpage_extent_buffer()のループを抜ける前にrcu_read_lock()を呼び出す必要があります。なぜなら、ループの後にrcu_read_unlock()を呼び出すためです。この問題はClangのスレッドセーフティアナライザーによって検出されました。

Linuxカーネルにおいて、以下の脆弱性が修正されました：btrfsのset received ioctlにおけるアイテムオーバーフローによるトランザクション中断の問題です。BTRFS_UUID_KEY_RECEIVED_SUBVOLを追加しようとした際にアイテムオーバーフローでset received ioctlが失敗すると、以前にメタデータの更新が行われているためトランザクションを中断する必要がありました。これにより、ユーザーが多数のサブボリュームに対して同じ受信UUIDフィールドを使ってこのioctlを呼び出すと、オーバーフローが発生しトランザクションが中断され、ファイルシステムは読み取り専用モードになります。悪意のあるユーザーはこれを悪用でき、このioctlは管理者権限（CAP_SYS_ADMIN）を必要とせず、サブボリュームの所有権さえあれば実行可能です。この問題は、トランザクション開始前に早期にアイテムオーバーフローを確認することで修正されました。subvol_semセマフォを排他（書き込み）モードで保持しているため、競合状態も防止しています。fstests用のテストケースは近日中に提供予定です。

Linuxカーネルにおいて、以下の脆弱性が修正されました。btrfsでは、名前のハッシュ衝突に起因するファイル作成時のトランザクション中断の問題を修正しました。複数のファイル名が同じハッシュになる場合、それらを同じディレクトリアイテムにパックする必要があり、この処理にはリーフサイズに固有の制限があります。しかし、その制限に達するとトランザクションが中断され、ファイルシステムが読み取り専用(RO)モードに切り替わります。これにより、管理者権限や特権を持たない悪意のあるユーザーがシステムを妨害できる可能性があります。再現コードの例では、最小ノードサイズを指定して高速にテストを行い、ハッシュ衝突を引き起こす複数のファイル名を作成しています。

Linuxカーネルにおいて、以下の脆弱性が修正されました。btrfsに関して、受信されたサブボリュームをスナップショット作成時のトランザクション中断の問題を修正しました。現在、ユーザーは以前に受信したスナップショットを複数回スナップショット作成することで、BTRFS_UUID_KEY_RECEIVED_SUBVOLアイテムのオーバーフロー（リーフに格納可能な最大アイテムサイズ）に達するまでトランザクションを中断させることが可能です。これは実際にはあまり一般的ではないと思われますが、発生した場合、ファイルシステムは読み取り専用（RO）モードになります。snapshot、send、set_received_subvolおよびsubvol_setflags（receiveで使用）はCAP_SYS_ADMINを必要とせず、inode_owner_or_capable()のみで実行可能です。そのため、悪意あるユーザーがこの脆弱性を利用してファイルシステムをROモードにし、システムに障害を引き起こす可能性があります。再現スクリプトの例は以下の通りです。#!/bin/bash DEV=/dev/sdi MNT=/mnt/sdi # テストを高速化するため最小のノードサイズを使用。 mkfs.btrfs -f --nodesize 4K $DEV mount $DEV $MNT # サブボリュームを作成し、sendのためにROに設定。 btrfs subvolume create $MNT/sv touch $MNT/sv/foo btrfs property set $MNT/sv ro true # サブボリュームをsnaps/svにsendとreceive。 mkdir $MNT/snaps btrfs send $MNT/sv | btrfs receive $MNT/snaps # 受信UUIDを持つ受信されたサブボリュームを多数回スナップショットし、リーフのオーバーフローをトリガー。 total=500 for ((i = 1; i = $total; i++)); do echo -ne "\rCreating snapshot $i/$total" btrfs subvolume snapshot -r $MNT/snaps/sv $MNT/snaps/sv_$i /dev/null done umount $MNT テスト実行時の出力例: ./test.sh (...)/mnt/sdi/svを作成 サブボリュームの422番目のスナップショット作成時にエラー: "値が定義されたデータ型に対して大きすぎます" スナップショット作成時にROファイルシステムエラーが発生し、ファイルシステムが読み取り専用モードに移行したことが確認されました。 dmesg/syslogには以下の警告が表示されます。 [251067.627338] BTRFS警告（デバイスsdi）: uuidアイテム挿入失敗 -75 (0x4628b21c4ac8d898, 0x2598bee2b1515c91) タイプ252! [251067.630033] BTRFS: トランザクション中断(エラー -75) [251067.630871] 警告: fs/btrfs/transaction.c:1907 at create_pending_snapshot.cold+0x52/0x465 [btrfs], CPU#10: btrfs/615235 以下省略。 この問題により、権限のないユーザーがbtrfsファイルシステムを読み取り専用モードに移行させ、システムの可用性に影響を与える可能性がありましたが、それを修正しました。

Linuxカーネルにおいて、x86/apicのs2ramからのリジューム時にファームウェアがx2apicモードを再度有効化する場合があり、カーネルがこれを想定して無効化していたため不整合が発生していました。この問題によりシステムがハングすることがありました。修正では、リジューム処理時にカーネルがx2apicを無効と判断した場合に確実に無効化するよう改善されています。ACPI仕様書に基づくと、ファームウェアはCPUの初期起動設定またはスリープ前設定を復元するため、この動作は仕様内に含まれています。したがって、今回の修正はこの不整合によるハングを防止し、適切にx2apicの状態を管理することでシステムの安定性を向上させます。

Linuxカーネルにおいて、以下の脆弱性が修正されました。ublk_ctrl_set_size()関数に存在したNULLポインタ参照の問題です。ublk_ctrl_set_size()は、ub-ub_diskがNULLかどうかを確認せずにset_capacity_and_notify()経由で無条件に参照していました。ub-ub_diskは、UBLK_CMD_START_DEVが完了する前（ublk_ctrl_start_dev()内でのみ割り当てられます）およびUBLK_CMD_STOP_DEVが実行された後（ublk_detach_disk()がNULLに設定します）にはNULLになります。UBLK_CMD_UPDATE_SIZEハンドラは状態検証を行わないため、ユーザーは追加されたがまだ開始されていないデバイス、もしくは停止されたデバイスにUPDATE_SIZEを送信することでNULLポインタ参照を引き起こす可能性がありました。対策として、参照前にub-mutexの下でub-ub_diskをチェックし、ディスクが利用できない場合は-ENODEVを返すように修正しました。

Linuxカーネルにおいて、drm/amdのデバイスのクリーンアップ時にNULLポインタデリファレンスが発生する複数の脆弱性が修正されました。サポートされていないハードウェアでNULLのバージョンポインタによりクリーンアップが失敗する経路が特定され、そのため適切なNULLチェックが追加されました。

Linuxカーネルのdrm/amdにおいて、デバイスのクリーンアップ時にNULLポインタ参照が発生する脆弱性が修正されました。GPUの初期化に失敗した場合、IPブロックがNULLのバージョンポインタを持つことがあり、クリーンアップ中にバージョンポインタへのNULLチェックが行われなかったため、クラッシュが発生していました。この問題を防ぐために、クリーンアップ処理でNULLチェックを追加しました。

Linuxカーネルにおいて、送信の有効化前にtxリングをシャッフルするmacbドライバの問題が修正されました。この問題は、送信バッファキューのポインタが正しくリセットされず、送信中のパケットが失われたりメモリリークが発生したり、送信がスタックした原因となっていました。この脆弱性により、AMD ZynqMpボードでNFS rootfsを使用した際の復帰時間が異常に長くなっていました。修正では、未送信パケットの再配置と適切なロックによる保護が行われています。

Linuxカーネルにおいて、以下の脆弱性が修正されました: net: dsa: microchip: PTP IRQセットアップにおけるエラーパスの修正です。request_threaded_irq()がPTPメッセージIRQセットアップ中に失敗した場合に、新たに作成されたIRQマッピングが破棄されませんでした。実際には、ksz_ptp_irq_setup()のエラーパスは正常にセットアップされたマッピングのみを解放していました。request_threaded_irq()のセットアップが失敗した場合に、新たに作成されたマッピングを破棄するように修正しました。

Linuxカーネルにおいて、net:mctpドライバーでプローブが失敗した際にUSBデバイスの参照が解放されない脆弱性が修正されました。この問題により、メモリリークのリスクが軽減されます。

OPNsenseはFreeBSDベースのファイアウォールおよびルーティングプラットフォームです。26.1.7より前のバージョンには、OPNsenseのlockout_handlerに論理的な欠陥があり、認証されていない攻撃者が自分のIPアドレスの認証失敗カウンターを継続的にリセットできました。攻撃者は、成功キーワード（"Accepted"または"Successful login"）を含む特殊に作成されたユーザー名を通常のブルートフォース試行の間に挿入することで、失敗カウンターがロックアウトのしきい値に達するのを防げます。この脆弱性は26.1.7で修正されました。

Fortinet FortiClientのWindows版7.4.0から7.4.2まで、およびWindows版7.2の全バージョンにおいて、ハードコーディングされた暗号鍵の使用に脆弱性があります。この脆弱性により、攻撃者はinsert attack vector hereを介して情報漏洩を引き起こす可能性があります。

Fortinet FortiTokenAndroid 6.2全バージョン、FortiTokenAndroid 6.1全バージョン、およびFortiTokenAndroid 5.2全バージョンにおいて、Androidアプリケーションコンポーネントが不適切にエクスポートされている脆弱性があります。この脆弱性により、攻撃者がinsert attack vector hereを介して不適切なアクセス制御を行う可能性があります。

etcdは分散システムのデータを管理する分散型キーバリューストアです。バージョン3.4.44、3.5.30、および3.6.11より前のetcdには、取引操作内のPutリクエストでのPrevKvを介した読み取りアクセスやリースの添付によってRBAC認可チェックを回避できる脆弱性があります。十分な読み取り権限またはリース関連権限を持たない認証ユーザーが、これらの機能を有効にした取引操作を呼び出すことで、許可されていないデータにアクセスしたりリースを添付したりする可能性があります。この脆弱性はバージョン3.4.44、3.5.30、および3.6.11で修正されています。

MISPはオープンソースの脅威インテリジェンスおよび共有プラットフォームです。2.5.37以前のバージョンでは、MISP Collectionsはuuidフィールドに対してRFC 4122 UUIDの検証を強制していませんでした。そのため、Collectionレコードを作成または変更できるユーザーは、不正な形式のUUID値を送信できました。これにより、Collection UUIDが有効な識別子であると仮定しているコードパスで整合性の問題や予期しない動作が発生する可能性がありました。この脆弱性は2.5.37で修正されています。