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

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

    安全性修正：

    * 核心：cxgb4：避免在清除篩選器時存取暫存器 (CVE-2021-47138)

    * 核心：hv_netvsc：修復 netvsc_probe 和 netvsc_remove 之間的爭用情形 (CVE-2024-26698)

    * 核心：mm/slub：修正可在 kmalloc() 失敗時傳回 errno (CVE-2022-48659)

    * 核心：檢查 inode 編號是否為無效的零值 CVE-2024-26982

    * 核心：vt：修正刪除字元時發生 unicode 緩衝區損毀 (CVE-2024-35823)

    * 核心：nvme-rdma：在損毀 qp 之前損毀 cm id 以避免使用已釋放記憶體 (CVE-2021-47378)

    * 核心：userfaultfd：修正 writeprotect 和 exit_mmap() 之間的爭用問題 (CVE-2021-47461)

    * 核心：r8169：修復片段化 Tx 封包上可能發生的環緩衝區損毀。(CVE-2024-38586)

    * 核心：bpf：在 BPF_LINK_CREATE 中新增 BPF_PROG_TYPE_CGROUP_SKB 附加類型強制 (CVE-2024-38564)

    * 核心：bnxt_re：避免移位 bnxt_qplib_alloc_init_hwq 中的未定義行為 (CVE-2024-38540)

    * kernel：iommu：修正探查期間可能發生的釋放後使用問題 (CVE-2022-48796)

    * 核心：xfs：將邊界檢查新增至 xlog_recover_process_data (CVE-2024-41014)

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

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

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

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

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

    安全性修正：

    * kernel：blk-mq：修復 sbitmap 喚醒爭用的 IO 懸置問題 (CVE-2024-26671)

    * kernel：iommu：修正探查期間可能發生的釋放後使用問題 (CVE-2022-48796)

    * kernel：mptcp：pm：修正 __timer_delete_sync 中的 uaf (CVE-2024-46858)

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

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

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

CentOS Linux 8.5 主機已安裝的套件會受到 TuxCare CENTOS8.5：CLSA-2024：1725876080 公告中提及的多個弱點影響。

  - 已解決 Linux 核心中的下列弱點：tracing: Restructure trace_clock_global() to never block It was reported that a fix to the ring buffer recursion detection would cause a hung machine when performing suspend / resume testing. The following backtrace was extracted from debugging that case: Call Trace: trace_clock_global+0x91/0xa0 __rb_reserve_next+0x237/0x460 ring_buffer_lock_reserve+0x12a/0x3f0 trace_buffer_lock_reserve+0x10/0x50 __trace_graph_return+0x1f/0x80 trace_graph_return+0xb7/0xf0 ? trace_clock_global+0x91/0xa0 ftrace_return_to_handler+0x8b/0xf0 ? pv_hash+0xa0/0xa0 return_to_handler+0x15/0x30 ? ftrace_graph_caller+0xa0/0xa0 ? trace_clock_global+0x91/0xa0 ? __rb_reserve_next+0x237/0x460 ? ring_buffer_lock_reserve+0x12a/0x3f0 ? trace_event_buffer_lock_reserve+0x3c/0x120 ? trace_event_buffer_reserve+0x6b/0xc0 ? trace_event_raw_event_device_pm_callback_start+0x125/0x2d0 ? dpm_run_callback+0x3b/0xc0 ? pm_ops_is_empty+0x50/0x50 ? platform_get_irq_byname_optional+0x90/0x90 ? trace_device_pm_callback_start+0x82/0xd0 ? dpm_run_callback+0x49/0xc0 With the following RIP: RIP:
    0010:native_queued_spin_lock_slowpath+0x69/0x200 Since the fix to the recursion detection would allow a single recursion to happen while tracing, this lead to the trace_clock_global() taking a spin lock and then trying to take it again: ring_buffer_lock_reserve() { trace_clock_global() { arch_spin_lock() {queued_spin_lock_slowpath() { /* lock taken */ (something else gets traced by function graph tracer) ring_buffer_lock_reserve() { trace_clock_global() { arch_spin_lock() { queued_spin_lock_slowpath() { /* DEAD LOCK! */ Tracing should *never* block, as it can lead to strange lockups like the above. Restructure the trace_clock_global() code to instead of simply taking a lock to update the recorded prev_time simply use it, as two events happening on two different CPUs that calls this at the same time, really doesn't matter which one goes first. Use a trylock to grab the lock for updating the prev_time, and if it fails, simply try again the next time. If it failed to be taken, that means something else is already updating it. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=212761 (CVE-2021-46939)

  - 已解決 Linux 核心中的下列弱點：userfaultfd: fix a race between writeprotect and exit_mmap() A race is possible when a process exits, its VMAs are removed by exit_mmap() and at the same time userfaultfd_writeprotect() is called. The race was detected by KASAN on a development kernel, but it appears to be possible on vanilla kernels as well. Use mmget_not_zero() to prevent the race as done in other userfaultfd operations. (CVE-2021-47461)

  - 已解決 Linux 核心中的下列弱點：net: amd-xgbe: Fix skb data length underflow There will be BUG_ON() triggered in include/linux/skbuff.h leading to intermittent kernel panic, when the skb length underflow is detected. Fix this by dropping the packet if such length underflows are seen because of inconsistencies in the hardware descriptors. (CVE-2022-48743)

  - 已解決 Linux 核心中的下列弱點：nvme-rdma: fix possible use-after-free in transport error_recovery work While nvme_rdma_submit_async_event_work is checking the ctrl and queue state before preparing the AER command and scheduling io_work, in order to fully prevent a race where this check is not reliable the error recovery work must flush async_event_work before continuing to destroy the admin queue after setting the ctrl state to RESETTING such that there is no race .submit_async_event and the error recovery handler itself changing the ctrl state. (CVE-2022-48788)

  - 已解決 Linux 核心中的下列弱點：nvme-tcp: fix possible use-after-free in transport error_recovery work While nvme_tcp_submit_async_event_work is checking the ctrl and queue state before preparing the AER command and scheduling io_work, in order to fully prevent a race where this check is not reliable the error recovery work must flush async_event_work before continuing to destroy the admin queue after setting the ctrl state to RESETTING such that there is no race .submit_async_event and the error recovery handler itself changing the ctrl state. (CVE-2022-48789)

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

Rocky Linux 8.6 主機上安裝的多個套件受到 CIQ ciqsa-2026_0871 公告中提及的多個弱點影響。

    此公告彙總了 CIQ LTS 8.6中核心 SRPM 的安全修正。它解決了 28 個 CVE：
    CVE-2025-21919、CVE-2022-50020、CVE-2022-48796、CVE-2022-49114CVE-2024-46858、 和 23 個。

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

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

CentOS Linux 8.4 主機安裝的套件會受到 TuxCare CENTOS8.4：CLSA-2024：1725872696 公告中提及的多個弱點影響。

  - 已解決 Linux 核心中的下列弱點：tracing: Restructure trace_clock_global() to never block It was reported that a fix to the ring buffer recursion detection would cause a hung machine when performing suspend / resume testing. The following backtrace was extracted from debugging that case: Call Trace: trace_clock_global+0x91/0xa0 __rb_reserve_next+0x237/0x460 ring_buffer_lock_reserve+0x12a/0x3f0 trace_buffer_lock_reserve+0x10/0x50 __trace_graph_return+0x1f/0x80 trace_graph_return+0xb7/0xf0 ? trace_clock_global+0x91/0xa0 ftrace_return_to_handler+0x8b/0xf0 ? pv_hash+0xa0/0xa0 return_to_handler+0x15/0x30 ? ftrace_graph_caller+0xa0/0xa0 ? trace_clock_global+0x91/0xa0 ? __rb_reserve_next+0x237/0x460 ? ring_buffer_lock_reserve+0x12a/0x3f0 ? trace_event_buffer_lock_reserve+0x3c/0x120 ? trace_event_buffer_reserve+0x6b/0xc0 ? trace_event_raw_event_device_pm_callback_start+0x125/0x2d0 ? dpm_run_callback+0x3b/0xc0 ? pm_ops_is_empty+0x50/0x50 ? platform_get_irq_byname_optional+0x90/0x90 ? trace_device_pm_callback_start+0x82/0xd0 ? dpm_run_callback+0x49/0xc0 With the following RIP: RIP:
    0010:native_queued_spin_lock_slowpath+0x69/0x200 Since the fix to the recursion detection would allow a single recursion to happen while tracing, this lead to the trace_clock_global() taking a spin lock and then trying to take it again: ring_buffer_lock_reserve() { trace_clock_global() { arch_spin_lock() {queued_spin_lock_slowpath() { /* lock taken */ (something else gets traced by function graph tracer) ring_buffer_lock_reserve() { trace_clock_global() { arch_spin_lock() { queued_spin_lock_slowpath() { /* DEAD LOCK! */ Tracing should *never* block, as it can lead to strange lockups like the above. Restructure the trace_clock_global() code to instead of simply taking a lock to update the recorded prev_time simply use it, as two events happening on two different CPUs that calls this at the same time, really doesn't matter which one goes first. Use a trylock to grab the lock for updating the prev_time, and if it fails, simply try again the next time. If it failed to be taken, that means something else is already updating it. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=212761 (CVE-2021-46939)

  - 已解決 Linux 核心中的下列弱點：net: amd-xgbe: Fix skb data length underflow There will be BUG_ON() triggered in include/linux/skbuff.h leading to intermittent kernel panic, when the skb length underflow is detected. Fix this by dropping the packet if such length underflows are seen because of inconsistencies in the hardware descriptors. (CVE-2022-48743)

  - 已解決 Linux 核心中的下列弱點：nvme-rdma: fix possible use-after-free in transport error_recovery work While nvme_rdma_submit_async_event_work is checking the ctrl and queue state before preparing the AER command and scheduling io_work, in order to fully prevent a race where this check is not reliable the error recovery work must flush async_event_work before continuing to destroy the admin queue after setting the ctrl state to RESETTING such that there is no race .submit_async_event and the error recovery handler itself changing the ctrl state. (CVE-2022-48788)

  - 已解決 Linux 核心中的下列弱點：nvme-tcp: fix possible use-after-free in transport error_recovery work While nvme_tcp_submit_async_event_work is checking the ctrl and queue state before preparing the AER command and scheduling io_work, in order to fully prevent a race where this check is not reliable the error recovery work must flush async_event_work before continuing to destroy the admin queue after setting the ctrl state to RESETTING such that there is no race .submit_async_event and the error recovery handler itself changing the ctrl state. (CVE-2022-48789)

  - 已解決 Linux 核心中的下列弱點：nvme: fix a possible use-after-free in controller reset during load Unlike .queue_rq, in .submit_async_event drivers may not check the ctrl readiness for AER submission. This may lead to a use-after-free condition that was observed with nvme-tcp.
    The race condition may happen in the following scenario: 1. driver executes its reset_ctrl_work 2. -> nvme_stop_ctrl - flushes ctrl async_event_work 3. ctrl sends AEN which is received by the host, which in turn schedules AEN handling 4. teardown admin queue (which releases the queue socket) 5. AEN processed, submits another AER, calling the driver to submit 6. driver attempts to send the cmd ==> use-after-free In order to fix that, add ctrl state check to validate the ctrl is actually able to accept the AER submission. This addresses the above race in controller resets because the driver during teardown should:
    1. change ctrl state to RESETTING 2. flush async_event_work (as well as other async work elements) So after 1,2, any other AER command will find the ctrl state to be RESETTING and bail out without submitting the AER. (CVE-2022-48790)

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

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

    kernel-rt 套件提供即時 Linux 核心，其可針對具有極高決定機制需求的系統啟用微調。

    安全性修正：

    * kernel：blk-mq：修復 sbitmap 喚醒爭用的 IO 懸置問題 (CVE-2024-26671)

    * kernel：iommu：修正探查期間可能發生的釋放後使用問題 (CVE-2022-48796)

    * kernel：mptcp：pm：修正 __timer_delete_sync 中的 uaf (CVE-2024-46858)

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

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

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

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

  - 在 Linux 核心中，已解決下列弱點： iommu: Fix potential use-after-free during probe Kasan has reported the following use after free on dev->iommu. when a device probe fails and it is in process of freeing dev->iommu in dev_iommu_free function, a deferred_probe_work_func runs in parallel and tries to access dev->iommu->fwspec in of_iommu_configure path thus causing use after free.
    BUG: KASAN: use-after-free in of_iommu_configure+0xb4/0x4a4 Read of size 8 at addr ffffff87a2f1acb8 by task kworker/u16:2/153 Workqueue: events_unbound deferred_probe_work_func Call trace:
    dump_backtrace+0x0/0x33c show_stack+0x18/0x24 dump_stack_lvl+0x16c/0x1e0 print_address_description+0x84/0x39c __kasan_report+0x184/0x308 kasan_report+0x50/0x78
    __asan_load8+0xc0/0xc4 of_iommu_configure+0xb4/0x4a4 of_dma_configure_id+0x2fc/0x4d4 platform_dma_configure+0x40/0x5c really_probe+0x1b4/0xb74 driver_probe_device+0x11c/0x228
    __device_attach_driver+0x14c/0x304 bus_for_each_drv+0x124/0x1b0 __device_attach+0x25c/0x334 device_initial_probe+0x24/0x34 bus_probe_device+0x78/0x134 deferred_probe_work_func+0x130/0x1a8 process_one_work+0x4c8/0x970 worker_thread+0x5c8/0xaec kthread+0x1f8/0x220 ret_from_fork+0x10/0x18 Allocated by task 1: ____kasan_kmalloc+0xd4/0x114 __kasan_kmalloc+0x10/0x1c kmem_cache_alloc_trace+0xe4/0x3d4 __iommu_probe_device+0x90/0x394 probe_iommu_group+0x70/0x9c bus_for_each_dev+0x11c/0x19c bus_iommu_probe+0xb8/0x7d4 bus_set_iommu+0xcc/0x13c arm_smmu_bus_init+0x44/0x130 [arm_smmu] arm_smmu_device_probe+0xb88/0xc54 [arm_smmu] platform_drv_probe+0xe4/0x13c really_probe+0x2c8/0xb74 driver_probe_device+0x11c/0x228 device_driver_attach+0xf0/0x16c __driver_attach+0x80/0x320 bus_for_each_dev+0x11c/0x19c driver_attach+0x38/0x48 bus_add_driver+0x1dc/0x3a4 driver_register+0x18c/0x244
    __platform_driver_register+0x88/0x9c init_module+0x64/0xff4 [arm_smmu] do_one_initcall+0x17c/0x2f0 do_init_module+0xe8/0x378 load_module+0x3f80/0x4a40 __se_sys_finit_module+0x1a0/0x1e4
    __arm64_sys_finit_module+0x44/0x58 el0_svc_common+0x100/0x264 do_el0_svc+0x38/0xa4 el0_svc+0x20/0x30 el0_sync_handler+0x68/0xac el0_sync+0x160/0x180 Freed by task 1: kasan_set_track+0x4c/0x84 kasan_set_free_info+0x28/0x4c ____kasan_slab_free+0x120/0x15c __kasan_slab_free+0x18/0x28 slab_free_freelist_hook+0x204/0x2fc kfree+0xfc/0x3a4 __iommu_probe_device+0x284/0x394 probe_iommu_group+0x70/0x9c bus_for_each_dev+0x11c/0x19c bus_iommu_probe+0xb8/0x7d4 bus_set_iommu+0xcc/0x13c arm_smmu_bus_init+0x44/0x130 [arm_smmu] arm_smmu_device_probe+0xb88/0xc54 [arm_smmu] platform_drv_probe+0xe4/0x13c really_probe+0x2c8/0xb74 driver_probe_device+0x11c/0x228 device_driver_attach+0xf0/0x16c __driver_attach+0x80/0x320 bus_for_each_dev+0x11c/0x19c driver_attach+0x38/0x48 bus_add_driver+0x1dc/0x3a4 driver_register+0x18c/0x244
    __platform_driver_register+0x88/0x9c init_module+0x64/0xff4 [arm_smmu] do_one_initcall+0x17c/0x2f0 do_init_module+0xe8/0x378 load_module+0x3f80/0x4a40 __se_sys_finit_module+0x1a0/0x1e4
    __arm64_sys_finit_module+0x44/0x58 el0_svc_common+0x100/0x264 do_el0_svc+0x38/0xa4 el0_svc+0x20/0x30 el0_sync_handler+0x68/0xac el0_sync+0x160/0x180 Fix this by setting dev->iommu to NULL first and then freeing dev_iommu structure in dev_iommu_free function. (CVE-2022-48796)

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

遠端主機上安裝的核心版本早於 5.10.102-99.473。因此，會受到 ALAS2KERNEL-5.10-2022-011 公告中所提及的多個弱點影響。

    AMD 建議針對此問題使用軟體緩解措施，該問題預設啟用核心。Linux 核心將在 AMD 執行個體 (*5a*) 上使用一般的 retpoline 軟體緩解措施，而非專門的 AMD 緩解措施。這是預設動作，不需要管理員動作。(CVE-2021-26341)

    AMD 建議針對此問題使用軟體緩解措施，該問題預設啟用核心。Linux 核心將在 AMD 執行個體 (*5a*) 上使用一般的 retpoline 軟體緩解措施，而非專門的 AMD 緩解措施。這是預設動作，不需要管理員動作。(CVE-2021-26401)

    在 Linux 核心的控制群組和命名空間子系統中，發現無權限的檔案處理程式寫入缺陷，導致使用者可存取某些受 cgroups 控制且提高特權父項處理程序的低權限處理程序。此缺陷實際上會影響控制群組的 cgroup2 和 cgroup1 版本。本機使用者可利用此瑕疵來損毀系統或提高自己的系統權限。(CVE-2021-4197)

    在 Linux 核心中，下列弱點已解決：

    PCI：pciehp：修正電源錯誤時 IRQ 處置程式中的無限迴圈 (CVE-2021-47617)

    在某些 Intel(R) 處理器的內容之間不透明地共用分支預測器選取器，可能允許授權使用者透過本機存取實現資訊披露。(CVE-2022-0001)

    在某些 Intel(R) 處理器的內容中不透明地共用分支預測器，可能允許授權使用者透過本地存取實現資訊披露。(CVE-2022-0002)

    在使用者使用 Linux 核心 TIPC 通訊協定功能傳送含有惡意內容的封包時發現一個堆疊溢位缺陷，在這個封包中，網域成員節點數高於所允許的 64 個。
    具有 TIPC 網路存取權的遠端使用者可利用這個缺陷造成系統當機，或可能提升自己的權限。(CVE-2022-0435)

    發現在 Linux 核心的 copy_page_to_iter_pipe 和 push_pipe 函式中，新管道緩衝區結構的旗標成員缺少適當初始化，因此可能包含過時值。無權限的本機使用者可利用此缺陷，在唯讀檔案支援的頁面快取中寫入頁面，並因此提升其在系統上的權限。(CVE-2022-0847)

    在 Linux 核心中，發現 net/sched/cls_api.c 的 tc_new_tfilter 函式中包含釋放後使用弱點。本機非特權使用者命名空間的可用性允許特權提升。
    (CVE-2022-1055)

    現在，Amazon Linux 核心依預設會針對所有 ARM 型 EC2 執行個體類型啟用此問題的軟體緩解措施。(CVE-2022-23960)

    在 Linux 核心的 ASIX AX88179_178A 型 USB 2.0/3.0 Gigabit 乙太網路裝置驅動程式中發現一個缺陷。此弱點包含多個超出邊界讀取問題，並可能造成超出邊界寫入。
    (CVE-2022-2964)

    在 Linux 核心中，下列弱點已解決：

    tipc：改善已接收網域記錄的大小驗證 (CVE-2022-48711)

    在 Linux 核心中，下列弱點已解決：

    ext4：修正 ext4_fc_record_modified_inode() 中的錯誤處理 (CVE-2022-48712)

    在 Linux 核心中，下列弱點已解決：

    perf/x86/intel/pt：修正在單一範圍模式下套用停止篩選條件時當機的問題 (CVE-2022-48713)

    在 Linux 核心中，下列弱點已解決：

    bpf：針對 ringbuf 使用 VM_MAP 而非 VM_ALLOC (CVE-2022-48714)

    在 Linux 核心中，下列弱點已解決：

    net：macsec：修正 NETDEV_UNREGISTER 事件的卸載支援 (CVE-2022-48720)

    在 Linux 核心中，下列弱點已解決：

    iommu/vt-d：修復 intel_setup_irq_remapping() 中潛在的記憶體流失問題 (CVE-2022-48724)

    在 Linux 核心中，下列弱點已解決：

    RDMA/ucma在並行多點傳送離開期間保護 mc (CVE-2022-48726)

    在 Linux 核心中，下列弱點已解決：

    IB/hfi1：修正 AIP 早期初始化時的嚴重錯誤 (CVE-2022-48728)

    在 Linux 核心中，下列弱點已解決：

    btrfs：修正配額停用和 qgroup 重新掃描背景程序之間出現鎖死的情況 (CVE-2022-48734)

    在 Linux 核心中，下列弱點已解決：

    selinux：修正錯誤路徑上的 cond_list 重複釋放 (CVE-2022-48740)

    在 Linux 核心中，下列弱點已解決：

    rtnetlink：確保重新整理 __rtnl_newlink() 中的 master_dev/m_ops (CVE-2022-48742)

    在 Linux 核心中，下列弱點已解決：

    net：amd-xgbe：修復 skb 資料長度反向溢位問題 (CVE-2022-48743)

    在 Linux 核心中，下列弱點已解決：

    net/mlx5：在暫停輪詢的 fw 重設流程中使用 del_timer_sync (CVE-2022-48745)

    在 Linux 核心中，下列弱點已解決：

    net/mlx5e：修正連結 netevent 期間的錯誤裝置處理 (CVE-2022-48746)

    在 Linux 核心中，下列弱點已解決：

    KVM：x86：切換 SMM 狀態時強制離開巢狀 virt (CVE-2022-48763)

    在 Linux 核心中，下列弱點已解決：

    xprtrdma：修正 rpcrdma_ep_create 出現錯誤時的指標解除參照 (CVE-2022-48773)

    在 Linux 核心中，下列弱點已解決：

    驅動程式hvvmbus修正 vmbus_add_channel_kobj 中的記憶體洩漏 (CVE-2022-48775)

    在 Linux 核心中，下列弱點已解決：

    vsock：連線因訊號中斷時，從已連線的表格移除 vsock (CVE-2022-48786)

    在 Linux 核心中，下列弱點已解決：

    nvme-rdma：修正傳輸 error_recovery 工作中可能的釋放後使用錯誤 (CVE-2022-48788)

    在 Linux 核心中，下列弱點已解決：

    nvme：修正載入期間控制器重設時可能發生的釋放後使用錯誤 (CVE-2022-48790)

    在 Linux 核心中，下列弱點已解決：

    iommu：修正探查期間可能發生的釋放後使用問題 (CVE-2022-48796)

    在 Linux 核心中，下列弱點已解決：

    mm不嘗試 NUMA 移轉有其他用途的 COW 頁面 (CVE-2022-48797)

    在 Linux 核心中，下列弱點已解決：

    perf：修正 perf_cgroup_switch() 中的清單損毀 (CVE-2022-48799)

    在 Linux 核心中，下列弱點已解決：

    fs/proctask_mmu.c不讀取移轉項目的 mapcount (CVE-2022-48802)

    在 Linux 核心中，下列弱點已解決：

    vt_ioctl：修復 vt_setactivate 中的 array_index_nospec (CVE-2022-48804)

    在 Linux 核心中，下列弱點已解決：

    net：usb：ax88179_178a：修復 RX 修正中的超出邊界存取弱點 (CVE-2022-48805)

    在 Linux 核心中，下列弱點已解決：

    net：修復取消複製 skb dst 及其詮釋資料時的記憶體流失問題 (CVE-2022-48809)

    在 Linux 核心中，下列弱點已解決：

    ipmr、ip6mr在失敗路徑上呼叫 ip[6]mr_free_table() 前先取得 RTNL (CVE-2022-48810)

    在 Linux 核心中，下列弱點已解決：

    netdsalantiq_gswip不針對 mdiobus 使用 devres (CVE-2022-48812)

    在 Linux 核心中，下列弱點已解決：

    net：dsa：felix：不要針對 mdiobus 使用 devres (CVE-2022-48813)

    在 Linux 核心中，下列弱點已解決：

    net：dsa：bcm_sf2：不要針對 mdiobus 使用 devres (CVE-2022-48815)

    在 Linux 核心中，下列弱點已解決：

    netdsaar9331在 devres 下註冊 mdiobus (CVE-2022-48817)

    在 Linux 核心中，下列弱點已解決：

    net：dsa：mv88e6xxx：不要針對 mdiobus 使用 devres (CVE-2022-48818)

    在 Linux 核心中，下列弱點已解決：

    scsi：qedf：修正 TMF 期間收到 LOGO 時的 refcount 問題 (CVE-2022-48823)

    在 Linux 核心中，下列弱點已解決：

    scsiqedf將 stag_work 新增至所有 vport (CVE-2022-48825)

    在 Linux 核心中發現記憶體管理子元件 fs/proc/task_mmu.c 存在爭用問題。
    具有使用者特權的本機攻擊者可藉由此問題造成拒絕服務。(CVE-2023-1582)

Tenable 已直接從所測試產品的安全公告擷取前置描述區塊。

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

ID	名稱	產品	系列	已發布	已更新	嚴重性
206593	RHEL 8：核心 (RHSA-2024:6297)	Nessus	Red Hat Local Security Checks	2024/9/4	2025/9/18	high
211756	RHEL 9：kernel (RHSA-2024:9942)	Nessus	Red Hat Local Security Checks	2024/11/24	2024/11/24	high
366947	CentOS Linux 8.5 [TuxCare] 安全性更新：bpftool / kernel / kernel-core / kernel-cross-headers / etc 多個弱點（CENTOS8.5：CLSA-2024：1725876080）	Nessus	CentOS Local Security Checks	2026/10/18	2026/10/18	high
355129	Rocky Linux 8.6 [CIQ] 安全性更新：bpftool / bpftool-debuginfo / kernel / kernel-abi-stablelists / etc 多個弱點（ciqsa-2026_0871）	Nessus	Rocky Linux Local Security Checks	2026/10/1	2026/10/12	high
366937	CentOS Linux 8.4 [TuxCare] 安全性更新：bpftool / kernel / kernel-core / kernel-cross-headers / etc 多個弱點（CENTOS8.4：CLSA-2024：1725872696）	Nessus	CentOS Local Security Checks	2026/10/18	2026/10/18	high
211757	RHEL 9：kernel-rt (RHSA-2024:9943)	Nessus	Red Hat Local Security Checks	2024/11/24	2024/11/24	high
225284	Linux Distros 未修補弱點：CVE-2022-48796	Nessus	Misc.	2025/3/5	2026/11/5	high
160425	Amazon Linux 2核心 --advisory ALAS2KERNEL-5。10-2022-011 (ALASKERNEL-5.10-2022-011)	Nessus	Amazon Linux Local Security Checks	2022/5/2	2026/2/26	high

偵測

搜尋 Plugin

high

high

high

high

high

high

high

high