検出

Ubuntu 20.04 LTS / 22.04 LTS : Linux カーネル (AWS) の脆弱性 (USN-6766-3)

high Nessus プラグイン ID 197517

Language:

概要

リモート Ubuntu ホストに 1 つ以上のセキュリティ更新がありません。

説明

リモートの Ubuntu 20.04 LTS / 22.04 LTS ホストには、USN-6766-3 のアドバイザリに記載された複数の脆弱性の影響を受けるパッケージがインストールされています。

 - Linux カーネルでは、次の脆弱性が解決されています。net: skb_segment() で mss オーバーフローを防止します。またも、syzbot は skb_segment() でカーネルをクラッシュさせることができます [1] GSO_BY_FRAGS は禁止値ですが、残念ながら skb_segment() の次の計算が非常に簡単に到達できます。
 mss = mss * partial_segs; 65535 = 3 * 5 * 17 * 257 となり、mss の初期値が非常に多いと、不良な最終結果になる可能性があります。新しい mss 値が GSO_BY_FRAGS よりも小さくなるように、セグメンテーションを必ず制限してください。[1] 一般保護違反、おそらく非標準アドレス 0xdffffc000000000e: 0000 [#1] PREEMPT SMP KASAN KASAN: 範囲 [0x0000000000000070-0x0000000000000077] CPU の null-ptr-deref 1 PID: 5079 Comm: syz-executor993 汚染されていない 6.7.0-rc4-syzkaller-00141-g1ae4cd3cbdd0 #0 ハードウェア名: Google Google Compute Engine/Google Compute Engine、BIOS Google 11/10/2023 RIP: 0010:skb_segment+0x181d/0x3f30 net/core/skbuff.c:4551 Code: 83 e3 02 e9 fb ed ff ff e8 90 68 1c f9 48 8b 84 24 f8 00 00 00 48 8d 78 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 8a 21 00 00 48 8b 84 24 f8 00 RSP: 0018:ffffc900043473d0 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000010046 RCX:
 ffffffff886b1597 RDX: 000000000000000e RSI: ffffffff886b2520 RDI: 0000000000000070 RBP: ffffc90004347578 R08: 0000000000000005 R09: 000000000000ffff R10: 000000000000ffff R11: 0000000000000002 R12:
 ffff888063202ac0 R13: 0000000000010000 R14: 000000000000ffff R15: 0000000000000046 FS:
 0000555556e7e380(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0:
 0000000080050033 CR2: 0000000020010000 CR3: 0000000027ee2000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
 0000000000000400 呼び出しトレース: <TASK> udp6_ufo_fragment+0xa0e/0xd00 net/ipv6/udp_offload.c:109 ipv6_gso_segment+0x534/0x17e0 net/ipv6/ip6_offload.c:120 skb_mac_gso_segment+0x290/0x610 net/core/gso.c:53
 __skb_gso_segment+0x339/0x710 net/core/gso.c:124 skb_gso_segment include/net/gso.h:83 [inline] validate_xmit_skb+0x36c/0xeb0 net/core/dev.c:3626 __dev_queue_xmit+0x6f3/0x3d60 net/core/dev.c:4338 dev_queue_xmit include/linux/netdevice.h:3134 [inline] packet_xmit+0x257/0x380 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3087 [inline] packet_sendmsg+0x24c6/0x5220 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0xd5/0x180 net/socket.c:745
 __sys_sendto+0x255/0x340 net/socket.c:2190 __do_sys_sendto net/socket.c:2202 [inline] __se_sys_sendto net/socket.c:2198 [inline] __x64_sys_sendto+0xe0/0x1b0 net/socket.c:2198 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b RIP: 0033:0x7f8692032aa9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 d1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff8d685418 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f8692032aa9 RDX:
 0000000000010048 RSI: 00000000200000c0 RDI: 0000000000000003 RBP: 00000000000f4240 R08: 0000000020000540 R09: 0000000000000014 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff8d685480 R13:
 0000000000000001 R14: 00007fff8d685480 R15: 0000000000000003 </TASK> リンクされたモジュール: ---[ end trace 0000000000000000 ]--- RIP: 0010:skb_segment+0x181d/0x3f30 net/core/skbuff.c:4551 Code: 83 e3 02 e9 fb ed ff ff e8 90 68 1c f9 48 8b 84 24 f8 00 00 00 48 8d 78 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 8a 21 00 00 48 8b 84 24 f8 00 RSP: 0018:ffffc900043473d0 EFLAGS:
 00010202 RAX: dffffc0000000000 RBX: 0000000000010046 RCX: ffffffff886b1597 RDX: 000000000000000e RSI:
 ffffffff886b2520 RDI: 0000000000000070 RBP: ffffc90004347578 R0 ---truncated--- (CVE-2023-52435)

 - Linux カーネルで、次の脆弱性は解決されています。drm: デッドロック処理のために、誤って同じ fb を何度も参照解除しません drm_mode_page_flip_ioctl() の fb 検索後にデッドロックを取得した場合、fb の参照解除を行った後に、最初から全体を再試行します。しかし、fb ポインターを NULL にリセットするのを忘れているため、再試行中に fb 検索の前に別のエラーが発生した場合は、別の参照を取得することなく、同じ fb の参照解除を再度続行します。最終的な結果として、fb は (最終的に) 使用中の段階で解放されてしまいます。fb を解除したら、fb を NULL にリセットします。これにより、別の fb 検索を実行するまで再設定が行われなくなります。これは、非同期フリップ (および CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y) を実行するときに、DG2 に非常に簡単にヒットすることがわかりました。最初に見た症状は、drm_closefb() が、フレームバッファリストをたどっている間に、ビジーループに単純にスタックすることでした。幸いなことに、代わりに oops を実行させることができ、そこから簡単に culprit を特定できました。
 (CVE-2023-52486)

 - Linux カーネルでは、次の脆弱性が解決されています。mm/sparsemem: memory_section->usage へのアクセス競合を修正します。以下の競合は、PFN が [ZONE_NORMAL ZONE_DEVICE ZONE_NORMAL] である場合に、実行するシステムメモリ設定のデバイスメモリ領域に該当する PFN で観察されます。通常のゾーンの開始および終了 pfn にはデバイスメモリ PFN も含まれているため、トリガーされたコンパクションはデバイスメモリ PFN でも試行しますが、これらは NOP になります (pfn_to_online_page() が ZONE_DEVICE メモリセクションに対して NULL を返すため)。問題の PFN が属する ZONE_DEVICE 領域のセクションマッピングが他のコアから削除される場合、コンパクションが現在操作されているため、CONFIG_SPASEMEM_VMEMAP が有効な状態でカーネルクラッシュを引き起こします。クラッシュログは [1] で確認できます。
 compact_zone() memunmap_pages ------------- --------------- __pageblock_pfn_to_page ...... (a)pfn_valid():
 valid_section()//return true (b)__remove_pages()-> sparse_remove_section()->section_deactivate(): [ms->usage 配列を解放し、ms->usage = NULL を設定] pfn_section_valid() [Access ms->usage これは NULL です] 注意:
以上のことから、競合は pfn_valid()/pfn_section_valid() の間に縮小され、SPASEMEM_VMEMAP を有効にしてセクションが無効化されたと言えます。コミット b943f045a9af (mm/sparse: pfn_section_valid チェックでカーネルクラッシュを修正) は、valid_section() が false を返すことを期待して SECTION_HAS_MEM_MAP をクリアすることで、同じ問題に対処しようとしました。このため、ms->usage はアクセスされません。以下の手順でこの問題を修正します。a) ->usage を解放する前に、SECTION_HAS_MEM_MAP を消去します。b) RCU で保護された読み取り側のクリティカルセクションは、SECTION_HAS_MEM_MAP がクリアされる際に NULL を返すか、アクセス ->usage に成功します。c) kfree_rcu() で ->usage を解放し、ms->usage = NULL を設定します。SECTION_HAS_MEM_MAP がクリアされ、valid_section() は false を返すため、これ以降は、access ->usage にアクセスする試みは行われません。このパッチに情報を提供してくれた David/Pavan 氏に感謝します。[1] https://lore.kernel.org/linux-mm/[email protected]/ 前述の PFN のメモリ設定を [ZONE_NORMAL ZONE_DEVICE ZONE_NORMAL] とする Snapdragon SoC では、デバイスファームでのテスト中に、毎日多数の問題を確認することができます。この特定の問題については、以下にログがあります。以下のログは pfn_section_valid(){ ms->usage;} を直接指し示していませんが、このダンプを T32 lauterbach ツールに読み込んだときには、それを指し示しています。[ 540.578056] 仮想アドレス 0000000000000000 のカーネル NULL ポインターデリファレンスを処理できません [ 540.578068] メモリ中止情報: [ 540.578070] ESR = 0x0000000096000005 [ 540.578073] EC = 0x25: DABT (現在の EL)、IL = 32 ビット [ 540.578077] SET = 0、FnV = 0 [ 540.578080] EA = 0、S1PTW = 0 [540.578082] FSC = 0x05: レベル 1 変換障害 [ 540.578085] データ中止情報: [ 540.578086] ISV = 0、ISS = 0x00000005 [ 540.578088] CM = 0、WnR = 0 [ 540.579431] pstate: 82400005 (Nzcv daif +PAN -UAO +TCO
 -DIT -SSBSBTYPE=--) [ 540.579436] pc : __pageblock_pfn_to_page+0x6c/0x14c [ 540.579454] lr :
 compact_zone+0x994/0x1058 [ 540.579460] sp : ffffffc03579b510 [ 540.579463] x29: ffffffc03579b510 x28:
 0000000000235800 x27:000000000000000c [ 540.579470] x26: 0000000000235c00 x25: 0000000000000068 x24:ffffffc03579b640 [ 540.579477] x23: 0000000000000001 x22: ffffffc03579b660 x21:0000000000000000 [540.579483] x20: 0000000000235bff x19: ffffffdebf7e3940 x18:ffffffdebf66d140 [ 540.579489] x17:
 00000000739ba063 x16: 00000000739ba063 x15:00000000009f4bff [ 540.579495] x14: 0000008000000000 x13:
 0000000000000000 x12:0000000000000001 [ 540.579501] x11: 0000000000000000 x10: 0000000000000000 x9 :ffffff897d2cd440 [ 540.579507] x8 : 0000000000000000 x7 : 0000000000000000 x6 :ffffffc03579b5b4 [540.579512] x5 : 0000000000027f25 x4 : ffffffc03579b5b8 x3 :0000000000000 ---truncated--- (CVE-2023-52489)

 - Linux カーネルで、次の脆弱性が解決されています。media: mtk-jpeg: mtk_jpeg_dec_device_run でのエラーパス処理によるメモリ解放後使用 (Use After Free) のバグを修正 mtk_jpeg_probe で、&jpeg->job_timeout_work が mtk_jpeg_job_timeout_work にバインドされます。mtk_jpeg_dec_device_run で、mtk_jpeg_set_dec_dst でエラーが発生した場合、v4l2_m2m_job_finish を呼び出すことでジョブを終了済みとしてマークしながら、最終的にワーカーを開始します。このバグを発生させる方法は 2 つあります。モジュールを削除した場合、mtk_jpeg_remove を呼び出してクリーンアップを実行します。考えられるシーケンスは次のとおりで、メモリ解放後使用 (Use After Free) バグを引き起こします。CPU0 CPU1 mtk_jpeg_dec_... | ワーカーを開始する | |mtk_jpeg_job_timeout_work mtk_jpeg_remove | v4l2_m2m_release | kfree(m2m_dev); | | | v4l2_m2m_get_curr_priv | m2m_dev->curr_ctx //use mtk_jpeg_release を呼び出すファイル記述子を閉じると、同様のシーケンスになります。jpegdec ワーカーが正常に起動した場合にのみタイムアウトワーカーを起動することで、このバグを修正します。その後、v4l2_m2m_job_finish は mtk_jpeg_job_timeout_work または mtk_jpeg_dec_device_run のいずれかでのみ呼び出されます。(CVE-2023-52491)

 - Linux カーネルで、次の脆弱性が解決されました。dmaengine: チャネル登録解除における NULL ポインターを修正します。関数 __dma_async_device_channel_register() が失敗する可能性があります。失敗した場合、chan->local は解放され (free_percpu() を使用)、chan->local は無効化されます。dma_async_device_unregister() が呼び出されると (マネージ API のため、または DMA コントローラードライバーにより意図的に)、チャネルは無条件に登録解除され、この NULL ポインターが発生します。[ 1.318693] 仮想アドレス 00000000000000d0 でカーネル NULL ポインターデリファレンスを処理できません [...] [ 1.484499] 呼び出しトレース: [ 1.486930] device_del+0x40/0x394 [1.490314] device_unregister+0x20/0x7c [ 1.494220] __dma_async_device_channel_unregister+0x68/0xc0 dma_async_device_register() 関数エラーパスを確認します。chan->local が NULL でない場合にのみ、チャネルデバイス登録解除が行われます。次に、__dma_async_device_channel_unregister() 関数の最初に同じ条件を追加し、この関数に到達するために使用した API が何であれ、NULL ポインターの問題を回避します。(CVE-2023-52492)

 - Linux カーネルでは、以下の脆弱性は解決されています。bus: mhi: host: バッファをキューに入れる前に chan ロックをドロップします。parse_xfer_event() から読み取りロックをドロップすることで、チャネルの読み取りおよび書き込みロックが連続して発生しないようにします。これにより、クライアントに与えられたコールバックは、バッファをキューに入れ、そのプロセスで書き込みロックを取得する可能性があります。バッファのキューイングは、複数のロックとソフトロックアップを引き起こす可能性があるため、チャネル読み取りロックを取得せずに実行する必要があります。[mani: 修正のタグを追加し、安定版 (stable) を CC に入れて送信] (CVE-2023-52493)

 - Linux カーネルにおいて、次の脆弱性は解決されています。bus: mhi: host: イベントリング読み取りポインターのアライメントチェックを追加します。is_valid_ring_ptr でイベントリング読み取りポインターをチェックし、バッファ範囲内にあることを確認します。しかし、ポインターが整列されていない可能性がある別のリスクがあります。イベントリング要素は 128 ビット (mhi_ring_element 構造体) 調整されていると予想されるため、調整されていない読み取りポインターは DoS やリングバッファメモリ破損などの複数の問題を引き起こす可能性があります。そのため、イベントリング読み取りポインターのアライメントチェックを追加します。(CVE-2023-52494)

 - Linux カーネルでは、以下の脆弱性が解決されています。PM: sleep: コアシステム全体の PM コードの潜在的なデッドロックを修正します。低メモリの状況では、async_schedule_dev() が実行されるため、システム全体がコアコードのデッドロックを再開すると報告されています。メモリを割り当てられない場合 (この場合だけでなく)、およびその関数がすでに保持されている mutex を取得しようとする場合、引数は同期的に機能します。
 dpm_async_fn() 内から引数関数を同期的に実行することは、順序の理由で問題となる場合があります (たとえば、必要なサプライヤデバイスのレジュームコールバックよりも前に、コンシューマデバイスのレジュームコールバックが呼び出される可能性があります)。デバイスの中断および再開関数の非同期実行をスケジュールするために async_schedule_dev_nocall() を使用し、async_schedule_dev_nocall() が false を返す場合はそれらを同期的に直接実行するように、問題のコードを変更することでこれに対処します。
 (CVE-2023-52498)

 - Linux カーネルでは、次の脆弱性が解決されています。ceph: dget() の誤用によるデッドロックまたはデッドコードを修正します denty とその親の間のロック順序が正しくありません。親が最初にロックを取得することを常に確認する必要があります。しかし、このデッドコードは使用されることはなく、親ディレクトリは常に呼び出し元から設定されるため、削除してしまいましょう。(CVE-2023-52583))

 - Linux カーネルで、次の脆弱性が解決されています。IB/ipoib: mcast リストロッキングを修正します 「ipoib_mcast_join_task()」で「priv->multicast_list」を反復する際に「priv->lock」をリリースすると、「ipoib_mcast_dev_flush」のウィンドウが開いて、反復の途中でアイテムを削除します。ロックが解除されている間に mcast が削除された場合、for ループが永久にスピンし、ハードロックアップが発生します (RHEL 4.18.0-372.75.1.el8_6 カーネルで報告されています)。タスク A (kworker/u72:2 below) | タスク B (kworker/u72:0 below)
 -----------------------------------+----------------------------------- ipoib_mcast_join_task(work) | ipoib_ib_dev_flush_light(work) spin_lock_irq(&priv->lock) | __ipoib_ib_dev_flush(priv, ...) list_for_each_entry(mcast, | ipoib_mcast_dev_flush(dev = priv->dev) &priv->multicast_list, list) | ipoib_mcast_join(dev, mcast) | spin_unlock_irq(&priv->lock) | | spin_lock_irqsave(&priv->lock, flags) | list_for_each_entry_safe(mcast, tmcast, | &priv->multicast_list, list) | list_del(&mcast->list); | list_add_tail(&mcast->list, &remove_list) | spin_unlock_irqrestore(&priv->lock, flags) spin_lock_irq(&priv->lock) | | ipoib_mcast_remove_list(&remove_list) (Here, `mcast` is no longer on the | list_for_each_entry_safe(mcast, tmcast, `priv->multicast_list` and we keep | remove_list, list) spinning on the `remove_list` of | >>> wait_for_completion(&mcast->done) the other thread which is blocked | and the list is still valid on | it's stack.) ロックを保持したままにし、最終的なスリープを回避するために GFP_ATOMIC に変更することで、これを修正します。残念ながら、ロックアップを再現し、この修正を確認することはできませんでしたが、コードレビューに基づいて、この修正でこのようなロックアップに対処する必要があると思います。crash> bc 31 PID: 747 TASK: ff1c6a1a007e8000 CPU: 31 COMMAND: kworker/u72:2 -- [exception RIP: ipoib_mcast_join_task+0x1b1] RIP: ffffffffc0944ac1 RSP: ff646f199a8c7e00 RFLAGS: 00000002 RAX: 0000000000000000 RBX: ff1c6a1a04dc82f8 RCX: 0000000000000000 work (&priv->mcast_task{,.work}) RDX: ff1c6a192d60ac68 RSI: 0000000000000286 RDI: ff1c6a1a04dc8000 &mcast->list RBP: ff646f199a8c7e90 R8: ff1c699980019420 R9: ff1c6a1920c9a000 R10: ff646f199a8c7e00 R11:
 ff1c6a191a7d9800 R12: ff1c6a192d60ac00 mcast R13: ff1c6a1d82200000 R14: ff1c6a1a04dc8000 R15:
 ff1c6a1a04dc82d8 dev priv (&priv->lock) &priv->multicast_list (aka head) ORIG_RAX: ffffffffffffffff CS:
 0010 SS: 0018 --- <NMI exception stack> --- #5 [ff646f199a8c7e00] ipoib_mcast_join_task+0x1b1 at ffffffffc0944ac1 [ib_ipoib] #6 [ff646f199a8c7e98] process_one_work+0x1a7 at ffffffff9bf10967 crash> rx ff646f199a8c7e68 ff646f199a8c7e68: ff1c6a1a04dc82f8 <<< work = &priv->mcast_task.work crash> list -hO ipoib_dev_priv.multicast_list ff1c6a1a04dc8000 (empty) crash> ipoib_dev_priv.mcast_task.work.func,mcast_mutex.owner.counter ff1c6a1a04dc8000 mcast_task.work.func = 0xffffffffc0944910 <ipoib_mcast_join_task>, mcast_mutex.owner.counter = 0xff1c69998efec000 crash> b 8 PID:
 8 TASK: ff1c69998efec000 CPU: 33 COMMAND: kworker/u72:0 -- #3 [ff646f1980153d50] wait_for_completion+0x96 at ffffffff9c7d7646 #4 [ff646f1980153d90] ipoib_mcast_remove_list+0x56 at ffffffffc0944dc6 [ib_ipoib] #5 [ff646f1980153de8] ipoib_mcast_dev_flush+0x1a7 at ffffffffc09455a7 [ib_ipoib] #6 [ff646f1980153e58] __ipoib_ib_dev_flush+0x1a4 at ffffffffc09431a4 [ib_ipoib] #7 [ff
 ---truncated--- (CVE-2023-52587)

 - Linux カーネルでは、次の脆弱性が解決されています。f2fs: ブロック移行中にページの gcing フラグにタグ付けするのを修正します。移行されたデータがチェックポイント中に保持されることを保証するために、ブロック移行中に欠落している gcing フラグをページに追加する必要があります。さもないと、データとノード間の異常な永続性により、SPOR 後にデータ破損が発生する可能性があります。同様の問題が、コミット 2d1fe8a86bf5 で修正されました (f2fs: ファイルデフラグ中のページの gcing フラグのタグ付けを修正)。(CVE-2023-52588)

 - Linux カーネルでは、次の脆弱性が解決されています。wifi: ath9k: ath9k_htc_txstatus() の array-index-out-of-bounds 読み取りの可能性を修正します ath9k_htc_txstatus() の array-index-out-of-bounds 読み取りを修正します。このバグは、USB デバイスによって提供される URB からのデータである txs->cnt が、HTC_MAX_TX_STATUS である txs->txstatus 配列のサイズよりも大きい場合に発生します。WARN_ON() はすでにチェックしていますが、チェック後のバグ処理コードはありません。その場合は、関数を戻します。syzkaller の修正バージョンによって見つかりました。UBSAN: htc_drv_txrx.c インデックス 13 内の array-index-out-of-bounds は、タイプ '__wmi_event_txstatus [12]' の範囲外です。呼び出しトレース: ath9k_htc_txstatus ath9k_wmi_event_tasklet tasklet_action_common __do_softirq irq_exit_rxu sysvec_apic_timer_interrupt (CVE-2023-52594)

 - Linux カーネルでは、次の脆弱性が解決されています。wifi: rt2x00: ハードウェアのリセット時に、ビーコンキューを再起動します。ハードウェアのリセットがトリガーされると、すべてのレジスターがリセットされるため、すべてのキューがハードウェアインターフェースで強制的に停止されます。ただし、mac80211 はキューを自動的に停止しません。ビーコンキューを手動で停止しないと、キューはデッドロック状態になり、再開できなくなります。このパッチは、ieee80211_restart_hw() を呼び出した後に Apple デバイスが AP に接続できない問題を修正します。
 (CVE-2023-52595)

 - Linux カーネルでは、次の脆弱性が解決されています。KVM: s390: fpc レジスターの設定を修正します kvm_arch_vcpu_ioctl_set_fpu() により、ゲスト cpu の浮動小数点コントロール (fpc) レジスターを設定できます。新しい値は、一時的に fpc レジスターにロードされることで、有効性がテストされます。これにより、ホストプロセスの fpc レジスターの破損が発生する可能性があります。値が fpc レジスターに一時的にロードされているときに割り込みが発生し、割り込みコンテキスト内で浮動小数点またはベクトルレジスターが使用されている場合、現在の fp/vx レジスターは save_fpu_regs() で保存され、それらがユーザー空間に属しており、ユーザー空間に戻るときに fp/vx レジスターにロードされると想定しています。test_fp_ctl() は、元のユーザー空間/ホストプロセスの fpc レジスター値を復元しますが、ユーザー空間に戻る際に破棄されます。その結果、ホストプロセスは、ゲスト cpu に使用されることになっている値で、間違って実行し続けます。
 テストを削除するだけでこれを修正できます。SIE コンテキストが入力される直前に、無効な値を処理する別のテストがあります。これにより、動作が変更されます。ioctl が -EINVAL で失敗するのではなく、無効な値が受け入れられます。このインターフェースが今後使用されない可能性が高いこと、さらに、これはメモリマップドインターフェースに実装された同じ動作であるため、これは許容可能であると思われます (無効な値をゼロに置換) - kvm-s390.c の sync_regs() を参照してください。(CVE-2023-52597)

 - Linux カーネルで、以下の脆弱性が解決されています。s390/ptrace: fpc レジスターの設定を適切に処理します。トレースされるプロセスの浮動小数点コントロール (fpc) レジスターの内容が ptrace インターフェースで変更されると、一時的に fpc レジスターにロードすることで、新しい値の妥当性がテストされます。これにより、トレースプロセスの fpc レジスターの破損が発生する可能性があります。値が fpc レジスターに一時的にロードされているときに割り込みが発生し、割り込みコンテキスト内で浮動小数点またはベクトルレジスターが使用されている場合、現在の fp/vx レジスターは save_fpu_regs() で保存され、それらがユーザー空間に属しており、ユーザー空間に戻るときに fp/vx レジスターにロードされると想定しています。
 test_fp_ctl() は、元のユーザー空間の fpc レジスター値を復元しますが、ユーザー空間に戻る際に破棄されます。その結果、トレーサーは、トレースされたプロセスに使用されることになっている値で、間違って実行し続けます。test_fp_ctl() を使用する前に save_fpu_regs() で fpu レジスターの内容を保存することで、これを修正します。(CVE-2023-52598)

 - Linux カーネルでは、次の脆弱性は解決されています。jfs: diNewExt 内の array-index-out-of-bounds を修正します [Syz レポート] UBSAN: fs/jfs/jfs_imap.c:2360:2 内の array-index-out-of-bounds インデックス -878706688 がタイプ「struct iagctl[128]」の範囲外です CPU: 1 PID: 5065 Comm: syz-executor282 汚染なし 6.7.0-rc4-syzkaller-00009-gbee0e7762ad2 #0 ハードウェア名: Google Google Compute Engine/Google Compute Engine、BIOS Google 11/10/2023 呼び出しトレース: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106 ubsan_epilogue lib/ubsan.c:217 [inline]
 __ubsan_handle_out_of_bounds+0x11c/0x150 lib/ubsan.c:348 diNewExt+0x3cf3/0x4000 fs/jfs/jfs_imap.c:2360 diAllocExt fs/jfs/jfs_imap.c:1949 [inline] diAllocAG+0xbe8/0x1e50 fs/jfs/jfs_imap.c:1666 diAlloc+0x1d3/0x1760 fs/jfs/jfs_imap.c:1587 ialloc+0x8f/0x900 fs/jfs/jfs_inode.c:56 jfs_mkdir+0x1c5/0xb90 fs/jfs/namei.c:225 vfs_mkdir+0x2f1/0x4b0 fs/namei.c:4106 do_mkdirat+0x264/0x3a0 fs/namei.c:4129
 __do_sys_mkdir fs/namei.c:4149 [inline] __se_sys_mkdir fs/namei.c:4147 [inline] __x64_sys_mkdir+0x6e/0x80 fs/namei.c:4147 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x45/0x110 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x63/0x6b RIP: 0033:0x7fcb7e6a0b57 Code: ff ff 77 07 31 c0 c3 0f 1f 40 00 48 c7 c2 b8 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 b8 53 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP:
 002b:00007ffd83023038 EFLAGS: 00000286 ORIG_RAX: 0000000000000053 RAX: ffffffffffffffda RBX:
 00000000ffffffff RCX: 00007fcb7e6a0b57 RDX: 00000000000a1020 RSI: 00000000000001ff RDI: 0000000020000140 RBP: 0000000020000140 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11:
 0000000000000286 R12: 00007ffd830230d0 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [分析] agstart が大きすぎる場合、agno のオーバーフローを引き起こす可能性があります。[修正] agno を取得した後、値が無効な場合は、後続のプロセスを終了します。カーネルテストロボット (Dan Carpenter) による linux-next レポートに基づいて、テストが agno > MAXAG から agno >= MAXAG に変更されました。(CVE-2023-52599)

 - Linux カーネルでは、次の脆弱性が解決されています。jfs: dbAdjTree の array-index-out-of-bounds を修正します。現在、dmt_stree にアクセスする際に、dbAdjTree にバインドチェックがありません。必要なチェックを追加するために、次のコミットで提案されているようにサイズを決定するために必要な bool is_ctl が追加されました。https://lore.kernel.org/linux-kernel-mentees/[email protected]/ (CVE-2023-52601)

 - Linux カーネルでは、次の脆弱性が解決されています。jfs: slab-out-of-bounds を修正します。dtSearch の読み取りの現在ページのソートされたエントリテーブルで現在のページを検索しているときに、領域外のアクセスがあります。エラーを修正するために境界チェックを追加しました。Dave: リターンコードを -EIO に設定 (CVE-2023-52602)

 - Linux カーネルでは、次の脆弱性は解決されています。FS:JFS:UBSAN: dbAdjTree 内の array-index-out-of-boundsin Syzkaller は次の問題を報告しました。UBSAN: 1 in fs/jfs/jfs_dmap.c:2867:6 内の array-index-out-of-bounds インデックス 196694 がタイプ「s8[1365]」( 別名「signed char[1365]」) の範囲外です CPU: 1 PID: 109 Comm: jfsCommit 汚染なし 6.6.0-rc3-syzkaller #0 ハードウェア名: Google Google Compute Engine/Google Compute Engine、BIOS Google 08/04/2023 呼び出しトレース: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106 ubsan_epilogue lib/ubsan.c:217 [inline]
__ubsan_handle_out_of_bounds+0x11c/0x150 lib/ubsan.c:348 dbAdjTree+0x474/0x4f0 fs/jfs/jfs_dmap.c:2867 dbJoin+0x210/0x2d0 fs/jfs/jfs_dmap.c:2834 dbFreeBits+0x4eb/0xda0 fs/jfs/jfs_dmap.c:2331 dbFreeDmap fs/jfs/jfs_dmap.c:2080 [inline] dbFree+0x343/0x650 fs/jfs/jfs_dmap.c:402 txFreeMap+0x798/0xd50 fs/jfs/jfs_txnmgr.c:2534 txUpdateMap+0x342/0x9e0 txLazyCommit fs/jfs/jfs_txnmgr.c:2664 [inline] jfs_lazycommit+0x47a/0xb70 fs/jfs/jfs_txnmgr.c:2732 kthread+0x2d3/0x370 kernel/kthread.c:388 ret_from_fork+0x48/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304 </TASK> ================================================================================ カーネルパニック - 同期していません: UBSAN: panic_on_warn set ... CPU: 1 PID: 109 Comm: jfsCommit Not tainted 6.6.0-rc3-syzkaller #0 ハードウェア名: Google Google Compute Engine/Google Compute Engine、BIOS Google 08/04/2023 呼び出しトレース:
 <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106 panic+0x30f/0x770 kernel/panic.c:340 check_panic_on_warn+0x82/0xa0 kernel/panic.c:236 ubsan_epilogue lib/ubsan.c:223 [inline] __ubsan_handle_out_of_bounds+0x13c/0x150 lib/ubsan.c:348 dbAdjTree+0x474/0x4f0 fs/jfs/jfs_dmap.c:2867 dbJoin+0x210/0x2d0 fs/jfs/jfs_dmap.c:2834 dbFreeBits+0x4eb/0xda0 fs/jfs/jfs_dmap.c:2331 dbFreeDmap fs/jfs/jfs_dmap.c:2080 [inline] dbFree+0x343/0x650 fs/jfs/jfs_dmap.c:402 txFreeMap+0x798/0xd50 fs/jfs/jfs_txnmgr.c:2534 txUpdateMap+0x342/0x9e0 txLazyCommit fs/jfs/jfs_txnmgr.c:2664 [inline] jfs_lazycommit+0x47a/0xb70 fs/jfs/jfs_txnmgr.c:2732 kthread+0x2d3/0x370 kernel/kthread.c:388 ret_from_fork+0x48/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304 </TASK> カーネルオフセット: 86400 秒後に再起動が無効にされます.. この問題は、lp の値が stree の最大サイズである CTLTREESIZE よりも大きくなると発生します。単純なチェックを追加することで、この問題を解決できます。Dave: この関数は void を返すため、エラーを適切に処理するには、より侵入的なコードを再編成する必要があります。そこで、よりクリーンなオプションが欠如している Osama 氏のパッチを use WARN_ON_ONCE で修正しました。パッチは syzbot を介してテストされます。(CVE-2023-52604)

 - Linux カーネルで、以下の脆弱性が解決されています。powerpc/lib: ベクトル操作のサイズを検証します sstep.c の一部の fp/vmx コードは、エミュレートされる命令に対して特定の最大サイズを想定しています。ただし、これらの操作のサイズは、analyse_instr() で個別に決定されます。操作の最大サイズの想定を検証するチェックを追加し、意図しないカーネルスタックの破損を防ぎます。(CVE-2023-52606)

 - Linux カーネルで、次の脆弱性が解決されています。powerpc/mm: pgtable_cache_add の NULL ポインターデリファレンスを修正します kasprintf() が、失敗時に NULL になる可能性のある動的に割り当てられたメモリへポインターを返します。ポインターの有効性をチェックして、割り当てが成功したことを確認します。
 (CVE-2023-52607)

 - Linux カーネルでは、以下の脆弱性が解決されています。ファームウェア: arm_scmi: 一貫性についてメールボックス/SMT チャネルをチェックします。完了割り込みを受け取ると、共有メモリ領域がアクセスされて、最初にメッセージヘッダーが取得されます。次に、メッセージシーケンス番号がまだ保留中のトランザクションを識別している場合は、関連するペイロードもフェッチされます。SCMI コマンドがタイムアウトした場合、最終的に遅れた返信を受信するまでチャネル所有権はプラットフォームに残ります。その結果、さらなる送信の試行は保留され、チャネルがプラットフォームによって放棄されるのを待機します。
 遅延した返信を受信すると、チャネル所有権はエージェントに戻され、保留中のリクエストは続行でき、配信されたばかりの返信の遅延した SMT 領域を上書きできます。その後、新しいリクエストに対する返信の待機が始まります。遅い返信に関連する偽の IRQ が、新たにエンキューされたリクエストと誤って関連付けられる可能性があることが確認されています。これが発生すると、SCMI スタックの処理中の検索手順は、実際の返信がまだ到着していないにもかかわらず、SMT 領域に現在存在するメッセージヘッダーが新しい保留中のトランザクションに関連しているという事実によって騙されます。A2P チャネルでのこの競合状態は、チャネルステータスビットを確認することで検出できます。プラットフォームからの真の返信は、完了 IRQ をトリガーする前にチャネル解放ビットを設定します。整合性チェックを追加し、A2P ISR のそのような状態を検証します。(CVE-2023-52608)

 - Linux カーネルで、以下の脆弱性が解決されています。PM / devfreq: trans_stat_show のバッファオーバーフローを修正します trans_stat_show() のバッファオーバーフローを修正します。シンプルな snprintf を、サイズが PAGE_SIZE のより安全な scnprintf に変換します。PAGE_SIZE を超えている場合は、条件チェックを追加し、早期にループを終了します。また、PAGE_SIZE を超えたこと、および stats が無効であることを示す警告を末尾に追加します。完全な移行テーブルを書き込むのに十分なスペースがない場合は、-EFBIG を返します。また、この関数が EFBIG エラーを返す可能性があることを ABI で文書化します。(CVE-2023-52614)

 - Linux カーネルでは、以下の脆弱性が解決されています。hwrng: core - mmap-ed hwrng のページ障害デッドロックを修正します。hwrng デバイスの読み取りパスにデッドロックがあります。これは、ユーザーが /dev/hwrng からメモリに読み取りを行い、/dev/hwrng からも mmap されたときにトリガーされます。その結果、ページ障害が発生すると、再帰的な読み取りがトリガーされ、デッドロックが発生します。copy_to_user を呼び出す際にスタックバッファを使用してこれを修正します。(CVE-2023-52615)

 - Linux カーネルでは、次の脆弱性が解決されています。crypto: lib/mpi - mpi_ec_init の予期しないポインターアクセスを修正します mpi_ec_ctx 構造体が初期化される際に、一部のフィールドが消去されず、構造体がリリースされたときにそのフィールドを参照する際にクラッシュが発生します。mpi_ec_ctx 用のメモリが __GFP_ZERO フラグで割り当てられるため、当初、この問題は無視されていました。たとえば、このエラーは、SM2 の Za 値を個別に計算するときにトリガーされます。(CVE-2023-52616)

 - Linux カーネルで、以下の脆弱性が解決されています。PCI: switchtec: 予期しないホットリムーブ後の stdev_release() クラッシュを修正 stdev->cdev が開いたままになっている間に、PCI デバイスのホットリムーバルが発生する可能性があります。stdev_release() への呼び出しは、close または exit の際に、switchtec_pci_remove() を通過したポイントで発生します。
 そうしないと、最後の ref が、戻る直前に、末尾の put_device() で消えてしまいます。後の時点で、devm クリーンアップはすでに stdev->mmio_mrpc マッピングを削除しています。また、stdev->pdev 参照がカウントされませんでした。したがって、DMA モードでは、stdev_release() の iowrite32() は致命的なページ障害を引き起こし、後続の dma_free_coherent() が到達すると、古い &stdev->pdev->dev ポインターを渡します。stdev_kill() の後に、MRPC DMA シャットダウンを switchtec_pci_remove() に移動することで、修正します。stdev->pdev 参照のカウントはオプションになりましたが、将来の事故を防ぐ可能性があります。https://lore.kernel.org/r/[email protected] のスクリプトを介して再現可能 (CVE-2023-52617)

 - Linux カーネルでは、次の脆弱性は解決されています。block/rnbd-srv: ありそうもない文字列オーバーフローをチェックします dev_search_path は技術的に PATH_MAX と同じ大きさになる可能性があるため、これと同じく PATH_MAX サイズの 2 番目の文字列を full_path へコピーする際に切り捨てのリスクがありました。W=1 ビルドはこの警告を報告していました。drivers/block/rnbd/rnbd-srv.c: 関数「process_msg_open.isra」内:
 drivers/block/rnbd/rnbd-srv.c:616:51: 警告: 「%s」ディレクティブ出力は、0 ～ 4095 のサイズの領域に最大 254 バイトを書き込む際に切り捨てられる可能性があります [-Wformat-truncation=] 616 | snprintf(full_path, PATH_MAX, %s/%s, | ^~ 関数「rnbd_srv_get_full_path」では、drivers/block/rnbd/rnbd-srv.c:721:14: で「process_msg_open.isra」 からインライン化 drivers/block/rnbd /rnbd-srv.c:616:17: 注意:「snprintf」は、サイズ 4096 616 の宛先に 2 ～ 4351 バイトを出力します | snprintf(full_path, PATH_MAX, %s/%s, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 617 | dev_search_path, dev_name); | ~~~~~~~~~~~~~~~~~~~~~~~~~~ これを修正するために、無条件に切り捨てをチェックします (%SESSNAME% が存在する場合にすでに行われています)。(CVE-2023-52618)

 - Linux カーネルでは、次の脆弱性は解決されています。pstore/ram: cpus の数を奇数に設定する際のクラッシュを修正します。CPU コアの数が 7 または他の奇数に調整されると、ゾーンサイズが奇数になります。ゾーンのアドレスは次のようになります。addr of zone0 = BASE addr of zone1 = BASE + zone_size addr of zone2 = BASE + zone_size*2 ... zone1/3/5/7 のアドレスは、非整合 va にマッピングされます。最終的には、これらの va にアクセスする際にクラッシュが発生します。そのため、ALIGN_DOWN() を使用してゾーンサイズが均等になるようにし、このバグを回避します。(CVE-2023-52619)

 - Linux カーネルで、次の脆弱性が解決されています。ext4: 過大な flex bg によるオンラインサイズ変更の失敗を回避します。過大な flexbg_size、mkfs.ext4 で ext4 ファイルシステムをオンラインでサイズ変更する場合
 -F -G 67108864 $dev -b 4096 100M mount $dev $dir resize2fs $dev 16G 次の WARN_ON がトリガーされます。
 ================================================================== 警告: CPU: 0 PID: 427 at mm/page_alloc.c:4402 __alloc_pages+0x411/0x550 リンクされたモジュール: sg(E) CPU: 0 PID: 427 Comm: resize2fs 汚染: G E 6.6.0-rc5+ #314 RIP: 0010:__alloc_pages+0x411/0x550 呼び出しトレース: <TASK>
 __kmalloc_large_node+0xa2/0x200 __kmalloc+0x16e/0x290 ext4_resize_fs+0x481/0xd80
 __ext4_ioctl+0x1616/0x1d90 ext4_ioctl+0x12/0x20 __x64_sys_ioctl+0xf0/0x150 do_syscall_64+0x3b/0x90 ================================================================== これは、flexbg_size が大きすぎて、割り当てられる new_group_data 配列のサイズが MAX_ORDER を超えています。現在、MAX_ORDER の最小値は 8、PAGE_SIZE の最小値は 4096、割り当て可能な対応するグループの最大数は次のとおりです。(PAGE_SIZE << MAX_ORDER) / sizeof(struct ext4_new_group_data) 21845 そして、 その値は 16384 の 2 のべき乗に整列されます。したがって、この値は MAX_RESIZE_BG として定義され、毎回追加されるグループの数がサイズ変更中にこの値を超えず、オンラインサイズ変更を完了するために複数回追加されます。違いは、flex_bg 内のメタデータはより分散される可能性があることです。(CVE-2023-52622)

 - Linux カーネルでは、次の脆弱性が解決されています。SUNRPC: 不審な RCU 使用の警告を修正します pNFS を実行している ontap サーバーに対して cthon を実行しているときに、次の警告を受け取りました。[57.202521] ========== =================== [ 57.202522] 警告: 不審な RCU の使用 [ 57.202523] 6.7.0-rc3-g2cc14f52aeb7 #41492 汚染されていない [ 57.202525] --- -------------------------- [ 57.202525] net/sunrpc/xprtmultipath.c:349 RCU リストが非リーダーセクションをトラバースしました!! [ 57.202527] これのデバッグに役立つ可能性のあるその他の情報: [ 57.202528] rcu_scheduler_active = 2、debug_locks = 1 [ 57.202529] test5/3567 により保持されているロックなし。 [ 57.202530] スタックバックトレース: [ 57.202532] CPU: 0 PID: 3567 通信: test5 汚染されていない 6.7.0-rc3-g2cc14f52aeb7 #41492 5b09971b4965c0aceba19f3eea324a4a806e227e [ 57.202534] 、ハードウェア名: QEMU Standard PC (Q35 + ICH9, 2009)、BIOS 不明 2022 年 2 月 2 日 [ 57.202536] 呼び出しトレース: [ 57.202537] <TASK> [57.202540] dump_stack_lvl+0x77/0xb0 [ 57.202551] lockdep_rcu_suspicious+0x154/0x1a0 [ 57.202556] rpc_xprt_switch_has_addr+0x17c/0x190 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6] [ 57.202596] rpc_clnt_setup_test_and_add_xprt+0x50/0x180 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6] [ 57.202621] ? rpc_clnt_add_xprt+0x254/0x300 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6] [ 57.202646] rpc_clnt_add_xprt+0x27a/0x300 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6] [ 57.202671] ?
 __pfx_rpc_clnt_setup_test_and_add_xprt+0x10/0x10 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6] [57.202696] nfs4_pnfs_ds_connect+0x345/0x760 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9] [ 57.202728] ? __pfx_nfs4_test_session_trunk+0x10/0x10 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9] [ 57.202754] nfs4_fl_prepare_ds+0x75/0xc0 [nfs_layout_nfsv41_files e3a4187f18ae8a27b630f9feae6831b584a9360a] [57.202760] filelayout_write_pagelist+0x4a/0x200 [nfs_layout_nfsv41_files e3a4187f18ae8a27b630f9feae6831b584a9360a] [ 57.202765] pnfs_generic_pg_writepages+0xbe/0x230 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9] [ 57.202788] __nfs_pageio_add_request+0x3fd/0x520 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202813] nfs_pageio_add_request+0x18b/0x390 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202831] nfs_do_writepage+0x116/0x1e0 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202849] nfs_writepages_callback+0x13/0x30 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202866] write_cache_pages+0x265/0x450 [ 57.202870] ?
 __pfx_nfs_writepages_callback+0x10/0x10 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202891] nfs_writepages+0x141/0x230 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202913] do_writepages+0xd2/0x230 [ 57.202917] ? filemap_fdatawrite_wbc+0x5c/0x80 [ 57.202921] filemap_fdatawrite_wbc+0x67/0x80 [ 57.202924] filemap_write_and_wait_range+0xd9/0x170 [ 57.202930] nfs_wb_all+0x49/0x180 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202947] nfs4_file_flush+0x72/0xb0 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9] [ 57.202969]
 __se_sys_close+0x46/0xd0 [ 57.202972] do_syscall_64+0x68/0x100 [ 57.202975] ? do_syscall_64+0x77/0x100 [57.202976] ? do_syscall_64+0x77/0x100 [ 57.202979] entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ 57.202982] RIP: 0033:0x7fe2b12e4a94 [ 57.202985] Code: 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 80 3d d5 18 0e 00 00 74 13 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 44 c3 0f 1f 00 48 83 ec 18 89 7c 24 0c e8 c3 [ 57.202987] RSP: 002b:00007ffe857ddb38 EFLAGS: 00000202 ORIG_RAX:
 0000000000000003 [ 57.202989] RAX: ffffffffffffffda RBX: 00007ffe857dfd68 RCX: 00007fe2b12e4a94 [57.202991] RDX: 0000000000002000 RSI: 00007ffe857ddc40 RDI: 0000000000000003 [ 57.202992] RBP:
 00007ffe857dfc50 R08: 7fffffffffffffff R09: 0000000065650f49 [ 57.202993] R10: 00007f ---truncated--- (CVE-2023-52623)

 - Linux カーネルで、次の脆弱性が解決されています。iio: adc: ad7091r: ユーザーにデバイスイベントの構成を許可 AD7091R-5 デバイスは、ad7091r-base ドライバーとともに ad7091r-5 ドライバーでサポートされています。これらのドライバーは、ADC 読み取りが下限レジスターのしきい値を下回ったか、上限レジスターの設定値を超えたときに、ユーザー空間に通知するための iio イベントを宣言しています。ただし、iio イベントとそのしきい値を構成するには、一連のコールバック関数を実装する必要がありますが、これまでは存在していませんでした。適切なコールバック関数なしで ad7091r-5 イベントの構成を試みた結果、コールバック関数へのポインターが設定されていないため、カーネルで NULL ポインターデリファレンスが発生しました。ユーザーがイベントしきい値を読み書きしたり、イベント生成を有効化/無効化したりできるように、イベント構成コールバックを実装します。イベント仕様構造体は AD7091R デバイスに対して汎用であるため、ad7091r-2/-4/-8 のサポートが追加されたときに再利用できるように、これらも ad7091r-5 ドライバーからベースドライバーに移動します。(CVE-2023-52627)

 - Linux カーネルでは、以下の脆弱性が解決されています。fs/ntfs3: NULL デリファレンスのバグを修正します。ここでの問題は、これが ntfs_load_attr_list() から呼び出される場合です。サイズは le32_to_cpu(attr->res.data_size) から取得されるため、64 ビットシステムではオーバーフローできませんが、32 ビットシステムでは +1023 がオーバーフローする可能性があり、結果はゼロになります。これは、kmalloc が ZERO_SIZE_PTR を返すことで成功し、次の行で memcpy() が Oops でクラッシュすることを意味します。(CVE-2023-52631)

 - Linux カーネルで、次の脆弱性が解決されています。um: time-travel: 時間の破損を修正します。「基本」タイムトラベリングモード (=inf-cpu または =ext なし) でも、タイマー割り込みが発生します。これらは任意の時点で発生する可能性があります。つまり、時間を少し早める timer_read() の実行中などです。次に、プッシュする新しい時間を計算した後で、実際にはそれを終了する前に、割り込みを取得した場合、割り込みが転送の時間と互換性のない時間の値を設定し、転送時に時間を戻したときにクラッシュします。これを修正するには、すべての割り込みを無効にして、time_tlabel_time の読み取り、調整の計算、調整を行います。(CVE-2023-52633)

 - Linux カーネルでは、次の脆弱性は解決されています。PM / devfreq: devfreq_monitor_[start/stop] を同期します。ループ内で行われるガバナーの頻繁な切り替えにより、タイマーリストが破損する場合、タイマーキャンセルが 2 つの場所から行われる可能性があります。1 つは cancel_delayed_work_sync() から、もう 1 つは expire_timers() からで、traces[1] から確認できます。true の場合 echo simple_ondemand > /sys/class/devfreq/1d84000.ufshc/governor echo performance > /sys/class/devfreq/1d84000.ufshc/governor done を実行します。それは 、遅延した作業がキューに入れられている、実行されている、またはキャンセルされている間に、device_monitor_[start/stop] を同期して遅延した作業を破損させる devfreq ドライバーの問題のようです。
 ポーリングフラグと devfreq ロックを使用して、タイマーインスタンスのキューイングを 2 回同期させて、破損している作業データを処理しましょう。[1] ... .. <idle>-0 [003] 9436.209662: timer_cancel timer=0xffffff80444f0428 <idle>-0 [003] 9436.209664: timer_expire_entry timer=0xffffff80444f0428 now=0x10022da1c function=__typeid__ZTSFvP10timer_listE_global_addr baseclk=0x10022da1c <idle>-0 [003] 9436.209718:
 timer_expire_exit timer=0xffffff80444f0428 kworker/u16:6-14217 [003] 9436.209863: timer_start timer=0xffffff80444f0428 function=__typeid__ZTSFvP10timer_listE_global_addr expires=0x10022da2b now=0x10022da1c flags=182452227 vendor.xxxyyy.ha-1593 [004] 9436.209888: timer_cancel timer=0xffffff80444f0428 vendor.xxxyyy.ha-1593 [004] 9436.216390: timer_init timer=0xffffff80444f0428 vendor.xxxyyy.ha-1593 [004] 9436.216392: timer_start timer=0xffffff80444f0428 function=__typeid__ZTSFvP10timer_listE_global_addr expires=0x10022da2c now=0x10022da1d flags=186646532 vendor.xxxyyy.ha-1593 [005] 9436.220992: timer_cancel timer=0xffffff80444f0428 xxxyyyTraceManag-7795 [004] 9436.261641: timer_cancel timer=0xffffff80444f0428 [2] 9436.261653][ C4] 仮想アドレスデッド00000000012a でカーネルページリクエストを処理できない [ 9436.261664][ C4] Mem abort info: [ 9436.261666][ C4] ESR = 0x96000044 [ 9436.261669] ][ C4] EC = 0x25: DABT (現在の EL)、IL = 32 ビット [ 9436.261671][ C4] SET = 0、FnV = 0 [ 9436.261673][ C4] EA = 0、S1PTW = 0 [ 9436.261675] [ C4 ] データ中止情報: [ 9436.261677][ C4] ISV = 0、ISS = 0x00000044 [ 9436.261680][ C4] CM = 0、WnR = 1 [ 9436.261682] [ C4] [dead00000000012a] ユーザーおよびカーネルアドレス範囲間のアドレス[ 9436.261685][ C4] 内部エラー: Oops: 96000044 [#1] SMP PREEMPT [ [ 9436.261701][ C4] md ftrace バッファダンプをスキップ: 0x3a982d0 ... [ 9436.262138][ C4] CPU: 4 PID: 7795 Comm: TraceManag 汚染: GSWO 5.10.149-android12-9-o-g17f915d29d0c #1 [ 9436.262141][C4] ハードウェア名: Qualcomm Technologies, Inc. (DT) [ 9436.262144][ C4] pstate: 22400085 (nzCv daIf +PAN -UAO +TCO BTYPE=--) [ 9436.262161][ C4] pc : expire_timers+0x9c/0x438 [ 9436.262164][ C4] lr :
 expire_timers+0x2a4/0x438 [ 9436.262168][ C4] sp : ffffffc010023dd0 [ 9436.262171][ C4] x29:
 ffffffc010023df0 x28: ffffffd0636fdc18 [ 9436.262178][ C4] x27: ffffffd063569dd0 x26: ffffffd063536008 [9436.262182][ C4] x25: 0000000000000001 x24: ffffff88f7c69280 [ 9436.262185][ C4] x23: 00000000000000e0 x22: dead000000000122 [ 9436.262188][ C4] x21: 000000010022da29 x20: ffffff8af72b4e80 [ 9436.262191][ C4] x19: ffffffc010023e50 x18: ffffffc010025038 [ 9436.262195][ C4] x17: 0000000000000240 x16:
 0000000000000201 [ 9436.262199][ C4] x15: ffffffffffffffff x14: ffffff889f3c3100 [ 9436.262203][ C4] x13:
 ffffff889f3c3100 x12: 00000000049f56b8 [ 9436.262207][ C4] x11: 00000000049f56b8 x10: 00000000ffffffff [9436.262212][ C4] x9 : ffffffc010023e50 x8 : dead000000000122 [ 9436.262216][ C4] x7 : ffffffffffffffff x6 : ffffffc0100239d8 [ 9436.262220][ C4] x5 : 0000000000000000 x4 : 0000000000000101 [ 9436.262223][ C4] x3 : 0000000000000080 x2 : ffffff8 ---truncated--- (CVE-2023-52635)

 - Linux カーネルで、次の脆弱性が解決されています。can: j1939: setsockopt(SO_J1939_FILTER) 中、j1939_sk_match_filter の UAF を修正します。setsockopt(..., SO_J1939_FILTER, ...) が jsk->filters を変更する場合、パケットの受信中に UAF を防止するために jsk->sk をロックします。次のトレースが、影響を受けるシステムで確認されました。================================================================== バグ: KASAN: j1939_sk_recv_match_one+0x1af/0x2d0 の slab-use-after-free [can_j1939] タスク j1939/350 による addr ffff888012144014 でのサイズ 4 の読み取りCPU: 0 PID: 350 Comm: j1939: 汚染: GW OE 6.5.0-rc5 #1 ハードウェア名: QEMU Standard PC (i440FX + PIIX, 1996)、BIOS 1.13.0-1ubuntu1.1 04/01/2014 2014年1月 呼び出しトレース: print_report+0xd3/0x620 ? kasan_complete_mode_report_info+0x7d/0x200 ? j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939] kasan_report+0xc2/0x100 ? j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939] __asan_load4+0x84/0xb0 j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939] j1939_sk_recv+0x20b/0x320 [can_j1939] ?
 __kasan_check_write+0x18/0x20 ? __pfx_j1939_sk_recv+0x10/0x10 [can_j1939] ? j1939_simple_recv+0x69/0x280 [can_j1939] ? j1939_ac_recv+0x5e/0x310 [can_j1939] j1939_can_recv+0x43f/0x580 [can_j1939] ?
 __pfx_j1939_can_recv+0x10/0x10 [can_j1939] ? raw_rcv+0x42/0x3c0 [can_raw] ? __pfx_j1939_can_recv+0x10/0x10 [can_j1939] can_rcv_filter+0x11f/0x350 [can] can_receive+0x12f/0x190 [can] ? __pfx_can_rcv+0x10/0x10 [can] can_rcv+0xdd/0x130 [can] ? __pfx_can_rcv+0x10/0x10 [can] __netif_receive_skb_one_core+0x13d/0x150 ?
 __pfx___netif_receive_skb_one_core+0x10/0x10 ? __kasan_check_write+0x18/0x20 ?
 _raw_spin_lock_irq+0x8c/0xe0 __netif_receive_skb+0x23/0xb0 process_backlog+0x107/0x260
 __napi_poll+0x69/0x310 net_rx_action+0x2a1/0x580 ? __pfx_net_rx_action+0x10/0x10 ?
 __pfx__raw_spin_lock+0x10/0x10 ? handle_irq_event+0x7d/0xa0 __do_softirq+0xf3/0x3f8 do_softirq+0x53/0x80 </IRQ> <TASK> __local_bh_enable_ip+0x6e/0x70 netif_rx+0x16b/0x180 can_send+0x32b/0x520 [can] ?
 __pfx_can_send+0x10/0x10 [can] ? __check_object_size+0x299/0x410 raw_sendmsg+0x572/0x6d0 [can_raw] ?
 __pfx_raw_sendmsg+0x10/0x10 [can_raw] ? apparmor_socket_sendmsg+0x2f/0x40 ? __pfx_raw_sendmsg+0x10/0x10 [can_raw] sock_sendmsg+0xef/0x100 sock_write_iter+0x162/0x220 ? __pfx_sock_write_iter+0x10/0x10 ?
 __rtnl_unlock+0x47/0x80 ? security_file_permission+0x54/0x320 vfs_write+0x6ba/0x750 ?
 __pfx_vfs_write+0x10/0x10 ? __fget_light+0x1ca/0x1f0 ? __rcu_read_unlock+0x5b/0x280 ksys_write+0x143/0x170 ? __pfx_ksys_write+0x10/0x10 ? __kasan_check_read+0x15/0x20 ? fpregs_assert_state_consistent+0x62/0x70
 __x64_sys_write+0x47/0x60 do_syscall_64+0x60/0x90 ? do_syscall_64+0x6d/0x90 ? irqentry_exit+0x3f/0x50 ? exc_page_fault+0x79/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 タスク 348 による割り当て:
 kasan_save_stack+0x2a/0x50 kasan_set_track+0x29/0x40 kasan_save_alloc_info+0x1f/0x30
 __kasan_kmalloc+0xb5/0xc0 __kmalloc_node_track_caller+0x67/0x160 j1939_sk_setsockopt+0x284/0x450 [can_j1939] __sys_setsockopt+0x15c/0x2f0 __x64_sys_setsockopt+0x6b/0x80 do_syscall_64+0x60/0x90 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Freed by task 349: kasan_save_stack+0x2a/0x50 kasan_set_track+0x29/0x40 kasan_save_free_info+0x2f/0x50 __kasan_slab_free+0x12e/0x1c0
 __kmem_cache_free+0x1b9/0x380 kfree+0x7a/0x120 j1939_sk_setsockopt+0x3b2/0x450 [can_j1939]
 __sys_setsockopt+0x15c/0x2f0 __x64_sys_setsockopt+0x6b/0x80 do_syscall_64+0x60/0x90 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 (CVE-2023-52637)

 - Linux カーネルで、次の脆弱性が解決されています。can: j1939: j1939_socks_lock を rwlock に変更することでデッドロックを防ぎます。次の 3 つのロックが互いに競合し、Syzbot バグレポートでデッドロック状況を引き起こす可能性があります -- j1939_socks_lock - active_session_list_lock - sk_session_queue_lock j1939_socks_lock が保護しているリンクされたリストに対して書き込みロックが必要とされるまれな状況で、コードがロックの取得を試行しないため、j1939_socks_lock を rwlock に変更することが妥当な修正です。これにより、循環ロックの依存関係が解消されます。たとえば、現在のスレッドがすでに j1939_socks_lock をロックして sk_session_queue_lock をロックしており、同時に別のスレッドが sk_session_queue_lock を保持しながら j1939_socks_lock の取得を試みます。注意: このパッチは、Syzbot によって報告された unregister_netdevice バグを修正しません。代わりに、Syzbot のバグを実際に修正するための 1 つ以上のパッチを準備するためのデッドロックの状況を解決します。これは、j1939 コードベース内の参照カウントの問題のようです。[mkl: 関連のない改行の変更を削除] (CVE-2023-52638)

 - Linux カーネルでは、次の脆弱性が解決されました。media: rc: bpf のアタッチ/デタッチには書き込み権限が必要です。bpf のアタッチ/デタッチには CAP_NET_ADMIN も必要です。(CVE-2023-52642)

 - Linux カーネルでは、次の脆弱性が解決されています。iio: core: iio_device_register_sysfs の memleak を修正します iio_device_register_sysfs_group() が失敗した場合、潜在的な memleak を防ぐために iio_dev_opaque->chan_attr_group.attrs を解放する必要があります。(CVE-2023-52643)

 - Linux カーネルの Open vSwitch サブコンポーネントで、脆弱性が報告されました。この欠陥は、コードプッシュの再帰操作が再帰的にコードブロックを呼び出すときに発生します。OVS モジュールがスタックの深さを検証しないため、多くのフレームをプッシュし、スタックオーバーフローが発生します。その結果、クラッシュまたはその他の関連する問題が発生する可能性があります。(CVE-2024-1151)

 - 6.7.1 までの Linux カーネルの net/rds/af_rds.c の rds_recv_track_latency に、RDS_MSG_RX_DGRAM_TRACE_MAX の比較に off-by-one のエラーがあり、領域外アクセスが発生する可能性があります。(CVE-2024-23849)

 - Linux カーネルでは、次の脆弱性が解決されています。ksmbd: ksmbd_tcp_new_connection() の UAF 問題を修正します。新しい TCP 接続の処理とその切断の間に競合があります。
 これは、ksmbd_tcp_new_connection() 関数の「struct tcp_transport」で UAF を引き起こします。(CVE-2024-26592)

 - Linux カーネルでは、以下の脆弱性が解決されています。i2c: i801: ブロックプロセス呼び出しトランザクションを修正してます。Intel データシートによると、ソフトウェアはブロックプロセス呼び出しトランザクションのブロックバッファインデックスを 2 回リセットしなければなりません。バッファに送信データを書き込む前とバッファから着信データを読み取る前です。ドライバーには現在 2 番目のリセットがないため、ブロックバッファの誤った部分が読み取られます。(CVE-2024-26593)

 - Linux カーネルでは、次の脆弱性が解決されています。ksmbd: セッションセットアップで mech トークンを検証します。クライアントがセッションセットアップリクエストで無効な mech トークンを送信すると、ksmbd は検証して、それが無効な場合にエラーを作成します。(CVE-2024-26594)

 - Linux カーネルで、次の脆弱性は解決されています。phy: ti: phy-omap-usb2: SRP の NULL ポインターデリファレンスを修正します phy-omap-usb2 と連動する外部 phy が send_srp() を実装しない場合でも、まだそれを呼び出そうとする可能性があります。これは、ウェイクアップをトリガーするアイドル状態のイーサネットガジェットで発生する可能性があります。例: configfs-gadget.g1 gadget.0: ECM 一時停止 configfs-gadget.g1 gadget.0: ポート一時停止。
 ウェイクアップをトリガーしています... 実行時に仮想アドレス 00000000 でカーネル NULL ポインターデリファレンスを処理できません ... PC は musb_gadget_wakeup+0x1d4/0x254 [musb_hdrc] で 0x0 LR です ... musb_gadget_wakeup [musb_hdrc] from usb_gadget_wakeup+0x1c/0x3c [udc_core] usb_gadget_wakeup [udc_core] from eth_start_xmit+0x3b0/0x3d4 [u_ether] eth_start_xmit [u_ether] from dev_hard_start_xmit+0x94/0x24c dev_hard_start_xmit from sch_direct_xmit+0x104/0x2e4 sch_direct_xmit from __dev_queue_xmit+0x334/0xd88
 __dev_queue_xmit from arp_solicit+0xf0/0x268 arp_solicit from neigh_probe+0x54/0x7c neigh_probe from
 __neigh_event_send+0x22c/0x47c __neigh_event_send from neigh_resolve_output+0x14c/0x1c0 neigh_resolve_output from ip_finish_output2+0x1c8/0x628 ip_finish_output2 from ip_send_skb+0x40/0xd8 ip_send_skb from udp_send_skb+0x124/0x340 udp_send_skb from udp_sendmsg+0x780/0x984 udp_sendmsg from
 __sys_sendto+0xd8/0x158 __sys_sendto from ret_fast_syscall+0x0/0x58 それらを呼び出す前に send_srp() と set_vbus() をチェックすることで、この問題を修正しましょう。USB 周辺機器のみの場合、これらは両方とも NULL になる可能性があります。
 (CVE-2024-26600)

 - Linux カーネルでは、次の脆弱性は解決されています。sched/membarrier: sys_membarrier を攻撃する機能が低下します。一部のシステムでは、sys_membarrier が非常に負荷が高く、すべてにおいて全体的な速度低下を引き起こす可能性があります。そのため、アクセスをシリアル化するためにパスにロックを設定し、これが高すぎる頻度で呼び出されてマシンを飽和する機能を回避します。(CVE-2024-26602)

 - Linux カーネルにおいて、以下の脆弱性が解決されています。バインダー: 自己作業のスレッドに epoll シグナルを送ります。(e)poll モードでは、多くの場合、スレッドは、データを消費する準備ができている時期を判断するために I/O イベントに依存しています。
 バインダー内で、スレッドが読み取りバッファなしで BINDER_WRITE_READ を介してコマンドを開始し、その後で応答を消費するために epoll_wait() または類似のものを使用する可能性があります。その場合、epoll スレッドが自身の作業をキューに入れるときは、wakeup でシグナルを送ることが重要です。そうしないと、作業を処理しないまま、イベントが発生するのを無期限に待機するリスクがあります。さらに悪いことに、スレッドに保留中の作業があるため、後続のコマンドも wakeup をトリガーしません。(CVE-2024-26606)

 - Linux カーネルでは、次の脆弱性は解決されています。ksmbd: ksmbd_nl_policy のグローバル oob を修正します。報告された問題 (コミット b33fb5b801c6 をチェック (net: qualcomm: rmnet: rmnet_policy のグローバル oob の修正)) と同様に、ローカルの fuzzer がポリシー ksmbd_nl_policy について別のグローバル境界外読み取りを検出します。以下のバグトレースを参照してください。================================================================== BUG: KASAN: global-out-of-bounds in validate_nla lib/nlattr.c:386 [inline] BUG: KASAN: global-out-of-bounds in __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600 Read of size 1 at addr ffffffff8f24b100 by task syz-executor.1/62810 CPU: 0 PID: 62810 Comm: syz-executor.1 Tainted: G N 6.1.0 #3ハードウェア名: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 呼び出しトレース: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x8b/0xb3 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:284 [inline] print_report+0x172/0x475 mm/kasan/report.c:395 kasan_report+0xbb/0x1c0 mm/kasan/report.c:495 validate_nla lib/nlattr.c:386 [inline] __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600 __nla_parse+0x3e/0x50 lib/nlattr.c:697 __nlmsg_parse include/net/netlink.h:748 [inline] genl_family_rcv_msg_attrs_parse.constprop.0+0x1b0/0x290 net/netlink/genetlink.c:565 genl_family_rcv_msg_doit+0xda/0x330 net/netlink/genetlink.c:734 genl_family_rcv_msg net/netlink/genetlink.c:833 [inline] genl_rcv_msg+0x441/0x780 net/netlink/genetlink.c:850 netlink_rcv_skb+0x14f/0x410 net/netlink/af_netlink.c:2540 genl_rcv+0x24/0x40 net/netlink/genetlink.c:861 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] netlink_unicast+0x54e/0x800 net/netlink/af_netlink.c:1345 netlink_sendmsg+0x930/0xe50 net/netlink/af_netlink.c:1921 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg+0x154/0x190 net/socket.c:734 ____sys_sendmsg+0x6df/0x840 net/socket.c:2482 ___sys_sendmsg+0x110/0x1b0 net/socket.c:2536 __sys_sendmsg+0xf3/0x1c0 net/socket.c:2565 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fdd66a8f359 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fdd65e00168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007fdd66bbcf80 RCX: 00007fdd66a8f359 RDX:
 0000000000000000 RSI: 0000000020000500 RDI: 0000000000000003 RBP: 00007fdd66ada493 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13:
 00007ffc84b81aff R14: 00007fdd65e00300 R15: 0000000000022000 </TASK> buggy アドレスは次の変数に属しています。ksmbd_nl_policy+0x100/0xa80 バグのあるアドレスは次の物理ページに属しています。
 page:0000000034f47940 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1ccc4b flags:
 0x200000000001000(reserved|node=0|zone=2) raw: 0200000000001000 ffffea00073312c8 ffffea00073312c8 0000000000000000 raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffffffff8f24b000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffffffff8f24b080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffffff8f24b100: f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9 f9 00 00 07 f9 ^ ffffffff8f24b180: f9 f9 f9 f9 00 05 f9 f9 f9 f9 f9 f9 00 00 00 05 ffffffff8f24b200: f9 f9 f9 f9 00 00 03 f9 f9 f9 f9 f9 00 00 04 f9 ================================================================== これを修正するには、次の名前のプレースホルダーを追加します
 __KSMBD_EVENT_MAX。KSMBD_EVENT_MAX を元の値に戻します - 他の netlink ファミリーの動作に応じて 1 にします。また、KSMBD_EVENT_MAX を参照する 2 つのサイトを正しい値に変更します。(CVE-2024-26608)

 - Linux カーネルでは、次の脆弱性が解決されています。wifi: iwlwifi: メモリ破損を修正します iwl_fw_ini_trigger_tlv::data は __le32 へのポインターです。これは、iwl_fw_ini_trigger_tlv::data + offset へコピーして、バイトである間にオフセットする場合、バッファを越えて書き込むことを意味しています。
 (CVE-2024-26610)

 - Linux カーネルでは、次の脆弱性は解決されています。tcp: accept_queue のスピンロックを 1 回必ず初期化してください。syz の再現 C プログラムをローカルで実行すると、次の問題が発生します。
 pvqspinlock: ロック 0xffff9d181cd5c660 には破損した値 0x0! があります。警告: CPU: 19 PID: 21160 at
 __pv_queued_spin_unlock_slowpath (kernel/locking/qspinlock_paravirt.h:508) ハードウェア名：Red Hat KVM、BIOS 0.5.101/01/2011 RIP: 0010:__pv_queued_spin_unlock_slowpath (kernel/locking/qspinlock_paravirt.h:508) コード: 73 56 3a ff 90 c3 cc cc cc cc 8b 05 bb 1f 48 01 85 c0 74 05 c3 cc cc cc cc 8b 17 48 89 fe 48 c7 c7 30 20 ce 8f e8 ad 56 42 ff <0f> 0b c3 cc cc cc cc 0f 0b 0f 1f 40 00 90 90 90 90 90 90 90 90 90 RSP:
 0018:ffffa8d200604cb8 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff9d1ef60e0908 RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffff9d1ef60e0900 RBP: ffff9d181cd5c280 R08:
 0000000000000000 R09: 00000000ffff7fff R10: ffffa8d200604b68 R11: ffffffff907dcdc8 R12: 0000000000000000 R13: ffff9d181cd5c660 R14: ffff9d1813a3f330 R15: 0000000000001000 FS: 00007fa110184640(0000) GS:ffff9d1ef60c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2:
 0000000020000000 CR3: 000000011f65e000 CR4: 00000000000006f0 呼び出しトレース: <IRQ> _raw_spin_unlock (kernel/locking/spinlock.c:186) inet_csk_reqsk_queue_add (net/ipv4/inet_connection_sock.c:1321) inet_csk_complete_hashdance (net/ipv4/inet_connection_sock.c:1358) tcp_check_req (net/ipv4/tcp_minisocks.c:868) tcp_v4_rcv (net/ipv4/tcp_ipv4.c:2260) ip_protocol_deliver_rcu (net/ipv4/ip_input.c:205) ip_local_deliver_finish (net/ipv4/ip_input.c:234) __netif_receive_skb_one_core (net/core/dev.c:5529) process_backlog (./include/linux/rcupdate.h:779) __napi_poll (net/core/dev.c:6533) net_rx_action (net/core/dev.c:6604) __do_softirq (./arch/x86/include/asm/jump_label.h:27) do_softirq (kernel/softirq.c:454 kernel/softirq.c:441) </IRQ> <TASK> __local_bh_enable_ip (kernel/softirq.c:381)
 __dev_queue_xmit (net/core/dev.c:4374) ip_finish_output2 (./include/net/neighbour.h:540 net/ipv4/ip_output.c:235) __ip_queue_xmit (net/ipv4/ip_output.c:535) __tcp_transmit_skb (net/ipv4/tcp_output.c:1462) tcp_rcv_synsent_state_process (net/ipv4/tcp_input.c:6469) tcp_rcv_state_process (net/ipv4/tcp_input.c:6657) tcp_v4_do_rcv (net/ipv4/tcp_ipv4.c:1929) __release_sock (./include/net/sock.h:1121 net/core/sock.c:2968) release_sock (net/core/sock.c:3536) inet_wait_for_connect (net/ipv4/af_inet.c:609) __inet_stream_connect (net/ipv4/af_inet.c:702) inet_stream_connect (net/ipv4/af_inet.c:748) __sys_connect (./include/linux/file.h:45 net/socket.c:2064) __x64_sys_connect (net/socket.c:2073 net/socket.c:2070 net/socket.c:2070) do_syscall_64 (arch/x86/entry/common.c:51 arch/x86/entry/common.c:82) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:129) RIP:
 0033:0x7fa10ff05a3d コード: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48>3d 01 f0 ff ff 73 01 c3 48 8b 0d ab a3 0e 00 f7 d8 64 89 01 48 RSP: 002b:00007fa110183de8 EFLAGS: 00000202 ORIG_RAX: 000000000000002a RAX: ffffffffffffffda RBX:
 0000000020000054 RCX: 00007fa10ff05a3d RDX: 000000000000001c RSI: 0000000020000040 RDI: 0000000000000003 RBP: 00007fa110183e20 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11:
 0000000000000202 R12: 00007fa110184640 R13: 0000000000000000 R14: 00007fa10fe8b060 R15: 00007fff73e23b20 </TASK> 問題を引き起こすプロセスは次のように分析されます。Thread A Thread B tcp_v4_rcv //receive ack TCP packet inet_shutdown tcp_check_req tcp_disconnect //disconnect sock ... tcp_set_state(sk、TCP_CLOSE) inet_csk_complete_hashdance ... inet_csk_reqsk_queue_add ---truncated--- (CVE-2024-26614)

 - Linux カーネルで、次の脆弱性が解決されています。net/smc: SMC-D 接続ダンプの違法な rmb_desc アクセスを修正します。SMC-D 接続をダンプするときにクラッシュが見つかりました。これは、次の手順で再現できます。- nginx/wrk テストを実行します。smc_run nginx smc_run wrk -t 16 -c 1000 -d <duration> -H 'Connection: Close' <URL> - パラレルで SMC-D 接続を継続的にダンプ: ウォッチ - n 1 の「smcss -D」バグ:
 カーネル NULL ポインターデリファレンス、アドレス: 0000000000000030 CPU: 2 PID: 7204 Comm: smcss Kdump: ロード済み 汚染: G E 6.7.0+ #55 RIP: 0010:__smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag] Call Trace: <TASK> ?
 __die+0x24/0x70 ? page_fault_oops+0x66/0x150 ? exc_page_fault+0x69/0x140 ? asm_exc_page_fault+0x26/0x30 ?
 __smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag] ? __kmalloc_node_track_caller+0x35d/0x430 ?
 __alloc_skb+0x77/0x170 smc_diag_dump_proto+0xd0/0xf0 [smc_diag] smc_diag_dump+0x26/0x60 [smc_diag] netlink_dump+0x19f/0x320 __netlink_dump_start+0x1dc/0x300 smc_diag_handler_dump+0x6a/0x80 [smc_diag] ?
 __pfx_smc_diag_dump+0x10/0x10 [smc_diag] sock_diag_rcv_msg+0x121/0x140 ? __pfx_sock_diag_rcv_msg+0x10/0x10 netlink_rcv_skb+0x5a/0x110 sock_diag_rcv+0x28/0x40 netlink_unicast+0x22a/0x330 netlink_sendmsg+0x1f8/0x420
 __sock_sendmsg+0xb0/0xc0 ____sys_sendmsg+0x24e/0x300 ? copy_msghdr_from_user+0x62/0x80
 ___sys_sendmsg+0x7c/0xd0 ? __do_fault+0x34/0x160 ? do_read_fault+0x5f/0x100 ? do_fault+0xb0/0x110 ?
 __handle_mm_fault+0x2b0/0x6c0 __sys_sendmsg+0x4d/0x80 do_syscall_64+0x69/0x180 entry_SYSCALL_64_after_hwframe+0x6e/0x76 ダンプの際は、接続が確立中の状態である可能性があります。接続は smc_conn_create() によりリンクグループに登録されていますが、rmb_desc が smc_buf_create() により初期化されていないため、conn->rmb_desc への不正なアクセスが発生したと想定されます。そのため、before dump をチェックして修正します。(CVE-2024-26615)

 - Linux カーネルで、次の脆弱性は解決されています。llc: リリースタイムでの sock_orphan() の呼び出し syzbot は、閉じられた llc ソケットの古い sk->sk_wq ポインターによって引き起こされる興味深いトレース [1] を報告しました。
 コミット ff7b11aa481f (net: socket: proto_ops::release() 呼び出し後に sock->sk を NULL に設定) で、Eric Biggers 氏は、完全な監査を実行する必要があるいくつかのプロトコルに sock_orphan() がないことを示唆しました。net-next で、sock_orphan() から sock->sk を消去し、Eric パッチを修正して警告を追加する予定です。[1] BUG: KASAN:
 slab-use-after-free in list_empty include/linux/list.h:373 [inline] BUG: KASAN: slab-use-after-free in waitqueue_active include/linux/wait.h:127 [inline] BUG: KASAN: slab-use-after-free in sock_def_write_space_wfree net/core/sock.c:3384 [inline] BUG: KASAN: slab-use-after-free in sock_wfree+0x9a8/0x9d0 net/core/sock.c:2468 Read of size 8 at addr ffff88802f4fc880 by task ksoftirqd/1/27 CPU: 1 PID: 27 Comm: ksoftirqd/1 Not tainted 6.8.0-rc1-syzkaller-00049-g6098d87eaf31 #0 ハードウェア名:
 QEMU Standard PC (Q35 + ICH9, 2009)、BIOS 1.16.2-debian-1.16.2-1 04/01/2014 呼び出しトレース: <TASK>
 __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc4/0x620 mm/kasan/report.c:488 kasan_report+0xda/0x110 mm/kasan/report.c:601 list_empty include/linux/list.h:373 [inline] waitqueue_active include/linux/wait.h:127 [inline] sock_def_write_space_wfree net/core/sock.c:3384 [inline] sock_wfree+0x9a8/0x9d0 net/core/sock.c:2468 skb_release_head_state+0xa3/0x2b0 net/core/skbuff.c:1080 skb_release_all net/core/skbuff.c:1092 [inline] napi_consume_skb+0x119/0x2b0 net/core/skbuff.c:1404 e1000_unmap_and_free_tx_resource+0x144/0x200 drivers/net/ethernet/intel/e1000/e1000_main.c:1970 e1000_clean_tx_irq drivers/net/ethernet/intel/e1000/e1000_main.c:3860 [inline] e1000_clean+0x4a1/0x26e0 drivers/net/ethernet/intel/e1000/e1000_main.c:3801 __napi_poll.constprop.0+0xb4/0x540 net/core/dev.c:6576 napi_poll net/core/dev.c:6645 [inline] net_rx_action+0x956/0xe90 net/core/dev.c:6778
 __do_softirq+0x21a/0x8de kernel/softirq.c:553 run_ksoftirqd kernel/softirq.c:921 [inline] run_ksoftirqd+0x31/0x60 kernel/softirq.c:913 smpboot_thread_fn+0x660/0xa10 kernel/smpboot.c:164 kthread+0x2c6/0x3a0 kernel/kthread.c:388 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:242 </TASK> タスク 5167 によって割り当て済み:
 kasan_save_stack+0x33/0x50 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:314 [inline] __kasan_slab_alloc+0x81/0x90 mm/kasan/common.c:340 kasan_slab_alloc include/linux/kasan.h:201 [inline] slab_post_alloc_hook mm/slub.c:3813 [inline] slab_alloc_node mm/slub.c:3860 [inline] kmem_cache_alloc_lru+0x142/0x6f0 mm/slub.c:3879 alloc_inode_sb include/linux/fs.h:3019 [inline] sock_alloc_inode+0x25/0x1c0 net/socket.c:308 alloc_inode+0x5d/0x220 fs/inode.c:260 new_inode_pseudo+0x16/0x80 fs/inode.c:1005 sock_alloc+0x40/0x270 net/socket.c:634
 __sock_create+0xbc/0x800 net/socket.c:1535 sock_create net/socket.c:1622 [inline] __sys_socket_create net/socket.c:1659 [inline] __sys_socket+0x14c/0x260 net/socket.c:1706 __do_sys_socket net/socket.c:1720 [inline] __se_sys_socket net/socket.c:1718 [inline] __x64_sys_socket+0x72/0xb0 net/socket.c:1718 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd3/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b タスク 0 により解放: kasan_save_stack+0x33/0x50 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640 poison_slab_object mm/kasan/common.c:241 [inline] __kasan_slab_free+0x121/0x1b0 mm/kasan/common.c:257 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2121 [inlin ---truncated--- (CVE-2024-26625)

 - Linux カーネルでは、次の脆弱性が解決されています。scsi: core: EH ハンドラーをウェイクアップするために、scsi_host_busy() をホストロックから移動します。scsi_eh_wakeup() 内では、scsi_host_busy() が呼び出され、ホストロックで毎回チェックされます。エラーハンドラー kthread をウェイクアップする必要があります。これは、次のような回復の場合には重すぎる可能性があります。- N 個のハードウェアキュー - キューの深さは各ハードウェアキューに対して M です - 各 scsi_host_busy() は、(N * M) 個のタグ/リクエストを反復します。すべてのリクエストが scsi_eh_wakeup() が最後の in-flight リクエストに対して呼び出され、scsi_host_busy() が (N * M - 1) 回実行され、リクエストが (N*M - 1) * (N * M) 回反復されました。N と M の両方が十分に大きい場合、ホストロックの取得時にハードロックアップがトリガーされる可能性があり、mpi3mr (128 の hw キュー、キューの深さ 8169) で観察されます。ホストロック外で scsi_host_busy() を呼び出すことで、この問題を修正します。ホストロックはビジーカウントをカバーしないため、ビジーカウントにホストロックは必要ありません。[mkp: Bart 氏が指摘した不要な「ビジー」変数をドロップします] (CVE-2024-26627)

 - Linux カーネルで、以下の脆弱性は解決されています。llc: ETH_P_TR_802_2 のサポートをドロップします。
 syzbot は、下記の uninit-value のバグを報告しました。[0] llc は ETH_P_802_2 (0x0004) をサポートしており、以前は ETH_P_TR_802_2 (0x0011) をサポートしていました。syzbot は後者を悪用してバグを引き起こしました。write$tun(r0, &(0x7f0000000040)={@val={0x0, 0x11}, @val, @mpls={[], @llc={@snap={0xaa, 0x1, ')', 90e5dd}}}}, 0x16) llc_conn_handler() は、llc_pdu_decode_sa()/llc_pdu_decode_da() で skb に基づいてローカル変数 {saddr,daddr}.mac を初期化し、それらを __llc_lookup() に渡します。ただし、初期化は skb->protocol が htons(ETH_P_802_2) である場合にのみ行われます。そうでない場合、__llc_lookup_established() と
 __llc_lookup_listener() がガベージを読み込みます。初期化の欠落は、コミット 211ed865108e より前に存在しました (net: トークンリングの特別処理のインスタンスをすべて削除します)。トークンリングスタッフを追い出すための部分を削除しましたが、ETH_P_TR_802_2 パケットが llc_rcv() に忍び込むことができるようにドアを閉じるのを忘れていました。
 llc_tr_packet_type を削除して、非推奨を完了させてください。[0]: BUG: KMSAN: uninit-value in
 __llc_lookup_established+0xe9d/0xf90 __llc_lookup_established+0xe9d/0xf90 __llc_lookup net/llc/llc_conn.c:611 [inline] llc_conn_handler+0x4bd/0x1360 net/llc/llc_conn.c:791 llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206 __netif_receive_skb_one_core net/core/dev.c:5527 [inline]
 __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5641 netif_receive_skb_internal net/core/dev.c:5727 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5786 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555 tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2020 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x8ef/0x1490 fs/read_write.c:584 ksys_write+0x20f/0x4c0 fs/read_write.c:637
 __do_sys_write fs/read_write.c:649 [inline] __se_sys_write fs/read_write.c:646 [inline]
 __x64_sys_write+0x93/0xd0 fs/read_write.c:646 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x63/0x6b Local variable daddr created at: llc_conn_handler+0x53/0x1360 net/llc/llc_conn.c:783 llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206 CPU: 1 PID: 5004 Comm: syz-executor994 Not tainted 6.6.0-syzkaller-14500-g1c41041124bd #0 ハードウェア名: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023 (CVE-2024-26635)

 - Linux カーネルで、次の脆弱性は解決されています。llc: llc_ui_sendmsg() を結合の変更に対してより堅牢にします。syzbot が llc_ui_sendmsg() を騙して、ヘッドルームなしで skb を割り当てましたが、その後、イーサネットヘッダーの 14 バイトのプッシュを試行する可能性があります。[1] 他のものと同様に、llc_ui_sendmsg() は sock_alloc_send_skb() を呼び出す前にソケットロックをリリースします。その後、再びそれを取得しますが、実行されたすべてのサニティチェックをやり直すわけではありません。この修正: - LL_RESERVED_SPACE() を使用してスペースを予約します。- ソケットロックが再び保持された後、すべての状態を再度チェックします。- イーサネットヘッダーを mtu 制限の対象にしません。[1] skbuff: skb_under_panic: text:ffff800088baa334 len:1514 put:14 head:ffff0000c9c37000 data:ffff0000c9c36ff2 tail:0x5dc end:0x6c0 dev:bond0 kernel BUG at net/core/skbuff.c:193 ! 内部エラー: Oops - BUG:
 00000000f2000800 [#1] リンクされた PREEMPT SMP モジュール: CPU: 0 PID: 6875 Comm: syz-executor.0 汚染されていない 6.7.0-rc8-syzkaller-00101-g0802e17d9aca-dirty #0 ハードウェア名: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : skb_panic net/core/skbuff.c:189 [inline] pc : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203 lr :
 skb_panic net/core/skbuff.c:189 [inline] lr : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203 sp :
 ffff800096f97000 x29: ffff800096f97010 x28: ffff80008cc8d668 x27: dfff800000000000 x26: ffff0000cb970c90 x25: 00000000000005dc x24: ffff0000c9c36ff2 x23: ffff0000c9c37000 x22: 00000000000005ea x21:
 00000000000006c0 x20: 000000000000000e x19: ffff800088baa334 x18: 1fffe000368261ce x17: ffff80008e4ed000 x16: ffff80008a8310f8 x15: 0000000000000001 x14: 1ffff00012df2d58 x13: 0000000000000000 x12:
 0000000000000000 x11: 0000000000000001 x10: 0000000000ff0100 x9 : e28a51f1087e8400 x8 : e28a51f1087e8400 x7 : ffff80008028f8d0 x6 : 0000000000000000 x5 : 0000000000000001 x4 : 0000000000000001 x3 :
 ffff800082b78714 x2 : 0000000000000001 x1 : 0000000100000000 x0 : 0000000000000089 Call trace: skb_panic net/core/skbuff.c:189 [inline] skb_under_panic+0x13c/0x140 net/core/skbuff.c:203 skb_push+0xf0/0x108 net/core/skbuff.c:2451 eth_header+0x44/0x1f8 net/ethernet/eth.c:83 dev_hard_header include/linux/netdevice.h:3188 [inline] llc_mac_hdr_init+0x110/0x17c net/llc/llc_output.c:33 llc_sap_action_send_xid_c+0x170/0x344 net/llc/llc_s_ac.c:85 llc_exec_sap_trans_actions net/llc/llc_sap.c:153 [inline] llc_sap_next_state net/llc/llc_sap.c:182 [inline] llc_sap_state_process+0x1ec/0x774 net/llc/llc_sap.c:209 llc_build_and_send_xid_pkt+0x12c/0x1c0 net/llc/llc_sap.c:270 llc_ui_sendmsg+0x7bc/0xb1c net/llc/af_llc.c:997 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] sock_sendmsg+0x194/0x274 net/socket.c:767 splice_to_socket+0x7cc/0xd58 fs/splice.c:881 do_splice_from fs/splice.c:933 [inline] direct_splice_actor+0xe4/0x1c0 fs/splice.c:1142 splice_direct_to_actor+0x2a0/0x7e4 fs/splice.c:1088 do_splice_direct+0x20c/0x348 fs/splice.c:1194 do_sendfile+0x4bc/0xc70 fs/read_write.c:1254
 __do_sys_sendfile64 fs/read_write.c:1322 [inline] __se_sys_sendfile64 fs/read_write.c:1308 [inline]
 __arm64_sys_sendfile64+0x160/0x3b4 fs/read_write.c:1308 __invoke_syscall arch/arm64/kernel/syscall.c:37 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:51 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:136 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:155 el0_svc+0x54/0x158 arch/arm64/kernel/entry-common.c:678 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:696 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:595 Code: aa1803e6 aa1903e7 a90023f5 94792f6a (d4210000) (CVE-2024-26636)

 - Linux カーネルで、次の脆弱性が解決されました。tcp: rx zerocopy にサニティチェックを追加します。TCP rx zerocopy の目的は、fs が所有するページではなく、NIC ドライバーから最初に割り当てられたページをマッピングすることです。このパッチは、can_map_frag() に以下の追加チェックを追加します。- ページは複合的なものであってはなりません。- page->mapping は NULL にする必要があります。これにより、ZhangPeng 氏により報告されたパニックが修正されます。syzbot は、sendfile() で構築されたパケットをループバックでき、ext4 ファイルが所有するページを TCP rx zerocopy にマッピングしていました。r3 = socket$inet_tcp(0x2, 0x1, 0x0) mmap(&(0x7f0000ff9000/0x4000)=nil, 0x4000, 0x0, 0x12, r3, 0x0) r4 = socket$inet_tcp(0x2, 0x1, 0x0) bind$inet(r4, &(0x7f0000000000)={0x2, 0x4e24, @multicast1}, 0x10) connect$inet(r4, &(0x7f00000006c0)={0x2, 0x4e24, @empty}, 0x10) r5 = openat$dir(0xffffffffffffff9c, &(0x7f00000000c0)='./file0\x00', 0x181e42, 0x0) fallocate(r5, 0x0, 0x0, 0x85b8) sendfile(r4, r5, 0x0, 0x8ba0) getsockopt$inet_tcp_TCP_ZEROCOPY_RECEIVE(r4, 0x6, 0x23, &(0x7f00000001c0)={&(0x7f0000ffb000/0x3000)=nil, 0x3000, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, &(0x7f0000000440)=0x40) r6 = openat$dir(0xffffffffffffff9c, &(0x7f00000000c0)='./file0\x00', 0x181e42, 0x0) (CVE-2024-26640)

 - Linux カーネルでは、次の脆弱性が解決されています。ip6_tunnel: __ip6_tnl_rcv() で内部ヘッダーを必ずプルしてください。 syzbot が、__ip6_tnl_rcv() が未利用のデータにアクセスする可能性があることを発見しました [1]。pskb_inet_may_pull() を呼び出してこれを修正し、skb->head を変更する可能性があるため、この呼び出しの後に ipv6h 変数を初期化してください。[1] バグ: KMSAN: __INET_ECN_decapsulate include/net/inet_ecn.h:253 の未初期化値 [インライン] バグ:
 KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] BUG: KMSAN: uninit-value in IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321 __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321 ip6ip6_dscp_ecn_decapsulate+0x178/0x1b0 net/ipv6/ip6_tunnel.c:727 __ip6_tnl_rcv+0xd4e/0x1590 net/ipv6/ip6_tunnel.c:845 ip6_tnl_rcv+0xce/0x100 net/ipv6/ip6_tunnel.c:888 gre_rcv+0x143f/0x1870 ip6_protocol_deliver_rcu+0xda6/0x2a60 net/ipv6/ip6_input.c:438 ip6_input_finish net/ipv6/ip6_input.c:483 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492 ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586 dst_input include/net/dst.h:461 [inline] ip6_rcv_finish+0x5db/0x870 net/ipv6/ip6_input.c:79 NF_HOOK include/linux/netfilter.h:314 [inline] ipv6_rcv+0xda/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5532 [inline]
 __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5646 netif_receive_skb_internal net/core/dev.c:5732 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5791 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555 tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2084 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0x786/0x1200 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643
 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline]
 __x64_sys_write+0x93/0xd0 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit was created at: slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [inline] kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560
 __alloc_skb+0x318/0x740 net/core/skbuff.c:651 alloc_skb include/linux/skbuff.h:1286 [inline] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2787 tun_alloc_skb drivers/net/tun.c:1531 [inline] tun_get_user+0x1e8a/0x66d0 drivers/net/tun.c:1846 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2084 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0x786/0x1200 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline]
 __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b CPU: 0 PID: 5034 Comm: syz-executor331 汚染されていない 6.7.0-syzkaller-00562-g9f8413c4a66f #0 ハードウェア名: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 (CVE-2024-26641)

 - Linux カーネルでは、次の脆弱性が解決されています。btrfs: 削除されたサブボリュームのスナップショットを作成しようとしても、ファイルシステムを中止しない スナップショット ioctl のソースファイル記述子が削除されたサブボリュームを参照している場合、次の中止が発生します。BTRFS: トランザクションが中止されました (エラー -2) 警告: CPU: 0 PID:
 833 at fs/btrfs/transaction.c:1875 create_pending_snapshot+0x1040/0x1190 [btrfs] リンクされたモジュール:
 pata_acpi btrfs ata_piix libata scsi_mod virtio_net blake2b_generic xor net_failover virtio_rng フェイルオーバー scsi_common rng_core raid6_pq libcrc32c CPU: 0 PID: 833 Comm: t_snapshot_dele Not tainted 6.7.0-rc6 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014 RIP:
 0010:create_pending_snapshot+0x1040/0x1190 [btrfs] RSP: 0018:ffffa09c01337af8 EFLAGS: 00010282 RAX:
 0000000000000000 RBX: ffff9982053e7c78 RCX: 0000000000000027 RDX: ffff99827dc20848 RSI: 0000000000000001 RDI: ffff99827dc20840 RBP: ffffa09c01337c00 R08: 0000000000000000 R09: ffffa09c01337998 R10:
 0000000000000003 R11: ffffffffb96da248 R12: fffffffffffffffe R13: ffff99820535bb28 R14: ffff99820b7bd000 R15: ffff99820381ea80 FS: 00007fe20aadabc0(0000) GS:ffff99827dc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000559a120b502f CR3: 00000000055b6000 CR4: 00000000000006f0 呼び出しトレース: <TASK> ? create_pending_snapshot+0x1040/0x1190 [btrfs] ? __warn+0x81/0x130 ? create_pending_snapshot+0x1040/0x1190 [btrfs] ? report_bug+0x171/0x1a0 ? handle_bug+0x3a/0x70 ? exc_invalid_op+0x17/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? create_pending_snapshot+0x1040/0x1190 [btrfs] ? create_pending_snapshot+0x1040/0x1190 [btrfs] create_pending_snapshots+0x92/0xc0 [btrfs] btrfs_commit_transaction+0x66b/0xf40 [btrfs] btrfs_mksubvol+0x301/0x4d0 [btrfs] btrfs_mksnapshot+0x80/0xb0 [btrfs] __btrfs_ioctl_snap_create+0x1c2/0x1d0 [btrfs] btrfs_ioctl_snap_create_v2+0xc4/0x150 [btrfs] btrfs_ioctl+0x8a6/0x2650 [btrfs] ? kmem_cache_free+0x22/0x340 ? do_sys_openat2+0x97/0xe0
 __x64_sys_ioctl+0x97/0xd0 do_syscall_64+0x46/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0x76 RIP:
 0033:0x7fe20abe83af RSP: 002b:00007ffe6eff1360 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX:
 ffffffffffffffda RBX: 0000000000000004 RCX: 00007fe20abe83af RDX: 00007ffe6eff23c0 RSI: 0000000050009417 RDI: 0000000000000003 RBP: 0000000000000003 R08: 0000000000000000 R09: 00007fe20ad16cd0 R10:
 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffe6eff13c0 R14: 00007fe20ad45000 R15: 0000559a120b6d58 </TASK> ---[ end trace 0000000000000000 ]--- BTRFS: create_pending_snapshot:1875: errno=-2 におけるエラー (デバイス vdc: 状態 A) そのようなエントリはありません BTRFS 情報 (デバイス vdc: 状態 EA): 読み取り専用を強制 BTRFS 警告 (デバイス vdc: 状態 EA): 中止されたトランザクションのコミットをスキップします。BTRFS:
cleanup_transaction:2055: errno=-2 におけるエラー (デバイス vdc: 状態 EA) そのようなエントリはありません。これは、create_pending_snapshot() が新しいルートアイテムをソースルートアイテムのコピーとして初期化するために発生します。これには refs フィールドが含まれ、削除されたサブボリュームでは 0 になります。したがって、btrfs_insert_root() への呼び出しは、refs == 0 の root を挿入します。btrfs_get_new_fs_root() は、root を見つけて、refs == 0 の場合に -ENOENT を返します。これにより、create_pending_snapshot() が中止されます。削除との競合を回避するために subvol_sem をロックした後、スナップショットを試行する前に、ソースルートの参照をチェックすることでこれを修正します。(CVE-2024-26644)

 - Linux カーネルでは、次の脆弱性が解決されました。トレース: 要素を tracing_map に挿入する際の可視性を確保します。マルチプロセッサの AArch64 マシンで次の 2 つのコマンドを並行して実行すると、重複ヒストグラムエントリについての予期しない警告が散発的に生成される可能性があります。$ while true; do echo hist:key=id.syscall:val=hitcount > \ /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/trigger cat /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/hist sleep 0.001 done $ stress-ng --sysbadaddr $(nproc) 警告は次のようになります。[ 2911.172474] ------------[ ここをカット ]------------ [ 2911.173111] 重複検出: 1 [ 2911.173574] 警告: CPU: 2 PID: 12247 at kernel/trace/tracing_map.c:983 tracing_map_sort_entries+0x3e0/0x408 [ 2911.174702] リンクされたモジュール: iscsi_ibft(E) iscsi_boot_sysfs(E) rfkill(E) af_packet(E) nls_iso8859_1(E) nls_cp437(E) vfat(E) fat(E) ena(E) tiny_power_button(E) qemu_fw_cfg(E) button(E) fuse(E) efi_pstore(E) ip_tables(E) x_tables(E) xfs(E) libcrc32c(E) aes_ce_blk(E) aes_ce_cipher(E) crct10dif_ce(E) polyval_ce(E) polyval_generic(E) ghash_ce(E) gf128mul(E) sm4_ce_gcm(E) sm4_ce_ccm(E) sm4_ce(E) sm4_ce_cipher(E) sm4(E) sm3_ce(E) sm3(E) sha3_ce(E) sha512_ce(E) sha512_arm64(E) sha2_ce(E) sha256_arm64(E) nvme(E) sha1_ce(E) nvme_core(E) nvme_auth(E) t10_pi(E) sg(E) scsi_mod(E) scsi_common(E) efivarfs(E) [ 2911.174738] アンロードされた汚染されたモジュール: cppc_cpufreq(E):1 [ 2911.180985] CPU:
 2 PID: 12247 Comm: cat Kdump: loaded Tainted: G E 6.7.0-default #2 1b58bbb22c97e4399dc09f92d309344f69c44a01 [ 2911.182398] ハードウェア名: Amazon EC2 c7g.8xlarge/, BIOS 1.0 11/1/2018 [ 2911.183208] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 2911.184038] pc : tracing_map_sort_entries+0x3e0/0x408 [ 2911.184667] lr : tracing_map_sort_entries+0x3e0/0x408 [2911.185310] sp : ffff8000a1513900 [ 2911.185750] x29: ffff8000a1513900 x28: ffff0003f272fe80 x27:
 0000000000000001 [ 2911.186600] x26: ffff0003f272fe80 x25: 0000000000000030 x24: 0000000000000008 [2911.187458] x23: ffff0003c5788000 x22: ffff0003c16710c8 x21: ffff80008017f180 [ 2911.188310] x20:
 ffff80008017f000 x19: ffff80008017f180 x18: ffffffffffffffff [ 2911.189160] x17: 0000000000000000 x16:
 0000000000000000 x15: ffff8000a15134b8 [ 2911.190015] x14: 0000000000000000 x13: 205d373432323154 x12:
 5b5d313131333731 [ 2911.190844] x11: 00000000fffeffff x10: 00000000fffeffff x9 : ffffd1b78274a13c [2911.191716] x8 : 000000000017ffe8 x7 : c0000000fffeffff x6 : 000000000057ffa8 [ 2911.192554] x5 :
 ffff0012f6c24ec0 x4 : 0000000000000000 x3 : ffff2e5b72b5d000 [ 2911.193404] x2 : 0000000000000000 x1 :
 0000000000000000 x0 : ffff0003ff254480 [ 2911.194259] Call trace: [ 2911.194626] tracing_map_sort_entries+0x3e0/0x408 [ 2911.195220] hist_show+0x124/0x800 [ 2911.195692] seq_read_iter+0x1d4/0x4e8 [ 2911.196193] seq_read+0xe8/0x138 [ 2911.196638] vfs_read+0xc8/0x300 [2911.197078] ksys_read+0x70/0x108 [ 2911.197534] __arm64_sys_read+0x24/0x38 [ 2911.198046] invoke_syscall+0x78/0x108 [ 2911.198553] el0_svc_common.constprop.0+0xd0/0xf8 [ 2911.199157] do_el0_svc+0x28/0x40 [ 2911.199613] el0_svc+0x40/0x178 [ 2911.200048] el0t_64_sync_handler+0x13c/0x158 [2911.200621] el0t_64_sync+0x1a8/0x1b0 [ 2911.201115] ---[ end trace 0000000000000000 ]--- この問題は、__tracing_map_insert() から発行された書き込みの CPU 順序変更が原因である可能性があります。この関数の特定のキーを持つ要素の存在のチェックは次のとおりです。val = READ_ONCE(entry->val); if (val && keys_match(key, val->key, map->key_size)) ... 新しいエントリの書き込みは次のとおりです。elt = get_free_elt(map);
 memcpy(elt->key, key, map->key_size); entry->val = elt; The memcpy(elt->key, key, map->key_size); および entry->val = elt; ストアが別の CPU で逆の順序で表示されるようになる可能性があります。この 2 番目の CPU は、新しいキーがすでに存在する val->key および subse と一致しないと誤って判断します
 ---truncated--- (CVE-2024-26645)

 - Linux カーネルでは、次の脆弱性が解決されています。drm/amd/display: DCN301 でストリームエンコーダー作成の境界チェックを実装します。「stream_enc_regs」配列は、dcn10_stream_enc_registers 構造体の配列です。この配列は、配列初期化子の stream_enc_regs() への 4 つの呼び出しに対応する 4 つの要素で初期化されます。これは、この配列の有効なインデックスが 0、1、2、3 であることを意味します。以下の「stream_enc_regs」4 <= 5 のエラーメッセージは、境界外であるインデックス 5 でこの配列にアクセスしようとする試みがあることを示しています。これにより、未定義の動作が引き起こされる可能性があります。ここでは、eng_id が、stream_enc_regs 配列にアクセスするためのインデックスとして使用されます。eng_id が 5 の場合、stream_enc_regs 配列で領域外アクセスが発生する可能性があります。したがって、Smatch によって報告された dcn301_stream_encoder_create のバッファオーバーフローエラーを修正します。
 drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn301/dcn301_resource.c:1011 dcn301_stream_encoder_create() エラー: バッファオーバーフロー 'stream_enc_regs' 4 <= 5 (CVE-2024-26660)

 - Linux カーネルでは、次の脆弱性が解決されています。tipc: tipc_udp_nl_bearer_add() を呼び出す前にベアラータイプをチェックします syzbot が以下の一般保護違反 [1] を報告しました。一般保護違反、おそらく非標準アドレス 0xdffffc0000000010: 0000 [#1] PREEMPT SMP KASAN KASAN: NULL ポインターデリファレンスの範囲 [0x0000000000000080-0x0000000000000087] ... RIP:
 0010:tipc_udp_is_known_peer+0x9c/0x250 net/tipc/udp_media.c:291 ... 呼び出しトレース: <TASK> tipc_udp_nl_bearer_add+0x212/0x2f0 net/tipc/udp_media.c:646 tipc_nl_bearer_add+0x21e/0x360 net/tipc/bearer.c:1089 genl_family_rcv_msg_doit+0x1fc/0x2e0 net/netlink/genetlink.c:972 genl_family_rcv_msg net/netlink/genetlink.c:1052 [inline] genl_rcv_msg+0x561/0x800 net/netlink/genetlink.c:1067 netlink_rcv_skb+0x16b/0x440 net/netlink/af_netlink.c:2544 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1076 netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x53b/0x810 net/netlink/af_netlink.c:1367 netlink_sendmsg+0x8b7/0xd70 net/netlink/af_netlink.c:1909 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0xd5/0x180 net/socket.c:745 ____sys_sendmsg+0x6ac/0x940 net/socket.c:2584 ___sys_sendmsg+0x135/0x1d0 net/socket.c:2638 __sys_sendmsg+0x117/0x1e0 net/socket.c:2667 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b この問題の原因は、tipc_nl_bearer_add() が TIPC_NLA_BEARER_UDP_OPTS 属性で呼び出される場合、tipc_udp_nl_bearer_add() がベアラーが UDP でなくても呼び出されることです。tipc_udp_nl_bearer_add() によって呼び出される tipc_udp_is_known_peer() は、tipc_bearer の media_ptr フィールドに udp_bearer タイプのオブジェクトがあると想定するため、非 UDP ベアラーに対して関数が異常になります。このパッチは、tipc_nl_bearer_add() で tipc_udp_nl_bearer_add() を呼び出す前にベアラータイプをチェックすることで、問題を修正します。(CVE-2024-26663)

 - Linux カーネルでは、以下の脆弱性が解決されています。hwmon: (coretemp) 領域外メモリアクセスを修正します 領域外チェックの前に pdata->cpu_map[] が設定されるバグを修正します。この問題は、パッケージあたりのコア数が 128 を超えるシステムで発生する可能性があります。(CVE-2024-26664)

 - Linux カーネルで、次の脆弱性が解決されています。tunnels: IPv6 PMTU エラーを構築する際の領域外アクセスを修正します。ICMPv6 エラーが非線形 skb から構築されている場合、次のスプラットを取得します。バグ: KASAN: do_csum+0x220/0x240 のスラブ領域外。 addr ffff88811d402c80 で netperf/820 によるサイズ 4 の読み取り CPU: 0 PID: 820 Comm: netperf Not tainted 6.8.0-rc1+ ... kasan_report+#5430xd8/0x110 do_csum+0x220/0x240 csum_partial+0xc/0x20 skb_tunnel_check_pmtu+0xeb9/0x3280 vxlan_xmit_one+0x14c2/0x4080 vxlan_xmit+0xf61/0x5c00 dev_hard_start_xmit+0xfb/0x510 __dev_queue_xmit+0x7cd/0x32a0 br_dev_queue_push_xmit+0x39d/0x6a0 非線形 SKB に対処できない csum_partial の代わりに skb_checksum を使用してください。(CVE-2024-26665)

 - Linux カーネルで、以下の脆弱性が解決されています。netfilter: nft_limit: 整数オーバーフローを引き起こす構成を拒否します。内部トークンカウンターがラップアラウンドする偽の構成を拒否します。
 これは、17gbyte/s などの非常に大きなリクエストでのみ発生します。不適切なレート制限を持つよりも、これを拒否したほうが良いです。(CVE-2024-26668)

 - Linux カーネルで、次の脆弱性が解決されています。blk-mq: sbitmap ウェイクアップ競合からの IO ハングアップを修正します blk_mq_mark_tag_wait() で、__add_wait_queue() が、ドライバータグエラーを取得する場合に、次の blk_mq_get_driver_tag() で再オーダーされる可能性があります。次に、__sbitmap_queue_wake_up() で、waitqueue_active() は blk_mq_mark_tag_wait() に追加された waiter を監視せず、何もウェイクアップしない可能性があります。その間、blk_mq_mark_tag_wait() はドライバータグを正常に取得できません。この問題は、次のテストをループで実行することで再現でき、fio のハングアップは、ラップトップのテスト VM で実行すると 30 分未満で発生します。modprobe -r scsi_debug modprobe scsi_debug delay=0 dev_size_mb=4096 max_queue=1 host_max_queue=1 submit_queues=4 dev=`ls -d /sys/bus/pseudo/drivers/scsi_debug/adapter*/host*/target*/*/block/* | head -1 | xargs basename` fio --filename=/dev/$dev --direct=1 --rw=randrw --bs=4k --iodepth=1 \ --runtime=100
 --numjobs=40 --time_based --name=test \ --ioengine=libaio blk_mq_mark_tag_wait() に 1 つの明示的なバリアを追加することで問題を修正します。タグがなくなった場合でも問題ありません。(CVE-2024-26671)

 - Linux カーネルで、次の脆弱性が解決されました。netfilter: nft_ct: カスタムの期待値でレイヤー 3 と 4 のプロトコル番号をサニタイズします - NFPROTO_{IPV4,IPV6,INET} 以外のファミリーを許可しません。- 宛先ポートがこのオブジェクトの必須属性であるため、ポートのないレイヤー 4 プロトコルを許可しません。
 (CVE-2024-26673)

 - Linux カーネルで、次の脆弱性が解決されています。ppp_async: MRU を 64K に制限します syzbot が __alloc_pages(): WARN_ON_ONCE_GFP(order > MAX_PAGE_ORDER, gfp) で警告 [1] をトリガーしました Willem がコミット c0a2a1b0d631 の同様の問題を修正しました (ppp: MRU を 64K に制限) ppp_async_ioctl(PPPIOCSMRU) に同じサニティチェックを採用してください [1]: 警告: CPU: 1 PID: 11 at mm/page_alloc.c:4543 __alloc_pages+0x308/0x698 mm/page_alloc.c:45433 リンクされたモジュール: CPU: 1 PID: 11 Comm: kworker/u4:0 汚染されていない 6.8.0-rc2-syzkaller-g41bccc98fb79 #0 ハードウェア名: Google Google Compute Engine/Google Compute Engine、BIOS Google 2023 年 11 月 17 日 Workqueue: events_unbound flush_to_ldisc pstate: 204000c5 (nzCv daIF +PAN -UAO -TCO
 -DIT -SSBS BTYPE=--) pc : __alloc_pages+0x308/0x698 mm/page_alloc.c:4543 lr : __alloc_pages+0xc8/0x698 mm/page_alloc.c:4537 sp : ffff800093967580 x29: ffff800093967660 x28: ffff8000939675a0 x27:
 dfff800000000000 x26: ffff70001272ceb4 x25: 0000000000000000 x24: ffff8000939675c0 x23: 0000000000000000 x22: 0000000000060820 x21: 1ffff0001272ceb8 x20: ffff8000939675e0 x19: 0000000000000010 x18:
 ffff800093967120 x17: ffff800083bded5c x16: ffff80008ac97500 x15: 0000000000000005 x14: 1ffff0001272cebc x13: 0000000000000000 x12: 0000000000000000 x11: ffff70001272cec1 x10: 1ffff0001272cec0 x9 :
 0000000000000001 x8 : ffff800091c91000 x7 : 0000000000000000 x6 : 000000000000003f x5 : 00000000ffffffff x4 : 0000000000000000 x3 : 0000000000000020 x2 : 0000000000000008 x1 : 0000000000000000 x0 :
 ffff8000939675e0 Call trace: __alloc_pages+0x308/0x698 mm/page_alloc.c:4543 __alloc_pages_node include/linux/gfp.h:238 [inline] alloc_pages_node include/linux/gfp.h:261 [inline]
 __kmalloc_large_node+0xbc/0x1fc mm/slub.c:3926 __do_kmalloc_node mm/slub.c:3969 [inline]
 __kmalloc_node_track_caller+0x418/0x620 mm/slub.c:4001 kmalloc_reserve+0x17c/0x23c net/core/skbuff.c:590
 __alloc_skb+0x1c8/0x3d8 net/core/skbuff.c:651 __netdev_alloc_skb+0xb8/0x3e8 net/core/skbuff.c:715 netdev_alloc_skb include/linux/skbuff.h:3235 [inline] dev_alloc_skb include/linux/skbuff.h:3248 [inline] ppp_async_input drivers/net/ppp/ppp_async.c:863 [inline] ppp_asynctty_receive+0x588/0x186c drivers/net/ppp/ppp_async.c:341 tty_ldisc_receive_buf+0x12c/0x15c drivers/tty/tty_buffer.c:390 tty_port_default_receive_buf+0x74/0xac drivers/tty/tty_port.c:37 receive_buf drivers/tty/tty_buffer.c:444 [inline] flush_to_ldisc+0x284/0x6e4 drivers/tty/tty_buffer.c:494 process_one_work+0x694/0x1204 kernel/workqueue.c:2633 process_scheduled_works kernel/workqueue.c:2706 [inline] worker_thread+0x938/0xef4 kernel/workqueue.c:2787 kthread+0x288/0x310 kernel/kthread.c:388 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860 (CVE-2024-26675)

 - Linux カーネルで、以下の脆弱性は解決されています。af_unix: GC で機能していない unix_(sk)->oob_skb に対して、kfree_skb() を呼び出します。syzbot が、__unix_gc() で警告 [0] を報告しました。その再現は、syzbot がソケットペアを作成し、ピアを使用して 1 つのソケットの fd をそれ自体に送信します。socketpair(AF_UNIX, SOCK_STREAM, 0, [3, 4]) = 0 sendmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base=\360, iov_len=1}], msg_iovlen=1, msg_control=[{cmsg_len=20, cmsg_level=SOL_SOCKET, cmsg_type=SCM_RIGHTS, cmsg_data=[3]}], msg_controllen=24, msg_flags=0}, MSG_OOB|MSG_PROBE|MSG_DONTWAIT|MSG_ZEROCOPY) = 1 これは、循環参照を形成し、GC は最終的にもつれを解消する必要がありますが、MSG_OOB 処理の不足により解消できず、メモリリークが発生します。最近、コミット 11498715f266 (af_unix: GC の io_uring コードを削除します) により、GC の io_uring のデッドコードが削除され、問題が明らかになりました。コードが GC の最終段階で実行され、すべての GC 候補を無条件で gc_candidates から gc_inflight_list に移動しました。それは、後続の WARN_ON_ONCE(!list_empty(&gc_candidates)) を常に false にすることで、報告された問題を上書きしました。この問題は、コミット 2aab4b969002 (af_unix: OOB サポートでの struct pid 漏洩の修正) が MSG_OOB に完全な scm サポートを追加し、別のバグを修正してから存在しています。この問題を修正するには、収集された skb をパージした後にソケットがまだ gc_candidates に存在する場合、unix_sk(sk)->oob_skb に対して kfree_skb() を呼び出す必要があります。次に、kfree_skb() を呼び出す前に、oob_skb に NULL を設定する必要があります。これは、最後の fput() を呼び出し、unix_release_sock() をトリガーするためです。NULL でない場合は、重複した kfree_skb(u->oob_skb) を呼び出します。注意: 漏洩されたソケットはグローバルリストにリンクされたままであるため、kmemleak もこれを検出できませんでした。/proc/net/protocol をチェックして、解放されたソケットに気付く必要があります。[0]: 警告: CPU: 0 PID: 2863 at net/unix/garbage.c:345
 __unix_gc+0xc74/0xe80 net/unix/garbage.c:345 リンクされたモジュール: CPU: 0 PID: 2863 Comm: kworker/u4:11 汚染されていない 6.8.0-rc1-syzkaller-00583-g1701940b1a02 #0 ハードウェア名 [b1a02] Google Google Compute Engine/Google Compute Engine、BIOS Google 2024 年 1 月 25 日 Workqueue: events_unbound __unix_gc RIP: 0010:__unix_gc+0xc74/0xe80 net/unix/garbage.c:345 コード: 8b 5c 24 50 e9 86 f8 ff ff e8 f8 e4 22 f8 31 d2 48 c7 c6 30 6a 69 89 4c 89 ef e8 97 ef ff ff e9 80 f9 ff ff e8 dd e4 22 f8 90 <0f> 0b 90 e9 7b fd ff ff 48 89 df e8 5c e7 7c f8 e9 d3 f8 ff ff e8 RSP: 0018:ffffc9000b03fba0 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffffc9000b03fc10 RCX:
 ffffffff816c493e RDX: ffff88802c02d940 RSI: ffffffff896982f3 RDI: ffffc9000b03fb30 RBP: ffffc9000b03fce0 R08: 0000000000000001 R09: fffff52001607f66 R10: 0000000000000003 R11: 0000000000000002 R12:
 dffffc0000000000 R13: ffffc9000b03fc10 R14: ffffc9000b03fc10 R15: 0000000000000001 FS:
 0000000000000000(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0:
 0000000080050033 CR2: 00005559c8677a60 CR3: 000000000d57a000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
 0000000000000400 呼び出しトレース: <TASK> process_one_work+0x889/0x15e0 kernel/workqueue.c:2633 process_scheduled_works kernel/workqueue.c:2706 [inline] worker_thread+0x8b9/0x12a0 kernel/workqueue.c:2787 kthread+0x2c6/0x3b0 kernel/kthread.c:388 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:242 </TASK> (CVE-2024-26676)

 - Linux カーネルで、次の脆弱性は解決されています。inet: inet_recv_error() で sk->sk_family を 1 回読み込みます。inet_recv_error() が、ソケットロックを保持せずに呼び出されます。IPv6 ソケットが、IPV6_ADDRFORM ソケットオプション付きの IPv4 に変異し、KCSAN 警告を発生させる可能性があります。(CVE-2024-26679)

 - Linux カーネルでは、次の脆弱性が解決されています。net: stmmac: xgmac: DMA チャネルの DPP 安全性エラーの処理を修正します Commit 56e58d6c8a56 (net: stmmac: XGMAC の安全機能を実装) は安全性エラーをチェックおよび報告しますが、DMAの各チャネルのデータパスパリティエラーがまったく処理されず、割り込みのストームを引き起こします。DMA_DPP_Interrupt_Status レジスターをチェックしてクリアすることで修正します。(CVE-2024-26684)

 - Linux カーネルで、次の脆弱性が解決されています。nilfs2: end_buffer_async_write の潜在的なバグを修正します syzbot レポートによると、ブロックデバイスの書き込みの完了を処理する end_buffer_async_write() が、バッファ async_write フラグの異常状態を検出し、 nilfs2 を使用する際の BUG_ON の失敗を引き起こします。Nilfs2 自体は end_buffer_async_write() を使用しません。ただし、async_write フラグは現在、nilfs_lookup_dirty_data_buffers() および nilfs_lookup_node_buffers() およびその結果生じるクラッシュにおけるダーティブロックの二重リスト挿入を解決する手段として、コミット 7f42ec394156 (nilfs2: ダーティブロックに対するセグメント間の競合状態の修正) によりマーカーとして使用されています。この変更は、ページキャッシュが独立しているファイルデータと b ツリーノードブロックに使用される限り安全です。ただし、セグメントサマリーおよびバッキングデバイスとバッファを共有するスーパールートブロックに async_write を導入することは、無関係かつ冗長でした。これにより、バッキングデバイスの独立したライトバックが並行して発生する場合、end_buffer_async_write の BUG_ON チェックが上記のように失敗する可能性がありました。セグメントサマリーバッファに対する async_write の使用は、以前の変更ですでに削除されています。残りのスーパールートブロックバッファに対する async_write フラグの操作を削除することで、この問題を修正します。(CVE-2024-26685)

 - Linux カーネルで、次の脆弱性が解決されました。ceph: encode_cap_msg() でメモリ解放後使用 (Use After Free) を防止します fs/ceph/caps.c、encode_cap_msg() で、この行で KASAN によるメモリ解放後使用 (Use After Free) エラーがキャッチされました - 「ceph_buffer_get(arg->xattr_buf);」。これは、refcount がここでインクリメントされる前に、refcount が解放されたことを意味します。同じファイルで、handle_cap_grant() の refcount はこの行によって減らされます - 「ceph_buffer_put(ci->i_xattrs.blob);」。前者の行が増加する前に、競合が発生し、後者の行によってリソースが解放されたようです。 encode_cap_msg() が __send_cap() により呼び出され、
 __send_cap() は、__prep_cap() の呼び出し後に ceph_check_caps() により呼び出されます。 __prep_cap() は、arg->xattr_buf が ci->i_xattrs.blob に割り当てられている場所です。これは、メモリ解放後使用 (Use After Free) エラーを防ぐために refcount を増やす必要がある箇所です。 (CVE-2024-26689)

 - Linux カーネルでは、以下の脆弱性が解決されています。 crypto: ccp - __sev_platform_shutdown_locked の null ポインターデリファレンスを修正します。たとえば、DEBUG_TEST_DRIVER_REMOVE を使用して、SEV プラットフォームデバイスを null psp_master でシャットダウンできます。KASAN を使用して見つかりました: [ 137.148210] ccp 0000:23:00.1:
 デバイスの有効化 (0000 -> 0002) [ 137.162647] ccp 0000:23:00.1: 利用可能なコマンドキューがありません [ 137.170598] ccp 0000:23:00.1: 重大な脆弱性が有効化 [ 137.174645] ccp 0000:23:00.1: psp が有効化 [ 137.178890] 一般保護違反、おそらく非標準アドレス 0xdffffc000000001e: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN NOPTI [ 137.182693] KASAN: NULLポインターデリファレンスの範囲 [0x00000000000000f0-0x00000000000000f7] [ 137.182693] CPU: 93 PID: 1 Comm: swapper/0 汚染なし 6.8.0-rc1+ #311 [ 137.182693] RIP:
 0010:__sev_platform_shutdown_locked+0x51/0x180 [ 137.182693] コード: 08 80 3c 08 00 0f 85 0e 01 00 00 48 8b 1d 67 b6 01 08 48 b8 00 00 00 00 00 fc ff df 48 8d bb f0 00 00 00 48 89 f9 48 c1 e9 03 <80> 3c 01 00 0f 85 fe 00 00 00 48 8b 9b f0 00 00 00 48 85 db 74 2c [ 137.182693] RSP: 0018:ffffc900000cf9b0 EFLAGS: 00010216 [ 137.182693] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 000000000000001e [ 137.182693] RDX:
 0000000000000000 RSI: 0000000000000008 RDI: 00000000000000f0 [ 137.182693] RBP: ffffc900000cf9c8 R08:
 0000000000000000 R09: fffffbfff58f5a66 [ 137.182693] R10: ffffc900000cf9c8 R11: ffffffffac7ad32f R12:
 ffff8881e5052c28 [ 137.182693] R13: ffff8881e5052c28 R14: ffff8881758e43e8 R15: ffffffffac64abf8 [137.182693] FS: 0000000000000000(0000) GS:ffff889de7000000(0000) knlGS:0000000000000000 [ 137.182693] CS:
 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 137.182693] CR2: 0000000000000000 CR3: 0000001cf7c7e000 CR4: 0000000000350ef0 [ 137.182693] Call Trace: [ 137.182693] <TASK> [ 137.182693] ? show_regs+0x6c/0x80 [137.182693] ? __die_body+0x24/0x70 [ 137.182693] ? die_addr+0x4b/0x80 [ 137.182693] ? exc_general_protection+0x126/0x230 [ 137.182693] ? asm_exc_general_protection+0x2b/0x30 [ 137.182693] ?
 __sev_platform_shutdown_locked+0x51/0x180 [ 137.182693] sev_firmware_shutdown.isra.0+0x1e/0x80 [137.182693] sev_dev_destroy+0x49/0x100 [ 137.182693] psp_dev_destroy+0x47/0xb0 [ 137.182693] sp_destroy+0xbb/0x240 [ 137.182693] sp_pci_remove+0x45/0x60 [ 137.182693] pci_device_remove+0xaa/0x1d0 [137.182693] device_remove+0xc7/0x170 [ 137.182693] really_probe+0x374/0xbe0 [ 137.182693] ? srso_return_thunk+0x5/0x5f [ 137.182693] __driver_probe_device+0x199/0x460 [ 137.182693] driver_probe_device+0x4e/0xd0 [ 137.182693] __driver_attach+0x191/0x3d0 [ 137.182693] ?
 __pfx___driver_attach+0x10/0x10 [ 137.182693] bus_for_each_dev+0x100/0x190 [ 137.182693] ?
 __pfx_bus_for_each_dev+0x10/0x10 [ 137.182693] ? __kasan_check_read+0x15/0x20 [ 137.182693] ? srso_return_thunk+0x5/0x5f [ 137.182693] ? _raw_spin_unlock+0x27/0x50 [ 137.182693] driver_attach+0x41/0x60 [ 137.182693] bus_add_driver+0x2a8/0x580 [ 137.182693] driver_register+0x141/0x480 [ 137.182693] __pci_register_driver+0x1d6/0x2a0 [ 137.182693] ? srso_return_thunk+0x5/0x5f [ 137.182693] ? esrt_sysfs_init+0x1cd/0x5d0 [ 137.182693] ? __pfx_sp_mod_init+0x10/0x10 [ 137.182693] sp_pci_init+0x22/0x30 [ 137.182693] sp_mod_init+0x14/0x30 [ 137.182693] ? __pfx_sp_mod_init+0x10/0x10 [137.182693] do_one_initcall+0xd1/0x470 [ 137.182693] ? __pfx_do_one_initcall+0x10/0x10 [ 137.182693] ? parameq+0x80/0xf0 [ 137.182693] ? srso_return_thunk+0x5/0x5f [ 137.182693] ? __kmalloc+0x3b0/0x4e0 [137.182693] ? kernel_init_freeable+0x92d/0x1050 [ 137.182693] ? kasan_populate_vmalloc_pte+0x171/0x190 [137.182693] ? srso_return_thunk+0x5/0x5f [ 137.182693] kernel_init_freeable+0xa64/0x1050 [ 137.182693] ?
 __pfx_kernel_init+0x10/0x10 [ 137.182693] kernel_init+0x24/0x160 [ 137.182693] ? __switch_to_asm+0x3e/0x70 [ 137.182693] ret_from_fork+0x40/0x80 [ 137.182693] ? __pfx_kernel_init+0x1 ---truncated--- (CVE-2024-26695)

 - Linux カーネルで、次の脆弱性が解決されています。nilfs2: nilfs_lookup_dirty_data_buffers() でのハングアップを修正します。Syzbot は、nilfs2 のログライターで呼び出される mbind() および nilfs_lookup_dirty_data_buffers() によって呼び出される migrate_pages_batch() のハングアップの問題があることを報告しました。migrate_pages_batch() が folio をロックし、書き戻しが完了するまで待機しますが、書き戻しを完了させるログライタースレッドが、その後のログ作成のために呼び出し、書き込みをロックしようとしていた nilfs_lookup_dirty_data_buffers() で書き戻されている Folio を選択します。したがって、デッドロックを引き起こします。ライトバック処理中の folio/ページが更新されダーティになることは、まず想定外です。
 Nilfs2 は、書き込まれているログの有効性を検証するためのチェックサムを追加し、それをマウント時のリカバリに使用するため、ライトバック中のデータ変更が抑制されます。これは破損しているため、クリーンでないシャットダウンによってリカバリが失敗する可能性があります。調査の結果、根本的な原因は、nilfs_page_mkwrite() のライトバック完了の待機が条件付きであり、バッキングデバイスが安定した書き込みを必要としない場合、待機なしでデータが変更されることであることが判明しました。バッキングデバイスの安定した書き込み要件に関係なく、ライトバックが完了するまで nilfs_page_mkwrite() を待機させることで、これらの問題を修正します。(CVE-2024-26696)

 - Linux カーネルで、以下の脆弱性が解決されています。nilfs2: 小さなブロックサイズの dsync ブロックリカバリのデータ破損を修正します クリーンでないシャットダウンの後にデータの同期書き込みにより作成されたログからのデータを復元する nilfs_recovery_dsync_blocks() のヘルパー関数 nilfs_recovery_copy_block() は、修復データをファイルのページキャッシュにコピーするときに、オンページオフセットを間違って計算します。ブロックサイズがページサイズよりも小さい環境では、この欠陥によりデータ破損が引き起こされ、復元プロセス中に初期化されていないメモリバイトが漏洩する可能性があります。ページ上のこのバイトオフセット計算を修正することで、これらの問題を修正します。(CVE-2024-26697)

 - Linux カーネルにおいて、次の脆弱性が解決されています。hv_netvsc: netvsc_probe と netvsc_remove の間の競合状態を修正します。コミット ac5047671758 (hv_netvsc: VMBus チャネルを閉じる前に NAPI を無効化) で、napi_disable が有効になっているかどうかを確認せずに全サブチャネルを含む全チャネルに対して呼び出されていました。これにより、netvsc_probe() の実行は終了したが nvdev->subchan_work がまだ起動していない場合に、hv_netvsc が napi_disable でハングしていました。netvsc_subchan_work() -> rndis_set_subchannel() はサブチャネルを作成しておらず、そのために netvsc_sc_open() は実行されていません。netvsc_remove() は、cancel_work_sync(&nvdev->subchan_work) を呼び出しますが、これに対して netvsc_subchan_work は実行されません。netif_napi_add() は、NAPI をスケジュールできないようにするため、ビット NAPI_STATE_SCHED を設定します。その後、netvsc_sc_open() -> napi_enable は NAPIF_STATE_SCHED ビットをクリアするため、スケジュールすることができます。
 napi_disable() はその逆を行います。現在は、netvsc_device_remove() 中に、これらのサブチャネルに対して napi_disable が呼び出されると、napi_disable が無限 msleep でスタックします。この修正では、napi_disable() が有効になっていない NAPI 構造体に対して呼び出されないようにすることで、この問題に対処しています。ただし、クリーンアップの目的で、これらの有効化されていない NAPI 構造に対して netif_napi_del() が依然として必要です。呼び出しトレース: [ 654.559417] task:modprobe state:D stack: 0 pid: 2321 ppid: 1091 flags:0x00004002 [ 654.568030] 呼び出しトレース: [ 654.571221] <TASK> [654.573790] __schedule+0x2d6/0x960 [ 654.577733] schedule+0x69/0xf0 [ 654.581214] schedule_timeout+0x87/0x140 [ 654.585463] ? __bpf_trace_tick_stop+0x20/0x20 [ 654.590291] msleep+0x2d/0x40 [ 654.593625] napi_disable+0x2b/0x80 [ 654.597437] netvsc_device_remove+0x8a/0x1f0 [hv_netvsc] [654.603935] rndis_filter_device_remove+0x194/0x1c0 [hv_netvsc] [ 654.611101] ? do_wait_intr+0xb0/0xb0 [654.615753] netvsc_remove+0x7c/0x120 [hv_netvsc] [ 654.621675] vmbus_remove+0x27/0x40 [hv_vmbus] (CVE-2024-26698)

 - Linux カーネルでは、次の脆弱性が解決されています。iio: magnetometer: rm3100: RM3100_REG_TMRC から読み取られた値の境界検査を追加します 最近、配列 rm3100_samp_rates の領域外アクセスにより引き起こされた関数 rm3100_common_probe でカーネルクラッシュに遭遇しました (下層にあるハードウェア障害が原因)。領域外アクセスを防ぐために境界検査を追加します。(CVE-2024-26702)

 - Linux カーネルでは、以下の脆弱性が解決されています。ext4: 不適切なエクステントにより発生するブロックのダブルフリーを修正します。move_len ext4_move_extents() で、moved_len はすべての move が正常に実行された場合にのみ更新され、move_len がゼロでない場合にのみ、orig_inode および donor_inode の事前割り当てを破棄します。一部のエクステントを正常に移動した後にループの終了に失敗した場合、moved_len は更新されずに 0 のままになるため、事前割り当てを破棄しません。移動されたエクステントが事前に割り当てられたエクステントと重複する場合、重複したエクステントは ext4_mb_release_inode_pa() および ext4_process_freed_data() で 2 回解放され (コミット 94d7c16cbbbd (ext4: EXT4_IOC_MOVE_EXT でブロックの二重解放を修正) に記載されているとおり)、bb_free が 2 回インクリメントされます。したがって、trim が実行されると、bb_free がゼロではなく bb_fragments がゼロであるため、mb_update_avg_fragment_size() でゼロ除算バグがトリガーされます。したがって、この問題を回避するには、エクステントを移動するたびに move_len を更新してください。(CVE-2024-26704)

 - Linux カーネルで、次の脆弱性が解決されています。net: hsr: send_hsr_supervision_frame() の WARN_ONCE() を削除します。Syzkaller は、hsr_init_skb() で skb にリソースを割り当てられなかった後に、警告が表示される [1] と報告しました。この場合 WARN_ONCE() 呼び出しはあまり役に立たないため、netdev_warn_once() に切り替えるのが賢明かもしれません。少なくとも、[1] のような syzkaller レポートを抑制します。念のため、同様の理由で send_prp_supervision_frame() で netdev_warn_once() を使用してください。[1] HSR: 監視フレームを送信できませんでした。警告: CPU: 1 PID: 85 at net/hsr/hsr_device.c:294 send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294 RIP:
 0010:send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294 ... 呼び出しトレース: <IRQ> hsr_announce+0x114/0x370 net/hsr/hsr_device.c:382 call_timer_fn+0x193/0x590 kernel/time/timer.c:1700 expire_timers kernel/time/timer.c:1751 [inline] __run_timers+0x764/0xb20 kernel/time/timer.c:2022 run_timer_softirq+0x58/0xd0 kernel/time/timer.c:2035 __do_softirq+0x21a/0x8de kernel/softirq.c:553 invoke_softirq kernel/softirq.c:427 [inline] __irq_exit_rcu kernel/softirq.c:632 [inline] irq_exit_rcu+0xb7/0x120 kernel/softirq.c:644 sysvec_apic_timer_interrupt+0x95/0xb0 arch/x86/kernel/apic/apic.c:1076 </IRQ> <TASK> asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:649 ... この問題は、古いカーネルでも見つかりました (少なくとも 5.10 まで)。
 (CVE-2024-26707)

 - Linux カーネルで、次の脆弱性が解決されています。powerpc/kasan: ページアラインメントによって引き起こされる addr エラーを修正します kasan_init_region で、k_start がページアラインされていないとき、for ループの開始で、k_cur = k_start & PAGE_MASK が k_start 未満であり、「va = block + k_cur - k_start」が block より小さい場合、va からブロックへのメモリアドレス空間が memblock_alloc によって割り当てられていないため、アドレス va は無効です。これは、後に memblock_reserve によって予約されず、他の場所で使用されています。その結果、メモリの上書きが発生します。例: int __init __weak kasan_init_region(void *start, size_t size) { [...] /* if say block(dcd97000) k_start(feef7400) k_end(feeff3fe) */ block = memblock_alloc(k_end
 - k_start, PAGE_SIZE); [...] for (k_cur = k_start & PAGE_MASK; k_cur < k_end; k_cur += PAGE_SIZE) { /* at the begin of for loop * block(dcd97000) va(dcd96c00) k_cur(feef7000) k_start(feef7400) * va(dcd96c00) is less than block(dcd97000), va is invalid */ void *va = block + k_cur - k_start; [...] } [...] } したがって、VA アドレスの有効性を保証するために、memblock_alloc() の前に k_start でページアライメントが実行されます。
 (CVE-2024-26712)

 - Linux カーネルで、次の脆弱性が解決されています。usb: dwc3: gadget: dwc3_gadget_suspend の NULL ポインターデリファレンスを修正します。現在のシナリオでプラグアウトとプラグインが継続的に実行されると、dwc->gadget_driver のチェック中に可能性があります dwc3_gadget_suspend で、NULL ポインターデリファレンスが発生する可能性があります。呼び出しスタック: CPU1: CPU2: gadget_unbind_driver dwc3_suspend_common dwc3_gadget_stop dwc3_gadget_suspend dwc3_disconnect_gadget CPU1 は基本的に変数を消去し、CPU2 は変数をチェックします。CPU1 は gadget_driver がクリアされる直前と実行中であると見なし、CPU2 は dwc3_gadget_suspend を実行します。ここで、NULL ではない dwc->gadget_driver を見つけて実行を再開し、CPU1 は実行を完了します。CPU2 は dwc3_disconnect_gadget を実行します。この場合、dwc->gadget_driver がすでに NULL であることを確認するため、NULL ポインターデリファレンスが発生します。(CVE-2024-26715)

 - Linux カーネルで、次の脆弱性が解決されています。HID: i2c-hid-of: 失敗した電源投入時の NULL-deref を修正します。しばらく前に I2C HID 実装は ACPI および OF 部分に分割されましたが、新しい OF ドライバーは、電源投入の失敗時に逆参照されるクライアントポインターを決して初期化しません。(CVE-2024-26717)

 - Linux カーネルでは、次の脆弱性は解決されています。mm/writeback: wb_dirty_limits() でのゼロ除算を修正します (struct dirty_throttle_control *)->thresh は符号なし long ですが、u32 除数引数を div_u64() に渡します。unsigned long が 64 バイトのアーキテクチャでは、引数は暗黙のうちに切り捨てられます。安全な除算チェックで使用される値が除数と同じになるように、div_u64() の代わりに div64_u64() を使用します。また、u64 への分子の冗長なキャストを削除します。これは暗黙のうちに発生するはずです。これは、domain_drity_limits() が使用する比率ベースの算術演算を考慮すると、memcg ドメインで悪用するのは困難ですが、たとえば vm.dirty_bytes=(1<<32)*PAGE_SIZE を使用して dtc->thresh == (1<<32) とする、BDI_CAP_STRICTLIMIT バッキングデバイスを備えたグローバルなライトバックドメインでははるかに簡単です。(CVE-2024-26720)

 - Linux カーネルでは、次の脆弱性が解決されています。ASoC: rt5645: rt5645_jack_detect_work() のデッドロックを修正します rt5645_jack_detect_work() に、rt5645->jd_mutex が永久にロックされたままになるパスがあります。これにより、rt5645_jack_detect_work() が 2 回目に呼び出されたときにデッドロックが発生する可能性があります。
 SVACE で Linux Verification Center (linuxtesting.org) によって発見されました。(CVE-2024-26722)

 - Linux カーネルで、次の脆弱性が解決されています。netfilter: nft_chain_filter: inet/ingress ベースチェーンの NETDEV_UNREGISTER を処理します NETDEV_UNREGISTER イベントが報告された場合に、inet/ingress ベースチェーンから netdevice を削除します。そうしないと、netdevice への古い参照がフックリストに残ります。
 (CVE-2024-26808)

 - Linux カーネルで、次の脆弱性は解決されています。nfc: nci: NCI デバイスのクリーンアップで rx_data_reassembly skb を解放します。断片化されたパケットを処理するために、NCI データ交換中に rx_data_reassembly skb が保存されます。最後のフラグメントが処理されたとき、または NCI_OP_RF_DEACTIVATE_NTF opcode のある NTF パケットを受信したときにのみドロップされます。ただし、NCI デバイスはその前に割り当て解除される可能性があり、これにより skb 漏洩が発生します。設計により、rx_data_reassembly skb は NCI デバイスにバインドされており、skb が何らかの方法で処理されてクリーンアップされる前にデバイスが解放されることを妨げるものは何もありません。NCI デバイスクリーンアップで解放します。Syzkaller で Linux Verification Center (linuxtesting.org) によって発見されました。(CVE-2024-26825)

 - Linux カーネルで、以下の脆弱性が解決されています。mptcp: 古いサブフローからのデータの再注入を修正します MPTCP PM がサブフローが古いことを検出すると、すべてのパケットスケジューラは、すべての mptcp レベルの未確認データを再注入する必要があります。不要なロックの取得を回避するために、最初に承認されていないデータが RTX キューに存在するかどうかを確認しようとしますが、MPTCP ソケットで TCP 固有のヘルパーを使用するため、このような確認は現在破損しています。興味深いことに、アクセスされたメモリは依然として mptcp_sock 構造体に属しているため、ファザーと静的チェッカーは満足しています。また、機能的な観点からしても、ショートカットテストは常に失敗するため、リカバリは正常に完了しました。最近の関連のない TCP の変更 - コミット d5fed5addb2b (tcp: tcp_sock 高速パス変数を再編成) - tcp フィールドの再編成により、mptcp コードが常に再接続をスキップするため、この問題を公開しました。偽造呼び出しがドロップする問題を修正します。進行状況が遅いため、早期最適化の悪意が再び証明されました。(CVE-2024-26826)

 - Linux カーネルでは、次の脆弱性が解決されています。media: ir_toy: irtoy_tx の memleak を修正します。irtoy_command が失敗した場合、buf は irtoy_tx によって割り当てられているか、memleak があるため、解放する必要があります。(CVE-2024-26829)

 - Linux カーネルでは、次の脆弱性が解決されています。netfilter: ipset: スワップ操作のパフォーマンス回帰を修正します。パッチ netfilter: ipset: swap/destroy とカーネルサイドの add/del/test の間の競合状態を修正し、コミット 28628fa9 は競合状態を修正します。しかし、swap 関数に追加された synchronize_rcu() は、それを不必要に遅くします。それは、destroy に安全に移動でき、代わりに call_rcu() を使用できます。
 Eric Dumazet 氏は、単に destroy 関数を rcu コールバックとして呼び出すだけでは機能しないことを指摘しました。タイムアウト付きのセットは、待機できる破壊時にキャンセルする必要があるガベージコレクターを使用します。したがって、destroy 関数は 2 つに分割されます。netlink が受信したコマンドの実行時にガベージコレクターを安全にキャンセルすることと、残りの部分のみを rcu コールバックに移動することです。(CVE-2024-26910)

 - Linux カーネルで、次の脆弱性が解決されています。drm/amd を戻す。中断エントリコミット ab4750332dbe で遅延した gfxoff をフラッシュします (drm/amdgpu/sdma5.2: begin/end_use リングコールバックを追加) これにより、GFXOFF コントロールがさらに使用されるようになりました。現在、コミット 0dee72639533 (drm/amd：中断エントリで遅延した gfxoff をフラッシュ) から削除されたコードパスは、中断時に再び実行できます。ユーザーは、GNOME を使用して lockscreen トリガーを一時停止すると、SDMA トラフィックとシステムのデッドロックが発生することがあると報告しています。
 これは、コミット 0dee726395333fea833eaaf838bc80962df886c8 を元に戻します。(CVE-2024-26916)

 - Linux カーネルで、次の脆弱性が解決されました。トレース/トリガー: スナップショットの割り当てに失敗した場合にエラーを返すように修正しました。スナップショットの割り当てに 0 (成功) ではなく失敗した場合に、エラーコードを返すように register_snapshot_trigger() を修正します。それ以外の場合は、スナップショットトリガーをエラーなしで登録します。
 (CVE-2024-26920)

 - この CVE は Intel によって割り当てられました。詳細については、CVE.org の CVE-2024-2201 を参照してください。(CVE-2024-2201)

Nessus はこれらの問題をテストしておらず、代わりにアプリケーションが自己報告するバージョン番号にのみ依存していることに注意してください。

ソリューション

影響を受けるカーネルパッケージを更新してください。

参考資料

https://ubuntu.com/security/notices/USN-6766-3

プラグインの詳細

深刻度: High

ID: 197517

ファイル名: ubuntu_USN-6766-3.nasl

バージョン: 1.1

タイプ: local

エージェント: unix

公開日: 2024/5/20

更新日: 2024/5/23

サポートされているセンサー: Frictionless Assessment AWS, Frictionless Assessment Azure, Frictionless Assessment Agent, Nessus Agent, Agentless Assessment, Nessus

リスク情報

VPR

リスクファクター: High

スコア: 7.4

CVSS v2

リスクファクター: Medium

基本値: 6.8

現状値: 5

ベクトル: CVSS2#AV:L/AC:L/Au:S/C:C/I:C/A:C

CVSS スコアのソース: CVE-2024-26592

CVSS v3

リスクファクター: High

基本値: 7.8

現状値: 6.8

ベクトル: CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

現状ベクトル: CVSS:3.0/E:U/RL:O/RC:C

脆弱性情報

CPE: p-cpe:/a:canonical:ubuntu_linux:linux-image-5.15.0-1061-aws, cpe:/o:canonical:ubuntu_linux:20.04:-:lts, cpe:/o:canonical:ubuntu_linux:22.04:-:lts

必要な KB アイテム: Host/cpu, Host/Debian/dpkg-l, Host/Ubuntu, Host/Ubuntu/release

エクスプロイトの容易さ: No known exploits are available

パッチ公開日: 2024/5/20

脆弱性公開日: 2024/1/23

参照情報

CVE: CVE-2023-52435, CVE-2023-52486, CVE-2023-52489, CVE-2023-52491, CVE-2023-52492, CVE-2023-52493, CVE-2023-52494, CVE-2023-52498, CVE-2023-52583, CVE-2023-52587, CVE-2023-52588, CVE-2023-52594, CVE-2023-52595, CVE-2023-52597, CVE-2023-52598, CVE-2023-52599, CVE-2023-52601, CVE-2023-52602, CVE-2023-52604, CVE-2023-52606, CVE-2023-52607, CVE-2023-52608, CVE-2023-52614, CVE-2023-52615, CVE-2023-52616, CVE-2023-52617, CVE-2023-52618, CVE-2023-52619, CVE-2023-52622, CVE-2023-52623, CVE-2023-52627, CVE-2023-52631, CVE-2023-52633, CVE-2023-52635, CVE-2023-52637, CVE-2023-52638, CVE-2023-52642, CVE-2023-52643, CVE-2024-1151, CVE-2024-2201, CVE-2024-23849, CVE-2024-26592, CVE-2024-26593, CVE-2024-26594, CVE-2024-26600, CVE-2024-26602, CVE-2024-26606, CVE-2024-26608, CVE-2024-26610, CVE-2024-26614, CVE-2024-26615, CVE-2024-26625, CVE-2024-26627, CVE-2024-26635, CVE-2024-26636, CVE-2024-26640, CVE-2024-26641, CVE-2024-26644, CVE-2024-26645, CVE-2024-26660, CVE-2024-26663, CVE-2024-26664, CVE-2024-26665, CVE-2024-26668, CVE-2024-26671, CVE-2024-26673, CVE-2024-26675, CVE-2024-26676, CVE-2024-26679, CVE-2024-26684, CVE-2024-26685, CVE-2024-26689, CVE-2024-26695, CVE-2024-26696, CVE-2024-26697, CVE-2024-26698, CVE-2024-26702, CVE-2024-26704, CVE-2024-26707, CVE-2024-26712, CVE-2024-26715, CVE-2024-26717, CVE-2024-26720, CVE-2024-26722, CVE-2024-26808, CVE-2024-26825, CVE-2024-26826, CVE-2024-26829, CVE-2024-26910, CVE-2024-26916, CVE-2024-26920

USN: 6766-3