遠端 Ubuntu 22.04 LTS/23.10 主機上安裝的一個套件會受到 USN-6774-1 公告中所提及的多個弱點影響。

  - 在 6.5.10 之前，Linux 核心中的 brcm80211 元件在裝置拔除 (透過熱插拔中斷 USB) 程式碼中有 brcmf_cfg80211_detach 釋放後使用錯誤。對於具有本機存取權的實際位置靠近的攻擊者，他們可在實際狀況中惡意利用此弱點。這與 drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 中的 brcmf_cfg80211_escan_timeout_worker 有關。
    (CVE-2023-47233)

  - 在 Linux 核心中，下列弱點已修正：jfs：修正 dbAdjTree 中的 array-index-out-of-bounds 目前，存取 dmt_stree 時，dbAdjTree 中缺少邊界檢查。若要新增必要的檢查，請根據以下 commit 中的建議新增確定大小所需的 bool is_ctl。https://lore.kernel.org/linux-kernel-mentees/f9475918-2186-49b8-b801-6f0f9e75f4fa@oracle.com/ (CVE-2023-52601)

  - 在 Linux 核心中，下列弱點已修正：jfs：修正 dtSearch 中的 slab-out-of-bounds 讀取 目前，在頁面的已排序項目試算表中搜尋目前頁面時，會發生超出邊界存取。已新增邊界檢查來修正錯誤。Dave：將傳回碼設為 -EIO (CVE-2023-52602)

  - 在 Linux 核心中，下列弱點已修正：FS:JFS:UBSAN:array-index-out-of-boundsin dbAdjTree Syzkaller 報告了以下問題：UBSAN：fs/jfs/jfs_dmap.c:2867:6 索引 196694 中的 array-index-out-of-bounds 超出類型「s8[1365]」(也稱為「signed char[1365]」) 的範圍 CPU：1 PID：109 命令：jfsCommit 未污染 6.6.0-rc3-syzkaller #0 硬體名稱：Google Google Compute Engine/Google Compute Engine，BIOS Google 08/04/2023 呼叫追蹤：<TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106 ubsan_epilogue lib/ubsan.c:217 [inline]
    __ubsan_handle_out_of_bounds+0x11c/0x150 lib/ubsan.c:348 dbAdjTree+0x474/0x4f0 fs/jfs/jfs_dmap.c:2867 dbJoin+0x210/0x2d0 fs/jfs/jfs_dmap.c:2834 dbFreeBits+0x4eb/0xda0 fs/jfs/jfs_dmap.c:2331 dbFreeDmap fs/jfs/jfs_dmap.c:2080 [inline] dbFree+0x343/0x650 fs/jfs/jfs_dmap.c:402 txFreeMap+0x798/0xd50 fs/jfs/jfs_txnmgr.c:2534 txUpdateMap+0x342/0x9e0 txLazyCommit fs/jfs/jfs_txnmgr.c:2664 [inline] jfs_lazycommit+0x47a/0xb70 fs/jfs/jfs_txnmgr.c:2732 kthread+0x2d3/0x370 kernel/kthread.c:388 ret_from_fork+0x48/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304 </TASK> ================================================================================ 核心錯誤 - 未同步：UBSAN：panic_on_warn 設定… CPU：1 PID：109 命令：jfsCommit 未污染 6.6.0-rc3-syzkaller #0 硬體名稱：Google Google Compute Engine/Google Compute Engine，BIOS Google 08/04/2023 呼叫追蹤：
    <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106 panic+0x30f/0x770 kernel/panic.c:340 check_panic_on_warn+0x82/0xa0 kernel/panic.c:236 ubsan_epilogue lib/ubsan.c:223 [inline] __ubsan_handle_out_of_bounds+0x13c/0x150 lib/ubsan.c:348 dbAdjTree+0x474/0x4f0 fs/jfs/jfs_dmap.c:2867 dbJoin+0x210/0x2d0 fs/jfs/jfs_dmap.c:2834 dbFreeBits+0x4eb/0xda0 fs/jfs/jfs_dmap.c:2331 dbFreeDmap fs/jfs/jfs_dmap.c:2080 [inline] dbFree+0x343/0x650 fs/jfs/jfs_dmap.c:402 txFreeMap+0x798/0xd50 fs/jfs/jfs_txnmgr.c:2534 txUpdateMap+0x342/0x9e0 txLazyCommit fs/jfs/jfs_txnmgr.c:2664 [inline] jfs_lazycommit+0x47a/0xb70 fs/jfs/jfs_txnmgr.c:2732 kthread+0x2d3/0x370 kernel/kthread.c:388 ret_from_fork+0x48/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304 </TASK> 核心位移：已停用 86400 秒後重啟… 若 lp 的值大於 CLTREEESIZE (即 stree 的最大大小)，則會導致此問題。新增一項簡單的檢查即可解決此問題。Dave：由於該函式會傳回 void，因此若要妥善處理錯誤，可能需要更激進的程式碼重組。由於缺少明確的選項，所以我修改了目前所用的 Osama 修補程式 WARN_ON_ONCE。修補程式已經過 syzbot 測試。(CVE-2023-52604)

  - 在 Linux 核心中，下列弱點已解決：hwrng：核心 - 修正 mmap-ed hwrng 上的頁面錯誤死結。hwrng 裝置讀取路徑中出現死結。這會在使用者從 /dev/hwrng 讀取至記憶體 (以及從 /dev/hwrng 讀取 mmap-ed) 時觸發。產生的頁面錯誤會觸發遞回讀取，進而造成死結。透過在呼叫 copy_to_user 時使用堆疊緩衝區來修正此問題。 (CVE-2023-52615)

  - 在 Linux 核心中，下列弱點已解決： tcp：確保初始化一次 accept_queue 的執行緒同步鎖定。在本機執行 syz 的再生 C 程式時，會造成下列問題：
    pvqspinlock：鎖定 0xffff9d181cd5c660 的值已損壞，為 0x0! 警告：CPU：19 PID：21160 位置：
    __pv_queued_spin_unlock_slowpath (kernel/locking/qspinlock_paravirt.h:508) 硬體名稱：Red Hat KVM, BIOS 0.5.1 2011 年 1 月 1 日 RIP: 0010:__pv_queued_spin_unlock_slowpath (kernel/locking/qspinlock_paravirt.h:508) 程式碼：73 56 3a ff 90 c3 cc cc cc cc 8b 05 bb 1f 48 01 85 c0 74 05 c3 cc cc cc cc 8b 17 48 89 fe 48 c7 c7 30 20 ce 8f e8 ad 56 42 ff <0f> 0b c3 cc cc cc cc 0f 0b 0f 1f 40 00 90 90 90 90 90 90 90 90 90 RSP:
    0018:ffffa8d200604cb8 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff9d1ef60e0908 RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffff9d1ef60e0900 RBP: ffff9d181cd5c280 R08:
    0000000000000000 R09: 00000000ffff7fff R10: ffffa8d200604b68 R11: ffffffff907dcdc8 R12: 0000000000000000 R13: ffff9d181cd5c660 R14: ffff9d1813a3f330 R15: 0000000000001000 FS: 00007fa110184640(0000) GS:ffff9d1ef60c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2:
    0000000020000000 CR3: 000000011f65e000 CR4: 00000000000006f0 Call Trace: <IRQ> _raw_spin_unlock (kernel/locking/spinlock.c:186) inet_csk_reqsk_queue_add (net/ipv4/inet_connection_sock.c:1321) inet_csk_complete_hashdance (net/ipv4/inet_connection_sock.c:1358) tcp_check_req (net/ipv4/tcp_minisocks.c:868) tcp_v4_rcv (net/ipv4/tcp_ipv4.c:2260) ip_protocol_deliver_rcu (net/ipv4/ip_input.c:205) ip_local_deliver_finish (net/ipv4/ip_input.c:234) __netif_receive_skb_one_core (net/core/dev.c:5529) process_backlog (./include/linux/rcupdate.h:779) __napi_poll (net/core/dev.c:6533) net_rx_action (net/core/dev.c:6604) __do_softirq (./arch/x86/include/asm/jump_label.h:27) do_softirq (kernel/softirq.c:454 kernel/softirq.c:441) </IRQ> <TASK> __local_bh_enable_ip (kernel/softirq.c:381)
    __dev_queue_xmit (net/core/dev.c:4374) ip_finish_output2 (./include/net/neighbour.h:540 net/ipv4/ip_output.c:235) __ip_queue_xmit (net/ipv4/ip_output.c:535) __tcp_transmit_skb (net/ipv4/tcp_output.c:1462) tcp_rcv_synsent_state_process (net/ipv4/tcp_input.c:6469) tcp_rcv_state_process (net/ipv4/tcp_input.c:6657) tcp_v4_do_rcv (net/ipv4/tcp_ipv4.c:1929) __release_sock (./include/net/sock.h:1121 net/core/sock.c:2968) release_sock (net/core/sock.c:3536) inet_wait_for_connect (net/ipv4/af_inet.c:609) __inet_stream_connect (net/ipv4/af_inet.c:702) inet_stream_connect (net/ipv4/af_inet.c:748) __sys_connect (./include/linux/file.h:45 net/socket.c:2064) __x64_sys_connect (net/socket.c:2073 net/socket.c:2070 net/socket.c:2070) do_syscall_64 (arch/x86/entry/common.c:51 arch/x86/entry/common.c:82) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:129) RIP:
    0033:0x7fa10ff05a3d 程式碼: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d ab a3 0e 00 f7 d8 64 89 01 48 RSP: 002b:00007fa110183de8 EFLAGS: 00000202 ORIG_RAX: 000000000000002a RAX: ffffffffffffffda RBX:
    0000000020000054 RCX: 00007fa10ff05a3d RDX: 000000000000001c RSI: 0000000020000040 RDI: 0000000000000003 RBP: 00007fa110183e20 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11:
    0000000000000202 R12: 00007fa110184640 R13: 0000000000000000 R14: 00007fa10fe8b060 R15: 00007fff73e23b20 </TASK> 觸發問題的過程分析如下：Thread A Thread B tcp_v4_rcv //receive ack TCP packet inet_shutdown tcp_check_req tcp_disconnect //disconnect sock ... tcp_set_state(sk, TCP_CLOSE) inet_csk_complete_hashdance ... inet_csk_reqsk_queue_add ---truncated--- (CVE-2024-26614)

  - 在 Linux 核心中，下列弱點已解決： tomoyo：修正 tomoyo_write_control() 中的 UAF 寫入錯誤。由於 tomoyo_write_control() 在要求 write() of long 行時，會更新 head->write_buf，因此我們需要在保留 head->io_sem 之後擷取 head->write_buf。否則，並行 write() 要求可造成釋放後使用寫入和重複釋放問題。(CVE-2024-26622)

  - 在 Linux 核心中，下列弱點已解決：llc：中斷對 ETH_P_TR_802_2 的支援。
    syzbot 報告了以下 uninit-value 錯誤。 [0] llc 支援 ETH_P_802_2 (0x0004) 且用於支援 ETH_P_TR_802_2 (0x0011)，但 syzbot 濫用後者來觸發錯誤。 write$tun(r0, &(0x7f0000000040)={@val={0x0, 0x11}, @val, @mpls={[], @llc={@snap={0xaa, 0x1, ')', 90e5dd}} }}，0x16) llc_conn_handler() 會根據 llc_pdu_decode_sa()/llc_pdu_decode_da() 中的 skb 初始化本機變數 {saddr,daddr}.mac，並將其傳送至 __llc_lookup()。不過，只有在 skb->protocol 為 htons(ETH_P_802_2) 時，才會完成初始化，否則為 __llc_lookup_established() 和
    __llc_lookup_listener() 會讀取記憶體。遺漏的初始化在 commit 211ed865108e 之前就已存在 (net：刪除權杖環特殊處理的所有執行個體)。該弱點已移除用於移除權杖環內容的部分，但忘記關閉門，進而允許 ETH_P_TR_802_2 封包潛入 llc_rcv()。
    不妨移除 llc_tr_packet_type 並完成取代。[0]：錯誤：KMSAN：uninit-value in
    __llc_lookup_established+0xe9d/0xf90 __llc_lookup_established+0xe9d/0xf90 __llc_lookup net/llc/llc_conn.c:611 [內嵌] llc_conn_handler+0x4bd/0x1360 net/llc/llc_conn.c:791 llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206 __netif_receive_skb_one_core net/core/dev.c:5527 [內嵌]
    __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5641 netif_receive_skb_internal net/core/dev.c:5727 [內嵌] netif_receive_skb+0x58/0x660 net/core/dev.c:5786 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555 tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2020 [內嵌] new_sync_write fs/read_write.c:491 [內嵌] vfs_write+0x8ef/0x1490 fs/read_write.c:584 ksys_write+0x20f/0x4c0 fs/read_write.c:637
    __do_sys_write fs/read_write.c:649 [內嵌] __se_sys_write fs/read_write.c:646 [內嵌]
    __x64_sys_write+0x93/0xd0 fs/read_write.c:646 do_syscall_x64 arch/x86/entry/common.c:51 [內嵌] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x63/0x6b 本機變數 daddr 的建立位置為：llc_conn_handler+0x53/0x1360 net/llc/llc_conn.c:783 llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206 CPU: 1 PID: 5004 Comm: syz-executor994 未受污染 6.6.0-syzkaller-14500-g1c41041124bd #0 硬體名稱：Google Google Compute Engine/Google Compute Engine、BIOS Google 2023 年 10 月 9 日 (CVE-2024-26635)

  - 在 Linux 核心中，下列弱點已解決：ext4：修正因錯誤範圍 moved_len 而造成的區塊重複釋放。在 ext4_move_extents() 函式中，只有當所有的移動操作成功執行時，才會更新 moved_len 的值，並且只有當 moved_len 不為零時，才會捨棄 orig_inode 和 donor_inode 的預分配。若迴圈在成功移動某些範圍後無法結束，moved_len 不會更新並保持為 0，因此不會捨棄預先配置。如果移動的範圍與預先配置的範圍重疊，重疊的範圍會在 ext4_mb_release_inode_pa() 和 ext4_process_freed_data() 中釋放兩次 (如 commit 94d7c16cbbbd (ext4：使用 EXT4_IOC_MOVE_EXT 修正區塊的重複釋放中) 所述)，且 bb_free 會增加兩次。因此，執行修剪時，會在 mb_update_avg_fragment_size() 中觸發一個除以零錯誤，因為 bb_free 不是零而 bb_fragments 是零。因此，請在每次移動範圍後更新 move_len，以避免發生此問題。(CVE-2024-26704)

  - 在 Linux 核心中，下列弱點已解決：Bluetooth：避免 hci_error_reset 中的潛在釋放後使用 處理 HCI_EV_HARDWARE_ERROR 事件時，如果基礎 BT 控制器沒有回應，GPIO 重設機制會釋放 hci_dev 並導致 hci_error_reset 中出現一個釋放後使用問題。以下是在搭載 Intel AX201 的 ChromeOS 裝置上觀察到的呼叫追蹤：
    queue_work_on+0x3e/0x6c __hci_cmd_sync_sk+0x2ee/0x4c0 [bluetooth <HASH:3b4a6>] ? init_wait_entry+0x31/0x31
    __hci_cmd_sync+0x16/0x20 [bluetooth <HASH:3b4a 6>] hci_error_reset+0x4f/0xa4 [bluetooth <HASH:3b4a 6>] process_one_work+0x1d8/0x33f worker_thread+0x21b/0x373 kthread+0x13a/0x152 ? pr_cont_work+0x54/0x54 ? kthread_blkcg+0x31/0x31 ret_from_fork+0x1f/0x30 此修補程式會在處理 HCI_EV_HARDWARE_ERROR 事件時，保留 hci_dev 上的參照計數，以避免可能發生的當機。(CVE-2024-26801)

  - 在 Linux 核心中，下列弱點已解決：netlink：修正 __skb_datagram_iter 中的 kernel-infoleak-after-free syzbot 報告了下列 uninit-value 存取問題 [1]：
    netlink_to_full_skb() 會建立新的「skb」，並將「skb->data」作為 netlink_to_full_skb() 的第一個引數傳送至新的「skb」。將資料大小指定為「len」並傳遞至 skb_put_data()。
    此「len」以「skb->end」為基礎，後者不是資料位移，而是緩衝區位移。「skb->end」包含資料和 tailroom。由於建立新的「skb」時 tailroom 並未初始化，KMSAN 會在復制資料時偵測未初始化的記憶體區域。此修補程式已解決此問題，方法是將 len 從「skb->end」更正為「skb->len」，即實際資料位移。錯誤：KMSAN：instrument_copy_to_user include/linux/instrumented.h:114 中的 kernel-infoleak-after-free [內嵌] 錯誤：KMSAN：copy_to_user_iter lib/iov_iter.c:24 中的 kernel-infoleak-after-free [內嵌] 錯誤：KMSAN：iterate_ubuf include/linux/iov_iter.h:29 中的 kernel-infoleak-after-free [內嵌] 錯誤：KMSAN：iterate_and_advance2 include/linux/iov_iter.h:245 中的 kernel-infoleak-after-free [內嵌] 錯誤：KMSAN：iterate_and_advance include/linux/iov_iter.h:271 中的 kernel-infoleak-after-free [內嵌] 錯誤：KMSAN：_copy_to_iter+0x364/0x2520 lib/iov_iter.c:186 instrument_copy_to_user include/linux/instrumented.h:114 中的 kernel-infoleak-after-free [內嵌] copy_to_user_iter lib/iov_iter.c:24 [內嵌] iterate_ubuf include/linux/iov_iter.h:29 [內嵌] iterate_and_advance2 include/linux/iov_iter.h:245 [內嵌] iterate_and_advance include/ linux/iov_iter.h:271 [內嵌]
    _copy_to_iter+0x364/0x2520 lib/iov_iter.c:186 copy_to_iter include/linux/uio.h:197 [內嵌] simple_copy_to_iter+0x68/0xa0 net/core/datagram.c:532 __skb_datagram_iter+0x123/0xdc0 net/core/datagram.c:420 skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:546 skb_copy_datagram_msg include/linux/skbuff.h:3960 [內嵌] packet_recvmsg+0xd9c/0x2000 net/packet/af_packet.c:3482 sock_recvmsg_nosec net/socket.c:1044 [內嵌] sock_recvmsg net/socket.c:1066 [內嵌] sock_read_iter+0x467/0x580 net/socket.c:1136 call_read_iter include/linux/fs.h:2014 [內嵌] new_sync_read fs/read_write.c:389 [內嵌] vfs_read+0x8f6/0xe00 fs/read_write.c:470 ksys_read+0x20f/0x4c0 fs/read_write.c:613 __do_sys_read fs/read_write.c:623 [內嵌] __se_sys_read fs/read_write.c:621 [內嵌]
    __x64_sys_read+0x93/0xd0 fs/read_write.c:621 do_syscall_x64 arch/x86/entry/common.c:52 [內嵌] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit 是儲存至位於下列位置的記憶體：skb_put_data include/linux/skbuff.h:2622 [內嵌] netlink_to_full_skb net/netlink/af_netlink.c:181 [內嵌] __netlink_deliver_tap_skb net/netlink/af_netlink.c:298 [內嵌]
    __netlink_deliver_tap+0x5be/0xc90 net/netlink/af_netlink.c:325 netlink_deliver_tap net/netlink/af_netlink.c:338 [內嵌] netlink_deliver_tap_kernel net/netlink/af_netlink.c:347 [內嵌] netlink_unicast_kernel net/netlink/af_netlink.c:1341 [內嵌] netlink_unicast+0x10f1/0x1250 net/netlink/af_netlink.c:1368 netlink_sendmsg+0x1238/0x13d0 net/netlink/af_netlink.c:1910 sock_sendmsg_nosec net/socket.c:730 [內嵌] __sock_sendmsg net/socket.c:745 [內嵌]
    ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638 __sys_sendmsg net/socket.c:2667 [內嵌] __do_sys_sendmsg net/socket.c:2676 [內嵌] __se_sys_sendmsg net/socket.c:2674 [內嵌] __x64_sys_sendmsg+0x307/0x490 net/socket.c:2674 do_syscall_x64 arch/x86/entry/common.c:52 [內嵌] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit 的建立位置為：free_pages_prepare mm/page_alloc.c:1087 [內嵌] free_unref_page_prepare+0xb0/0xa40 mm/page_alloc.c:2347 free_unref_page_list+0xeb/0x1100 mm/page_alloc.c:2533 release_pages+0x23d3/0x2410 mm/swap.c:1042 free_pages_and_swap_cache+0xd9/0xf0 mm/swap_state.c:316 tlb_batch_pages ---truncated--- (CVE-2024-26805)

  - 此 CVE 是由 Intel 指派。如需詳細資訊，請參閱 CVE.org 上的 CVE-2024-2201。(CVE-2024-2201)

請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

偵測

Ubuntu 22.04 LTS/23.10：Linux 核心弱點 (USN-6774-1)

medium Nessus Plugin ID 197216

版本 1.0