Rocky Linux 9.6 主機已安裝的套件會受到 TuxCare ALMALINUX9.6：CLSA-2026：1783091784 公告中提及的多個弱點影響。

  - 已解決 Linux 核心中的下列弱點：net: bcmgenet: Use stronger register read/writes to assure ordering GCC12 appears to be much smarter about its dependency tracking and is aware that the relaxed variants are just normal loads and stores and this is causing problems like: [210.074549] ------------[ cut here ]------------ [ 210.079223] NETDEV WATCHDOG: enabcm6e4ei0 (bcmgenet):
    transmit queue 1 timed out [ 210.086717] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:529 dev_watchdog+0x234/0x240 [ 210.095044] Modules linked in: genet(E) nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat] [ 210.146561] ACPI CPPC: PCC check channel failed for ss: 0. ret=-110 [ 210.146927] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G E 5.17.0-rc7G12+ #58 [ 210.153226] CPPC Cpufreq:cppc_scale_freq_workfn: failed to read perf counters [210.161349] Hardware name: Raspberry Pi Foundation Raspberry Pi 4 Model B/Raspberry Pi 4 Model B, BIOS EDK2-DEV 02/08/2022 [ 210.161353] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [210.161358] pc : dev_watchdog+0x234/0x240 [ 210.161364] lr : dev_watchdog+0x234/0x240 [ 210.161368] sp :
    ffff8000080a3a40 [ 210.161370] x29: ffff8000080a3a40 x28: ffffcd425af87000 x27: ffff8000080a3b20 [210.205150] x26: ffffcd425aa00000 x25: 0000000000000001 x24: ffffcd425af8ec08 [ 210.212321] x23:
    0000000000000100 x22: ffffcd425af87000 x21: ffff55b142688000 [ 210.219491] x20: 0000000000000001 x19:
    ffff55b1426884c8 x18: ffffffffffffffff [ 210.226661] x17: 64656d6974203120 x16: 0000000000000001 x15:
    6d736e617274203a [ 210.233831] x14: 2974656e65676d63 x13: ffffcd4259c300d8 x12: ffffcd425b07d5f0 [210.241001] x11: 00000000ffffffff x10: ffffcd425b07d5f0 x9 : ffffcd4258bdad9c [ 210.248171] x8 :
    00000000ffffdfff x7 : 000000000000003f x6 : 0000000000000000 [ 210.255341] x5 : 0000000000000000 x4 :
    0000000000000000 x3 : 0000000000001000 [ 210.262511] x2 : 0000000000001000 x1 : 0000000000000005 x0 :
    0000000000000044 [ 210.269682] Call trace: [ 210.272133] dev_watchdog+0x234/0x240 [ 210.275811] call_timer_fn+0x3c/0x15c [ 210.279489] __run_timers.part.0+0x288/0x310 [ 210.283777] run_timer_softirq+0x48/0x80 [ 210.287716] __do_softirq+0x128/0x360 [ 210.291392]
    __irq_exit_rcu+0x138/0x140 [ 210.295243] irq_exit_rcu+0x1c/0x30 [ 210.298745] el1_interrupt+0x38/0x54 [210.302334] el1h_64_irq_handler+0x18/0x24 [ 210.306445] el1h_64_irq+0x7c/0x80 [ 210.309857] arch_cpu_idle+0x18/0x2c [ 210.313445] default_idle_call+0x4c/0x140 [ 210.317470] cpuidle_idle_call+0x14c/0x1a0 [ 210.321584] do_idle+0xb0/0x100 [ 210.324737] cpu_startup_entry+0x30/0x8c [210.328675] secondary_start_kernel+0xe4/0x110 [ 210.333138] __secondary_switched+0x94/0x98 The assumption when these were relaxed seems to be that device memory would be mapped non reordering, and that other constructs (spinlocks/etc) would provide the barriers to assure that packet data and in memory rings/queues were ordered with respect to device register reads/writes. This itself seems a bit sketchy, but the real problem with GCC12 is that it is moving the actual reads/writes around at will as though they were independent operations when in truth they are not, but the compiler can't know that. When looking at the assembly dumps for many of these routines its possible to see very clean, but not strictly in program order operations occurring as the compiler would be free to do if these weren't actually register reads/write operations. Its possible to suppress the timeout with a liberal bit of dma_mb()'s sprinkled around but the device still seems unable to reliably send/receive data. A better plan is to use the safer readl/writel everywhere. Since this partially reverts an older commit, which notes the use of the relaxed variants for performance reasons. I would suggest that any performance problems ---truncated--- (CVE-2022-49194)

  - 已解決 Linux 核心中的下列弱點：can: isotp: sanitize CAN ID checks in isotp_bind() Syzbot created an environment that lead to a state machine status that can not be reached with a compliant CAN ID address configuration. The provided address information consisted of CAN ID 0x6000001 and 0xC28001 which both boil down to 11 bit CAN IDs 0x001 in sending and receiving. Sanitize the SFF/EFF CAN ID values before performing the address checks. (CVE-2022-49269)

  - 已解決 Linux 核心中的下列弱點：net/smc: Reset connection when trying to use SMCRv2 fails. We found a crash when using SMCRv2 with 2 Mellanox ConnectX-4. It can be reproduced by: - smc_run nginx - smc_run wrk -t 32 -c 500 -d 30 http://<ip>:<port> BUG: kernel NULL pointer dereference, address: 0000000000000014 #PF: supervisor read access in kernel mode #PF: error_code(0x0000)
    - not-present page PGD 8000000108713067 P4D 8000000108713067 PUD 151127067 PMD 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 4 PID: 2441 Comm: kworker/4:249 Kdump: loaded Tainted: G W E 6.4.0-rc1+ #42 Workqueue:
    smc_hs_wq smc_listen_work [smc] RIP: 0010:smc_clc_send_confirm_accept+0x284/0x580 [smc] RSP:
    0018:ffffb8294b2d7c78 EFLAGS: 00010a06 RAX: ffff8f1873238880 RBX: ffffb8294b2d7dc8 RCX: 0000000000000000 RDX: 00000000000000b4 RSI: 0000000000000001 RDI: 0000000000b40c00 RBP: ffffb8294b2d7db8 R08:
    ffff8f1815c5860c R09: 0000000000000000 R10: 0000000000000400 R11: 0000000000000000 R12: ffff8f1846f56180 R13: ffff8f1815c5860c R14: 0000000000000001 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8f1aefd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2:
    0000000000000014 CR3: 00000001027a0001 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? mlx5_ib_map_mr_sg+0xa1/0xd0 [mlx5_ib] ? smcr_buf_map_link+0x24b/0x290 [smc] ?
    __smc_buf_create+0x4ee/0x9b0 [smc] smc_clc_send_accept+0x4c/0xb0 [smc] smc_listen_work+0x346/0x650 [smc] ?
    __schedule+0x279/0x820 process_one_work+0x1e5/0x3f0 worker_thread+0x4d/0x2f0 ?
    __pfx_worker_thread+0x10/0x10 kthread+0xe5/0x120 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2c/0x50 </TASK> During the CLC handshake, server sequentially tries available SMCRv2 and SMCRv1 devices in smc_listen_work(). If an SMCRv2 device is found. SMCv2 based link group and link will be assigned to the connection. Then assumed that some buffer assignment errors happen later in the CLC handshake, such as RMB registration failure, server will give up SMCRv2 and try SMCRv1 device instead. But the resources assigned to the connection won't be reset. When server tries SMCRv1 device, the connection creation process will be executed again. Since conn->lnk has been assigned when trying SMCRv2, it will not be set to the correct SMCRv1 link in smcr_lgr_conn_assign_link(). So in such situation, conn->lgr points to correct SMCRv1 link group but conn->lnk points to the SMCRv2 link mistakenly. Then in smc_clc_send_confirm_accept(), conn->rmb_desc->mr[link->link_idx] will be accessed. Since the link->link_idx is not correct, the related MR may not have been initialized, so crash happens. | Try SMCRv2 device first | |-> conn->lgr: assign existed SMCRv2 link group; | |-> conn->link: assign existed SMCRv2 link (link_idx may be 1 in SMC_LGR_SYMMETRIC); | |-> sndbuf & RMB creation fails, quit; | | Try SMCRv1 device then | |-> conn->lgr:
    create SMCRv1 link group and assign; | |-> conn->link: keep SMCRv2 link mistakenly; | |-> sndbuf & RMB creation succeed, only RMB->mr[link_idx = 0] | initialized. | | Then smc_clc_send_confirm_accept() accesses | conn->rmb_desc->mr[conn->link->link_idx, which is 1], then crash. v This patch tries to fix this by cleaning conn->lnk before assigning link. In addition, it is better to reset the connection and clean the resources assigned if trying SMCRv2 failed in buffer creation or registration. (CVE-2023-53382)

  - 已解決 Linux 核心中的下列弱點：RDMA/irdma: Cap MSIX used to online CPUs + 1 The irdma driver can use a maximum number of msix vectors equal to num_online_cpus() + 1 and the kernel warning stack below is shown if that number is exceeded. The kernel throws a warning as the driver tries to update the affinity hint with a CPU mask greater than the max CPU IDs. Fix this by capping the MSIX vectors to num_online_cpus() + 1. WARNING: CPU: 7 PID: 23655 at include/linux/cpumask.h:106 irdma_cfg_ceq_vector+0x34c/0x3f0 [irdma] RIP: 0010:irdma_cfg_ceq_vector+0x34c/0x3f0 [irdma] Call Trace:
    irdma_rt_init_hw+0xa62/0x1290 [irdma] ? irdma_alloc_local_mac_entry+0x1a0/0x1a0 [irdma] ?
    __is_kernel_percpu_address+0x63/0x310 ? rcu_read_lock_held_common+0xe/0xb0 ? irdma_lan_unregister_qset+0x280/0x280 [irdma] ? irdma_request_reset+0x80/0x80 [irdma] ? ice_get_qos_params+0x84/0x390 [ice] irdma_probe+0xa40/0xfc0 [irdma] ? rcu_read_lock_bh_held+0xd0/0xd0 ? irdma_remove+0x140/0x140 [irdma] ? rcu_read_lock_sched_held+0x62/0xe0 ? down_write+0x187/0x3d0 ? auxiliary_match_id+0xf0/0x1a0 ? irdma_remove+0x140/0x140 [irdma] auxiliary_bus_probe+0xa6/0x100
    __driver_probe_device+0x4a4/0xd50 ? __device_attach_driver+0x2c0/0x2c0 driver_probe_device+0x4a/0x110
    __driver_attach+0x1aa/0x350 bus_for_each_dev+0x11d/0x1b0 ? subsys_dev_iter_init+0xe0/0xe0 bus_add_driver+0x3b1/0x610 driver_register+0x18e/0x410 ? 0xffffffffc0b88000 irdma_init_module+0x50/0xaa [irdma] do_one_initcall+0x103/0x5f0 ? perf_trace_initcall_level+0x420/0x420 ? do_init_module+0x4e/0x700 ?
    __kasan_kmalloc+0x7d/0xa0 ? kmem_cache_alloc_trace+0x188/0x2b0 ? kasan_unpoison+0x21/0x50 do_init_module+0x1d1/0x700 load_module+0x3867/0x5260 ? layout_and_allocate+0x3990/0x3990 ? rcu_read_lock_held_common+0xe/0xb0 ? rcu_read_lock_sched_held+0x62/0xe0 ? rcu_read_lock_bh_held+0xd0/0xd0 ? __vmalloc_node_range+0x46b/0x890 ? lock_release+0x5c8/0xba0 ? alloc_vm_area+0x120/0x120 ? selinux_kernel_module_from_file+0x2a5/0x300 ? __inode_security_revalidate+0xf0/0xf0 ?
    __do_sys_init_module+0x1db/0x260 __do_sys_init_module+0x1db/0x260 ? load_module+0x5260/0x5260 ? do_syscall_64+0x22/0x450 do_syscall_64+0xa5/0x450 entry_SYSCALL_64_after_hwframe+0x66/0xdb (CVE-2023-53811)

  - 已解決 Linux 核心中的下列弱點：i2c: smbus: fix NULL function pointer dereference Baruch reported an OOPS when using the designware controller as target only. Target-only modes break the assumption of one transfer function always being available. Fix this by always checking the pointer in __i2c_transfer. [wsa: dropped the simplification in core-smbus to avoid theoretical regressions] (CVE-2024-35984)

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

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

  - 在 Linux 核心中，下列弱點已解決: scsi: sg: 修復 sg_release() 中的 slab 釋放後使用讀取。修復 sg_release() 中的釋放後使用錯誤，該錯誤是由 syzbot 與 KASAN 偵測到的: BUG: KASAN: slab-use-after-free in lock_release+0x151/0xa30 kernel/locking/lockdep.c:5838
    __mutex_unlock_slowpath+0xe2/0x750 kernel/locking/mutex.c:912 sg_release+0x1f4/0x2e0 drivers/scsi/sg.c:407。在 sg_release() 函式中，會先呼叫函式 kref_put(&sfp->f_ref, sg_remove_sfp)，然後再釋出 open_rel_lock mutex。kref_put() 呼叫可能會將 sfp 的參照計數歸零，進而觸發透過 sg_remove_sfp() 進行的清理作業。該清理過程包括透過 sg_remove_sfp_usercontext() 排程延遲的工作，並於最後釋放 sfp。在執行 kref_put() 之後，sg_release() 仍會繼續解鎖 open_rel_lock，並可能參照 sfp 或 sdp。如果已釋放 sfp，這就會導致 slab 釋放後使用錯誤。解鎖 open_rel_lock mutex 後再移動 kref_put(&sfp->f_ref, sg_remove_sfp) 呼叫。此改動可確保: - 參照計數遞減後，不會再發生對 sfp 或 sdp 的參照。- sg_remove_sfp() 和 sg_remove_sfp_usercontext() 等清理函式可安全執行，而不會影響 sg_release() 中的 mutex 處理。此修復方式已由 syzbot 測試並驗證。此修補程式可解決下列 syzkaller 連結中回報的錯誤，並確保資源清理和 mutex 作業的順序正確，進而消除在 sg_release() 中發生釋放後使用錯誤的風險。 (CVE-2024-56631)

  - 在 Linux 核心中，下列弱點已解決: can: isotp: 清理 isotp_bind() 中的 CAN ID 檢查。Syzbot 建立的環境會導致狀態機器進入異常狀態，這在使用相容的 CAN ID 位址設定時是不可能達到的。已提供的位址資訊包含 CAN ID 0x6000001 和 0xC28001，兩者在傳送和接收過程中都會歸結為 11 位元 CAN ID 0x001。在執行位址檢查之前，清理 SFF/EFF CAN ID 值。(CVE-2022-49269)

  - 在 Linux 核心中，下列弱點已解決: can: bcm: 修復 bcm_proc_show() 中的 UAF BUG: KASAN: bcm_proc_show+0x969/0xa80 中的 slab 釋放後使用。讀取大小: 8 位元組。存取位址: ffff888155846230。觸發工作: cat/7862。CPU: 1。PID: 7862。指令名稱: cat。未污染 6.5.0-rc1-00153-gc8746099c197#230硬體名稱:
    QEMU 標準 PC (i440FX + PIIX, 1996)、BIOS 1.15.0-1 04/01/2014 呼叫追蹤: <TASK> dump_stack_lvl+0xd5/0x150 print_report+0xc1/0x5e0 kasan_report+0xba/0xf0 bcm_proc_show+0x969/0xa80 seq_read_iter+0x4f6/0x1260 seq_readread +0x165/0x210 proc_reg_read+0x227/0x300 vfs_read+0x1d5/0x8d0 ksys_read+0x11e/0x240 do_syscall_64+0x35/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcd。由工作 7846 分配: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 __kasan_kmalloc+0x9e/0xa0 bcm_sendmsg +0x264b/0x44e0 sock_sendmsg+0xda/0x180____sys_sendmsg+0x735/0x920 ___sys_sendmsg+0x11d/0x1b0
    __sys_sendmsg+0xfa/0x1d0 do_syscall_64+0x35/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcd。已由工作 7846 釋放: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 kasan_save_free_info+0x27/0x40
    ____kasan_slab_free+0x161/0x1c0 slab_free_freelist_hook+0x119/0x220 __kmem_cache_free+0xb4/0x2e0 rcu_core+0x809/0x1bd0。在 bcm_release() 中，bcm_op 在對應的 procfs 項目移除之前就已被釋放， 這導致 bcm_proc_show() 可能會讀取已釋放的 bcm_op 結構。(CVE-2023-52922)

  - 在 Linux 核心中，下列弱點已解決: x86/xen: 避免透過 hypercall 頁面執行 PV iret hypercall。不再跳轉至執行 iret hypercall 的 Xen hypercall 頁面，而是直接在 xen-asm.S. 中編寫所需的序列。這樣做是為了準備銜接未來完全停用 hypercall 頁面的機制，因為目前已證實該頁面會在使用推測緩解措施時產生問題。這是屬於 XSA-466/CVE-2024-53241 的問題。(CVE-2024-53241)

  - 在 Linux 核心中，下列弱點已解決: scsi: megaraid_sas: 修復潛在的鎖死問題。這可修復「偵測到可能的循環鎖定相依性」警告。 CPU0 CPU1 ----
    ---- lock(&instance->reset_mutex); lock(&shost->scan_mutex); lock(&instance->reset_mutex);
    lock(&shost->scan_mutex); 透過暫時釋放 reset_mutex 來修復此問題。(CVE-2024-57807)

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

遠端 Redhat Enterprise Linux 9 主機上安裝的多個套件受到 RHSA-2025:20518 公告中提及的多個弱點影響。

    核心套件中包含 Linux 核心，後者是任何 Linux 作業系統的核心。

    安全性修正：

    * 核心：can：isotp：修正 isotp_rcv() 中潛在的 CAN 框架接收爭用 (CVE-2022-48830)

    * 核心：soc：qcom：cmd-db：將共用記憶體對應為 WC，而非 WB (CVE-2024-46689)

    * 核心：Squashfs：功能健全檢查符號連結大小(CVE-2024-46744)

    * 核心：vfs：修正 evice_inodes() 和 find_inode()&iput() 之間的爭用 (CVE-2024-47679)

    * 核心：x86/tdx：修正核心內 MMIO 檢查 (CVE-2024-47727)

    * 核心：rxrpc：修正通訊端設定和 I/O 執行緒建立之間的爭用 (CVE-2024-49864)

    * 核心：io_uring：檢查溢位排清期間是否需要重新排程 (CVE-2024-50060)

    * 核心：can：m_can：pci：在 probe/remove 方法中新增遺漏的 m_can_class_free_dev() (CVE-2022-49024)

    * 核心：posix-clock：修正 pc_clock_settime() 中遺漏的 timespec64 檢查 (CVE-2024-50195)

    * 核心：rxrpc：修正造成呼叫懸置的遺漏鎖定 (CVE-2024-50294)

    * 核心：io_uring/rw：修正 O_DIRECT 開始寫入中遺漏的 NOWAIT 檢查 (CVE-2024-53052)

    * 核心：afs：修正鎖定遞迴 (CVE-2024-53090)

    * 核心：virtio/vsock：修正 accept_queue 記憶體洩漏 (CVE-2024-53119)

    * 核心：KVM：VMX：將 Intel PT 虛擬化 (訪客/主機模式) 隱藏在 CONFIG_BROKEN 之後 (CVE-2024-53135)

    * 核心: xen: Xen hypercall 頁面未對推測性攻擊提供保護 (Xen 安全公告 466) (CVE-2024-53241)

    * 核心：RDMA/rxe：修正 req 中的 qp 排清警告 (CVE-2024-53229)

    * 核心：block：修正 uaf 以便在迭代標籤時排清 rq (CVE-2024-53170)

    * 核心：nfsd：使用 rcu_work 發布 svc_expkey/svc_export (CVE-2024-53216)

    * 核心：net：af_can：不在 can_create() 中遺留懸置 sk 指標 (CVE-2024-56603)

    * 核心：blk-cgroup：修正 blkcg_unpin_online() 中的 UAF 問題 (CVE-2024-56672)

    * 核心：acpi：nfit：acpi_nfit_ctl 中的 vmalloc-out-of-bounds 讀取 (CVE-2024-56662)

    * 核心：bpf：透過錯誤匹配 bpf_prog/attachment RCU flavors 修正 UAF (CVE-2024-56675)

    * 核心：can：j1939: j1939_session_new()：修正 skb 參照計數 (CVE-2024-56645)

    * 核心：crypto：pcrypt - 當 padata_do_parallel() 傳回 -EBUSY 時直接呼叫 crypto 層(CVE-2024-56690)

    * 核心：io_uring：檢查 iowq 在佇列前是否已刪除 (CVE-2024-56709)

    * 核心：rtc：檢查 rtc_timer_do_work() 中的 __rtc_read_time 是否成功(CVE-2024-56739)

    * 核心：bpf：當可以安全解除配置連結時，放置 bpf_link 的程式 (CVE-2024-56786)

    * 核心：igb：修正 igb_init_module() 中潛在的無效記憶體存取 (CVE-2024-52332)

    * 核心：ipvs：修正 ip_vs_protocol_init() 中未初始化堆疊存取所導致的 UB (CVE-2024-53680)

    * 核心：netfilter：conntrack：將雜湊表大小上限限制為 INT_MAX(CVE-2025-21648)

    * 核心：sched：sch_cake：將邊界檢查新增至主機大量流量公平計數(CVE-2025-21647)

    * 核心：block、bfq：修復 bfq_split_bfqq() 後的 waker_bfqq UAF 問題(CVE-2025-21631)

    * 核心：zram：修復 zram 表格潛在的 UAF 問題 (CVE-2025-21671)

    * 核心：afs：修正合併偏好設定規則失敗情況 (CVE-2025-21672)

    * 核心：mm：zswap：CPU hotunplug 期間正確同步釋放資源 (CVE-2025-21693)

    * 核心：cachestat：修正頁面快取統計資料權限檢查 (CVE-2025-21691)

    * 核心：mm：清除 mremap() 上的 uffd-wp PTE/PMD 狀態 (CVE-2025-21696)

    * 核心：pfifo_tail_enqueue：：當 sch->limit == 0 時放置新封包 (CVE-2025-21702)

    * 核心：usbnet：修正錯誤情況下的記憶體流失 (CVE-2022-49657)

    * 核心：powerpc/xics：修正 icp_opal_init() 中的 refcount 洩漏 (CVE-2022-49432)

    * 核心：net：tun：在損毀時取消 NAPI 與裝置的連結 (CVE-2022-49672)

    * 核心：powerpc/papr_scm：不使用 '0' 大小的統計資料緩衝區要求統計資料 (CVE-2022-49353)

    * 核心：powerpc/xive：修正 xive_spapr_init 中的 refcount 洩漏 (CVE-2022-49437)

    * 核心：ima：修正 ima_init_crypto() 中的潛在記憶體洩漏 (CVE-2022-49627)

    * 核心：linux/dim：修正 RDMA DIM 中的除以零錯誤 (CVE-2022-49670)

    * 核心：can：isotp：清理 isotp_bind() 中的 CAN ID 檢查 (CVE-2022-49269)

    * 核心：ima：修正 ima_appraise_measurement 中的潛在整數溢位 (CVE-2022-49643)

    * 核心：powerpc/xive/spapr：更正點陣圖配置大小 (CVE-2022-49623)

    * 核心：efi：不針對 T2 Macs 從 UEFI Secure Boot 匯入憑證 (CVE-2022-49357)

    * 核心：list：修正有關 ep->rdllist 的資料爭用 (CVE-2022-49443)

    * 核心：tracing/histograms：修正記憶體洩漏問題 (CVE-2022-49648)

    * 核心：Input：synaptics - 修正啟用 Pass-Through 連接埠時發生的當機 (CVE-2025-21746)

    * 核心：NFSD：修正 nfsd4_shutdown_callback 中的懸置 (CVE-2025-21795)

    * 核心：bpf：如果是 !preemptible，則以非同步方式傳送訊號 (CVE-2025-21728)

    * 核心：NFS：修正 nfs_sysfs_link_rpc_client() 中的潛在緩衝區溢位 (CVE-2024-54456)

    * 核心：Bluetooth：btrtl：檢查 btrtl_setup_realtek() 中的 NULL (CVE-2024-57987)

    * 核心：wifi: brcmsmac: 將增益範圍檢查新增至 wlc_phy_iqcal_gainparams_nphy() (CVE-2024-58014)

    * 核心：Bluetooth：btbcm：修正 btbcm_get_board_name() 中的 NULL 解除參照 (CVE-2024-57988)

    * 核心：RDMA/mlx5：修正隱含的 ODP 釋放後使用 (CVE-2025-21714)

    * 核心：drm/xe/tracing：修正潛在的 TP_printk UAF (CVE-2024-49570)

    * 核心：HID：hid-thrustmaster：透過新增端點檢查來修正 torquemaster_probe 中的警告 (CVE-2024-57993)

    * 核心：wifi：rtw89：修正 cancel_hw_scan 和 hw_scan 完成之間的爭用 (CVE-2025-21729)

    * 核心：wifi：mt76：mt7925：修正 mt7925_change_vif_links 中的 NULL 解除參照檢查 (CVE-2024-57989)

    * 核心：wifi: ath12k：對於超出邊界存取錯誤的修正 (CVE-2024-58015)

    * 核心：OPP：新增要宣告的索引檢查，避免 _read_freq() 中發生緩衝區溢位 (CVE-2024-57998)

    * 核心：wifi：ath12k：修正 ath12k_mac_assign_vif_to_vdev() 中的釋放後讀取指標 (CVE-2024-57995)

    * 核心：nfsd：釋放 acl_access/acl_default 後予以清除 (CVE-2025-21796)

    * 核心：scsi：ufs：core：修正 init 錯誤中的釋放後使用並移除路徑 (CVE-2025-21739)

    * 核心：workqueue：將集區與 rescuer 分開後放置 pwq (CVE-2025-21786)

    * 核心：ata：libata-sff：確保我們無法在配置的緩衝區之外寫入 (CVE-2025-21738)

    * 核心：HID: core: 修復解析乘數必須位於邏輯集合中的假設 (CVE-2024-57986)

    * 核心：padata：避免 reorder_work 的 UAF (CVE-2025-21726)

    * 核心：vrf：在 l3mdev_l3_out() 中使用 RCU 保護 (CVE-2025-21791)

    * 核心：team：改善 TEAM_OPTION_TYPE_STRING 驗證 (CVE-2025-21787)

    * 核心：usb: xhci: 修復中止特定命令期間的 NULL 指標解除參照 (CVE-2024-57981)

    * 核心：vxlan：檢查 vxlan_vnigroup_init() 傳回值 (CVE-2025-21790)

    * 核心：wifi：mt76：mt7925：修正 mt7925_load_clc() 中的差一問題 (CVE-2024-57990)

    * 核心：ipv6：在 ip6_default_advmss() 中使用 RCU 保護 (CVE-2025-21765)

    * 核心：ASoC：SOF：Intel：hda-dai：確保 DAI Widget 在參數執行期間有效 (CVE-2024-58012)

    * 核心：blk-cgroup: 修復類別 @block_class 的子系統 refcount 洩漏問題 (CVE-2025-21745)

    * 核心：net: 讓 net.core.dev_weight 始終保持為非零 (CVE-2025-21806)

    * 核心：wifi：rtlwifi：移除未使用的 check_buddy_priv (CVE-2024-58072)

    * 核心：OPP：修正頻寬表未初始化時的 dev_pm_opp_find_bw_*() (CVE-2024-58068)

    * 核心：wifi：iwlwifi：mvm：避免 Null 指標解除參照問題 (CVE-2024-58062)

    * 核心：idpf：將工作佇列轉換為未繫結 (CVE-2024-58057)

    * 核心：wifi：mac80211：不清除未上傳的 STA (CVE-2025-21828)

    * 核心：KVM：明確驗證目標 vCPU 已經在 kvm_get_vcpu() 上線 (CVE-2024-58083)

    * 核心：netfilter：nf_tables：拒絕包含設定金鑰長度的 field_len 不相符的總和 (CVE-2025-21826)

    * 核心：ASoC：soc-pcm：不要在 .prepare 回呼時使用 soc_pcm_ret() (CVE-2024-58077)

    * 核心：crypto：不在 tegra init 失敗時傳輸 req (CVE-2024-58075)

    * 核心：RDMA/rxe：修正警告 __rxe_cleanup+0x12c/0x170 [rdma_rxe] (CVE-2025-21829)

    * 核心：KVM：x86：在進入 .vcpu_run() 迴圈之前，僅以訪客值載入 DR6 (CVE-2025-21839)

    * 核心：io_uring/uring_cmd：在準備階段無條件複製 SQE (CVE-2025-21837)

    * 核心：透過某些 AMD 處理器中的瞬態執行弱點造成資訊洩漏 (CVE-2024-36350)

    * 核心：某些 AMD 處理器中的瞬態執行弱點 (CVE-2024-36357)

    * 核心：bpf：修正 64k 頁面核心上 arena_map_free 中的 softlockup (CVE-2025-21851)

    * 核心：ibmvnic：傳送至 VIOS 後不參照 skb (CVE-2025-21855)

    * 核心：smb：client：在 receive_encrypted_standard() 中新增 next_buffer 檢查 (CVE-2025-21844)

    * 核心：bpf：避免在 mmap 作業期間持有 freeze_mutex (CVE-2025-21853)

    * 核心：ASoC：SOF：stream-ipc：檢查 sof_ipc_msg_data() 中的 cstream 無效性 (CVE-2025-21847)

    * 核心：tcp：在我們目前放置 dst 的同時放置 secpath (CVE-2025-21864)

    * 核心：bpf：修正釋放 cgroup 儲存空間時的鎖死問題 (CVE-2024-58088)

    * 核心：acct：從工作佇列執行上次寫入 (CVE-2025-21846)

    * 核心：mm/migrate_device：不要在 migrate_device_finalize() 中新增釋放至 LRU 的 folio (CVE-2025-21861)

    * 核心：io_uring：防止 opcode 推測 (CVE-2025-21863)

    * 核心：nfp：bpf：新增 nfp_app_ctrl_msg_alloc() 的檢查 (CVE-2025-21848)

    * 核心：netfilter：nft_tunnel：修正 geneve_opt 類型混淆新增 (CVE-2025-22056)

    * 核心：can：j1939：j1939_send_one()：修正缺少的 CAN 標頭初始化 (CVE-2022-49845)

    * 核心：usb：typec：ucsi：displayport：修正 NULL 指標存取 (CVE-2025-37994)

    * 核心：wifi: ath12k：修正 ath12k_core_init() 中的 uaf (CVE-2025-38116)

    * 核心：fs：匯出 anon_inode_make_secure_inode() 並修正 secretmem LSM 繞過 (CVE-2025-38396)

    如需安全性問題的詳細資料，包括影響、CVSS 評分、致謝及其他相關資訊，請參閱〈參照〉一節列出的 CVE 頁面。

    其他變更：

    如需有關此發行版本的詳細變更資訊，請參閱可從「參照」一節連結的 Red Hat Enterprise Linux 9 版本資訊。

Tenable 已直接從 Red Hat Enterprise Linux 安全公告擷取前置描述區塊。

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

遠端 AlmaLinux 9 主機已安裝受到多個弱點影響的套件如 ALSA-2025:20518 公告中所提及。

    * 核心canisotp修正 isotp_rcv() 中可能發生的 CAN 框架接收爭用 (CVE-2022-48830)
      * 核心soc: qcom: cmd-db將共用記憶體對應為 WC 而非 WB (CVE-2024-46689)
      * 核心Squashfs功能健全檢查符號連結大小 (CVE-2024-46744)
      * 核心vfs修正 evice_inodes() 和 find_inode()&iput() 之間的爭用 (CVE-2024-47679)
      * 核心x86/tdx修正核心內 MMIO 檢查 (CVE-2024-47727)
      * 核心rxrpc修正通訊端設定和 I/O 執行緒建立之間的爭用 (CVE-2024-49864)
      * 核心io_uring溢位排清期間檢查是否需要重新排程 (CVE-2024-50060)
      * 核心canm_canpci新增探查/移除方法中缺少的 m_can_class_free_dev() (CVE-2022-49024)
      * 核心posix-clock修正 pc_clock_settime() 中遺漏的 timespec64 檢查 (CVE-2024-50195)
      * 核心rxrpc修正造成呼叫懸置的遺漏鎖定 (CVE-2024-50294)
      * 核心io_uring/rw修正遺漏的 O_DIRECT 開始寫入的 NOWAIT 檢查 (CVE-2024-53052)
      * 核心afs修正鎖定遞回 (CVE-2024-53090)
      * 核心virtio/vsock修正 accept_queue 記憶體洩漏 (CVE-2024-53119)
      * 核心KVMVMX將 Intel PT 虛擬化 (來賓/主機模式) 隱藏在 CONFIG_BROKEN 之後 (CVE-2024-53135)
      * 核心: xen: Xen hypercall 頁面未對推測性攻擊提供保護 (Xen 安全公告 466) (CVE-2024-53241)
      * 核心RDMA/rxe修正 req 中的 qp 排清警告 (CVE-2024-53229)
      * 核心區塊修正 uaf 以在反覆標籤時排清 rq (CVE-2024-53170)
      * 核心nfsd使用 rcu_work 版本 svc_expkey/svc_export (CVE-2024-53216)
      * 核心netaf_can不將懸置的 sk 指標留在 can_create() 中 (CVE-2024-56603)
      * 核心blk-cgroup修正 blkcg_unpin_online() 中的 UAF (CVE-2024-56672)
      * 核心acpi: nfitacpi_nfit_ctl 中的 vmalloc-out-of-bounds Read (CVE-2024-56662)
      * 核心bpf透過不相符的 bpf_prog/attachment RCU 類別修正 UAF (CVE-2024-56675)
      * 核心canj1939j1939_session_new()修正 skb 參照計數 (CVE-2024-56645)
      * 核心cryptopcrypt - 當 padata_do_parallel() 傳回 -EBUSY 時直接呼叫 crypto 層 (CVE-2024-56690)
      * 核心io_uring檢查在佇列前iowq 是否已終止 (CVE-2024-56709)
      * 核心rtc檢查 rtc_timer_do_work() 中的 __rtc_read_time 是否成功 (CVE-2024-56739)
      * 核心bpf在連結可以安全解除配置時放置 bpf_link 的程式 (CVE-2024-56786)
      * 核心igb修正 igb_init_module() 中可能發生的無效記憶體存取 (CVE-2024-52332)
      * 核心ipvs修正 ip_vs_protocol_init() 中未初始化堆疊存取所導致的 UB (CVE-2024-53680)
      * 核心netfilterconntrack將雜湊表大小上限限制為 INT_MAX (CVE-2025-21648)
      * 核心schedsch_cake新增邊界檢查至主機大量流量公平計數 (CVE-2025-21647)
      * kernel: block、bfq在 bfq_split_bfqq() 之後修正 waker_bfqq UAF (CVE-2025-21631)
      * 核心zram修正 zram 表格的潛在 UAF (CVE-2025-21671)
      * 核心afs修正合併偏好設定規則失敗情形 (CVE-2025-21672)
      * 核心mmzswap在 CPU 熱插拔期間正確同步釋放資源 (CVE-2025-21693)
      * 核心cachestat修正頁面快取統計資料權限檢查 (CVE-2025-21691)
      * 核心mm清除 mremap() 上的 uffd-wp PTE/PMD 狀態 (CVE-2025-21696)
      * 核心pfifo_tail_enqueue在 sch->limit == 0 時放置新封包 (CVE-2025-21702)
      * 核心usbnet修正錯誤案例中的記憶體洩漏 (CVE-2022-49657)
      * 核心powerpc/xics修正 icp_opal_init() 中的 refcount 洩漏 (CVE-2022-49432)
      * 核心nettun取消破壞時 NAPI 與裝置連結 (CVE-2022-49672)
      * 核心powerpc/papr_scm不以 '0' 大小的統計資料緩衝區要求統計資料 (CVE-2022-49353)
      * 核心powerpc/xive修正 xive_spapr_init 中的 refcount 洩漏 (CVE-2022-49437)
      * 核心ima修正 ima_init_crypto() 中的潛在記憶體洩漏 (CVE-2022-49627)
      * 核心linux/dim修正 RDMA DIM 中的除以零錯誤 (CVE-2022-49670)
      * 核心canisotp清理 isotp_bind() 中的 CAN ID 檢查 (CVE-2022-49269)
      * 核心ima修正 ima_appraise_measurement 中一個潛在的整數溢位問題 (CVE-2022-49643)
      * 核心powerpc/xive/spapr更正點陣圖配置大小 (CVE-2022-49623)
      * 核心efi不從適用於 T2 Macs 的 UEFI 安全開機匯入憑證 (CVE-2022-49357)
      * 核心list修正有關 ep->rdllist 的資料爭用 (CVE-2022-49443)
      * 核心追踪/直方圖修正記憶體洩漏問題 (CVE-2022-49648)
      * 核心輸入synaptics - 修正啟用傳遞連接埠時發生的當機 (CVE-2025-21746)
      * 核心NFSD修正 nfsd4_shutdown_callback 中的懸置 (CVE-2025-21795)
      * 核心bpf在 !preemptible 的情況下以非同步方式傳送訊號 (CVE-2025-21728)
      * 核心NFS修正 nfs_sysfs_link_rpc_client() 中的潛在緩衝區溢位 (CVE-2024-54456)
      * 核心藍牙btrtl檢查 btrtl_setup_realtek() 中的 NULL (CVE-2024-57987)
      * 核心wifibrcmsmac新增增益範圍檢查至 wlc_phy_iqcal_gainparams_nphy() (CVE-2024-58014)
      * 核心藍牙btbcm修正 btbcm_get_board_name() 中的 NULL 解除參照 (CVE-2024-57988)
      * 核心RDMA/mlx5修正隱含的 ODP 釋放後使用 (CVE-2025-21714)
      * 核心drm/xe/tracing修正潛在的 TP_printk UAF (CVE-2024-49570)
      * 核心HIDhid-thrustmaster新增端點檢查以修正 torquemaster_probe 中的警告 (CVE-2024-57993)
      * 核心wifirtw89修正 cancel_hw_scan 和 hw_scan 完成之間的爭用 (CVE-2025-21729)
      * 核心wifimt76mt7925修正 mt7925_change_vif_links 中的 NULL 解除參照檢查 (CVE-2024-57989)
      * 核心wifiath12k 超出邊界存取錯誤修正 (CVE-2024-58015)
      * 核心OPP新增索引檢查以宣告避免 _read_freq() 中發生緩衝區溢位 (CVE-2024-57998)
      * 核心wifiath12k修正 ath12k_mac_assign_vif_to_vdev() 中的釋放後讀取指標 (CVE-2024-57995)
      * 核心nfsd釋出 acl_access/acl_default 後予以清除 (CVE-2025-21796)
      * 核心scsiufs核心修正 init 錯誤中的釋放後使用錯誤並移除路徑 (CVE-2025-21739)
      * 核心workqueue從集區卸離救援程式後放置 pwq (CVE-2025-21786)
      * 核心atalibata-sff確保我們無法在配置的緩衝區之外寫入 (CVE-2025-21738)
      * 核心HID核心修正解析乘數必須位於邏輯集合中的假設 (CVE-2024-57986)
      * 核心padata避免 reorder_work 的 UAF (CVE-2025-21726)
      * 核心vrf在 l3mdev_l3_out() 中使用 RCU 保護 (CVE-2025-21791)
      * 核心團隊改善 TEAM_OPTION_TYPE_STRING 驗證 (CVE-2025-21787)
      * 核心usbxhci修正特定命令中止時的 NULL 指標解除參照 (CVE-2024-57981)
      * 核心vxlan檢查 vxlan_vnigroup_init() 傳回值 (CVE-2025-21790)
      * 核心wifimt76mt7925修正 mt7925_load_clc() 中的差一問題 (CVE-2024-57990)
      * 核心ipv6在 ip6_default_advmss() 中使用 RCU 保護 (CVE-2025-21765)
      * 核心ASoCSOFIntelhda-dai確保 DAI Widget 在參數執行期間有效 (CVE-2024-58012)
      * 核心blk-cgroup修正類別 @block_class 的子系統 refcount 洩漏 (CVE-2025-21745)
      * 核心netnet.core.dev_weight 永遠為非零 (CVE-2025-21806)
      * 核心wifirtlwifi移除未使用的 check_buddy_priv (CVE-2024-58072)
      * 核心OPP修正頻寬表格未初始化時的 dev_pm_opp_find_bw_*() (CVE-2024-58068)
      * 核心：wifi：iwlwifi：mvm：避免 Null 指標解除參照問題 (CVE-2024-58062)
      * 核心idpf將 workqueue 轉換為 unbound (CVE-2024-58057)
      * 核心wifimac80211不排清未上傳的 STA (CVE-2025-21828)
      * 核心KVM明確驗證目標 vCPU 在 kvm_get_vcpu() 中是否在線 (CVE-2024-58083)
      * 核心netfilternf_tables拒絕含有設定金鑰長度之 field_len 不符的總和 (CVE-2025-21826)
      * 核心ASoCsoc-pcm不在 .prepare 回呼上使用 soc_pcm_ret() (CVE-2024-58077)
      * 核心cryptotegra - 當 tegra init 失敗時不傳輸 req (CVE-2024-58075)
      * 核心RDMA/rxe修正警告 __rxe_cleanup+0x12c/0x170 [rdma_rxe] (CVE-2025-21829)
      * 核心KVMx86進入 .vcpu_run() 迴圈前僅以來賓值載入 DR6 (CVE-2025-21839)
      * 核心io_uring/uring_cmd準備時無條件複製 SQE (CVE-2025-21837)
      * 核心：透過某些 AMD 處理器中的瞬態執行弱點造成資訊洩漏 (CVE-2024-36350)
      * 核心：某些 AMD 處理器中的瞬態執行弱點 (CVE-2024-36357)
      * 核心bpf修正 64k 頁面核心上 arena_map_free 中的軟鎖定 (CVE-2025-21851)
      * 核心ibmvnic傳送至 VIOS 後不參照 skb (CVE-2025-21855)
      * kernelsmbclient新增 receive_encrypted_standard() 中的 next_buffer 檢查 (CVE-2025-21844)
      * 核心bpf避免在 mmap 作業期間按住 freeze_mutex (CVE-2025-21853)
      * 核心ASoCSOFstream-ipc檢查 sof_ipc_msg_data() 中的 cstream 無效性 (CVE-2025-21847)
      * 核心tcp在我們目前放置 dst 的同時放置 secpath (CVE-2025-21864)
      * 核心bpf修正釋放 cgroup 儲存空間時的鎖死問題 (CVE-2024-58088)
      * 核心acct從工作佇列執行上次寫入 (CVE-2025-21846)
      * 核心mm/migrate_device不將要釋放的作品集新增至 migrate_device_finalize() 中的 LRU (CVE-2025-21861)
      * 核心io_uring防止 opcode 推測 (CVE-2025-21863)
      * 核心nfpbpf新增 nfp_app_ctrl_msg_alloc() 的檢查 (CVE-2025-21848)
      * 核心netfilternft_tunnel修正geneve_opt 類型混淆新增 (CVE-2025-22056)
      * 核心canj1939j1939_send_one()修正遺漏的 CAN 標頭初始化 (CVE-2022-49845)
      * 核心usbtypecucsidisplayport修正 NULL 指標存取 (CVE-2025-37994)
      * 核心wifiath12k修正 ath12k_core_init() 中的 uaf (CVE-2025-38116)
      * 核心fs匯出 anon_inode_make_secure_inode() 並修正 secretmem LSM 繞過 (CVE-2025-38396)

Tenable 已直接從 AlmaLinux 安全公告擷取前置描述區塊。

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

遠端 Oracle Linux 9 主機中安裝的套件受到 ELSA-2025-205180 公告中提及的多個弱點影響。

    - io_uring/futex確保 io_futex_wait() 在失敗時正確清理 (CKI Backport Bot) [RHEL-114336] {CVE-2025-39698}
    - NFS修正 nfs_fh_to_dentry() 中的 filehandle 邊界檢查 (CKI Backport Bot) [RHEL-113611] {CVE-2025-39730}
    - eventpoll修正半無限制遞回 (CKI 反向移植機器人) [RHEL-111050] {CVE-2025-38614}
    - ALSA：hda/ca0132：修正 add_tuning_control 中的緩衝區溢位 (CKI Backport Bot) [RHEL-114850] {CVE-2025-39751}
    - wifiath12k處理 RX 對等片段設定錯誤時遞減 TID (CKI 反向移植機器人) [RHEL-114708] {CVE-2025-39761}
    - ALSA：usb-audio：也驗證 UAC3 power 網域描述符號 (Jaroslav Kysela) [RHEL-114691] {CVE-2025-38729}
    - ALSAusb-audio驗證 UAC3 叢集區段描述符號 (CKI Backport Bot) [RHEL-114691] {CVE-2025-39757}
    - selfteststls新增零長度記錄的測試 (Sabrina Dubroca) [RHEL-114324] {CVE-2025-39682}
    - tls修正 rx_list 上零長度記錄的處理 (Sabrina Dubroca) [RHEL-114324] {CVE-2025-39682}

Tenable 已直接從 Oracle Linux 安全公告擷取前置描述區塊。

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

Rocky Linux 9 主機已安裝的套件會受到 CIQ crlsa-2025_20518 公告中提及的多個弱點影響。

    * 核心：can：isotp：修正 isotp_rcv() 中潛在的 CAN 框架接收爭用 (CVE-2022-48830)

    * 核心：soc：qcom：cmd-db：將共用記憶體對應為 WC，而非 WB (CVE-2024-46689)

    * 核心：Squashfs：功能健全檢查符號連結大小(CVE-2024-46744)

    * 核心：vfs：修正 evice_inodes() 和 find_inode()&iput() 之間的爭用 (CVE-2024-47679)

    * 核心：x86/tdx：修正核心內 MMIO 檢查 (CVE-2024-47727)

    * 核心：rxrpc：修正通訊端設定和 I/O 執行緒建立之間的爭用 (CVE-2024-49864)

    * 核心：io_uring：檢查溢位排清期間是否需要重新排程 (CVE-2024-50060)

    * 核心：can：m_can：pci：在 probe/remove 方法中新增遺漏的 m_can_class_free_dev() (CVE-2022-49024)

    * 核心：posix-clock：修正 pc_clock_settime() 中遺漏的 timespec64 檢查 (CVE-2024-50195)

    * 核心：rxrpc：修正造成呼叫懸置的遺漏鎖定 (CVE-2024-50294)

    * 核心：io_uring/rw：修正 O_DIRECT 開始寫入中遺漏的 NOWAIT 檢查 (CVE-2024-53052)

    * 核心：afs：修正鎖定遞迴 (CVE-2024-53090)

    * 核心：virtio/vsock：修正 accept_queue 記憶體洩漏 (CVE-2024-53119)

    * 核心：KVM：VMX：將 Intel PT 虛擬化 (訪客/主機模式) 隱藏在 CONFIG_BROKEN 之後 (CVE-2024-53135)

    * 核心: xen: Xen hypercall 頁面未對推測性攻擊提供保護 (Xen 安全公告 466) (CVE-2024-53241)

    * 核心：RDMA/rxe：修正 req 中的 qp 排清警告 (CVE-2024-53229)

    * 核心：block：修正 uaf 以便在迭代標籤時排清 rq (CVE-2024-53170)

    * 核心：nfsd：使用 rcu_work 發布 svc_expkey/svc_export (CVE-2024-53216)

    * 核心：net：af_can：不在 can_create() 中遺留懸置 sk 指標 (CVE-2024-56603)

    * 核心：blk-cgroup：修正 blkcg_unpin_online() 中的 UAF 問題 (CVE-2024-56672)

    * 核心：acpi：nfit：acpi_nfit_ctl 中的 vmalloc-out-of-bounds 讀取 (CVE-2024-56662)

    * 核心：bpf：透過錯誤匹配 bpf_prog/attachment RCU flavors 修正 UAF (CVE-2024-56675)

    * 核心：can：j1939: j1939_session_new()：修正 skb 參照計數 (CVE-2024-56645)

    * 核心：crypto：pcrypt - 當 padata_do_parallel() 傳回 -EBUSY 時直接呼叫 crypto 層(CVE-2024-56690)

    * 核心：io_uring：檢查 iowq 在佇列前是否已刪除 (CVE-2024-56709)

    * 核心：rtc：檢查 rtc_timer_do_work() 中的 __rtc_read_time 是否成功(CVE-2024-56739)

    * 核心：bpf：當可以安全解除配置連結時，放置 bpf_link 的程式 (CVE-2024-56786)

    * 核心：igb：修正 igb_init_module() 中潛在的無效記憶體存取 (CVE-2024-52332)

    * 核心：ipvs：修正 ip_vs_protocol_init() 中未初始化堆疊存取所導致的 UB (CVE-2024-53680)

    * 核心：netfilter：conntrack：將雜湊表大小上限限制為 INT_MAX(CVE-2025-21648)

    * 核心：sched：sch_cake：將邊界檢查新增至主機大量流量公平計數(CVE-2025-21647)

    * 核心：block、bfq：修復 bfq_split_bfqq() 後的 waker_bfqq UAF 問題(CVE-2025-21631)

    * 核心：zram：修復 zram 表格潛在的 UAF 問題 (CVE-2025-21671)

    * 核心：afs：修正合併偏好設定規則失敗情況 (CVE-2025-21672)

    * 核心：mm：zswap：CPU hotunplug 期間正確同步釋放資源 (CVE-2025-21693)

    * 核心：cachestat：修正頁面快取統計資料權限檢查 (CVE-2025-21691)

    * 核心：mm：清除 mremap() 上的 uffd-wp PTE/PMD 狀態 (CVE-2025-21696)

    * 核心：pfifo_tail_enqueue：：當 sch->limit == 0 時放置新封包 (CVE-2025-21702)

    * 核心：usbnet：修正錯誤情況下的記憶體流失 (CVE-2022-49657)

    * 核心：powerpc/xics：修正 icp_opal_init() 中的 refcount 洩漏 (CVE-2022-49432)

    * 核心：net：tun：在損毀時取消 NAPI 與裝置的連結 (CVE-2022-49672)

    * 核心：powerpc/papr_scm：不使用 '0' 大小的統計資料緩衝區要求統計資料 (CVE-2022-49353)

    * 核心：powerpc/xive：修正 xive_spapr_init 中的 refcount 洩漏 (CVE-2022-49437)

    * 核心：ima：修正 ima_init_crypto() 中的潛在記憶體洩漏 (CVE-2022-49627)

    * 核心：linux/dim：修正 RDMA DIM 中的除以零錯誤 (CVE-2022-49670)

    * 核心：can：isotp：清理 isotp_bind() 中的 CAN ID 檢查 (CVE-2022-49269)

    * 核心：ima：修正 ima_appraise_measurement 中的潛在整數溢位 (CVE-2022-49643)

    * 核心：powerpc/xive/spapr：更正點陣圖配置大小 (CVE-2022-49623)

    * 核心：efi：不針對 T2 Macs 從 UEFI Secure Boot 匯入憑證 (CVE-2022-49357)

    * 核心：list：修正有關 ep->rdllist 的資料爭用 (CVE-2022-49443)

    * 核心：tracing/histograms：修正記憶體洩漏問題 (CVE-2022-49648)

    * 核心：Input：synaptics - 修正啟用 Pass-Through 連接埠時發生的當機 (CVE-2025-21746)

    * 核心：NFSD：修正 nfsd4_shutdown_callback 中的懸置 (CVE-2025-21795)

    * 核心：bpf：如果是 !preemptible，則以非同步方式傳送訊號 (CVE-2025-21728)

    * 核心：NFS：修正 nfs_sysfs_link_rpc_client() 中的潛在緩衝區溢位 (CVE-2024-54456)

    * 核心：Bluetooth：btrtl：檢查 btrtl_setup_realtek() 中的 NULL (CVE-2024-57987)

    * 核心：wifi: brcmsmac: 將增益範圍檢查新增至 wlc_phy_iqcal_gainparams_nphy() (CVE-2024-58014)

    * 核心：Bluetooth：btbcm：修正 btbcm_get_board_name() 中的 NULL 解除參照 (CVE-2024-57988)

    * 核心：RDMA/mlx5：修正隱含的 ODP 釋放後使用 (CVE-2025-21714)

    * 核心：drm/xe/tracing：修正潛在的 TP_printk UAF (CVE-2024-49570)

    * 核心：HID：hid-thrustmaster：透過新增端點檢查來修正 torquemaster_probe 中的警告 (CVE-2024-57993)

    * 核心：wifi：rtw89：修正 cancel_hw_scan 和 hw_scan 完成之間的爭用 (CVE-2025-21729)

    * 核心：wifi：mt76：mt7925：修正 mt7925_change_vif_links 中的 NULL 解除參照檢查 (CVE-2024-57989)

    * 核心：wifi: ath12k：對於超出邊界存取錯誤的修正 (CVE-2024-58015)

    * 核心：OPP：新增要宣告的索引檢查，避免 _read_freq() 中發生緩衝區溢位 (CVE-2024-57998)

    * 核心：wifi：ath12k：修正 ath12k_mac_assign_vif_to_vdev() 中的釋放後讀取指標 (CVE-2024-57995)

    * 核心：nfsd：釋放 acl_access/acl_default 後予以清除 (CVE-2025-21796)

    * 核心：scsi：ufs：core：修正 init 錯誤中的釋放後使用並移除路徑 (CVE-2025-21739)

    * 核心：workqueue：將集區與 rescuer 分開後放置 pwq (CVE-2025-21786)

    * 核心：ata：libata-sff：確保我們無法在配置的緩衝區之外寫入 (CVE-2025-21738)

    * 核心：HID: core: 修復解析乘數必須位於邏輯集合中的假設 (CVE-2024-57986)

    * 核心：padata：避免 reorder_work 的 UAF (CVE-2025-21726)

    * 核心：vrf：在 l3mdev_l3_out() 中使用 RCU 保護 (CVE-2025-21791)

    * 核心：team：改善 TEAM_OPTION_TYPE_STRING 驗證 (CVE-2025-21787)

    * 核心：usb: xhci: 修復中止特定命令期間的 NULL 指標解除參照 (CVE-2024-57981)

    * 核心：vxlan：檢查 vxlan_vnigroup_init() 傳回值 (CVE-2025-21790)

    * 核心：wifi：mt76：mt7925：修正 mt7925_load_clc() 中的差一問題 (CVE-2024-57990)

    * 核心：ipv6：在 ip6_default_advmss() 中使用 RCU 保護 (CVE-2025-21765)

    * 核心：ASoC：SOF：Intel：hda-dai：確保 DAI Widget 在參數執行期間有效 (CVE-2024-58012)

    * 核心：blk-cgroup: 修復類別 @block_class 的子系統 refcount 洩漏問題 (CVE-2025-21745)

    * 核心：net: 讓 net.core.dev_weight 始終保持為非零 (CVE-2025-21806)

    * 核心：wifi：rtlwifi：移除未使用的 check_buddy_priv (CVE-2024-58072)

    * 核心：OPP：修正頻寬表未初始化時的 dev_pm_opp_find_bw_*() (CVE-2024-58068)

    * 核心：wifi：iwlwifi：mvm：避免 Null 指標解除參照問題 (CVE-2024-58062)

    * 核心：idpf：將工作佇列轉換為未繫結 (CVE-2024-58057)

    * 核心：wifi：mac80211：不清除未上傳的 STA (CVE-2025-21828)

    * 核心：KVM：明確驗證目標 vCPU 已經在 kvm_get_vcpu() 上線 (CVE-2024-58083)

    * 核心：netfilter：nf_tables：拒絕包含設定金鑰長度的 field_len 不相符的總和 (CVE-2025-21826)

    * 核心：ASoC：soc-pcm：不要在 .prepare 回呼時使用 soc_pcm_ret() (CVE-2024-58077)

    * 核心：crypto：不在 tegra init 失敗時傳輸 req (CVE-2024-58075)

    * 核心：RDMA/rxe：修正警告 __rxe_cleanup+0x12c/0x170 [rdma_rxe] (CVE-2025-21829)

    * 核心：KVM：x86：在進入 .vcpu_run() 迴圈之前，僅以訪客值載入 DR6 (CVE-2025-21839)

    * 核心：io_uring/uring_cmd：在準備階段無條件複製 SQE (CVE-2025-21837)

    * 核心：透過某些 AMD 處理器中的瞬態執行弱點造成資訊洩漏 (CVE-2024-36350)

    * 核心：某些 AMD 處理器中的瞬態執行弱點 (CVE-2024-36357)

    * 核心：bpf：修正 64k 頁面核心上 arena_map_free 中的 softlockup (CVE-2025-21851)

    * 核心：ibmvnic：傳送至 VIOS 後不參照 skb (CVE-2025-21855)

    * 核心：smb：client：在 receive_encrypted_standard() 中新增 next_buffer 檢查 (CVE-2025-21844)

    * 核心：bpf：避免在 mmap 作業期間持有 freeze_mutex (CVE-2025-21853)

    * 核心：ASoC：SOF：stream-ipc：檢查 sof_ipc_msg_data() 中的 cstream 無效性 (CVE-2025-21847)

    * 核心：tcp：在我們目前放置 dst 的同時放置 secpath (CVE-2025-21864)

    * 核心：bpf：修正釋放 cgroup 儲存空間時的鎖死問題 (CVE-2024-58088)

    * 核心：acct：從工作佇列執行上次寫入 (CVE-2025-21846)

    * 核心：mm/migrate_device：不要在 migrate_device_finalize() 中新增釋放至 LRU 的 folio (CVE-2025-21861)

    * 核心：io_uring：防止 opcode 推測 (CVE-2025-21863)

    * 核心：nfp：bpf：新增 nfp_app_ctrl_msg_alloc() 的檢查 (CVE-2025-21848)

    * 核心：netfilter：nft_tunnel：修正 geneve_opt 類型混淆新增 (CVE-2025-22056)

    * 核心：can：j1939：j1939_send_one()：修正缺少的 CAN 標頭初始化 (CVE-2022-49845)

    * 核心：usb：typec：ucsi：displayport：修正 NULL 指標存取 (CVE-2025-37994)

    * 核心：wifi: ath12k：修正 ath12k_core_init() 中的 uaf (CVE-2025-38116)

    * 核心：fs：匯出 anon_inode_make_secure_inode() 並修正 secretmem LSM 繞過 (CVE-2025-38396)

Tenable 已直接從 CIQ 安全性公告中擷取上述描述區塊。

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

遠端 RockyLinux 9 主機已安裝受到多個弱點影響的套件如 RLSA-2025:20518 公告中所提及。

    * 核心：can：isotp：修正 isotp_rcv() 中潛在的 CAN 框架接收爭用 (CVE-2022-48830)

    * 核心：soc：qcom：cmd-db：將共用記憶體對應為 WC，而非 WB (CVE-2024-46689)

    * 核心：Squashfs：功能健全檢查符號連結大小(CVE-2024-46744)

    * 核心：vfs：修正 evice_inodes() 和 find_inode()&iput() 之間的爭用 (CVE-2024-47679)

    * 核心：x86/tdx：修正核心內 MMIO 檢查 (CVE-2024-47727)

    * 核心：rxrpc：修正通訊端設定和 I/O 執行緒建立之間的爭用 (CVE-2024-49864)

    * 核心：io_uring：檢查溢位排清期間是否需要重新排程 (CVE-2024-50060)

    * 核心：can：m_can：pci：在 probe/remove 方法中新增遺漏的 m_can_class_free_dev() (CVE-2022-49024)

    * 核心：posix-clock：修正 pc_clock_settime() 中遺漏的 timespec64 檢查 (CVE-2024-50195)

    * 核心：rxrpc：修正造成呼叫懸置的遺漏鎖定 (CVE-2024-50294)

    * 核心：io_uring/rw：修正 O_DIRECT 開始寫入中遺漏的 NOWAIT 檢查 (CVE-2024-53052)

    * 核心：afs：修正鎖定遞迴 (CVE-2024-53090)

    * 核心：virtio/vsock：修正 accept_queue 記憶體洩漏 (CVE-2024-53119)

    * 核心：KVM：VMX：將 Intel PT 虛擬化 (訪客/主機模式) 隱藏在 CONFIG_BROKEN 之後 (CVE-2024-53135)

    * 核心: xen: Xen hypercall 頁面未對推測性攻擊提供保護 (Xen 安全公告 466) (CVE-2024-53241)

    * 核心：RDMA/rxe：修正 req 中的 qp 排清警告 (CVE-2024-53229)

    * 核心：block：修正 uaf 以便在迭代標籤時排清 rq (CVE-2024-53170)

    * 核心：nfsd：使用 rcu_work 發布 svc_expkey/svc_export (CVE-2024-53216)

    * 核心：net：af_can：不在 can_create() 中遺留懸置 sk 指標 (CVE-2024-56603)

    * 核心：blk-cgroup：修正 blkcg_unpin_online() 中的 UAF 問題 (CVE-2024-56672)

    * 核心：acpi：nfit：acpi_nfit_ctl 中的 vmalloc-out-of-bounds 讀取 (CVE-2024-56662)

    * 核心：bpf：透過錯誤匹配 bpf_prog/attachment RCU flavors 修正 UAF (CVE-2024-56675)

    * 核心：can：j1939: j1939_session_new()：修正 skb 參照計數 (CVE-2024-56645)

    * 核心：crypto：pcrypt - 當 padata_do_parallel() 傳回 -EBUSY 時直接呼叫 crypto 層(CVE-2024-56690)

    * 核心：io_uring：檢查 iowq 在佇列前是否已刪除 (CVE-2024-56709)

    * 核心：rtc：檢查 rtc_timer_do_work() 中的 __rtc_read_time 是否成功(CVE-2024-56739)

    * 核心：bpf：當可以安全解除配置連結時，放置 bpf_link 的程式 (CVE-2024-56786)

    * 核心：igb：修正 igb_init_module() 中潛在的無效記憶體存取 (CVE-2024-52332)

    * 核心：ipvs：修正 ip_vs_protocol_init() 中未初始化堆疊存取所導致的 UB (CVE-2024-53680)

    * 核心：netfilter：conntrack：將雜湊表大小上限限制為 INT_MAX(CVE-2025-21648)

    * 核心：sched：sch_cake：將邊界檢查新增至主機大量流量公平計數(CVE-2025-21647)

    * 核心：block、bfq：修復 bfq_split_bfqq() 後的 waker_bfqq UAF 問題(CVE-2025-21631)

    * 核心：zram：修復 zram 表格潛在的 UAF 問題 (CVE-2025-21671)

    * 核心：afs：修正合併偏好設定規則失敗情況 (CVE-2025-21672)

    * 核心：mm：zswap：CPU hotunplug 期間正確同步釋放資源 (CVE-2025-21693)

    * 核心：cachestat：修正頁面快取統計資料權限檢查 (CVE-2025-21691)

    * 核心：mm：清除 mremap() 上的 uffd-wp PTE/PMD 狀態 (CVE-2025-21696)

    * 核心：pfifo_tail_enqueue：：當 sch->limit == 0 時放置新封包 (CVE-2025-21702)

    * 核心：usbnet：修正錯誤情況下的記憶體流失 (CVE-2022-49657)

    * 核心：powerpc/xics：修正 icp_opal_init() 中的 refcount 洩漏 (CVE-2022-49432)

    * 核心：net：tun：在損毀時取消 NAPI 與裝置的連結 (CVE-2022-49672)

    * 核心：powerpc/papr_scm：不使用 '0' 大小的統計資料緩衝區要求統計資料 (CVE-2022-49353)

    * 核心：powerpc/xive：修正 xive_spapr_init 中的 refcount 洩漏 (CVE-2022-49437)

    * 核心：ima：修正 ima_init_crypto() 中的潛在記憶體洩漏 (CVE-2022-49627)

    * 核心：linux/dim：修正 RDMA DIM 中的除以零錯誤 (CVE-2022-49670)

    * 核心：can：isotp：清理 isotp_bind() 中的 CAN ID 檢查 (CVE-2022-49269)

    * 核心：ima：修正 ima_appraise_measurement 中的潛在整數溢位 (CVE-2022-49643)

    * 核心：powerpc/xive/spapr：更正點陣圖配置大小 (CVE-2022-49623)

    * 核心：efi：不針對 T2 Macs 從 UEFI Secure Boot 匯入憑證 (CVE-2022-49357)

    * 核心：list：修正有關 ep->rdllist 的資料爭用 (CVE-2022-49443)

    * 核心：tracing/histograms：修正記憶體洩漏問題 (CVE-2022-49648)

    * 核心：Input：synaptics - 修正啟用 Pass-Through 連接埠時發生的當機 (CVE-2025-21746)

    * 核心：NFSD：修正 nfsd4_shutdown_callback 中的懸置 (CVE-2025-21795)

    * 核心：bpf：如果是 !preemptible，則以非同步方式傳送訊號 (CVE-2025-21728)

    * 核心：NFS：修正 nfs_sysfs_link_rpc_client() 中的潛在緩衝區溢位 (CVE-2024-54456)

    * 核心：Bluetooth：btrtl：檢查 btrtl_setup_realtek() 中的 NULL (CVE-2024-57987)

    * 核心：wifi: brcmsmac: 將增益範圍檢查新增至 wlc_phy_iqcal_gainparams_nphy() (CVE-2024-58014)

    * 核心：Bluetooth：btbcm：修正 btbcm_get_board_name() 中的 NULL 解除參照 (CVE-2024-57988)

    * 核心：RDMA/mlx5：修正隱含的 ODP 釋放後使用 (CVE-2025-21714)

    * 核心：drm/xe/tracing：修正潛在的 TP_printk UAF (CVE-2024-49570)

    * 核心：HID：hid-thrustmaster：透過新增端點檢查來修正 torquemaster_probe 中的警告 (CVE-2024-57993)

    * 核心：wifi：rtw89：修正 cancel_hw_scan 和 hw_scan 完成之間的爭用 (CVE-2025-21729)

    * 核心：wifi：mt76：mt7925：修正 mt7925_change_vif_links 中的 NULL 解除參照檢查 (CVE-2024-57989)

    * 核心：wifi: ath12k：對於超出邊界存取錯誤的修正 (CVE-2024-58015)

    * 核心：OPP：新增要宣告的索引檢查，避免 _read_freq() 中發生緩衝區溢位 (CVE-2024-57998)

    * 核心：wifi：ath12k：修正 ath12k_mac_assign_vif_to_vdev() 中的釋放後讀取指標 (CVE-2024-57995)

    * 核心：nfsd：釋放 acl_access/acl_default 後予以清除 (CVE-2025-21796)

    * 核心：scsi：ufs：core：修正 init 錯誤中的釋放後使用並移除路徑 (CVE-2025-21739)

    * 核心：workqueue：將集區與 rescuer 分開後放置 pwq (CVE-2025-21786)

    * 核心：ata：libata-sff：確保我們無法在配置的緩衝區之外寫入 (CVE-2025-21738)

    * 核心：HID: core: 修復解析乘數必須位於邏輯集合中的假設 (CVE-2024-57986)

    * 核心：padata：避免 reorder_work 的 UAF (CVE-2025-21726)

    * 核心：vrf：在 l3mdev_l3_out() 中使用 RCU 保護 (CVE-2025-21791)

    * 核心：team：改善 TEAM_OPTION_TYPE_STRING 驗證 (CVE-2025-21787)

    * 核心：usb: xhci: 修復中止特定命令期間的 NULL 指標解除參照 (CVE-2024-57981)

    * 核心：vxlan：檢查 vxlan_vnigroup_init() 傳回值 (CVE-2025-21790)

    * 核心：wifi：mt76：mt7925：修正 mt7925_load_clc() 中的差一問題 (CVE-2024-57990)

    * 核心：ipv6：在 ip6_default_advmss() 中使用 RCU 保護 (CVE-2025-21765)

    * 核心：ASoC：SOF：Intel：hda-dai：確保 DAI Widget 在參數執行期間有效 (CVE-2024-58012)

    * 核心：blk-cgroup: 修復類別 @block_class 的子系統 refcount 洩漏問題 (CVE-2025-21745)

    * 核心：net: 讓 net.core.dev_weight 始終保持為非零 (CVE-2025-21806)

    * 核心：wifi：rtlwifi：移除未使用的 check_buddy_priv (CVE-2024-58072)

    * 核心：OPP：修正頻寬表未初始化時的 dev_pm_opp_find_bw_*() (CVE-2024-58068)

    * 核心：wifi：iwlwifi：mvm：避免 Null 指標解除參照問題 (CVE-2024-58062)

    * 核心：idpf：將工作佇列轉換為未繫結 (CVE-2024-58057)

    * 核心：wifi：mac80211：不清除未上傳的 STA (CVE-2025-21828)

    * 核心：KVM：明確驗證目標 vCPU 已經在 kvm_get_vcpu() 上線 (CVE-2024-58083)

    * 核心：netfilter：nf_tables：拒絕包含設定金鑰長度的 field_len 不相符的總和 (CVE-2025-21826)

    * 核心：ASoC：soc-pcm：不要在 .prepare 回呼時使用 soc_pcm_ret() (CVE-2024-58077)

    * 核心：crypto：不在 tegra init 失敗時傳輸 req (CVE-2024-58075)

    * 核心：RDMA/rxe：修正警告 __rxe_cleanup+0x12c/0x170 [rdma_rxe] (CVE-2025-21829)

    * 核心：KVM：x86：在進入 .vcpu_run() 迴圈之前，僅以訪客值載入 DR6 (CVE-2025-21839)

    * 核心：io_uring/uring_cmd：在準備階段無條件複製 SQE (CVE-2025-21837)

    * 核心：透過某些 AMD 處理器中的瞬態執行弱點造成資訊洩漏 (CVE-2024-36350)

    * 核心：某些 AMD 處理器中的瞬態執行弱點 (CVE-2024-36357)

    * 核心：bpf：修正 64k 頁面核心上 arena_map_free 中的 softlockup (CVE-2025-21851)

    * 核心：ibmvnic：傳送至 VIOS 後不參照 skb (CVE-2025-21855)

    * 核心：smb：client：在 receive_encrypted_standard() 中新增 next_buffer 檢查 (CVE-2025-21844)

    * 核心：bpf：避免在 mmap 作業期間持有 freeze_mutex (CVE-2025-21853)

    * 核心：ASoC：SOF：stream-ipc：檢查 sof_ipc_msg_data() 中的 cstream 無效性 (CVE-2025-21847)

    * 核心：tcp：在我們目前放置 dst 的同時放置 secpath (CVE-2025-21864)

    * 核心：bpf：修正釋放 cgroup 儲存空間時的鎖死問題 (CVE-2024-58088)

    * 核心：acct：從工作佇列執行上次寫入 (CVE-2025-21846)

    * 核心：mm/migrate_device：不要在 migrate_device_finalize() 中新增釋放至 LRU 的 folio (CVE-2025-21861)

    * 核心：io_uring：防止 opcode 推測 (CVE-2025-21863)

    * 核心：nfp：bpf：新增 nfp_app_ctrl_msg_alloc() 的檢查 (CVE-2025-21848)

    * 核心：netfilter：nft_tunnel：修正 geneve_opt 類型混淆新增 (CVE-2025-22056)

    * 核心：can：j1939：j1939_send_one()：修正缺少的 CAN 標頭初始化 (CVE-2022-49845)

    * 核心：usb：typec：ucsi：displayport：修正 NULL 指標存取 (CVE-2025-37994)

    * 核心：wifi: ath12k：修正 ath12k_core_init() 中的 uaf (CVE-2025-38116)

    * 核心：fs：匯出 anon_inode_make_secure_inode() 並修正 secretmem LSM 繞過 (CVE-2025-38396)

Tenable 已直接從 RockyLinux 安全公告擷取前置描述區塊。

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

AlmaLinux 9.2 主機安裝的套件會受到 TuxCare ALMALINUX9.2：CLSA-2026：1783791447 公告中提及的多個弱點影響。

  - 已解決 Linux 核心中的下列弱點：phy: mdio: fix memory leak Syzbot reported memory leak in MDIO bus interface, the problem was in wrong state logic. MDIOBUS_ALLOCATED indicates 2 states: 1. Bus is only allocated 2. Bus allocated and __mdiobus_register() fails, but device_register() was called In case of device_register() has been called we should call put_device() to correctly free the memory allocated for this device, but mdiobus_free() calls just kfree(dev) in case of MDIOBUS_ALLOCATED state To avoid this behaviour we need to set bus->state to MDIOBUS_UNREGISTERED _before_ calling device_register(), because put_device() should be called even in case of device_register() failure. (CVE-2021-47416)

  - 在 Linux 核心的 TeleTYpe 子系統中發現超出邊界讀取缺陷。由於 flush_to_ldisc 函式中存在記憶體洩漏弱點，使用者利用 ioctls 的 TIOCSPTLCK、TIOCGPTPEER、TIOCSTI 和 TCXONC 觸發爭用情形時會發生此問題。本機使用者可利用此缺陷造成系統當機，或從記憶體讀取未經授權的隨機資料。(CVE-2022-1462)

  - 已解決 Linux 核心中的下列弱點：can: isotp: sanitize CAN ID checks in isotp_bind() Syzbot created an environment that lead to a state machine status that can not be reached with a compliant CAN ID address configuration. The provided address information consisted of CAN ID 0x6000001 and 0xC28001 which both boil down to 11 bit CAN IDs 0x001 in sending and receiving. Sanitize the SFF/EFF CAN ID values before performing the address checks. (CVE-2022-49269)

  - 已解決 Linux 核心中的下列弱點：tty: fix deadlock caused by calling printk() under tty_port->lock pty_write() invokes kmalloc() which may invoke a normal printk() to print failure message. This can cause a deadlock in the scenario reported by syz-bot below: CPU0 CPU1 CPU2 ----
    ---- ---- lock(console_owner); lock(&port_lock_key); lock(&port->lock); lock(&port_lock_key);
    lock(&port->lock); lock(console_owner); As commit dbdda842fe96 (printk: Add console owner and waiter logic to load balance console writes) said, such deadlock can be prevented by using printk_deferred() in kmalloc() (which is invoked in the section guarded by the port->lock). But there are too many printk() on the kmalloc() path, and kmalloc() can be called from anywhere, so changing printk() to printk_deferred() is too complicated and inelegant. Therefore, this patch chooses to specify __GFP_NOWARN to kmalloc(), so that printk() will not be called, and this deadlock problem can be avoided. Syzbot reported the following lockdep error: ====================================================== WARNING: possible circular locking dependency detected 5.4.143-00237-g08ccc19a-dirty #10 Not tainted
    ------------------------------------------------------ syz-executor.4/29420 is trying to acquire lock:
    ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: console_trylock_spinning kernel/printk/printk.c:1752 [inline] ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: vprintk_emit+0x2ca/0x470 kernel/printk/printk.c:2023 but task is already holding lock: ffff8880119c9158 (&port->lock){-.-.}-{2:2}, at: pty_write+0xf4/0x1f0 drivers/tty/pty.c:120 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&port->lock){-.-.}-{2:2}: __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159 tty_port_tty_get drivers/tty/tty_port.c:288 [inline] <-- lock(&port->lock);
    tty_port_default_wakeup+0x1d/0xb0 drivers/tty/tty_port.c:47 serial8250_tx_chars+0x530/0xa80 drivers/tty/serial/8250/8250_port.c:1767 serial8250_handle_irq.part.0+0x31f/0x3d0 drivers/tty/serial/8250/8250_port.c:1854 serial8250_handle_irq drivers/tty/serial/8250/8250_port.c:1827 [inline] <-- lock(&port_lock_key); serial8250_default_handle_irq+0xb2/0x220 drivers/tty/serial/8250/8250_port.c:1870 serial8250_interrupt+0xfd/0x200 drivers/tty/serial/8250/8250_core.c:126 __handle_irq_event_percpu+0x109/0xa50 kernel/irq/handle.c:156 [...] -> #1 (&port_lock_key){-.-.}-{2:2}: __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159 serial8250_console_write+0x184/0xa40 drivers/tty/serial/8250/8250_port.c:3198 <-- lock(&port_lock_key);
    call_console_drivers kernel/printk/printk.c:1819 [inline] console_unlock+0x8cb/0xd00 kernel/printk/printk.c:2504 vprintk_emit+0x1b5/0x470 kernel/printk/printk.c:2024 <-- lock(console_owner);
    vprintk_func+0x8d/0x250 kernel/printk/printk_safe.c:394 printk+0xba/0xed kernel/printk/printk.c:2084 register_console+0x8b3/0xc10 kernel/printk/printk.c:2829 univ8250_console_init+0x3a/0x46 drivers/tty/serial/8250/8250_core.c:681 console_init+0x49d/0x6d3 kernel/printk/printk.c:2915 start_kernel+0x5e9/0x879 init/main.c:713 secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:241 -> #0 (console_owner){....}-{0:0}: [...] lock_acquire+0x127/0x340 kernel/locking/lockdep.c:4734 console_trylock_spinning kernel/printk/printk.c:1773 ---truncated--- (CVE-2022-49441)

  - 已解決 Linux 核心中的下列弱點：list: fix a data-race around ep->rdllist ep_poll() first calls ep_events_available() with no lock held and checks if ep->rdllist is empty by list_empty_careful(), which reads rdllist->prev. Thus all accesses to it need some protection to avoid store/load-tearing. Note INIT_LIST_HEAD_RCU() already has the annotation for both prev and next.
    Commit bf3b9f6372c4 (epoll: Add busy poll support to epoll with socket fds.) added the first lockless ep_events_available(), and commit c5a282e9635e (fs/epoll: reduce the scope of wq lock in epoll_wait()) made some ep_events_available() calls lockless and added single call under a lock, finally commit e59d3c64cba6 (epoll: eliminate unnecessary lock for zero timeout) made the last ep_events_available() lockless. BUG: KCSAN: data-race in do_epoll_wait / do_epoll_wait write to 0xffff88810480c7d8 of 8 bytes by task 1802 on cpu 0: INIT_LIST_HEAD include/linux/list.h:38 [inline] list_splice_init include/linux/list.h:492 [inline] ep_start_scan fs/eventpoll.c:622 [inline] ep_send_events fs/eventpoll.c:1656 [inline] ep_poll fs/eventpoll.c:1806 [inline] do_epoll_wait+0x4eb/0xf40 fs/eventpoll.c:2234 do_epoll_pwait fs/eventpoll.c:2268 [inline] __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline] __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275 __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae read to 0xffff88810480c7d8 of 8 bytes by task 1799 on cpu 1: list_empty_careful include/linux/list.h:329 [inline] ep_events_available fs/eventpoll.c:381 [inline] ep_poll fs/eventpoll.c:1797 [inline] do_epoll_wait+0x279/0xf40 fs/eventpoll.c:2234 do_epoll_pwait fs/eventpoll.c:2268 [inline] __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline] __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275 __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae value changed: 0xffff88810480c7d0 -> 0xffff888103c15098 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 1799 Comm: syz-fuzzer Tainted:
    G W 5.17.0-rc7-syzkaller-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 (CVE-2022-49443)

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

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且供應商未提供可用的修補程式。

  - 在 Linux 核心中，已解決下列弱點： can: isotp: sanitize CAN ID checks in isotp_bind() Syzbot created an environment that lead to a state machine status that can not be reached with a compliant CAN ID address configuration. The provided address information consisted of CAN ID 0x6000001 and 0xC28001 which both boil down to 11 bit CAN IDs 0x001 in sending and receiving. Sanitize the SFF/EFF CAN ID values before performing the address checks. (CVE-2022-49269)

請注意，Nessus 依賴供應商報告的套件存在。

遠端 MiracleLinux 9 主機已安裝受到多個弱點影響的套件如 AXSA:2025-11493:94 公告中所提及。

    * 核心：can：isotp：修正 isotp_rcv() 中潛在的 CAN 框架接收爭用 (CVE-2022-48830)
      * 核心：soc：qcom：cmd-db：將共用記憶體對應為 WC，而非 WB (CVE-2024-46689)
      * 核心：Squashfs：功能健全檢查符號連結大小(CVE-2024-46744)
      * 核心：vfs：修正 evice_inodes() 和 find_inode()&iput() 之間的爭用 (CVE-2024-47679)
      * 核心：x86/tdx：修正核心內 MMIO 檢查 (CVE-2024-47727)
      * 核心：rxrpc：修正通訊端設定和 I/O 執行緒建立之間的爭用 (CVE-2024-49864)
      * 核心：io_uring：檢查溢位排清期間是否需要重新排程 (CVE-2024-50060)
      * 核心：can：m_can：pci：在 probe/remove 方法中新增遺漏的 m_can_class_free_dev() (CVE-2022-49024)
      * 核心：posix-clock：修正 pc_clock_settime() 中遺漏的 timespec64 檢查 (CVE-2024-50195)
      * 核心：rxrpc：修正造成呼叫懸置的遺漏鎖定 (CVE-2024-50294)
      * 核心：io_uring/rw：修正 O_DIRECT 開始寫入中遺漏的 NOWAIT 檢查 (CVE-2024-53052)
      * 核心：afs：修正鎖定遞迴 (CVE-2024-53090)
      * 核心：virtio/vsock：修正 accept_queue 記憶體洩漏 (CVE-2024-53119)
      * 核心：KVM：VMX：將 Intel PT 虛擬化 (訪客/主機模式) 隱藏在 CONFIG_BROKEN 之後 (CVE-2024-53135)
      * 核心: xen: Xen hypercall 頁面未對推測性攻擊提供保護 (Xen 安全公告 466) (CVE-2024-53241)
      * 核心：RDMA/rxe：修正 req 中的 qp 排清警告 (CVE-2024-53229)
      * 核心：block：修正 uaf 以便在迭代標籤時排清 rq (CVE-2024-53170)
      * 核心：nfsd：使用 rcu_work 發布 svc_expkey/svc_export (CVE-2024-53216)
      * 核心：net：af_can：不在 can_create() 中遺留懸置 sk 指標 (CVE-2024-56603)
      * 核心：blk-cgroup：修正 blkcg_unpin_online() 中的 UAF 問題 (CVE-2024-56672)
      * 核心：acpi：nfit：acpi_nfit_ctl 中的 vmalloc-out-of-bounds 讀取 (CVE-2024-56662)
      * 核心：bpf：透過錯誤匹配 bpf_prog/attachment RCU flavors 修正 UAF (CVE-2024-56675)
      * 核心：can：j1939: j1939_session_new()：修正 skb 參照計數 (CVE-2024-56645)
      * 核心：crypto：pcrypt - 當 padata_do_parallel() 傳回 -EBUSY 時直接呼叫 crypto 層(CVE-2024-56690)
      * 核心：io_uring：檢查 iowq 在佇列前是否已刪除 (CVE-2024-56709)
      * 核心：rtc：檢查 rtc_timer_do_work() 中的 __rtc_read_time 是否成功(CVE-2024-56739)
      * 核心：bpf：當可以安全解除配置連結時，放置 bpf_link 的程式 (CVE-2024-56786)
      * 核心：igb：修正 igb_init_module() 中潛在的無效記憶體存取 (CVE-2024-52332)
      * 核心：ipvs：修正 ip_vs_protocol_init() 中未初始化堆疊存取所導致的 UB (CVE-2024-53680)
      * 核心：netfilter：conntrack：將雜湊表大小上限限制為 INT_MAX(CVE-2025-21648)
      * 核心：sched：sch_cake：將邊界檢查新增至主機大量流量公平計數(CVE-2025-21647)
      * 核心：block、bfq：修復 bfq_split_bfqq() 後的 waker_bfqq UAF 問題(CVE-2025-21631)
      * 核心：zram：修復 zram 表格潛在的 UAF 問題 (CVE-2025-21671)
      * 核心：afs：修正合併偏好設定規則失敗情況 (CVE-2025-21672)
      * 核心：mm：zswap：CPU hotunplug 期間正確同步釋放資源 (CVE-2025-21693)
      * 核心：cachestat：修正頁面快取統計資料權限檢查 (CVE-2025-21691)
      * 核心：mm：清除 mremap() 上的 uffd-wp PTE/PMD 狀態 (CVE-2025-21696)
      * 核心：pfifo_tail_enqueue：：當 sch->limit == 0 時放置新封包 (CVE-2025-21702)
      * 核心：usbnet：修正錯誤情況下的記憶體流失 (CVE-2022-49657)
      * 核心：powerpc/xics：修正 icp_opal_init() 中的 refcount 洩漏 (CVE-2022-49432)
      * 核心：net：tun：在損毀時取消 NAPI 與裝置的連結 (CVE-2022-49672)
      * 核心：powerpc/papr_scm：不使用 '0' 大小的統計資料緩衝區要求統計資料 (CVE-2022-49353)
      * 核心：powerpc/xive：修正 xive_spapr_init 中的 refcount 洩漏 (CVE-2022-49437)
      * 核心：ima：修正 ima_init_crypto() 中的潛在記憶體洩漏 (CVE-2022-49627)
      * 核心：linux/dim：修正 RDMA DIM 中的除以零錯誤 (CVE-2022-49670)
      * 核心：can：isotp：清理 isotp_bind() 中的 CAN ID 檢查 (CVE-2022-49269)
      * 核心：ima：修正 ima_appraise_measurement 中的潛在整數溢位 (CVE-2022-49643)
      * 核心：powerpc/xive/spapr：更正點陣圖配置大小 (CVE-2022-49623)
      * 核心：efi：不針對 T2 Macs 從 UEFI Secure Boot 匯入憑證 (CVE-2022-49357)
      * 核心：list：修正有關 ep->rdllist 的資料爭用 (CVE-2022-49443)
      * 核心：tracing/histograms：修正記憶體洩漏問題 (CVE-2022-49648)
      * 核心：Input：synaptics - 修正啟用 Pass-Through 連接埠時發生的當機 (CVE-2025-21746)
      * 核心：NFSD：修正 nfsd4_shutdown_callback 中的懸置 (CVE-2025-21795)
      * 核心：bpf：如果是 !preemptible，則以非同步方式傳送訊號 (CVE-2025-21728)
      * 核心：NFS：修正 nfs_sysfs_link_rpc_client() 中的潛在緩衝區溢位 (CVE-2024-54456)
      * 核心：Bluetooth：btrtl：檢查 btrtl_setup_realtek() 中的 NULL (CVE-2024-57987)
      * 核心：wifi: brcmsmac: 將增益範圍檢查新增至 wlc_phy_iqcal_gainparams_nphy() (CVE-2024-58014)
      * 核心：Bluetooth：btbcm：修正 btbcm_get_board_name() 中的 NULL 解除參照 (CVE-2024-57988)
      * 核心：RDMA/mlx5：修正隱含的 ODP 釋放後使用 (CVE-2025-21714)
      * 核心：drm/xe/tracing：修正潛在的 TP_printk UAF (CVE-2024-49570)
      * 核心：HID：hid-thrustmaster：透過新增端點檢查來修正 torquemaster_probe 中的警告 (CVE-2024-57993)
      * 核心：wifi：rtw89：修正 cancel_hw_scan 和 hw_scan 完成之間的爭用 (CVE-2025-21729)
      * 核心：wifi：mt76：mt7925：修正 mt7925_change_vif_links 中的 NULL 解除參照檢查 (CVE-2024-57989)
      * 核心：wifi: ath12k：對於超出邊界存取錯誤的修正 (CVE-2024-58015)
      * 核心：OPP：新增要宣告的索引檢查，避免 _read_freq() 中發生緩衝區溢位 (CVE-2024-57998)
      * 核心：wifi：ath12k：修正 ath12k_mac_assign_vif_to_vdev() 中的釋放後讀取指標 (CVE-2024-57995)
      * 核心：nfsd：釋放 acl_access/acl_default 後予以清除 (CVE-2025-21796)
      * 核心：scsi：ufs：core：修正 init 錯誤中的釋放後使用並移除路徑 (CVE-2025-21739)
      * 核心：workqueue：將集區與 rescuer 分開後放置 pwq (CVE-2025-21786)
      * 核心：ata：libata-sff：確保我們無法在配置的緩衝區之外寫入 (CVE-2025-21738)
      * 核心：HID: core: 修復解析乘數必須位於邏輯集合中的假設 (CVE-2024-57986)
      * 核心：padata：避免 reorder_work 的 UAF (CVE-2025-21726)
      * 核心：vrf：在 l3mdev_l3_out() 中使用 RCU 保護 (CVE-2025-21791)
      * 核心：team：改善 TEAM_OPTION_TYPE_STRING 驗證 (CVE-2025-21787)
      * 核心：usb: xhci: 修復中止特定命令期間的 NULL 指標解除參照 (CVE-2024-57981)
      * 核心：vxlan：檢查 vxlan_vnigroup_init() 傳回值 (CVE-2025-21790)
      * 核心：wifi：mt76：mt7925：修正 mt7925_load_clc() 中的差一問題 (CVE-2024-57990)
      * 核心：ipv6：在 ip6_default_advmss() 中使用 RCU 保護 (CVE-2025-21765)
      * 核心：ASoC：SOF：Intel：hda-dai：確保 DAI Widget 在參數執行期間有效 (CVE-2024-58012)
      * 核心：blk-cgroup: 修復類別 @block_class 的子系統 refcount 洩漏問題 (CVE-2025-21745)
      * 核心：net: 讓 net.core.dev_weight 始終保持為非零 (CVE-2025-21806)
      * 核心：wifi：rtlwifi：移除未使用的 check_buddy_priv (CVE-2024-58072)
      * 核心：OPP：修正頻寬表未初始化時的 dev_pm_opp_find_bw_*() (CVE-2024-58068)
      * 核心：wifi：iwlwifi：mvm：避免 Null 指標解除參照問題 (CVE-2024-58062)
      * 核心：idpf：將工作佇列轉換為未繫結 (CVE-2024-58057)
      * 核心：wifi：mac80211：不清除未上傳的 STA (CVE-2025-21828)
      * 核心：KVM：明確驗證目標 vCPU 已經在 kvm_get_vcpu() 上線 (CVE-2024-58083)
      * 核心：netfilter：nf_tables：拒絕包含設定金鑰長度的 field_len 不相符的總和 (CVE-2025-21826)
      * 核心：ASoC：soc-pcm：不要在 .prepare 回呼時使用 soc_pcm_ret() (CVE-2024-58077)
      * 核心：crypto：不在 tegra init 失敗時傳輸 req (CVE-2024-58075)
      * 核心：RDMA/rxe：修正警告 __rxe_cleanup+0x12c/0x170 [rdma_rxe] (CVE-2025-21829)
      * 核心：KVM：x86：在進入 .vcpu_run() 迴圈之前，僅以訪客值載入 DR6 (CVE-2025-21839)
      * 核心：io_uring/uring_cmd：在準備階段無條件複製 SQE (CVE-2025-21837)
      * 核心：透過某些 AMD 處理器中的瞬態執行弱點造成資訊洩漏 (CVE-2024-36350)
      * 核心：某些 AMD 處理器中的瞬態執行弱點 (CVE-2024-36357)
      * 核心：bpf：修正 64k 頁面核心上 arena_map_free 中的 softlockup (CVE-2025-21851)
      * 核心：ibmvnic：傳送至 VIOS 後不參照 skb (CVE-2025-21855)
      * 核心：smb：client：在 receive_encrypted_standard() 中新增 next_buffer 檢查 (CVE-2025-21844)
      * 核心：bpf：避免在 mmap 作業期間持有 freeze_mutex (CVE-2025-21853)
      * 核心：ASoC：SOF：stream-ipc：檢查 sof_ipc_msg_data() 中的 cstream 無效性 (CVE-2025-21847)
      * 核心：tcp：在我們目前放置 dst 的同時放置 secpath (CVE-2025-21864)
      * 核心：bpf：修正釋放 cgroup 儲存空間時的鎖死問題 (CVE-2024-58088)
      * 核心：acct：從工作佇列執行上次寫入 (CVE-2025-21846)
      * 核心：mm/migrate_device：不要在 migrate_device_finalize() 中新增釋放至 LRU 的 folio (CVE-2025-21861)
      * 核心：io_uring：防止 opcode 推測 (CVE-2025-21863)
      * 核心：nfp：bpf：新增 nfp_app_ctrl_msg_alloc() 的檢查 (CVE-2025-21848)
      * 核心：netfilter：nft_tunnel：修正 geneve_opt 類型混淆新增 (CVE-2025-22056)
      * 核心：can：j1939：j1939_send_one()：修正缺少的 CAN 標頭初始化 (CVE-2022-49845)
      * 核心：usb：typec：ucsi：displayport：修正 NULL 指標存取 (CVE-2025-37994)
      * 核心：wifi: ath12k：修正 ath12k_core_init() 中的 uaf (CVE-2025-38116)
      * 核心：fs：匯出 anon_inode_make_secure_inode() 並修正 secretmem LSM 繞過 (CVE-2025-38396)

Tenable 已直接從 MiracleLinux 安全性公告擷取前置描述區塊。

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

AlmaLinux 9.6 主機已安裝的套件會受到 TuxCare ALMALINUX9.6：CLSA-2026：1783091784 公告中提及的多個弱點影響。

  - 已解決 Linux 核心中的下列弱點：net: bcmgenet: Use stronger register read/writes to assure ordering GCC12 appears to be much smarter about its dependency tracking and is aware that the relaxed variants are just normal loads and stores and this is causing problems like: [210.074549] ------------[ cut here ]------------ [ 210.079223] NETDEV WATCHDOG: enabcm6e4ei0 (bcmgenet):
    transmit queue 1 timed out [ 210.086717] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:529 dev_watchdog+0x234/0x240 [ 210.095044] Modules linked in: genet(E) nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat] [ 210.146561] ACPI CPPC: PCC check channel failed for ss: 0. ret=-110 [ 210.146927] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G E 5.17.0-rc7G12+ #58 [ 210.153226] CPPC Cpufreq:cppc_scale_freq_workfn: failed to read perf counters [210.161349] Hardware name: Raspberry Pi Foundation Raspberry Pi 4 Model B/Raspberry Pi 4 Model B, BIOS EDK2-DEV 02/08/2022 [ 210.161353] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [210.161358] pc : dev_watchdog+0x234/0x240 [ 210.161364] lr : dev_watchdog+0x234/0x240 [ 210.161368] sp :
    ffff8000080a3a40 [ 210.161370] x29: ffff8000080a3a40 x28: ffffcd425af87000 x27: ffff8000080a3b20 [210.205150] x26: ffffcd425aa00000 x25: 0000000000000001 x24: ffffcd425af8ec08 [ 210.212321] x23:
    0000000000000100 x22: ffffcd425af87000 x21: ffff55b142688000 [ 210.219491] x20: 0000000000000001 x19:
    ffff55b1426884c8 x18: ffffffffffffffff [ 210.226661] x17: 64656d6974203120 x16: 0000000000000001 x15:
    6d736e617274203a [ 210.233831] x14: 2974656e65676d63 x13: ffffcd4259c300d8 x12: ffffcd425b07d5f0 [210.241001] x11: 00000000ffffffff x10: ffffcd425b07d5f0 x9 : ffffcd4258bdad9c [ 210.248171] x8 :
    00000000ffffdfff x7 : 000000000000003f x6 : 0000000000000000 [ 210.255341] x5 : 0000000000000000 x4 :
    0000000000000000 x3 : 0000000000001000 [ 210.262511] x2 : 0000000000001000 x1 : 0000000000000005 x0 :
    0000000000000044 [ 210.269682] Call trace: [ 210.272133] dev_watchdog+0x234/0x240 [ 210.275811] call_timer_fn+0x3c/0x15c [ 210.279489] __run_timers.part.0+0x288/0x310 [ 210.283777] run_timer_softirq+0x48/0x80 [ 210.287716] __do_softirq+0x128/0x360 [ 210.291392]
    __irq_exit_rcu+0x138/0x140 [ 210.295243] irq_exit_rcu+0x1c/0x30 [ 210.298745] el1_interrupt+0x38/0x54 [210.302334] el1h_64_irq_handler+0x18/0x24 [ 210.306445] el1h_64_irq+0x7c/0x80 [ 210.309857] arch_cpu_idle+0x18/0x2c [ 210.313445] default_idle_call+0x4c/0x140 [ 210.317470] cpuidle_idle_call+0x14c/0x1a0 [ 210.321584] do_idle+0xb0/0x100 [ 210.324737] cpu_startup_entry+0x30/0x8c [210.328675] secondary_start_kernel+0xe4/0x110 [ 210.333138] __secondary_switched+0x94/0x98 The assumption when these were relaxed seems to be that device memory would be mapped non reordering, and that other constructs (spinlocks/etc) would provide the barriers to assure that packet data and in memory rings/queues were ordered with respect to device register reads/writes. This itself seems a bit sketchy, but the real problem with GCC12 is that it is moving the actual reads/writes around at will as though they were independent operations when in truth they are not, but the compiler can't know that. When looking at the assembly dumps for many of these routines its possible to see very clean, but not strictly in program order operations occurring as the compiler would be free to do if these weren't actually register reads/write operations. Its possible to suppress the timeout with a liberal bit of dma_mb()'s sprinkled around but the device still seems unable to reliably send/receive data. A better plan is to use the safer readl/writel everywhere. Since this partially reverts an older commit, which notes the use of the relaxed variants for performance reasons. I would suggest that any performance problems ---truncated--- (CVE-2022-49194)

  - 已解決 Linux 核心中的下列弱點：can: isotp: sanitize CAN ID checks in isotp_bind() Syzbot created an environment that lead to a state machine status that can not be reached with a compliant CAN ID address configuration. The provided address information consisted of CAN ID 0x6000001 and 0xC28001 which both boil down to 11 bit CAN IDs 0x001 in sending and receiving. Sanitize the SFF/EFF CAN ID values before performing the address checks. (CVE-2022-49269)

  - 已解決 Linux 核心中的下列弱點：net/smc: Reset connection when trying to use SMCRv2 fails. We found a crash when using SMCRv2 with 2 Mellanox ConnectX-4. It can be reproduced by: - smc_run nginx - smc_run wrk -t 32 -c 500 -d 30 http://<ip>:<port> BUG: kernel NULL pointer dereference, address: 0000000000000014 #PF: supervisor read access in kernel mode #PF: error_code(0x0000)
    - not-present page PGD 8000000108713067 P4D 8000000108713067 PUD 151127067 PMD 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 4 PID: 2441 Comm: kworker/4:249 Kdump: loaded Tainted: G W E 6.4.0-rc1+ #42 Workqueue:
    smc_hs_wq smc_listen_work [smc] RIP: 0010:smc_clc_send_confirm_accept+0x284/0x580 [smc] RSP:
    0018:ffffb8294b2d7c78 EFLAGS: 00010a06 RAX: ffff8f1873238880 RBX: ffffb8294b2d7dc8 RCX: 0000000000000000 RDX: 00000000000000b4 RSI: 0000000000000001 RDI: 0000000000b40c00 RBP: ffffb8294b2d7db8 R08:
    ffff8f1815c5860c R09: 0000000000000000 R10: 0000000000000400 R11: 0000000000000000 R12: ffff8f1846f56180 R13: ffff8f1815c5860c R14: 0000000000000001 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8f1aefd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2:
    0000000000000014 CR3: 00000001027a0001 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? mlx5_ib_map_mr_sg+0xa1/0xd0 [mlx5_ib] ? smcr_buf_map_link+0x24b/0x290 [smc] ?
    __smc_buf_create+0x4ee/0x9b0 [smc] smc_clc_send_accept+0x4c/0xb0 [smc] smc_listen_work+0x346/0x650 [smc] ?
    __schedule+0x279/0x820 process_one_work+0x1e5/0x3f0 worker_thread+0x4d/0x2f0 ?
    __pfx_worker_thread+0x10/0x10 kthread+0xe5/0x120 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2c/0x50 </TASK> During the CLC handshake, server sequentially tries available SMCRv2 and SMCRv1 devices in smc_listen_work(). If an SMCRv2 device is found. SMCv2 based link group and link will be assigned to the connection. Then assumed that some buffer assignment errors happen later in the CLC handshake, such as RMB registration failure, server will give up SMCRv2 and try SMCRv1 device instead. But the resources assigned to the connection won't be reset. When server tries SMCRv1 device, the connection creation process will be executed again. Since conn->lnk has been assigned when trying SMCRv2, it will not be set to the correct SMCRv1 link in smcr_lgr_conn_assign_link(). So in such situation, conn->lgr points to correct SMCRv1 link group but conn->lnk points to the SMCRv2 link mistakenly. Then in smc_clc_send_confirm_accept(), conn->rmb_desc->mr[link->link_idx] will be accessed. Since the link->link_idx is not correct, the related MR may not have been initialized, so crash happens. | Try SMCRv2 device first | |-> conn->lgr: assign existed SMCRv2 link group; | |-> conn->link: assign existed SMCRv2 link (link_idx may be 1 in SMC_LGR_SYMMETRIC); | |-> sndbuf & RMB creation fails, quit; | | Try SMCRv1 device then | |-> conn->lgr:
    create SMCRv1 link group and assign; | |-> conn->link: keep SMCRv2 link mistakenly; | |-> sndbuf & RMB creation succeed, only RMB->mr[link_idx = 0] | initialized. | | Then smc_clc_send_confirm_accept() accesses | conn->rmb_desc->mr[conn->link->link_idx, which is 1], then crash. v This patch tries to fix this by cleaning conn->lnk before assigning link. In addition, it is better to reset the connection and clean the resources assigned if trying SMCRv2 failed in buffer creation or registration. (CVE-2023-53382)

  - 已解決 Linux 核心中的下列弱點：RDMA/irdma: Cap MSIX used to online CPUs + 1 The irdma driver can use a maximum number of msix vectors equal to num_online_cpus() + 1 and the kernel warning stack below is shown if that number is exceeded. The kernel throws a warning as the driver tries to update the affinity hint with a CPU mask greater than the max CPU IDs. Fix this by capping the MSIX vectors to num_online_cpus() + 1. WARNING: CPU: 7 PID: 23655 at include/linux/cpumask.h:106 irdma_cfg_ceq_vector+0x34c/0x3f0 [irdma] RIP: 0010:irdma_cfg_ceq_vector+0x34c/0x3f0 [irdma] Call Trace:
    irdma_rt_init_hw+0xa62/0x1290 [irdma] ? irdma_alloc_local_mac_entry+0x1a0/0x1a0 [irdma] ?
    __is_kernel_percpu_address+0x63/0x310 ? rcu_read_lock_held_common+0xe/0xb0 ? irdma_lan_unregister_qset+0x280/0x280 [irdma] ? irdma_request_reset+0x80/0x80 [irdma] ? ice_get_qos_params+0x84/0x390 [ice] irdma_probe+0xa40/0xfc0 [irdma] ? rcu_read_lock_bh_held+0xd0/0xd0 ? irdma_remove+0x140/0x140 [irdma] ? rcu_read_lock_sched_held+0x62/0xe0 ? down_write+0x187/0x3d0 ? auxiliary_match_id+0xf0/0x1a0 ? irdma_remove+0x140/0x140 [irdma] auxiliary_bus_probe+0xa6/0x100
    __driver_probe_device+0x4a4/0xd50 ? __device_attach_driver+0x2c0/0x2c0 driver_probe_device+0x4a/0x110
    __driver_attach+0x1aa/0x350 bus_for_each_dev+0x11d/0x1b0 ? subsys_dev_iter_init+0xe0/0xe0 bus_add_driver+0x3b1/0x610 driver_register+0x18e/0x410 ? 0xffffffffc0b88000 irdma_init_module+0x50/0xaa [irdma] do_one_initcall+0x103/0x5f0 ? perf_trace_initcall_level+0x420/0x420 ? do_init_module+0x4e/0x700 ?
    __kasan_kmalloc+0x7d/0xa0 ? kmem_cache_alloc_trace+0x188/0x2b0 ? kasan_unpoison+0x21/0x50 do_init_module+0x1d1/0x700 load_module+0x3867/0x5260 ? layout_and_allocate+0x3990/0x3990 ? rcu_read_lock_held_common+0xe/0xb0 ? rcu_read_lock_sched_held+0x62/0xe0 ? rcu_read_lock_bh_held+0xd0/0xd0 ? __vmalloc_node_range+0x46b/0x890 ? lock_release+0x5c8/0xba0 ? alloc_vm_area+0x120/0x120 ? selinux_kernel_module_from_file+0x2a5/0x300 ? __inode_security_revalidate+0xf0/0xf0 ?
    __do_sys_init_module+0x1db/0x260 __do_sys_init_module+0x1db/0x260 ? load_module+0x5260/0x5260 ? do_syscall_64+0x22/0x450 do_syscall_64+0xa5/0x450 entry_SYSCALL_64_after_hwframe+0x66/0xdb (CVE-2023-53811)

  - 已解決 Linux 核心中的下列弱點：i2c: smbus: fix NULL function pointer dereference Baruch reported an OOPS when using the designware controller as target only. Target-only modes break the assumption of one transfer function always being available. Fix this by always checking the pointer in __i2c_transfer. [wsa: dropped the simplification in core-smbus to avoid theoretical regressions] (CVE-2024-35984)

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

ID	名稱	產品	系列	已發布	已更新	嚴重性
360066	Rocky Linux 9.6 [TuxCare] 安全性更新：kernel / kernel-abi-stablelists / kernel-core / etc 多個漏洞（ALMALINUX9.6：CLSA-2026：1783091784）	Nessus	Rocky Linux Local Security Checks	2026/10/1	2026/10/1	medium
233298	CentOS 9: kernel-5.14.0-573.el9	Nessus	CentOS Local Security Checks	2025/3/24	2025/3/24	high
274839	RHEL 9：核心 (RHSA-2025:20518)	Nessus	Red Hat Local Security Checks	2025/11/12	2025/11/17	high
275824	AlmaLinux 9核心 (ALSA-2025:20518)	Nessus	Alma Linux Local Security Checks	2025/11/19	2026/3/12	high
276689	Oracle Linux 9 ELSA-2025-20518-0: / kernel (ELSA-2025-205180)	Nessus	Oracle Linux Local Security Checks	2025/11/25	2026/3/6	high
357988	Rocky Linux 9 [CIQ] 安全性更新：kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc 多個弱點（crlsa-2025_20518）	Nessus	Rocky Linux Local Security Checks	2026/10/1	2026/10/1	high
277164	RockyLinux 9核心 (RLSA-2025:20518)	Nessus	Rocky Linux Local Security Checks	2025/12/3	2026/2/27	high
352871	AlmaLinux 9.2 [TuxCare] 安全性更新：bpftool / kernel / kernel-abi-stablelists / kernel-core / etc 多個弱點（ALMALINUX9.2：CLSA-2026：1783791447）	Nessus	Alma Linux Local Security Checks	2026/9/30	2026/10/1	medium
225403	Linux Distros 未修補弱點：CVE-2022-49269	Nessus	Misc.	2025/3/5	2026/7/17	medium
282807	MiracleLinux 9kernel-5.14.0-611.5.1.el9_7 (AXSA:2025-11493:94)	Nessus	Miracle Linux Local Security Checks	2026/1/13	2026/2/16	high
360243	AlmaLinux 9.6 [TuxCare] 安全性更新：kernel / kernel-abi-stablelists / kernel-core / etc 多個弱點（ALMALINUX9.6：CLSA-2026：1783091784）	Nessus	Alma Linux Local Security Checks	2026/10/1	2026/10/1	medium

偵測

搜尋 Plugin

medium

high

high

high

high

high

high

medium

medium

high

medium