|
各大廠牌軟硬體高風險弱點摘要
|
| 廠牌 |
軟硬體型號 |
弱點數量 |
說明 |
CVE ID |
| IBM | Storage Virtualize | 1 | IBM FlashSystem（IBM Storage Virtualize 版本 8.5.0.0 到 8.5.0.13、8.5.1.0、8.5.2.0 到 8.5.2.3、8.5.3.0 到 8.5.3.1、8.5.4.0、8.6.0.0 到 8.6.0.5、8.6.1.0、8.6.2.0 到 8.6.2.1、8.6.3.0、8.7.0.0 到 8.7.0.2、8.7.1.0、8.7.2.0 到 8.7.2.1）可能允許遠端攻擊者通過發送特製的 HTTP 請求來繞過 RPCAdapter 端點身份驗證。 | CVE-2025-0159
|
| IBM | i | 1 | IBM i 7.2、7.3、7.4 和 7.5 可能允許具有編譯或恢復程序能力的用戶，由於未經資格驗證的庫調用，獲得提升的權限。惡意行為者可能會使用戶控制的代碼以管理員權限運行。 | CVE-2024-55898
|
| IBM | Storage Virtualize | 1 | IBM FlashSystem（IBM Storage Virtualize 版本 8.5.0.0 到 8.5.0.13、8.5.1.0、8.5.2.0 到 8.5.2.3、8.5.3.0 到 8.5.3.1、8.5.4.0、8.6.0.0 到 8.6.0.5、8.6.1.0、8.6.2.0 到 8.6.2.1、8.6.3.0、8.7.0.0 到 8.7.0.2、8.7.1.0、8.7.2.0 到 8.7.2.1）可能允許具有系統訪問權限的遠端攻擊者，由於 RPCAdapter 服務中的不當限制，執行任意 Java 程式碼。 | CVE-2025-0160
|
| IBM | MQ | 1 | IBM MQ 9.3 LTS、9.3 CD、9.4 LTS 和 9.4 CD 控制台可能允許已認證的用戶，由於對轉義字符處理不當，執行程式碼。 | CVE-2025-0975
|
| Linux | Linux | 1 | 在 Linux 核心中，已解決以下漏洞：ubi：修復 ctrl_cdev_ioctl 和 ubi_cdev_ioctl 之間的競態條件。Hulk Robot 報告了有關 use-after-free 的 KASAN 報告： ================================================================== BUG: KASAN: use-after-free 在 __list_del_entry_valid+0x13d/0x160 在地址 ffff888035e37d98 上讀取大小為 8 的數據，任務 ubiattach/1385 發生此錯誤 [...] 調用堆疊： klist_dec_and_del+0xa7/0x4a0 klist_put+0xc7/0x1a0 device_del+0x4d4/0xed0 cdev_device_del+0x1a/0x80 ubi_attach_mtd_dev+0x2951/0x34b0 [ubi] ctrl_cdev_ioctl+0x286/0x2f0 [ubi] 分配給任務 1414： device_add+0x60a/0x18b0 cdev_device_add+0x103/0x170 ubi_create_volume+0x1118/0x1a10 [ubi] ubi_cdev_ioctl+0xb7f/0x1ba0 [ubi] 由任務 1385 釋放： cdev_device_del+0x1a/0x80 ubi_remove_volume+0x438/0x6c0 [ubi] ubi_cdev_ioctl+0xbf4/0x1ba0 [ubi] [...] ================================================================== ctrl_cdev_ioctl 持有的鎖是 ubi_devices_mutex，但 ubi_cdev_ioctl 持有的鎖是 ubi->device_mutex。因此，這兩個鎖可以是並發的。ctrl_cdev_ioctl 包含兩個操作：ubi_attach 和 ubi_detach。ubi_detach 是無錯誤的，因為它使用引用計數來防止並發。然而，ubi_attach 中的 uif_init 和 uif_close 可能會與 ubi_cdev_ioctl 競爭。uif_init 會與 ubi_cdev_ioctl 競爭，堆疊如以下所示： cpu1 cpu2 cpu3 _______________________|________________________|______________________ ctrl_cdev_ioctl ubi_attach_mtd_dev uif_init ubi_cdev_ioctl ubi_create_volume cdev_device_add ubi_add_volume // sysfs exist kill_volumes ubi_cdev_ioctl ubi_remove_volume cdev_device_del // 首次釋放 ubi_free_volume cdev_del // 雙重釋放 cdev_device_del 而 uif_close 會與 ubi_cdev_ioctl 競爭，堆疊如以下所示： cpu1 cpu2 cpu3 _______________________|________________________|______________________ ctrl_cdev_ioctl ubi_attach_mtd_dev uif_init ubi_cdev_ioctl ubi_create_volume cdev_device_add ubi_debugfs_init_dev // 錯誤，跳轉到 out_uif； uif_close kill_volumes ubi_cdev_ioctl ubi_remove_volume cdev_device_del // 首次釋放 ubi_free_volume // 雙重釋放 此問題的原因是提交 714fb87e8bc0 在設備通過 sysfs 可訪問之前將其標記為「可用」。因此，我們將回滾此修改。我們將通過刪除 vol_attribute_show 和 dev_attribute_show 中的 ubi_get_device 來解決 ubi 設備創建和 udev 之間的競態條件。這樣可以避免訪問未初始化的 ubi_devices[ubi_num]。ubi_get_device 用於防止設備在 sysfs 執行期間被刪除。然而，現在 kernfs 確保在所有引用計數釋放之前，設備不會被刪除。關鍵過程顯示在以下堆疊中： device_del device_remove_attrs device_remove_groups sysfs_remove_groups sysfs_remove_group remove_files kernfs_remove_by_name kernfs_remove_by_name_ns __kernfs_remove kernfs_drain | CVE-2021-47634
|
| Linux | Linux | 1 | 在 Linux 核心中，已解決以下漏洞：KVM：x86/mmu：在 TDP MMU 中取消映射 gfn 範圍時清除 _all_ 根。當清除/取消映射 gfn 範圍時，應該清除有效和無效的根，因為 KVM 必須確保在從取消映射操作返回後不會持有對已釋放頁面的引用。最值得注意的是，TDP MMU 在 mmu_notifier 回調中不會清除無效根。如果 mmu_notifier 完成執行，而無效根清除器讓步，則會導致 use-after-free 和其他問題，因為 KVM 沒有遵守要求，即在 mmu_notifier 返回後，頁面必須 _沒有_ 任何引用。這個錯誤最容易通過修改 KVM 使 set_nx_huge_pages() 和 kvm_mmu_notifier_release() 發生碰撞來重現，但該錯誤也存在於 kvm_mmu_notifier_invalidate_range_start() 和 memslot 更新之間。無效根的清除可以確保頁面無法被來賓訪問，並且 KVM 本身不會讀寫頁面數據，但 KVM 在清除 SPTE 時會觸發例如 kvm_set_pfn_dirty()，因此在 mmu_notifier 返回後完成無效根的清除是致命的。 警告： CPU: 24 PID: 1496 在 arch/x86/kvm/../../../virt/kvm/kvm_main.c:173 [kvm] RIP: 0010:kvm_is_zone_device_pfn+0x96/0xa0 [kvm] 調用堆疊： kvm_set_pfn_dirty+0xa8/0xe0 [kvm] __handle_changed_spte+0x2ab/0x5e0 [kvm] __handle_changed_spte+0x2ab/0x5e0 [kvm] __handle_changed_spte+0x2ab/0x5e0 [kvm] zap_gfn_range+0x1f3/0x310 [kvm] kvm_tdp_mmu_zap_invalidated_roots+0x50/0x90 [kvm] kvm_mmu_zap_all_fast+0x177/0x1a0 [kvm] set_nx_huge_pages+0xb4/0x190 [kvm] param_attr_store+0x70/0x100 module_attr_store+0x19/0x30 kernfs_fop_write_iter+0x119/0x1b0 new_sync_write+0x11c/0x1b0 vfs_write+0x1cc/0x270 ksys_write+0x5f/0xe0 do_syscall_64+0x38/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae | CVE-2021-47639
|
| Linux | Linux | 1 | 在 Linux 核心中，已解決以下漏洞：還原 ""還原 'block, bfq: 尊重已設置的隊列合併'""。在與提交 2d52c58b9c9b (""block, bfq: 尊重已設置的隊列合併"") 相關的操作中觸發了一個崩潰 [1]。該提交隨後被提交 ebc69e897e17 (""還原 'block, bfq: 尊重已設置的隊列合併'"") 所還原。然而，還原的提交並不是引入錯誤的提交。事實上，它實際上觸發了一個由其他提交引入的 UAF（Use-After-Free），該問題現在已通過提交 d29bd41428cf (""block, bfq: 在組變更時重置 last_bfqq_created"") 進行修復。因此，沒有必要將提交 2d52c58b9c9b (""block, bfq: 尊重已設置的隊列合併"") 保留在外。此提交將其恢復。 [1] https://bugzilla.kernel.org/show_bug.cgi?id=214503 | CVE-2021-47646
|
| Linux | Linux | 1 | 在 Linux 核心中，已解決以下漏洞：media: davinci: vpif: 修復驅動程式解除綁定時的 use-after-free 問題。該驅動程式在探測過程中分配並註冊了兩個平台設備結構，但這些設備在驅動程式解除綁定時從未被註銷。這導致在驅動程式解除綁定時發生 use-after-free，因為設備結構是使用 devres 分配的，並且當 remove() 返回時，驅動程式核心會釋放它們。通過將缺失的註銷調用添加到 remove() 回調中並在註冊錯誤時使探測失敗來修復此問題。請注意，平台設備結構必須使用正確的釋放回調來釋放，以避免泄漏與設備名稱相關的資源。 | CVE-2021-47653
|
| Linux | Linux | 1 | 在 Linux 核心中，已解決以下漏洞：jffs2: 修復 jffs2_clear_xattr_subsystem 中的 use-after-free 問題。當我們掛載 jffs2 映像時，假設映像的前幾個區塊是正常的並包含至少一個與 xattr 相關的 inode，但接下來的區塊是不正常的。結果，jffs2_scan_eraseblock() 返回錯誤。然後，在 jffs2_build_filesystem() 中調用了 jffs2_clear_xattr_subsystem()，並在 jffs2_do_fill_super() 中再次調用。最終，我們可以觀察到以下報告： ================================================================== BUG: KASAN: use-after-free 在 jffs2_clear_xattr_subsystem+0x95/0x6ac 在地址 ffff8881243384e0 上讀取大小為 8 的數據，任務 mount/719 發生此錯誤 [...] 調用堆疊： dump_stack+0x115/0x16b jffs2_clear_xattr_subsystem+0x95/0x6ac jffs2_do_fill_super+0x84f/0xc30 jffs2_fill_super+0x2ea/0x4c0 mtd_get_sb+0x254/0x400 mtd_get_sb_by_nr+0x4f/0xd0 get_tree_mtd+0x498/0x840 jffs2_get_tree+0x25/0x30 vfs_get_tree+0x8d/0x2e0 path_mount+0x50f/0x1e50 do_mount+0x107/0x130 __se_sys_mount+0x1c5/0x2f0 __x64_sys_mount+0xc7/0x160 do_syscall_64+0x45/0x70 entry_SYSCALL_64_after_hwframe+0x44/0xa9 分配給任務 719： kasan_save_stack+0x23/0x60 __kasan_kmalloc.constprop.0+0x10b/0x120 kasan_slab_alloc+0x12/0x20 kmem_cache_alloc+0x1c0/0x870 jffs2_alloc_xattr_ref+0x2f/0xa0 jffs2_scan_medium.cold+0x3713/0x4794 jffs2_do_mount_fs.cold+0xa7/0x2253 jffs2_do_fill_super+0x383/0xc30 jffs2_fill_super+0x2ea/0x4c0 [...] 由任務 719 釋放： kmem_cache_free+0xcc/0x7b0 jffs2_free_xattr_ref+0x78/0x98 jffs2_clear_xattr_subsystem+0xa1/0x6ac jffs2_do_mount_fs.cold+0x5e6/0x2253 jffs2_do_fill_super+0x383/0xc30 jffs2_fill_super+0x2ea/0x4c0 [...] 錯誤地址屬於大小為 48 的 jffs2_xattr_ref 緩存中的對象，該對象的地址為 ffff8881243384b8。錯誤地址位於 48 字節區域 [ffff8881243384b8, ffff8881243384e8) 內 40 字節處。 [...] ================================================================== 錯誤觸發的堆疊顯示如下： ----------------------------------------------------------- jffs2_fill_super jffs2_do_fill_super jffs2_do_mount_fs jffs2_build_filesystem jffs2_scan_medium jffs2_scan_eraseblock <--- 錯誤 jffs2_clear_xattr_subsystem <--- 釋放 jffs2_clear_xattr_subsystem <--- 再次釋放 ----------------------------------------------------------- 在 jffs2_do_mount_fs() 中返回錯誤。如果錯誤是由 jffs2_sum_init() 返回的，則不需要執行 jffs2_clear_xattr_subsystem()。如果錯誤是由 jffs2_build_filesystem() 返回的，則也不需要再次執行 jffs2_clear_xattr_subsystem()。因此，將 jffs2_clear_xattr_subsystem() 從 'out_inohash' 移動到 'out_root' 來修復此 UAF 問題。 | CVE-2021-47656
|
| Linux | Linux | 1 | 在 Linux 核心中，已解決以下漏洞：ep93xx: clock: 修復 ep93xx_clk_register_gate() 中的 UAF 問題。 在檔案 `arch/arm/mach-ep93xx/clock.c` 的第 154 行出現了警告：使用已釋放的記憶體 [clang-analyzer-unix.Malloc]。 詳細信息如下： - 第 151 行：注意：如果條件成立，會執行以下操作： `if (IS_ERR(clk))` - 第 152 行：注意：記憶體已被釋放： `kfree(psc);` - 第 154 行：注意：在記憶體被釋放後使用它： `return &psc->hw;` 這段程式碼存在使用已釋放的記憶體的問題，這是導致 UAF（Use After Free）漏洞的原因。 | CVE-2022-49047
|
| Linux | Linux | 1 | 在 Linux 核心中，已解決以下漏洞：scsi: target: tcmu: 修復可能的頁面 UAF 問題。 `tcmu_try_get_data_page()` 在 `cmdr_lock` 下查找頁面，但未正確處理引用計數，只是返回頁面指針。當 `tcmu_try_get_data_page()` 返回時，返回的頁面可能已被 `tcmu_blocks_release()` 釋放。我們需要在 `cmdr_lock` 下使用 `get_page()` 來避免與 `tcmu_blocks_release()` 的並發操作。 | CVE-2022-49053
|
| Linux | Linux | 1 | 在 Linux 核心中，以下漏洞已解決： nfc：nci：新增 flush_workqueue 以防止 uaf 我們的偵測器在分離 NCI 裝置時發現了並發使用後釋放錯誤。此錯誤的主要原因是所使用的延遲機制（計時器和工作佇列）之間的意外調度。比賽可以在下面示範：線程 1 線程 2 | nci_dev_up() | nci_open_device() | __nci_request（nci_reset_req）| nci_send_cmd |隊列工作（cmd_work）nci_unregister_device（）| nci_close_device() | ... del_timer_sync（cmd_timer）[1] | .... |工作者 nci_free_device() | nci_cmd_work() 釋放 kfree(ndev)[3] | mod_timer(cmd_timer)[2] 簡而言之，清理程序認為 cmd_timer 已被 [1] 分離，但 mod_timer 可以重新附加定時器 [2]，即使它已被釋放 [3]，從而導致 UAF。此UAF很容易觸發，POC的碰撞追蹤如下[66.703713] ===================================== [ 66.703974] BUG: KASAN: use-after-free in enqueue_timer+0x448/0x490 [ 66.703974] Write of size 8 at addr ffff888009fb7058 by task kworker/u4:1/33 [ 66.703974] [ 66.703974] CPU: 1 PID: 33 Comm: kworker/u4:1 Not tainted 5.18.0-rc2 #5 [ 66.703974] Workqueue: nfc2_nci_cmd_wq nci_cmd_work [ 66.703974] Call Trace: [ 66.703974] [ 66.703974] dump_stack_lvl+0x57/0x7d [ 66.703974] print_report.cold+0x5e/0x5db [ 66.703974] ? enqueue_timer+0x448/0x490 [ 66.703974] kasan_report+0xbe/0x1c0 [ 66.703974] ? enqueue_timer+0x448/0x490 [ 66.703974] enqueue_timer+0x448/0x490 [ 66.703974] __mod_timer+0x5e6/0xb80 [ 66.703974] ? mark_held_locks+0x9e/0xe0 [ 66.703974] ? try_to_del_timer_sync+0xf0/0xf0 [ 66.703974] ? lockdep_hardirqs_on_prepare+0x17b/0x410 [ 66.703974] ? queue_work_on+0x61/0x80 [ 66.703974] ? lockdep_hardirqs_on+0xbf/0x130 [ 66.703974] process_one_work+0x8bb/0x1510 [ 66.703974] ? lockdep_hardirqs_on_prepare+0x410/0x410 [ 66.703974] ? pwq_dec_nr_in_flight+0x230/0x230 [ 66.703974] ? rwlock_bug.part.0+0x90/0x90 [ 66.703974] ? _raw_spin_lock_irq+0x41/0x50 [ 66.703974] worker_thread+0x575/0x1190 [ 66.703974] ? process_one_work+0x1510/0x1510 [ 66.703974] kthread+0x2a0/0x340 [ 66.703974] ? kthread_complete_and_exit+0x20/0x20 [ 66.703974] ret_from_fork+0x22/0x30 [ 66.703974] [ 66.703974] [ 66.703974] Allocated by task 267: [ 66.703974] kasan_save_stack+0x1e/0x40 [ 66.703974] __kasan_kmalloc+0x81/0xa0 [ 66.703974] nci_allocate_device+0xd3/0x390 [ 66.703974] nfcmrvl_nci_register_dev+0x183/0x2c0 [ 66.703974] nfcmrvl_nci_uart_open+0xf2/0x1dd [ 66.703974] nci_uart_tty_ioctl+0x2c3/0x4a0 [ 66.703974] tty_ioctl+0x764/0x1310 [ 66.703974] __x64_sys_ioctl+0x122/0x190 [ 66.703974] do_syscall_64+0x3b/0x90 [ 66.703974] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 66.703974] [ 66.703974] Freed by task 406: [ 66.703974] kasan_save_stack+0x1e/0x40 [ 66.703974] kasan_set_track+0x21/0x30 [ 66.703974] kasan_set_free_info+0x20/0x30 [ 66.703974] __kasan_slab_free+0x108/0x170 [ 66.703974] kfree+0xb0/0x330 [ 66.703974] nfcmrvl_nci_unregister_dev+0x90/0xd0 [ 66.703974] nci_uart_tty_close+0xdf/0x180 [ 66.703974] tty_ldisc_kill+0x73/0x110 [ 66.703974] tty_ldisc_hangup+0x281/0x5b0 [ 66.703974] __tty_hangup.part.0+0x431/0x890 [ 66.703974] tty_release+0x3a8/0xc80 [ 66.703974] __fput+0x1f0/0x8c0 [ 66.703974] task_work_run+0xc9/0x170 [ 66.703974] exit_to_user_mode_prepare+0x194/0x1a0 [ 66.703974] syscall_exit_to_user_mode+0x19/0x50 [ 66.703974] do_syscall_64+0x48/0x90 [ 66.703974] entry_SYSCALL_64_after_hwframe+0x44/0x ---truncated--- | CVE-2022-49059
|
| Linux | Linux | 1 | 在Linux核心中，已解決以下漏洞：ICE：ARFS：在釋放@RX_CPU_RMAP時無使用後使用CI測試觸發了以下SPLAT：[718.203054]錯誤ffff8881bd127e00 by Task sh/20834 [718.212852] 負載： OE 5.17.0-RC8_NEXTQUEUE-DEVEUE-DEVEUE-02643-G2643-G23F3121ACA.7193.7193.7193.719.719.719.719.193.193.719.19619.196969. C620.86B.02.01.0012.07070720200218 07/07/2020 [718.223418]呼叫追蹤：[718.2271139] escription.constprop.9+0x21/0x178123x1702123x178123x釋放_irq_cpu_rmap+0x53/0x80 [ 718.241885] ？ free_irq_cpu_rmap+0x53/0x80 [ 718.245539] kasan_report.cold.18+0x7f/0x11b [ 718.249197] ？ free_irq_cpu_rmap+0x53/0x80 [718.252852] free_irq_cpu_rmap+0x53/0x80 [718.256471] ice_free_cpu_rx_rmap.part.11+0x37/00x507/00x5070000x11+ /0x70 [冰] [718.263810] ice_rebuild_arfs+0x3b/0x70 [冰] [718.267419] ice_rebuild+0x39c/0xb60 [冰] [718.270974]？ asm_sysvec_apic_timer_interrupt+0x12/0x20 [ 718.274472] ？ ice_init_phy_user_cfg+0x360/0x360 [冰] [ 718.278033] ？延遲_tsc + 0x4a/0xb0 [ 718.281513]？搶佔計數子+0x14/0xc0 [ 718.284984]？ delay_tsc+0x8f/0xb0 [718.288463] ICE_DO_RESET+0x92/0xf0 [ICE] [718.292014] ICE_PCI_ERR_ERR_ERR_RESUME+0X91/0X91/CI_ERR_ERR_ERR_RESUME+0X91/0X91/1F30370303039039039039039030030030030003003000300233053000003000033000330003300033000330000300030030003300003000300300033000030003003330000000 [718.495688]最後可能相關的工作創建：[718.568966]該蟲子地址屬於FFFFFFFFFFFFFFFF88881BD127E00，該物件屬於該物件96位元組區域的內部[FFFF8881BD127E00，該物件屬於該物件96位元組區域的內部[FFFF8881BD127E00，FFFFFFFF21175757575757562757562757575753333333333個，。 8905 FB FB FB FB FB FC FC FC FC [718.604796] FFFF88881BD127D80：00 00 00 00 00 00 00 00 00 00 00 00 00 0000000 00 00 FB FB FB FC FC FC FC [718.610811] ^ [718.613819] FFFF8881BD127E80：00 00 00 00 00 00 00 00 00 00 00000 000 0 00 00 00 b fb fb fb fb fb fb fc fc fc fc fc fc這是由於free_irq_cpu_rmap（）始終被稱為 *（devm_）free_irq（），因此它試圖與已經釋放的IRQ DESC一起工作。例如，在裝置重置時，驅動程式會在分配新的 rmap（上面的 splat）之前釋放 rmap。使 rmap 建立和釋放函數與 {request,free}_irq() 呼叫對稱，即在 ifup/ifdown 上執行這些操作，而不是在裝置探測/刪除/復原時執行。這些操作可以獨立於實際設備 aRFS 配置執行。此外，確保 ice_vsi_free_irq() 僅在 aRFS 被禁用時清除 IRQ 親和性通知程序 - 否則，CPU rmap 會設定並清除其自身的通知程序，並且不得手動。 | CVE-2022-49063
|
| Linux | Linux | 1 | 在 Linux 核心中，以下漏洞已解決：RDMA/hfi1：修復 mm 結構的使用後釋放錯誤在某些條件下，例如 MPI_Abort，hfi1 清理程式碼可能代表任務 mm 上持有的最後一個參考。然後，hfi1_mmu_rb_unregister() 刪除最後一個引用，並且在 hfi1_release_user_pages() 中的最終使用之前釋放 mm。新任務可能會分配仍在使用的 mm 結構，從而導致問題。其中一個表現是 mmap_sem 計數器損壞，導致 down_write() 掛起。另一個原因是另一個任務正在使用的 mm 結構損壞。 | CVE-2022-49076
|
| Linux | Linux | 1 | 在 Linux 核心中，以下漏洞已解決： lz4：修正 LZ4_decompress_safe_partial 越界讀取問題 在進行部分解碼時，如果我們已經填充了輸出緩衝區或無法繼續讀取以下匹配的偏移量，則為 EOF。在某些極端情況下，當壓縮資料嚴重損壞時，就會發生 UAF。根據 KASAN [1] 報告，LZ4_decompress_safe_partial 可能導致解碼過程中出現讀取越界問題。 lz4 上游已經修復了這個問題 [2]，這個問題之前已經在這裡討論過 [3]。目前的解壓縮程序是從 lz4 v1.8.3 移植的，將 lib/lz4 升級到 v1.9.+ 肯定是一項艱鉅的工作，所以我們最好先修復它。 [1] https://lore.kernel.org/all/000000000000830d1205cf7f0477@google.com/ [2] https://github.com/lz4/lz4/commit/c5d6f8a8be3927c0bec91b5866776986670 -4CA4-4951-B6FB-A2EFDE3AC03B@fb.com/ | CVE-2022-49078
|
| Linux | Linux | 1 | 在Linux核心中，已解決以下漏洞：SCSI：MPT3SAS：在_scsih_expander_node_remove（）中免費使用後修復使用MPT3SAS_TRANSPORT_PORT_REMOVE（）info（）呼叫下列功能（例如，在執行驅動器================ ========================[ 3479.378496] BUG: KASAN: use-after-free in _scsih_expander_node_remove+0x710/0x750 [mpt3sas] [ 3479.386936] Read of size 1 at addr ffff8881c037691c by task rmmod/1531 [ 3479.393524] [ 3479.395035] CPU: 18 PID: 1531 Comm: rmmod Not tainted 5.17.0-rc8+ #1436 [ 3479.401712] Hardware name: Supermicro Super Server/H12SSL-NT, BIOS 2.1 06/02/2021 [ 3479.409263] Call Trace: [ 3479.411743] [ 3479.413875] dump_stack_lvl+0x45/0x59 [ 3479.417582] print_address_description.constprop.0+0x1f/0x120 [ 3479.423389] ? _scsih_expander_node_remove+0x710/0x750 [mpt3sas] [ 3479.429469] kasan_report.cold+0x83/0xdf [ 3479.433438] ? _scsih_expander_node_remove+0x710/0x750 [mpt3sas] [ 3479.439514] _scsih_expander_node_remove+0x710/0x750 [mpt3sas] [ 3479.445411] ? _raw_spin_unlock_irqrestore+0x2d/0x40 [ 3479.452032] scsih_remove+0x525/0xc90 [mpt3sas] [ 3479.458212] ? mpt3sas_expander_remove+0x1d0/0x1d0 [mpt3sas] [ 3479.465529] ? down_write+0xde/0x150 [ 3479.470746] ? up_write+0x14d/0x460 [ 3479.475840] ? kernfs_find_ns+0x137/0x310 [ 3479.481438] pci_device_remove+0x65/0x110 [ 3479.487013] __device_release_driver+0x316/0x680 [ 3479.493180] driver_detach+0x1ec/0x2d0 [ 3479.498499] bus_remove_driver+0xe7/0x2d0 [ 3479.504081] pci_unregister_driver+0x26/0x250 [ 3479.510033] _mpt3sas_exit+0x2b/0x6cf [mpt3sas] [ 3479.516144] __x64_sys_delete_module+0x2fd/0x510 [ 3479.522315] ? free_module+0xaa0/0xaa0 [ 3479.527593] ? __cond_resched+0x1c/0x90 [ 3479.532951] ? lockdep_hardirqs_on_prepare+0x273/0x3e0 [ 3479.539607] ? syscall_enter_from_user_mode+0x21/0x70 [ 3479.546161] ? trace_hardirqs_on+0x1c/0x110 [ 3479.551828] do_syscall_64+0x35/0x80 [ 3479.556884] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 3479.563402] RIP: 0033:0x7f1fc482483b ... [ 3479.943087] ===================================================================== 透過在執行 mpt3sas_transport_port_remove() 之前引入局部變數 port==== 透過在執行 mpt3sas_transport_port_remove() 之前引入局部變數 port_id 來解決此問題 ID 值，從而解決此問題 ID。然後在對 ioc_info() 的呼叫中使用這個局部變量，而不是取消引用已釋放的連接埠結構。 | CVE-2022-49082
|
| Linux | Linux | 1 | 在 Linux 核心中，以下漏洞已解決： drbd：修正 get_initial_state 中的五個 use after free 錯誤 在 get_initial_state 中，如果 cb->args[5]==1，它會呼叫 notify_initial_state_done(skb,..)。如果 genlmsg_put() 在 notify_initial_state_done() 中失敗，則 skb 將由 nlmsg_free(skb) 釋放。然後 get_initial_state 會 goto out 並且釋放的 skb 會被傳回值 skb->len 使用，這是一個 uaf 錯誤。更糟的是，同樣的問題甚至進一步加劇：skb 也可以在下面的 notify_*_state_change -> notify_*_state 呼叫中被釋放。因此又發生了 4 個額外的 uaf 錯誤。我的補丁讓問題呼叫函數：notify_initial_state_done 和 notify_*_state_change 在發生錯誤時傳回錯誤代碼。這樣錯誤代碼就可以傳播，並且可以避免 uaf 錯誤。 v2 報告編譯警告。此 v3 修復了這個警告並且在我的本地環境中成功構建，並且沒有任何額外的警告。 v2：https://lore.kernel.org/patchwork/patch/1435218/ | CVE-2022-49085
|
| Linux | Linux | 1 | 在 Linux 核心中，以下漏洞已解決： rxrpc：修正 rxrpc_exit_net() 中的競爭 目前程式碼可能導致下列競爭： CPU0 CPU1 rxrpc_exit_net() rxrpc_peer_keepalive_worker() if (rxnet->) rxrpc_peer_keepalive_worker() if (rxnet->) rxnet->live = false; del_timer_sync（＆rxnet->peer_keepalive_timer）； timer_reduce(&rxnet->peer_keepalive_timer，jiffies + 延遲);取消_work_sync（＆rxnet->peer_keepalive_work）；當 peer_keepalive_timer 仍然處於啟用狀態時，rxrpc_exit_net() 退出，從而導致釋放後使用。 syzbot report was: ODEBUG: free active (active state 0) object type: timer_list hint: rxrpc_peer_keepalive_timeout+0x0/0xb0 WARNING: CPU: 0 PIDprint: 3660 at lib/debug:objects jects.c:505 Modules linked in: CPU: 0 PID: 3660 Comm: kworker/u4:6 Not tainted 5.17.0-syzkaller-13993-g88e6c0207623 #000 name nameler-1393-g88e6c0207623 #0000 :2003/Google RIP: 0010:debug_print_object+0x16e/0x250 lib/debugobjects.c:505 Code: ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 af 0f ？ : 00010082 RAX: 0000000000000000 RBX: 0000000000000003 RCX: 000000000000000 0000000000000001 R08: 0000000000000000000000001 R08: 000000000000000 14e0 R14: ffffffffff816628c0 R15: dffffc0000000000 FS: 0000000000000000(0000) GS:ffff8880b9c00000(0000) CSGS ES: 0000 CR0: 0000000080050033 CR2: 00007fe1f2908924 CR3: 0000000043720000 CR4: 00000000003506f000 00 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __dem* check_no_obj_freed+0x301/0x420 lib/debugobjects.c:1023 kfree+0xd6/0x310 mm/slab.c:3809 ops_free_list.part.0+0x119/0x370 netspace/1770 cleanup_net+0x591/0xb00 net/core/net_namespace.c:598 process_one_work+0x996/0x1610 kernel/workqueue.c:2289 worker_thread+0x665/0x1080 kernel/workqueue. 376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:298 | CVE-2022-49087
|
| Linux | Linux | 1 | 在 Linux 核心中，以下漏洞已解決： skbuff：修正 page_pool 碎片回收的合併問題，修正使用 page_pool 與頁面碎片時出現的釋放後使用問題。我們在 hns3 驅動程式的正常 RX 過程中遇到了這個問題：（1）最初我們在 RX 佇列中有三個檔案描述子。第一個透過page_pool分配PAGE1，另外兩個各分配PAGE2的一半。頁面引用如下所示：RX_BD1 _______ PAGE1 RX_BD2 _______ PAGE2 RX_BD3 _________/ （2）在第一個檔案描述子上處理 RX。分配SKB1，最終透過tcp_queue_rcv()加入接收佇列。 （3）處理第二個檔案描述子上的 RX。分配SKB2並將其傳遞給netif_receive_skb()：netif_receive_skb(SKB2) ip_rcv(SKB2) SKB3 = skb_clone(SKB2) SKB2 和 SKB3 透過 skb_shinfo()->dataref 共享對 PAGE2 的參考。對 PAGE2 的另一個引用仍由 RX_BD3 持有： SKB2 ---+- PAGE2 SKB3 __/ / RX_BD3 _________/ （3b）現在，在處理 TCP 時，將 SKB3 與 SKB1 合併： tcp_v4_rcv(SKB3) t3_Ds> ) skb_release_data(SKB3) // 丟棄一個資料參考 SKB1 _____ PAGE1 \____ SKB2 _____ PAGE2 / RX_BD3 _________/ 在 skb_try_coalesce() 中，__skb_frag_ref(rag) 將頁面引用 PAGE 2，而它應該會引用它應該會被引用。如果不合併，則在釋放 SKB2 和 SKB3 時，對 PAGE2 的單一引用將被刪除。現在，當釋放 SKB1 和 SKB2 時，對 PAGE2 的兩個引用將被刪除，導致下溢。 (3c) 刪除 SKB2：af_packet_rcv(SKB2) consumer_skb(SKB2) skb_release_data(SKB2) // 刪除第二個資料參考 page_pool_return_skb_page(PAGE2) // 刪除一個 pp_frag_count RXB1 _____2 1 \____ 7/____7 RXB1 19 SKB1 並釋放它。由於 SKB3 與 SKB1 合併，我們也釋放 SKB3 頁面：tcp_eat_recv_skb(SKB1) skb_release_data(SKB1) page_pool_return_skb_page(PAGE1) page_pool_return_skb_page(PAGE2) // ragcount RX_fRX2) // 刪除它。在我們的案例中，這會導致 IOMMU 故障，但如果 IOMMU 被停用，它會悄悄地破壞記憶體。改變檢查 pp_recycle SKB 是否可以合併的邏輯。我們仍然拒絕“from”和“to”SKB 之間不同的 pp_recycle，但為了避免上述情況，當“from”和“to”都是 pp_recycle 並且“from”是克隆時，我們也拒絕合併。新的邏輯允許將克隆的 pp_recycle SKB 合併為頁面引用計數的 SKB，因為在這種情況下，釋放（4）將刪除正確的引用，即 skb_try_coalesce() 所採用的引用。 | CVE-2022-49093
|
| Linux | Linux | 1 | 在 Linux 核心中，以下漏洞已解決：藍牙：修復 hci_send_acl 中的釋放後使用問題這修復了由接收 HCI_EV_DISCONN_PHY_LINK_COMPLETE 引起的以下追蹤，該追蹤確實調用了 hci_conn_del，而沒有先檢查 conn-==type 是否正確清理是否可以調用了 hci_conn_del，而沒有先檢查 conn-====type 是否正確清理層======================================================BUG: KASAN: use-after-free in hci_send_acl+0xaba/0xc50 Read of size 8 at addr ffff88800e404818 by task bluetoothd/142 CPU: 0 PID: 142 Comm: bluetoothd Not tainted 5.17.0-rc5-00006-gda4022eeac1a #7 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x45/0x59 print_address_description.constprop.0+0x1f/0x150 kasan_report.cold+0x7f/0x11b hci_send_acl+0xaba/0xc50 l2cap_do_send+0x23f/0x3d0 l2cap_chan_send+0xc06/0x2cc0 l2cap_sock_sendmsg+0x201/0x2b0 sock_sendmsg+0xdc/0x110 sock_write_iter+0x20f/0x370 do_iter_readv_writev+0x343/0x690 do_iter_write+0x132/0x640 vfs_writev+0x198/0x570 do_writev+0x202/0x280 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RSP: 002b:00007ffce8a099b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000014 Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 14 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 89 54 24 1c 48 89 74 24 10 RDX: 0000000000000001 RSI: 00007ffce8a099e0 RDI: 0000000000000015 RAX: ffffffffffffffda RBX: 00007ffce8a099e0 RCX: 00007f788fc3cf77 R10: 00007ffce8af7080 R11: 0000000000000246 R12: 000055e4ccf75580 RBP: 0000000000000015 R08: 0000000000000002 R09: 0000000000000001 R13: 000055e4ccf754a0 R14: 000055e4ccf75cd0 R15: 000055e4ccf4a6b0 Allocated by task 45: kasan_save_stack+0x1e/0x40 __kasan_kmalloc+0x81/0xa0 hci_chan_create+0x9a/0x2f0 l2cap_conn_add.part.0+0x1a/0xdc0 l2cap_connect_cfm+0x236/0x1000 le_conn_complete_evt+0x15a7/0x1db0 hci_le_conn_complete_evt+0x226/0x2c0 hci_le_meta_evt+0x247/0x450 hci_event_packet+0x61b/0xe90 hci_rx_work+0x4d5/0xc50 process_one_work+0x8fb/0x15a0 worker_thread+0x576/0x1240 kthread+0x29d/0x340 ret_from_fork+0x1f/0x30 Freed by task 45: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 kasan_set_free_info+0????x20/0x30 __kasan_slab_free+0xfb/0x130 kfree+0xac/0x350 hci_conn_cleanup+0x101/0x6a0 hci_conn_del+0x27e/0x6c0 hci_disconn_phylink_complete_evt+0xe0/0x120 hci_event_packet+0x812/0xe90 hci_rx_work+0x4d5/0xc50 process_one_work+0x8fb/0x15a0 worker_thread+0x576/0x1240 kthread+0x29d/0x340 ret_from_fork+0x1f/0x30 The buggy address belongs to the object at ffff88800c0f0500 The buggy address is located 24 bytes inside of which belongs to the cache kmalloc-128 of size 128 The buggy address belongs to the page: 128-byte region [ffff88800c0f0500, ffff88800c0f0580) flags: 0x100000000000200(slab|node=0|zone=1) page:00000000fe45cd86 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xc0f0 raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000 raw: 0100000000000200 ffffea00003a2c80 dead000000000004 ffff8880078418c0 page dumped because: kasan: bad access detected ffff88800c0f0400: 00 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc Memory state around the buggy address: >ffff88800c0f0500: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff88800c0f0480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88800c0f0580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ---truncated--- | CVE-2022-49111
|
| Linux | Linux | 1 | 在 Linux 核心中，以下漏洞已解決：ref_tracker：實作釋放後使用偵測，每當呼叫 ref_tracker_dir_init() 時，將 struct ref_tracker_dir 標記為已死亡。從 ref_tracker_alloc() 和 ref_tracker_free() 測試死亡狀態這應該可以偵測到在網路裝置拆除過程中發生得太晚的錯誤 dev_put()/dev_hold()。 | CVE-2022-49127
|
| Linux | Linux | 1 | 在Linux核心中，以下漏洞已解決：mt76：mt7921：修正啟動失敗時崩潰的問題。如果網路卡啟動失敗，有可能reset_work已經被調度了。確保工作項目被取消，這樣如果在執行工作項目之前呼叫清理，我們就不會發生釋放後使用當機。當 mt7921k 無線電無法運作時，這修復了我的 x86_64 apu2 上的當機。無線電仍然故障，但作業系統沒有崩潰。 | CVE-2022-49129
|
| Linux | Linux | 1 | CVE-2022-49136 是 Linux 核心中的一個 use-after-free（使用已釋放記憶體）弱點，存在於藍牙子系統的 HCI（Host Controller Interface）同步命令佇列處理中。 當系統調用 hci_unregister_dev 以註銷藍牙設備時，若此時仍有命令被佇列，可能在命令超時後訪問已被釋放的設備記憶體，導致系統不穩定或安全弱點。 | CVE-2022-49136
|
| Linux | Linux | 1 | CVE-2022-49168 是 Linux 核心中的一個 use-after-free（使用已釋放記憶體）弱點，存在於 Btrfs 檔案系統的修復過程中。 | CVE-2022-49168
|
| Linux | Linux | 1 | CVE-2022-49176 是 Linux 核心中的一個 use-after-free（使用已釋放記憶體）弱點，發生在 BFQ（Budget Fair Queueing）排程器的 bfq_dispatch_request 函式中。 此弱點可能允許本地使用者在系統上提升權限。 | CVE-2022-49176
|
| Linux | Linux | 1 | CVE-2022-49179 是 Linux 核心中的一個 use-after-free（使用已釋放記憶體）弱點，發生在 BFQ（Budget Fair Queueing）排程器的 bfq_bfqq_move() 函式中。 此弱點可能允許本地使用者在系統上提升權限。 | CVE-2022-49179
|
| Linux | Linux | 1 | CVE-2022-49223 是 Linux 核心中的一個 use-after-free（使用已釋放記憶體）弱點，發生在 Compute Express Link（CXL）子系統的 cxl_decoder_release() 函式中。 此弱點可能導致系統不穩定或潛在的安全風險。 | CVE-2022-49223
|
| Linux | Linux | 1 | CVE-2022-49236 是 Linux 核心中的一個 use-after-free（使用已釋放記憶體）弱點，發生在 BPF（Berkeley Packet Filter）子系統中。 此弱點源於 btf_try_get_module 與 load_module 之間的競態條件，可能導致系統不穩定或潛在的安全風險。 | CVE-2022-49236
|
| Linux | Linux | 1 | CVE-2022-49238 是 Linux 核心中的一個 use-after-free（使用已釋放記憶體）弱點，發生在 ath11k 無線網路驅動程式中。 該弱點源於在 QCA6390 和 WCN6855 晶片組中，當工作站（station）從接取點（AP）斷線時，未正確釋放對等體（peer）資訊。 此問題可能導致系統不穩定或潛在的安全風險。 | CVE-2022-49238
|
| Linux | Linux | 1 | CVE-2022-49258 是 Linux 核心中一個 use-after-free（使用已釋放記憶體）弱點，發生在 net/netfilter/nf_tables_api.c 的 nf_tables 子系統中。 此弱點可能允許本地使用者在系統上提升權限。 該弱點已在 Linux 核心的後續版本中修復。 若您的系統正在使用受影響的 Linux 核心版本，建議您盡快更新至包含修補程式的版本，以確保系統的安全性和穩定性。 | CVE-2022-49258
|
| Linux | Linux | 1 | CVE-2022-49270 是 Linux 核心中的一個 use-after-free（使用已釋放記憶體）弱點，存在於設備映射（Device Mapper，簡稱 DM）子系統的 dm_cleanup_zoned_dev() 函式中。在執行 dm_cleanup_zoned_dev() 時，若該函式在 blk_cleanup_disk() 開始清理之前被調用，可能導致資源清理順序錯誤。這種情況下，RCU（Read-Copy-Update）回呼可能先於 dm_cleanup_zoned_dev() 執行，導致該函式訪問已被釋放的記憶體，從而引發錯誤。 | CVE-2022-49270
|
| Linux | Linux | 1 | CVE-2022-49287 是 Linux 核心中的一個弱點，影響 TPM（受信平台模組）子系統。該弱點源於對 struct tpm_chip 的引用計數管理不當，可能導致使用已釋放記憶體的情況。 | CVE-2022-49287
|
| Linux | Linux | 1 | CVE-2022-49288 是 Linux 核心中的一個弱點，影響 ALSA（Advanced Linux Sound Architecture）PCM（Pulse Code Modulation）子系統。該弱點源於在處理並行的 PCM 緩衝區預分配操作時，缺乏適當的同步機制，可能導致競態條件，進而引發使用已釋放記憶體（use-after-free）或其他異常行為。在沒有適當保護的情況下，通過 proc 檔案系統對 PCM 緩衝區預分配進行並行修改，可能導致競態條件，進而引發使用已釋放記憶體或其他異常問題。 | CVE-2022-49288
|
| Linux | Linux | 1 | 在 Linux 核心中，以下弱點已解決： ALSA：pcm：修復並發 hw_params 和 hw_free 呼叫之間的競爭 目前，我們沒有針對 PCM hw_params 和 hw_free ioctl 的並發呼叫進行適當的檢查或保護，這可能會導致 UAF。由於現有的 PCM 流鎖不能用於保護整個 ioctl 操作，因此我們需要一個新的互斥體來保護這些活潑的呼叫。此補丁引入了一個新的互斥體，runtime->buffer_mutex，並將其應用於 hw_params 和 hw_free ioctl 程式碼路徑。同時，為了程式碼簡單性，這兩個函數都被稍微修改了（mmap_count 檢查被移到狀態檢查區塊中）。 | CVE-2022-49291
|
| Linux | Linux | 1 | 在 Linux 核心中，以下弱點已解決： mt76：透過刪除非 RCU wcid 指標修復釋放後使用 透過在 mt76_txq_schedule 和 sta_info_[alloc, free] 之間使用 rcu_lock 保護 mtxq->wcid，修復 SANKA 中捕獲的有關 76_lockxq. [18853.876689] ============================================================== [18853.876751] BUG：KASAN：mt76_txq_schedule+0x204/0xaf8 18767676767676767676767]。 ffffffaf989a2138 透過任務 mt76-tx phy0/883 [18853.876786] [18853.876810] CPU: 5 PID: 883 Comm: mt76-tx phy0 未污染 5.10.10075-10075-603 bbcf41a530f52043508fec2e31a4215 [18853.876840]呼叫追蹤：[18853.876861] dump_backtrace+0x0/0x3ec [18853.876878] showTrace+0x0/0x3ec [18853.876878] show8768789070000 x11 c/0x1ac [18853.876918] print_address_description+0x74/0x514 [18853.876934] kasan_report+0x134/0x174 [18853.876948] 0x134/0x174 [18853.876948] 13867070060700030x050x ] mt 76_txq_schedule+0x204/0xaf8 [mt76 074e03e4640e97fe7405ee1fab547b81c4fa45d2] [18853.877002] mt76_tx_schedu fe74 05ee1fab547b81c4fa45d2] [18853.877030] mt7921_tx_worker+0xa0/0x1cc [mt7921_common f0875ebdbac9d7b4754e101054857050750 月_ worker_fn+0x190/0x22c [mt76 074e03e4640e97fe7405ee1fab547b81c4fa45d2] [18853.877071] kthread+0x2f8/0x3b8 [18838 [fromx70 853 .877098] [18853.877112] 由任務 941 分配：[18853.877131] kasan_save_stack+0x38/0x68 [18853.877147] __kasan_kmal7/0x68 [18853.877147] __kasan_kmal7/0x6818853.877147] __kasan_kmal.70 77177] __kmalloc+0x264/0x3c4 [18853.877294] sta_info_alloc+0x460/0xf88 [mac80211] [18853.877410] ieee80211_prep. 523] ieee80211_mgd_auth+0x6c4/0xa4c [mac80211] [18853.877635] ieee80211_auth+0x20/0x2c [mac80211] [18853.87373+21073]x 53.877826] cfg80211_mlme_auth+0x26c/0x390 [cfg80211] [18853.877919] nl80211_authenticate+0x6d4/0x904 [cfg80211_authenticate+0x6d4/0x904 [cfg802117853x3x75x3x75x72020212/2013x72020213x. .877954] netlink_rcv_skb+0x160/0x2a8 [18853.877969] genl_rcv+0x3c/0x54 [18853.877985] netlink_unicast_kernel+0x104/00x 68 [18853.878015] netlink_sendmsg+0x3cc/0x5f0 [18853.878030] sock_sendmsg+0xb4/0xd8 [18853.878043] ____sys_81853xd8 [18853.878043] ____sys_81853x 8/0x150 [18853.878071] __sys_sendmsg+0xc4/0x1f4 [18853.878087] __arm64_compat_sys_sendmsg+0x88/0x9c [18853.87810117690101] x. 5] do_el0_svc_compat+0x8c/0xdc [18853.878131] el0_svc_compat+0x10/0x1c [18853.878146] el0_sync_compat_handler+0xa8/0x878146] el0_sync_compat_handler+0xa8/0x8781853870201800018 0 [18853.878171] [18853.878183] 由任務 10927 釋出：[18853.878200] kasan_save_stack+0x38/0x68 [18853.878215] 電池+0x38/0x68 [18853.878215] kasan_~8583832032032032x。 set_free_info+0??x24/0x48[18853.878244]__kasan_slab_free+0x11c/0x154[18853.878259]kasan_slab_free+0x14/0x24[18853.878853.8780905 3.878287] kfree+0x104/0x390 [18853.878402] sta_info_free+0x198/0x210 [mac80211] [18853.878515] __sta_info_destroy_partic+x __sta_info_flush+0x300/0x37c [mac80211] [18853.878740] ieee80211_set_disassoc+0x2cc/0xa7c [mac80211] [18853.878851] 3080x8 ] [18853.878962] ieee80211_deauth+0x20/0x2c [mac80211] [18853.879057] rdev_deauth+0x7c/0x438 [cfg80211] rdev_deauth+0x7c/0x438 [cfg80211] [18853. 414 [cfg80211] [18853.879243] cfg80211_mlme_down+0xe4/0x118 [cfg80211] [18853.879335] cfg80211_disconnect+021898385 [ g80211_leave+0x17c/0x240 [cfg80211] [18853.879519] cfg80211_leave+0x3c/0x58 [cfg80211] [18853.879611] wi008385000x105050gf; 6] 28] dpm_run_callback+0x58/0x408 [18853.879642] __device_suspend+0x4cc/0x864 [18853.879658] async_suspend+0x34/0x4-f-f-f-f--x4-f-f-f0x34/0x4-f-f-f-- | CVE-2022-49328
|
| Linux | Linux | 1 | 在 Linux 核心中，以下弱點已解決： ext4：修正 ext4_rename_dir_prepare 中的 use-after-free 我們遇到的問題如下： EXT4-fs (loop0)：掛載的檔案系統沒有日誌。選擇：，錯誤=繼續ext4_get_first_dir_block：bh->b_data=0xffff88810bee6000 len=34478 ext4_get_first_dir_block：*parent_de=0xffff88810beee6data bh-dffbf. 1] parent_de=0xffffff88810beee6ae ============================================================ BUG：KASAN：在 ext4_rename_dir_prepare+0x152/0x220 中透過任務讀取的5 通訊：代表未受污染 5.10.0+ #241 呼叫追蹤：dump_stack+0xbe/0xf9 print_address_description.constprop.0+0x1e/0x220 kasan_report.cold+0x37/0x7f ext4_rename_dir_x40150001/00150000 0 ext4_rename2+0x11c/0x170 vfs_rename+0xa84/0x1440 do_renameat2+0x683/0x8f0 __x64_sys_renameat+0x53/0x60 do_SYScall_64+033/J503/0x60 4__SYScall_64+033/109053/1009_> 003 3：0x7f45a6fc41c9 RSP：002b：00007ffc5a470218 EFLAGS：00000246 ORIG_RAX：0000000000000108 RAX：ffffffffff0 fc41c9 RDX：0000000000000005 RSI：0000000020000180 RDI：0000000000000005 RBP：00007ffc5a470240 Rff8：000070050 ：00000000200001c0 R11：0000000000000246 R12：0000000000400bb0 R13：00007ffc5a470320 R14：000000000007ffc5a470320 R14：00000000002page :00000000440015ce refcount:0 mapcount:0 映射：000000000000000 index:0x1 pfn:0x10beee flags: 0x2000000000000000(ff 04325608 0000000000000000 原始：000000000000001 000000000000000 00000000ffffffffff 00000000000000000000000ffff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88810beee600：ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88810beee780: ff ff ff ff ff ff ff ff ff ff ====================================================================================================================== _rename_dir_prepare: [2] Parent_de->inode=3537895424 ext4_rename_dir_prepare: [3] dir=0xffff888124170140 ext4_rename_dir_prepareffff888124170140 ext4_rename_dir_prepare: [4] ino=27075-d項的 'rec_len' 為 34478，然後將得到非法的父項。現在，我們在讀取“ext4_get_first_dir_block”中的目錄區塊後不檢查目錄條目。若要解決此問題，請檢查「ext4_get_first_dir_block」中的目錄條目。 [ 如果目錄缺少“.”，則觸發 ext4_error() 而不是僅發出警告或“..”條目。如果檔案系統損壞，也要確保我們回傳錯誤代碼。 -TYT] | CVE-2022-49349
|
| Linux | Linux | 1 | 在 Linux 核心中，以下弱點已解決： drm/panfrost：作業應引用 MMU 而不是 file_priv 一段時間以來，允許 MMU 上下文比其相??應的 panfrost_priv 壽命更長，但是作業結構仍然引用 panfrost_priv 來獲取 MMU 上下文。如果 panfrost_priv 已被釋放，則這是釋放後使用，我已經能夠觸發該釋放，從而導致 splat。若要解決此問題，請在作業結構中刪除對 panfrost_priv 的引用，並新增對實際需要的 MMU 結構的直接引用。 | CVE-2022-49359
|
| Linux | Linux | 1 | 在 Linux 核心中，以下弱點已解決： NFSD：修復 nfsd_file_put() 中潛在的釋放後使用 nfsd_file_put_noref() 可以釋放 @nf，因此不要在從 nfsd_file_put_noref() 返回後立即取消引用 @nf。 | CVE-2022-49362
|
| Linux | Linux | 1 | 在 Linux 核心中，以下弱點已解決： blk-mq: don't touch ->tagset in blk_mq_get_sq_hctx blk_mq_run_hw_queues() 可以在沒有排隊請求時運行，並且在隊列清理後，此時 taget 被釋放，因為 tage tagem 生命週期在 bqueue) 被釋放後，此時 taget 生命週期被釋放，因為 tages 值因此，不要觸碰 ->tagset 透過請求佇列中內建的對應來決定目前預設 hctx，這樣就可以避免 tagset 上的 use-after-free 。同時，這種方式應該比從標記集中檢索映射要快。 | CVE-2022-49377
|
| Linux | Linux | 1 | 在 Linux 核心中，以下弱點已解決： driver: base: 當 driver_attach 失敗時修復 UAF 當 driver_attach(drv); 時失敗，driver_private 將被釋放。但它被添加到總線上，導致了UAF。要修復它，我們需要在失敗時將其從總線中刪除。 | CVE-2022-49385
|
| Linux | Linux | 1 | Linux 核心中，已解決下列弱點： ubi: ubi_create_volume: 修正磁碟區建立失敗時的 use-after-free ubi_create_volume() 的錯誤處理路徑中存在 'eba_tbl' 的 use-after-free 問題： ubi_eba_replace_tablepvol, edestro_boo _table(eba_tbl) // Free 'eba_tbl' out_unlock: put_device(&vol->dev) vol_release kfree(tbl->entries) // UAF 透過刪除多餘的 'eba_tbl' 釋放來修復它。在[連結]中取得複製器。 | CVE-2022-49388
|
| Linux | Linux | 1 | 在 Linux 核心中，以下弱點已解決： macsec：修正 real_dev 的 UAF 錯誤 建立新的 macsec 設備，但不取得對 real_dev 的參考。這不能確保real_dev在macsec之後被釋放。這將觸發 real_dev 的 UAF 錯誤，如下所示： ================================================================ BUG: KASAN: use-after-free in macsec_get_iflink+0x5f/0x70 getdrivers/mac/mac. drivers/net/macsec.c: 3662 dev_get_iflink+0x73/0xe0 net/core/dev.c:637 default_operstate net/core/link_watch.c:42 [內聯] rfc2863_poli link_watch.c:161 被任務 222 分配09: ... alloc_netdev_mqs+0x98/0x1100 net/core/dev.c:10549 rtnl_create_link+0x9d7/0xc00 net/core/rtnetlinkc:330+0x02330xc00 net/ 8 釋放： ... kfree+0xd6/0x4d0 mm/slub.c:4552 kvfree+0x42/0x50 mm/util.c:615 device_release+0x9f/0x240 drivers/base/core.c:2229 object_anbject85:b. c:704 [內聯] kref_put include/linux/kref.h:65 [內聯] kobject_put+0x1 c8/0x540 lib/kobject.c:721 netdev_run_todo+0x72e/0x10b0 net/c/minc7c 27:400145: 允許取消 3fnet 」允許提交 3125:000545:000 3fnet 」允許 3fnet 」允許提交 3125:005425:000 . ）和提交 e5f80fcf869a（“ipv6：給 blackhole_netdev 提供 IPv6 開發”）之後，我們可以添加 dev_hold_ macsec_dev_init() 中的 track() 和 macsec_free_netdev() 中的 dev_put_track() 來修復該問題。 | CVE-2022-49390
|
| Linux | Linux | 1 | 在 Linux 核心中，以下弱點已解決： bfq：避免合併具有不同父佇列的佇列 在我們決定兩個佇列值得合併（並設定 bic->stable_merge_bfqq）和呼叫 bfq_setup_merge() 之間，bfqq 的父佇列可能會發生變更。這可能會發生，例如因為該進程為不同的 cgroup 提交了 IO，因此 bfqq 被重新設定了父級。甚至我們要合併的 bfqq 的父 cgroup 已經離線並且將被銷毀，在這種情況下，合併可能會導致釋放後使用問題，例如： BUG: KASAN: use-after-free in __bfq_deactivate_entity+0x9cb/0xa50 Read of size 8 at addr. 4 CPU : 0 PID: 10544 Comm: runc:[2:INIT] 受污染: GE 5.15.2-0.g5fb85fd-default #1 openSUSE Tumbleweed (未發布) f1f3b891c72369aebeSUSE Tumbleweed (未發布) f1f3b891c72369aebeO2e 346486469a ( 1996) )，BIOS rel-1.14.0-0-g155821a-rebuilt.opensuse.org 04/01/2014 呼叫追蹤： dump_stack_lvl+0x46/0x5a print_address_description.constack_lvl+0x46/0x5a print_address_description.constack_lvl+0x46/0x5a print_address_description.constack_lvl+01f/x0x1f/0x1.010p. __bfq_deactivate_entity+0x9cb/0xa50 kasan_report.cold+0x7f/0x11b ？ __bfq_deactivate_entity+0x9cb/0xa50 __bfq_deactivate_entity+0x9cb/0xa50 ？ update_curr+0x32f/0x5d0 bfq_deactivate_entity+0xa0/0x1d0 bfq_del_bfqq_busy+0x28a/0x420 ？ resched_curr+0x116/0x1d0 ？ bfq_requeue_bfqq+0x70/0x70 ？ check_preempt_wakeup+0x52b/0xbc0 __bfq_bfqq_expire+0x1a2/0x270 bfq_bfqq_expire+0xd16/0x2160 ？ try_to_wake_up+0x4ee/0x1260 ？ bfq_end_wr_async_queues+0xe0/0xe0 ？ _raw_write_unlock_bh+0x60/0x60 ？ _raw_spin_lock_irq+0x81/0xe0 bfq_idle_slice_timer+0x109/0x280？ bfq_dispatch_request+0x4870/0x4870 __hrtimer_run_queues+0x37d/0x700 ？ enqueue_hrtimer+0x1b0/0x1b0 ？ kvm_clock_get_cycles+0xd/0x10 ？ ktime_get_update_offsets_now+0x6f/0x280 hrtimer_interrupt+0x2c8/0x740 透過檢查我們在 bfq_setup_merge() 中合併的兩個 bfqq 的父級是否相同來修復該問題。 | CVE-2022-49412
|
| Linux | Linux | 1 | 在 Linux 核心中，以下弱點已解決： bfq：在合併 bio 之前更新 cgroup 資訊 當進程遷移到不同的 cgroup 時（或在寫回剛開始提交與不同 cgroup 關聯的 BIOS 的情況下），bfq_merge_bio() 可以使用 bic 中的陳舊 cgroup 資訊進行操作。因此，bio 可以合併到來自不同 cgroup 的請求，或者可能導致不同 cgroup 的 bfqq 合併或已死亡 cgroup 的 bfqq 合併，並可能導致釋放後使用問題。透過更新 bfq_merge_bio() 中的 cgroup 資訊來修復該問題。 | CVE-2022-49413
|
| Linux | Linux | 1 | 在 Linux 核心中，以下弱點已解決： wifi: mac80211: 修復 chanctx 程式碼中的釋放後使用 在 ieee80211_vif_use_reserved_context() 中，當我們有舊上下文且新上下文的 Replace_state 設定為 IEEE80211_CHANTX_REPLD15釋放舊上下文()。因此，我們不能再檢查old_ctx，所以我們應該在此時將其設為NULL。但是，由於 new_ctx 替換狀態顯然不是 IEEE80211_CHUNCTX_REPLACES_OTHER，因此我們不會在此函數中執行任何其他操作，只需返回即可避免存取已釋放的 old_ctx。 | CVE-2022-49416
|
| Linux | Linux | 1 | Linux 核心驅動 vesafb 存在釋放後使用弱點。該弱點已解決。 | CVE-2022-49419
|
| Linux | Linux | 1 | Linux 核心呼叫函式 mmgrab()/mmdrop() 存在釋放後使用弱點。該弱點已解決。 | CVE-2022-49426
|
| Linux | Linux | 1 | Linux 核心檔案系統 erofs 存在緩衝區溢出弱點。該弱點已解決。 | CVE-2022-49464
|
| Linux | Linux | 1 | Linux 核心區塊 blk-throttle 存在釋放後使用弱點。該弱點已解決。 | CVE-2022-49465
|
| Linux | Linux | 1 | Linux 核心其中 Bluetooth 存在緩衝區溢出弱點。該弱點已解決。 | CVE-2022-49470
|
| Linux | Linux | 1 | Linux 核心其中 Bluetooth 存在釋放後使用弱點。該弱點已解決。 | CVE-2022-49474
|
| Linux | Linux | 1 | Linux 核心其中 mt76 存在釋放後使用弱點。該弱點已解決。 | CVE-2022-49479
|
| Linux | Linux | 1 | Linux 核心其中 ASoC:rt5645 存在排序驗證弱點。該弱點已解決。 | CVE-2022-49493
|
| Linux | Linux | 1 | Linux 核心驅動 usbnet 存在排序驗證弱點。該弱點已解決。 | CVE-2022-49501
|
| Linux | Linux | 1 | Linux 核心驅動 NFC 存在排序驗證弱點。該弱點已解決。 | CVE-2022-49505
|
| Linux | Linux | 1 | Linux 核心驅動 PCI:cx23885 存在排序驗證弱點。該弱點已解決。 | CVE-2022-49524
|
| Linux | Linux | 1 | Linux kernel有安全弱點，以下弱點已解決，此弱點源自於FLOGI和PLOGI失敗後未正確處理節點引用計數，可能導致空指標取消引用。 | CVE-2022-49535
|
| Linux | Linux | 1 | Linux kernel有安全弱點，以下弱點已解決，弱點源自於nf_tables在verdict為NF_STOLEN時可能存取已釋放的skb，導致釋放後重複使用。 | CVE-2022-49622
|
| Linux | Linux | 1 | Linux kernel有安全弱點，以下弱點已解決，此弱點源自於禁用sriov時可能讀取已釋放的vf->pci_dev，導致釋放後重複使用。 | CVE-2022-49626
|
| Linux | Linux | 1 | Linux kernel有安全弱點，以下弱點已解決，此弱點源自於遷移時css_sets預先載入的來源和目標節點問題。 | CVE-2022-49647
|
| Linux | Linux | 1 | Linux kernel有安全弱點，以下弱點已解決，弱點源自於cleanup_srcu_struct函式中的GP檢查不嚴。 | CVE-2022-49651
|
| Linux | Linux | 1 | Linux kernel有安全弱點，以下弱點已解決，弱點源自於bonding在802.3ad從屬解綁後使用已釋放記憶體。 | CVE-2022-49667
|
| Linux | Linux | 1 | Linux kernel有安全弱點，以下弱點已解決，此弱點源自於mptcp中未接受套接字的競爭條件。 | CVE-2022-49669
|
| Linux | Linux | 1 | Linux kernel有安全弱點，以下弱點已解決，此弱點源自於sysfs trigger在移除時有釋放後重複使用問題。 | CVE-2022-49685
|
| Linux | Linux | 1 | Linux kernel有資源管理錯誤弱點，以下弱點已解決，此弱點源自於igb_clean_tx_ring在XDP模式下存在釋放後重複使用問題。 | CVE-2022-49695
|
| Linux | Linux | 1 | Linux kernel有資源管理錯誤弱點，以下弱點已解決，此弱點源自於tipc_named_reinit中存在使用後讀取問題。 | CVE-2022-49696
|
| Linux | Linux | 1 | Linux kernel有資源管理錯誤弱點，以下弱點已解決，此弱點源自於slab分配器在釋放CPU slab時未更新TID，可能導致物件遺失或錯誤釋放。 | CVE-2022-49700
|
| Linux | Linux | 1 | 在Linux核心中，已解決以下弱點：bus: fsl-mc-bus: 修正fsl_mc_bus_remove()中的KASAN使用後釋放弱點，在fsl_mc_bus_remove()中，mc->root_mc_bus_dev->mc_io被傳遞給fsl_destroy_mc_io()。然而，mc->root_mc_bus_dev已經在fsl_mc_device_remove()中被釋放。接著對mc->root_mc_bus_dev->mc_io的引用觸發了KASAN的使用後釋放弱點。為了避免這個問題，應該將mc->root_mc_bus_dev->mc_io的引用保存在本地變數中，再傳遞給fsl_destroy_mc_io()。此更新檔需要重新處理才能應用於v5.15之前的核心版本。 | CVE-2022-49711
|
| Linux | Linux | 1 | 在Linux核心中，已解決以下弱點：scsi: lpfc: 解決中止ELS LOGO後的NULL 指標解引用問題，當ELS LOGO被中止後，可能會發生使用後釋放崩潰。具體來說，一個nodelist結構被釋放後，在錯誤調用狀態機並帶有NLP_EVT_DEVICE_RM參數時，ndlp->vport->cfg_log_verbose在lpfc_nlp_get()中被解引用。修改lpfc_cmpl_els_logo()來防止重複調用釋放nodelist結構。 | CVE-2022-49730
|
| Linux | Linux | 1 | 在Linux核心中，已解決以下弱點：IORING_OP_READ未正確消耗提供的緩衝區列表，當讀取I/O返回小於0（除了-EAGAIN和-EIOCBQUEUED返回值）時，這可能導致在通過io_rw_done完成操作時發生使用後釋放。 | CVE-2023-52926
|
| NVIDIA | IGX Orin | 1 | 在Linux核心中，已解決以下弱點：NVIDIA Jetson Linux和IGX OS映像中的UEFI韌體RCM啟動模式弱點，未經授權的攻擊者如果能夠物理訪問設備，則可以加載不受信任的程式碼。成功的利用可能導致程式碼執行、權限提升、數據篡改、服務阻斷（DoS）和資訊洩漏。影響範圍可能會擴展到其他元件。 | CVE-2024-0148
|
| Linux | Linux | 1 | 在Linux核心中，已解決以下弱點：drm/xe/tracing: 修正潛在的TP_printk使用後釋放弱點，提交afd2627f727b（“tracing: 檢查"%s"的解引用是否透過字段而不是TP_printk格式”）暴露了xe_bo_move追蹤事件中的潛在UAF。透過避免在TP_printk時解引用xe_mem_type_to_name[]數組來修正這些問題。由於程式碼重構，可能需要對6.10版本之前的核心進行明確的反向移植。 | CVE-2024-49570
|
| Linux | Linux | 1 | 在Linux核心中，已解決以下弱點：scsi: ufs: bsg: 在移除後將bsg_queue設為NULL，目前這不會引發任何問題，但我認為在移除後需要將bsg_queue設為NULL，以防止潛在的使用後釋放（UAF）問題。 | CVE-2024-54458
|
| Linux | Linux | 1 | 在Linux核心中，已解決以下弱點：pps: 修正使用後釋放問題，在運行ntpd和gpsd的板子上，當重啟時，從gpsd的sys_exit()中可以看到一致的使用後釋放。在這個情況下，pps_device_destruct()在調用cdev_del()之後立即釋放了pps_device，但正如cdev_del()上方的註解所示，對先前打開的cdev的fops仍然可以調用，即使cdev_del()返回後。這個錯誤一直存在，但現在在重啟時開始每次發生。為了解決這個問題，我們採取了從pps_idr中註冊字符設備並移除嵌入的cdev的建議。 | CVE-2024-57979
|
| Linux | Linux | 1 | 在Linux核心中，已解決以下弱點：i3c: dw: 修正dw_i3c_master驅動中的使用後釋放問題，在dw_i3c_common_probe中，&master->hj_work與dw_i3c_hj_work綁定。dw_i3c_master_irq_handler可以調用dw_i3c_master_irq_handle_ibis函數啟動該工作。如果我們刪除模組，將調用dw_i3c_common_remove來清理，這會通過i3c_master_unregister釋放master->base，而上述工作仍然會使用master->base。為了修正這個問題，應該在進行dw_i3c_common_remove清理之前確保取消工作。 | CVE-2024-57984
|
| Cisco | Cisco NX-OS Software | 1 | Cisco Nexus 3000和9000系列交換機健康監控診斷弱點，在獨立NX-OS模式下，Cisco Nexus 3000系列和Cisco Nexus 9000系列交換機的健康監控診斷中存在弱點。未經認證的鄰近攻擊者可能會發送精心構造的以太網幀來利用此弱點，導致設備意外重啟，從而引發服務阻斷（DoS）條件。 | CVE-2025-20111
|
| Linux | Linux | 1 | 在Linux核心中，已解決以下弱點：RDMA/mlx5: 修正隱式ODP使用後釋放弱點，通過使用__xa_cmpxchg()來確保只銷毀一次特定的mr，防止隱式ODP在釋放後再次銷毀導致的使用後釋放問題。 | CVE-2025-21714
|
| Linux | Linux | 1 | 在Linux核心中，已解決以下弱點：net: davicom: 修正dm9000_drv_remove中的使用後釋放弱點，dm是網路設備的私有數據，不能在調用free_netdev()後使用。使用dm而未釋放它會導致UAF錯誤。通過將free_netdev()移動到函數的結尾來修正此問題。 | CVE-2025-21715
|
| Linux | Linux | 1 | 在 Linux Kernel 中，以下漏洞已修復：nilfs2: 避免在緩衝區被引用時強制清除 folio。這次修補針對 nilfs2 檔案系統在偵測到檔案系統損壞並切換為唯讀模式時，可能發生的 緩衝區狀態不一致問題 以及 Use-After-Free（UAF）漏洞。當 nilfs2 偵測到檔案系統損壞並轉為 唯讀模式，在某些情況下會出現以下兩種錯誤：(1) mark_buffer_dirty() 設定緩衝區為 Dirty 時發現狀態不一致：當系統執行 mark_buffer_dirty() 設定緩衝區（Buffer）為髒（Dirty）時，會發現該緩衝區處於 非最新狀態（not uptodate），導致內核警告：WARNING: CPU: 0 PID: 6049 at fs/buffer.c:1177 mark_buffer_dirty+0x2e5/0x520 fs/buffer.c:1177，涉及函式包括 nilfs_palloc_commit_alloc_entry()、nilfs_ifile_create_inode()、nilfs_new_inode()、nilfs_mkdir()。(2) nilfs_btree_propagate() 傳遞 Dirty 狀態時發生狀態不一致：當 nilfs_btree_propagate() 向 B-Tree 父節點傳遞 Dirty 狀態 時，發現原始緩衝區（Buffer）並未標記為 Dirty，導致內核警告：WARNING: CPU: 0 PID: 5245 at fs/nilfs2/btree.c:2089 nilfs_btree_propagate+0xc79/0xdf0 fs/nilfs2/btree.c:2089，涉及函式包括 nilfs_bmap_propagate()、nilfs_collect_file_data()、nilfs_segctor_apply_buffers()、nilfs_segctor_scan_file()、nilfs_segctor_construct()。這些問題來自於 頁面/folio 寫入請求的回調函數，在檔案系統變成唯讀模式時，會強制清除 頁面狀態，導致正在使用的 Buffer 狀態被意外清除。修正方法是：在清除 page/folio 狀態前，先檢查該緩衝區是否仍被引用（referenced），如果緩衝區仍被使用，則 跳過清除，避免發生狀態不一致。本次修復影響使用 nilfs2 檔案系統的 Linux 內核版本，可能影響包括 緩衝區狀態異常、Use-After-Free（UAF）漏洞、檔案系統錯誤 以及 內核崩潰（Kernel Panic）。這次修復解決了緩衝區狀態管理的問題，提升了 nilfs2 在唯讀模式下的穩定性與安全性。 | CVE-2025-21722
|
| Linux | Linux | 1 | 在 Linux Kernel 中，以下漏洞已修復：padata: 避免 reorder_work 的 Use-After-Free（UAF）。雖然先前的修補程式已經解決了 _do_serial 中 ps 和 ps 的 UAF 問題，但仍然 無法防止 reorder_work 可能發生的 UAF 漏洞。此問題可能發生在以下情境中：1. crypto_request 發送請求。2. padata_do_serial() 開始處理請求。3. padata_reorder() 進入 while (1) 迴圈處理所有剩餘的請求：- if (!padata) break; 檢查是否仍有可用的 padata。4. padata_do_serial() 允許新的請求加入：- list_add() 看到新的請求，並透過 queue_work(reorder_work) 進入 reorder_work 佇列。5. padata_reorder() 呼叫 queue_work_on(squeue->work) 處理請求。6. kworker 進入執行狀態：- padata_serial_worker() 處理新請求，當請求執行完畢後，沒有其他未處理請求時，crypto_del_alg() 釋放 pd 。7. kworker 再次執行 invoke_padata_reorder()，導致 pd 的 Use-After-Free（UAF）發生。為了避免 reorder_work 的 Use-After-Free（UAF），這次修補採取了以下措施：1. 在 reorder_work 進入 serial_wq 佇列前，增加 pd 的引用計數（ref count），確保 pd 不會被過早釋放。2. 直到 serial_wq 執行完畢後，才釋放 pd 的引用計數，確保 pd 在 reorder_work 結束前仍然有效。這項修復解決了 padata 機制中的競態條件，確保 reorder_work 在執行期間不會引用到 已經被釋放的記憶體，提升了 Linux 內核在並行處理中的穩定性與安全性。 | CVE-2025-21726
|
| Linux | Linux | 1 | 在 Linux Kernel 中，以下漏洞已修復：padata: 修復 padata_reorder 中的 Use-After-Free（UAF）。在執行 LTP 測試（pcrypt_aead01） 時發現了一個 Use-After-Free（UAF） 問題，錯誤日誌如下：BUG: KASAN: slab-use-after-free in padata_find_next+0x29/0x1a0 Read of size 4 at addr ffff88bbfe003524 by task kworker/u113:2/3039206。如果在 padata_reorder 函數中 在 padata_find_next 之前加入 mdelay(10)，則可以輕易透過 LTP 測試 pcrypt_aead01 來復現此問題。問題流程如下：(1) 加密請求開始執行 (pcrypt_aead_encrypt)；(2) padata_do_parallel() 增加 pd->refcnt 計數，確保 pd 仍被引用；(3) padata_do_serial() 進入 padata_reorder()，開始循環處理 pd，padata_find_next(pd, true); 嘗試尋找下一個 padata 任務，使用 pd，queue_work_on() 將請求推送到工作隊列；(4) 另一個執行緒 (padata_serial_worker) 處理請求，演算法 (alg) 被刪除，導致 padata_put_pd_cnt() 減少 pd->refcnt，padata_free_shell() 釋放 pd，但 padata_reorder() 仍在 while 迴圈中，當 padata_find_next(pd, true) 再次執行時，pd 已經被釋放，導致 Use-After-Free（UAF）。為了解決這個 Use-After-Free（UAF） 問題，開發者採取了以下修正措施：(1) 在 padata_free_shell() 中加入 synchronize_rcu()，確保 do_serial 調用完成後才釋放 pd，避免 pd 被提前釋放；(2) do_serial 應在 關閉 Bottom Halves（BHs） 的狀態下運行，並且始終受 RCU 保護。參考資料：[1] 修復討論與提交記錄：https://lore.kernel.org/all/20221028160401.cccypv4euxikusiq@parnassus.localdomain/；[2] 內核郵件串：https://lore.kernel.org/linux-kernel/jfjz5d7zwbytztackem7ibzalm5lnxldi2eofeiczqmqs2m7o6@fq426cwnjtkm/。此修復確保 padata_reorder 不會引用已經釋放的記憶體，避免 Use-After-Free，提高 Linux Kernel 並行處理的穩定性與安全性。 | CVE-2025-21727
|
| Linux | Linux | 1 | 在 Linux Kernel 中，以下漏洞已修復：wifi: rtw89: 修復 cancel_hw_scan 與 hw_scan 完成之間的競爭條件（race condition）。該問題發生的原因是 rtwdev->scanning 標誌原本未受到互斥鎖（mutex）保護，導致 cancel_hw_scan 可能通過條件檢查，但 hw_scan 可能在此期間完成並取消該標誌，然後調用 ieee80211_scan_completed() 釋放 local->hw_scan_req，導致 cancel_hw_scan 發生 NULL pointer dereference 和 Use-After-Free（UAF）。錯誤日誌顯示：KASAN: null-ptr-deref in range [0x0000000000000088-0x000000000000008f]。問題發生的典型流程如下：(1) hw_scan 執行時，rtwdev->scanning 設置為 true；(2) cancel_hw_scan() 執行，通過條件檢查但未鎖定 mutex；(3) hw_scan 同時完成並取消 rtwdev->scanning，釋放 hw_scan_req；(4) cancel_hw_scan() 繼續執行，但 hw_scan_req 已被釋放，導致 NULL pointer dereference 或 Use-After-Free。為了解決這個 競爭條件（race condition），開發者進行了以下修正：(1) 將條件檢查移動到受 mutex 保護的區域，確保 cancel_hw_scan 和 hw_scan 之間的操作不會發生競爭；(2) 修復了 可能導致 NULL pointer dereference 和 Use-After-Free 的情況，確保 hw_scan_req 在 cancel_hw_scan 執行時仍然有效。此修復提高了 rtw89 無線網卡驅動程式的穩定性，防止競爭條件導致 Kernel panic 或 系統崩潰。 | CVE-2025-21729
|
| Linux | Linux | 1 | 在 Linux 核心中，已解決以下漏洞：nbd: 不允許在斷開連接後重新連接。以下過程可能會導致 nbd_config 使用後釋放（UAF）問題：1) 暫時抓取 nbd_config；2) 在 nbd_genl_disconnect() 中刷新所有 recv_work() 並釋放初始引用：nbd_genl_disconnect、nbd_disconnect_and_put、nbd_disconnect、flush_workqueue(nbd->recv_workq)、如果 test_and_clear_bit(NBD_RT_HAS_CONFIG_REF, ...) 成立，則 nbd_config_put 被調用 -> 由於步驟 1），引用仍然未為零；3) nbd_genl_reconfigure() 再次排隊 recv_work()；nbd_genl_reconfigure、config = nbd_get_config_unlocked(nbd)、如果 !config，則成功；如果 !test_bit(NBD_RT_BOUND, ...)，則成功；nbd_reconnect_socket、排隊 work 到 nbd->recv_workq；4) 步驟 1）釋放引用；5) 最終，recv_work() 會觸發使用後釋放（UAF）：recv_work、nbd_config_put(nbd) -> nbd_config 被釋放；atomic_dec(&config->recv_threads) -> UAF。為了解決這個問題，通過在 nbd_genl_disconnect() 中清除 NBD_RT_BOUND，使得 nbd_genl_reconfigure() 失敗。 | CVE-2025-21731
|
| Linux | Linux | 1 | 在 Linux 核心中，已解決以下漏洞：scsi: ufs: core: 修正初始化錯誤和移除路徑中的使用後釋放問題。devm_blk_crypto_profile_init() 註冊了一個清理處理程序，當相關的（平台）設備被釋放時運行。對於 UFS，密碼學私有數據和指針存儲在 ufs_hba 的數據結構 struct ufs_hba::crypto_profile 中。這個結構體作為底層 ufshcd 和 Scsi_host 分配的一部分進行分配。在驅動釋放或在 ufshcd_pltfrm_init() 的錯誤處理期間，這個結構體在 ufshcd_dealloc_host() 中被釋放，然後才會釋放與上述密碼學調用相關聯的（平台）設備。一旦這個設備被釋放，密碼學清理代碼將運行，並使用剛釋放的 struct ufs_hba::crypto_profile。這會導致使用後釋放的情況。調用堆疊如下：kfree+0x60/0x2d8 (P) kvfree+0x44/0x60 blk_crypto_profile_destroy_callback+0x28/0x70 devm_action_release+0x1c/0x30 release_nodes+0x6c/0x108 devres_release_all+0x98/0x100 device_unbind_cleanup+0x20/0x70 really_probe+0x218/0x2d0 換句話說，初始化代碼流程是：1. 平台設備探測 2. ufshcd_pltfrm_init() 3. ufshcd_alloc_host() 4. scsi_host_alloc() 5. 分配 struct ufs_hba 6. 創建 scsi-host 設備 7. devm_blk_crypto_profile_init() 8. 使用平台設備註冊清理處理程序，並在 ufshcd_pltfrm_init() 的錯誤處理期間或驅動卸載期間：9. ufshcd_dealloc_host() 10. scsi_host_put() 11. put_device(scsi-host) 12. 釋放 struct ufs_hba 13. put_device(platform-device) 14. 密碼學清理處理程序。為了解決這個使用後釋放問題，將 ufshcd_alloc_host() 修改為註冊一個 devres 操作，當 ufshcd 被銷毀時，能夠自動清理底層的 SCSI 設備，而不需要顯式調用 ufshcd_dealloc_host()。這樣可以達到以下目的：- 密碼學配置文件和所有其他 ufs_hba 擁有的資源會在 SCSI 釋放之前銷毀（因為它們是在之後註冊的）。- 在 tc-dwc-g210-pci.c 的 remove() 中，會解決內存泄漏的問題。- EXPORT_SYMBOL_GPL(ufshcd_dealloc_host) 可以完全刪除，因為它不再需要。- 任何未來使用 ufshcd_alloc_host() 的驅動程序都不會再忘記添加清理操作。 | CVE-2025-21739
|
| Linux | Linux | 1 | 在 Linux 核心中，已解決以下漏洞：net/mlx5: HWS，變更匹配器斷開連接時的錯誤處理流程。目前，當在匹配器斷開連接流程中發生固件故障時，函數的錯誤處理流程會將匹配器重新連接並返回錯誤，這會繼續運行調用函數，最終釋放正在斷開的匹配器。這導致匹配器在匹配器列表中被釋放，進而引發使用後釋放錯誤並最終崩潰。此補丁通過在固件命令在斷開連接期間失敗時不再嘗試重新連接匹配器來修正此問題。請注意，這裡處理的是固件錯誤，我們無法克服此問題。這可能導致錯誤的導向狀態（例如匹配器之間的錯誤連接），並且會導致資源泄漏，就像其他資源銷毀過程中的錯誤處理情況一樣。然而，這裡的目標是允許驅動程序繼續運行，而不是因為使用後釋放錯誤而使機器崩潰。 | CVE-2025-21751
|
| Linux | Linux | 1 | 在 Linux 核心中，已解決以下漏洞：btrfs: 修正嘗試加入中止交易時的使用後釋放問題。當我們嘗試加入當前交易並且它已被中止時，我們在解鎖 fs_info->trans_lock 並且未持有額外的引用計數的情況下讀取其 'aborted' 欄位。這意味著一個正在中止交易的並行任務可能會在我們讀取其 'aborted' 欄位之前釋放交易，導致使用後釋放問題。通過在持有 fs_info->trans_lock 的情況下讀取 'aborted' 欄位來修正此問題，因為任何釋放交易的任務必須首先獲取該鎖，並在釋放交易之前將 fs_info->running_transaction 設為 NULL。 | CVE-2025-21753
|
| Linux | Linux | 1 | 在 Linux 核心中，以下漏洞已解決： vsock：保持綁定直到套接字銷毀保留套接字綁定；這包括由顯式 bind() 產生的結果和在 connect() 期間透過自動綁定隱式綁定的結果。 | CVE-2025-21756
|
| Linux | Linux | 1 | 在 Linux 核心中，以下漏洞已解決： ipv6：mcast：在 igmp6_send() 中擴展 RCU 保護 igmp6_send() 可以在不持有 RTNL 或 RCU 的情況下呼叫。擴展 RCU 保護，以便我們可以安全地取得網路指標並避免潛在的 UAF。請注意，我們不再能使用 sock_alloc_send_skb()，因為 ipv6.igmp_sk 使用可以休眠的 GFP_KERNEL 分配。而是使用 alloc_skb() 並在 RCU 保護下為 net->ipv6.igmp_sk 套接字充電。 | CVE-2025-21759
|
| Linux | Linux | 1 | 在 Linux 核心中，以下漏洞已解決： ndisc：擴充 ndisc_send_skb() 中的 RCU 保護 ndisc_send_skb() 可以在不持有 RTNL 或 RCU 的情況下呼叫。儘早取得 rcu_read_lock()，以便我們可以使用 dev_net_rcu() 並避免潛在的 UAF。 | CVE-2025-21760
|
| Linux | Linux | 1 | 在 Linux 核心中，以下漏洞已解決： openvswitch：在 ovs_vport_cmd_fill_info() 中使用 RCU 保護 ovs_vport_cmd_fill_info() 可以在沒有 RTNL 或 RCU 的情況下呼叫。使用 RCU 保護和 dev_net_rcu() 來避免潛在的 UAF。 | CVE-2025-21761
|
| Linux | Linux | 1 | 在 Linux 核心中，以下漏洞已解決： arp：在 arp_xmit() 中使用 RCU 保護 arp_xmit() 可以在沒有 RTNL 或 RCU 保護的情況下呼叫。使用 RCU 保護以避免潛在的 UAF。 | CVE-2025-21762
|
| Linux | Linux | 1 | 在 Linux 核心中，以下漏洞已解決：neighbour：在 __neigh_notify() 中使用 RCU 保護 __neigh_notify() 可以在沒有 RTNL 或 RCU 保護的情況下呼叫。使用 RCU 保護以避免潛在的 UAF。 | CVE-2025-21763
|
| Linux | Linux | 1 | 在 Linux 核心中，以下漏洞已解決： ndisc：在 ndisc_alloc_skb() 中使用 RCU 保護 ndisc_alloc_skb() 可以在不持有 RTNL 或 RCU 的情況下呼叫。添加 RCU 保護以避免可能出現的 UAF。 | CVE-2025-21764
|
| Linux | Linux | 1 | 在 Linux核心中，以下漏洞已解決：workqueue：從池中分離救援程序後放置pwq，提交68f83057b913（"workqueue: Reap workers via kthread_stop() and remove detach_completion"）新增了獲取正常工作人員的程式碼，但錯誤地沒有處理救援程序。為了避免出現釋放後使用錯誤，必須保留pool的參考直到分離完成。因此，將rescuer從pool中分離後放置pwq的程式碼移開。 | CVE-2025-21786
|
| Linux | Linux | 1 | 在 Linux 核心中，下列漏洞已解決： vrf：在 l3mdev_l3_out() 中使用 RCU 保護 可以在不持有 RCU 的情況下呼叫 l3mdev_l3_out()： raw_sendm() ip_push_pending_frames() ip_send_kbout( read_lock() / rcu_read_unlock() 對以避免潛在的 UAF。 | CVE-2025-21791
|
| Linux | Linux | 1 | 在 Linux 核心中，以下漏洞已解決： nfsd：釋放 acl_access/acl_default 後將其清除 如果取得 acl_default 失敗，acl_access 和 acl_default 將同時被釋放。 | CVE-2025-21796
|
| Linux | Linux | 1 | 在 Linux 核心中，以下漏洞已解決： HID：corsair-void：為耳機狀態添加缺失的延遲工作取消 錯過 cancel_delayed_work_sync() 調用，導致 corsair_void_remove() 中出現釋放後使用。 | CVE-2025-21797
|
