リモートの Ubuntu 22.04 LTS ホストには、USN-6688-1 のアドバイザリに記載された複数の脆弱性の影響を受けるパッケージがインストールされています。 - Xen の仮想ネットワークプロトコルでの送信リクエストは、複数の部分で構成される場合があります。あまり有用ではありませんが、最初の部分を除いて、それらのいずれも長さがゼロ、つまり、データをまったく伝送しない可能性があります。転送されるデータの最初の特定の部分に加えて、これらの部分は Linux が SKB フラグメントと呼ぶものに直接変換されます。このように変換されたリクエスト部分は、特定の SKB の長さがすべてゼロの場合、コアネットワーキングコードで NULL のデリファレンスを引き起こす可能性があります。(CVE-2023-46838) - 6.6.5 までの Linux カーネルの drivers/accel/habanalabs/common/habanalabs_ioctl.c の sec_attest_info により、ユーザー空間への情報漏洩の可能性があります。これは、info->pad0 が初期化されないためです。(CVE-2023-50431) - Linux カーネルで、以下の脆弱性が解決されています。f2fs: xattr リストを明示的に NULL 終了させます xattr を設定する際、xattr リストを明示的に NULL 終了させます。これにより、未使用の xattr スペースが常にゼロに設定されているという脆弱な前提がなくなります。(CVE-2023-52436) - Linux カーネルでは、次の脆弱性が解決されています。binder: shinker のコールバックのメモリ解放後使用 (Use After Free) を修正します mmap 読み取りロックが shrinker のコールバック中に使用されるため、alloc->vma ポインターの使用は安全でなくなり、munmap() と競合する可能性があります。コミット dd2283f2605e (mm: mmap: munmap の読み取り mmap_sem による zap ページ) の時点では、vma が分離された後に mmap ロックがダウングレードされています。一部の遅延を手動で追加し、shrinker のデバッグ sysfs を通じてページ再利用をトリガーすることで、この問題を再現できました。次の KASAN レポートでも UAF が確認されています。 ================================================================== BUG: KASAN: slab-use-after-free in zap_page_range_single+0x470/0x4b8 Read of size 8 at addr ffff356ed50e50f0 by task bash/478 CPU: 1 PID: 478 Comm: bash Not tainted 6.6.0-rc5-00055-g1c8b86a3799f-dirty #70 ハードウェア名: linux,dummy-virt (DT) 呼び出しトレース: zap_page_range_single+0x470/0x4b8 binder_alloc_free_page+0x608/0xadc __list_lru_walk_one+0x130/0x3b0 list_lru_walk_node+0xc4/0x22c binder_shrink_scan+0x108/0x1dc shrinker_debugfs_scan_write+0x2b4/0x500 full_proxy_write+0xd4/0x140 vfs_write+0x1ac/0x758 ksys_write+0xf0/0x1dc __arm64_sys_write+0x6c/0x9c Allocated by task 492: kmem_cache_alloc+0x130/0x368 vm_area_alloc+0x2c/0x190 mmap_region+0x258/0x18bc do_mmap+0x694/0xa60 vm_mmap_pgoff+0x170/0x29c ksys_mmap_pgoff+0x290/0x3a0 __arm64_sys_mmap+0xcc/0x144 Freed by task 491: kmem_cache_free+0x17c/0x3c8 vm_area_free_rcu_cb+0x74/0x98 rcu_core+0xa38/0x26d4 rcu_core_si+0x10/0x1c __do_softirq+0x2fc/0xd24 最後に関連する作業の作成: __call_rcu_common.constprop.0+0x6c/0xba0 call_rcu+0x10/0x1c vm_area_free+0x18/0x24 remove_vma+0xe4/0x118 do_vmi_align_munmap.isra.0+0x718/0xb5c do_vmi_munmap+0xdc/0x1fc __vm_munmap+0x10c/0x278 __arm64_sys_munmap+0x58/0x7c mmap ロックダウングレードの前に分離された vma を見つけることに失敗する vma_lookup() を代わりに実行することで、この問題を修正します。注意: コンテンションを増加させる可能性のある mmap 書き込みロックにアップグレードするよりも、このオプションのパフォーマンスが向上します。また、いずれにしても mmap_write_trylock() は最近削除されました。(CVE-2023-52438) - Linux カーネルでは、以下の脆弱性が解決されています。uio: uio_open core-1 core-2 におけるメモリ解放後使用 (Use After Free) の修正 ------------------------------------------------------- uio_unregister_device uio_open idev = idr_find() device_unregister(&idev->dev) put_device(&idev->dev) uio_device_release get_device(&idev->dev) kfree(idev) uio_free_minor(minor) uio_release put_device(&idev->dev) kfree(idev) -------------------------------------------------- ----- core-1 uio_unregister_device() で、idev->dev kobject ref が 1 の場合、device_unregister は idev を kfree します。しかし、core-1 device_unregister、put_device の後、かつ kfree を行う前に、core-2 は get_device することがあります。1. core-1 が idev を kfree した後、core-2 は idev に対してメモリ解放後使用 (Use After Free) を実行します。2. core-2 が uio_release および put_device を行う場合、idev が二重解放されます。この問題に対処するために、minor_lock で idev atomic および inc idev 参照を取得できます。 (CVE-2023-52439) - Linux カーネルで、以下の脆弱性が解決されています。apparmor: 解析されたプロファイル名が空の場合にクラッシュを回避します。unpack_profile() でパックされたプロファイルを処理する際に、profile :ns::samba-dcerpcd /usr/lib*/samba/{,samba/}samba-dcerpcd {...} のように記述されます。文字列 :samba-dcerpcd が完全修飾名として解凍され、aa_splitn_fqname() に渡されます。aa_splitn_fqname() は、名前空間のみを含むものとして :samba-dcerpcd を扱います。したがって、tmpname に対して NULL を返しますが、tmpns は非 NULL です。新しいプロファイル名が現在 NULL であるため、後で aa_alloc_profile() がクラッシュします。一般保護違反、おそらく非標準アドレス 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: 範囲 [0x0000000000000000-0x0000000000000007] の null-ptr-deref CPU: 6 PID: 1657 Comm: apparmor_parser 汚染されていない 6.7.0-rc2-dirty #16 ハードウェア名: QEMU Standard PC (i440FX + PIIX、1996)、BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014 RIP: 0010:strlen+0x1e/0xa0 呼び出しトレース: ? strlen+0x1e/0xa0 aa_policy_init+0x1bb/0x230 aa_alloc_profile+0xb1/0x480 unpack_profile+0x3bc/0x4960 aa_unpack+0x309/0x15e0 aa_replace_profiles+0x213/0x33c0 policy_update+0x261/0x370 profile_replace+0x20e/0x2a0 vfs_write+0x2af/0xe00 ksys_write+0x126/0x250 do_syscall_64+0x46/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0x76 ---[ end trace 0000000000000000 ]--- RIP: 0010:strlen+0x1e/0xa0 aa_splitn_fqname() のこのような動作は予期されるものであり、呼び出される他の場所 (aa_remove_profiles など) でチェックされるようです。次のプロファイルのない ns 名が内部で許可されているという明示的なコメントがあります。AFAICS、解凍された名前が「samba-dcerpcd - ユーザー空間から渡される」のような形式になることを妨げるものはありません。このような場合、プロファイルセット全体の置換を拒否し、EPROTO および説明メッセージをユーザーに通知します。Linux Verification Center (linuxtesting.org) による発見。 (CVE-2023-52443) - Linux カーネルで、次の脆弱性が解決されました。f2fs: dirent 破損を回避するための修正 Link[1] で Al が報告したとおり: f2fs_rename() ... if (old_dir != new_dir && !whiteout) f2fs_set_link(old_inode, old_dir_entry, old_dir_page, new_dir); else f2fs_put_page(old_dir_page, 0); .. リンクで正しい inumber が必要です。また、古い場所にホワイトアウトを残すように求められていたとしても、クロスディレクトリの名前の変更により、ソースは新しい親に移動します。[1] https://lore.kernel.org/all/20231017055040.GN800259@ZenIV/ 以下のテストケースでは、.. を更新する f2fs_set_link() の呼び出しを逃したため、dirent の破損を引き起こす可能性があります。新しいディレクトリへのリンク。- mkdir -p dir/foo - renameat2 -w dir/foo bar [ASSERT] (__chk_dots_dentries:1421) --> 「..」に対する不良な inode 番号 [0x4]、親の親 ino は [0x3] [FSCK] 他の破損したバグ [失敗] (CVE-2023-52444) - Linux カーネルでは、次の脆弱性が解決されています。メディア: pvrusb2: コンテキスト切断時のメモリ解放後使用 (Use After Free) を修正します。モジュールがロードされると、pvr2_context_thread_func 関数をターゲットとする kthread が作成されます。これにより、pvr2_context_destroy を呼び出し、コンテキストオブジェクトで kfree() を呼び出す可能性があります。ただし、これは usb hub_event ハンドラーがドライバーに通知できるようになる前に発生する可能性があります。このパッチは、syzbot により報告される無効な読み取りの前に、コンテキスト切断コールスタック内でのサニティチェックを追加します。(CVE-2023-52445) - Linux カーネルでは、以下の脆弱性が解決されています。bpf: 必要に応じて内部マップの解放を延期します。マップ配列またはマップ htab の内部マップを更新または削除するとき、マップがスリープ不可能なプログラムまたはスリープ可能なプログラムによってまだアクセスされる可能性があります。ただし、bpf_map_fd_put_ptr() は、bpf_map_put() を通じて直接内部マップの ref-counter を減少させます。ref-counter が最後のものである場合は (ほとんどの場合に当てはまる)、内部マップは kworker の ops->map_free() によって解放されます。しかし、現時点では、ほとんどの .map_free() コールバックは、synchronize_rcu() またはその変種を使用して、RCU 猶予期間が経過するのを待機しません。したがって、ops->map_free の呼び出しの完了後、内部 map にアクセスする bpf プログラムにより、メモリ解放後使用 (Use After Free) 問題が発生する可能性があります。以前に内部マップが外部マップから削除されている場合、RCU 猶予期間とタスクの両方が RCU 猶予期間をトレースした後に bpf_map_free_deferred() を呼び出すことで、内部マップの解放を修正します。延期は、bpf マップの最後の ref-counter をリリースする際に、call_rcu() または call_rcu_tasks_trace() を使用することで達成されます。新しく追加された bpf_map の rcu_head フィールドは、同じストレージスペースを作業フィールドと共有し、bpf_map のサイズを縮小します。(CVE-2023-52447) - Linux カーネルで、次の脆弱性が解決されています。gfs2: gfs2_rgrp_dump のカーネル NULL ポインターデリファレンスを修正します Syzkaller 氏が、gfs2_rgrp_dump() の rgd->rd_rgl にアクセスするときの NULL ポインターデリファレンスを報告しました。これは、read_rindex_entry() で rgd->rd_gl の作成が失敗したときに発生する可能性があります。それを防ぐために、gfs2_rgrp_dump() に NULL ポインターチェックを追加します。(CVE-2023-52448) - Linux カーネルでは、次の脆弱性が解決されています。mtd: ftl notifier によって引き起こされた gluebi NULL ポインターデリファレンスを修正します。ftl.ko と gluebi.ko の両方がロードされている場合、ftl の通知子が、gluebi_read() の gluebi->desc' にアクセスを試みる際に、NULL ポインターデリファレンスをトリガーします。ubi_gluebi_init ubi_register_volume_notifier ubi_enumerate_volumes ubi_notify_all gluebi_notify nb->notifier_call() gluebi_create mtd_device_register mtd_device_parse_register add_mtd_device blktrans_notify_add not->add() ftl_add_mtd tr->add_mtd() scan_header mtd_read mtd_read_oob mtd_read_oob_std gluebi_read mtd->read() gluebi->desc - NULL Detailed の複製情報はリンク [1] で入手可能です。通常の場合、gluebi_get_device() で gluebi->desc を取得し、gluebi_read() で gluebi->desc にアクセスします。ただし、gluebi_get_device() が ftl_add_mtd() プロセスで事前に実行されないため、NULL ポインターデリファレンスが発生します。gluebi モジュールのソリューションは、ftl または mtdblock との連携を考慮せずに、UBI ボリュームで jffs2 を実行することです [2]。したがって、MTD_UBIVOLUME タイプの mtd パーティションを作成した後に gluebi が mtdblock デバイスを作成しないようにすることで、この問題を回避できます。(CVE-2023-52449) - Linux カーネルで、次の脆弱性が解決されています。powerpc/pseries/memhp: drmem 配列の終端を超えたアクセスを修正します。LMB 検索が特定の DRC インデックスによるエントリと一致しない場合、dlpar_memory_remove_by_index() が drmem lmb 配列の境界を超えてアクセスする可能性があります。検索が失敗すると、カーソルは &drmem_info->lmbs[drmem_info->n_lmbs] を指したままになります。これは、配列の最後の有効なエントリの後の 1 要素です。関数の末尾にあるデバッグメッセージは、このポインターを逆参照します。 pr_debug(%llx\n、lmb->base_addr でメモリをホットリムーブすることに失敗しました)。これは、検査の結果見つかり、KASAN で確認されました。pseries-hotplug-mem: LMB をホットリムーブしようとします、drc index 1234 ================================================================== BUG: KASAN: dlpar_memory+0x298/0x1658 の slab-out-of-bounds タスク bash/949 dump_stack_lvl+0xa4/0xfc (信頼できない) print_report+0x214/0x63c kasan_report+0x140/0x2e0 による addr c000000364e97fd0 でのサイズ 8 の読み取り __asan_load8+0xa8/0xe0 dlpar_memory+0x298/0x1658 handle_dlpar_errorlog+0x130/0x1d0 dlpar_store+0x18c/0x3e0 kobj_attr_store+0x68/0xa0 sysfs_kf_write+0xc4/0x110 kernfs_fop_write_iter+0x26c/0x390 vfs_write+0x2d4/0x4e0 ksys_write+0xac/0x1a0 system_call_exception+0x268/0x530 system_call_vectored_common+0x15c/0x2ec Allocated by task 1: kasan_save_stack+0x48/0x80 kasan_set_track+0x34/0x50 kasan_save_alloc_info+0x34/0x50 __kasan_kmalloc+0xd0/0x120 __kmalloc+0x8c/0x320 kmalloc_array.constprop.0+0x48/0x5c drmem_init+0x2a0/0x41c do_one_initcall+0xe0/0x5c0 kernel_init_freeable+0x4ec/0x5a0 kernel_init+0x30/0x1e0 ret_from_kernel_user_thread+0x14/0x1c バグのあるアドレスは、131072 のサイズのキャッシュ kmalloc-128k に属する c000000364e80000 のオブジェクトに属します。バグのあるアドレスは、割り当てられた 98256 バイトの領域 [c000000364e80000、c000000364e97fd0) の右の 0 バイトに配置されています ================================================================== pseries-hotplug-mem: 0 でメモリをホットリムーブするのに失敗しました。失敗した検索を別のメッセージでログし、有効なエントリを指している場合にのみカーソルをデリファレンスします。(CVE-2023-52451) - Linux カーネルでは、次の脆弱性が解決されています。nvmet-tcp: ホストが無効な H2C PDU 長を送信するときのカーネルパニックを修正します。ホストが無効な DATAL で H2CData コマンドを送信する場合、カーネルが nvmet_tcp_build_pdu_iovec() でクラッシュすることがあります。仮想アドレス 0000000000000000 でカーネルの NULL ポインターデリファレンスを処理できません lr : nvmet_tcp_io_work+0x6ac/0x718 [nvmet_tcp] 呼び出しトレース: process_one_work+0x174/0x3c8 worker_thread+0x2d0/0x3e8 kthread+0x104/0x110 DATAL がパケットサイズと首尾一貫しない場合に致命的なエラーが発生することにより、バグを修正します。また、PDU の長さは、nvmet_tcp_handle_icreq() でホストに伝達された MAXH2CDATA パラメーターを決して超えてはなりません。(CVE-2023-52454) - Linux カーネルでは、次の脆弱性が解決されています。serial: imx: tx 状態マシンのデッドロックを修正します。シリアルポートを RS485 ポートとして使用する場合、tx 状態マシンは、RS485トランシーバーの TX_EN ピンを駆動する RTS ピンを制御するために使用されます。TTY ポートが転送の途中 (ユーザーランドアプリケーションのクラッシュなど) で閉じられると、imx_uart_shutdown はインターフェースを無効にし、転送完了割り込みを無効にします。その後、imx_uart_stop_tx は不完全な転送で終了し、TC 割り込みによって再トリガーされます。この割り込みは無効であるため、tx ステートマシンは SEND から移行しません。ステートマシンは現在デッドロックにあり、TX_EN が Low のままであるため、インターフェースが役に立ちません。imx_uart_stop_tx は、不完全な送信をチェックするようになり、また TC 割り込みがベイリングの再トリガー前に有効化されているかどうかをチェックします。これにより、状態マシン処理が達成され、WAIT_AFTER_SEND に適切に設定されるようになります。(CVE-2023-52456) - Linux カーネルでは、次の脆弱性は解決されています。serial: 8250: omap: pm_runtime_resume_and_get() が失敗した場合、リソース解放をスキップしないでください。.remove() からエラーコードを返すと、ドライバーコアに役に立つエラーメッセージが出力されます。削除コールバックがゼロ以外の値を返しました。これは無視されます。それから、デバイスを削除します。したがって、この場合、解放されなかったすべてのリソースは漏洩します。 serial8250_unregister_port() をスキップすると、メモリ解放後使用 (Use After Free) をトリガーするのに十分な UART が周囲に残る可能性があります。そのため、エラーリターン (それと少し役立つエラーメッセージ) を、より有用なエラーメッセージで置き換え、クリーンアップを継続します。(CVE-2023-52457) - Linux カーネルでは、次の脆弱性が解決されています。block: パーティションの長さをブロックサイズと調整する必要があることのチェックを追加します。add パーティションまたは resize パーティションを呼び出す前に、または長さが論理ブロックサイズと調整されているかどうかのチェックがありません。ディスクの論理ブロックサイズが 512 バイトより大きい場合、パーティションサイズが論理ブロックサイズの倍数でない可能性があり、最後のセクターが読み取られるときに、bio_truncate() は bio サイズを調整し、読み取りコマンドが論理ブロックサイズよりも地裁場合に IO エラーが発生します。整合性データがサポートされている場合、これにより bio_integrity_free を呼び出す際に NULL ポインターデリファレンスも発生します。(CVE-2023-52458) - Linux カーネルでは、次の脆弱性が解決されています。bpf: スピルされたポインターを破損させる試みのチェックを修正します。レジスターが 1/2/4 バイトのレジスターとしてスタックにスピルされると、slot_type[BPF_REG_SIZE - 1] が設定されます (加えて、実際のスピルサイズに応じて、その下にさらに存在する可能性があります)。したがって、一部のスタックスロットがレジスターをスピルしているかどうかを確認するには、slot_type[0] ではなく slot_type[7] を調べる必要があります。これを覚えておく必要がなく、将来的に二重チェックするには、is_spilled_reg() ヘルパーを使用します。 (CVE-2023-52462) - Linux カーネルでは、次の脆弱性は解決されています。efivarfs: SetVariable がサポートされていない場合、再マウント時に RO を強制します。ランタイムの SetVariable がファームウェアによってサポートされていない場合、その関数にコールバックを割り当てることはありません。同時に efivarfs を RO としてマウントし、誰もそれを呼び出せないようにします。ただし、誰かがファイルシステムを RW として再マウントした場合は、アクセス許可フラグをチェックしません。結果として、これは次のようなクラッシュを引き起こします。$ mount -o remount,rw /sys/firmware/efi/efivars $ efi-updatevar -f PK.auth PK [303.279166] 仮想アドレス 0000000000000000 [303.280482] でカーネル NULL ポインターデリファレンスを処理できません Mem abort info: [ 303.280854] ESR = 0x0000000086000004 [ 303.281338] EC = 0x21: IABT (current EL), IL = 32 bits [ 303.282016] SET = 0, FnV = 0 [ 303.282414] EA = 0, S1PTW = 0 [ 303.282821] FSC = 0x04: level 0 translation fault [ 303.283771] user pgtable: 4k pages, 48-bit VAs, pgdp=000000004258c000 [303.284913] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 [ 303.286076] Internal error: Oops: 0000000086000004 [#1] PREEMPT SMP [ 303.286936] Modules linked in: qrtr tpm_tis tpm_tis_core crct10dif_ce arm_smccc_trng rng_core drm fuse ip_tables x_tables ipv6 [ 303.288586] CPU: 1 PID: 755 Comm: efi-updatevar Not tainted 6.3.0-rc1-00108-gc7d0c4695c68 #1 [ 303.289748] ハードウェア名: Unknown Unknown Product/Unknown Product, BIOS 2023.04-00627-g88336918701d 04/01/2023 [ 303.291150] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 303.292123] pc : 0x0 [ 303.292443] lr : efivar_set_variable_locked+0x74/0xec [ 303.293156] sp : ffff800008673c10 [ 303.293619] x29: ffff800008673c10 x28: ffff0000037e8000 x27: 0000000000000000 [ 303.294592] x26: 0000000000000800 x25: ffff000002467400 x24: 0000000000000027 [ 303.295572] x23: ffffd49ea9832000 x22: ffff0000020c9800 x21: ffff000002467000 [ 303.296566] x20: 0000000000000001 x19: 00000000000007fc x18: 0000000000000000 [303.297531] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaaac807ab54 [ 303.298495] x14: ed37489f673633c0 x13: 71c45c606de13f80 x12: 47464259e219acf4 [ 303.299453] x11: ffff000002af7b01 x10: 0000000000000003 x9 : 0000000000000002 [ 303.300431] x8 : 0000000000000010 x7 : ffffd49ea8973230 x6 : 0000000000a85201 [ 303.301412] x5 : 0000000000000000 x4 : ffff0000020c9800 x3 : 00000000000007fc [303.302370] x2 : 0000000000000027 x1 : ffff000002467400 x0 : ffff000002467000 [ 303.303341] 呼び出しトレース: [303.303679] 0x0 [ 303.303938] efivar_entry_set_get_size+0x98/0x16c [ 303.304585] efivarfs_file_write+0xd0/0x1a4 [ 303.305148] vfs_write+0xc4/0x2e4 [ 303.305601] ksys_write+0x70/0x104 [303.306073] __arm64_sys_write+0x1c/0x28 [ 303.306622] invoke_syscall+0x48/0x114 [ 303.307156] el0_svc_common.constprop.0+0x44/0xec [ 303.307803] do_el0_svc+0x38/0x98 [ 303.308268] el0_svc+0x2c/0x84 [303.308702] el0t_64_sync_handler+0xf4/0x120 [ 303.309293] el0t_64_sync+0x190/0x194 [ 303.309794] コード: ???????? ???????? ???????? ???????? (????????) [ 303.310612] ---[ end trace 0000000000000000 ]--- .reconfigure() 関数を fs 操作に追加することによりこれを修正します。これは、リクエストされたフラグを確認したり、ファームウェアがランタイムで SetVariable を実装しない場合に RO でないものすべてを拒否するの使用できます。(CVE-2023-52463) - Linux カーネルで、次の脆弱性が解決されています。EDAC/thunderx: 領域外の文字列アクセスの可能性を修正します -Wstringop-overflow をグローバルに有効にすると、strncat() の使用における一般的なバグの警告が表示されます。drivers/edac/thunderx_edac.c: 「thunderx_ocx_com_threaded_isr」関数内: drivers/edac/thunderx_edac.c:1136:17: error: 'strncat' specified bound 1024 equals destination size [-Werror=stringop-overflow=] 1136 | strncat(msg, other, OCX_MESSAGE_SIZE); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ... 1145 | strncat(msg, other, OCX_MESSAGE_SIZE); ... 1150 | strncat(msg, other, OCX_MESSAGE_SIZE); ... 明らかに、このドライバーの作成者は、strncat() が strlcat() と同じように動作することを期待していました。これは、ソースバッファの長さではなく、宛先バッファのサイズを 3 番目の引数として使用します。その結果、割り当てられたバッファのサイズはチェックされません。これを strlcat() に変更します。[ bp: コンパイラ出力をトリミングし、コミットメッセージを修正。] (CVE-2023-52464) - Linux カーネルで、次の脆弱性が解決されています。mfd: syscon: of_syscon_register() の NULL ポインターデリファレンスを修正します kasprintf() が、失敗時に NULL になる可能性のある動的に割り当てられたメモリへポインターを返します。(CVE-2023-52467) - Linux カーネルでは、次の脆弱性が解決されています。drivers/amd/pm: kv_parse_power_table のメモリ解放後使用 (Use After Free) を修正します kzalloc によって割り当てられた ps が NULL の場合、kv_parse_power_table は、より前に割り当てられていた adev->pm.dpm.ps を解放します。ただし、制御フローが以下の呼び出しチェーンを通過した後: kv_parse_power_table |-> kv_dpm_init |-> kv_dpm_sw_init |-> kv_dpm_fini adev->pm.dpm.ps は、kv_parse_power_table で最初に解放された後、kv_dpm_fini の for ループで使用され、メモリ解放後使用 (Use After Free) のバグを引き起こします。(CVE-2023-52469) - Linux カーネルで、以下の脆弱性は解決されています。drm/radeon: radeon_crtc_init() で alloc_workqueue の戻り値をチェックし、radeon_crtc_init() で alloc_workqueue の戻り値をチェックして、null-ptr-deref を回避します。(CVE-2023-52470) - Linux カーネルでは、次の脆弱性が解決されています。ceph: dget() の誤用によるデッドロックまたはデッドコードを修正します denty とその親の間のロック順序が正しくありません。親が最初にロックを取得することを常に確認する必要があります。しかし、このデッドコードは使用されることはなく、親ディレクトリは常に呼び出し元から設定されるため、削除してしまいましょう。(CVE-2023-52583) - Linux カーネルでは、以下の脆弱性は解決されています。spmi: mediatek: デバイス削除の UAF を修正します。クロックを含む pmif ドライバーデータは、spmi_controller とともに割り当てられます。デバイスの削除では、spmi_controller が最初に解放され、次にクロックを含む devres がクリーンアップされます。これは、クロックを配置すると、spmi_controller とともにすでに解放されている pmif ドライバーデータのクロックにアクセスするため、UAF につながります。これは、DEBUG_TEST_DRIVER_REMOVE を有効にし、KASAN でカーネルを構築することで再現できます。管理されていない clk_bulk_get() を使用し、spmi_controller を解放する前にクロックを配置することで、UAF の問題を修正します。(CVE-2023-52584) - 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 カーネルでは、次の脆弱性が解決されています。f2fs: ブロック移行中にページの gcing フラグにタグ付けするのを修正します。移行されたデータがチェックポイント中に保持されることを保証するために、ブロック移行中に欠落している gcing フラグをページに追加する必要があります。さもないと、データとノード間の異常な永続性により、SPOR 後にデータ破損が発生する可能性があります。同様の問題が、コミット 2d1fe8a86bf5 で修正されました (f2fs: ファイルデフラグ中のページの gcing フラグのタグ付けを修正)。(CVE-2023-52588) - Linux カーネルで、次の脆弱性が解決されています。media: rkisp1: IRQ 無効化競合問題を修正します rkisp1_isp_stop() および rkisp1_csi_disable() で、ドライバーが割り込みをマスクし、その後明らかに割り込みハンドラーが実行されていないと想定し、停止手順を実行します。割り込みハンドラーがすでに実行されている可能性があるため、割り込みハンドラーがキャプチャされたフレームを処理している間に、ISP が無効になっている場合はそうではありません。これにより、2 つの問題が発生します。1) 割り込みハンドラーがまだ実行されてレジスターにアクセスしているときに、ISP の電源が切れて、ボードのロックアップにつながる可能性があります。2) 割り込みハンドラーコードと、ストリーミングを無効にするコードが、競合することを行う可能性があります。2) が実際の問題を引き起こすかどうかは明確ではありませんが、1) は割り込みハンドラーの適切な遅延 (または printk) で発生し、ボードのロックアップを引き起こす可能性があります。(CVE-2023-52589) - Linux カーネルでは、次の脆弱性が解決されています。wifi: wfx: wfx_set_mfp_ap() の NULL ポインターデリファレンスの可能性を修正します「ieee80211_beacon_get()」は NULL を返す可能性があるため、「wfx_set_mfp_ap()」は skb データを調べる前に戻り値をチェックする必要があります。そのため、後者を変換して適切なエラーコードを返し、それを伝播して「wfx_start_ap()」からも返します。テスト済みのみをコンパイルします。(CVE-2023-52593) - 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: jfs_evict_inode の uaf を修正します diMount(ipimap) の実行が失敗したときに、リリースされた ipimap のオブジェクトが、diFreeSpecial() でアクセスされる可能性があります。rcu_core() が jfs_free_node() を呼び出す際に、非同期の ipimap リリースが発生します。したがって、diMount(ipimap) が失敗した場合、sbi->ipimap は ipimap として初期化されるべきではありません。(CVE-2023-52600) - 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 カーネルにおいて、以下の脆弱性は解決されています。UBSAN: dtSplitRoot 内の array-index-out-of-bounds Syzkaller は、次の問題を報告しました。oop0: 0 から 32768 への容量変更を検出しました UBSAN: fs/jfs/jfs_dtree.c:1971:9 内の array-index-out-of-bounds index -2 はタイプ「struct dtslot [128]」の範囲外です CPU: 0 PID: 3613 Comm: syz-executor270 汚染なし 6.0.0-syzkaller-09423-g493ffd6605b2 #0 ハードウェア名: Google Google Compute Engine/Google Compute Engine、BIOS Google 09/22/2022 呼び出しトレース: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106 ubsan_epilogue lib/ubsan.c:151 [inline] __ubsan_handle_out_of_bounds+0xdb/0x130 lib/ubsan.c:283 dtSplitRoot+0x8d8/0x1900 fs/jfs/jfs_dtree.c:1971 dtSplitUp fs/jfs/jfs_dtree.c:985 [inline] dtInsert+0x1189/0x6b80 fs/jfs/jfs_dtree.c:863 jfs_mkdir+0x757/0xb00 fs/jfs/namei.c:270 vfs_mkdir+0x3b3/0x590 fs/namei.c:4013 do_mkdirat+0x279/0x550 fs/namei.c:4038 __do_sys_mkdirat fs/namei.c:4053 [inline] __se_sys_mkdirat fs/namei.c:4051 [inline] __x64_sys_mkdirat+0x85/0x90 fs/namei.c:4051 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fcdc0113fd9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 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 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffeb8bc67d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000102 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fcdc0113fd9 RDX: 0000000000000000 RSI: 0000000020000340 RDI: 0000000000000003 RBP: 00007fcdc00d37a0 R08: 0000000000000000 R09: 00007fcdc00d37a0 R10: 00005555559a72c0 R11: 0000000000000246 R12: 00000000f8008000 R13: 0000000000000000 R14: 00083878000000f8 R15: 0000000000000000 この問題は、fsi の値が -1 未満になると発生します。fsi 値が -1 になったときにループをブレークするためのチェックが存在しますが、syzbot が -1 未満の値を生成することができたため、エラーが発生します。このパッチは、単に 0 未満の値の変更を追加するだけです。パッチは syzbot を介してテストされています。(CVE-2023-52603) - 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 カーネルで、次の脆弱性が解決されています。ACPI: extlog: NULL ポインターデリファレンスチェックを修正します gcc プラグイン -fanalyzer [1] は、不適切な動作のさまざまなパターンの検出を試みます。ツールによるレポート: drivers/acpi/acpi_extlog.c: In function extlog_exit': drivers/acpi/acpi_extlog.c:307:12: 警告: すでに逆参照している後の extlog_l1_addr' での NULL のチェック [-Wanalyzer-deref-before-check] | | 306 | ((struct extlog_l1_head *)extlog_l1_addr)->flags &= ~FLAG_OS_OPTIN; | | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~ | | | | | (1) ポインター extlog_l1_addr' がここで逆参照されます | 307 | if (extlog_l1_addr) | | ~ | | | | | （2）ポインター extlog_l1_addr' の NULL がここでチェックされますが、すでに (1) で逆参照されています | extlog_exit() の NULL ポインターデリファレンスチェックを修正します。(CVE-2023-52605) - Linux カーネルで、以下の脆弱性が解決されています。powerpc/lib: ベクトル操作のサイズを検証します sstep.c の一部の fp/vmx コードは、エミュレートされる命令に対して特定の最大サイズを想定しています。ただし、これらの操作のサイズは、analyse_instr() で個別に決定されます。操作の最大サイズの想定を検証するチェックを追加し、意図しないカーネルスタックの破損を防ぎます。(CVE-2023-52606) - Linux カーネルで、次の脆弱性が解決されています。powerpc/mm: pgtable_cache_add の NULL ポインターデリファレンスを修正します kasprintf() が、失敗時に NULL になる可能性のある動的に割り当てられたメモリへポインターを返します。ポインターの有効性をチェックして、割り当てが成功したことを確認します。 (CVE-2023-52607) - CVE-2023-33951 および CVE-2023-33952 の修正の一部として行われた参照カウントの変更により、メモリオブジェクトがサーフェス保存に使用されていたときの方法に、メモリ解放後使用 (Use-After-Free) の欠陥があることがわかりました。3D アクセラレーションが有効になっている VMware ゲスト内で実行している場合、権限のないローカルユーザーがこの欠陥を利用して、権限を昇格する可能性があります。(CVE-2023-5633) - Linux カーネルの fs/smb/client/smb2ops.c 内の smb2_dump_detail に領域外読み取りの脆弱性が見つかりました。この問題により、ローカルの攻撃者がシステムをクラッシュさせたり、内部カーネル情報を漏洩させたりする可能性があります。 (CVE-2023-6610) - Linux カーネルの drivers/vhost/vhost.c の vhost_new_msg に脆弱性が見つかりました。vhost/vhost.c:vhost_new_msg() 関数における、仮想ゲストとホストオペレーティングシステムの間で渡されるメッセージでメモリを適切に初期化しません。この問題により、/dev/vhost-net デバイスファイルからの読み取り時に、ローカルの特権ユーザーが一部のカーネルメモリの内容を読み取る可能性があります。(CVE-2024-0340) - Linux カーネルの netfilter: nf_tables コンポーネントに存在するメモリ解放後使用 (Use After Free) の脆弱性が悪用されると、ローカルの権限昇格が達成される可能性があります。nft_setelem_catchall_deactivate() 関数は、catch-all セット要素を解放する前に、次世代ではなく現世代でアクティブかどうかをチェックしますが、次世代では非アクティブのフラグを立てるだけであるため、要素を複数回解放することが可能であり、二重解放の脆弱性につながります。過去のコミット b1db244ffd041a49ecc9618e8feb6b5c1afcdaa7 をアップグレードすることをお勧めします。(CVE-2024-1085) - Linux カーネルの netfilter: nf_tables コンポーネントに存在するメモリ解放後使用 (Use After Free) の脆弱性が悪用されると、ローカルの権限昇格が達成される可能性があります。nft_verdict_init() 関数は、フック判定内のドロップエラーとして正の値を許可するため、NF_ACCEPT に似たドロップエラーで NF_DROP が発行された場合、nf_hook_slow() 関数は二重解放の脆弱性を引き起こす可能性があります。過去のコミット f342de4e2f33e0e39165d8639387aa6c19dff660 へのアップグレードを推奨します。(CVE-2024-1086) - 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 カーネルの bluetooth デバイスドライバーの {min,max}_key_size_set() 関数に競合状態が見つかりました。これにより、NULL ポインターデリファレンスの問題が発生し、カーネルパニックまたはサービス拒否問題が発生する可能性があります。(CVE-2024-24860) - Linux カーネルでは、次の脆弱性が解決されています。netfilter: nft_set_rbtree: 挿入時の gc rbtree lazy gc からのスキップ終了間隔要素は、このトランザクションで追加されたばかりの終了間隔要素、まだアクティブでないスキップ終了間隔要素を収集する可能性があります。(CVE-2024-26581) - Linux カーネルでは、次の脆弱性が解決されています。LoongArch: BPF: 領域外メモリアクセスを防止します test_tag テストにより、処理されないページ障害がトリガーされます: # ./test_tag [ 130.640218] CPU 0 仮想アドレス ffff80001b898004、era == 9000000003137f7c、ra == 9000000003139e70 で、カーネルページングリクエストを処理できません [ 130.640501] Oops[#3]: [ 130.640553] CPU: 0 PID: 1326 Comm: test_tag Tainted: G D O 6.7.0-rc4-loong-devel-gb62ab1a397cf #47 61985c1d94084daa2432f771daa45b56b10d8d2a [ 130.640764] Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022 [ 130.640874] pc 9000000003137f7c ra 9000000003139e70 tp 9000000104cb4000 sp 9000000104cb7a40 [ 130.641001] a0 ffff80001b894000 a1 ffff80001b897ff8 a2 000000006ba210be a3 0000000000000000 [ 130.641128] a4 000000006ba210be a5 00000000000000f1 a6 00000000000000b3 a7 0000000000000000 [ 130.641256] t0 0000000000000000 t1 00000000000007f6 t2 0000000000000000 t3 9000000004091b70 [ 130.641387] t4 000000006ba210be t5 0000000000000004 t6 fffffffffffffff0 t7 90000000040913e0 [ 130.641512] t8 0000000000000005 u0 0000000000000dc0 s9 0000000000000009 s0 9000000104cb7ae0 [ 130.641641] s1 00000000000007f6 s2 0000000000000009 s3 0000000000000095 s4 0000000000000000 [ 130.641771] s5 ffff80001b894000 s6 ffff80001b897fb0 s7 9000000004090c50 s8 0000000000000000 [ 130.641900] ra: 9000000003139e70 build_body+0x1fcc/0x4988 [ 130.642007] ERA: 9000000003137f7c build_body+0xd8/0x4988 [ 130.642112] CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) [ 130.642261] PRMD: 00000004 (PPLV0 +PIE -PWE) [130.642353] EUEN: 00000003 (+FPE +SXE -ASXE -BTE) [ 130.642458] ECFG: 00071c1c (LIE=2-4,10-12 VS=7) [130.642554] ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0) [ 130.642658] BADV: ffff80001b898004 [130.642719] PRID: 0014c010 (Loongson-64bit, Loongson-3A5000) [ 130.642815] リンクされたモジュール: [最終アンロード: bpf_testmod(O)] [ 130.642924] Process test_tag (pid: 1326, threadinfo=00000000f7f4015f, task=000000006499f9fd) [ 130.643062] スタック : 0000000000000000 9000000003380724 0000000000000000 0000000104cb7be8 [ 130.643213] 0000000000000000 25af8d9b6e600558 9000000106250ea0 9000000104cb7ae0 [130.643378] 0000000000000000 0000000000000000 9000000104cb7be8 90000000049f6000 [ 130.643538] 0000000000000090 9000000106250ea0 ffff80001b894000 ffff80001b894000 [ 130.643685] 00007ffffb917790 900000000313ca94 0000000000000000 0000000000000000 [ 130.643831] ffff80001b894000 0000000000000ff7 0000000000000000 9000000100468000 [ 130.643983] 0000000000000000 0000000000000000 0000000000000040 25af8d9b6e600558 [ 130.644131] 0000000000000bb7 ffff80001b894048 0000000000000000 0000000000000000 [130.644276] 9000000104cb7be8 90000000049f6000 0000000000000090 9000000104cb7bdc [ 130.644423] ffff80001b894000 0000000000000000 00007ffffb917790 90000000032acfb0 [ 130.644572] ... [ 130.644629] 呼び出しトレース: [ 130.644641] [<9000000003137f7c>] build_body+0xd8/0x4988 [ 130.644785] [<900000000313ca94>] bpf_int_jit_compile+0x228/0x4ec [ 130.644891] [<90000000032acfb0>] bpf_prog_select_runtime+0x158/0x1b0 [130.645003] [<90000000032b3504>] bpf_prog_load+0x760/0xb44 [ 130.645089] [<90000000032b6744>] __sys_bpf+0xbb8/0x2588 [ 130.645175] [<90000000032b8388>] sys_bpf+0x20/0x2c [ 130.645259] [<9000000003f6ab38>] do_syscall+0x7c/0x94 [ 130.645369] [<9000000003121c5c>] handle_syscall+0xbc/0x158 [130.645507] [ 130.645539] コード: 380839f6 380831f9 28412bae <24000ca6> 004081ad 0014cb50 004083e8 02bff34c 58008e91 [ 130.645729] [ 130.646418] ---[ 終了トレース 0000000000000000 ]--- CONFIG_PAGE_SIZE_16KB=y を持つ私のマシンでは、2039 命令で BPF プログラムをロード中にテストが失敗しました: prog = (struct bpf_prog *)ffff80001b894000 insn = (struct bpf_insn *)(prog->insnsi)fff ---truncated--- (CVE-2024-26588) - Linux カーネルで、次の脆弱性が解決されています。bpf: PTR_TO_FLOW_KEYS の変数オフセット alu を拒否します PTR_TO_FLOW_KEYS の場合、check_flow_keys_access() は検証に固定 off のみを使用します。ただし、変数オフセットポインター alu はこの種類のポインターに対して禁止されていません。そのため、変数オフセットはチェックされません。次のプログラムが受け入れられます。func#0 @0 0: R1=ctx() R10=fp0 0: (bf) r6 = r1 ; R1=ctx() R6_w=ctx() 1: (79) r7 = *(u64 *)(r6 +144) ; R6_w=ctx() R7_w=flow_keys() 2: (b7) r8 = 1024 ; R8_w=1024 3: (37) r8 /= 1 ; R8_w=scalar() 4: (57) r8 &= 1024 ; R8_w=scalar(smin=smin32=0, smax=umax=smax32=umax32=1024,var_off=(0x0; 0x400)) 5: (0f) r7 += r8 mark_precise: frame0: last_idx 5 first_idx 0 subseq_idx -1 mark_precise: frame0: regs=r8 stack= before 4: (57) r8 &= 1024 mark_precise: frame0: regs=r8 stack= before 3: (37) r8 /= 1 mark_precise: frame0: regs=r8 stack= before 2: (b7) r8 = 1024 6: R7_w=flow_keys(smin=smin32=0,smax=umax=smax32=umax32=1024,var_off =(0x0; 0x400)) R8_w=scalar(smin=smin32=0,smax=umax=smax32=umax32=1024, var_off=(0x0; 0x400)) 6: (79) r0 = *(u64 *)(r7 +0) ; R0_w=scalar() 7: (95) exit このプログラムは、flow_keys を r7 へロードし、変数オフセット r8 を r7 へ追加し、最後に領域外アクセスを引き起こします。BUG: アドレス: ffffc90014c80038 のページ違反を処理できません [...] 呼び出しトレース: bpf_dispatcher_nop_func include/linux/bpf.h:1231 [inline] __bpf_prog_run include/linux/filter.h:651 [inline] bpf_prog_run include/linux/filter.h:658 [inline] bpf_prog_run_pin_on_cpu include/linux/filter.h:675 [inline] bpf_flow_dissect+0x15f/0x350 net/core/flow_dissector.c:991 bpf_prog_test_run_flow_dissector+0x39d/0x620 net/bpf/test_run.c:1359 bpf_prog_test_run kernel/bpf/syscall.c:4107 [inline] __sys_bpf+0xf8f/0x4560 kernel/bpf/syscall.c:5475 __do_sys_bpf kernel/bpf/syscall.c:5561 [inline] __se_sys_bpf kernel/bpf/syscall.c:5559 [inline] __x64_sys_bpf+0x73/0xb0 kernel/bpf/syscall.c:5559 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x3f/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b flow_keys の変数オフセットでポインター alu を拒否することで、これを修正します。パッチを適用すると、flow_keys で R7 ポインター演算が禁止されているプログラムが拒否されます。(CVE-2024-26589) - Linux カーネルでは、次の脆弱性が解決されています。bpf: bpf_tracing_prog_attach の再添付ブランチが修正されます。次のケースでは、attach_btf がないためクラッシュを引き起こす可能性があります。1) rawtp プログラムをロード 2) rawtp を target_fd として使用して fentry プログラムをロード 3) target_fd = 0 で fentry プログラムのトレーシングリンクを作成 4) 3 を繰り返します。最後の結果: - prog->aux->dst_trampoline == NULL - tgt_prog == NULL (target_fd を link_create に提供しなかったから) - prog->aux->attach_btf == NULL (プログラムが attach_prog_fd=X でロードされた) - プログラムは tgt_prog に対してロードされましたが、どのバグかを調べる方法がありません。BUG: カーネル NULL ポインターデリファレンス、アドレス: 0000000000000058 呼び出しトレース: ? __die+0x20/0x70 ? page_fault_oops+0x15b/0x430 ? fixup_exception+0x22/0x330 ? exc_page_fault+0x6f/0x170 ? asm_exc_page_fault+0x22/0x30 ? bpf_tracing_prog_attach+0x279/0x560 ? btf_obj_id+0x5/0x10 bpf_tracing_prog_attach+0x439/0x560 __sys_bpf+0x1cf4/0x2de0 __x64_sys_bpf+0x1c/0x30 do_syscall_64+0x41/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0x76 この状況では、-EINVAL を返します。 (CVE-2024-26591) - Linux カーネルでは、次の脆弱性が解決されています。ksmbd: ksmbd_tcp_new_connection() の UAF 問題を修正します。新しい TCP 接続の処理とその切断の間に競合があります。これは、ksmbd_tcp_new_connection() 関数の「struct tcp_transport」で UAF を引き起こします。(CVE-2024-26592) - Linux カーネルでは、次の脆弱性が解決されています。ksmbd: セッションセットアップで mech トークンを検証します。クライアントがセッションセットアップリクエストで無効な mech トークンを送信すると、ksmbd は検証して、それが無効な場合にエラーを作成します。(CVE-2024-26594) - Linux カーネルで、次の脆弱性が解決されています。net: qualcomm: rmnet_policy のグローバル oob が修正されます。変数 rmnet_link_ops は、*大きな* maxtype を割り当てます。これにより、netlink 属性を解析するときに、グローバルな領域外読み取りが引き起こされます。以下のバグトレースを参照してください。 ================================================================== 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 ffffffff92c438d0 by task syz-executor.6/84207 CPU: 0 PID: 84207 Comm: syz-executor.6 Tainted: G N 6.1.0 #3 ハードウェア名: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: __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 nla_parse_nested_deprecated include/net/netlink.h:1248 [inline] __rtnl_newlink+0x50a/0x1880 net/core/rtnetlink.c:3485 rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3594 rtnetlink_rcv_msg+0x43c/0xd70 net/core/rtnetlink.c:6091 netlink_rcv_skb+0x14f/0x410 net/netlink/af_netlink.c:2540 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:0x7fdcf2072359 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:00007fdcf13e3168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007fdcf219ff80 RCX: 00007fdcf2072359 RDX: 0000000000000000 RSI: 0000000020000200 RDI: 0000000000000003 RBP: 00007fdcf20bd493 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fffbb8d7bdf R14: 00007fdcf13e3300 R15: 0000000000022000 バグのあるアドレスは次の変数に属しています。rmnet_policy+0x30/0xe0 バグのあるアドレスは物理ページに属しています。page:0000000065bdeb3c refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x155243 flags: 0x200000000001000(reserved|node=0|zone=2) raw: 0200000000001000 ffffea00055490c8 ffffea00055490c8 0000000000000000 raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffffffff92c43780: f9 f9 f9 f9 00 00 00 02 f9 f9 f9 f9 00 00 00 07 ffffffff92c43800: f9 f9 f9 f9 00 00 00 05 f9 f9 f9 f9 06 f9 f9 f9 >ffffffff92c43880: f9 f9 f9 f9 00 00 00 00 00 00 f9 f9 f9 f9 f9 f9 ^ ffffffff92c43900: 00 00 00 00 00 00 00 00 07 f9 f9 f9 f9 f9 f9 f9 ffffffff92c43980: 00 00 00 07 f9 f9 f9 f9 00 00 00 05 f9 f9 f9 f9 According to the comment of `nla_parse_nested_deprecated`, the maxtype should be len(destination array) - 1. したがって、ここで「IFLA_RMNET_MAX」を使用します。(CVE-2024-26597) - 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 カーネルで、次の脆弱性が解決されました。pwm: of_pwm_single_xlate() の領域外アクセスを修正します args->args_count == 2 の場合に args->args[2] が定義されていません。実際には、フラグは args->args[1] に含まれています。(CVE-2024-26599) - 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 カーネルで、次の脆弱性は解決されています。ext4: fc 再生下でブロック解放が失敗した後に buddy を再生成します。これはほとんどがコミット 6bd97bf273bd を元に戻し (ext4: 冗長な mb_regenerate_buddy() を削除)、mb_regenerate_buddy() を再導入します。mb_free_blocks() のコードによると、高速コミットリプレイにより、すでにフリーブロックとしてマークされているブロックが最終的にマークされる可能性があります。これにより、バディービットマップが破損するため、その場合は再生成する必要があります。(CVE-2024-26601) - Linux カーネルでは、次の脆弱性が解決されています。af_unix: sk_diag_dump_icons() の lockdep 誤検出を修正します。syzbot は、lockdep スプラット [1] を報告しました。Blamed コミットは、lockdep 違反の可能性を示唆しており、コードは、lockdep を封じようとして unix_state_lock_nested() を使用していました。unix_state_lock_nested() は unix_state_double_lock() からすでに使用されているため、十分ではありません。別のサブクラスを使用する必要があります。このパッチは、より明確にするために個別の列挙を追加します。また、クリーンアップとして unix_state_double_lock() の swap() を使用します。v2: 不足している inline キーワードを unix_state_lock_nested() に追加します [1] 警告: 循環ロッキング依存関係の可能性が検出されました 6.8.0-rc1-syzkaller-00356-g8a696a29c690 #0 汚染されていません syz-executor.1/2542 がロックを取得しようとしています: ffff88808b5df9e8 (rlock-AF_UNIX){+.+.}-{2:2}、場所: skb_queue_tail+0x36/0x120 net/core/skbuff.c:3863 しかし、タスクはすでにロックを保持しています: ffff88808b5dfe70 (&u->lock/1){+.+.}-{2:2}、場所: unix_dgram_sendmsg+0xfc7/0x2200 net/unix/af_unix.c:2089 このロックはすでに新しいロックに依存しています。既存の依存関係チェーン (逆順) は次のとおりです。-> #1 (&u->lock/1){+.+.}-{2:2}: lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754 _raw_spin_lock_nested+0x31/0x40 kernel/locking/spinlock.c:378 sk_diag_dump_icons net/unix/diag.c:87 [inline] sk_diag_fill+0x6ea/0xfe0 net/unix/diag.c:157 sk_diag_dump net/unix/diag.c:196 [inline] unix_diag_dump+0x3e9/0x630 net/unix/diag.c:220 netlink_dump+0x5c1/0xcd0 net/netlink/af_netlink.c:2264 __netlink_dump_start+0x5d7/0x780 net/netlink/af_netlink.c:2370 netlink_dump_start include/linux/netlink.h:338 [inline] unix_diag_handler_dump+0x1c3/0x8f0 net/unix/diag.c:319 sock_diag_rcv_msg+0xe3/0x400 netlink_rcv_skb+0x1df/0x430 net/netlink/af_netlink.c:2543 sock_diag_rcv+0x2a/0x40 net/core/sock_diag.c:280 netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x7e6/0x980 net/netlink/af_netlink.c:1367 netlink_sendmsg+0xa37/0xd70 net/netlink/af_netlink.c:1908 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] sock_write_iter+0x39a/0x520 net/socket.c:1160 call_write_iter include/linux/fs.h:2085 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0xa74/0xca0 fs/read_write.c:590 ksys_write+0x1a0/0x2c0 fs/read_write.c:643 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b -> #0 (rlock-AF_UNIX){+.+.}-{2:2}: check_prev_add kernel/locking/lockdep.c:3134 [inline] check_prevs_add kernel/locking/lockdep.c:3253 [inline] validate_chain+0x1909/0x5ab0 kernel/locking/lockdep.c:3869 __lock_acquire+0x1345/0x1fd0 kernel/locking/lockdep.c:5137 lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162 skb_queue_tail+0x36/0x120 net/core/skbuff.c:3863 unix_dgram_sendmsg+0x15d9/0x2200 net/unix/af_unix.c:2112 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] ____sys_sendmsg+0x592/0x890 net/socket.c:2584 ___sys_sendmsg net/socket.c:2638 [inline] __sys_sendmmsg+0x3b2/0x730 net/socket.c:2724 __do_sys_sendmmsg net/socket.c:2753 [inline] __se_sys_sendmmsg net/socket.c:2750 [inline] __x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2750 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b これをデバッグするのに役立つ他の情報: 安全でないロックの可能性のあるシナリオ: CPU0 ---truncated--- (CVE-2024-26624) - 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 カーネルでは、次の脆弱性が解決されています。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 カーネルでは、以下の脆弱性は解決されています。drm/amdkfd: ロック依存関係の警告を修正します ============================ ========================= 警告: 循環ロック依存関係の可能性が 6.5.0-kfd-fkuehlin を検出しました #276 汚染されていません -------------------------------------------------- ---- kworker/8:2/2676 はロックの取得を試行しています: ffff9435aae95c88 ((work_completion)(&svm_bo->eviction_work)){+.+.}-{0:0}、場所: __flush_work+0x52/0x550 しかしタスクはすでにロックを保持しています。ffff9435cd8e1720 (&svms->lock){+.+.}-{3:3}、場所: svm_range_deferred_list_work+0xe8/0x340 [amdgpu] このロックはすでに新しいロックに依存しています。既存の依存関係チェーン (逆順): -> #2 (&svms->lock){+.+.}-{3:3}: __mutex_lock+0x97/0xd30 kfd_ioctl_alloc_memory_of_gpu+0x6d/0x3c0 [amdgpu] kfd_ioctl+0x1b2/0x5d0 [amdgpu] __x64_sys_ioctl+0x86/0xc0 do_syscall_64+0x39/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd -> #1 (&mm->mmap_lock){++++}-{3:3}: down_read+0x42/0x160 svm_range_evict_svm_bo_worker+0x8b/0x340 [amdgpu] process_one_work+0x27a/0x540 worker_thread+0x53/0x3e0 kthread+0xeb/0x120 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x11/0x20 -> #0 ((work_completion)(&svm_bo->eviction_work)){+.+.}-{0:0}: __lock_acquire+0x1426/0x2200 lock_acquire+0xc1/0x2b0 __flush_work+0x80/0x550 __cancel_work_timer+0x109/0x190 svm_range_bo_release+0xdc/0x1c0 [amdgpu] svm_range_free+0x175/0x180 [amdgpu] svm_range_deferred_list_work+0x15d/0x340 [amdgpu] process_one_work+0x27a/0x540 worker_thread+0x53/0x3e0 kthread+0xeb/0x120 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x11/0x20 これをデバッグするのに役立つその他の情報: チェーンの存在: (work_completion)(&svm_bo->eviction_work) --> &mm->mmap_lock --> &svms->lock 安全でないロックの可能性のあるシナリオ CPU0 CPU1 ---- ---- lock(&svms->lock); lock(&mm->mmap_lock); lock(&svms->lock); lock((work_completion)(&svm_bo->eviction_work))。BO refcount が 0 以外の場合にのみ mmap_read_lock を取るため、これは実際にはデッドロックにつながることはないと思います。これは、svm_range_bo_release が同時に実行されていないことを意味します。ただし、これに注釈を付ける良い方法はありません。この問題を回避するには、ワーカーではなく svm_range_schedule_evict_svm_bo で BO 参照を取得します。これにより、削除作業が保留中であり、svm_range_bo_release での cancel_work_sync 呼び出しを排除できる間に、BO が解放されることはありません。 v2: svm_bo_ref_unless_zero を使用し、それが安全である理由を説明しました。また、amdkfd_fence_enable_signaling ですでに行われている冗長なチェックを削除しました。(CVE-2024-26628) Nessus はこれらの問題をテストしておらず、代わりにアプリケーションが自己報告するバージョン番号にのみ依存していることに注意してください。

検出

プラグインの検索

high