リモートの Ubuntu 20.04 LTS ホストには、USN-6767-2 のアドバイザリに記載された複数の脆弱性の影響を受けるパッケージがインストールされています。 - 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 呼び出しトレース: 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 リンクされたモジュール: ---[ 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 カーネルでは、次の脆弱性が解決されています。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 --- --- #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 , 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 カーネルでは、次の脆弱性が解決されています。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 呼び出しトレース: __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/f9475918-2186-49b8-b801-6f0f9e75f4fa@oracle.com/ (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 呼び出しトレース: __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 ================================================================================ カーネルパニック - 同期していません: 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 呼び出しトレース: __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 カーネルオフセット: 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 カーネルでは、以下の脆弱性が解決されています。hwrng: core - mmap-ed hwrng のページ障害デッドロックを修正します。hwrng デバイスの読み取りパスにデッドロックがあります。これは、ユーザーが /dev/hwrng からメモリに読み取りを行い、/dev/hwrng からも mmap されたときにトリガーされます。その結果、ページ障害が発生すると、再帰的な読み取りがトリガーされ、デッドロックが発生します。copy_to_user を呼び出す際にスタックバッファを使用してこれを修正します。(CVE-2023-52615) - 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/20231113212150.96410-1-dns@arista.com のスクリプトを介して再現可能 (CVE-2023-52617) - 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 呼び出しトレース: __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] [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 カーネルで、次の脆弱性が解決されています。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 __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) - 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 カーネルでは、以下の脆弱性が解決されています。i2c: i801: ブロックプロセス呼び出しトランザクションを修正してます。Intel データシートによると、ソフトウェアはブロックプロセス呼び出しトランザクションのブロックバッファインデックスを 2 回リセットしなければなりません。バッファに送信データを書き込む前とバッファから着信データを読み取る前です。ドライバーには現在 2 番目のリセットがないため、ブロックバッファの誤った部分が読み取られます。(CVE-2024-26593) - Linux カーネルでは、次の脆弱性が解決されています。KVM: arm64: vgic-its: LPI 変換キャッシュの潜在的な UAF を回避します LPI 変換キャッシュヒットが、キャッシュを無効にする操作と競合する場合 (DISCARD ITS コマンドなど)、UAF のシナリオが存在する可能性があります。この問題の根本原因は、vgic_its_check_cache() が、refcount の変更をシリアル化するロックをドロップする前に、vgic_irq の refcount を昇格させないことです。vgic_its_check_cache() に、返された vgic_irq の refcount を増加させ、割り込みをキューに入れた後に、対応するデクリメントを追加します。(CVE-2024-26598) - 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 カーネルで、次の脆弱性が解決されています。net/smc: SMC-D 接続ダンプの違法な rmb_desc アクセスを修正します。SMC-D 接続をダンプするときにクラッシュが見つかりました。これは、次の手順で再現できます。- nginx/wrk テストを実行します。smc_run nginx smc_run wrk -t 16 -c 1000 -d -H 'Connection: Close' - パラレルで 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: ? __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 呼び出しトレース: __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 タスク 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 カーネルで、以下の脆弱性は解決されています。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 カーネルでは、次の脆弱性が解決されました。トレース: 要素を 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 カーネルでは、次の脆弱性が解決されています。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 ... 呼び出しトレース: 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 カーネルで、次の脆弱性が解決されています。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 カーネルで、次の脆弱性は解決されています。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 カーネルで、次の脆弱性が解決されています。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 カーネルでは、次の脆弱性が解決されています。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 カーネルでは、次の脆弱性は解決されています。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 カーネルで、次の脆弱性は解決されています。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 カーネルでは、次の脆弱性が解決されています。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 カーネルで、次の脆弱性が解決されました。トレース/トリガー: スナップショットの割り当てに失敗した場合にエラーを返すように修正しました。スナップショットの割り当てに 0 (成功) ではなく失敗した場合に、エラーコードを返すように register_snapshot_trigger() を修正します。それ以外の場合は、スナップショットトリガーをエラーなしで登録します。 (CVE-2024-26920) Nessus はこれらの問題をテストしておらず、代わりにアプリケーションが自己報告するバージョン番号にのみ依存していることに注意してください。

バージョン 1.1 Jul 10, 2024, 6:14 PM Plugin metadata Plugin Feed: 202407101814
バージョン 1.0 May 14, 2024, 11:03 PM New Plugin Feed: 202405142303

検出

Ubuntu 20.04 LTS : Linux kernel (BlueField) の脆弱性 (USN-6767-2)

high Nessus プラグイン ID 196947

バージョン 1.1

バージョン 1.0