Ubuntu 22.04 LTS：Linux 核心 (OEM) 弱點 (USN-6688-1)
high Nessus Plugin ID 191796
語系：
概要
遠端 Ubuntu 主機缺少一個或多個安全性更新。說明
遠端 Ubuntu 22.04 LTS 主機上安裝的一個套件受到 USN-6688-1 公告中所提及的多個弱點影響。- Xen 虛擬網路通訊協定中的傳輸要求可由多個部分組成。雖然這些部分不是真的實用，但除了初始部分，其中任何一個都可能是零長度，即根本不攜帶任何資料。除了要傳輸資料的特定初始部分，這些部分會直接轉譯為 Linux 所稱的 SKB 片段。這類轉換的要求部分在針對特定 SKB 而言長度為零時，可導致核心網路程式碼中出現 NULL 解除參照。(CVE-2023-46838)
- 在 6.6.5 及之前的 Linux 核心中，由于 info->pad0 未被初始化，drivers/accel/habanalabs/common/habanalabs_ioctl.c 中的 sec_attest_info 可導致資訊洩漏至使用者空間。(CVE-2023-50431)
- 在 Linux 核心中，下列弱點已修正：f2fs：明確使 xattr 清單以 null 結尾 設定 xattr 時，明確使 xattr 清單以 null 結尾。這使得未使用的 xattr 空間一律歸零這一經不起推敲的假設無效。(CVE-2023-52436)
- 在 Linux 核心中，下列弱點已修正：binder：修正 shinker 回呼中的釋放後使用 在 shrinker 回呼期間使用 mmap 讀取鎖定意味著使用 alloc->vma 指標並不安全，因為它會與 munmap() 發生爭用。自 commit dd2283f2605e (mm：mmap：munmap 中含有讀取 mmap_sem 的 zap 頁面) 起，mmap 鎖定會在 vma 被隔離之後降級。透過 shrinker 的除錯 sysfs，我可以手動新增一些延遲並觸發頁面回收來重現此問題。下列 KASAN 報告確認了 UAF：
================================================================== 錯誤：KASAN：zap_page_range_single+0x470/0x4b8 中存在 slab-use-after-free 讀取大小為 8 位於：addr ffff356ed50e50f0 按任務 bash/478 CPU：1 PID：478 命令：bash 未污染 6.6.0-rc5-00055-g1c8b86a3799f-dirty #70 硬體名稱：linux,dummy-virt (DT) 呼叫追蹤：zap_page_range_single+0x470/0x4b8 binder_alloc_free_page+0x608/0xadc
__list_lru_walk_one+0x130/0x3b0 list_lru_walk_node+0xc4/0x22c binder_shrink_scan+0x108/0x1dc shrinker_debugfs_scan_write+0x2b4/0x500 full_proxy_write+0xd4/0x140 vfs_write+0x1ac/0x758 ksys_write+0xf0/0x1dc __arm64_sys_write+0x6c/0x9c 根據任務 492 配置：kmem_cache_alloc+0x130/0x368 vm_area_alloc+0x2c/0x190 mmap_region+0x258/0x18bc do_mmap+0x694/0xa60 vm_mmap_pgoff+0x170/0x29c ksys_mmap_pgoff+0x290/0x3a0 __arm64_sys_mmap+0xcc/0x144 根據任務 491 配置：kmem_cache_free+0x17c/0x3c8 vm_area_free_rcu_cb+0x74/0x98 rcu_core+0xa38/0x26d4 rcu_core_si+0x10/0x1c __do_softirq+0x2fc/0xd24 上次可能的相關工作建立：__call_rcu_common.constprop.0+0x6c/0xba0 call_rcu+0x10/0x1c vm_area_free+0x18/0x24 remove_vma+0xe4/0x118 do_vmi_align_munmap.isra.0+0x718/0xb5c do_vmi_munmap+0xdc/0x1fc __vm_munmap+0x10c/0x278 __arm64_sys_munmap+0x58/0x7c 透過執行 vma_lookup() 來解決此問題，此函式在 mmap 鎖定降级之后才能找到被隔離的 vma。
請注意，與升級至 mmap 寫入鎖定 (會增加爭用概率) 相比，此選項的效果更好。此外，mmap_write_trylock() 已於近期移除。(CVE-2023-52438)
- 在 Linux 核心中，下列弱點已修正：uio：修正 uio_open core-1 core-2 中的釋放後使用 ------------------------------------------------------- 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 将 kfree idev。但在執行 core-1 device_unregister、put_device 与 kfree 之間，core-2 可能會 get_device。然后：1. 在 core-1 kfree idev 之後，core-2 将會為 idev 執行釋放後使用。2. core-2 執行 uio_release 和 put_device 後，idev 將被雙重釋放。若要解決此問題，我們可以透过 minor_lock 取得 idev atomic 和 inc idev 參照。
(CVE-2023-52439)
- 在 Linux 核心中，下列弱點已修正：apparmor：避免剖析的設定檔名稱為空時發生當機 處理 unpack_profile() 中的壓縮設定檔時，如設定檔 :ns::samba-dcerpcd /usr/lib*/samba/{,samba/}samba-dcerpcd {...} 所述，字串 :samba-dcerpcd 被解壓縮為完整名稱，然後傳送至 aa_splitn_fqname()。aa_splitn_fqname() 視 :samba-dcerpcd 僅包含命名空間。因此，它會為 tmpname 傳回 NULL，同時 tmpns 為非 NULL。稍後，aa_alloc_profile() 損毀，因為新的設定檔名稱現在為 NULL。一般保護錯誤，可能適用於非正式位址 0xdffffc0000000000：0000 [#1] PREEMPT SMP KASAN NOPTI KASAN：null-ptr-deref 在範圍內 [0x0000000000000000-0x0000000000000007] CPU：6 PID：1657 命令：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> ---[結束追蹤 0000000000000000]--- RIP：
0010:strlen+0x1e/0xa0 aa_splitn_fqname() 的此類行為似乎在預期之中，並在被呼叫的其他位置 (例如 aa_remove_profiles) 進行檢查。內部有一個明確的註解：可以使用不含下列設定檔的 ns 名稱。AFAICS，沒有什麼能夠防止解壓縮的名稱採用類似 :samba-dcerpcd 的形式，因為名稱從使用者空間傳遞而來。拒絕在此類情況下取代整個設定檔設定，並透過 EPROTO 向使用者傳送解釋訊息通知。由 Linux Verification Center (linuxtesting.org) 發現。
(CVE-2023-52443)
- 在 Linux 核心中，下列弱點已修正：f2fs：经过修正，可避免 dirent 损坏 如 Al 在 link[1] 中所報告的那樣：f2fs_rename() ... 若 (old_dir != new_dir && !whiteout) f2fs_set_link(old_inode, old_dir_entry, old_dir_page, new_dir); 否則 f2fs_put_page(old_dir_page, 0); 您需要糾正 .. 連結中的編號。而且跨目錄重新命名會將來源移至新的父項，即使系統要求您在舊位置留下 whiteout。[1] https://lore.kernel.org/all/20231017055040。GN800259@ZenIV/ 使用下列測試案例時，可能會造成 dirent 损坏，因為其未呼叫 f2fs_set_link() 来更新…
連結至新目錄。- mkdir -p dir/foo - renameat2 -w dir/foo bar [ASSERT] (__chk_dots_dentries:1421)
--> '..' 的錯誤 inode 編號 [0x4]，父 ino 為 [0x3] [FSCK] 其他損毀錯誤 [失敗] (CVE-2023-52444)
- 在 Linux 内核中，下列弱點已修正：media：pvrusb2：修正內容中斷連線時發生的釋放後使用 在模組載入時，系統為 pvr2_context_thread_func 函式建立了一個 kthread，該函式可以呼叫 pvr2_context_destroy，因而也能呼叫內容對象上的 kfree()。不過，這可能發生在 usb hub_event 處置程式通知驅動程式之前。在 syzbot 報告無效讀取之前，此修補程式已在內容中斷連線呼叫堆疊內新增功能健全檢查。(CVE-2023-52445)
- 在 Linux 核心中，下列弱點已修正：bpf：必要時，延遲釋放內部對應 更新或刪除對應陣列或對應 htab 中的內部對應，非睡眠模式或睡眠模式仍可存取該對應。但是，若 ref-counter 排在最后 (大多數情況下為 true)，bpf_map_fd_put_ptr() 會直接透過 bpf_map_put() 減少內部對應的 ref-counter，並且內部對應將被 kworker 中的 ops->map_free() 釋放。但目前，大多數 .map_free() 回呼並未使用 synchronize_rcu() 或其變體來等待 RCU 寬限期過去，因此在 ops->map_free 叫用完成後，存取內部對應的 bpf 程式 可能會引發釋放後使用問題。透過在一個 RCU 寬限期和一個工作追蹤 RCU 寬限期之後呼叫 bpf_map_free_deferred() (若之前已從外部對應中刪除內部對應)，修正內部對應釋放。若要釋放 bpf 對應的最後一個 ref-counter，可使用 call_rcu() 或 call_rcu_tasks_trace() 來達到延遲釋放的目的。bpf_map 中新增的 rcu_head 欄位與 work 欄位共用同一儲存空間，以減小 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 通知程式造成的 gluebi NULL 指標解除參照 若 ftl.ko 和 gluebi.ko 都已載入，嘗試存取 gluebi_read() 中的 gluebi->desc' 時，ftl 的通知程式會觸發 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 若要再現問題詳情，請存取連結 [1]。正常情況下，請在 gluebi_get_device() 中取得 gluebi->desc，並在 gluebi_read() 中存取 gluebi->desc。但是，gluebi_get_device() 不會提前在 ftl_add_mtd() 進程中執行，導致發生 NULL 指標解除參照。適用於 gluebi 模組的解決方案是在 UBI 磁碟區上執行 jffs2，而不考慮使用 ftl 或 mtdblock [2]。因此，透過阻止 gluebi 在建立類型 MTD_UBIVOLUME 的 mtd 磁碟分割後建立 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]，即陣列中最後一個有效項目之後的元素。然後，函式結尾的除錯訊息會解除參照此指標：
pr_debug (無法熱移除 %llx\n 的記憶體，lmb->base_addr)；檢查時發現了該問題，並透過 KASAN 確認：pseries-hotplug-mem：嘗試熱移除 LMB，drc 索引 1234 ======================== ========================================== 錯誤：KASAN：dlpar_memory+0x298/0x1658 中存在 slab-out-of-bounds 讀取大小為 8 位於：addr c000000364e97fd0 按工作 bash/949 dump_stack_lvl+0xa4/0xfc (unreliable) print_report+0x214/0x63c kasan_report+0x140/0x2e0
__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 根據工作 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 錯誤位址屬於 c000000364e80000 中的物件 (屬於大小為 131072 的快取 kmalloc-128k)。錯誤位址位於被配置 98256 位元組的區域的右側 0 位元組處 [c000000364e80000, c000000364e97fd0) ================================================================== pseries-hotplug-mem：
無法在 0 處熱移除記憶體 系統無法記錄透過單獨的訊息執行的查閱，並且僅當游標指向有效項目時解除參照。(CVE-2023-52451)
- 在 Linux 核心中，下列弱點已修正：nvmet-tcp：修正主機傳送無效 H2C PDU 長度時發生的核心錯誤 若主機傳送含有無效 DATAL 的 H2CData 命令，核心在 nvmet_tcp_build_pdu_iovec() 中可能會當機。無法處理虛擬位址 0000000000000000 的核心 NULL 指標解除參照 lr：nvmet_tcp_io_work+0x6ac/0x718 [nvmet_tcp] 呼叫追蹤：
process_one_work+0x174/0x3c8 worker_thread+0x2d0/0x3e8 kthread+0x104/0x110 若 DATAL 與封包大小不一致，則透過觸發嚴重錯誤來修正此錯誤。此外，PDU 長度絕不應超過已在 nvmet_tcp_handle_icreq() 中傳送至主機的 MAXH2CDATA 參數。(CVE-2023-52454)
- 在 Linux 核心中，下列弱點已修正：serial：imx：修正 tx 狀態機器鎖死 序列連接埠用作 RS485 連接埠时，tx 狀態機器用於控制 RTS pin，以驅動 RS485 收發器 TX_EN pin。若 TTY 連接埠在傳輸過程中關閉 (例如，在 userland 應用程式當機期間)，imx_uart_shutdown 會停用介面並停用「傳輸完成」中斷。之後，imx_uart_stop_tx 會結束 TC 中斷重新觸發的不完整傳輸。此中斷已停用，因此 tx 狀態機器永遠不會轉換出 SEND。狀態機器現在處於鎖死狀態，且 TX_EN 維持在低位，導致介面無法使用。imx_uart_stop_tx 現在會在重新觸發釋出前檢查是否有不完整的傳輸，以及 TC 中斷是否已啟用。這可確保狀態機器被處理並正確設定為 WAIT_AFTER_SEND。(CVE-2023-52456)
- 在 Linux 核心中，下列弱點已修正：serial：8250：omap：若 pm_runtime_resume_and_get() 失敗，則不跳過資源釋放 從 .remove() 返回錯誤程式碼可使驅動程式核心發出「幾乎無用」的錯誤訊息：移除回呼傳回非零值。系統將忽略此訊息，然後仍然移除裝置。因此，在此情況下，所有未釋放的資源都會被洩漏。
略過 serial8250_unregister_port() 可能會保留足夠的 UART，從而觸發釋放後使用。因此，以更實用的錯誤訊息取代錯誤傳回 (以及「幾乎無用」的錯誤訊息)，並繼續進行清理。(CVE-2023-52457)
- 在 Linux 核心中，下列弱點已修正：block：新增對磁碟分割長度是否需要與區塊大小保持一致的檢查 呼叫「新增磁碟分割」或「調整磁碟分割大小」之前，未檢查長度是否與邏輯區塊大小保持一致。若磁碟的邏輯區塊大小大於 512 位元組，則磁碟分割大小可能不是邏輯區塊大小的倍數。此外，讀取最後一個磁區時，bio_truncate() 會調整 bio 大小，若讀取命令的大小小於邏輯區塊的大小，則會導致 IO 错误。若支援完整性資料，這還將導致呼叫 bio_integrity_free 時發生 null 指標解除參照。(CVE-2023-52458)
- 在 Linux 核心中，下列弱點已修正：bpf：修正對嘗試損壞溢位指標的檢查 當暫存器作為 1/2/4 位元組暫存器在堆疊上發生溢位時，我們會設定 slot_type[BPF_REG_SIZE - 1] (以及其下方可能發生更多少量溢位，視實際溢位大小而定)。因此，若要檢查某個堆疊插槽是否發生了暫存器溢位，我們需要查閱 slot_type[7]，而非 slot_type[0]。為避免以後需要記住和仔細檢查此項，只需使用 is_spilled_reg() 協助程式即可。
(CVE-2023-52462)
- 在 Linux 核心中，下列弱點已修正：efivarfs：如果不支援 SetVariable，在重新掛載時會強制執行 RO 若韌體不支援執行階段的 SetVariable，我們絕不會為該函式指派回呼。同時將 efivarfs 掛載為 RO，讓任何人都無法呼叫。但是，我們從不會檢查權限旗標，除非有人將檔案系統掛載為 RW。因此，這會導致當機，如下所示：$ mount -o remount,rw /sys/firmware/efi/efivars $ efi-updatevar -f PK.auth PK [303.279166] 無法處理虛擬位址 0000000000000000 的 NULL 指標解除參照 [303.280482] 記憶體中止資訊：[ 303.280854] ESR = 0x0000000086000004 [ 303.281338] EC = 0x21：IABT (当前 EL)，IL = 32 位 [ 303.282016] SET = 0，FnV = 0 [ 303.282414] EA = 0，S1PTW = 0 [ 303.282821] FSC = 0x04：
0 級轉譯錯誤 [303.283771 ] 使用者 pgtable：4k 頁面，48 位元 VA，pgdp=000000004258c000 [303.284913] [0000000000000000] pgd=0000000000000000、p4d=0000000000000000 [ 303.286076] 內部錯誤：
Oops：0000000086000004 [#1] PREEMPT SMP [ 303.286936] 模組連結位置：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 命令：
efi-updatevar 未污染 6.3.0-rc1-00108-gc7d0c4695c68 #1 [ 303.289748] 硬體名稱：未知 未知产品/未知产品，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] ---[結束追蹤 0000000000000000]--- 透過向 fs 作業新增 .reconfigure() 函式修正此弱點，我們可以使用此函式檢查請求的旗標，並拒絕不是 RO 的任何內容 (前提是固體在執行階段未實作 SetVariable)。(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：錯誤：「strncat」指定的邊界 1024 等於目的地大小 [-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() 的方式運作，後者使用目的地緩衝區的大小而不是來源緩衝區的長度作為第三個引數。結果就是系統不會檢查已配置緩衝區的大小，而是將其變更為 strlcat()。[ bp：修剪編譯器輸出，修正提交訊息。] (CVE-2023-52464)
- 在 Linux 核心中，下列弱點已修正：mfd：syscon：修正 of_syscon_register() 中的 null 指標解除參照 kasprintf() 會向動態配置記憶體傳回指標，此指標在失敗時變為 NULL。(CVE-2023-52467)
- 在 Linux 核心中，下列弱點已修正：drivers/amd/pm：修正 kv_parse_power_table 中的釋放後使用 若 kzalloc 配置的 ps 等於 NULL，kv_parse_power_table 會釋放之前配置的 adev->pm.dpm.ps。但是，在控制流程經過下列呼叫鏈之後：kv_parse_power_table |-> kv_dpm_init |-> kv_dpm_sw_init |-> kv_dpm_fini 在 kv_parse_power_table 中第一次釋放後，adev->pm.dpm.ps 用於 kv_dpm_fini 的 for 迴圈，並且會造成釋放後使用錯誤。(CVE-2023-52469)
- 在 Linux 核心中，下列弱點已修正：drm/radeon：檢查 radeon_crtc_init() 中的 alloc_workqueue 傳回值。檢查 radeon_crtc_init() 中的 alloc_workqueue 傳回值，以避免 null-ptr-deref。(CVE-2023-52470)
- 在 Linux 核心中，下列弱點已修正：ceph：修正誤用 dget() 造成的鎖死或無作用程式碼 denty 及其父項之間的鎖定順序不正確，我們應始終確保父項先被鎖定。但由於從未使用過此無作用程式碼且始終透過呼叫程式設定父目錄，我們只需將其移除即可。(CVE-2023-52583)
- 在 Linux 核心中，下列弱點已修正：spmi：mediatek：修正裝置移除時出現的 UAF。含有時鐘的 pmif 驅動程式資料會與 spmi_controller 一起被配置。移除裝置時，會先釋放 spmi_controller，然後再清理 devres (包括時鐘)。這會導致 UAF，因為放置時鐘將存取 pmif 驅動程式資料中的時鐘，而這些資料已隨 spmi_controller 一起被釋放。啟用 DEBUG_TEST_DRIVER_REMOVE 並使用 KASAN 構建核心即可重現此問題。透過使用未受管理的 clk_bulk_get() 並在釋放 spmi_controller 之前放置時鐘即可修正 UAF 問題。(CVE-2023-52584)
- 在 Linux 核心中，下列弱點已修正：IB/ipoib：修正 mcast 清單鎖定 在迭代「ipoib_mcast_join_task()」中的「priv->multicast_list」的同時釋放「priv->lock」會為「ipoib_mcast_dev_flush()」開啟視窗，導致項目在迭代過程中被移除。若在卸除鎖定的同時移除 mcast，for 迴圈會永遠旋轉，從而導致硬鎖定 (正如 RHEL 4.18.0-372.75.1.el8_6 kernel 核心中所報告的那樣)：工作 A (下方的 kworker/u72:2) | 工作 B (下方的 kworker/u72:0)
-----------------------------------+----------------------------------- ipoib_mcast_join_task(work) | ipoib_ib_dev_flush_light(work) spin_lock_irq(&priv->lock) | __ipoib_ib_dev_flush(priv, ...) list_for_each_entry(mcast, | ipoib_mcast_dev_flush(dev = priv->dev) &priv->multicast_list, list) | ipoib_mcast_join(dev, mcast) | spin_unlock_irq(&priv->lock) | | spin_lock_irqsave(&priv->lock, flags) | list_for_each_entry_safe(mcast, tmcast, | &priv->multicast_list, list) | list_del(&mcast->list); | list_add_tail(&mcast->list, &remove_list) | spin_unlock_irqrestore(&priv->lock, flags) spin_lock_irq(&priv->lock) | | ipoib_mcast_remove_list(&remove_list) (Here, `mcast` is no longer on the | list_for_each_entry_safe(mcast, tmcast, `priv->multicast_list` and we keep | remove_list, list) spinning on the `remove_list` of | >>> wait_for_completion(&mcast->done) the other thread which is blocked | and the list is still valid on | it's stack.) 透過保持鎖定並變更為 GFP_ATOMIC 來修正此問題，以防最終進入睡眠狀態。遺憾的是，我們無法重現鎖定問題並確認此修正，但根據程式碼檢閱，我認為此修正應該可以解決此類鎖定問題。crash> bc 31 PID：747 TASK：ff1c6a1a007e8000 CPU：31 命令：kworker/u72:2 -- [異常 RIP：ipoib_mcast_join_task+0x1b1] RIP：ffffffffc0944ac1 RSP：ff646f199a8c7e00 RFLAGS：00000002 RAX：0000000000000000 RBX：ff1c6a1a04dc82f8 RCX：0000000000000000 work (&priv->mcast_task{,.work}) RDX：ff1c6a192d60ac68 RSI：0000000000000286 RDI：ff1c6a1a04dc8000 &mcast->list RBP：ff646f199a8c7e90 R8：ff1c699980019420 R9：ff1c6a1920c9a000 R10：ff646f199a8c7e00 R11：
ff1c6a191a7d9800 R12：ff1c6a192d60ac00 mcast R13：ff1c6a1d82200000 R14：ff1c6a1a04dc8000 R15：
ff1c6a1a04dc82d8 dev priv (&priv->lock) &priv->multicast_list (即 head) ORIG_RAX：ffffffffffffffff CS：
0010 SS: 0018 --- <NMI exception stack> --- #5 [ff646f199a8c7e00] ffffffffc0944ac1 中的 ipoib_mcast_join_task+0x1b1 [ib_ipoib] #6 [ff646f199a8c7e98] ffffffff9bf10967 中的 process_one_work+0x1a7 crash> rx ff646f199a8c7e68 ff646f199a8c7e68: ff1c6a1a04dc82f8 <<< work = &priv->mcast_task.work crash> list -hO ipoib_dev_priv.multicast_list ff1c6a1a04dc8000 (empty) crash> ipoib_dev_priv.mcast_task.work.func,mcast_mutex.owner.counter ff1c6a1a04dc8000 mcast_task.work.func = 0xffffffffc0944910 <ipoib_mcast_join_task>, mcast_mutex.owner.counter = 0xff1c69998efec000 crash> b 8 PID：
8 工作：ff1c69998efec000 CPU：33 命令：kworker/u72:0 -- #3 [ff646f1980153d50] ffffffff9c7d7646 中的 wait_for_completion+0x96 #4 [ff646f1980153d90] ffffffffc0944dc6 中的 ipoib_mcast_remove_list+0x56 [ib_ipoib] #5 [ff646f1980153de8] ffffffffc09455a7 中的 ipoib_mcast_dev_flush+0x1a7 [ib_ipoib] #6 [ff646f1980153e58] ffffffffc09431a4 中的 __ipoib_ib_dev_flush+0x1a4 [ib_ipoib] #7 [ff
---truncated--- (CVE-2023-52587)
- 在 Linux 核心中，下列弱點已修正：f2fs：經過修正，可在區塊移轉期間在頁面上標記 gcing 旗標 在區塊移轉期間，在頁面上新增遺漏的 gcing 旗標才能保證移轉的資料在檢查點期間持續存在，否則資料和節點之間持久存在的亂序可能會在 SPOR 后造成資料損毀。類似的問題已由 commit 2d1fe8a86bf5 修正 (f2fs：經過修正，可在檔案重組期間在頁面上標記 gcing 旗標)。(CVE-2023-52588)
- 在 Linux 核心中，下列弱點已修正：media：rkisp1：解決 IRQ 停用爭用問題 在 rkisp1_isp_stop() 和 rkisp1_csi_disable() 中，驅動程式會遮罩中斷，然後理所當然地假設中斷處置程式不會執行並繼續執行停止程序。事實並非如此，因為中斷處置程式可能已經在執行，導致 ISP 在中斷處置程式處理擷取的框架時遭到停用。這會引發兩個問題：1) ISP 在中斷處置程式仍在執行並存取暫存器的情況下被關閉，從而導致面板鎖定；以及 2) 中斷處置程式的程式碼和用於停用資料流的程式碼可能發生衝突。我不清楚 2) 是否會造成真正的問題，但發現 1) 會導致中斷處置程式出現適當的延遲 (在本例中為 printk)，進而導致面板鎖定。(CVE-2023-52589)
- 在 Linux 核心中，下列弱點已修正：wifi：wfx：修正 wfx_set_mfp_ap() 中可能存在的 NULL 指標解除參照 由於「ieee80211_beacon_get()」可傳回 NULL，所以「wfx_set_mfp_ap()」應在檢查 skb 資料之前檢查傳回值。因此，轉換後者會傳回適當的錯誤碼，並進行傳播，從而也從「wfx_start_ap()」傳回。僅測試編譯檔案。(CVE-2023-52593)
- 在 Linux 核心中，下列弱點已修正：wifi: ath9k：修正 ath9k_htc_txstatus() 中潛在的 array-index-out-of-bounds 讀取 修正 ath9k_htc_txstatus() 中的 array-index-out-of-bounds 讀取。若 txs->cnt (來自 USB 裝置提供的 URB 資料) 大於陣列 txs->txstatus 的大小 (HTC_MAX_TX_STATUS)，會發生此錯誤。WARN_ON() 已對其進行檢查，但檢查後未發現錯誤處理程式碼。如果是這樣，請傳回函式。此問題由 syzkaller 的修改版本發現。UBSAN：htc_drv_txrx.c 索引 13 中的 array-index-out-of-bounds 超出類型「__wmi_event_txstatus [12]」的範圍 呼叫追蹤：ath9k_htc_txstatus ath9k_wmi_event_tasklet tasklet_action_common __do_softirq irq_exit_rxu sysvec_apic_timer_interrupt (CVE-2023-52594)
- 在 Linux 核心中，下列弱點已修正：wifi：rt2x00：硬體重設时，重新啟動 beacon 佇列 觸發硬體重設時，所有暫存器都會被重設，因此硬體介面中的所有佇列都會被強制停止。不過，mac80211 不會自動停止佇列。如果我們不手動停止 beacon 佇列，佇列將會鎖死且無法再次啟動。此修補程式修正了 Apple 裝置在呼叫 ieee80211_restart_hw() 後無法連線至 AP 的問題。
(CVE-2023-52595)
- 在 Linux 核心中，下列弱點已修正：KVM：s390：修正 fpc 暫存器的設定 kvm_arch_vcpu_ioctl_set_fpu() 允许設定來賓 cpu 的浮點控制 (fpc) 暫存器。系統會暫時將新值載入 fpc 暫存器，以測試其有效性。這可能會導致主機進程的 fpc 暫存器損毀：如果在將值暫時載入 fpc 暫存器時發生中斷，且在中斷內容中使用了浮點或向量暫存器，則目前的 fp/vx 暫存器會與 save_fpu_regs() 一併儲存。假設二者都屬於使用者空間，則會在傳回使用者空間時載入至 fp/vx 暫存器中。test_fp_ctl() 會復原原始的使用者空間/主機進程中的 fpc 暫存器值，但當傳回使用者空間時，該值會遭到捨棄。因此，主機進程將按預期用於來賓 cpu 的值繼續錯誤地執行。
只需移除測試即可解決此問題。在進入 SIE 內容之前有另一個測試權，用於處理無效值。這會導致行為變更：現在將接受無效值，而非導致 ioctl 失敗的 -EINVAL 值。考慮到此介面很可能不再使用，而且這與透過記憶體對應介面實作的行為相同 (以零取代無效值)，這似乎是可以接受的 - 請參閱 kvm-s390.c 中的 sync_regs()。(CVE-2023-52597)
- 在 Linux 核心中，下列弱點已修正：s390/ptrace：正確處理 fpc 暫存器的設定 在受追蹤的進程中，若浮點控制 (fpc) 暫存器的內容在 ptrace 介面被修改，則需要暫時將新值載入到 fpc 暫存器中來測試其有效性。這可能會導致追蹤進程的 fpc 暫存器損毀：如果在將值暫時載入 fpc 暫存器時發生中斷，且在中斷內容中使用了浮點或向量暫存器，則目前的 fp/vx 暫存器會與 save_fpu_regs() 一併儲存。假設二者都屬於使用者空間，則會在傳回使用者空間時載入至 fp/vx 暫存器中。
test_fp_ctl() 會復原原始使用者空間的 fpc 暫存器值，但當傳回使用者空間時，該值會遭到捨棄。因此，追蹤程序將按預期用於受追蹤進程的值繼續錯誤執行。此問題的解決方法如下：在使用 test_fp_ctl() 之前，以 save_fpu_regs() 儲存 fpu 暫存器內容。(CVE-2023-52598)
- 在 Linux 核心中，下列弱點已修正：jfs：修正 diNewExt 中的 array-index-out-of-bounds [Syz 報告] UBSAN：fs/jfs/jfs_imap.c:2360:2 index -878706688 中的 array-index-out-of-bounds 超過類型「struct iagctl[128]」的範圍 CPU：1 PID：5065 命令：syz-executor282 未污染 6.7.0-rc4-syzkaller-00009-gbee0e7762ad2 #0 硬體名稱：Google Google Compute Engine/Google Compute Engine，BIOS Google 11/10/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 diNewExt+0x3cf3/0x4000 fs/jfs/jfs_imap.c:2360 diAllocExt fs/jfs/jfs_imap.c:1949 [inline] diAllocAG+0xbe8/0x1e50 fs/jfs/jfs_imap.c:1666 diAlloc+0x1d3/0x1760 fs/jfs/jfs_imap.c:1587 ialloc+0x8f/0x900 fs/jfs/jfs_inode.c:56 jfs_mkdir+0x1c5/0xb90 fs/jfs/namei.c:225 vfs_mkdir+0x2f1/0x4b0 fs/namei.c:4106 do_mkdirat+0x264/0x3a0 fs/namei.c:4129
__do_sys_mkdir fs/namei.c:4149 [inline] __se_sys_mkdir fs/namei.c:4147 [inline] __x64_sys_mkdir+0x6e/0x80 fs/namei.c:4147 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x45/0x110 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x63/0x6b RIP：0033:0x7fcb7e6a0b57 程式碼：ff ff 77 07 31 c0 c3 0f 1f 40 00 48 c7 c2 b8 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 b8 53 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP：
002b:00007ffd83023038 EFLAGS：00000286 ORIG_RAX：0000000000000053 RAX：ffffffffffffffda RBX：
00000000ffffffff RCX：00007fcb7e6a0b57 RDX：00000000000a1020 RSI：00000000000001ff RDI：0000000020000140 RBP：0000000020000140 R08：0000000000000000 R09：0000000000000000 R10：0000000000000000 R11：
0000000000000286 R12：00007ffd830230d0 R13：0000000000000000 R14：0000000000000000 R15：0000000000000000 [分析] agstart 过大会造成 agno 溢位。[修正] 取得 agno 後，若值無效，則結束後續進程。根據核心測試機器人 (Dan Carpenter) 的 linux-next 報告，將測試從 agno > MAXAG 改為 agno >= MAXAG。(CVE-2023-52599)
- 在 Linux 核心中，下列弱點已修正：jfs：修正 jfs_evict_inode 中的 uaf 執行 diMount(ipimap) 失敗時，已釋放的物件 ipimap 或可在 diFreeSpecial() 中進行訪問。rcu_core() 呼叫 jfs_free_node() 時發生非同步 ipimap 釋放。因此，diMount(ipimap) 失敗時，sbi->ipimap 不應被初始化為 ipimap。(CVE-2023-52600)
- 在 Linux 核心中，下列弱點已修正：jfs：修正 dbAdjTree 中的 array-index-out-of-bounds 目前，存取 dmt_stree 時，dbAdjTree 中缺少邊界檢查。若要新增必要的檢查，請根據以下 commit 中的建議新增確定大小所需的 bool is_ctl。https://lore.kernel.org/linux-kernel-mentees/[email protected]/ (CVE-2023-52601)
- 在 Linux 核心中，下列弱點已修正：jfs：修正 dtSearch 中的 slab-out-of-bounds 讀取 目前，在頁面的已排序項目試算表中搜尋目前頁面時，會發生超出邊界存取。已新增邊界檢查來修正錯誤。Dave：將傳回碼設為 -EIO (CVE-2023-52602)
- 在 Linux 核心中，下列弱點已修正：UBSAN：dtSplitRoot 中的 array-index-out-of-bounds Syzkaller 報告了以下問題：oop0：檢測到容量變化範圍在 0 到 32768 之间 UBSAN：
fs/jfs/jfs_dtree.c:1971:9 索引 -2 中的 array-index-out-of-bounds 超出類型「struct dtslot [128]」的範圍 CPU：0 PID：3613 命令：syz-executor270 未污染 6.0.0-syzkaller-09423-g493ffd6605b2 #0 硬體名稱：Google Google Compute Engine/Google Compute Engine，BIOS Google 09/22/2022 呼叫追蹤：<TASK>
__dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106 ubsan_epilogue lib/ubsan.c:151 [inline] __ubsan_handle_out_of_bounds+0xdb/0x130 lib/ubsan.c:283 dtSplitRoot+0x8d8/0x1900 fs/jfs/jfs_dtree.c:1971 dtSplitUp fs/jfs/jfs_dtree.c:985 [inline] dtInsert+0x1189/0x6b80 fs/jfs/jfs_dtree.c:863 jfs_mkdir+0x757/0xb00 fs/jfs/namei.c:270 vfs_mkdir+0x3b3/0x590 fs/namei.c:4013 do_mkdirat+0x279/0x550 fs/namei.c:4038 __do_sys_mkdirat fs/namei.c:4053 [inline] __se_sys_mkdirat fs/namei.c:4051 [inline] __x64_sys_mkdirat+0x85/0x90 fs/namei.c:4051 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP：0033:0x7fcdc0113fd9 程式碼：ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP：002b:00007ffeb8bc67d8 EFLAGS：00000246 ORIG_RAX：0000000000000102 RAX：ffffffffffffffda RBX：0000000000000000 RCX：00007fcdc0113fd9 RDX：
0000000000000000 RSI：0000000020000340 RDI：0000000000000003 RBP：00007fcdc00d37a0 R08：0000000000000000 R09：00007fcdc00d37a0 R10：00005555559a72c0 R11：0000000000000246 R12：00000000f8008000 R13：
0000000000000000 R14：00083878000000f8 R15：0000000000000000 </TASK> 此問題因 fsi 的值小於 -1 所致。雖然系統可以檢查 fsi 值變為 -1 是否會發生迴圈中斷，但 syzbot 能夠產生小於 -1 的值 (導致錯誤)。此修補程式只針對小於 0 的值新增變更。此修補程式已經過 syzbot 測試。(CVE-2023-52603)
- 在 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 核心中，下列弱點已修正：ACPI：extlog：修正 NULL 指標解除參照檢查 gcc 外掛程式 -fanalyzer [1] 嘗試偵測各種錯誤行為模式。
工具報告：drivers/acpi/acpi_extlog.c：在函式 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) 在 (1) 中解除參照指標 extlog_l1_addr 後，在此處檢查其是否為 NULL | 修正 extlog_exit() 中的 NULL 指標解除參照檢查。(CVE-2023-52605)
- 在 Linux 核心中，下列弱點已修正：powerpc/lib：驗證向量作業的大小 sstep.c 中的某些 fp/vmx 程式碼會假設要模擬的指令有特定大小上限。不過，這些作業的大小會在 analyse_instr() 中單獨決定。新增一項檢查以驗證關於作業大小上限時的假設，以防止任何意外的核心堆疊損毀。(CVE-2023-52606)
- 在 Linux 核心中，下列弱點已修正：powerpc/mm：修正 pgtable_cache_add 中的 null 指標解除參照 kasprintf() 會向動態配置記憶體傳回指標，此指標在失敗時變為 NULL。透過檢查指標有效性確保配置成功。
(CVE-2023-52607)
- 作為 CVE-2023-33951 和 CVE-2023-33952 修正一部分所作的參照計數變更被用於儲存表面時，暴露了記憶體物件處理方式存在釋放後使用缺陷。在已啟用 3D 加速功能的 VMware 來賓內執行時，無權限的本機使用者可能利用此缺陷提升其權限。(CVE-2023-5633)
- 在 Linux 核心 fs/smb/client/smb2ops.c 的 smb2_dump_detail 中發現一個超出邊界讀取弱點。此問題允許本機攻擊者造成系統當機或洩漏核心內部資訊。
(CVE-2023-6610)
在 Linux 核心中，在 drivers/vhost/vhost.c 的 vhost_new_msg 中發現一個弱點，其不會正確初始化 vhost/vhost.c:vhost_new_msg() 函數中虛擬來賓和主機作業系統之間傳遞的訊息中的記憶體。這問題可允許有權限的本機使用者從 /dev/vhost-net 裝置檔案執行讀取作業時，讀取到一些核心記憶體內容。(CVE-2024-0340)
- Linux 核心的 netfilter: nf_tables 元件中有一個釋放後使用弱點，可遭惡意利用來提升本機權限。在釋放之前，nft_setelem_catchall_deactivate() 函式會檢查全能集元素在目前的世代中是否處於作用中狀態，而非在新一代中，但該函式只會在新一代中將其標示為非作用，因而可能多次釋放該元素，進而導致一個重複釋放弱點。我們建議升級上一個 commit b1db244ffd041a49ecc9618e8feb6b5c1afcdaa7。(CVE-2024-1085)
- Linux 核心的 netfilter: nf_tables 元件中有一個釋放後使用弱點，可遭惡意利用來提升本機權限。nft_verdict_init() 函式允許將正值視為勾點判定中的放置錯誤，因此當發出與 NF_ACCEPT 類似的放置錯誤的 NF_DROP 時，nf_hook_slow() 函式可造成重複釋放弱點。我們建議升級上一個 commit f342de4e2f33e0e39165d8639387aa6c19dff660。(CVE-2024-1086)
- 在 6.7.1 及其之前版本的 Linux 核心中，net/rds/af_rds.c 的 rds_recv_track_latency 中存在一個 RDS_MSG_RX_DGRAM_TRACE_MAX 比較的差一錯誤，這會導致超出邊界存取。(CVE-2024-23849)
- 在 Linux 核心的藍牙裝置驅動程式的 {min,max}_key_size_set() 函式中發現一個爭用情形。這可導致 null 指標解除參照問題，進而可能導致核心錯誤或拒絕服務問題。(CVE-2024-24860)
- 在 Linux 核心中，下列弱點已修正：netfilter：nft_set_rbtree：跳過來自 gc 的結束間隔元素 插入時，rbtree lazy gc 可能會收集此交易中剛新增的結束間隔元素，略過尚未啟用的結束間隔元素。(CVE-2024-26581)
- 在 Linux 核心中，下列弱點已修正：LoongArch：BPF：防止超出邊界讀取記憶體 test_tag 測試會觸發未處理的頁面錯誤：# ./test_tag [ 130.640218] CPU 0 無法處理在虛擬位址 ffff80001b898004 提出的核心分頁要求，era == 9000000003137f7c，ra == 9000000003139e70 [ 130.640501] Oops[#3]：[ 130.640553] CPU：0 PID：1326 命令：test_tag 已污染：G D O 6.7.0-rc4-loong-devel-gb62ab1a397cf #47 61985c1d94084daa2432f771daa45b56b10d8d2a [ 130.640764] 硬體名稱：QEMU QEMU 虛擬機器，BIOS 未知 2/2/2022 [ 130.640874] pc 9000000003137f7c ra 9000000003139e70 tp 9000000104cb4000 sp 9000000104cb7a40 [ 130.641001] a0 ffff80001b894000 a1 ffff80001b897ff8 a2 000000006ba210be a3 0000000000000000 [ 130.641128] a4 000000006ba210be a5 00000000000000f1 a6 00000000000000b3 a7 0000000000000000 [ 130.641256] t0 0000000000000000 t1 00000000000007f6 t2 0000000000000000 t3 9000000004091b70 [130.641387 ] t4 000000006ba210be t5 0000000000000004 t6 fffffffffffffff0 t7 90000000040913e0 [ 130.641512] t8 0000000000000005 u0 0000000000000dc0 s9 0000000000000009 s0 9000000104cb7ae0 [ 130.641641] s1 00000000000007f6 s2 0000000000000009 s3 0000000000000095 s4 0000000000000000 [ 130.641771] s5 ffff80001b894000 s6 ffff80001b897fb0 s7 9000000004090c50 s8 0000000000000000 [ 130.641900] ra: 9000000003139e70 build_body+0x1fcc/0x4988 [ 130.642007] ERA：9000000003137f7c build_body+0xd8/0x4988 [ 130.642112] CRMD：
000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) [ 130.642261] PRMD：00000004 (PPLV0 +PIE -PWE) [130.642353] EUEN：00000003 (+FPE +SXE -ASXE -BTE) [ 130.642458] ECFG：00071c1c (LIE=2-4、10-12 VS=7) [130.642554] ESTAT：00010000 [PIL] (IS= ECode=1 EsubCode=0) [ 130.642658] BADV：ffff80001b898004 [130.642719] PRID：0014c010 (Loongson-64bit、Loongson-3A5000) [ 130.642815] 模組連結位置：[last unloaded: bpf_testmod(O)] [ 130.642924] 處理 test_tag (pid：1326、threadinfo=00000000f7f4015f、task=000000006499f9fd) [ 130.643062] 堆疊：0000000000000000 9000000003380724 0000000000000000 0000000104cb7be8 [ 130.643213] 0000000000000000 25af8d9b6e600558 9000000106250ea0 9000000104cb7ae0 [130.643378] 0000000000000000 0000000000000000 9000000104cb7be8 90000000049f6000 [ 130.643538] 0000000000000090 9000000106250ea0 ffff80001b894000 ffff80001b894000 [ 130.643685] 00007ffffb917790 900000000313ca94 0000000000000000 0000000000000000 [ 130.643831] ffff80001b894000 0000000000000ff7 0000000000000000 9000000100468000 [ 130.643983] 0000000000000000 0000000000000000 0000000000000040 25af8d9b6e600558 [ 130.644131] 0000000000000bb7 ffff80001b894048 0000000000000000 0000000000000000 [130.644276] 9000000104cb7be8 90000000049f6000 0000000000000090 9000000104cb7bdc [ 130.644423] ffff80001b894000 0000000000000000 00007ffffb917790 90000000032acfb0 [ 130.644572] ... [ 130.644629] 呼叫追蹤：[ 130.644641] [<9000000003137f7c>] build_body+0xd8/0x4988 [ 130.644785] [<900000000313ca94>] bpf_int_jit_compile+0x228/0x4ec [ 130.644891] [<90000000032acfb0>] bpf_prog_select_runtime+0x158/0x1b0 [130.645003] [<90000000032b3504>] bpf_prog_load+0x760/0xb44 [ 130.645089] [<90000000032b6744>]
__sys_bpf+0xbb8/0x2588 [ 130.645175] [<90000000032b8388>] sys_bpf+0x20/0x2c [ 130.645259] [<9000000003f6ab38>] do_syscall+0x7c/0x94 [ 130.645369] [<9000000003121c5c>] handle_syscall+0xbc/0x158 [130.645507] [ 130.645539] 程式碼：380839f6 380831f9 28412bae <24000ca6> 004081ad 0014cb50 004083e8 02bff34c 58008e91 [ 130.645729] [ 130.646418] ---[結束追蹤 0000000000000000 ]--- 在我的機器 (含有 CONFIG_PAGE_SIZE_16KB=y) 上，根據 2039 指示載入 BPF prog 的測試失敗：prog = (struct bpf_prog *)ffff80001b894000 insn = (struct bpf_insn *)(prog->insnsi)fff ---truncated--- (CVE-2024-26588)
- 在 Linux 核心中，下列弱點已修正：bpf：拒絕 PTR_TO_FLOW_KEYS 上的變數位移 alu 對於 PTR_TO_FLOW_KEYS，check_flow_keys_access() 僅使用修正的 off 進行驗證。
不過，未針對此 ptr 類別禁止變數位移 ptr alu。因此系統不會檢查變數位移。已接受以下 prog：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 此 prog 將 flow_keys 載入 r7，並將變數位移 r8 增加到 r7，最終導致超出邊界存取：錯誤：無法處理位址頁面錯誤：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 上拒絕使用變數位移的 ptr alu 來修正此弱點。套用修補程式，拒絕執行「禁止在 flow_keys 上使用 R7 指標算術」的程式。(CVE-2024-26589)
- 在 Linux 核心中，下列弱點已修正：bpf：修正 bpf_tracing_prog_attach 中的重新附加分支。由於缺少 ttach_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 載入程式，但我們無法找出是哪一個 錯誤：核心 NULL 指標解除參照，位於：0000000000000058 呼叫追蹤：<TASK> ? __die+0x20/0x70 ? page_fault_oops+0x15b/0x430 ? fixup_exception+0x22/0x330 ? exc_page_fault+0x6f/0x170 ? asm_exc_page_fault+0x22/0x30 ? bpf_tracing_prog_attach+0x279/0x560 ? btf_obj_id+0x5/0x10 bpf_tracing_prog_attach+0x439/0x560 __sys_bpf+0x1cf4/0x2de0 __x64_sys_bpf+0x1c/0x30 do_syscall_64+0x41/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0x76 在此情況下傳回 -EINVAL。
(CVE-2024-26591)
- 在 Linux 核心中，下列弱點已修正：ksmbd：修正 ksmbd_tcp_new_connection() 中的 UAF 問題 處理新的 TCP 連線與中斷連線時發生爭用。
這會導致 ksmbd_tcp_new_connection() 函式中的「struct tcp_transport」發生 UAF。(CVE-2024-26592)
- 在 Linux 核心中，下列弱點已修正：ksmbd：驗證工作階段設定中的 mech token 若用戶端在工作階段設定要求中傳送無效的 mech token，ksmbd 會進行驗證並在確定無效時產生錯誤。(CVE-2024-26594)
- 在 Linux 核心中，下列弱點已修正：net：qualcomm：rmnet：修正 rmnet_policy 中的全域 oob 變數 rmnet_link_ops 會指派*更大的*maxtype 弱點，其會在剖析 netlink 屬性時導致發生全域超出邊界讀取。請參閱以下錯誤追蹤：
================================================== ================ 錯誤：KASAN：validate_nla lib/nlattr.c:386 中存在 global-out-of-bounds [inline] 錯誤：KASAN：
__nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600 中存在 global-out-of-bounds 讀取大小為 1 位於：addr ffffffff92c438d0 按工作 syz-executor.6/84207 CPU：0 PID：84207 命令：syz-executor.6 未污染：G N 6.1.0 #3 硬體名稱：QEMU Standard PC (i440FX + PIIX，1996)，BIOS 1.13.0-1ubuntu1.1 04/01/2014 呼叫追蹤：<TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x8b/0xb3 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:284 [inline] print_report+0x172/0x475 mm/kasan/report.c:395 kasan_report+0xbb/0x1c0 mm/kasan/report.c:495 validate_nla lib/nlattr.c:386 [inline] __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600 __nla_parse+0x3e/0x50 lib/nlattr.c:697 nla_parse_nested_deprecated include/net/netlink.h:1248 [inline] __rtnl_newlink+0x50a/0x1880 net/core/rtnetlink.c:3485 rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3594 rtnetlink_rcv_msg+0x43c/0xd70 net/core/rtnetlink.c:6091 netlink_rcv_skb+0x14f/0x410 net/netlink/af_netlink.c:2540 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] netlink_unicast+0x54e/0x800 net/netlink/af_netlink.c:1345 netlink_sendmsg+0x930/0xe50 net/netlink/af_netlink.c:1921 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg+0x154/0x190 net/socket.c:734 ____sys_sendmsg+0x6df/0x840 net/socket.c:2482
___sys_sendmsg+0x110/0x1b0 net/socket.c:2536 __sys_sendmsg+0xf3/0x1c0 net/socket.c:2565 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fdcf2072359 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP：002b:00007fdcf13e3168 EFLAGS：00000246 ORIG_RAX：000000000000002e RAX：ffffffffffffffda RBX：00007fdcf219ff80 RCX：00007fdcf2072359 RDX：
0000000000000000 RSI：0000000020000200 RDI：0000000000000003 RBP：00007fdcf20bd493 R08：0000000000000000 R09：0000000000000000 R10：0000000000000000 R11：0000000000000246 R12：0000000000000000 R13：
00007fffbb8d7bdf R14：00007fdcf13e3300 R15：0000000000022000 </TASK> 錯誤位址屬於變數：rmnet_policy+0x30/0xe0 錯誤位址屬於實體頁面：page:0000000065bdeb3c refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x155243 旗標：
0x200000000001000(reserved|node=0|zone=2) raw：0200000000001000 ffffea00055490c8 ffffea00055490c8 0000000000000000 raw：0000000000000000 0000000000000000 00000001ffffffff 0000000000000000 頁面被棄用，因為：kasan：檢測到不良存取 錯誤位址記憶體狀態：ffffffff92c43780：f9 f9 f9 f9 00 00 00 02 f9 f9 f9 f9 00 00 00 07 ffffffff92c43800：f9 f9 f9 f9 00 00 00 05 f9 f9 f9 f9 06 f9 f9 f9 >ffffffff92c43880：f9 f9 f9 f9 00 00 00 00 00 00 f9 f9 f9 f9 f9 f9 ^ ffffffff92c43900：00 00 00 00 00 00 00 00 07 f9 f9 f9 f9 f9 f9 f9 ffffffff92c43980：00 00 00 07 f9 f9 f9 f9 00 00 00 05 f9 f9 f9 f9 根據「nla_parse_nested_deprecated」的註解，maxtype 應為 len (目的地陣列) - 1. 因此在此處使用「IFLA_RMNET_MAX」。(CVE-2024-26597)
- 在 Linux 核心中，已解決下列弱點：KVM：arm64：vgic-its：避免 LPI 轉譯快取中可能發生的 UAF。LPI 轉譯快取命中與使快取無效的作業 (例如 DISCARD ITS 命令等) 爭用的情況下，可能發生 UAF 狀況。問題的根本在於 vgic_its_check_cache() 未先提升 vgic_irq 上的 refcount，便卸除將 refcount 變更序列化的鎖定。讓 vgic_its_check_cache() 在已傳回的 vgic_irq 上增加 refcount，並在將中斷排入佇列之後，新增對應的遞減。(CVE-2024-26598)
- 在 Linux 核心中，下列弱點已修正：pwm：修正 of_pwm_single_xlate() 因 args->args_count == 2 args->args[2] 未定義而引起的超出邊界存取。實際上，旗標包含在 args->args[1] 中。(CVE-2024-26599)
- 在 Linux 核心中，下列弱點已修正：phy：ti：phy-omap-usb2：修正 SRP 的 NULL 指標解除參照 若與 phy-omap-usb2 搭配使用的外部 phy 未實作 send_srp()，我們可能仍會嘗試進行呼叫。這種情況可能發生在閒置乙太網路小工具觸發喚醒時，例如 configfs-gadget.g1 gadget.0：ECM 暂停 configfs-gadget.g1 gadget.0：連接埠已暫停。
正在觸發喚醒… 執行…時，無法處理虛擬位址 00000000 處發生的核心 NULL 指標解除參照PC 位於 0x0 LR 位於 musb_gadget_wakeup+0x1d4/0x254 [musb_hdrc] ... musb_gadget_wakeup [musb_hdrc] from usb_gadget_wakeup+0x1c/0x3c [udc_core] usb_gadget_wakeup [udc_core] from eth_start_xmit+0x3b0/0x3d4 [u_ether] eth_start_xmit [u_ether] from dev_hard_start_xmit+0x94/0x24c dev_hard_start_xmit from sch_direct_xmit+0x104/0x2e4 sch_direct_xmit from __dev_queue_xmit+0x334/0xd88
__dev_queue_xmit from arp_solicit+0xf0/0x268 arp_solicit from neigh_probe+0x54/0x7c neigh_probe from
__neigh_event_send+0x22c/0x47c __neigh_event_send from neigh_resolve_output+0x14c/0x1c0 neigh_resolve_output from ip_finish_output2+0x1c8/0x628 ip_finish_output2 from ip_send_skb+0x40/0xd8 ip_send_skb from udp_send_skb+0x124/0x340 udp_send_skb from udp_sendmsg+0x780/0x984 udp_sendmsg from
__sys_sendto+0xd8/0x158 __sys_sendto from ret_fast_syscall+0x0/0x58 要解決此問題，我們可以檢查 send_srp() 和 set_vbus() 之后再進行呼叫。對於僅限 USB 周邊的情況下，這兩者都可以是 NULL。
(CVE-2024-26600)
- 在 Linux 核心中，下列弱點已修正：ext4：在 fc 重播的情況下，系統會在區塊釋放失敗後重新產生 buddy 這主要會導致復原 commit 6bd97bf273bd (ext4：移除多餘的 mb_regenerate_buddy()) 並重新引入 mb_regenerate_buddy()。根據 mb_free_blocks() 中的程式碼，快速 commit 重播最終會導致區塊被重複標記為已释放。這會造成 buddy 點陣圖損毀，因此我們需要在這種情況下重新產生點陣圖。(CVE-2024-26601)
- 在 Linux 核心中，下列弱點已修正：af_unix：修正 sk_diag_dump_icons() 中的 lockdep 误报 syzbot 報告了 lockdep 展開 [1]。Blamed commit 暗示了可能的 lockdep 違規，並且程式碼使用了 unix_state_lock_nested() 來試圖使 lockdep 靜音。這還不夠，因為已使用 unix_state_double_lock() 中的 unix_state_lock_nested()。我們需要使用獨立的子類別。此修補程式新增了獨特的列舉，使事情變得更明確。也可使用 unix_state_double_lock() 中的 swap() 進行清理。v2：向 unix_state_lock_nested() 新增遺漏的內嵌關鍵字 [1] 警告：偵測到可能存在循環鎖定相依性 6.8.0-rc1-syzkaller-00356-g8a696a29c690 #0 未污染 syz-executor.1/2542 嘗試取得鎖定：ffff88808b5df9e8 (rlock-AF_UNIX){+.+.}-{2:2}，位於：
skb_queue_tail+0x36/0x120 net/core/skbuff.c:3863 但工作正在保持鎖定：ffff88808b5dfe70 (&u->lock/1){+.+.}-{2:2}，位於：unix_dgram_sendmsg+0xfc7/0x2200 net/unix/af_unix.c:2089 哪項鎖定依賴新的鎖定。現有的相依性連結 (倒序) 為：-> #1 (&u->lock/1){+.+.}-{2:2}：lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754
_raw_spin_lock_nested+0x31/0x40 kernel/locking/spinlock.c:378 sk_diag_dump_icons net/unix/diag.c:87 [inline] sk_diag_fill+0x6ea/0xfe0 net/unix/diag.c:157 sk_diag_dump net/unix/diag.c:196 [inline] unix_diag_dump+0x3e9/0x630 net/unix/diag.c:220 netlink_dump+0x5c1/0xcd0 net/netlink/af_netlink.c:2264
__netlink_dump_start+0x5d7/0x780 net/netlink/af_netlink.c:2370 netlink_dump_start include/linux/netlink.h:338 [inline] unix_diag_handler_dump+0x1c3/0x8f0 net/unix/diag.c:319 sock_diag_rcv_msg+0xe3/0x400 netlink_rcv_skb+0x1df/0x430 net/netlink/af_netlink.c:2543 sock_diag_rcv+0x2a/0x40 net/core/sock_diag.c:280 netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x7e6/0x980 net/netlink/af_netlink.c:1367 netlink_sendmsg+0xa37/0xd70 net/netlink/af_netlink.c:1908 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] sock_write_iter+0x39a/0x520 net/socket.c:1160 call_write_iter include/linux/fs.h:2085 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0xa74/0xca0 fs/read_write.c:590 ksys_write+0x1a0/0x2c0 fs/read_write.c:643 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b -> #0 (rlock-AF_UNIX){+.+.}-{2:2}：check_prev_add kernel/locking/lockdep.c:3134 [inline] check_prevs_add kernel/locking/lockdep.c:3253 [inline] validate_chain+0x1909/0x5ab0 kernel/locking/lockdep.c:3869
__lock_acquire+0x1345/0x1fd0 kernel/locking/lockdep.c:5137 lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
_raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162 skb_queue_tail+0x36/0x120 net/core/skbuff.c:3863 unix_dgram_sendmsg+0x15d9/0x2200 net/unix/af_unix.c:2112 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] ____sys_sendmsg+0x592/0x890 net/socket.c:2584 ___sys_sendmsg net/socket.c:2638 [inline] __sys_sendmmsg+0x3b2/0x730 net/socket.c:2724
__do_sys_sendmmsg net/socket.c:2753 [inline] __se_sys_sendmmsg net/socket.c:2750 [inline]
__x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2750 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b 可能有助於我們對此問題進行除錯的其他資訊：可能不安全的鎖定情況：CPU0 ---truncated--- (CVE-2024-26624)
- 在 Linux 核心中，下列弱點已修正：llc：在發佈時呼叫 sock_orphan() syzbot 報告了一個相關追蹤 [1]，因已關閉的 llc 通訊端中的過時 sk->sk_wq 指標造成。
在 commit ff7b11aa481f (net：socket：呼叫 proto_ops::release() 后，將 sock->sk 設為 NULL) 中，Eric Biggers 提示某些通訊協定遺漏 sock_orphan()，我們需要執行完整稽核。在 net-next 中，我計劃從 sock_orphan() 清除 sock->sk 並修正 Eric 修補程式以新增警告。[1] 錯誤：KASAN：
list_empty 中的 slab-use-after-free，include/linux/list.h:373 [inline] 錯誤：KASAN：waitqueue_active 中的 slab-use-after-free，include/linux/wait.h:127 [inline] 錯誤：KASAN：sock_def_write_space_wfree 中的 slab-use-after-free，net/core/sock.c:3384 [inline] 錯誤：KASAN：sock_wfree+0x9a8/0x9d0 中的 slab-use-after-free，net/core/sock.c:2468 讀取大小為 8 位於：addr ffff88802f4fc880 按工作 ksoftirqd/1/27 CPU：1 PID：27 命令：ksoftirqd/1 未污染 6.8.0-rc1-syzkaller-00049-g6098d87eaf31 #0 硬體名稱：
QEMU Standard PC (Q35 + ICH9，2009)、BIOS 1.16.2-debian-1.16.2-1 04/01/2014 呼叫追蹤：<TASK>
__dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc4/0x620 mm/kasan/report.c:488 kasan_report+0xda/0x110 mm/kasan/report.c:601 list_empty include/linux/list.h:373 [inline] waitqueue_active include/linux/wait.h:127 [inline] sock_def_write_space_wfree net/core/sock.c:3384 [inline] sock_wfree+0x9a8/0x9d0 net/core/sock.c:2468 skb_release_head_state+0xa3/0x2b0 net/core/skbuff.c:1080 skb_release_all net/core/skbuff.c:1092 [inline] napi_consume_skb+0x119/0x2b0 net/core/skbuff.c:1404 e1000_unmap_and_free_tx_resource+0x144/0x200 drivers/net/ethernet/intel/e1000/e1000_main.c:1970 e1000_clean_tx_irq drivers/net/ethernet/intel/e1000/e1000_main.c:3860 [inline] e1000_clean+0x4a1/0x26e0 drivers/net/ethernet/intel/e1000/e1000_main.c:3801 __napi_poll.constprop.0+0xb4/0x540 net/core/dev.c:6576 napi_poll net/core/dev.c:6645 [inline] net_rx_action+0x956/0xe90 net/core/dev.c:6778
__do_softirq+0x21a/0x8de kernel/softirq.c:553 run_ksoftirqd kernel/softirq.c:921 [inline] run_ksoftirqd+0x31/0x60 kernel/softirq.c:913 smpboot_thread_fn+0x660/0xa10 kernel/smpboot.c:164 kthread+0x2c6/0x3a0 kernel/kthread.c:388 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:242 </TASK> 根據工作 5167 配置：
kasan_save_stack+0x33/0x50 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:314 [inline] __kasan_slab_alloc+0x81/0x90 mm/kasan/common.c:340 kasan_slab_alloc include/linux/kasan.h:201 [inline] slab_post_alloc_hook mm/slub.c:3813 [inline] slab_alloc_node mm/slub.c:3860 [inline] kmem_cache_alloc_lru+0x142/0x6f0 mm/slub.c:3879 alloc_inode_sb include/linux/fs.h:3019 [inline] sock_alloc_inode+0x25/0x1c0 net/socket.c:308 alloc_inode+0x5d/0x220 fs/inode.c:260 new_inode_pseudo+0x16/0x80 fs/inode.c:1005 sock_alloc+0x40/0x270 net/socket.c:634
__sock_create+0xbc/0x800 net/socket.c:1535 sock_create net/socket.c:1622 [inline] __sys_socket_create net/socket.c:1659 [inline] __sys_socket+0x14c/0x260 net/socket.c:1706 __do_sys_socket net/socket.c:1720 [inline] __se_sys_socket net/socket.c:1718 [inline] __x64_sys_socket+0x72/0xb0 net/socket.c:1718 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd3/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b 由工作 0 釋放：kasan_save_stack+0x33/0x50 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640 poison_slab_object mm/kasan/common.c:241 [inline] __kasan_slab_free+0x121/0x1b0 mm/kasan/common.c:257 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2121 [inlin ---truncated--- (CVE-2024-26625)
- 在 Linux 核心中，下列弱點已修正：scsi：核心：將 scsi_host_busy() 移除主機鎖定，以喚醒 EH 處置程式 在 scsi_eh_wakeup() 中，每次都會呼叫並檢查主機鎖定，以決定是否需要喚醒錯誤處置程式 kthread。在復原的情況下，負載可能過重，例如：- N 個硬體佇列 - 每個硬體佇列的佇列深度為 M - 每個 scsi_host_busy() 迭代 (N * M) 個標籤/要求 觸發復原需要滿足下列條件：每個要求都在進行中，每個 scsi_eh_wakeup() 都經過嚴格序列化，已為最後一個進行中的要求呼叫 scsi_eh_wakeup()，scsi_host_busy() 已執行 (N * M - 1) 次，要求已迭代 (N*M - 1) * (N * M) 次。如果 N 和 M 都夠大，則可在取得主機鎖定時觸發硬鎖定，且可在 mpi3mr (128 hw 佇列，佇列深度 8169) 上觀察到。透過在主機鎖定之外呼叫 scsi_host_busy() 來解決此問題。我們不需要透過主機鎖定獲取 busy 計數，因為這絕非主機鎖定的功能。[中斷 Bart 指出的非必要「busy」變數 ] (CVE-2024-26627)
- 在 Linux 核心中，下列弱點已修正：drm/amdkfd：修正鎖定相依性警告 ============================= ========================= 警告：偵測到可能的循環鎖定相依性 6.5.0-kfd-fkuehlin #276 未污染
-------------------------------------------------- ---- kworker/8:2/2676 正在嘗試取得鎖定：
ffff9435aae95c88 ((work_completion)(&svm_bo->eviction_work)){+.+.}-{0:0}，位於：__flush_work+0x52/0x550 但工作正在保持鎖定：ffff9435cd8e1720 (&svms->lock){+.+.}-{3:3}，位於：
svm_range_deferred_list_work+0xe8/0x340 [amdgpu] 哪項鎖定依賴新的鎖定。現有的相依性連結 (倒序) 為：-> #2 (&svms->lock){+.+.}-{3:3}：__mutex_lock+0x97/0xd30 kfd_ioctl_alloc_memory_of_gpu+0x6d/0x3c0 [amdgpu] kfd_ioctl+0x1b2/0x5d0 [amdgpu] __x64_sys_ioctl+0x86/0xc0 do_syscall_64+0x39/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd -> #1 (&mm->mmap_lock){++++}-{3:3}：
down_read+0x42/0x160 svm_range_evict_svm_bo_worker+0x8b/0x340 [amdgpu] process_one_work+0x27a/0x540 worker_thread+0x53/0x3e0 kthread+0xeb/0x120 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x11/0x20 -> #0 ((work_completion)(&svm_bo->eviction_work)){+.+.}-{0:0}：__lock_acquire+0x1426/0x2200 lock_acquire+0xc1/0x2b0 __flush_work+0x80/0x550 __cancel_work_timer+0x109/0x190 svm_range_bo_release+0xdc/0x1c0 [amdgpu] svm_range_free+0x175/0x180 [amdgpu] svm_range_deferred_list_work+0x15d/0x340 [amdgpu] process_one_work+0x27a/0x540 worker_thread+0x53/0x3e0 kthread+0xeb/0x120 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x11/0x20 可能有助於我們對此問題進行除錯的其他資訊：鏈存在於：(work_completion)(&svm_bo->eviction_work) --> &mm->mmap_lock --> &svms->lock 可能不安全的鎖定情況：CPU0 CPU1 ---- ---- lock(&svms->lock); lock(&mm->mmap_lock);
lock(&svms->lock); lock((work_completion)(&svm_bo->eviction_work)); 我認為這實際上不會導致鎖死，因為 svm_range_evict_svm_bo_worker 只有在 BO refcount 為非 0 時才會採用 mmap_read_lock。這表示 svm_range_bo_release 不可能同時執行。不過，沒有好的方式對此进行註解。若要避免此問題，請在 svm_range_schedule_evict_svm_bo 而非背景工作中使用 BO 參照。如此一來，若收回工作擱置，BO 便無法被釋放，且 svm_range_bo_release 中的 cancel_work_sync 呼叫可被消除。
v2：使用 svm_bo_ref_unless_zero 並說明它為什麼安全。也移除了已在 amdkfd_fence_enable_signaling 中完成的多餘檢查。(CVE-2024-26628)
請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。
解決方案
更新受影響的 kernel 套件。另請參閱
Plugin 詳細資訊
嚴重性: High
ID: 191796
檔案名稱: ubuntu_USN-6688-1.nasl
版本: 1.3
類型: local
代理程式: unix
已發布: 2024/3/11
已更新: 2024/4/18
支援的感應器: Agentless Assessment, Frictionless Assessment Agent, Frictionless Assessment AWS, Frictionless Assessment Azure, Nessus Agent, Nessus
風險資訊
VPR
風險因素: Critical
分數: 9.6
CVSS v2
風險因素: Medium
基本分數: 6.8
時間分數: 5.9
媒介: CVSS2#AV:L/AC:L/Au:S/C:C/I:C/A:C
CVSS 評分資料來源: CVE-2024-26599
CVSS v3
風險因素: High
基本分數: 7.8
時間分數: 7.5
媒介: CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
時間媒介: CVSS:3.0/E:H/RL:O/RC:C
弱點資訊
CPE: cpe:/o:canonical:ubuntu_linux:22.04:-:lts, p-cpe:/a:canonical:ubuntu_linux:linux-image-6.1.0-1035-oem
必要的 KB 項目: Host/cpu, Host/Ubuntu, Host/Ubuntu/release, Host/Debian/dpkg-l
可被惡意程式利用: true
可輕鬆利用: Exploits are available
修補程式發佈日期: 2024/3/11
弱點發布日期: 2023/10/23
參考資訊
CVE: CVE-2023-46838, CVE-2023-50431, CVE-2023-52436, CVE-2023-52438, CVE-2023-52439, CVE-2023-52443, CVE-2023-52444, CVE-2023-52445, CVE-2023-52447, CVE-2023-52448, CVE-2023-52449, CVE-2023-52451, CVE-2023-52454, CVE-2023-52456, CVE-2023-52457, CVE-2023-52458, CVE-2023-52462, CVE-2023-52463, CVE-2023-52464, CVE-2023-52467, CVE-2023-52469, CVE-2023-52470, CVE-2023-52583, CVE-2023-52584, CVE-2023-52587, CVE-2023-52588, CVE-2023-52589, CVE-2023-52593, CVE-2023-52594, CVE-2023-52595, CVE-2023-52597, CVE-2023-52598, CVE-2023-52599, CVE-2023-52600, CVE-2023-52601, CVE-2023-52602, CVE-2023-52603, CVE-2023-52604, CVE-2023-52605, CVE-2023-52606, CVE-2023-52607, CVE-2023-5633, CVE-2023-6610, CVE-2024-0340, CVE-2024-1085, CVE-2024-1086, CVE-2024-23849, CVE-2024-24860, CVE-2024-26581, CVE-2024-26588, CVE-2024-26589, CVE-2024-26591, CVE-2024-26592, CVE-2024-26594, CVE-2024-26597, CVE-2024-26598, CVE-2024-26599, CVE-2024-26600, CVE-2024-26601, CVE-2024-26624, CVE-2024-26625, CVE-2024-26627, CVE-2024-26628
USN: 6688-1