SUSE SLES15 セキュリティ更新 : kernel (SUSE-SU-2024:0857-1)
high Nessus プラグイン ID 192014
Language:
概要
リモートの SUSE ホストに 1 つ以上のセキュリティ更新がありません。説明
リモートの SUSE Linux SLES15 / SLES_SAP15 ホストには、SUSE-SU-2024:0857-1 のアドバイザリに記載された複数の脆弱性の影響を受けるパッケージがインストールされています。- Linux カーネルでは、次の脆弱性が解決されています。i2c: 潜在的な use-after-free を修正します。adap 構造は使用後にのみ解放されます。このパッチは、put_device() をわずかに下へ移動して use-after-free を回避します。[wsa: コードにコメントを追加、修正タグを追加] (CVE-2019-25162)
- Linux カーネルでは、次の脆弱性が解決されています。media: dvbdev: dvb_media_device_free() のメモリリークを修正します。dvb_media_device_free() はメモリをリークしています。include/media/media-device.h に記載されているとおり、NULL に設定する前に「dvbdev->adapter->conn」を解放します。media_entity インスタンス自体は、必要に応じてドライバーによって明示的に解放する必要があります。(CVE-2020-36777)
- Linux カーネルでは、次の脆弱性が解決されています。net: hso: tty デバイス登録解除中の null-ptr-deref を修正します。複数の tty が同じマイナー番号を要求しようと試みるため、同じデバイスでの登録解除の重複が発生します。最初の登録解除は成功しますが、次の登録解除では null-ptr-deref が発生します。get_free_serial_index() 関数から利用可能なマイナー番号が返されますが、すぐには割り当てられません。割り当ては、後で呼び出し元が行います。しかし、この割り当ての前は、get_free_serial_index() を呼び出すと、同じマイナー番号が返されます。これを修正するには、get_free_serial_index を修正して、該当するマイナー番号が判明したら直ちにそれを割り当て、その機能をより適切に示すように名前を get_minor() に変更します。同様に、set_serial_by_index() の名前を release_minor() に変更し、指定された hso_serial のマイナー番号を解放するよう変更します。すべての obtain_minor() には、対応する release_minor() 呼び出しが必要です。(CVE-2021-46904)
- Linux カーネルでは、次の脆弱性が解決されています。net: hso: 切断回帰の NULL-deref を修正します。コミット 8a12f8836145 (net: hso: tty デバイス登録解除中の null-ptr-deref を修正) は、syzbot によって報告された、際どいマイナーな割り当てを修正しましたが、代わりに、毎回の切断に対して無条件の NULL ポインターデリファレンスが導入されました。具体的には、hso_serial_tty_unregister() によってマイナーが解放された後は、シリアルデバイステーブルにアクセスできなくなります。(CVE-2021-46905)
- Linux カーネルでは、次の脆弱性が解決されています。HID: usbhid: hid_submit_ctrl の情報漏洩を修正します。hid_submit_ctrl() では、レポートの長さ計算の方法に、report->size がゼロになる可能性が考慮されません。syzkaller 再生装置を実行している場合、サイズが 0 のレポートにより、hid_submit_ctrl) が transfer_buffer_length を 16384 として計算します。この urb が usb コアレイヤーに渡されると、KMSAN が 16384 バイトの情報漏洩を報告します。これを修正するには、まず hid_report_len() を修正し、除算に DIV_ROUND_UP を使用してレポートサイズがゼロの場合に対応させます。次にこれを hid_submit_ctrl() から呼び出します。(CVE-2021-46906)
- Linux カーネルでは、次の脆弱性が解決されています。netfilter: nft_limit: nft_limit_init div_u64() が u64 を u32 で除算する除算エラーを回避します。nft_limit_init() は u64 を u64 で除算するので、適切な math 関数 (div64_u64) を使用します。除算エラー: 0000 [#1] PREEMPT SMP KASAN CPU: 1 PID: 8390 Comm: syz-executor188 Not tainted 5.12.0-rc4-syzkaller #0 ハードウェア名: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:div_u64_rem include/linux/math64.h:28 [inline] RIP: 0010:div_u64 include/linux/math64.h:127 [inline] RIP: 0010:nft_limit_init+0x2a2/0x5e0 net/netfilter/nft_limit.c:85 Code: ef 4c 01 eb 41 0f 92 c7 48 89 de e8 38 a5 22 fa 4d 85 ff 0f 85 97 02 00 00 e8 ea 9e 22 fa 4c 0f af f3 45 89 ed 31 d2 4c 89 f0 <49> f7 f5 49 89 c6 e8 d3 9e 22 fa 48 8d 7d 48 48 b8 00 00 00 00 00 RSP: 0018:ffffc90009447198 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000200000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff875152e6 RDI: 0000000000000003 RBP:
ffff888020f80908 R08: 0000200000000000 R09: 0000000000000000 R10: ffffffff875152d8 R11: 0000000000000000 R12: ffffc90009447270 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS:
000000000097a300(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033 CR2: 00000000200001c4 CR3: 0000000026a52000 CR4: 00000000001506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
0000000000000400 呼出しトレース: nf_tables_newexpr net/netfilter/nf_tables_api.c:2675 [inline] nft_expr_init+0x145/0x2d0 net/netfilter/nf_tables_api.c:2713 nft_set_elem_expr_alloc+0x27/0x280 net/netfilter/nf_tables_api.c:5160 nf_tables_newset+0x1997/0x3150 net/netfilter/nf_tables_api.c:4321 nfnetlink_rcv_batch+0x85a/0x21b0 net/netfilter/nfnetlink.c:456 nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:580 [inline] nfnetlink_rcv+0x3af/0x420 net/netfilter/nfnetlink.c:598 netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927 sock_sendmsg_nosec net/socket.c:654 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:674 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2350 ___sys_sendmsg+0xf3/0x170 net/socket.c:2404 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2433 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xae (CVE-2021-46915)
- 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 カーネルでは、次の脆弱性が解決されています。sctp: call_rcu を使用してエンドポイントを解放します。このパッチでは、call_rcu() を呼び出すことでエンドポイントの解放を遅らせ、sctp_sock_dump() 内の別の use-after-free の問題を修正します: BUG: KASAN: use-after-free in __lock_acquire+0x36d9/0x4c20 Call Trace:
__lock_acquire+0x36d9/0x4c20 kernel/locking/lockdep.c:3218 lock_acquire+0x1ed/0x520 kernel/locking/lockdep.c:3844 __raw_spin_lock_bh include/linux/spinlock_api_smp.h:135 [inline]
_raw_spin_lock_bh+0x31/0x40 kernel/locking/spinlock.c:168 spin_lock_bh include/linux/spinlock.h:334 [inline] __lock_sock+0x203/0x350 net/core/sock.c:2253 lock_sock_nested+0xfe/0x120 net/core/sock.c:2774 lock_sock include/net/sock.h:1492 [inline] sctp_sock_dump+0x122/0xb20 net/sctp/diag.c:324 sctp_for_each_transport+0x2b5/0x370 net/sctp/socket.c:5091 sctp_diag_dump+0x3ac/0x660 net/sctp/diag.c:527
__inet_diag_dump+0xa8/0x140 net/ipv4/inet_diag.c:1049 inet_diag_dump+0x9b/0x110 net/ipv4/inet_diag.c:1065 netlink_dump+0x606/0x1080 net/netlink/af_netlink.c:2244 __netlink_dump_start+0x59a/0x7c0 net/netlink/af_netlink.c:2352 netlink_dump_start include/linux/netlink.h:216 [inline] inet_diag_handler_cmd+0x2ce/0x3f0 net/ipv4/inet_diag.c:1170 __sock_diag_cmd net/core/sock_diag.c:232 [inline] sock_diag_rcv_msg+0x31d/0x410 net/core/sock_diag.c:263 netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2477 sock_diag_rcv+0x2a/0x40 net/core/sock_diag.c:274 この問題は、アソシエーションがピールオフされたときに発生し、旧 sk は asoc->base.sk による取得後、lock_sock(sk) の呼び出し前に解放されます。
sk ホルダーとして sk を解放することを防ぐには、lock_sock() を呼び出す際に ep を動作させておく必要があります。このパッチは、call_rcu() を使用し、sock_put と ep free を sctp_endpoint_destroy_rcu() に移動します。これにより、sctp_transport_traverse_process() の rcu_read_lock で ep を安全に保留できます。sctp_endpoint_hold() が true を返した場合、この ep がまだアクティブであり、保留していたもので、ダンプを続行できることを意味します。false を返した場合、この ep は無効であり、rcu_read_unlock の後に解放できるためスキップします。sctp_sock_dump() で sk をロックした後、この ep が tsp->asoc->ep と異なる場合は、ダンプ中に、この asoc が lock_sock() を呼び出す前にピールオフされており、sk をスキップする必要があることを意味します。この ep が tsp->asoc->ep と同じである場合、この asoc ではピールオフは発生せず、lock_sock により、今後も release_sock までピールオフが発生しないことを意味します。ポートの解放は call_rcu() を呼び出す前に sctp_endpoint_destroy() で発生するため、エンドポイントの解放を遅延させてもポートのリリースは遅延しません。また、call_rcu() によってエンドポイントを解放すると、sctp_assocs_seq_show() および sctp_rcv() の asoc->base.sk による sk へのアクセスが安全になります。
Jones 氏にこの問題の提起を感謝します。v1->v2: 変更ログを改善します。Jakub 氏が述べたとおり、kfree(ep) を sctp_endpoint_destroy_rcu() に追加します。(CVE-2021-46929)
- 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 カーネルでは、次の脆弱性が解決されています。ACPI: GTDT: watchdow プローブエラーでは割り込みマッピングは破損されません。無効なファームウェアプロパティのためにドライバープローブが失敗する場合、GTDT ドライバーは、以前にマップした割り込みのマッピングを解除します。ただし、割り込みのマッピングが実際に成功したかどうかはチェックされません。さらに、GIC SGI 範囲と重複する不正な割り込み番号がファームウェアによって報告された場合、IPI のマッピングが解除され、Dann Frazier 氏による報告のとおり続いて fireworks が発生する可能性があります。ドライバーを修正して動作をわずかに正し、マッピング解除の前に割り込みがマッピングされているかどうかを実際にチェックします。(CVE-2021-46953)
- Linux カーネルでは、次の脆弱性が解決されています。sscsi: qla2xxx: 追加の IRQ ベクトルを予約します。コミット a6dcfe08487e (scsi: qla2xxx: 割り込みベクトルを CPU の数に制限する) が、CPU の数に割り当てられる MSI-X ベクトルを減らします。これは、qla83xx_iospace_config()、qla24xx_enable_msix()、および qla2x00_iospace_config() でベクトル割り当ての前提に反しています。いずれの関数でも、qpair の最大数は次のように計算されます。ha->max_qpairs = ha->msix_count - 1 (MB 割り込み) - 1 (デフォルトの応答キュー) - 1 (ATIO、デュアルまたはピュアターゲットモード) CPU が 2 つありイニシエーターモードの場合は max_qpairs をゼロに設定します。その後、この番号は qla2x00_alloc_queues() 内で ha->queue_pair_map を割り当てるために使用されます。割り当ては発生せず、ha->queue_pair_map は NULL のままですが、ドライバーでは使用可能なキューのペアがあると見なされます。qla2xxx_queuecommand() は、マップおよびクラッシュで qpair を見つけようとします: if (ha->mqenable) {uint32_t tag; uint16_t hwq; struct qla_qpair *qpair = NULL; tag = blk_mq_unique_tag(cmd->request); hwq = blk_mq_unique_tag_to_hwq(tag); qpair = ha->queue_pair_map[hwq]; # <- HERE if (qpair) return qla2xxx_mqueuecommand(host, cmd, qpair); } BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops:
0000 [#1] SMP PTI CPU: 0 PID: 72 Comm: kworker/u4:3 Tainted: G W 5.10.0-rc1+ #25 ハードウェア名: QEMU Standard PC (Q35+ ICH9, 2009), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014 Workqueue: scsi_wq_7 fc_scsi_scan_rport [scsi_transport_fc] RIP: 0010:qla2xxx_queuecommand+0x16b/0x3f0 [qla2xxx] Call Trace:
scsi_queue_rq+0x58c/0xa60 blk_mq_dispatch_rq_list+0x2b7/0x6f0 ? __sbitmap_get_word+0x2a/0x80
__blk_mq_sched_dispatch_requests+0xb8/0x170 blk_mq_sched_dispatch_requests+0x2b/0x50
__blk_mq_run_hw_queue+0x49/0xb0 __blk_mq_delay_run_hw_queue+0xfb/0x150 blk_mq_sched_insert_request+0xbe/0x110 blk_execute_rq+0x45/0x70 __scsi_execute+0x10e/0x250 scsi_probe_and_add_lun+0x228/0xda0 __scsi_scan_target+0xf4/0x620 ? __pm_runtime_resume+0x4f/0x70 scsi_scan_target+0x100/0x110 fc_scsi_scan_rport+0xa1/0xb0 [scsi_transport_fc] process_one_work+0x1ea/0x3b0 worker_thread+0x28/0x3b0 ? process_one_work+0x3b0/0x3b0 kthread+0x112/0x130 ? kthread_park+0x80/0x80 ret_from_fork+0x22/0x30 ドライバーは、すべての CPU に独自の HW キューを提供し、予約済み (MB、RSP、ATIO) 割り込みを処理するのに十分なベクトルを割り当てる必要があります。この変更により、デュアルコア VM でのクラッシュが修正され、nr_hw_queues が CPU の数よりも 2 少ない場合に発生する、不均衡な QP 割り当てが回避されます。(CVE-2021-46964)
- Linux カーネルでは、次の脆弱性が解決されています。ACPI: custom_method: 潜在的な use-after-free の問題を修正します。cm_write() では、buf が関数の終端に達すると常に解放されます。リクエストされたカウントが table.length 未満の場合、割り当てられたバッファは解放されますが、cm_write() への後続の呼び出しで引き続きアクセスが試みられます。関数の末尾にある無条件の kfree(buf) を削除し、-EINVAL エラーパスで buf を NULL に設定して、関数の残りの部分と一致させます。(CVE-2021-46966)
- Linux カーネルでは、次の脆弱性が解決されています。s390/zcrypt：zcard および zqueue のホットアンプラグのメモリリークを修正します kvm および kmemdebug カーネルを使用したテストで、埋め込まれた kref カウンターの get/put との不一致のため、適切に解放されません。この修正により、kref カウンターの処理が調整されるようになりました。init では、kref カウンターは 1 から始まります。リリースをトリガーしてオブジェクトを解放するには、カードまたはキューの登録解除でこの初期値をゼロまで低下させる必要があります。(CVE-2021-46968)
- Linux カーネルでは、次の脆弱性が解決されています。bpf: 負の dst レジスタでのマスキング否定ロジックを修正します。off_reg が dst レジスタにある場合の否定ロジックは正しくなく、加算を単に減算、あるいはその逆に反転することはできません。修正としては、最後のビット単位の and-op を無条件で off_reg から AX に対して実行し、次にポインターを src から dst に移動し、最終的に AX を元のポインター算術演算のソースとして使用し、反転によって正しい結果が得られるようにします。即時ベースの操作ではないため、定数のブラインディングでこれを保持している場合は、その間の単一の非 AX mov が可能です。(CVE-2021-46974)
- Linux カーネルでは、次の脆弱性が解決されています。hfsplus: 縮小する切り捨ての破損を防ぎます。コミット 31651c607151 によって導入された問題がいくつかあると思われます (hfsplus: ファイル切り捨てのデッドロックを回避) HFS+ には、常に 8 つのエクステントを含むエクステントレコードがあります。カタログファイルの最初のエクステントレコードがいっぱいになった場合、エクステントオーバーフローファイルから新しいレコードが割り当てられます。エクステントオーバーフローファイル内にあるエクステントレコードの中間で縮小切り捨てが発生する場合、hfsplus_file_truncate() のロジックが変更されており、hfs_brec_remove() の呼び出しが保護されなくなっています。正しいアクションは、hfsplus_free_extents() を呼び出してエクステントレコード内の新しいサイズを超えるエクステントを解放し、エクステントレコード全体を削除するかどうかをチェックすることです。ただし、ガード (blk_cnt > start) は hfs_brec_remove() 呼び出しの後になっているため、最後に一致したエクステントレコードが無条件に削除されるという残念な影響があります。この問題を再現するには、少なくとも 10 のエクステントのあるファイルを作成し、最後のエクステントレコードの途中で縮小切り捨てを実行して、残りのエクステントの数が 8 未満または 8 で割り切れないようにします。これにより、最後のエクステントレコード (8 つのエクステント) が途中で切り捨てられずに完全に削除されます。そのため、これが破損やデータ損失の原因になります。これに対する修正は、新しく切り捨てられた終端がこのエクステントレコードの開始以降であるかどうかを単にチェックするだけで、完全なエクステントレコードを安全に削除できるようにします。ただし、->tree_lock をドロップしているため、hfs_brec_remove() への呼び出しを前の場所には移動できず、これによって競合状態が発生し、キャッシュされた情報が無効になり、ノードデータが破損する可能性があります。別の問題もこれに関連しています。ブロックに入るとき (blk_cnt > start)、->tree_lock が保持されていません。ロックを保持していないループから抜け出せますが、hfs_find_exit() によってロックが解除されます。他の誰かがロックを取得してしまうかどうかは不明ですが、デバッグが困難なエラーが発生したり、早期にロック解除される可能性があります。実際のリスクがなくても、ロックのバランスは常に維持する必要があります。そのため、チェックの直前にロックを取得します。(CVE-2021-46989)
- Linux カーネルでは、次の脆弱性が解決されています。PCI: エンドポイント: ->get_features() の NULL ポインターデリファレンスを修正しました。pci_epc_ops の get_features ops が NULL を返し、pci_epf_test_alloc_space 関数で NULL ポインターデリファレンスを引き起こすことがあります。このような NULL ポインターデリファレンスを回避し、pci_epc_feature が見つからない場合は -ENOTSUPP を返すようにするには、アクセスする前に pci_epf_test_bind に pci_epc_feature ポインターに対するチェックを追加します。パッチが適用されず、EPC 機能がプラットフォームドライバーに実装されていない場合、カーネル NULL ポインターデリファレンスによる次のダンプが発生します。call trace:
pci_epf_test_bind+0xf4/0x388 pci_epf_bind+0x3c/0x80 pci_epc_epf_link+0xa8/0xcc configfs_symlink+0x1a4/0x48c vfs_symlink+0x104/0x184 do_symlinkat+0x80/0xd4
__arm64_sys_symlinkat+0x1c/0x24 el0_svc_common.constprop.3+0xb8/0x170 el0_svc_handler+0x70/0x88 el0_svc+0x8/0x640 Code: d2800581 b9403ab9 f9404ebb 8b394f60 (f9400400) ---[ end trace a438e3c5a24f9df0]--- (CVE-2021-47005)
- Linux カーネルでは、次の脆弱性が解決されています。RDMA/siw: siw_alloc_mr の use-after-free を修正します。当社のコードアナライザーにより、UAF が報告されました。siw_alloc_mr() では、siw_mr_add_mem(mr,..) を呼び出します。siw_mr_add_mem() の実装では、mem が mr->mem に割り当てられ、xa_alloc_circicic() が失敗すると kfree(mem) を介して mem が解放されます。ここで、mr->mem は引き続き解放されたオブジェクトを指し示しています。その後、この実行は siw_alloc_mr の err_out ブランチまで続き、解放された mr->mem は siw_mr_drop_mem(mr) で使用されます。使用中のパッチが mr->mem = mem を if (xa_alloc_cyclic(..)<0) {} の背後に移動し、uaf を回避します。(CVE-2021-47012)
- Linux カーネルでは、次の脆弱性が解決されています。net:emac/emac-mac: emac_mac_tx_buf_send の use-after-free を修正します。emac_mac_tx_buf_send で、これが emac_tx_fill_tpd(..,skb,..) を呼び出します。emac_tx_fill_tpd() でエラーが発生した場合、skb は dev_kfree_skb(skb) を介して emac_tx_fill_tpd() のエラーブランチで解放されます。ただし、解放された skb は引き続き skb->len を介して netdev_sent_queue(,skb->len) に使用されています。emac_tx_fill_tpd() が skb->len の値を変更していないことを確認できたため、使用中のパッチにより、想定される解放の前に skb->len が「len」に割り当てられ、後で skb->len の代わりに「len」が使用されます。(CVE-2021-47013)
- Linux カーネルでは、次の脆弱性が解決されています。bus: qcom: 戻る前に子ノードを配置します。戻る前に子ノードを配置し、参照カウントの漏洩の可能性を修正します。一般に、子の参照カウントは for_each_available_child_of_node() マクロで自動的に増減されますが、ループ本体でループが破損している場合は手動でカウントする必要があります。(CVE-2021-47054)
- Linux カーネルでは、次の脆弱性が解決されています。KVM: バスが破壊された場合、Coalesced MMIO ゾーンの検索を停止します。kvm_io_bus_unregister_dev() でバスの新しいインスタンスへのメモリの割り当てが失敗する場合、Coalesced MMIO ゾーンのウォークを中止します。新しいバスをインスタンス化できない場合、unregister_dev() はターゲットデバイスを除くすべてのデバイスを破壊します。ただし、呼び出し側には、バスを消去し、バス上にあったすべてのデバイスに対してデストラクターを呼び出したことは通知されません。Coalesced MMIO では、これによって (ウォーク内の) 将来のエントリが削除された後に coalesced_zones で繰り返し処理を継続しようとすると、削除されたリストエントリの逆参照が発生する可能性があります。多数の行を含んでいても、guts が単一の if ステートメントであるため括弧なしで忍び込む for ループに波括弧を使いやすいように追加します。
(CVE-2021-47060)
- Linux カーネルでは、次の脆弱性が解決されています。KVM: SRCU の同期後の登録解除エラーで I/O バスデバイスを破壊します。デバイスの登録解除中に I/O バスの新しいインスタンスの割り当てが失敗する場合は、すべてのリーダーが新しい NULL バスを確認するまでデバイスの破壊を待ちます。リーダーは、バスの参照上のデバイスが有効なままであると想定しているため、バスが無効になる前にデバイスを破壊すると、use-after-free を引き起こす可能性があります。(CVE-2021-47061)
- Linux カーネルでは、次の脆弱性が解決されています。ipc/mqueue、msg、sem: 期限が切れた後のスタック参照への依存を回避します。do_mq_timedreceive は、スタックローカルアドレスで wq_sleep を呼び出します。送信者 (do_mq_timedsend) はこのアドレスを使用して、後で pipelined_send を呼び出します。これにより、トリガーが非常に困難になる競合が発生し、do_mq_timedreceive 呼び出しが戻り、do_mq_timedsend を無効なアドレスに依存させ、以下のクラッシュが発生する可能性があります。RIP: 0010:wake_q_add_safe+0x13/0x60 Call Trace:
__x64_sys_mq_timedsend+0x2a9/0x490 do_syscall_64+0x80/0x680 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP:
0033:0x7f5928e40343 競合は次のように発生します。1. do_mq_timedreceive が関数スタック上の「struct ext_wait_queue」のアドレス (ここでは「ewq_addr」とエイリアスされます) で wq_sleep を呼び出し、
スタックが上書きされていない限り、有効な「struct ext_wait_queue*」を保持します。2.「ewq_addr」が wq_add の info->e_wait_q[RECV].list に追加され、do_mq_timedsend が wq_get_first_waiter (info, RECV) を介してこれを受信し、__pipelined_op を呼び出します。3.
送信者が __pipelined_op::smp_store_release(&this->state, STATE_READY) を呼び出します。ここから競合期間が始まります。(「this」は「ewq_addr」です) 4. レシーバーが do_mq_timedreceive::wq_sleep でウェイクアップすると、「state == STATE_READY」と表示されてブレークします。5. do_mq_timedreceive が戻されると、「ewq_addr」は do_mq_timedreceive のスタック上にあったために「struct ext_wait_queue *」であるとは保証されなくなりました。(ただし、アドレスは、別の関数に利用されるまで上書きされない、つまり無期限に持続する可能性があります) 6. do_mq_timedsend::__pipelined_op() は「ewq_addr」を「struct ext_wait_queue *」とみなすため、これを使用して task_struct を検索し、wake_q_add_safe 呼び出しに渡します。「ewq_addr」がまだ上書きされていなければ、「ewq_addr->task」が適切な task_struct になります。上書きされていれば、__pipelined_op::wake_q_add_safe がレシーバーの task_struct として偽造のアドレスを渡され、クラッシュの原因になります。do_mq_timedsend::__pipelined_op() は、STATE_READY の設定後に「this」を逆参照しません。これは、レシーバーの戻る側が空いたためです。レシーバーのスタック上にある「this」を逆参照するのではなく、get_task_struct によって返されるレシーバーの task_struct で wake_q_add_safe を呼び出すように __pipelined_op を変更します。Manfred 氏が指摘したように、競合は ipc/msg.c::expunge_all および ipc/sem.c::wake_up_sem_queue_prepare にも存在する可能性があります。これらも同様に修正します。
(CVE-2021-47069)
- Linux カーネルでは、次の脆弱性が解決されています。RDMA/rxe: 無効な lkey が提供された場合に CQE エラーを返します。RXE に、LOCAL_WRITE エラーの WQE ステータスの更新がありません。これにより、明らかに間違った lkey でアトミック操作が送信された場合に、次のカーネルパニックが発生していました。[leonro@vm ~]$ mkt test test_atomic_invalid_lkey (tests.test_atomic.AtomicTest) ... WARNING: CPU: 5 PID: 263 at drivers/infiniband/sw/rxe/rxe_comp.c:740 rxe_completer+0x1a6d/0x2e30 [rdma_rxe] Modules linked in:
crc32_generic rdma_rxe ip6_udp_tunnel udp_tunnel rdma_ucm rdma_cm ib_umad ib_ipoib iw_cm ib_cm mlx5_ib ib_uverbs ib_core mlx5_core ptp pps_core CPU: 5 PID: 263 Comm: python3 Not tainted 5.13.0-rc1+ #2936 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org04/01/2014 RIP: 0010:rxe_completer+0x1a6d/0x2e30 [rdma_rxe] Code: 03 0f 8e 65 0e 00 00 3b 93 10 06 00 00 0f 84 82 0a 00 00 4c 89 ff 4c 89 44 24 38 e8 2d 74 a9 e1 4c 8b 44 24 38 e9 1c f5 ff ff <0f> 0b e9 0c e8 ff ff b8 05 00 00 00 41 bf 05 00 00 00 e9 ab e7 ff RSP: 0018:ffff8880158af090 EFLAGS: 00010246 RAX:
0000000000000000 RBX: ffff888016a78000 RCX: ffffffffa0cf1652 RDX: 1ffff9200004b442 RSI: 0000000000000004 RDI: ffffc9000025a210 RBP: dffffc0000000000 R08: 00000000ffffffea R09: ffff88801617740b R10:
ffffed1002c2ee81 R11: 0000000000000007 R12: ffff88800f3b63e8 R13: ffff888016a78008 R14: ffffc9000025a180 R15: 000000000000000c FS: 00007f88b622a740(0000) GS:ffff88806d540000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f88b5a1fa10 CR3: 000000000d848004 CR4: 0000000000370ea0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6:
00000000fffe0ff0 DR7: 0000000000000400 Call Trace: rxe_do_task+0x130/0x230 [rdma_rxe] rxe_rcv+0xb11/0x1df0 [rdma_rxe] rxe_loopback+0x157/0x1e0 [rdma_rxe] rxe_responder+0x5532/0x7620 [rdma_rxe] rxe_do_task+0x130/0x230 [rdma_rxe] rxe_rcv+0x9c8/0x1df0 [rdma_rxe] rxe_loopback+0x157/0x1e0 [rdma_rxe] rxe_requester+0x1efd/0x58c0 [rdma_rxe] rxe_do_task+0x130/0x230 [rdma_rxe] rxe_post_send+0x998/0x1860 [rdma_rxe] ib_uverbs_post_send+0xd5f/0x1220 [ib_uverbs] ib_uverbs_write+0x847/0xc80 [ib_uverbs] vfs_write+0x1c5/0x840 ksys_write+0x176/0x1d0 do_syscall_64+0x3f/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae (CVE-2021-47076)
- Linux カーネルでは、次の脆弱性が解決されています。RDMA/rxe: 作成に失敗した場合、すべての QP フィールドをクリアします。rxe_qp_do_cleanup() は正しく作成されたものについては、QP の有効なポインター値を利用しますが、rxe_qp_from_init() が失敗した場合はガベージが入力され、次のエラーが発生します。
refcount_t: underflow; use-after-free. WARNING: CPU: 1 PID: 12560 at lib/refcount.c:28 refcount_warn_saturate+0x1d1/0x1e0 lib/refcount.c:28 Modules linked in: CPU: 1 PID: 12560 Comm: syz-executor.4 Not tainted 5.12.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:refcount_warn_saturate+0x1d1/0x1e0 lib/refcount.c:28 Code: e9 db fe ff ff 48 89 df e8 2c c2 ea fd e9 8a fe ff ff e8 72 6a a7 fd 48 c7 c7 e0 b2 c1 89 c6 05 dc 3a e6 09 01 e8 ee 74 fb 04 <0f> 0b e9 af fe ff ff 0f 1f 84 00 00 00 00 00 41 56 41 55 41 54 55 RSP:
0018:ffffc900097ceba8 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000040000 RSI: ffffffff815bb075 RDI: fffff520012f9d67 RBP: 0000000000000003 R08:
0000000000000000 R09: 0000000000000000 R10: ffffffff815b4eae R11: 0000000000000000 R12: ffff8880322a4800 R13: ffff8880322a4940 R14: ffff888033044e00 R15: 0000000000000000 FS: 00007f6eb2be3700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2:
00007fdbe5d41000 CR3: 000000001d181000 CR4: 00000000001506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace:
__refcount_sub_and_test include/linux/refcount.h:283 [inline] __refcount_dec_and_test include/linux/refcount.h:315 [inline] refcount_dec_and_test include/linux/refcount.h:333 [inline] kref_put include/linux/kref.h:64 [inline] rxe_qp_do_cleanup+0x96f/0xaf0 drivers/infiniband/sw/rxe/rxe_qp.c:805 execute_in_process_context+0x37/0x150 kernel/workqueue.c:3327 rxe_elem_release+0x9f/0x180 drivers/infiniband/sw/rxe/rxe_pool.c:391 kref_put include/linux/kref.h:65 [inline] rxe_create_qp+0x2cd/0x310 drivers/infiniband/sw/rxe/rxe_verbs.c:425 _ib_create_qp drivers/infiniband/core/core_priv.h:331 [inline] ib_create_named_qp+0x2ad/0x1370 drivers/infiniband/core/verbs.c:1231 ib_create_qp include/rdma/ib_verbs.h:3644 [inline] create_mad_qp+0x177/0x2d0 drivers/infiniband/core/mad.c:2920 ib_mad_port_open drivers/infiniband/core/mad.c:3001 [inline] ib_mad_init_device+0xd6f/0x1400 drivers/infiniband/core/mad.c:3092 add_client_context+0x405/0x5e0 drivers/infiniband/core/device.c:717 enable_device_and_get+0x1cd/0x3b0 drivers/infiniband/core/device.c:1331 ib_register_device drivers/infiniband/core/device.c:1413 [inline] ib_register_device+0x7c7/0xa50 drivers/infiniband/core/device.c:1365 rxe_register_device+0x3d5/0x4a0 drivers/infiniband/sw/rxe/rxe_verbs.c:1147 rxe_add+0x12fe/0x16d0 drivers/infiniband/sw/rxe/rxe.c:247 rxe_net_add+0x8c/0xe0 drivers/infiniband/sw/rxe/rxe_net.c:503 rxe_newlink drivers/infiniband/sw/rxe/rxe.c:269 [inline] rxe_newlink+0xb7/0xe0 drivers/infiniband/sw/rxe/rxe.c:250 nldev_newlink+0x30e/0x550 drivers/infiniband/core/nldev.c:1555 rdma_nl_rcv_msg+0x36d/0x690 drivers/infiniband/core/netlink.c:195 rdma_nl_rcv_skb drivers/infiniband/core/netlink.c:239 [inline] rdma_nl_rcv+0x2ee/0x430 drivers/infiniband/core/netlink.c:259 netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927 sock_sendmsg_nosec net/socket.c:654 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:674 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2350
___sys_sendmsg+0xf3/0x170 net/socket.c:2404 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2433 do_syscall_64+0x3a/0xb0 arch/x86/entry/common.c:47 entry_SYSCALL_64_after_hwframe+0 ---truncated--- (CVE-2021-47078)
- Linux カーネルでは、次の脆弱性が解決されています。pinctrl: mediatek: global-out-of-bounds 問題を修正します。eint 仮想 eint 番号が gpio 番号より大きい場合、'desc[eint_n]' サイズの globle-out-of-bounds の問題が発生する可能性があります。(CVE-2021-47083)
- sock.c の lock_sock_nested では、競合状態によるメモリ解放後使用 (Use-After-Free) の可能性があります。これにより、システム実行権限が必要なローカルでの権限昇格が引き起こされる可能性があります。ユーザー操作が不要な悪用が可能です。製品: Android。バージョン: Android kernel。Android ID: A-174846563References: Upstream kernel (CVE-2022-20154)
- Linux カーネルでは、以下の脆弱性が解決されています。vt: バッファで char を削除するときのメモリオーバーラッピングを修正します。長い行を削除する際に、メモリオーバーラッピングのコピーが発生します。宛先バッファがソースバッファと重複する場合、memcpy はその動作を保証しないため、scr_memcpyw が memcpy に対して最適化されていると、このメモリ重複コピーによってデータが破損する可能性があります。memcpy は結果が確定的ではないハードウェアアクセラレーションを利用するため、ラインバッファは常に破損しているとは限りません。
scr_memcpyw の scr_memmovew への置き換えを利用し、この問題を修正します。(CVE-2022-48627)
- この CVE は Intel によって割り当てられました。詳細については、CVE.org の CVE-2023-28746 を参照してください。
(CVE-2023-28746)
- 6.3.8までの Linux カーネルで問題が発見されました。drivers/net/ethernet/renesas/ravb_main.c の ravb_remove に、メモリ解放後使用 (Use-After-Free) が見つかりました。(CVE-2023-35827)
- 6.5.9 より前の Linux カーネルには、net/nfc/nci/spi.c の send_acknowledge に NULL ポインターデリファレンスがあります。(CVE-2023-46343)
- 6.4.12 より前の Linux カーネルでは、drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c の amdgpu_cs_wait_all_fences にメモリ解放後使用 (use-after-free) があります。(CVE-2023-51042)
- ルーターは、大きすぎて次のホップに送信できない 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 呼び出しトレース: <TASK> ? 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 </TASK> ---[ 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 カーネルでは、次の脆弱性が解決されています。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 カーネルでは、次の脆弱性は解決されています。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 カーネルでは、次の脆弱性が解決されています。入力: 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 カーネルでは、次の脆弱性が解決されています。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 カーネルでは、次の脆弱性が解決されています。net: mana: TX CQE エラー処理を修正します。未知の TX CQE エラータイプ (おそらく新しいハードウェアのもの) については引き続き SKB を解放し、キューの末尾等を更新します。そうでない場合、説明に誤りが生じます。また、破損したパケットのインジェクションによって TX エラーがトリガーされる可能性があるため、WARN_ONCE をレート制限したエラーログに置き換えます。(CVE-2023-52532)
- Linux カーネルでは、次の脆弱性が解決されています。btrfs: 遅延 dir インデックス項目の挿入に失敗した後に、BUG() を削除します。遅延 dir インデックス項目の遅延ノードツリーへの挿入に失敗したとき、BUG() を呼び出すのではなく、以前に割り当て/取得したすべてのリソースを解放し、エラーを呼び出し元に返すことができます。すべての既存の呼び出しチェーンは、(トランザクションコミットパスで保留中のスナップショットを作成する場合) btrfs_insert_delayed_dir_index() または BUG_ON を呼び出す前に行ったことをすべて元に戻すため、問題ありません。そのため、BUG() 呼び出しを削除し、適切なエラー処理を行います。これは、以下にリンクされている syzbot レポートに関連していますが、BUG() の発生を防ぐだけであり、複数の異なるインデックス項目に対して同じインデックス番号を 2 回使用しようとする問題は是正されないため、レポートは修正されません。
(CVE-2023-52569)
- Linux カーネルでは、次の脆弱性が解決されています。team: チームのデバイスタイプが変更される際に、null-ptr-deref を修正します。再生装置 [1] で次のように null-ptr-deref バグを取得します。BUG: kernel NULL pointer dereference, address: 0000000000000228 ... RIP: 0010:vlan_dev_hard_header+0x35/0x140 [8021q] ... Call Trace: <TASK> ? __die+0x24/0x70 ? page_fault_oops+0x82/0x150 ? exc_page_fault+0x69/0x150 ? asm_exc_page_fault+0x26/0x30 ? vlan_dev_hard_header+0x35/0x140 [8021q] ? vlan_dev_hard_header+0x8e/0x140 [8021q] neigh_connected_output+0xb2/0x100 ip6_finish_output2+0x1cb/0x520 ? nf_hook_slow+0x43/0xc0 ? ip6_mtu+0x46/0x80 ip6_finish_output+0x2a/0xb0 mld_sendpack+0x18f/0x250 mld_ifc_work+0x39/0x160 process_one_work+0x1e6/0x3f0 worker_thread+0x4d/0x2f0 ? __pfx_worker_thread+0x10/0x10 kthread+0xe5/0x120 ?
__pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 [1] $ teamd -t team0 -d -c '{runner: {name: loadbalance}}' $ ip link add name t-dummy type dummy $ ip link add link t-dummy name t-dummy.100 type vlan id 100 $ ip link add name t-nlmon type nlmon $ ip link set t-nlmon master team0 $ ip link set t-nlmon nomaster $ ip link set t-dummy up $ ip link set team0 up $ ip link set t-dummy.100 down $ ip link set t-dummy.100 master team0 チームデバイスに vlan デバイスをスレーブし、チームデバイスのタイプが non-ether から ether に変更されると、チームデバイスの header_ops が vlan_header_ops に変更されます。これは正しくなく、チームデバイスが vlan デバイスではないため、vlan_dev_hard_header() で vlan->real_dev に対して null-ptr-deref が発生します。team_setup() で eth_header_ops をキャッシュしてから、タイプが non-ether から ether に変更されたときに、キャッシュされた header_ops をチームネットデバイスの header_ops に割り当てて、バグを修正します。(CVE-2023-52574)
- 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 カーネルで、次の脆弱性が解決されています。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 カーネルの netfilter: nf_tables コンポーネントに存在するメモリ解放後使用 (Use After Free) の脆弱性が悪用されると、ローカルの権限昇格が達成される可能性があります。関数 nft_pipapo_walk は、セットのウォーク中に非アクティブな要素をスキップしなかったため、PIPAPO (Pile Packet Policies) 要素の二重非アクティベーションが発生し、メモリ解放後使用 (use-after-free) につながる可能性がありました。過去のコミット 317eb9685095678f2c9f5a8189de698c5354316a へのアップグレードを推奨します。(CVE-2023-6817)
- Linux カーネルの drivers/vhost/vhost.c の vhost_new_msg に脆弱性が見つかりました。vhost/vhost.c:vhost_new_msg() 関数における、仮想ゲストとホストオペレーティングシステムの間で渡されるメッセージでメモリを適切に初期化しません。この問題により、/dev/vhost-netデバイスファイルからの読み取り時に、ローカルの特権ユーザーが一部のカーネルメモリの内容を読み取る可能性があります。(CVE-2024-0340)
- 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 カーネルの 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 のページ違反を処理できません [...] 呼び出しトレース: <TASK> 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 カーネルでは、以下の脆弱性が解決されています。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 カーネルでは、次の脆弱性は解決されています。sched/membarrier: sys_membarrier を攻撃する機能が低下します。一部のシステムでは、sys_membarrier が非常に負荷が高く、すべてにおいて全体的な速度低下を引き起こす可能性があります。そのため、アクセスをシリアル化するためにパスにロックを設定し、これが高すぎる頻度で呼び出されてマシンを飽和する機能を回避します。(CVE-2024-26602)
- 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 はこれらの問題をテストしておらず、代わりにアプリケーションが自己報告するバージョン番号にのみ依存していることに注意してください。
ソリューション
影響を受けるパッケージを更新してください。参考資料
https://bugzilla.suse.com/1200599
https://bugzilla.suse.com/1207653
https://bugzilla.suse.com/1212514
https://bugzilla.suse.com/1213456
https://bugzilla.suse.com/1216223
https://bugzilla.suse.com/1218195
https://bugzilla.suse.com/1218689
https://bugzilla.suse.com/1218915
https://bugzilla.suse.com/1219127
https://bugzilla.suse.com/1219128
https://bugzilla.suse.com/1219146
https://bugzilla.suse.com/1219295
https://bugzilla.suse.com/1219653
https://bugzilla.suse.com/1219827
https://bugzilla.suse.com/1219835
https://bugzilla.suse.com/1219915
https://bugzilla.suse.com/1220009
https://bugzilla.suse.com/1220140
https://bugzilla.suse.com/1220187
https://bugzilla.suse.com/1220238
https://bugzilla.suse.com/1220240
https://bugzilla.suse.com/1220241
https://bugzilla.suse.com/1220243
https://bugzilla.suse.com/1220250
https://bugzilla.suse.com/1220253
https://bugzilla.suse.com/1220255
https://bugzilla.suse.com/1220328
https://bugzilla.suse.com/1220330
https://bugzilla.suse.com/1220344
https://bugzilla.suse.com/1220398
https://bugzilla.suse.com/1220409
https://bugzilla.suse.com/1220416
https://bugzilla.suse.com/1220418
https://bugzilla.suse.com/1220421
https://bugzilla.suse.com/1220436
https://bugzilla.suse.com/1220444
https://bugzilla.suse.com/1220459
https://bugzilla.suse.com/1220469
https://bugzilla.suse.com/1220482
https://bugzilla.suse.com/1220526
https://bugzilla.suse.com/1220538
https://bugzilla.suse.com/1220570
https://bugzilla.suse.com/1220572
https://bugzilla.suse.com/1220599
https://bugzilla.suse.com/1220627
https://bugzilla.suse.com/1220641
https://bugzilla.suse.com/1220649
https://bugzilla.suse.com/1220660
https://bugzilla.suse.com/1220689
https://bugzilla.suse.com/1220700
https://bugzilla.suse.com/1220735
https://bugzilla.suse.com/1220736
https://bugzilla.suse.com/1220737
https://bugzilla.suse.com/1220742
https://bugzilla.suse.com/1220745
https://bugzilla.suse.com/1220767
https://bugzilla.suse.com/1220796
https://bugzilla.suse.com/1220825
https://bugzilla.suse.com/1220826
https://bugzilla.suse.com/1220831
https://bugzilla.suse.com/1220845
https://bugzilla.suse.com/1220860
https://bugzilla.suse.com/1220863
https://bugzilla.suse.com/1220870
https://bugzilla.suse.com/1220917
https://bugzilla.suse.com/1220918
https://bugzilla.suse.com/1220930
https://bugzilla.suse.com/1220931
https://bugzilla.suse.com/1220932
https://bugzilla.suse.com/1221039
https://bugzilla.suse.com/1221040
http://www.nessus.org/u?fa461192
https://www.suse.com/security/cve/CVE-2019-25162
https://www.suse.com/security/cve/CVE-2020-36777
https://www.suse.com/security/cve/CVE-2020-36784
https://www.suse.com/security/cve/CVE-2021-46904
https://www.suse.com/security/cve/CVE-2021-46905
https://www.suse.com/security/cve/CVE-2021-46906
https://www.suse.com/security/cve/CVE-2021-46915
https://www.suse.com/security/cve/CVE-2021-46924
https://www.suse.com/security/cve/CVE-2021-46929
https://www.suse.com/security/cve/CVE-2021-46932
https://www.suse.com/security/cve/CVE-2021-46934
https://www.suse.com/security/cve/CVE-2021-46953
https://www.suse.com/security/cve/CVE-2021-46964
https://www.suse.com/security/cve/CVE-2021-46966
https://www.suse.com/security/cve/CVE-2021-46968
https://www.suse.com/security/cve/CVE-2021-46974
https://www.suse.com/security/cve/CVE-2021-46989
https://www.suse.com/security/cve/CVE-2021-47005
https://www.suse.com/security/cve/CVE-2021-47012
https://www.suse.com/security/cve/CVE-2021-47013
https://www.suse.com/security/cve/CVE-2021-47054
https://www.suse.com/security/cve/CVE-2021-47060
https://www.suse.com/security/cve/CVE-2021-47061
https://www.suse.com/security/cve/CVE-2021-47069
https://www.suse.com/security/cve/CVE-2021-47076
https://www.suse.com/security/cve/CVE-2021-47078
https://www.suse.com/security/cve/CVE-2021-47083
https://www.suse.com/security/cve/CVE-2022-20154
https://www.suse.com/security/cve/CVE-2022-48627
https://www.suse.com/security/cve/CVE-2023-28746
https://www.suse.com/security/cve/CVE-2023-35827
https://www.suse.com/security/cve/CVE-2023-46343
https://www.suse.com/security/cve/CVE-2023-51042
https://www.suse.com/security/cve/CVE-2023-52340
https://www.suse.com/security/cve/CVE-2023-52429
https://www.suse.com/security/cve/CVE-2023-52439
https://www.suse.com/security/cve/CVE-2023-52443
https://www.suse.com/security/cve/CVE-2023-52445
https://www.suse.com/security/cve/CVE-2023-52448
https://www.suse.com/security/cve/CVE-2023-52449
https://www.suse.com/security/cve/CVE-2023-52451
https://www.suse.com/security/cve/CVE-2023-52463
https://www.suse.com/security/cve/CVE-2023-52475
https://www.suse.com/security/cve/CVE-2023-52478
https://www.suse.com/security/cve/CVE-2023-52482
https://www.suse.com/security/cve/CVE-2023-52502
https://www.suse.com/security/cve/CVE-2023-52530
https://www.suse.com/security/cve/CVE-2023-52531
https://www.suse.com/security/cve/CVE-2023-52532
https://www.suse.com/security/cve/CVE-2023-52569
https://www.suse.com/security/cve/CVE-2023-52574
https://www.suse.com/security/cve/CVE-2023-52597
https://www.suse.com/security/cve/CVE-2023-52605
https://www.suse.com/security/cve/CVE-2023-6817
https://www.suse.com/security/cve/CVE-2024-0340
https://www.suse.com/security/cve/CVE-2024-0607
https://www.suse.com/security/cve/CVE-2024-1151
https://www.suse.com/security/cve/CVE-2024-23849
https://www.suse.com/security/cve/CVE-2024-23851
https://www.suse.com/security/cve/CVE-2024-26585
https://www.suse.com/security/cve/CVE-2024-26586
https://www.suse.com/security/cve/CVE-2024-26589
https://www.suse.com/security/cve/CVE-2024-26593
https://www.suse.com/security/cve/CVE-2024-26595
https://www.suse.com/security/cve/CVE-2024-26602
プラグインの詳細
深刻度: High
ID: 192014
ファイル名: suse_SU-2024-0857-1.nasl
バージョン: 1.1
タイプ: local
エージェント: unix
ファミリー: SuSE Local Security Checks
公開日: 2024/3/13
更新日: 2024/3/19
サポートされているセンサー: Agentless Assessment, Frictionless Assessment Agent, Frictionless Assessment AWS, Frictionless Assessment Azure, Nessus Agent, Nessus
リスク情報
VPR
リスクファクター: High
スコア: 7.4
CVSS v2
リスクファクター: Medium
基本値: 4.4
現状値: 3.3
ベクトル: CVSS2#AV:L/AC:M/Au:N/C:P/I:P/A:P
CVSS スコアのソース: CVE-2022-20154
CVSS v3
リスクファクター: High
基本値: 7.8
現状値: 6.8
ベクトル: CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
現状ベクトル: CVSS:3.0/E:U/RL:O/RC:C
CVSS スコアのソース: CVE-2024-26589
脆弱性情報
CPE: p-cpe:/a:novell:suse_linux:cluster-md-kmp-default, p-cpe:/a:novell:suse_linux:dlm-kmp-default, p-cpe:/a:novell:suse_linux:gfs2-kmp-default, p-cpe:/a:novell:suse_linux:kernel-64kb, p-cpe:/a:novell:suse_linux:kernel-64kb-devel, p-cpe:/a:novell:suse_linux:kernel-default, p-cpe:/a:novell:suse_linux:kernel-default-base, p-cpe:/a:novell:suse_linux:kernel-default-devel, p-cpe:/a:novell:suse_linux:kernel-default-livepatch, p-cpe:/a:novell:suse_linux:kernel-default-livepatch-devel, p-cpe:/a:novell:suse_linux:kernel-devel, p-cpe:/a:novell:suse_linux:kernel-livepatch-5_3_18-150300_59_153-default, p-cpe:/a:novell:suse_linux:kernel-macros, p-cpe:/a:novell:suse_linux:kernel-obs-build, p-cpe:/a:novell:suse_linux:kernel-preempt, p-cpe:/a:novell:suse_linux:kernel-preempt-devel, p-cpe:/a:novell:suse_linux:kernel-source, p-cpe:/a:novell:suse_linux:kernel-syms, p-cpe:/a:novell:suse_linux:kernel-zfcpdump, p-cpe:/a:novell:suse_linux:ocfs2-kmp-default, p-cpe:/a:novell:suse_linux:reiserfs-kmp-default, cpe:/o:novell:suse_linux:15
必要な KB アイテム: Host/local_checks_enabled, Host/cpu, Host/SuSE/release, Host/SuSE/rpm-list
エクスプロイトの容易さ: No known exploits are available
パッチ公開日: 2024/3/13
脆弱性公開日: 2022/6/15
参照情報
CVE: CVE-2019-25162, CVE-2020-36777, CVE-2020-36784, CVE-2021-46904, CVE-2021-46905, CVE-2021-46906, CVE-2021-46915, CVE-2021-46924, CVE-2021-46929, CVE-2021-46932, CVE-2021-46934, CVE-2021-46953, CVE-2021-46964, CVE-2021-46966, CVE-2021-46968, CVE-2021-46974, CVE-2021-46989, CVE-2021-47005, CVE-2021-47012, CVE-2021-47013, CVE-2021-47054, CVE-2021-47060, CVE-2021-47061, CVE-2021-47069, CVE-2021-47076, CVE-2021-47078, CVE-2021-47083, CVE-2022-20154, CVE-2022-48627, CVE-2023-28746, CVE-2023-35827, CVE-2023-46343, CVE-2023-51042, CVE-2023-52340, CVE-2023-52429, CVE-2023-52439, CVE-2023-52443, CVE-2023-52445, CVE-2023-52448, CVE-2023-52449, CVE-2023-52451, CVE-2023-52463, CVE-2023-52475, CVE-2023-52478, CVE-2023-52482, CVE-2023-52502, CVE-2023-52530, CVE-2023-52531, CVE-2023-52532, CVE-2023-52569, CVE-2023-52574, CVE-2023-52597, CVE-2023-52605, CVE-2023-6817, CVE-2024-0340, CVE-2024-0607, CVE-2024-1151, CVE-2024-23849, CVE-2024-23851, CVE-2024-26585, CVE-2024-26586, CVE-2024-26589, CVE-2024-26593, CVE-2024-26595, CVE-2024-26602, CVE-2024-26607, CVE-2024-26622
SuSE: SUSE-SU-2024:0857-1