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

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

    安全修复：

    * kernel：xfrm：将 dev ref 保留至 transport_finish NF_HOOK 后 （CVE-2026-31663）

    * 内核：smb：客户端：修复 OOB 读取解析符号链接错误响应 (CVE-2026-31613)

    * kernel：RDMA/rxe：修复 QP 定时器处理程序中的争用条件 （CVE-2026-45910）

    * kernel：RDMA/rxe：在 rxe_rcv 中 payload_size（） 前验证 pad 和 ICRC (CVE-2026-46043)

    * kernel：RDMA/rxe：在 ICRC 处理之前拒绝未知操作码（CVE-2026-46133）

    * kernel：RDMA/rxe：拒绝非 8 字节 ATOMIC_WRITE 负载 （CVE-2026-46114）

    * kernel：xfrm： policy：修复 xfrm_policy_bysel_ctx（） 中不准确的 bin 上的释放后使用 （CVE-2026-53239）

    * kernel： ipv6： exthdrs：在 ipv6_hop_jumbo（） 之后刷新 nh 指针（CVE-2026-63924） 

    * kernel：ipv6：exthdrs：处理 HAO 选项后刷新 nh（CVE-2026-63922） 

    * kernel： ipv6：复制到 cmsg 之前验证扩展标头长度（CVE-2026-63920）

    * kernel： netfilter： synproxy：skb_ensure_writable  后刷新 tcphdr（CVE-2026-64007）

    * kernel：ip6：vti：在 vti6_siocdevprivate（） 中使用 ip6_tnl.net（CVE-2026-63921）

    * kernel： ipv6： rpl：修复 ipv6_rpl_srh_decompress（）中的 hdrlen 溢出（CVE-2026-63984）

    * kernel：xfrm： input：在延迟传输重新注入期间保持 netns （CVE-2026-63919）

    * kernel：ip6：vti：在 vti6_changelink（） 中使用 ip6_tnl.net（CVE-2026-63917）

    * kernel：RDMA/rxe：修复 rxe_mmap 中的释放后使用问题（CVE-2026-64582） 

    * kernel：xfrm：异步加密窃取 GSO 段后修复过时的 skb->prev （CVE-2026-68426）

    * kernel： nvmet-auth：拒绝短 AUTH_RECEIVE 缓冲区 （CVE-2026-72130）

    * kernel： ipv6：修复 ip6_finish_output2（） 中的释放后使用（CVE-2026-80792）

    * kernel：RDMA/rxe：修复 IB_QP_MAX_DEST_RD_ATOMIC modify_qp 上的响应程序 UAF（CVE-2026-80864）

    * kernel： RDMA/rxe：修复 free_rd_atomic_resources（）中的 OOB（CVE-2026-80863） 

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

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

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

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

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

    安全修复：

    *kernel：ALSA：firewire-motu：修复 DSP 事件的 hwdep 读取中的缓冲区溢出 (CVE-2025-68347)

    * kernel：xfrm：将 dev ref 保留至 transport_finish NF_HOOK 后 （CVE-2026-31663）

    * kernel： udf：修复分区描述符附加簿记 （CVE-2026-45991）

    * kernel：RDMA/rxe：在 rxe_rcv 中 payload_size（） 前验证 pad 和 ICRC (CVE-2026-46043)

    * kernel：RDMA/rxe：在 ICRC 处理之前拒绝未知操作码（CVE-2026-46133）

    * kernel：ipc：将 next_id 分配限制在有效 ID 范围 (CVE-2026-52923)

    * kernel： sctp：清除过时的 COOKIE-ECHO 处理 outqueue （CVE-2026-52924）

    * kernel：dm 缓存策略 smq：修复使缓存块失效时缺少的锁定 （CVE-2026-53062） 

    * kernel：xfrm： policy：修复 xfrm_policy_bysel_ctx（） 中不准确的 bin 上的释放后使用 （CVE-2026-53239）

    * kernel： netfilter： synproxy：skb_ensure_writable  后刷新 tcphdr（CVE-2026-64007）

    * kernel：ip6：vti：在 vti6_siocdevprivate（） 中使用 ip6_tnl.net（CVE-2026-63921）

    * kernel：xfrm： input：在延迟传输重新注入期间保持 netns （CVE-2026-63919）

    * kernel：ip6：vti：在 vti6_changelink（） 中使用 ip6_tnl.net（CVE-2026-63917）

    * kernel： nvmet：修复 Discovery Get Log Page  中的 pre-auth 越界堆读取（CVE-2026-64320）

    * kernel：AMD-SN-7061：安全 RET 中断漏洞 （CVE-2026-68480）

    * kernel：RDMA/rxe：修复 rxe_mmap 中的释放后使用问题（CVE-2026-64582） 

    * kernel：网络：qrtr：限制在初始网络命名空间中创建套接字 (CVE-2026-68294)

    * kernel：xfrm：异步加密窃取 GSO 段后修复过时的 skb->prev （CVE-2026-68426）

    * kernel：SCSI：libiscsi_tcp：将 SCSI 响应数据段绑定到连接缓冲区 (CVE-2026-74556)

    * kernel： netfilter： flowtable：发布 GC 可见元组 last （CVE-2026-74746）

    * kernel：RDMA/rxe：修复 IB_QP_MAX_DEST_RD_ATOMIC modify_qp 上的响应程序 UAF（CVE-2026-80864）

    * kernel： RDMA/rxe：修复 free_rd_atomic_resources（）中的 OOB（CVE-2026-80863） 

    错误修复和增强功能：

    * 返回委派时 NFS 客户端挂起 （JIRA：RHEL-112278）

    * scsi：mpt3sas：避免释放未分配的 PCIe SGL 缓冲区（JIRA：RHEL-256998）

    * inode 分配期间来自 [xfs_trans_cancel] 的 xfs 损坏 （JIRA：RHEL-257186）

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

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

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

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

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

    安全修复：

    * kernel： smc：修复 tcp_write_timer_handler（） （CVE-2023-53781） 中的释放后使用

    *kernel：ALSA：firewire-motu：修复 DSP 事件的 hwdep 读取中的缓冲区溢出 (CVE-2025-68347)

    * kernel：xfrm：将 dev ref 保留至 transport_finish NF_HOOK 后 （CVE-2026-31663）

    * kernel：Bluetooth：MGMT：验证加载时的 LTK enc_size (CVE-2026-43020)

    * kernel：Linux kernel：未正确限制 xfrm 单碎片长度 （）

    * kernel：RDMA/rxe：在 rxe_rcv 中 payload_size（） 前验证 pad 和 ICRC (CVE-2026-46043)

    * kernel：RDMA/rxe：在 ICRC 处理之前拒绝未知操作码（CVE-2026-46133）

    * kernel： sctp：清除过时的 COOKIE-ECHO 处理 outqueue （CVE-2026-52924）

    * kernel：xfrm： policy：修复 xfrm_policy_bysel_ctx（） 中不准确的 bin 上的释放后使用 （CVE-2026-53239）

    * kernel：ip6：vti：在 vti6_siocdevprivate（） 中使用 ip6_tnl.net（CVE-2026-63921）

    * kernel：xfrm： input：在延迟传输重新注入期间保持 netns （CVE-2026-63919）

    * kernel：ip6：vti：在 vti6_changelink（） 中使用 ip6_tnl.net（CVE-2026-63917）

    * kernel：AMD-SN-7061：安全 RET 中断漏洞 （CVE-2026-68480）

    * kernel：RDMA/rxe：修复 rxe_mmap 中的释放后使用问题（CVE-2026-64582） 

    * kernel：网络：qrtr：限制在初始网络命名空间中创建套接字 (CVE-2026-68294)

    * kernel：xfrm：异步加密窃取 GSO 段后修复过时的 skb->prev （CVE-2026-68426）

    * kernel： netfilter： flowtable：发布 GC 可见元组 last （CVE-2026-74746）

    * 内核：RDMA/rxe：修复 IB_QP_MAX_DEST_RD_ATOMIC modify_qp （CVE-2026-80864） 上的响应程序 UAF

    * kernel： RDMA/rxe：修复 free_rd_atomic_resources（） （CVE-2026-80863） 中的 OOB

    错误修复和增强功能：

    * scsi：mpt3sas：避免释放未分配的 PCIe SGL 缓冲区 （JIRA：RHEL-256999）

    * inode 分配期间来自 [xfs_trans_cancel] 的 xfs 损坏 （JIRA：RHEL-257187）

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

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

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

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - RDMA/rxe：修复 free_rd_atomic_resources（） 中的 OOB free_rd_atomic_resources（） 使用 qp->attr.max_dest_rd_atomic 进行迭代。在释放旧数组之前更新max_dest_rd_atomic可使自由路径遍历旧分配并触发 KASAN 捕获的 slab 越界写入：
    ================================================================== 缺陷：KASAN：free_rd_atomic_resource drivers/infiniband/sw/rxe/rxe_qp.c：180 中的 slab-out-of-bound [内联] 缺陷：KASAN：free_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c：171 中的 slab-out-of-bound [内联] 缺陷：KASAN：free_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c：163 中的 slab-out-of-bound [内联] 缺陷：KASAN：rxe_qp_from_attr+0x1e88/0x2150 drivers/infiniband/sw/rxe/ 中的 slab-out-of-boundrxe_qp.c： 712 在地址 ffff88802b8dddb8 处通过任务 syz.3.451/11063 写入大小为 4 CPU：0 UID：0 PID：11063 通信：syz.3.451 未受感染 7.1.0 #2 PREEMPT（完整） 硬件名称：QEMU Ubuntu 24.04 PC v2（i440FX + PIIX，arch_caps补丁，1996 年）、BIOS 1.16.3-debian-1.16.3-2 04/01/2014 调用跟踪： <TASK> __dump_stack lib/dump_stack.c：94 [内联] dump_stack_lvl+0x10e/0x1f0 lib/dump_stack.c：120 print_address_description mm/kasan/report.c：378 [内联] print_report+0xf7/0x600 mm/kasan/report.c：482 kasan_report+0xe4/0x120 mm/kasan/report.c：595 free_rd_atomic_resource drivers/infiniband/sw/rxe/rxe_qp.c：180 [内联] free_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c：171 [内联] free_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c：163 [内联] rxe_qp_from_attr+0x1e88/0x2150 drivers/infiniband/sw/rxe/rxe_qp.c：712 rxe_modify_qp+0x1e2/0x530 drivers/infiniband/sw/rxe/rxe_verbs.c：623 ib_security_modify_qp+0x223/0xfa0 drivers/infiniband/core/security.c：625 _ib_modify_qp+0x333/0xec0 drivers/infiniband/core/verbs.c：1915 modify_qp+0x13ca/0x1940 drivers/infiniband/core/uverbs_cmd.c：1932 ib_uverbs_modify_qp+0xcb/0x120 drivers/infiniband/core/uverbs_cmd.c：1958 ib_uverbs_write+0xb86/0x1030 drivers/infiniband/core/uverbs_main.c：680 vfs_write+0x2aa/0x1070 fs/read_write.c：686 ksys_write+0x1f8/0x250 fs/read_write.c：740 do_syscall_x64 arch/x86/entry/syscall_64.c：63 [inline] do_syscall_64+0x116/0x800 arch/x86/entry/syscall_64.c：94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP：
    0033：0x7fefc75a70cd 代码： ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP： 002b：00007fefc8495018 EFLAGS： 00000246 ORIG_RAX： 0000000000000001 RAX： ffffffffffffffda RBX：
    00007fefc7835fa0 RCX： 00007fefc75a70cd RDX： 0000000000000078 RSI： 0000200000000240 RDI： 0000000000000007 RBP： 00007fefc764f10f R08： 00000000000000000 R09： 000000000000000000 R10： 000000000000000000 R11：
    0000000000000246 R12： 0000000000000000 R13： 00007fefc7836038 R14： 00007fefc7835fa0 R15： 00007ffcf0586aa0 </TASK> 按任务 11063 分配：kasan_save_stack+0x33/0x60 mm/kasan/common.c：57 kasan_save_track+0x14/0x30 mm/kasan/common.c：78 poison_kmalloc_redzone mm/kasan/common.c：398 [内联]
    __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c：415 kasan_kmalloc include/linux/kasan.h：263 [内联]
    __do_kmalloc_node mm/slub.c：5296 [内联] __kmalloc_noprof+0x32a/0x850 mm/slub.c：5308 kmalloc_noprof include/linux/slab.h：954 [内联] kzalloc_noprof include/linux/slab.h：1188 [内联] alloc_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c：155 [内联] rxe_qp_from_attr+0x3f8/0x2150 drivers/infiniband/sw/rxe/rxe_qp.c：714 rxe_modify_qp+0x1e2/0x530 drivers/infiniband/sw/rxe/rxe_verbs.c：623 ib_security_modify_qp+0x223/0xfa0 drivers/infiniband/core/security.c：625 _ib_modify_qp+0x333/0xec0 drivers/infiniband/core/verbs.c：1915 modify_qp+0x13ca/0x1940 drivers/infiniband/core/uverbs_cmd.c：1932 ib_uverbs_modify_qp+0xcb/0x120 drivers/infiniband/core/uverbs_cmd.c：1958 ib_uverbs_write+0xb86/0x1030 drivers/infiniband/core/uverbs_马 ---truncated--- （CVE-2026-80863）

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

远程主机上安装的内核版本低于 5.10.269-270.1108。因此，会受到 ALAS2KERNEL-5.10-2026-133 公告中提及的多个漏洞影响。

    Linux 内核的 virtio-net/TAP 网络路径中的问题可允许在客户机虚拟机内具有特权访问权限的执行者发送特别构建的网络数据包，这些数据包会损坏运行未修补的 Linux 内核版本 4.4 的基于 KVM 的 6.18管理程序上的主机内核内存。这可导致主机内存泄露或拒绝服务。



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

    netfilter：nf_tables：为设备删除添加挂钩事务 （CVE-2026-63858）

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

    bpf、skmsg：修复 testdict sk_data_ready ktls rx 争用

    当存在 TLS RX 上下文时，sk_psock_strp_data_ready（） 已经检查 tls_sw_has_ctx_rx（） 并推迟到 psock->saved_data_ready，从而避免与 TLS strparser 的 receivequeue 所有权发生冲突（提交 e91de6afa81c，bpf：修复运行sk_skb程序类型与 ktls）。

    sk_psock_verdict_data_ready（） 没有等效保护。在配置 TLS RX 之前将套接字插入 sockmap （BPF_SK_SKB_VERDICT） 时，tls_sw_strparser_arm（） 将保存 sk_psock_verdict_data_readyas rx_ctx->saved_data_ready。数据到达时：

    tls_data_ready -> tls_strp_data_ready -> tls_rx_msg_ready-> saved_data_ready（） = sk_psock_verdict_data_ready（）-> tcp_read_skb（） 在不调用 tcp_eat_skb（） 的情况下通过 __skb_unlink（） 耗尽sk_receive_queue，因此未推进copied_seq。

    然后，tls_strp_msg_load（） 在现在为空的队列中查找 tcp_inq（） >= full_len（过时）、callstcp_recv_skb（），命中 WARN_ON_ONCE（！first），然后返回指向 psock 拥有（可能已释放）skb 的 rx_ctx->strp.anchor.frag_list。tls_decrypt_sg（） 进而thatfrag_list：释放后使用。

    应用与 sk_psock_strp_data_ready（） 相同的补丁：如果存在 TLS RX 上下文，则对 wakerecv（） 等待程序调用 psock->saved_data_ready （sock_def_readable） 并立即返回，不影响接收队列。TLS 保留队列的唯一所有权并通过 tls_sw_recvmsg（） 正常解密记录。（CVE-2026-64025）

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

    USB：iowarrior：修复断开连接争用 （CVE-2026-64341） 时的释放后使用

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

    ipvs：重新分配 head 后重新加载 ip 标头 （CVE-2026-68476）

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

    ipv4：igmp：修复 igmp_gq_start_timer（） （） 中CVE-2026-72323潜在的 UAF

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

    bridge：stp：修复删除桥接时潜在的释放后使用 （CVE-2026-72389）

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

    ipvlan：继承 phy_dev （） 的 needed_headroom 和CVE-2026-74744 needed_tailroom

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

    HID：magicmouse：如果未声明任何输入，则不保留过时的 msc->input （CVE-2026-80782）

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

    ext4：不对新的加密文件启用 DAX （CVE-2026-80806）

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

    nilfs2：拒绝 GC ioctl （CVE-2026-80807） 中无效的区块索引

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

    usb：usbfs：修复 usbdev_release（） （）CVE-2026-80824 中的 usb_device释放后使用

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

    USB：serial：选项：修复中断 URB 回调 （CVE-2026-80827） 中的 slab OOB 读取

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

    usb：core：向 usb_wakeup_notification（） 添加锁 （CVE-2026-80830）

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

    ipv6：seg6：清除 IPIP 解封装 （CVE-2026-80840） 上的 IPv4 控制块

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

    xfrm：修复 xfrm_state_construct（） auth-trunc 泄漏 （CVE-2026-80843）

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

    RDMA/rxe：修复 free_rd_atomic_resources（） （CVE-2026-80863） 中的 OOB

    在 Linux 内核中，以下漏洞已修复：ipv4: validate checksum_start before completing checksum If a packet with bad checksum metadata gets into the ipv4 stack, skb_checksum_help can corrupt the network header and cause a bunch of mischief. This was discovered and reported by Paulos, and has been reporoduced by others independently since. We really shouldn't allow such packets in, but as a defence in depth measure, let's also check before we complete the checksum. A more complete validation at input is forthcoming, but needs more work. (CVE-2026-99999)

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

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

远程 Debian 12 主机上存在安装的程序包，该程序包受到 dla-4777 公告中提及的多个漏洞的影响。

    - ------------------------------------------------------------------------- Debian LTS 公告 DLA-4777-1 debian-lts@lists.debian.org https://www.debian.org/lts/security/Salvatore Bonaccorso 2026 年 9 月 8 日 https://wiki.debian.org/LTS
    - -------------------------------------------------------------------------

    程序包： linux 版本： 6.1.187-1 CVE ID： CVE-2023-53706 CVE-2023-54141 CVE-2023-54263 CVE-2024-38620 CVE-2024-46754 CVE-2024-58094 CVE-2024-58095 CVE-2025-22104 CVE-2025-38117 CVE-2025-38203 CVE-2025-38206 CVE-2025-38237 CVE-2025-38616 CVE-2025-39833 CVE-2025-39901 CVE-2025-39925 CVE-2025-40054 CVE-2025-40064 CVE-2025-40102 CVE-2025-40139 CVE-2025-40168 CVE-2025-40206 CVE-2025-40307 CVE-2025-68794 CVE-2026-23394 CVE-2026-31419 CVE-2026-43491 CVE-2026-45963 CVE-2026-46111 CVE-2026-46158 CVE-2026-46170 CVE-2026-46266 CVE-2026-53089 CVE-2026-53090 CVE-2026-53361 CVE-2026-64082 CVE-2026-64139 CVE-2026-64192 CVE-2026-64270 CVE-2026-64272 CVE-2026-64280 CVE-2026-64294 CVE-2026-64434 CVE-2026-64507 CVE-2026-64508 CVE-2026-64542 CVE-2026-64543 CVE-2026-64561 CVE-2026-64562 CVE-2026-64563 CVE-2026-64564 CVE-2026-64565 CVE-2026-64567 CVE-2026-64569 CVE-2026-64571 CVE-2026-64572 CVE-2026-64573 CVE-2026-64576 CVE-2026-64577 CVE-2026-64578 CVE-2026-64579 CVE-2026-64580 CVE-2026-64581 CVE-2026-64582 CVE-2026-64583 CVE-2026-64584 CVE-2026-64586 CVE-2026-64590 CVE-2026-68082 CVE-2026-68093 CVE-2026-68096 CVE-2026-68099 CVE-2026-68100 CVE-2026-68104 CVE-2026-68106 CVE-2026-68108 CVE-2026-68111 CVE-2026-68115 CVE-2026-68117 CVE-2026-68121 CVE-2026-68123 CVE-2026-68124 CVE-2026-68125 CVE-2026-68127 CVE-2026-68129 CVE-2026-68130 CVE-2026-68131 CVE-2026-68132 CVE-2026-68135 CVE-2026-68136 CVE-2026-68137 CVE-2026-68138 CVE-2026-68140 CVE-2026-68141 CVE-2026-68142 CVE-2026-68143 CVE-2026-68144 CVE-2026-68146 CVE-2026-68147 CVE-2026-68148 CVE-2026-68151 CVE-2026-68153 CVE-2026-68154 CVE-2026-68155 CVE-2026-68156 CVE-2026-68157 CVE-2026-68158 CVE-2026-68159 CVE-2026-68160 CVE-2026-68162 CVE-2026-68164 CVE-2026-68165 CVE-2026-68169 CVE-2026-68175 CVE-2026-68176 CVE-2026-68180 CVE-2026-68181 CVE-2026-68182 CVE-2026-68183 CVE-2026-68184 CVE-2026-68186 CVE-2026-68187 CVE-2026-68188 CVE-2026-68189 CVE-2026-68190 CVE-2026-68192 CVE-2026-68194 CVE-2026-68195 CVE-2026-68196 CVE-2026-68197 CVE-2026-68198 CVE-2026-68199 CVE-2026-68202 CVE-2026-68204 CVE-2026-68206 CVE-2026-68207 CVE-2026-68209 CVE-2026-68210 CVE-2026-68212 CVE-2026-68213 CVE-2026-68214 CVE-2026-68215 CVE-2026-68216 CVE-2026-68217 CVE-2026-68218 CVE-2026-68222 CVE-2026-68223 CVE-2026-68226 CVE-2026-68227 CVE-2026-68229 CVE-2026-68231 CVE-2026-68234 CVE-2026-68243 CVE-2026-68244 CVE-2026-68246 CVE-2026-68248 CVE-2026-68249 CVE-2026-68250 CVE-2026-68251 CVE-2026-68253 CVE-2026-68254 CVE-2026-68255 CVE-2026-68259 CVE-2026-68269 CVE-2026-68277 CVE-2026-68278 CVE-2026-68279 CVE-2026-68280 CVE-2026-68284 CVE-2026-68294 CVE-2026-68297 CVE-2026-68299 CVE-2026-68300 CVE-2026-68301 CVE-2026-68302 CVE-2026-68304 CVE-2026-68309 CVE-2026-68310 CVE-2026-68313 CVE-2026-68315 CVE-2026-68320 CVE-2026-68322 CVE-2026-68324 CVE-2026-68325 CVE-2026-68326 CVE-2026-68327 CVE-2026-68328 CVE-2026-68331 CVE-2026-68333 CVE-2026-68335 CVE-2026-68336 CVE-2026-68338 CVE-2026-68340 CVE-2026-68343 CVE-2026-68344 CVE-2026-68349 CVE-2026-68350 CVE-2026-68351 CVE-2026-68352 CVE-2026-68353 CVE-2026-68354 CVE-2026-68355 CVE-2026-68357 CVE-2026-68359 CVE-2026-68360 CVE-2026-68361 CVE-2026-68362 CVE-2026-68363 CVE-2026-68365 CVE-2026-68366 CVE-2026-68367 CVE-2026-68368 CVE-2026-68369 CVE-2026-68370 CVE-2026-68371 CVE-2026-68373 CVE-2026-68376 CVE-2026-68377 CVE-2026-68386 CVE-2026-68388 CVE-2026-68395 CVE-2026-68397 CVE-2026-68398 CVE-2026-68402 CVE-2026-68403 CVE-2026-68405 CVE-2026-68406 CVE-2026-68407 CVE-2026-68410 CVE-2026-68411 CVE-2026-68413 CVE-2026-68414 CVE-2026-68417 CVE-2026-68422 CVE-2026-68425 CVE-2026-68427 CVE-2026-68428 CVE-2026-68430 CVE-2026-68431 CVE-2026-68432 CVE-2026-68433 CVE-2026-68434 CVE-2026-68444 CVE-2026-68446 CVE-2026-68450 CVE-2026-68451 CVE-2026-68452 CVE-2026-68476 CVE-2026-68480 CVE-2026-72012 CVE-2026-72015 CVE-2026-72017 CVE-2026-72023 CVE-2026-72030 CVE-2026-72035 CVE-2026-72040 CVE-2026-72041 CVE-2026-72045 CVE-2026-72051 CVE-2026-72057 CVE-2026-72062 CVE-2026-72063 CVE-2026-72065 CVE-2026-72069 CVE-2026-72070 CVE-2026-72077 CVE-2026-72096 CVE-2026-72099 CVE-2026-72110 CVE-2026-72113 CVE-2026-72114 CVE-2026-72115 CVE-2026-72116 CVE-2026-72117 CVE-2026-72118 CVE-2026-72119 CVE-2026-72121 CVE-2026-72124 CVE-2026-72125 CVE-2026-72142 CVE-2026-72146 CVE-2026-72157 CVE-2026-72170 CVE-2026-72172 CVE-2026-72191 CVE-2026-72216 CVE-2026-72236 CVE-2026-72237 CVE-2026-72242 CVE-2026-72252 CVE-2026-72253 CVE-2026-72260 CVE-2026-72262 CVE-2026-72299 CVE-2026-72305 CVE-2026-72308 CVE-2026-72323 CVE-2026-72392 CVE-2026-74436 CVE-2026-74441 CVE-2026-74443 CVE-2026-74444 CVE-2026-74446 CVE-2026-74450 CVE-2026-74453 CVE-2026-74454 CVE-2026-74455 CVE-2026-74456 CVE-2026-74457 CVE-2026-74458 CVE-2026-74459 CVE-2026-74460 CVE-2026-74461 CVE-2026-74463 CVE-2026-74464 CVE-2026-74465 CVE-2026-74467 CVE-2026-74468 CVE-2026-74469 CVE-2026-74470 CVE-2026-74471 CVE-2026-74472 CVE-2026-74473 CVE-2026-74475 CVE-2026-74476 CVE-2026-74478 CVE-2026-74479 CVE-2026-74480 CVE-2026-74481 CVE-2026-74482 CVE-2026-74485 CVE-2026-74487 CVE-2026-74488 CVE-2026-74490 CVE-2026-74492 CVE-2026-74493 CVE-2026-74494 CVE-2026-74495 CVE-2026-74497 CVE-2026-74498 CVE-2026-74499 CVE-2026-74505 CVE-2026-74507 CVE-2026-74508 CVE-2026-74509 CVE-2026-74510 CVE-2026-74512 CVE-2026-74514 CVE-2026-74515 CVE-2026-74516 CVE-2026-74518 CVE-2026-74519 CVE-2026-74522 CVE-2026-74523 CVE-2026-74525 CVE-2026-74540 CVE-2026-74546 CVE-2026-74547 CVE-2026-74548 CVE-2026-74549 CVE-2026-74550 CVE-2026-74551 CVE-2026-74552 CVE-2026-74553 CVE-2026-74555 CVE-2026-74556 CVE-2026-74557 CVE-2026-74563 CVE-2026-74564 CVE-2026-74566 CVE-2026-74567 CVE-2026-74569 CVE-2026-74575 CVE-2026-74577 CVE-2026-74579 CVE-2026-74580 CVE-2026-74581 CVE-2026-74582 CVE-2026-74583 CVE-2026-74585 CVE-2026-74586 CVE-2026-74587 CVE-2026-74588 CVE-2026-74589 CVE-2026-74594 CVE-2026-74595 CVE-2026-74597 CVE-2026-74598 CVE-2026-74601 CVE-2026-74603 CVE-2026-74604 CVE-2026-74607 CVE-2026-74608 CVE-2026-74609 CVE-2026-74612 CVE-2026-74613 CVE-2026-74614 CVE-2026-74615 CVE-2026-74616 CVE-2026-74620 CVE-2026-74621 CVE-2026-74622 CVE-2026-74623 CVE-2026-74624 CVE-2026-74625 CVE-2026-74626 CVE-2026-74628 CVE-2026-74630 CVE-2026-74631 CVE-2026-74632 CVE-2026-74635 CVE-2026-74636 CVE-2026-74637 CVE-2026-74641 CVE-2026-74647 CVE-2026-74648 CVE-2026-74649 CVE-2026-74650 CVE-2026-74651 CVE-2026-74654 CVE-2026-74656 CVE-2026-74657 CVE-2026-74658 CVE-2026-74659 CVE-2026-74660 CVE-2026-74662 CVE-2026-74663 CVE-2026-74664 CVE-2026-74666 CVE-2026-74667 CVE-2026-74668 CVE-2026-74669 CVE-2026-74671 CVE-2026-74672 CVE-2026-74673 CVE-2026-74675 CVE-2026-74676 CVE-2026-74678 CVE-2026-74679 CVE-2026-74680 CVE-2026-74682 CVE-2026-74683 CVE-2026-74688 CVE-2026-74689 CVE-2026-74691 CVE-2026-74692 CVE-2026-74693 CVE-2026-74694 CVE-2026-74696 CVE-2026-74697 CVE-2026-74701 CVE-2026-74704 CVE-2026-74705 CVE-2026-74714 CVE-2026-74717 CVE-2026-74719 CVE-2026-74720 CVE-2026-74722 CVE-2026-74724 CVE-2026-74726 CVE-2026-74730 CVE-2026-74737 CVE-2026-74739 CVE-2026-74743 CVE-2026-74744 CVE-2026-74746 CVE-2026-74748 CVE-2026-80527 CVE-2026-80528 CVE-2026-80529 CVE-2026-80534 CVE-2026-80536 CVE-2026-80539 CVE-2026-80540 CVE-2026-80541 CVE-2026-80547 CVE-2026-80548 CVE-2026-80549 CVE-2026-80550 CVE-2026-80552 CVE-2026-80553 CVE-2026-80555 CVE-2026-80557 CVE-2026-80558 CVE-2026-80559 CVE-2026-80560 CVE-2026-80561 CVE-2026-80562 CVE-2026-80565 CVE-2026-80567 CVE-2026-80568 CVE-2026-80569 CVE-2026-80570 CVE-2026-80572 CVE-2026-80573 CVE-2026-80574 CVE-2026-80583 CVE-2026-80584 CVE-2026-80586 CVE-2026-80589 CVE-2026-80590 CVE-2026-80678 CVE-2026-80679 CVE-2026-80680 CVE-2026-80681 CVE-2026-80684 CVE-2026-80686 CVE-2026-80706 CVE-2026-80707 CVE-2026-80708 CVE-2026-80709 CVE-2026-80714 CVE-2026-80715 CVE-2026-80716 CVE-2026-80717 CVE-2026-80718 CVE-2026-80722 CVE-2026-80725 CVE-2026-80726 CVE-2026-80730 CVE-2026-80731 CVE-2026-80732 CVE-2026-80733 CVE-2026-80737 CVE-2026-80742 CVE-2026-80743 CVE-2026-80744 CVE-2026-80752 CVE-2026-80754 CVE-2026-80756 CVE-2026-80757 CVE-2026-80762 CVE-2026-80763 CVE-2026-80764 CVE-2026-80765 CVE-2026-80766 CVE-2026-80767 CVE-2026-80768 CVE-2026-80770 CVE-2026-80772 CVE-2026-80781 CVE-2026-80782 CVE-2026-80783 CVE-2026-80784 CVE-2026-80788 CVE-2026-80789 CVE-2026-80790 CVE-2026-80791 CVE-2026-80792 CVE-2026-80793 CVE-2026-80794 CVE-2026-80795 CVE-2026-80796 CVE-2026-80797 CVE-2026-80798 CVE-2026-80799 CVE-2026-80800 CVE-2026-80801 CVE-2026-80802 CVE-2026-80803 CVE-2026-80805 CVE-2026-80806 CVE-2026-80807 CVE-2026-80808 CVE-2026-80809 CVE-2026-80812 CVE-2026-80814 CVE-2026-80819 CVE-2026-80823 CVE-2026-80824 CVE-2026-80826 CVE-2026-80827 CVE-2026-80828 CVE-2026-80829 CVE-2026-80830 CVE-2026-80831 CVE-2026-80832 CVE-2026-80840 CVE-2026-80842 CVE-2026-80843 CVE-2026-80844 CVE-2026-80846 CVE-2026-80848 CVE-2026-80852 CVE-2026-80854 CVE-2026-80855 CVE-2026-80856 CVE-2026-80863 CVE-2026-80888 CVE-2026-80890 CVE-2026-80891 CVE-2026-80892 CVE-2026-80893 CVE-2026-80901 CVE-2026-80902 CVE-2026-80904 CVE-2026-80906 CVE-2026-80908 CVE-2026-80909 CVE-2026-80910 CVE-2026-80913

    在 Linux 内核中发现多个可能导致权限升级、拒绝服务或信息泄漏的漏洞。

    对于 Debian 12 bookworm，这些问题已在版本 6.1.187-1中修复。

    建议您升级 linux 程序包。

    如需了解 linux 的详细安全状态，请参阅其安全跟踪页面：
    https://security-tracker.debian.org/tracker/linux

    有关 Debian LTS 安全公告、如何将这些更新应用到系统以及常见问题解答的更多信息，请访问以下网址：https://wiki.debian.org/LTS

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

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

Rocky Linux 8.6 主机上安装的多个程序包受到 CIQ ciqsa-2026_1573 公告中提及的多个漏洞影响。

    此公告汇总了 CIQ LTS 8.6中内核 SRPM 的安全修复。它解决了 51 个 CVE：
    CVE-2026-53002、 CVE-2026-64268、 CVE-2021-4083、 CVE-2022-1012和 CVE-2023-163746 个。

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

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

Rocky Linux 9.6 主机上安装的多个程序包受到 CIQ ciqsa-2026_1641 公告中提及的多个漏洞影响。

    此公告汇总了 CIQ LTS 9.6中内核 SRPM 的安全修复。它解决了 24 个 CVE：
    CVE-2026-53002、、CVE-2026-63919、CVE-2026-74746CVE-2025-21826CVE-2026-98260和 19 个。

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

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

远程 CentOS Linux 9 主机上安装的多个程序包受到 kernel-5.14.0-756.el9 版本变更日志中提及的多个漏洞影响。

  - 已修复 Linux 内核中的下列漏洞：wifi: cfg80211: bound element ID read when checking non-inheritance cfg80211_is_element_inherited() reads the first data octet of the candidate element (id = elem->data[0]) to look it up in an extension non-inheritance list. It does so after testing elem->id, but without verifying that the element actually has a data octet. A zero-length extension element (WLAN_EID_EXTENSION with length 0) therefore makes it read one octet past the end of the element.
    _ieee802_11_parse_elems_full() runs this check for every element of a frame once a non-inheritance context exists -- e.g. while parsing a per-STA profile of a Multi-Link element in a (re)association response, or a non-transmitted BSS profile -- so a crafted frame from an AP can trigger a one-octet slab-out-of-bounds read during element parsing: BUG: KASAN: slab-out-of-bounds in cfg80211_is_element_inherited Read of size 1 ... in net/wireless/scan.c Return early (treat the element as inherited) when an extension element carries no data, mirroring the existing handling of empty ID lists. The bug was found by fuzzing ieee802_11_parse_elems_full() under KASAN. (CVE-2026-68402)

  - 已修复 Linux 内核中的下列漏洞：RDMA/siw: Reject MPA FPDU length underflow before signed receive math A malicious connected siw peer can send an iWARP FPDU whose MPA length field (c_hdr->mpa_len, 16 bit big-endian, peer-controlled) is smaller than the fixed DDP/RDMAP header for the announced opcode. Soft-iWARP parses the full header in siw_get_hdr() based on iwarp_pktinfo[opcode] .hdr_len, but never compares mpa_len against that header length. siw_tcp_rx_data() then derives srx->fpdu_part_rem = be16_to_cpu(mpa_len) - fpdu_part_rcvd + MPA_HDR_SIZE; where fpdu_part_rcvd equals iwarp_pktinfo[opcode].hdr_len at this point. For a tagged WRITE (hdr_len 16, MPA_HDR_SIZE 2) the smallest on-wire mpa_len of 0 yields fpdu_part_rem = -14, and any mpa_len below hdr_len - MPA_HDR_SIZE underflows to a negative int. The signed value then flows into siw_proc_write()/siw_proc_rresp() as bytes = min(srx->fpdu_part_rem, srx->skb_new); is handed to siw_check_mem() as an int len (whose interval check addr + len > mem->va + mem->len is satisfied for a valid base when len is negative), and reaches siw_rx_data() -> siw_rx_kva() / siw_rx_umem() -> skb_copy_bits() as a signed copy length. The header copy branch in skb_copy_bits() promotes that to size_t, producing a multi-gigabyte read. KASAN under a KUnit harness that drives the real kernel TCP receive path -- a loopback AF_INET socketpair, the malformed FPDU written via kernel_sendmsg, sk_data_ready firing in softirq, tcp_read_sock dispatching to siw_tcp_rx_data -- reports: BUG: KASAN: use-after-free in skb_copy_bits+0x284/0x480 Read of size 4294967295 at addr ffff888... Call Trace:
    skb_copy_bits siw_rx_kva siw_rx_data siw_check_mem siw_proc_write siw_tcp_rx_data __tcp_read_sock siw_qp_llp_data_ready tcp_data_ready tcp_data_queue Add the missing invariant at the earliest point where the peer header is fully assembled. iwarp_pktinfo[*].hdr_len - MPA_HDR_SIZE is exactly the value the siw transmitter uses as the minimum mpa_len for each opcode (drivers/infiniband/sw/siw/siw_qp.c:33), so this matches the protocol contract. Out-of-range FPDUs terminate the connection with TERM_ERROR_LAYER_LLP / LLP_ETYPE_MPA / LLP_ECODE_FPDU_START -- which is RFC 5044 Section 8 error code 3 (Marker and ULPDU Length fields do not agree on the start of an FPDU), the correct framing-error class for this inconsistency.
    (CVE-2026-64102)

  - 已修复 Linux 内核中的下列漏洞：RDMA/rxe: Fix race condition in QP timer handlers I encontered the following warning: WARNING: drivers/infiniband/sw/rxe/rxe_task.c:249 at rxe_sched_task+0x1c8/0x238 [rdma_rxe], CPU#0: swapper/0/0 ... libsha1 [last unloaded: ip6_udp_tunnel] CPU:
    0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G C 6.19.0-rc5-64k-v8+ #37 PREEMPT Tainted: [C]=CRAP Hardware name: Raspberry Pi 4 Model B Rev 1.2 Call trace: rxe_sched_task+0x1c8/0x238 [rdma_rxe] (P) retransmit_timer+0x130/0x188 [rdma_rxe] call_timer_fn+0x68/0x4d0 __run_timers+0x630/0x888 ... WARNING:
    drivers/infiniband/sw/rxe/rxe_task.c:38 at rxe_sched_task+0x1c0/0x238 [rdma_rxe], CPU#0: swapper/0/0 ...
    WARNING: drivers/infiniband/sw/rxe/rxe_task.c:111 at do_work+0x488/0x5c8 [rdma_rxe], CPU#3:
    kworker/u17:4/93400 ... refcount_t: underflow; use-after-free. WARNING: lib/refcount.c:28 at refcount_warn_saturate+0x138/0x1a0, CPU#3: kworker/u17:4/93400 The issue is caused by a race condition between retransmit_timer() and rxe_destroy_qp, leading to the Queue Pair's (QP) reference count dropping to zero during timer handler execution. It seems this warning is harmless because rxe_qp_do_cleanup() will flush all pending timers and requests. Example of flow causing the issue: CPU0 CPU1 retransmit_timer() {spin_lock_irqsave rxe_destroy_qp() __rxe_cleanup() __rxe_put() // qp->ref_count decrease to 0 rxe_qp_do_cleanup() { if (qp->valid) { rxe_sched_task() { WARN_ON(rxe_read(task->qp) <= 0); } } spin_unlock_irqrestore } spin_lock_irqsave qp->valid = 0 spin_unlock_irqrestore } Ensure the QP's reference count is maintained and its validity is checked within the timer callbacks by adding calls to rxe_get(qp) and corresponding rxe_put(qp) after use. (CVE-2026-45910)

  - 已修复 Linux 内核中的下列漏洞：ext4: fix e4b bitmap inconsistency reports A bitmap inconsistency issue was observed during stress tests under mixed huge-page workloads.
    Ext4 reported multiple e4b bitmap check failures like: ext4_mb_complex_scan_group:2508: group 350, 8179 free clusters as per group info. But got 8192 blocks Analysis and experimentation confirmed that the issue is caused by a race condition between page migration and bitmap modification. Although this timing window is extremely narrow, it is still hit in practice: folio_lock ext4_mb_load_buddy __migrate_folio check ref count folio_mc_copy __filemap_get_folio folio_try_get(folio) ...... mb_mark_used ext4_mb_unload_buddy
    __folio_migrate_mapping folio_ref_freeze folio_unlock The root cause of this issue is that the fast path of load_buddy only increments the folio's reference count, which is insufficient to prevent concurrent folio migration. We observed that the folio migration process acquires the folio lock. Therefore, we can determine whether to take the fast path in load_buddy by checking the lock status. If the folio is locked, we opt for the slow path (which acquires the lock) to close this concurrency window. Additionally, this change addresses the following issues: When the DOUBLE_CHECK macro is enabled to inspect bitmap-related issues, the following error may be triggered: corruption in group 324 at byte 784(6272): f in copy != ff on disk/prealloc Analysis reveals that this is a false positive. There is a specific race window where the bitmap and the group descriptor become momentarily inconsistent, leading to this error report:
    ext4_mb_load_buddy ext4_mb_load_buddy __filemap_get_folio(create|lock) folio_lock ext4_mb_init_cache folio_mark_uptodate __filemap_get_folio(no lock) ...... mb_mark_used mb_mark_used_double mb_cmp_bitmaps mb_set_bits(e4b->bd_bitmap) folio_unlock The original logic assumed that since mb_cmp_bitmaps is called when the bitmap is newly loaded from disk, the folio lock would be sufficient to prevent concurrent access. However, this overlooks a specific race condition: if another process attempts to load buddy and finds the folio is already in an uptodate state, it will immediately begin using it without holding folio lock. (CVE-2026-45942)

  - 已修复 Linux 内核中的下列漏洞：RDMA/rxe: Validate pad and ICRC before payload_size() in rxe_rcv rxe_rcv() currently checks only that the incoming packet is at least header_size(pkt) bytes long before payload_size() is used. However, payload_size() subtracts both the attacker-controlled BTH pad field and RXE_ICRC_SIZE from pkt->paylen: payload_size = pkt->paylen - offset[RXE_PAYLOAD] - bth_pad(pkt) - RXE_ICRC_SIZE This means a short packet can still make payload_size() underflow even if it includes enough bytes for the fixed headers. Simply requiring header_size(pkt) + RXE_ICRC_SIZE is not sufficient either, because a packet with a forged non-zero BTH pad can still leave payload_size() negative and pass an underflowed value to later receive-path users. Fix this by validating pkt->paylen against the full minimum length required by payload_size(): header_size(pkt) + bth_pad(pkt) + RXE_ICRC_SIZE. (CVE-2026-46043)

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

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

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

    安全修复：

    * kernel：xfrm：将 dev ref 保留至 transport_finish NF_HOOK 后 （CVE-2026-31663）

    * 内核：ALSA：6fire：修复断开连接时的释放后使用 （CVE-2026-31581）

    * kernel：gfs2：修复 iomap 内联数据写入路径中的释放后使用 （CVE-2026-45984）

    * kernel： udf：修复分区描述符附加簿记 （CVE-2026-45991）

    * kernel：RDMA/rxe：在 rxe_rcv 中 payload_size（） 前验证 pad 和 ICRC (CVE-2026-46043)

    * kernel：RDMA/rxe：在 ICRC 处理之前拒绝未知操作码（CVE-2026-46133）

    * kernel： sctp：清除过时的 COOKIE-ECHO 处理 outqueue （CVE-2026-52924）

    * kernel：xfrm： policy：修复 xfrm_policy_bysel_ctx（） 中不准确的 bin 上的释放后使用 （CVE-2026-53239）

    * kernel： netfilter： synproxy：skb_ensure_writable  后刷新 tcphdr（CVE-2026-64007）

    * kernel：ip6：vti：在 vti6_siocdevprivate（） 中使用 ip6_tnl.net（CVE-2026-63921）

    * kernel：xfrm： input：在延迟传输重新注入期间保持 netns （CVE-2026-63919）

    * kernel：ip6：vti：在 vti6_changelink（） 中使用 ip6_tnl.net（CVE-2026-63917）

    * kernel：RDMA/rxe：修复 rxe_mmap 中的释放后使用问题（CVE-2026-64582） 

    * kernel：网络：qrtr：限制在初始网络命名空间中创建套接字 (CVE-2026-68294)

    * kernel：xfrm：异步加密窃取 GSO 段后修复过时的 skb->prev （CVE-2026-68426）

    * kernel：SCSI：libiscsi_tcp：将 SCSI 响应数据段绑定到连接缓冲区 (CVE-2026-74556)

    * kernel： netfilter： flowtable：发布 GC 可见元组 last （CVE-2026-74746）

    * 内核：RDMA/rxe：修复 IB_QP_MAX_DEST_RD_ATOMIC modify_qp （CVE-2026-80864） 上的响应程序 UAF

    * kernel： RDMA/rxe：修复 free_rd_atomic_resources（） （CVE-2026-80863） 中的 OOB

    错误修复和增强功能：

    * inode 分配期间来自 [xfs_trans_cancel] 的 xfs 损坏 （JIRA：RHEL-257185）

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

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

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

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

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

    安全修复：

    * kernel： ipv6：为 SRv6 路径中的 idev 添加 NULL 检查 （CVE-2026-23442）

    * kernel：RDMA/rxe：修复 QP 定时器处理程序中的争用条件 （CVE-2026-45910）

    * kernel：RDMA/rxe：在 rxe_rcv 中 payload_size（） 前验证 pad 和 ICRC (CVE-2026-46043)

    * kernel：RDMA/rxe：在 ICRC 处理之前拒绝未知操作码（CVE-2026-46133）

    * kernel：RDMA/rxe：拒绝非 8 字节 ATOMIC_WRITE 负载 （CVE-2026-46114）

    * kernel： ipv6： exthdrs：在 ipv6_hop_jumbo（） （） 之后CVE-2026-63924刷新 nh 指针

    * 内核：ipv6：exthdrs：处理 HAO 选项 （CVE-2026-63922） 后刷新 nh

    * kernel： ipv6：复制到 cmsg （CVE-2026-63920） 之前验证扩展标头长度

    * kernel： ipv6： rpl：修复 ipv6_rpl_srh_decompress（） （CVE-2026-63984） 中的 hdrlen 溢出

    * 内核：内核 SMB 客户端：双重释放漏洞允许远程拒绝服务或权限升级 （CVE-2026-64385）

    * kernel：smb：客户端：修复 SMB2_flush（） 重播中的双重释放 （CVE-2026-64383）

    * kernel：smb：客户端：修复 query_info() 重播中的双重释放（CVE-2026-64386）

    * kernel：RDMA/rxe：修复 rxe_mmap 中的释放后使用问题（CVE-2026-64582） 

    * kernel： ipv6：修复 ip6_finish_output2（） （CVE-2026-80792） 中的释放后使用

    * 内核：RDMA/rxe：修复 IB_QP_MAX_DEST_RD_ATOMIC modify_qp （CVE-2026-80864） 上的响应程序 UAF

    * kernel： RDMA/rxe：修复 free_rd_atomic_resources（） （CVE-2026-80863） 中的 OOB

    错误修复和增强功能：

    * gfs2：远程删除问题 [rhel-9.6.z] （JIRA：RHEL-172430）

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

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

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

Rocky Linux 9.2 主机上安装的多个程序包受到 CIQ ciqsa-2026_1575 公告中提及的多个漏洞影响。

    此公告汇总了 CIQ LTS 9.2中内核 SRPM 的安全修复。它解决了 78 个 CVE：
    CVE-2026-64304、、CVE-2023-52933、CVE-2023-1637CVE-2024-41090CVE-2023-28466和 73 个。

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

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

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
363822	RHEL 9：内核 (RHSA-2026:77218)	Nessus	Red Hat Local Security Checks	2026/10/7	2026/10/21	critical
364137	Oracle Linux 10 / 9：Unbreakable Enterprise 内核 (ELSA-2026-500374)	Nessus	Oracle Linux Local Security Checks	2026/10/8	2026/10/8	high
363766	RHEL 8：内核 (RHSA-2026:77216)	Nessus	Red Hat Local Security Checks	2026/10/7	2026/10/21	critical
363823	RHEL 8：内核 (RHSA-2026:77301)	Nessus	Red Hat Local Security Checks	2026/10/7	2026/10/21	high
343045	Linux Distros 未修补的漏洞：CVE-2026-80863	Nessus	Misc.	2026/9/4	2026/10/21	high
365191	Amazon Linux 2：内核 (ALASKERNEL-5.10-2026-133)	Nessus	Amazon Linux Local Security Checks	2026/10/12	2026/10/19	high
343851	Debian dla-4777：ata-modules-6.1.0-52-armmp-di - 安全更新	Nessus	Debian Local Security Checks	2026/9/8	2026/9/8	high
359534	Rocky Linux 8.6 [CIQ] 安全更新：bpftool / kernel / kernel-abi-stablelists / kernel-core / 等多种漏洞（ciqsa-2026_1573）	Nessus	Rocky Linux Local Security Checks	2026/10/1	2026/10/12	high
366513	Rocky Linux 9.6 [CIQ] 安全更新：kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc 多个漏洞（ciqsa-2026_1641）	Nessus	Rocky Linux Local Security Checks	2026/10/16	2026/10/23	high
363461	CentOS 9: kernel-5.14.0-756.el9	Nessus	CentOS Local Security Checks	2026/10/6	2026/10/8	critical
351155	Debian dsa-6528：ata-modules-6.12.111+deb13-armmp-di - 安全更新	Nessus	Debian Local Security Checks	2026/9/29	2026/9/29	high
362907	Debian dla-4817：ata-modules-6.12.107+deb12-armmp-di - 安全更新	Nessus	Debian Local Security Checks	2026/10/4	2026/10/4	high
363954	Oracle Linux 8/9：Unbreakable Enterprise 内核 (ELSA-2026-500377)	Nessus	Oracle Linux Local Security Checks	2026/10/7	2026/10/7	high
363817	RHEL 8：内核 (RHSA-2026:77217)	Nessus	Red Hat Local Security Checks	2026/10/7	2026/10/21	high
364148	RHEL 9：内核 (RHSA-2026:77219)	Nessus	Red Hat Local Security Checks	2026/10/8	2026/10/21	medium
359533	Rocky Linux 9.2 [CIQ] 安全更新：bpftool / kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc 多种漏洞（ciqsa-2026_1575）	Nessus	Rocky Linux Local Security Checks	2026/10/1	2026/10/23	high

检测

插件搜索

critical

high

critical

high

high

high

high

high

high

critical

high

high

high

high

medium

high