遠端 CentOS Linux 9 主機上安裝的套件受到 kernel-5.14.0-542.el9 版本變更記錄中提及的多個弱點影響。

  - 在 Linux 核心中，已解決下列弱點：nfsd：取消在 nfs4_state_shutdown_net 中使用同步模式的 nfsd_shrinker_work 在正常情況下，當我們執行 `echo 0 > /proc/fs/nfsd/threads` 時， `nfs4_state_shutdown_net` 中的函式 `nfs4_state_destroy_net` 將釋放與雜湊 `nfs4_client` 相關的所有資源。如果 `nfsd_client_shrinker` 正在同時執行，則 `expire_client` 函式會先取消此用戶端的雜湊，然後再將其損毀。這可能導致出現下列警告。
    此外，也可能發生數個釋放後使用錯誤。nfsd_client_shrinker echo 0 > /proc/fs/nfsd/threads expire_client nfsd_shutdown_net unhash_client ... nfs4_state_shutdown_net /* won't wait shrinker exit */ /* cancel_work(&nn->nfsd_shrinker_work) * nfsd_file for this /* won't destroy unhashed client1 */ * client1 still alive nfs4_state_destroy_net */ nfsd_file_cache_shutdown /* trigger warning */ kmem_cache_destroy(nfsd_file_slab) kmem_cache_destroy(nfsd_file_mark_slab) /* release nfsd_file and mark */ __destroy_client ==================================================================== 錯誤 nfsd_file (未受污染)：物件保留在 __kmem_cache_shutdown() 的 nfsd_file 中
    -------------------------------------------------------------------- CPU: 4 UID: 0 PID: 764 Comm: sh 未受污染 6.12.0-rc3+ #1 dump_stack_lvl+0x53/0x70 slab_err+0xb0/0xf0 __kmem_cache_shutdown+0x15c/0x310 kmem_cache_destroy+0x66/0x160 nfsd_file_cache_shutdown+0xac/0x210 [nfsd] nfsd_destroy_serv+0x251/0x2a0 [nfsd] nfsd_svc+0x125/0x1e0 [nfsd] write_threads+0x16a/0x2a0 [nfsd] nfsctl_transaction_write+0x74/0xa0 [nfsd] vfs_write+0x1a5/0x6d0 ksys_write+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e ==================================================================== 錯誤 nfsd_file_mark (受污染：GBW )：
    __kmem_cache_shutdown() 中剩餘 nfsd_file_mark 的物件
    -------------------------------------------------------------------- dump_stack_lvl+0x53/0x70 slab_err+0xb0/0xf0 __kmem_cache_shutdown+0x15c/0x310 kmem_cache_destroy+0x66/0x160 nfsd_file_cache_shutdown+0xc8/0x210 [nfsd] nfsd_destroy_serv+0x251/0x2a0 [nfsd] nfsd_svc+0x125/0x1e0 [nfsd] write_threads+0x16a/0x2a0 [nfsd] nfsctl_transaction_write+0x74/0xa0 [nfsd] vfs_write+0x1a5/0x6d0 ksys_write+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e 若要解決這個問題，在 nfs4_state_shutdown_net 中使用同步模式以取消 `nfsd_shrinker_work`。(CVE-2024-50121)

  - 在 Linux 核心中，已解決下列弱點：fscache：修正因與 cookie_lru 和 use_cookie 爭用而導致的 oops 如果 LRU 中的 cookie 過期並且已經設定 LRU_DISCARD 旗標，但是狀態機器尚未執行，則另一個執行緒可能可以呼叫 fscache_use_cookie 並開始使用它。
    當 cookie_worker 最終執行時，它會發現 LRU_DISCARD 旗標已設定，將 cookie->state 轉換為 LRU_DISCARDING，進而撤回 cookie。一旦撤回 cookie，該物件就會遭到移除，同時由於與 cookie 相關聯的物件現在為 NULL，因此將會發生下面的 oops。如果另一個執行緒在 cookie_worker 執行之前使用 cookie，則會藉由清除 LRU_DISCARD 位元來修正 oops。錯誤：核心 NULL 指標解除參照，位址：0000000000000008 ... CPU：31 PID：44773 Comm：kworker/u130:1 污染：GE 6.0.0-5.dneg.x86_64 #1 硬體名稱：Google Compute Engine/Google Compute Engine、BIOS Google 08/26/2022 工作佇列：events_unbound netfs_rreq_write_to_cache_work [ netfs] RIP：
    0010:cachefiles_prepare_write+0x28/0x90 [cachefiles] ... 呼叫追踪：
    netfs_rreq_write_to_cache_work+0x11c/0x320 [netfs] process_one_work+0x217/0x3e0 worker_thread+0x4a/0x3b0 kthread+0xd6/0x100 (CVE-2022-48989)

  - 在 Linux 核心中，已解決下列弱點：scsi：aacraid：修正透過 aac_driver_ident::init 指標呼叫硬體特定的 init 函式時，在探查失敗 aac_probe_one() 發生重複釋放的問題，所有這些函式最終都會向下呼叫至 aac_init_adapter( )。如果 aac_init_adapter() 在為 aac_dev::queues 配置記憶體之後失敗，它會釋放記憶體，但不會清除該成員。在硬體特定的 init 函式傳回錯誤之後，aac_probe_one() 會進入錯誤路徑，造成釋放 aac_dev::queues 所指向的記憶體，進而導致雙重釋放弱點。(CVE-2024-46673)

  - 在 Linux 核心中，已解決下列弱點：cachefiles：修正 cachefiles_open_file() 中的 dentry 洩漏。同時對 cookie 和 cull 進行查閱時，可能會造成 dentry 洩漏：P1 | P2
    -------------------------------------------------- --------- cachefiles_lookup_cookie cachefiles_look_up_object lookup_one_positive_unlocked // get dentry cachefiles_cull inode->i_flags |= S_KERNEL_FILE; cachefiles_open_file cachefiles_mark_inode_in_use __cachefiles_mark_inode_in_use can_use = false if (!(inode->i_flags & S_KERNEL_FILE)) can_use = true return false return false // 傳回錯誤，但不放置 dentry 之後，卸載後端資料夾時會觸發下列警告： ================================================= ================= 錯誤：Dentry 000000008ad87947{i=7a,n=Dx_1_1.img} 仍在使用中 (1) [unmount of ext4 sda] 警告：CPU: 4 PID: 359261 at fs/dcache.c:1767 umount_check+0x5d/0x70 CPU: 4 PID: 359261 Comm: umount 未受污染的 6.6.0-dirty #25 RIP：
    0010:umount_check+0x5d/0x70 呼叫追蹤：<TASK> d_walk+0xda/0x2b0 do_one_tree+0x20/0x40 shrink_dcache_for_umount+0x2c/0x90 generic_shutdown_super+0x20/0x160 kill_block_super+0x1a/0x40 ext4_kill_sb+0x22/0x40 deactivate_locked_super+0x35/0x80 cleanup_mnt+0x104 /0x160 ================================================ ================== 無論 cachefiles_open_file() 傳回 true 還是 false，都應該釋出在 cachefiles_look_up_object() 中透過 lookup_positive_unlocked() 取得的參照計數。因此，在 cachefiles_look_up_object() 中釋放該參照計數，以修正上述問題並簡化程式碼。(CVE-2024-49870)

  - 在 Linux 核心中已解決下列弱點：uprobes：透過 [uprobes] vma xol_add_vma() 將 __create_xol_area() 配置的未初始化頁面對應至使用者空間，修正核心資訊洩漏。
    在某些架構 (x86) 上，即使沒有 VM_READ 也可讀取此記憶體，VM_EXEC 會產生與 VM_EXEC|VM_READ 相同的 pgprot_t，儘管這並不重要，但是偵錯工具仍可讀取此記憶體。
    (CVE-2024-49975)

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

偵測

CentOS 9：kernel-5.14.0-542.el9

high Nessus Plugin ID 213059

版本 1.1