リモートの SUSE Linux SLES15 ホストには、SUSE-SU-2024:0977-1 のアドバイザリに記載された複数の脆弱性の影響を受けるパッケージがインストールされています。 - Linux カーネルでは、次の脆弱性が解決されています。i2c: 潜在的な use-after-free を修正します。adap 構造は使用後にのみ解放されます。このパッチは、put_device() をわずかに下へ移動して use-after-free を回避します。[wsa: コードにコメントを追加、修正タグを追加] (CVE-2019-25162) - Linux カーネルでは、次の脆弱性は解決されています： fs/mount_setattr: always cleanup mount_kattr ビルドの際にとった参照の漏洩を防ぐために、成功したケースと失敗したケースの両方で mount_kattr がビルドされた後に finish_mount_kattr() が呼び出されることを確認してください発見しました。パス検索の失敗時に復帰したため、idmapped マウントがリクエストされたとき、mount_kattr のビルド時に取得した追加の参照が漏洩するリスクが生じました。(CVE-2021-46923) - Linux カーネルでは、次の脆弱性が解決されています。NFC: st21nfca: デバイスプローブのメモリ漏洩を修正し、削除します。「phy->pending_skb」はデバイスプローブで割り当てられても、エラー処理のパスで解放されず、パスは削除されません。これにより、次のようなメモリリークが発生します。未参照オブジェクト 0xffff88800bc06800 (size 512): comm 8, pid 11775, jiffies 4295159829 (age 9.032s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000d66c09ce>] __kmalloc_node_track_caller+0x1ed/0x450 [<00000000c93382b3>] kmalloc_reserve+0x37/0xd0 [<000000005fea522c>] __alloc_skb+0x124/0x380 [<0000000019f29f9a>] st21nfca_hci_i2c_probe+0x170/0x8f2 エラー内の 'pending_skb' を解放して削除し、これを修正します。(CVE-2021-46924) - Linux カーネルでは、次の脆弱性が解決されています。Input: appletouch - デバイス登録前に作業を初期化します。Syzbot が __flush_work() で警告を報告しました。この警告は、work->func == NULL によって発生します。これは、作業の初期化が行われていないことを意味します。これは、input_dev->close() が cancel_work_sync(&dev->work) を呼び出しますが、dev->work の初期化が _after_ input_register_device() 呼び出しで起こるために発生する可能性があります。したがって、このパッチでは、入力デバイスを登録する前に dev->work 初期化を移動します (CVE-2021-46932) - Linux カーネルでは、次の脆弱性が解決されています。i2c: compat ioctl でユーザーデータを検証します。ユーザーデータに誤りがあると、i2c_transfer() で警告が発生することがあります (例: ゼロ msgs など)。ユーザー空間は警告をトリガーできないため、このパッチで compact ioctl でユーザーデータの検証チェックを追加し、報告された警告を回避します (CVE-2021-46934) - Linux カーネルでは、次の脆弱性が解決されています。pinctrl: mediatek: global-out-of-bounds 問題を修正します。eint 仮想 eint 番号が gpio 番号より大きい場合、'desc[eint_n]' サイズの globle-out-of-bounds の問題が発生する可能性があります。(CVE-2021-47083) - Linux カーネルでは、以下の脆弱性が解決されています。vt: バッファで char を削除するときのメモリオーバーラッピングを修正します。長い行を削除する際に、メモリオーバーラッピングのコピーが発生します。宛先バッファがソースバッファと重複する場合、memcpy はその動作を保証しないため、scr_memcpyw が memcpy に対して最適化されていると、このメモリ重複コピーによってデータが破損する可能性があります。memcpy は結果が確定的ではないハードウェアアクセラレーションを利用するため、ラインバッファは常に破損しているとは限りません。 scr_memcpyw の scr_memmovew への置き換えを利用し、この問題を修正します。(CVE-2022-48627) - 一部の Intel(R) Atom(R) プロセッサの一部のレジスタファイルからの一時的な実行後のマイクロアーキテクチャ状態を介した情報漏洩により、認証されたユーザーがローカルアクセスを介して情報漏洩を可能にする可能性があります。(CVE-2023-28746) - Linux カーネルの netfilter: nf_tables コンポーネントに存在するメモリ解放後使用 (Use After Free) の脆弱性が悪用されると、ローカルの権限昇格が達成される可能性があります。同じトランザクション内のチェーンバインディングに対するルールの追加と削除により、メモリ解放後使用 (Use After Free) が引き起こされます。過去のコミット f15f29fd4779be8a418b66e9d52979bb6d6c2325 をアップグレードすることをお勧めします。(CVE-2023-5197) - ルーターは、大きすぎて次のホップに送信できない IPv6 パケットに遭遇すると、ICMP6 大きすぎるパケット (PTB) メッセージを送信者に返します。送信者はこの更新された Maximum Transmission Unit (MTU) をキャッシュし、その後同じホストにルーティングするときにこの値を超えないようにします。(CVE-2023-52340) - 6.7.4 までの Linux カーネルの drivers/md/dm-table.c 内の dm_table_create は、dm_ioctl.target_count 構造のチェックがないため、(alloc_targets で) INT_MAX バイトを超えて割り当てようとして、クラッシュする可能性があります。(CVE-2023-52429) - 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 カーネルでは、次の脆弱性が解決されています。メディア: 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 (信頼できない) による 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 バグのあるアドレスは、13kloc のサイズ 131072 のキャッシュ kmalloc-128k に属する c000000364e80000 のオブジェクトに属します。バグのあるアドレスは、割り当てられた 98256 バイトの領域[c000000364e80000、c000000364e97fd0) の右の 0 バイトに配置されています ================================================================== pseries-hotplug-mem: 0 でメモリをホットリムーブするのに失敗しました。失敗した検索を別のメッセージでログし、有効なエントリを指している場合にのみカーソルをデリファレンスします。(CVE-2023-52451) - Linux カーネルで、次の脆弱性が解決されています。bpf: 初期化されていないスタックスロットへのアクセスを修正します。権限のあるプログラムは、初期化されていないスタックメモリを (6715df8d5 以降はすべて) 読み取ることができると想定されていますが、このパッチより前は、これらのアクセスの許可は一貫して許可されているわけではありませんでした。特に、state->allocate_stack より上のアクセスは許可されましたが、それより下のアクセスは許可されませんでした。つまり、スタックがすでに十分に大きければアクセスが許可されましたが、そうでない場合は、スタックを拡大するのではなく、アクセスが拒否されていました。この望ましくない拒否は、- check_stack_slot_within_bounds() 内と check_stack_range_initialized() 内の 2 か所で発生しています。このパッチでは、これらのアクセスが許可されるように調整しています。古い拒否に依存していた一連のテストを変更する必要がありました。権限のない状態での実行も追加するようにすべて変更されており、そのため古い動作も維持されています。global_func16 という 1 つのテストは更新できませんでした。これは、他の理由により権限なしで実行できないためです。このパッチでは、可変オフセット読み取りのスタックサイズの追跡も修正します。この 2 番目の修正は、相互に関連しているため、最初の修正と同じコミットにバンドルされています。このパッチより前では、(固定の既知の値を持つレジスタではなく) 可変オフセットを含むレジスタを使用するスタックへの書き込みは、関数に必要とされるスタックサイズに適切に関与していませんでした。その結果、プログラムによる検証は可能でしたが、割り当てられたスタックが小さすぎるために領域外データをランタイムで読み取ろうとする可能性がありました。各関数は、bpf_subprog_info.stack_depth で必要なスタックのサイズを追跡します。これは update_stack_depth() によって維持されます。通常のメモリアクセスの場合、check_mem_access() は update_state_depth() を呼び出していましたが、オフセットレジスタの修正された部分のみを渡し、変数オフセットを無視していました。これは正しくなく、そのレジスタで可能な最小値を代わりに使用する必要があります。この追跡は、スタックサイズの追跡を grow_stack_state() で一元化し、grow_stack_state() の呼び出しを Andrii の提案どおり check_stack_access_within_bounds() に引き上げることによって修正されました。コードがよりシンプルになり、最大スタックサイズを説得力のある方法で正しく追跡できるようになりました。 check_stack_range_initialized() は、アクセスに十分なスタックが割り当てられたと想定できるため、最初の問題の修正に役立ちます。スタック深度の計算もチェックするように、いくつかのテストが変更されました。このパッチがなければ、verifier_var_off:stack_write_priv_vs_unpriv が失敗します。 (CVE-2023-52452) - 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 カーネルでは、次の脆弱性は解決されています。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 カーネルでは、次の脆弱性が解決されています。入力: powermate: powermate_config_complete の use-after-free を修正します。syzbot が powermate ドライバー内で use-after-free のバグ [1] を検出しました。これはデバイスが切断されたときに発生し、メモリが powermate_device 構造体から解放されます。 kfree とそのコールバックが呼び出された後に非同期コントロールメッセージが完了すると、ロックが存在しなくなるためバグが発生します。デバイスの切断時に、pm->config で usb_kill_urb() を使用して、進行中のリクエストをキャンセルします。[1] (https://syzkaller.appspot.com/bug?extid=0434ac83f907a1dbdd1e(CVE-2023-52475) - Linux カーネルで、次の脆弱性が解決されています。HID: logitech-hidpp: レシーバー USB 切断時のカーネルクラッシュを修正。hidpp_connect_event() は競合状態にある時 4 回の time-of-check vs time-of-use (TOCTOU) の競合状態が発生します。hidpp_connect_event() は主に作業キューから実行されますが、probe() でも実行されます。hidpp_connect_event() を実行しているスレッドがハードウェアで待機しているときに、デバイス接続パケットがハードウェアによって受信された場合は、probe() から 2 番目のスレッドで実行中の hidpp_connect_event() が作業キューから開始されます。これは以下の競合を開きます (以下のコードは簡略化されています)。1. プロトコルの取得 + 印刷 (無害な競合): if (!hidpp->protocol_major) {hidpp_root_get_protocol_version() hidpp->protocol_major = response.rap.params[0 ];この競合は実際に、接続された HID++ [] デバイスに添付された abrt 出力の dmesg で確認できます rhbz#2227968: [ 3064.624215] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5。[3064.658184] logitech-hidpp-device 0003:046D:4071.0049：HID++ 4.5 デバイスが接続されました。追加のロギングを追加してテストしたところ、この後 2 つのスレッドが順番に hw アクセス mutex (send_mutex) を取得するため、他のすべての TOCTOU のケースで ping-pong を行うことができます。(無害な競合) : if (hidpp->name == hdev->name) { ... hidpp->name = new_name; 3. バッテリーの power_suspend クラスの初期化 (問題あり！): hidpp_initialize_battery() { if (hidpp->battery.ps) が 0 を返します。probe_battery(); /* ブロック、スレッドが順番にこれを実行します */ hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_ emerge_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); 4. 遅延した input_device の作成 (問題がある可能性があります): if (hidpp->delayed_input) return; hidpp->delayed_input = hidpp_allocate_input(hdev);ここでの本当に大きな問題は 3 です。競合状態になると、次のシーケンスになります。hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); ... hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); そのため、同じバッテリーに対して 2 つの電源を登録しました。ユーザー空間の pov からは少し異常に見えますが、これは大きな問題ではありません。方法をご覧ください。1. これはすべて devm-maganaged です。2. hidpp->battery.desc 構造体は 2 つの電源で共有されています。3. hidpp->battery.desc.properties は 2 番目の devm_kmemdup() の結果を指し示しています。そのためレシーバーの USB 切断時に use-after-free が発生します。1. 最後に登録された電源クラスのデバイスが登録解除されます。2. 最後の devm_kmemdup() 呼び出しからのメモリが解放され、hidpp->battery.desc.properties が解放されたメモリを指すようになります。3. 最初に登録された電源クラスのデバイスが登録解除されます。これによって remove uevent もユーザー空間へ送信され、power_ emerge_uevent() が呼び出され、uevent データが入力されます。4. power_ emerge_uevent() は、hidpp->battery.desc.properties を使用します。これは次のように、解放されたメモリを指します。Sep 22 20:01:35 eric kernel: BUG: unable to handle page fault for address: ffffb2140e017f08 ... Sep 22 20:01:35 eric kernel: Workqueue: usb_hub_wq hub_event Sep 22 20:01:35 eric kernel: RIP: 0010:power_ emerge_uevent+0xee/0x1d0 ... Sep 22 20:01:35 eric kernel: ? asm_exc_page_fault+0x26/0x30 Sep 22 20:01:35 eric kernel: ? power_supply_uevent+0xee/0x1d0 Sep 22 20:01:35 eric kernel: ? power_supply_uevent+0x10d/0x1d0 Sep 22 20:01:35 eric kernel: dev_uevent+0x10f/0x2d0 Sep 22 20:01:35 eric kernel: kobject_uevent_env+0x291/0x680 Sep 22 20:01:35 eric kernel: ---truncated--- (CVE-2023-52478) - Linux カーネルでは、次の脆弱性が解決されています。x86/srso: Hygon プロセッサに SRSO 緩和策を追加します。Hygon プロセッサにも存在する投機的リターンスタックのオーバーフローの脆弱性に対して緩和策を追加します。(CVE-2023-52482) - Linux カーネルでは、次の脆弱性が解決されています。iommu/arm-smmu-v3: arm_smmu_mm_invalidate_range によってトリガーされるソフトロックアップを修正します。SVA ケースを実行すると、次のソフトロックアップがトリガーされます: -------------------------------------------------------------------- watchdog: BUG: ソフトロックアップ - CPU#244 26 秒間動かなくなりました。pstate: 83400009 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : arm_smmu_cmdq_issue_cmdlist+0x178/0xa50 lr : arm_smmu_cmdq_issue_cmdlist+0x150/0xa50 sp : ffff8000d83ef290 x29: ffff8000d83ef290 x28: 000000003b9aca00 x27: 0000000000000000 x26: ffff8000d83ef3c0 x25: da86c0812194a0e8 x24: 0000000000000000 x23: 0000000000000040 x22: ffff8000d83ef340 x21: ffff0000c63980c0 x20: 0000000000000001 x19: ffff0000c6398080 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: ffff3000b4a3bbb0 x14: ffff3000b4a30888 x13: ffff3000b4a3cf60 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc08120e4d6bc x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000048cfa x5 : 0000000000000000 x4 : 0000000000000001 x3 : 000000000000000a x2 : 0000000080000000 x1 : 0000000000000000 x0 : 0000000000000001 Call trace: arm_smmu_cmdq_issue_cmdlist+0x178/0xa50 __arm_smmu_tlb_inv_range+0x118/0x254 arm_smmu_tlb_inv_range_asid+0x6c/0x130 arm_smmu_mm_invalidate_range+0xa0/0xa4 __mmu_notifier_invalidate_range_end+0x88/0x120 unmap_vmas+0x194/0x1e0 unmap_region+0xb4/0x144 do_mas_align_munmap+0x290/0x490 do_mas_munmap+0xbc/0x124 __vm_munmap+0xa8/0x19c __arm64_sys_munmap+0x28/0x50 invoke_syscall+0x78/0x11c el0_svc_common.constprop.0+0x58/0x1c0 do_el0_svc+0x34/0x60 el0_svc+0x2c/0xd4 el0t_64_sync_handler+0x114/0x140 el0t_64_sync+0x1a4/0x1a8 -------------------------------------------------------------------- 6.6-rc1 以降、上記の arm_smmu_mm_invalidate_range は arm_smmu_mm_arch_invalidate_secondary_tlbs に名前が変更されていますが、問題は残っています。コミット 06ff87bae8d3 (arm64: mm: 未使用の関数と変数プロトタイプを削除) は、CPU MMU 側の同様のロックアップを修正しました。しかし、arm_smmu_mm_arch_invalidate_secondary_tlbs() は通常、MMU tlb flush 関数の次に呼び出されるため、SMMU でも発生する可能性があります。 tlb_flush_mmu_tlbonly { tlb_flush { __flush_tlb_range { // check MAX_TLBI_OPS } } mmu_notifier_arch_invalidate_secondary_tlbs { arm_smmu_mm_arch_invalidate_secondary_tlbs { // does not check MAX_TLBI_OPS } } } CMDQ_MAX_TLBI_OPS を tlbflush.h の MAX_TLBI_OPS から複製してください。SVA の場合に SMMU は CPU ページテーブルを使うため、tlbflush コードと合わせるのが合理的です。次に、リクエストサイズがこのしきい値に達した場合は、ページごとの TLBI コマンドを 1 つの asid ごとの TLBI コマンドで置き換えます。 (CVE-2023-52484) - Linux カーネルでは、次の脆弱性が解決されています。wifi: mac80211: 潜在的なキーの use-after-free を修正します。ieee80211_key_link() が ieee80211_gtk_rekey_add() によって呼び出されますが、KRACK 保護 (同一キーの再インストール) のために 0 が返されると、ieee80211_gtk_rekey_add() はそのまま潜在的な use-after-free のキーにポインターを返します。これは独自に KRACK 保護されている WoWLAN rekey オフロードの場合にのみ iwlwifi によって呼び出されるため、通常は発生しませんが、修正が推奨されます。そのためには、エラーコードを返し、それを cfg80211 境界でのみ実行できるようにし、ieee80211_gtk_rekey_add() の不適切な呼び出し元のエラーを残すように変換します。(CVE-2023-52530) - Linux カーネルでは、次の脆弱性が解決されています。wifi: iwlwifi: mvm: メモリ破損の問題を修正します。数行上では、スペースが sizeof(struct iwl_nvm_data) + sizeof(struct ieee80211_channel) + sizeof(struct ieee80211_rate) に対して kzalloc() されます。「mvm->nvm_data」は「struct iwl_nvm_data」であるため問題ありません。この構造の最後には、「channels」flex 配列があります。各要素のタイプは「struct ieee80211_channel」です。したがって、この配列には 1 つの要素のみが割り当てられます。次の場合に実行します。 mvm->nvm_data->bands[0].channels = mvm->nvm_data->channels; 「channels」flex 配列の最初の要素をポイントします。これで問題ありません。ただし、(u8 *) キャストのために mvm->nvm_data->bands[0].bitrates = (void *)((u8 *)mvm->nvm_data->channels + 1) を実行する場合、flex 配列の開始アドレスに 1 のみを追加します。直後に割り当てられた「struct ieee80211_rate」を指し示す場合と同じです。ポインター演算が想定どおりに動作するように偽のキャスティングを削除します。(CVE-2023-52531) - Linux カーネルでは、次の脆弱性が解決されています。iommu/vt-d: iommu_suspend() のメモリ割り当てを回避します。IRQ が無効な状態で、iommu_suspend() syscore の中断コールバックが呼び出されます。GFP_KERNEL フラグでメモリを割り当てると、中断コールバック中に IRQ が再度有効になることがあり、これによって次のカーネルトレースで断続的な中断/休止の問題が発生する可能性があります: Calling iommu_suspend+0x0/0x1d0 ------------[ cut here ]------------ WARNING: CPU: 0 PID: 15 at kernel/time/timekeeping.c:868 ktime_get+0x9b/0xb0 ... CPU: 0 PID: 15 Comm: rcu_preempt Tainted: G U E 6.3-intel #r1 RIP: 0010:ktime_get+0x9b/0xb0 ... Call Trace: tick_sched_timer+0x22/0x90 ? __pfx_tick_sched_timer+0x10/0x10 __hrtimer_run_queues+0x111/0x2b0 hrtimer_interrupt+0xfa/0x230 __sysvec_apic_timer_interrupt+0x63/0x140 sysvec_apic_timer_interrupt+0x7b/0xa0 asm_sysvec_apic_timer_interrupt+0x1f/0x30 ... ------------[ここでカット ]------------ Interrupts enabled after iommu_suspend+0x0/0x1d0 WARNING: CPU: 0 PID: 27420 at drivers/base/syscore.c:68 syscore_suspend+0x147/0x270 CPU: 0 PID: 27420 Comm: rtcwake Tainted: G U W E 6.3-intel #r1 RIP: 0010:syscore_suspend+0x147/0x270 ... Call Trace: hibernation_snapshot+0x25b/0x670 hibernate+0xcd/0x390 state_store+0xcf/0xe0 kobj_attr_store+0x13/0x30 sysfs_kf_write+0x3f/0x50 kernfs_fop_write_iter+0x128/0x200 vfs_write+0x1fd/0x3c0 ksys_write+0x6f/0xf0 __x64_sys_write+0x1d/0x30 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc 4 ワードのメモリのみが必要な場合、iommu_suspend() のメモリ割り当てを回避します。(CVE-2023-52559) - Linux カーネルの ATA over Ethernet (AoE) ドライバーに欠陥が見つかりました。aoecmd_cfg_pkts() 関数は「struct net_device」の refcnt を不適切に更新し、構造体での解放と「skbtxq」グローバルキューを介したアクセスとの間の競合によってメモリ解放後使用 (Use After Free) を発生させる可能性があります。これは、サービス拒否またはコードの実行につながる可能性があります。(CVE-2023-6270) - Linux カーネルの netfilter: nf_tables コンポーネントに存在するメモリ解放後使用 (Use After Free) の脆弱性が悪用されると、ローカルの権限昇格が達成される可能性があります。関数 nft_pipapo_walk は、セットのウォーク中に非アクティブな要素をスキップしなかったため、PIPAPO (Pile Packet Policies) 要素の二重非アクティベーションが発生し、メモリ解放後使用 (use-after-free) につながる可能性がありました。過去のコミット 317eb9685095678f2c9f5a8189de698c5354316a へのアップグレードを推奨します。(CVE-2023-6817) - Linux カーネルの Netfilter サブシステムで欠陥が発見されました。問題は nft_byteorder_eval() 関数にあり、コードがループを繰り返して「dst」配列に書き込みます。各反復で 8 バイトが書き込まれますが、「dst」は u32 の配列であるため、各要素には 4 バイト分のスペースしかありません。つまり、反復するたびに前の要素の一部が上書きされ、この u32 の配列が破損してしまいます。この欠陥により、ローカルユーザーがサービス拒否を引き起こしたり、NetFilter の機能を破壊したりする可能性があります。(CVE-2024-0607) - Linux カーネルの Open vSwitch サブコンポーネントで、脆弱性が報告されました。この欠陥は、コードプッシュの再帰操作が再帰的にコードブロックを呼び出すときに発生します。OVS モジュールがスタックの深さを検証しないため、多くのフレームをプッシュし、スタックオーバーフローが発生します。その結果、クラッシュまたはその他の関連する問題が発生する可能性があります。(CVE-2024-1151) - 6.7.1 までの Linux カーネルの net/rds/af_rds.c の rds_recv_track_latency に、RDS_MSG_RX_DGRAM_TRACE_MAX の比較に off-by-one のエラーがあり、領域外アクセスが発生する可能性があります。(CVE-2024-23849) - 6.7.1 までの、Linux カーネルの fs/btrfs/disk-io.c の btrfs_get_root_ref では、アサーション失敗およびクラッシュが発生する可能性があります。これは、サブボリューム作成時に、サブボリュームのルート項目が挿入された後すぐサブボリュームが読み取られる可能性があるためです。(CVE-2024-23850) - 6.7.1 までの Linux カーネルの drivers/md/dm-ioctl.c の copy_params は、param_kernel->data_size チェックがないため、INT_MAX バイトを超える割り当てを試みてクラッシュする可能性があります。これは、ctl_ioctl に関連しています。(CVE-2024-23851) - Linux カーネルでは、次の脆弱性が解決されています。tls: tx 作業スケジュールとソケットクローズの間の競合を修正します。以前のコミットと同様、送信中のスレッド (recvmsg/sendmsg) が、非同期暗号ハンドラーが complete() を呼び出すとすぐに終了する可能性があります。complete() を呼び出す前に作業のスケジュールを並べ替えます。これは、送信スレッドが行うことの逆の順序であるため、第一に、より論理的に思えます。(CVE-2024-26585) - Linux カーネルでは、次の脆弱性が解決されています。mlxsw: spectrum_acl_tcam: スタック破損を修正します。tc フィルターが最初にネットデバイスに追加されると、対応するローカルポートがデバイスの ACL グループにバインドされます。グループには ACL のリストが含まれます。次に、各 ACL は、フィルターが保存されている異なる TCAM 領域を指し示します。転送中、一致が見つかるまで ACL が順番に評価されます。フィルターを異なる領域に配置する理由の 1 つは、優先順位を下げ、順番を変えて追加し、キーの用途により 2 つの連続するフィルターが同じ領域に収まらないようにするためです。Spectrum-2 以降の ASIC では、ファームウェアが、グループ内の ACL の最大数が 16 を超えると報告するようになりましたが、ACL グループを設定するレジスタのレイアウト (PAGT) は、それを説明するように更新されていませんでした。したがって、グループに 16 を超える ACL が必要なまれなケースでは、スタック破損 [1] に達する可能性があります。最大 ACL グループサイズを、ファームウェアが報告する値と PAGT レジスタに適合する最大 ACL との間の最小値に制限することで、修正します。テストケースを追加して、この状態に達したときにマシンがクラッシュしないことを確認します。[1] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: mlxsw_sp_acl_tcam_group_update+0x116/0x120 [...] dump_stack_lvl+0x36/0x50 panic+0x305/0x330 __stack_chk_fail+0x15/0x20 mlxsw_sp_acl_tcam_group_update+0x116/0x120 mlxsw_sp_acl_tcam_group_region_attach+0x69/0x110 mlxsw_sp_acl_tcam_vchunk_get+0x492/0xa20 mlxsw_sp_acl_tcam_ventry_add+0x25/0xe0 mlxsw_sp_acl_rule_add+0x47/0x240 mlxsw_sp_flower_replace+0x1a9/0x1d0 tc_setup_cb_add+0xdc/0x1c0 fl_hw_replace_filter+0x146/0x1f0 fl_change+0xc17/0x1360 tc_new_tfilter+0x472/0xb90 rtnetlink_rcv_msg+0x313/0x3b0 netlink_rcv_skb+0x58/0x100 netlink_unicast+0x244/0x390 netlink_sendmsg+0x1e4/0x440 ____sys_sendmsg+0x164/0x260 ___sys_sendmsg+0x9a/0xe0 __sys_sendmsg+0x7a/0xc0 do_syscall_64+0x40/0xe0 entry_SYSCALL_64_after_hwframe+0x63/0x6b (CVE-2024-26586) - 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 カーネルでは、以下の脆弱性が解決されています。i2c: i801: ブロックプロセス呼び出しトランザクションを修正してます。Intel データシートによると、ソフトウェアはブロックプロセス呼び出しトランザクションのブロックバッファインデックスを 2 回リセットしなければなりません。バッファに送信データを書き込む前とバッファから着信データを読み取る前です。ドライバーには現在 2 番目のリセットがないため、ブロックバッファの誤った部分が読み取られます。(CVE-2024-26593) - Linux カーネルでは、次の脆弱性が解決されています: mlxsw: spectrum_acl_tcam: エラーパスの NULL ポインターデリファレンスを修正します。ACL グループに領域を添付することに失敗した後にエラーパスから mlxsw_sp_acl_tcam_region_destroy() を呼び出すと、「region->group->tcam」で NULL ポインターデリファレンスになります [1]。mlxsw_sp_acl_to_tcam() を使用して 'tcam' ポインターを取得します。[1] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] RIP: 0010:mlxsw_sp_acl_tcam_region_destroy+0xa0/0xd0 [...] Call Trace: mlxsw_sp_acl_tcam_vchunk_get+0x88b/0xa20 mlxsw_sp_acl_tcam_ventry_add+0x25/0xe0 mlxsw_sp_acl_rule_add+0x47/0x240 mlxsw_sp_flower_replace+0x1a9/0x1d0 tc_setup_cb_add+0xdc/0x1c0 fl_hw_replace_filter+0x146/0x1f0 fl_change+0xc17/0x1360 tc_new_tfilter+0x472/0xb90 rtnetlink_rcv_msg+0x313/0x3b0 netlink_rcv_skb+0x58/0x100 netlink_unicast+0x244/0x390 netlink_sendmsg+0x1e4/0x440 ____sys_sendmsg+0x164/0x260 ___sys_sendmsg+0x9a/0xe0 __sys_sendmsg+0x7a/0xc0 do_syscall_64+0x40/0xe0 entry_SYSCALL_64_after_hwframe+0x63/0x6b (CVE-2024-26595) - 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 カーネルでは、次の脆弱性は解決されています。sched/membarrier: sys_membarrier を攻撃する機能が低下します。一部のシステムでは、sys_membarrier が非常に負荷が高く、すべてにおいて全体的な速度低下を引き起こす可能性があります。そのため、アクセスをシリアル化するためにパスにロックを設定し、これが高すぎる頻度で呼び出されてマシンを飽和する機能を回避します。(CVE-2024-26602) - Linux カーネルで、次の脆弱性が解決されています。x86/fpu: 情報についてユーザー空間に依存することを止め、xsave バッファで障害を発生させないようにします。この変更前は、ユーザー空間バッファの予想されるサイズは fx_sw->xstate_size から取得されていました。fx_sw->xstate_size はユーザー空間から変更できるため、次のような状況で sigreturn フレームの構築が可能でした。* fx_sw->xstate_size が、fx_sw->xfeatures の有効なビットによって必要とされるサイズよりも小さい。* ユーザー空間が sigrame fpu バッファの一部のマッピングを解除し、xrstor が必要とするバッファの一部にアクセスできない。この場合、xrstor はマッピングされていない領域を復元してアクセスしようとするため、障害が発生します。しかし、buf + fx_sw->xstate_size がまだマップされている領域内にあり、戻って xrstor を再試行するため、fault_in_readable は成功します。これは無限ループになります。代わりに、XRSTOR が操作できる最大サイズに障害があります (fpstate->user_size から取得)。[dhansen: 件名の調整/変更ログ] (CVE-2024-26603) - Linux カーネルでは、次の脆弱性が解決されています。drm/bridge：sii902x：プローブ競合の問題を修正します sii9022 bridge：[53.271356] sii902x_get_edid+0x34/0x70 [sii902x] ] [ 53.276066] sii902x_bridge_get_edid+0x14/0x20 [sii902x] [53.281381] drm_bridge_get_edid+0x20/0x34 [drm] [ 53.286305] drm_bridge_connector_get_modes+0x8c/0xcc [drm_kms_helper] [ 53.292955] drm_helper_probe_single_connector_modes+0x190/0x538 [drm_kms_helper] [53.300510drm_client_modeset_probe+0x1f0/0xbd4 [drm] [ 53.305958] __drm_fb_helper_initial_config_and_unlock+0x50/0x510 [drm_kms_helper] [ 53.313611] drm_fb_helper_initial_config+0x48/0x58 [drm_kms_helper] [ 53.320039] drm_fbdev_dma_client_hotplug+0x84/0xd4 [drm_dma_helper] [ 53.326401] drm_client_register+0x5c/0xa0 [drm] [53.331216] drm_fbdev_dma_setup+ 0xc8/0x13c [drm_dma_helper] [ 53.336881] tidss_probe+0x128/0x264 [tidss] [53.341174] platform_probe+0x68/0xc4 [ 53.344841] real_probe+0x188/0x3c4 [ 53.348501] __driver_probe_device+0x7c/0x16c [ 53.352854] driver_probe_device+0x3c/0x10c [ 53.357033] __device_attach_driver+0xbc/0x158 [ 53.361472] bus_for_each_drv+0x88/0xe8 [ 53.365303] __device_attach+0xa0/0x1b4 [53.369135] device_initial_probe+0x14/0x20 [53.373314] bus_probe_device+0xb0/0xb4 [53.377145] deferred_probe_work_func+0xcc/0x124 [53.381757] process_one_work+0x1f0/0x518 [53.385770] worker_thread+0x1e8/0x3dc [53.389519] kthread+0x11c/0x120 [53.392750] ret_from_fork+0x10/0x20 ここでの問題は次のとおりです: - tidss プローブがありますが、sii902x がないため延期されます。- sii902x はプローブを開始し、sii902x_init() を開始します。- sii902x は drm_bridge_add() を呼び出します。これで、DRM の見地からの sii902x ブリッジの準備が整いました。sii902x が sii902x_audio_codec_init() と platform_device_register_data() を呼び出します。オーディオプラットフォームデバイスの登録により、延期されたデバイスのプローブが発生します。tidss がプローブされ、これによって最終的に sii902x_bridge_get_edid() が呼び出されます。sii902x_bridge_get_edid() は、i2c を使用して edid を読み取ろうとします。ただし、sii902x ドライバーは i2c パーツをまだ設定していないため、クラッシュが発生します。drm_bridge_add() を sii902x_init() の最後に移動して修正します。これは、sii902x_probe() の最後でもあります。 (CVE-2024-26607) - Linux カーネルでは、次の脆弱性が解決されています。tomoyo: tomoyo_write_control() の UAF 書き込みバグを修正します。長い行の write() がリクエストされたとき、tomoyo_write_control() は head->write_buf を更新するので、head->io_sem が保留された後 head->write_buf を取得する必要があります。そうしないと、write() の同時リクエストが use-after-free-write と二重解放の問題を引き起こす可能性があります。(CVE-2024-26622) Nessus はこれらの問題をテストしておらず、代わりにアプリケーションが自己報告するバージョン番号にのみ依存していることに注意してください。

バージョン 1.1 Apr 18, 2024, 3:14 PM CVSSv2 score source (changed from "CVE-2024-26589" to "CVE-2024-26598") Plugin Feed: 202404181514
バージョン 1.0 Mar 23, 2024, 11:39 AM New Plugin Feed: 202403231139

検出

SUSE SLES15 セキュリティ更新 : kernel (SUSE-SU-2024:0977-1)

high Nessus プラグイン ID 192490

バージョン 1.1

バージョン 1.0