Ubuntu 20.04 LTS/22.04 LTS：Linux 核心弱點 (USN-6725-1)
critical Nessus Plugin ID 193084
語系：
概要
遠端 Ubuntu 主機缺少一個或多個安全性更新。說明
遠端 Ubuntu 20.04 LTS/22.04 LTS 主機上安裝的一個套件受到 USN-6725-1 公告中所提及的多個弱點影響。- 在 Linux 核心中，核心內 samba 伺服器和 CIFS 的 KSMBD 實作的 parse_lease_state 中發現超出邊界 (OOB) 記憶體讀取缺陷。當攻擊者將含有格式錯誤承載的 CREATE 命令傳送至 KSMBD 時，由於缺少對 `parse_lease_state()` 函式中的 `NameOffset` 檢查，`create_context` 物件可存取無效的記憶體。(CVE-2023-1194)
- 在 Linux 核心的 ksmbd (一種高效能核心內 SMB 伺服器) 中發現一個缺陷。處理 SMB2_TREE_DISCONNECT 命令的過程中存在特定瑕疵。此問題的原因在於，在物件上執行作業時缺少適當的鎖定。攻擊者可利用此弱點，在核心環境中執行程式碼。(CVE-2023-32254)
- 在 Linux 核心的 ksmbd (一種高效能核心內 SMB 伺服器) 中發現一個缺陷。處理 SMB2_LOGOFF 和 SMB2_CLOSE 命令的過程中存在特定瑕疵。此問題的原因在於，在物件上執行作業時缺少適當的鎖定。攻擊者可利用此弱點，在核心環境中執行程式碼。(CVE-2023-32258)
- 在 6.3.8 之前的 Linux 核心中發現一個問題。 ksmbd 中的 fs/smb/server/smb2pdu.c 在 deassemble_neg_contexts 中有整數反向溢位和超出邊界讀取問題。(CVE-2023-38427)
- 在 6.3.9 之前的 Linux 核心中發現一個問題。ksmbd 未驗證 SMB 要求通訊協定 ID，進而導致超出邊界讀取。(CVE-2023-38430)
- 在 6.3.8 之前的 Linux 核心中發現一個問題。 ksmbd 中的 fs/smb/server/connection.c 透過 pdu_size in ksmbd_conn_handler_loop 未驗證 NetBIOS 標頭長度欄位與 SMB 標頭大小之間的關係，進而導致超出邊界讀取。(CVE-2023-38431)
- Xen 虛擬網路通訊協定中的傳輸要求可由多個部分組成。雖然這些部分不是真的實用，但除了初始部分，其中任何一個都可能是零長度，即根本不攜帶任何資料。除了要傳輸資料的特定初始部分，這些部分會直接轉譯為 Linux 所稱的 SKB 片段。這類轉換的要求部分在針對特定 SKB 而言長度為零時，可導致核心網路程式碼中出現 NULL 解除參照。(CVE-2023-46838)
- 在 6.7.4 及之前的 Linux 核心中，drivers/md/dm-table.c 中的 dm_table_create 會嘗試 (在 alloc_targets 中) 分配大於 INT_MAX 的位元組，但此位元組會因缺少對 dm_ioctl.target_count 結構的檢查而損毀。(CVE-2023-52429)
- 在 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 核心中，下列弱點已解決：ksmbd：修復 init_smb2_rsp_hdr() 中的超出邊界問題。若用戶端傳送 smb2 交涉要求，然後再傳送 smb1 交涉要求，系統就會因 need_neg 設為 false，針對 smb1 交涉要求呼叫 init_smb2_rsp_hdr。在 ->need_neg 設為 false 後，此修補程式會略過 smb1 封包。(CVE-2023-52441)
- 在 Linux 核心中，下列弱點已解決：ksmbd：smb2_get_ksmbd_tcon() 和 smb2_check_user_session() 中的 `smb2_get_msg()` 將驗證複合要求中的工作階段 ID 和樹狀結構 ID，並將一律傳回複合要求中的第一個要求 smb2 標頭。若 `SMB2_TREE_CONNECT_HE` 是複合要求中的第一個命令， 將會傳回 0，即略過樹狀結構 id 檢查。此修補程式會使用 ksmbd_req_buf_next() 取得複合中的最新命令。(CVE-2023-52442)
- 在 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 核心中，下列弱點已修復：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 核心中，下列弱點已解決：ksmbd：修復工作階段查閱和到期之間的爭用情形 執行緒 A + 執行緒 B ksmbd_session_lookup | smb2_sess_setup sess = xa_load | | | xa_erase(&conn->sessions, sess->id); | | ksmbd_session_destroy(sess) --> kfree(sess) | // UAF! | sess->last_active = jiffies | + 此修補程式會新增 rwsem 以修復 ksmbd_session_lookup 和 ksmbd_expire_session 之間的爭用情形。(CVE-2023-52480)
- 在 Linux 核心中，下列弱點已解決：binder：修復 mmput() 和 do_exit() 之間的爭用。工作 A 會呼叫 binder_update_page_range()，以便從工作 B 的遠端位址空間配置和插入頁面。為此，工作 A 會先透過 mmget_not_zero() 釘選遠端 mm。這可與工作 B do_exit() 造成爭用，且最終的 mmput() refcount 遞減將來自 工作 A。工作 A | 工作 B
-------------------+-------------------------------- mmget_not_zero() | | do_exit() | exit_mm() | mmput() mmput() | exit_mmap() | remove_vma() | fput() | 在此情況下，工作 B 的____fput() 工作會在工作 A 中排入 TWA_RESUME 佇列。因此理論上，工作 A 會傳回使用者空間並執行清理工作。
不過，工作 A 會改而進入睡眠狀態，等待從未收到的工作 B 回覆 (已終止)。這表示 binder_deferred_release() 會遭到封鎖，直到不相關的 binder 事件強制工作 A 回到使用者空間為止。在此之前，所有相關聯的死亡通知也會延遲。若要修復此問題，請使用 mmput_async()，其將在對應的 mm->async_put_work WQ 而非工作 A 中排程工作。(CVE-2023-52609)
- 在 Linux 核心中，下列弱點已解決：net/sched：act_ct：修復 ooo 片段上的 skb 洩漏和損毀。act_ct 會在分割前新增 skb->users。如果片段按順序送達，最後一個片段的參照會重設於： inet_frag_reasm_prepare skb_morph 中，而這並不簡單。但是，當片段無序送達時，沒有人會取消參照最後一個片段，因此會洩漏所有片段。情況甚至更為嚴重，因為同時複製和共用 skb 時，初始化封包擷取可導致當機 [0]。透過在分割之前移除 skb_get() 來修復此問題。分割失敗或正在進行時，act_ct 會傳回 TC_ACT_CONSUMED。[0]：[843.804823] ------------[ cut here ]------------ [843.809659] net/core/skbuff.c:2091! 的存在核心錯誤 [843.814516] 無效 opcode：0000 [#1] PREEMPT SMP [843.819296] CPU：7 PID：0 Comm：swapper/7 Kdump：已載入 污染：GS 6.7.0-rc3 #2 [843.824107] 硬體名稱：XFUSION 1288H V6/BC13MBSBD、BIOS 1.29 11/25/2022 [ 843.828953] RIP: 0010:pskb_expand_head+0x2ac/0x300 [ 843.833805] 程式碼：8b 70 28 48 85 f6 74 82 48 83 c6 08 bf 01 00 00 00 e8 38 bd ff ff 8b 83 c0 00 00 00 48 03 83 c8 00 00 00 e9 62 ff ff 0f 0b <0f> 0b e8 8d d0 ff ff e9 b3 fd ff ff 81 7c 24 14 40 01 00 00 4c 89 [843.843698] RSP: 0018:ffffc9000cce07c0 EFLAGS: 00010202 [ 843.848524] RAX: 0000000000000002 RBX:
ffff88811a211d00 RCX: 0000000000000820 [ 843.853299] RDX: 0000000000000640 RSI: 0000000000000000 RDI:
ffff88811a211d00 [ 843.857974] RBP: ffff888127d39518 R08: 00000000bee97314 R09: 0000000000000000 [843.862584] R10: 0000000000000000 R11: ffff8881109f0000 R12: 0000000000000880 [ 843.867147] R13:
ffff888127d39580 R14: 0000000000000640 R15: ffff888170f7b900 [ 843.871680] FS: 0000000000000000(0000) GS:ffff889ffffc0000(0000) knlGS:0000000000000000 [ 843.876242] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033 [ 843.880778] CR2: 00007fa42affcfb8 CR3: 000000011433a002 CR4: 0000000000770ef0 [843.885336] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 843.889809] DR3:
0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 843.894229] PKRU: 55555554 [ 843.898539] 呼叫追蹤：[ 843.902772] <IRQ> [ 843.906922] ? __die_body+0x1e/0x60 [ 843.911032] ? die+0x3c/0x60 [843.915037] ? do_trap+0xe2/0x110 [ 843.918911] ? pskb_expand_head+0x2ac/0x300 [ 843.922687] ? do_error_trap+0x65/0x80 [ 843.926342] ? pskb_expand_head+0x2ac/0x300 [ 843.929905] ? exc_invalid_op+0x50/0x60 [ 843.933398] ? pskb_expand_head+0x2ac/0x300 [ 843.936835] ? asm_exc_invalid_op+0x1a/0x20 [ 843.940226] ? pskb_expand_head+0x2ac/0x300 [ 843.943580] inet_frag_reasm_prepare+0xd1/0x240 [ 843.946904] ip_defrag+0x5d4/0x870 [ 843.950132] nf_ct_handle_fragments+0xec/0x130 [nf_conntrack] [ 843.953334] tcf_ct_act+0x252/0xd90 [act_ct] [843.956473] ? tcf_mirred_act+0x516/0x5a0 [act_mirred] [ 843.959657] tcf_action_exec+0xa1/0x160 [843.962823] fl_classify+0x1db/0x1f0 [cls_flower] [ 843.966010] ? skb_clone+0x53/0xc0 [ 843.969173] tcf_classify+0x24d/0x420 [ 843.972333] tc_run+0x8f/0xf0 [ 843.975465]
__netif_receive_skb_core+0x67a/0x1080 [ 843.978634] ? dev_gro_receive+0x249/0x730 [ 843.981759]
__netif_receive_skb_list_core+0x12d/0x260 [ 843.984869] netif_receive_skb_list_internal+0x1cb/0x2f0 [843.987957] ? mlx5e_handle_rx_cqe_mpwrq_rep+0xfa/0x1a0 [mlx5_core] [ 843.991170] napi_complete_done+0x72/0x1a0 [ 843.994305] mlx5e_napi_poll+0x28c/0x6d0 [mlx5_core] [ 843.997501]
__napi_poll+0x25/0x1b0 [ 844.000627] net_rx_action+0x256/0x330 [ 844.003705] __do_softirq+0xb3/0x29b [844.006718] irq_exit_rcu+0x9e/0xc0 [ 844.009672] common_interrupt+0x86/0xa0 [ 844.012537] </IRQ> [844.015285] <TASK> [ 844.017937] asm_common_interrupt+0x26/0x40 [ 844.020591] RIP:
0010:acpi_safe_halt+0x1b/0x20 [ 844.023247] Code: ff 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 65 48 8b 04 25 00 18 03 00 48 8b 00 a8 08 75 0c 66 90 0f 00 2d 81 d0 44 00 fb ---truncated--- (CVE-2023-52610)
- 在 Linux 核心中，下列弱點已解決：crypto: scomp - 修復 req->dst 緩衝區溢位。應在從 scomp_scratch->dst 複製之前檢查 req->dst 緩衝區大小，以避免 req->dst 緩衝區溢位問題。(CVE-2023-52612)
- 在 Linux 核心 6.6.10 之前版本的 ksmbd 中發現一個問題。由於未正確處理名稱資料和 CreateContexts 資料之間的關係，fs/smb/server/smb2misc.c 中的 smb2_get_data_area_len 可造成 smb_strndup_from_utf16 超出邊界存取。(CVE-2024-22705)
- 在 6.7.1 版本之前的 Linux 核心中，fs/btrfs/disk-io.c 內的 btrfs_get_root_ref 可能會發生宣告失敗及損毀，這是因為在建立子磁碟區時，插入其 root 項目後過快讀取子磁碟區所致。 (CVE-2024-23850)
- 在 6.7.1 版本之前的 Linux 核心中，drivers/md/dm-ioctl.c 內的 copy_params 可嘗試配置超過 INT_MAX 位元組並損毀，這是因為缺少 param_kernel->data_size 檢查所致。此問題與 ctl_ioctl 有關。(CVE-2024-23851)
- 在 Linux 核心的藍牙裝置驅動程式的 {min,max}_key_size_set() 函式中發現一個爭用情形。這可導致 null 指標解除參照問題，進而可能導致核心錯誤或拒絕服務問題。(CVE-2024-24860)
- 在 Linux 核心中，下列弱點已解決：mlxsw：spectrum_acl_tcam：修復堆疊損毀問題。第一次將 tc 篩選器新增至 net 裝置時，對應的本機連接埠會系結至裝置中的 ACL 群組。該群組包含 ACL 清單。而每個 ACL 會指向儲存篩選器的不同 TCAM 區域。轉送期間，系統會依序評估 ACL，直到找到相符項目為止。將篩選器放置在不同區域的一個原因是，以遞減的優先順序和交替順序新增篩選器時，兩個連續的篩選器因為其金鑰使用方式，而永遠無法放入相同的區域。在 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 進行驗證。
不過，未針對此 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 核心中，下列弱點已修復：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 核心中，下列弱點已解決：ipv6：mcast：修復 ipv6_mc_down/ mld_ifc_work idev->mc_ifc_count 中的資料爭用，無需適當鎖定即可撰寫。最初由 syzbot [1] 發現，請針對 mld_ifc_stop_work() (以及 mld_gq_stop_work() 進行適當衡量) 以 mutex_lock() 和 mutex_unlock() 封裝對 mld_ifc_stop_work() 的呼叫，以修復此問題，因為這些函式只能根據其宣告以 mc_lock 呼叫。 [1] 錯誤：KCSAN：ipv6_mc_down/mld_ifc_work 中的資料爭用：透過 cpu 0 上的工作 3771 寫入 0xffff88813a80c832，共 1 個位元組：mld_ifc_stop_work net/ipv6/mcast.c:1080 [內嵌] ipv6_mc_down+0x10a/0x280 net/ipv6/mcast.c:2725 addrconf_ifdown+0xe32/0xf10 net/ipv6/addrconf.c:3949 addrconf_notify+0x310/0x980 notifier_call_chain kernel/notifier.c:93 [內嵌] raw_notifier_call_chain+0x6b/0x1c0 kernel/notifier.c:461 __dev_notify_flags+0x205/0x3d0 dev_change_flags+0xab/0xd0 net/core/dev.c:8685 do_setlink+0x9f6/0x2430 net/core/rtnetlink.c:2916 rtnl_group_changelink net/core/rtnetlink.c:3458 [內嵌] __rtnl_newlink net/core/rtnetlink.c:3717 [內嵌] rtnl_newlink+0xbb3/0x1670 net/core/rtnetlink.c:3754 rtnetlink_rcv_msg+0x807/0x8c0 net/core/rtnetlink.c:6558 netlink_rcv_skb+0x126/0x220 net/netlink/af_netlink.c:2545 rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:6576 netlink_unicast_kernel net/netlink/af_netlink.c:1342 [內嵌] netlink_unicast+0x589/0x650 net/netlink/af_netlink.c:1368 netlink_sendmsg+0x66e/0x770 net/netlink/af_netlink.c:1910 ... 透過 cpu 1 上的工作 22 寫入 0xffff88813a80c832 (共 1 個位元組)：
mld_ifc_work+0x54c/0x7b0 net/ipv6/mcast.c:2653 process_one_work kernel/workqueue.c:2627 [內嵌] process_scheduled_works+0x5b8/0xa30 kernel/workqueue.c:2700 worker_thread+0x525/0x730 kernel/workqueue.c:2781 ... (CVE-2024-26631)
- 在 Linux 核心中，下列弱點已解決：ip6_tunnel：修復 ip6_tnl_parse_tlv_enc_lim() 中的 NEXTHDR_FRAGMENT 處理 syzbot 指出 [1] NEXTHDR_FRAGMENT 處理已中斷。
只有在我們提取足夠的位元組至 skb->head 時，才能讀取 frag_off。目前我們可能會存取記憶體。[1] BUG: KMSAN: uninit-value in ip6_tnl_parse_tlv_enc_lim+0x94f/0xbb0 ip6_tnl_parse_tlv_enc_lim+0x94f/0xbb0 ipxip6_tnl_xmit net/ipv6/ip6_tunnel.c:1326 [inline] ip6_tnl_start_xmit+0xab2/0x1a70 net/ipv6/ip6_tunnel.c:1432 __netdev_start_xmit include /linux/netdevice.h:4940 [內嵌] netdev_start_xmit include/linux/netdevice.h:4954 [內嵌] xmit_one net/core/dev.c:3548 [內嵌] dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564
__dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349 dev_queue_xmit include/linux/netdevice.h:3134 [內嵌] neigh_connected_output+0x569/0x660 net/core/neighbour.c:1592 neigh_output include/net/neighbour.h:542 [內嵌] ip6_finish_output2+0x23a9/0x2b30 net/ipv6/ip6_output.c:137 ip6_finish_output+0x855/0x12b0 net/ipv6/ip6_output.c:222 NF_HOOK_COND include/linux/netfilter.h:303 [內嵌] ip6_output+0x323/0x610 net/ipv6/ip6_output.c:243 dst_output include/net/dst.h:451 [內嵌] ip6_local_out+0xe9/0x140 net/ipv6/output_core.c:155 ip6_send_skb net/ipv6/ip6_output.c:1952 [內嵌] ip6_push_pending_frames +0x1f9/0x560 net/ipv6/ip6_output.c:1972 rawv6_push_pending_frames+0xbe8/0xdf0 net/ipv6/raw.c:582 rawv6_sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920 inet_sendmsg+0x105/0x190 net/ipv4/ af_inet.c:847 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 建立於：slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 slab_alloc_node mm /slub.c:3478 [內嵌] __kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517
__do_kmalloc_node mm/slab_common.c:1006 [內嵌] __kmalloc_node_track_caller+0x118/0x3c0 mm/slab_common.c:1027 kmalloc_reserve+0x249/0x4a0 net/core/skbuff.c:582 pskb_expand_head+0x226/0x1a00 net/core/skbuff.c: 2098 __pskb_pull_tail+0x13b/0x2310 net/core/skbuff.c:2655 pskb_may_pull_reason include/linux/skbuff.h:2673 [內嵌] pskb_may_pull include/linux/skbuff.h:2681 [內嵌] ip6_tnl_parse_tlv_enc_lim+0x901/0xbb0 net/ipp// ip6_tunnel.c:408 ipxip6_tnl_xmit net/ipv6/ip6_tunnel.c:1326 [內嵌] ip6_tnl_start_xmit+0xab2/0x1a70 net/ipv6/ip6_tunnel.c:1432 __netdev_start_xmit include/linux/netdevice.h:4940 [內嵌] netdev_start_xmit/linux/ netdevice.h:4954 [內嵌] xmit_one net/core/dev.c:3548 [內嵌] dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564
__dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349 dev_queue_xmit include/linux/netdevice.h:3134 [內嵌] neigh_connected_output+0x569/0x660 net/core/neighbour.c:1592 neigh_output include/net/neighbour.h:542 [內嵌] ip6_finish_output2+0x23a9/0x2b30 net/ipv6/ip6_output.c:137 ip6_finish_output+0x855/0x12b0 net/ipv6/ip6_output.c:222 NF_HOOK_COND include/linux/netfilter.h:303 [內嵌] ip6_output+0x323/0x610 net/ipv6/ip6_output.c:243 dst_output include/net/dst.h:451 [內嵌] ip6_local_out+0xe9/0x140 net/ipv6/output_core.c:155 ip6_send_skb net/ipv6/ip6_output.c:1952 [內嵌] ip6_push_pending_frames +0x1f9/0x560 net/ipv6/ip6_output.c:1972 rawv6_push_pending_frames+0xbe8/0xdf0 net/ipv6/raw.c:582 rawv6_sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920 inet_sendmsg+0x105/0x190 net/ipv4/ af_inet.c:847 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_sendms ---truncated--- (CVE-2024-26633)
- 路由器遇到 IPv6 封包過大而無法傳輸至下一個躍點時，會向傳送者傳回 ICMP6 封包過大 (PTB) 訊息。傳送者會快取此更新後的最大傳輸單位 (MTU)，以便在後續路由至相同主機時知道不要超過此值。(CVE-2023-52340)
請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。
解決方案
更新受影響的 kernel 套件。另請參閱
Plugin 詳細資訊
嚴重性: Critical
ID: 193084
檔案名稱: ubuntu_USN-6725-1.nasl
版本: 1.0
類型: local
代理程式: unix
已發布: 2024/4/9
已更新: 2024/4/9
支援的感應器: Agentless Assessment, Frictionless Assessment Agent, Frictionless Assessment AWS, Frictionless Assessment Azure, Nessus Agent, Nessus
風險資訊
VPR
風險因素: High
分數: 7.4
CVSS v2
風險因素: Critical
基本分數: 10
時間分數: 7.4
媒介: CVSS2#AV:N/AC:L/Au:N/C:C/I:C/A:C
CVSS 評分資料來源: CVE-2023-38427
CVSS v3
風險因素: Critical
基本分數: 9.8
時間分數: 8.5
媒介: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
時間媒介: CVSS:3.0/E:U/RL:O/RC:C
弱點資訊
CPE: cpe:/o:canonical:ubuntu_linux:20.04:-:lts, cpe:/o:canonical:ubuntu_linux:22.04:-:lts, p-cpe:/a:canonical:ubuntu_linux:linux-image-5.15.0-102-generic, p-cpe:/a:canonical:ubuntu_linux:linux-image-5.15.0-102-generic-64k, p-cpe:/a:canonical:ubuntu_linux:linux-image-5.15.0-102-generic-lpae, p-cpe:/a:canonical:ubuntu_linux:linux-image-5.15.0-102-lowlatency, p-cpe:/a:canonical:ubuntu_linux:linux-image-5.15.0-102-lowlatency-64k, p-cpe:/a:canonical:ubuntu_linux:linux-image-5.15.0-1040-gkeop, p-cpe:/a:canonical:ubuntu_linux:linux-image-5.15.0-1048-nvidia, p-cpe:/a:canonical:ubuntu_linux:linux-image-5.15.0-1048-nvidia-lowlatency, p-cpe:/a:canonical:ubuntu_linux:linux-image-5.15.0-1050-ibm, p-cpe:/a:canonical:ubuntu_linux:linux-image-5.15.0-1050-raspi, p-cpe:/a:canonical:ubuntu_linux:linux-image-5.15.0-1052-intel-iotg, p-cpe:/a:canonical:ubuntu_linux:linux-image-5.15.0-1054-gke, p-cpe:/a:canonical:ubuntu_linux:linux-image-5.15.0-1054-kvm, p-cpe:/a:canonical:ubuntu_linux:linux-image-5.15.0-1055-gcp, p-cpe:/a:canonical:ubuntu_linux:linux-image-5.15.0-1060-azure-fde
必要的 KB 項目: Host/cpu, Host/Ubuntu, Host/Ubuntu/release, Host/Debian/dpkg-l
可輕鬆利用: No known exploits are available
修補程式發佈日期: 2024/4/9
弱點發布日期: 2023/7/10
參考資訊
CVE: CVE-2023-1194, CVE-2023-32254, CVE-2023-32258, CVE-2023-38427, CVE-2023-38430, CVE-2023-38431, CVE-2023-3867, CVE-2023-46838, CVE-2023-52340, CVE-2023-52429, CVE-2023-52436, CVE-2023-52438, CVE-2023-52439, CVE-2023-52441, CVE-2023-52442, CVE-2023-52443, CVE-2023-52444, CVE-2023-52445, 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-52480, CVE-2023-52609, CVE-2023-52610, CVE-2023-52612, CVE-2024-22705, CVE-2024-23850, CVE-2024-23851, CVE-2024-24860, CVE-2024-26586, CVE-2024-26589, CVE-2024-26591, CVE-2024-26597, CVE-2024-26598, CVE-2024-26631, CVE-2024-26633
USN: 6725-1