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 8 主机上安装的程序包受到 RHSA-2024:6297 公告中提及的多个漏洞的影响。

    内核程序包中包含 Linux 内核，后者是任何 Linux 操作系统的核心。

    安全修复：

    * kernel: cxgb4：避免在清除过滤条件时访问寄存器 (CVE-2021-47138)

    * kernel: hv_netvsc：修复 netvsc_probe 与 netvsc_remove 之间的争用条件 (CVE-2024-26698)

    * kernel: mm/slub：修复以在 kmalloc() 失败时返回 errno (CVE-2022-48659)

    * 内核：Squashfs：检查 inode 号是否不是无效的零值 (CVE-2024-26982)

    * 内核：vt：修复了删除字符时的 unicode 缓冲区损坏问题 (CVE-2024-35823)

    * kernel: nvme-rdma：在破坏 qp 之前破坏 cm id 以避免释放后使用 (CVE-2021-47378)

    * kernel：userfaultfd：修复 writeprotect 和 exit_mmap() 之间的争用问题 (CVE-2021-47461)

    * 内核：r8169：修复拆分后的 Tx 数据包上可能存在的环形缓冲区损坏。(CVE-2024-38586)

    * 内核: bpf：在 BPF_LINK_CREATE 中添加 BPF_PROG_TYPE_CGROUP_SKB 附加类型执行 (CVE-2024-38564)

    * kernel：bnxt_re：避免在 bnxt_qplib_alloc_init_hwq 中转移未定义行为 (CVE-2024-38540)

    * 内核：iommu：修复探测期间潜在的释放后使用问题 (CVE-2022-48796)

    * 内核：xfs：为 xlog_recover_process_data 添加边界检查 (CVE-2024-41014)

    有关上述安全问题的更多详细信息，包括其影响、CVSS 得分、致谢，以及其他相关信息，请参阅列于“参考”部分的 CVE 页面。

Tenable 已直接从 Red Hat Enterprise Linux 安全公告中提取上述描述块。

请注意，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 千兆位以太网设备驱动程序中发现一个缺陷，该漏洞包含多个越界读取问题，并且可能造成越界写入。
    (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 内核中，以下漏洞已修复：

    Drivers: hv: vmbus：修复 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不尝试对具有其他用途的 COW 页面进行 NUMA 迁移 (CVE-2022-48797)

    在 Linux 内核中，以下漏洞已修复：

    perf：修复 perf_cgroup_switch() 中的列表损坏 (CVE-2022-48799)

    在 Linux 内核中，以下漏洞已修复：

    fs/proc：task_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 内核中，以下漏洞已修复：

    ipmrip6mr在失败路径上调用 ip[6]mr_free_table() 之前获取 RTNL (CVE-2022-48810)

    在 Linux 内核中，以下漏洞已修复：

    netdsalantiq_gswip不要将 devres 用于 mdiobusCVE-2022-48812

    在 Linux 内核中，以下漏洞已修复：

    net：dsa：felix：不将 devres 用于 mdiobus (CVE-2022-48813)

    在 Linux 内核中，以下漏洞已修复：

    net：dsa：bcm_sf2：不将 devres 用于 mdiobus (CVE-2022-48815)

    在 Linux 内核中，以下漏洞已修复：

    netdsaar9331注册 devres 下的 mdiobus (CVE-2022-48817)

    在 Linux 内核中，以下漏洞已修复：

    net：dsa：mv88e6xxx：不将 devres 用于 mdiobus (CVE-2022-48818)

    在 Linux 内核中，以下漏洞已修复：

    scsi：qedf：修复在 TMF 期间收到 LOGO 时的引用计数问题 (CVE-2022-48823)

    在 Linux 内核中，以下漏洞已修复：

    scsiqedf将 stag_work 添加到所有 vports (CVE-2022-48825)

    在 Linux 内核中发现内存管理子组件的 fs/proc/task_mmu.c 存在争用问题。
    具有用户权限的本地攻击者可利用此缺陷造成系统拒绝服务。(CVE-2023-1582)

Tenable 已直接从测试产品的安全公告中提取上述描述块。

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

远程 Redhat Enterprise Linux 9 主机上安装的程序包受到 RHSA-2024:9943 公告中提及的多个漏洞影响。

    kernel-rt 程序包提供 Real Time Linux Kernel，支持对具有极高确定性要求的系统进行微调。

    安全修复：

    * 内核：blk-mq：修复 sbitmap 唤醒争用导致的 IO 挂起问题 (CVE-2024-26671)

    * 内核：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 依赖供应商报告的程序包是否存在进行判断。

远程 Redhat Enterprise Linux 9 主机上安装的程序包受到 RHSA-2024:9942 公告中提及的多个漏洞影响。

    内核程序包中包含 Linux 内核，后者是任何 Linux 操作系统的核心。

    安全修复：

    * 内核：blk-mq：修复 sbitmap 唤醒争用导致的 IO 挂起问题 (CVE-2024-26671)

    * 内核：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-49114和 CVE-2024-4685823 个。

Tenable 已直接从 CIQ 安全公告中提取上述描述块。

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
366937	CentOS Linux 8.4 [TuxCare] 安全更新：bpftool / kernel / kernel-core / kernel-cross-headers / 等多个漏洞（CENTOS8.4：CLSA-2024：1725872696）	Nessus	CentOS Local Security Checks	2026/10/18	2026/10/18	high
206593	RHEL 8：内核 (RHSA-2024:6297)	Nessus	Red Hat Local Security Checks	2024/9/4	2025/9/18	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
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
211756	RHEL 9：内核 (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 / 等多个漏洞（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 / 等多种漏洞（ciqsa-2026_0871）	Nessus	Rocky Linux Local Security Checks	2026/10/1	2026/10/12	high

检测

插件搜索

high

high

high

high

high

high

high

high