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

  - crypto：atmel-sha204a - 修复删除路径中潜在的 UAF 和内存泄漏 取消注册 hwrng 以防止新的 ->read（） 调用并在拆卸之前刷新 Atmel I2C 工作队列，以防止在设备删除时运行排队回调时可能出现 UAF。终止过早返回以确保删除 sysfs 条目并释放 ->hwrng.priv，从而防止内存泄漏。（CVE-2026-46075）

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

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

  - ext4：修复 ext4_ext_shift_extents（） 中的内存泄漏 在 ext4_ext_shift_extents（） 中，如果 while 循环中的盘区为空，函数会立即返回而不释放通过 ext4_find_extent（） 获取的路径，从而导致内存泄漏。通过跳转到 out 标签确保正确释放路径修复此问题。（CVE-2026-45948）

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

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

  - RDMA/rxe：修复 rxe_srq_from_init 中的双重释放 在 rxe_srq_from_init（） 中，队列指针“q”分配给“srq->rq.queue”，然后再将 SRQ 编号复制到用户空间。如果 copy_to_user（） 失败，该函数将调用 rxe_queue_cleanup（） 以释放队列，但将现在无效的指针留在“srq->rq.queue”中。rxe_srq_from_init（） （rxe_create_srq） 的调用程序最终在收到错误时调用 rxe_srq_cleanup（），这会在相同内存上触发第二个 rxe_queue_cleanup（），从而导致双重释放。调用跟踪如下所示：kmem_cache_free+0x.../0x...rxe_queue_cleanup+0x1a/0x30 [rdma_rxe] rxe_srq_cleanup+0x42/0x60 [rdma_rxe] rxe_elem_release+0x31/0x70 [rdma_rxe] rxe_create_srq+0x12b/0x1a0 [rdma_rxe] ib_create_srq_user+0x9a/0x150 [ib_core] 通过在copy_to_user后移动“srq->rq.queue = q”来修复此问题。（CVE-2026-45852）

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

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

  - Bluetooth：hci_event：修复 SSP 密钥处理程序中潜在的 UAF hci_conn查找和字段访问必须由 hci_user_passkey_notify_evt（） 和 hci_keypress_notify_evt（） 中的 hdev 锁定覆盖，否则可同时释放连接。扩展hci_dev_lock关键部分以涵盖两个处理程序中的所有 conn 使用情况。通过通用解锁路径路由提早退出，来保持现有按键通知行为不变。（CVE-2026-46056）

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

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

  - ext4：拆分盘区期间不缓存盘区 拆分过程中缓存盘区存在风险，因为这可能导致过时盘区保留在状态树中。此外，在大多数情况下，相应的盘区块条目很可能在拆分发生之前就已经缓存，因此此处的缓存并不是特别有用。假设我们有一个未写入的范围，然后 DIO 写入前半部分。
    [UUUUUUUUUUUUUUUUUU] 磁盘盘区 U：未写入盘区 [UUUUUUUUUUUUUUUUU] 盘区状态树 |<- ->|----> dio 写入此范围 首先，当 ext4_split_extent_at（） 拆分此盘区时，它会截断现有盘区，然后插入一个新盘区。在此过程中，此盘区状态条目可能会被缩小，并且可能会调用 ext4_find_extent（） 和 ext4_cache_extents（），从而可能会将截断的范围作为漏洞插入盘区状态树中。分割完成后，该孔不会被替换为正确的状态。[呜呜|UUUUUUUU] 磁盘盘区 U：未写入盘区 [UUUUUUU|HHHHHHH] 范围状态树 H：漏洞 然后，外部调用函数也不会修正这个剩余的漏洞范围。
    最后，如果我们在后一部分执行延迟缓冲区写入，它将重新插入延迟盘区并导致空间核算中的错误。此外，如果未写入的盘区缓存在拆分期间未缩小，ext4_cache_extents（） 也会在缓存盘区时与现有盘区发生冲突。将来，我们将在缓存盘区时添加检查，这将触发警告。因此，不要缓存正在拆分的盘区。（CVE-2026-45912）

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

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

  - ntfs3：修复 run_unpack（） 卷边界检查中的整数溢出 卷边界检查“lcn + len > sbi->used.bitmap.nbits”使用原始加法，该加法可针对较大的 lcn 和 len 值进行封装，从而绕过验证。使用check_add_overflow（），如已对相邻 prev_lcn + dlcn 和 vcn64 + 提交 3ac37e100385 添加的 len 检查（ntfs3： 修复 run_unpack（）） 中的整数溢出）。通过使用源修补的工具 （LibAFL + QEMU） 进行模糊测试发现。（CVE-2026-46062）

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

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

  - spi：修复设备设置失败时的资源泄漏 在注册设备时，如果 spi_setup（） 失败，请务必调用控制器 cleanup（），以免泄漏 setup（） 分配的任何资源。（CVE-2026-46083）

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

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

  - bonding：alb：修复绑定启动/关闭期间rlb_arp_recv中的 UAF ALB RX 路径可在绑定拆卸的同时访问rx_hashtbl。在快速绑定启动/关闭周期期间，rlb_deinitialize（） 会在 RX 处理程序仍在运行时释放rx_hashtbl，从而导致 KASAN 检测到空指针取消引用。但是，根本原因是将 recv_probe 设置为 NULL 后仍可访问 rlb_arp_recv（），这实际上是释放后使用 （UAF） 问题。这就是在 Fixes 标签中使用引用的提交的原因。[ 214.174138] 错误：一般保护错误，可能针对非规范地址0xdffffc000000001d：
    0000 [#1] SMP KASAN PTI [ 214.186478] KASAN：范围内的 null-ptr-deref [0x00000000000000e8-0x00000000000000ef] [ 214.194933] CPU：30 UID：0 PID：2375 Comm：ping Kdump：已加载 未受感染 6.19.0-rc8+ #2 PREEMPT（自愿性） [ 214.205907] 硬件名称：Dell Inc. PowerEdge R730/0WCJNT，BIOS 2.14.0 2022 年 1 月 14 日 [ 214.214357] RIP：0010：rlb_arp_recv+0x505/0xab0 [bonding] [214.220320] 代码：0f 85 2b 05 00 00 00 48 b8 00 00 00 00 FC FF DF 40 0f b6 ed 48 C1 E5 06 49 03 AD 78 01 00 00 48 8D7d 28 48 89 FA 48 C1 EA 03 <0f> B6 04 02 84 C0 74 06 0f 8E 12 05 00 00 80 7d 28 00 0f 84 8c 00 [ 214.241280] RSP：0018：ffffc900073d8870 EFLAGS：00010206 [ 214.247116] RAX：dffffc0000000000 RBX：
    ffff888168556822 RCX： ffff88816855681e [ 214.255082] RDX： 000000000000001d RSI： dffffc00000000000 RDI：
    00000000000000e8 [ 214.263048] RBP： 000000000000000c0 R08： 0000000000000002 R09： ffffed11192021c8 [214.271013] R10： ffff8888c9010e43 R11： 0000000000000001 R12： 1ffff92000e7b119 [ 214.278978] R13：
    ffff8888c9010e00 R14： ffff888168556822 R15： ffff888168556810 [ 214.286943] FS： 00007f85d2d9cb80（0000） GS：ffff88886ccb3000（0000） knlGS：000000000000000 [ 214.295966] CS：0010 DS：0000 ES：0000 CR0：
    0000000080050033 [ 214.302380] CR2： 00007f0d047b5e34 CR3： 00000008a1c2e002 CR4： 000000000001726f0 [214.310347] 调用跟踪： [ 214.313070] <IRQ> [ 214.315318] ？ __pfx_rlb_arp_recv+0x10/0x10 [bonding] [214.320975] bond_handle_frame+0x166/0xb60 [bonding] [ 214.326537] ？ __pfx_bond_handle_frame+0x10/0x10 [bonding] [ 214.332680] __netif_receive_skb_core.constprop.0+0x576/0x2710 [ 214.339199] ？
    __pfx_arp_process+0x10/0x10 [ 214.343775] ？ sched_balance_find_src_group+0x98/0x630 [ 214.349513] ？
    __pfx___netif_receive_skb_core.constprop.0+0x10/0x10 [ 214.356513] ？ arp_rcv+0x307/0x690 [ 214.360311] ？
    __pfx_arp_rcv+0x10/0x10 [ 214.364499] ？ __lock_acquire+0x58c/0xbd0 [ 214.368975]
    __netif_receive_skb_one_core+0xae/0x1b0 [ 214.374518] ？ __pfx___netif_receive_skb_one_core+0x10/0x10 [214.380743] ？ lock_acquire+0x10b/0x140 [ 214.385026] process_backlog+0x3f1/0x13a0 [ 214.389502] ？ process_backlog+0x3aa/0x13a0 [ 214.394174] __napi_poll.constprop.0+0x9f/0x370 [ 214.399233] net_rx_action+0x8c1/0xe60 [ 214.403423] ？ __pfx_net_rx_action+0x10/0x10 [ 214.408193] ？ lock_acquire.part.0+0xbd/0x260 [ 214.413058] ？ sched_clock_cpu+0x6c/0x540 [ 214.417540] ？ mark_held_locks+0x40/0x70 [ 214.421920] handle_softirqs+0x1fd/0x860 [ 214.426302] ？
    __pfx_handle_softirqs+0x10/0x10 [ 214.431264] ？ __neigh_event_send+0x2d6/0xf50 [ 214.436131] do_softirq+0xb1/0xf0 [ 214.439830] </IRQ> 通过在接收 ARP 消息时反复运行 ip link set bond0 来重现此问题，其中 rlb_arp_recv（） 可与 rlb_deinitialize（） 争用并取消引用已释放的 rx_hashtbl 条目。通过将 recv_probe 设置为 NULL 然后调用 synchronize_net（） 以等待任何并发 RX 处理完成来修复此问题。这样可以确保在 bond_alb_deinitialize（） 中释放rx_hashtbl之后，任何 RX 处理程序都无法访问它。（CVE-2026-45970）

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

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

  - ALSA：caiaq：正确处理探测错误 caiaq 驱动程序中 setup_card（） 的探测过程未妥善处理错误情况，例如来自 snd_card_register（） 的错误会调用 snd_card_free（），但会继续处理。这将导致用于 snd_usb_caiaq_control_init（） 等进一步调用的 UAF，正如 Berk 在下面链接中的另一个修补程序中所建议的那样。然而，问题不仅如此;通常，尽管调用者可以将错误传播到 snd_probe（），最终调用 snd_card_free（） 作为适当的错误路径，但此函数会终止所有错误处理（因为它是 void 函数）。也就是说，我们应当处理 setup_card（） 中的每个错误情况，并及时返回错误代码，然后将其作为 snd_probe（） 中的致命错误进行处理。此修补程序通过更改 setup_card（） 以返回错误代码来实现此目的。此外，还删除了多余的 snd_card_free（） 调用。请注意，返回错误时仍可安全地设置 card->private_free。card_free（） 中所有调用的函数都检查了未分配的资源或 NULL 检查。（CVE-2026-46004）

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

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

  - fbdev：au1200fb：修复 au1200fb_drv_probe（） 中的内存泄漏 在 au1200fb_drv_probe（） 中，当 platform_get_irq fails（） 时，它会直接从函数返回错误代码，这会造成内存泄漏。请将其替换为转至标签以确保正确清理。（CVE-2026-45954）

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

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

  - ibmasm：修复 command_file_write 中因缺少大小检查而导致的 OOB 读取 command_file_write（） 处理程序分配精确计数字节的内核缓冲区并将用户数据复制到其中，但在将缓冲区传递到 get_dot_command_size（） 和 get_dot_command_timeout（） 之前未根据 dot 命令协议对缓冲区进行验证。由于分配大小 （count） 和标头字段 （command_size、data_size） 均独立由用户控制，攻击者可造成 get_dot_command_size（） 返回超出分配的值，从而触发 get_dot_command_timeout（） 中的 OOB 读取和越界 memcpy_toio（），将内核堆内存泄漏给服务处理器。使用双防护进行修复：拒绝分配前小于 sizeof（struct dot_command_header） 的写入，然后在复制用户数据后拒绝缓冲区小于标头声明的总大小的命令 （sizeof（header） + command_size + data_size）。这可确保所有后续标头和负载字段访问都停留在缓冲区内。（CVE-2026-45994）

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

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

  - selinux：修复 overlayfs mmap（） 和 mprotect（） 访问检查 overlayfs 的现有 SELinux 安全模型会在当前任务能够访问顶级文件（用户文件）且挂载者的凭据足以访问较低级别文件（后备文件）的情况下允许访问。
    遗憾的是，当前代码未对 overlayfs 文件系统上的 mmap（） 和 mprotect（） 操作正确实施这些访问控制。此修补程序利用新创建的 security_mmap_backing_file（） LSM 挂钩为 mmap（） 操作提供缺少的后备文件实施，并利用后备文件 API 和新的 LSM blob 提供必要信息以正确实施 mprotect（） 访问控制。（CVE-2026-46054）

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

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

  - power：supply：cpcap-battery：修复 power_supply_changed（） 中的释放后使用 _before_ 请求 IRQ 的“devm_”变体 用于分配/注册“power_supply”句柄的“devm_”变体意味着“power_supply”句柄将在中断处理程序之前 _ 解除分配/取消注册（因为“devm_”自然会以反向分配顺序释放）。这意味着删除过程中存在争用条件，其中，中断可能恰好在释放了“power_supply”句柄后，*但是* 恰好在 IRQ 处理程序的相应取消注册运行之前触发。这将导致 IRQ 处理程序通过释放的“power_supply”句柄调用“power_supply_changed（）”。这通常会使系统崩溃或以其他方式静默地损坏内存... 请注意，在“probe（）”期间也可能发生类似的情况;_before_ 注册“power_supply”句柄时中断触发的可能性。然后，这将导致使用“power_supply_changed（）”中使用“power_supply”句柄 *uninitialized* 的糟糕情况。通过确保在注册“power_supply”句柄后 _ 请求 IRQ，修复了此 racy 释放后使用。（CVE-2026-45885）

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

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

  - FastNetMon Community Edition through 1.2.9 存在越界内存访问权限，因为它未正确解析设置了扩展长度标记的 BGP 路径属性。在 src/bgp_protocol.hpp 中，parse_raw_bgp_attribute（） 函数可正确识别何时设置 extended_length_bit 并将 length_of_length_field 设为 2，但随后仅读取属性值长度的单个字节（第 173 行的 attribute_value_length = value[2]）。根据 RFC 4271 部分 4.3，当设置扩展长度位时，属性长度字段为两个八进制数，该值应从 value[2] 和 value[3] 读取为 16 位大端整数。因此，任何长度超过 255 字节的属性都会静默截断为低位字节（例如，300 字节 = 0x012C 会读取为 0x2C = 44 字节）。剩余的 256 字节随后会被错解释为后续属性，从而导致级联解析失败和潜在的越界内存访问。（CVE-2026-48685）

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

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

  - SUNRPC：auth_gss：修复 XDR 解码错误路径中的内存泄漏 gssx_dec_ctx（）、gssx_dec_status（） 和 gssx_dec_name（） 函数通过调用 kmemdup（） 的 gssx_dec_buffer（） 分配内存。当后续的解码操作失败时，这些函数将立即返回而不释放之前分配的缓冲区，从而导致内存泄漏。gssx_dec_ctx（） 中的泄露特别相关，因为调用程序 （gssp_accept_sec_context_upcall） 将多个缓冲区长度字段初始化为非零值，从而导致内存分配：struct gssx_ctx rctxh = { .exported_context_token.len = GSSX_max_output_handle_sz， .mech.len = GSS_OID_MAX_LEN， .src_name.display_name.len = GSSX_max_princ_sz， .targ_name.display_name.len = GSSX_max_princ_sz };例如，如果 gssx_dec_name（） 对 src_name 成功但对 targ_name 失败，则分配给 exported_context_token、mech 和 src_name.display_name 的内存将保持未引用且无法回收。通过基于 goto 的清理添加错误处理，以在返回错误之前释放任何以前分配的缓冲区。（CVE-2026-45870）

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

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

  - FastNetMon Community Edition 通过 1.2.9 /tmp 中容易受到通过可预测文件路径进行的本地符号链接攻击。统计数据文件路径默认为“/tmp/fastnetmon.dat”（src/fastnetmon.cpp第 159 行）。
    print_screen_contents_into_file（） 函数（src/fastnetmon_logic.cpp 第 2186 行）通过 std：：ios：：trunc 打开此路径，而不检查符号链接或使用O_NOFOLLOW。此外，无论传递了哪个 file_path 参数，第 2190 行上的 chmod（） 调用始终对cli_stats_file_path起作用（应用错误权限的缺陷），并且在后台程序化期间 umask 设置为 0（src/fastnetmon.cpp第 1821 行），从而使创建的所有文件全局可写。本地攻击者可利用此漏洞，以 FastNetMon 进程用户（通常为根用户）的身份覆盖任意文件。（CVE-2026-48693）

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

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

  - hfsplus：当节点已存在于 hfs_bnode_create 中时返回错误 当 hfs_bnode_create（） 发现某个节点已经过哈希处理（在正常操作中应该不会发生这种情况）时，它当前返回现有节点，而不增加其引用计数。这会导致引用计数不一致，导致稍后在 hfs_bnode_put（） 中释放该节点时出现内核错误： fs/hfsplus/bnode.c：676！BUG_ON（！atomic_read（&node->refcnt）） 当 hfs_bmap_alloc（） 尝试分配已在使用的节点时（例如，节点 0 的位图位未正确取消设置时）或由于文件系统损坏，可能会出现这种情况。从创建路径返回现有节点不是正常操作。通过返回 ERR_PTR（-EEXIST） 而不是已哈希的节点来修复此问题。这会向已检查 IS_ERR（） 返回值的调用程序正确地发出错误信号。（CVE-2026-45960）

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

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

  - ibmasm：修复 ibmasm_send_i2o_message（） 中的堆过度读取 ibmasm_send_i2o_message（） 函数使用 get_dot_command_size（） 计算 memcpy_toio（） 的字节计数，但此值派生自dot_command_header中受用户控制的字段（command_size：u8、data_size：u16），并且从不根据实际分配大小进行验证。根用户可以包含已膨胀的标头字段写入小型缓冲区，从而使 memcpy_toio（） 在超过分配末尾后向相邻内核堆中读取最多 ~65 KB，然后通过 MMIO 将其转发到服务处理器。静默地限制副本大小是不够的：
    如果标头字段声明的大小大于缓冲区，则 SP 会收到一个 dot 命令，其自身的标头与 I2O 消息长度不一致，这可造成 SP 不同步。通过返回失败来彻底拒绝此类命令。在调用 get_mfa_inbound（） 之前验证command_size，避免泄漏 I2O 消息帧：读取INBOUND_QUEUE_PORT会将硬件帧从控制器的空闲池中出列，并且返回而不进行相应的 set_mfa_inbound（） 调用将永久耗尽该帧。此外，在 memcpy_toio（） 之前将command_size钳制为 I2O_COMMAND_SIZE，以便 MMIO 写入停留在 I2O 消息帧内，这与 outgoing_message_size（） 已针对标头字段执行的钳制一致。（CVE-2026-46064）

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

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

  - drm/nouveau：修复 pushbuf 重定位边界检查中的 u32 溢出 nouveau_gem_pushbuf_reloc_apply（） 使用 IF （r->reloc_bo_offset + 4 > nvbo->bo.base.size） 来验证每次重定位，但reloc_bo_offset是 __u32 （uapi/drm/nouveau_drm.h） 并且整数文字 4 提升为无符号 int，因此加法以 32 位执行，并在与 size_t bo 大小进行比较之前进行封装。转换为 u64，以便以 64 位算法进行加法。[ 添加 Fixes： 标签。- 达尼洛 ] （CVE-2026-46006）

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

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

  - spi：imx：修复取消绑定时的释放后使用 SPI 子系统在注销过程中释放控制器和任何子系统分配的驱动程序数据（除非分配由设备管理）。在注销控制器之前，请进行另一个引用，以便在驱动程序完成使用之前不会释放驱动程序数据。
    (CVE-2026-45996)

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

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

  - smack：/smack/doi：接受之前使用的值 写入过去曾写入该处的值至 /smack/doi 会禁用非环境标签的网络。例如 # cat /smack/doi 3 # netlabelctl -p 密码列表 已配置 CIPSO 映射 （1） DOI 值：3 映射类型：PASS_THROUGH # netlabelctl -p 映射列表 已配置 NetLabel 域映射 （3） 域：_ （IPv4） 协议：无标签域：默认 （IPv4） 协议：CIPSO，DOI = 3 域：默认 （IPv6） 协议：无标签 # cat /smack/ambient _ # cat /proc/$$/attr/smack/current _ # ping -c1 10.1.95.12 64 字节来自 10.1.95.12：icmp_seq=1 ttl=64 time=0.964 ms # echo foo >/proc/$$/attr/smack/current # ping -c1 10.1.95.12 64 字节来自 10.1.95.12： icmp_seq=1 ttl=64 time=0.956 ms unknown option 86 # echo 4 >/smack/doi # echo 3 >/smack/doi ！> [ 214.050395] smk_cipso_doi：691 cipso add rc = -17 # echo 3 >/smack/doi ！> [ 249.402261] smk_cipso_doi：678 删除 rc =
    -2 ！> [ 249.402261] smk_cipso_doi：691 cipso add rc = -17 # ping -c1 10.1.95.12 ！！> ping： 10.1.95.12
    不支持主机名的地址系列 # echo _ >/proc/$$/attr/smack/current # ping -c1 10.1.95.12 64 字节来自 10.1.95.12：icmp_seq=1 ttl=64 时间=0.617 ms 发生这种情况是因为 Smack 保留已停用的 DOI，未能重新添加它们，因此拒绝添加默认域映射：# netlabelctl -p 密码列表 已配置的 CIPSO 映射 （2） DOI 值： 3 映射类型： PASS_THROUGH DOI 值： 4 映射类型：PASS_THROUGH # netlabelctl -p 映射列表 配置的 NetLabel 域映射 （2） 域：_ （IPv4） 协议：UNLABELED ！>（此处无默认域的 IPv4 映射） 域：默认 （IPv6） 协议：UNLABELED 通过清除已停用的 DOI 定义并使用新锁序列化并发 DOI 更新进行修复。
    此外：- 允许 /smack/doi 处于未配置状态，因为添加映射 （netlbl_cfg_cipsov4_map_add） 可能会失败。
    CIPSO_V4_DOI_UNKNOWN（0） 表示未配置的 DOI - 在删除旧的默认映射之前添加新的 DOI，以便在添加失败时保留旧映射 （2008-02-04， Casey Schaufler） （CVE-2025-71304）

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

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

  - ceph：未哈希时仅 d_add（） 负 dentry Ceph 可在主 dcache 哈希中已存在的负 dentry 上调用 d_add（dentry， NULL）。在当前的 VFS 中，这是不安全的。
    d_add（） 通过 __d_add（） 到 __d_rehash（），这样会无条件地将 dentry->d_hash 重新插入 hlist_bl 存储段。如果 dentry 已经哈希，重新插入相同的节点可损坏存储段，包括创建自循环。一旦发生此情况，__d_lookup（） 会在 hlist_bl walk 中一直旋转，通常只会在 d_name.hash 不匹配检查时循环，最终触发 RCU 停止报告，如下所示：rcu： INFO： rcu_sched CPU 上自我检测到的停止 rcu： 87-....：（此 GP 2100 刻度） idle=3a4c/1/0x4000000000000000 softirq=25003319/25003319 fqs=829 rcu： （t=2101 jiffies g=79058445 q=698988 ncpus=192） CPU： 87 UID：2952868916 PID：3933303 通信：php-cgi8.3 未受感染 6.18.17-i1-amd #950 无 硬件名称：Dell Inc. PowerEdge R7615/0G9DHV，BIOS 1.6.6 09/22/2023 RIP：0010：__d_lookup+0x46/0xb0 代码：c1 e8 07 48 8d 04 c2 48 8b 00 49 89 fc 49 89 f5 48 89 c3 48 83 e3 fe 48 83 f8 01 77 0f eb 2d 0f 1f 44 00 00 48 8b 1b 48 85 db <74> 20 39 6b 18 75 f348 8d 7b 78 e8 ba 85 d0 00 4c 39 63 10 74 1f RSP：
    0018：ff745a70c8253898 EFLAGS：00000282 RAX：ff26e470054cb208 RBX：ff26e470054cb208 RCX：000000006e958966 RDX：ff26e48267340000 RSI：ff745a70c82539b0 RDI：ff26e458f74655c0 RBP：000000006e958966 R08：
    0000000000000180 R09： 9cd08d909b919a89 R10： ff26e458f74655c0 R11： 0000000000000000 R12： ff26e458f74655c0 R13： ff745a70c82539b0 R14： d0d0d0d0d0d0 R15： 2f2f2f2f2f2f2f2f FS： 00007f5770896980（0000） GS：ff26e482c5d88000（0000） knlGS：000000000000000 CS： 0010 DS： 0000 ES： 0000 CR0： 0000000080050033 CR2：
    00007f5764de50c0 CR3： 000000a72abb5001 CR4： 0000000000771ef0 PKRU： 55555554 调用跟踪： <TASK> lookup_fast+0x9f/0x100 walk_component+0x1f/0x150 link_path_walk+0x20e/0x3d0 path_lookupat+0x68/0x180 filename_lookup+0xdc/0x1e0 vfs_statx+0x6c/0x140 vfs_fstatat+0x67/0xa0 __do_sys_newfstatat+0x24/0x60 do_syscall_64+0x6a/0x230 entry_SYSCALL_64_after_hwframe+0x76/0x7e 这可以通过重用的缓存负 dentry 实现。Ceph 查找或atomic_open可向已哈希的负目录项传递，然后 fs/ceph/dir.c 命中错误假设负也意味着未哈希的两条路径之一：- ceph_finish_lookup（）：MDS 回复为 -ENOENT，没有跟踪 -> d_add（dentry， NULL） - ceph_lookup（）：具有共享端点的完整目录的本地 ENOENT 快速路径 -> d_add（dentry， NULL）因此，这两个路径都可以重新添加已哈希的负 dentry。Ceph 已在其他地方使用正确的模式：
    仅当 d_unhashed（dn） 为真时，ceph_fill_trace（） 才会调用 d_add（dn， NULL） 以获取负的 null-dentry 回复。
    以相同的方式修复两个 fs/ceph/dir.c 站点：仅当实际未哈希负目录项调用 d_add（）。如果已对负目录项执行哈希处理，请将其保留并按原样重复使用。这样可保留未哈希的 dentry 的现有行为d_hash同时避免因重用的哈希负值而导致的列表损坏。（CVE-2026-46052）

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

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

  - rbd：修复 device_add_disk（） 失败时的 null-ptr-deref do_rbd_add（） 在调用 device_add_disk（） 之前发布具有 device_add（） 的设备。如果 device_add_disk（） 在 device_add（） 成功后失败，错误路径会直接调用 rbd_free_disk（），然后转向 rbd_dev_device_release（），后者会再次调用 rbd_free_disk（）。此双重拆卸可使 blk-mq 清理在无效状态下运行并触发 __blk_mq_free_map_and_rqs（） 中的 null-ptr-deref（），从 blk_mq_free_tag_set（） 到达。通过遵循正常的删除排序来修复此问题：当 device_add_disk（） 在 device_add（） 之后失败时，在 rbd_dev_device_release（） 之前调用 device_del（）。如此可保持拆卸序列的一致性，并避免通过错误路径重新输入磁盘清理。我们正在开发的用于内核内存管理缺陷的实验性分析工具在分析 v6.13-rc1 时，首先标记此缺陷。该工具仍在开发中，尚未公开可用。我们在 v7.0 上，使用真正的 Ceph 后端和启用 KASAN 和 CONFIG_FAILSLAB 引导的 QEMU x86_64来宾机重现了该错误。复制器将 failslab 注入限制在 __add_disk（） 范围内，并通过 /sys/bus/rbd/add_single_major 映射 RBD 图像时注入 fail-nth。在未经修复的内核上，fail-nth=4 可靠地触发了该错误：哎呀：
    一般保护错误，可能针对非规范地址 0xdffffc0000000000：0000 [#1] SMP KASAN NOPTI KASAN：范围 [0x0000000000000000-0x0000000000000007] 中的 null-ptr-deref CPU：0 UID：0 PID：273 Comm：bash 未受感染 7.0.0-01247-gd60bc1401583 #6 PREEMPT（lazy） 硬件名称：QEMU Standard PC （Q35 + ICH9， 2009）， BIOS 1.15.0-1 04/01/2014 RIP： 0010：__blk_mq_free_map_and_rqs+0x8c/0x240 代码： 00 00 48 8b 6b 60 41 89 f4 49 c1 e4 03 4c 01 e5 45 85 ed 0f 85 0a 01 0000 48 b8 00 00 00 00 00 00 FC FF DF 48 89 e9 48 c1 e9 03 <80> 3c 01 00 0f 85 31 01 00 00 4c 8b 6d 00 4d 85 ed 0f 84 e2 00 00 RSP： 0018：ff1100000ab0fac8 EFLAGS： 00000246 RAX： dffffc00000000000 RBX： ff11000000c4806a0 RCX： 00000000000000000 RDX： 0000000000000002 RSI：
    00000000000000000 RDI： ff1100000c4806f4 RBP： 00000000000000000 ： 0000000000000001 R09： ffe21c000189001b R10： ff1100000c4800df R11： ff1100006cf37be0 R12： 00000000000000000 R13： 00000000000000000 R14：R08
    ff1100000c480700 R15： ff1100000c480004 FS： 00007f0fbe8fe740（0000） GS：ff110000e5851000（0000） knlGS：000000000000000 CS： 0010 DS： 0000 ES： 0000 CR0： 0000000080050033 CR2： 00007fe53473b2e0 CR3：
    0000000012eef000 CR4： 00000000007516f0 PKRU： 55555554 调用跟踪： <TASK> blk_mq_free_tag_set+0x77/0x460 do_rbd_add+0x1446/0x2b80 ？ __pfx_do_rbd_add+0x10/0x10 ？ lock_acquire+0x18c/0x300 ？ find_held_lock+0x2b/0x80 ？ sysfs_file_kobj+0xb6/0x1b0 ？ __pfx_sysfs_kf_write+0x10/0x10 kernfs_fop_write_iter+0x2f4/0x4a0 vfs_write+0x98e/0x1000 ？ expand_files+0x51f/0x850 ？
    __pfx_vfs_write+0x10/0x10 ksys_write+0xf2/0x1d0 ？__pfx_ksys_write+0x10/0x10 do_syscall_64+0x115/0x690 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP：0033：0x7f0fbea15907 代码：10 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 4889 54 24 18 48 89 74 24 RSP：002b：00007ffe22346ea8 EFLAGS：00000246 ORIG_RAX：0000000000000001 RAX：ffffffffffffffda RBX：0000000000000058 RCX：00007f0fbea15907 RDX：
    0000000000000058 RSI：0000563ace6c0ef0 RDI：0000000000000001 RBP：0000563ace6c0ef0：0000563ace6c0ef0R09：6b6435726d694141R10：5250337279762f78R11：0000000000000246R12：0000000000000058R13：R08
    00007f0fbeb1c780 R14： ff1100000c480700 R15： ff1100000c480004 </TASK> 应用此补丁之后，通过 fail-nth=1..256 重新运行复制程序不会产生任何 KASAN 报告。[ idryomov：重命名 err_out_device_del -> err_out_device ]（CVE-2026-46079）

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

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

  - KVM：nSVM：在 L2 的 VMRUN 之后将中断阴影同步到缓存的 vmcb12 在访客模式下 VMRUN 之后，nested_sync_control_from_vmcb02（） 会将 CPU 写入的字段从 vmcb02 同步到缓存的 vmcb12。这是因为缓存的 vmcb12 被用作某些控件的授权副本，并且是保存/还原嵌套状态时的负载。int_state同样由 CPU 写入，特别是位 0（即
    SVM_INTERRUPT_SHADOW_MASK），但其未同步至缓存的 vmcb12。如果KVM_SET_NESTED_STATE在还原路径中处于KVM_SET_VCPU_EVENTS之前，这不会造成问题，因为中断阴影将被正确地还原到 vmcb02（KVM_SET_VCPU_EVENTS会覆盖KVM_SET_NESTED_STATE在 int_state 中还原的内容）。但是，如果KVM_SET_VCPU_EVENTS先于KVM_SET_NESTED_STATE，则中断阴影将被还原为 vmcb01，而不是 vmcb02。这对 L1 而言大多是良性的（延迟中断），但对于 L2 则不然。对于 L2，vCPU 可能挂起（例如，如果唤醒中断在应处于中断阴影中的 HLT 之前提供）。将int_state同步到 nested_sync_control_from_vmcb02（） 中缓存的 vmcb12 以避免此问题。这样，KVM_SET_NESTED_STATE 就可以恢复正确的中断阴影状态，如果随后发生KVM_SET_VCPU_EVENTS，它将使用相同的值对其进行覆盖。（CVE-2026-45987）

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

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

  - net：bridge：在 RCU 读取器中使用稳定的 FDB dst 快照 本地 FDB 条目可通过“fdb_delete_local（）”就地重写，它会将“f->dst”更新到另一个端口或“NULL”，同时保持条目活动。
    多个桥接 RCU 读取器检查“f->dst”，包括通过“brforward_read（）”sysfs 路径的“br_fdb_fillbuf（）”。这些阅读器当前会多次加载“f->dst”，因此会观察到在检查期间和之后的取消引用值不一致。在“br_fdb_fillbuf（）”中，这表示并行 local-FDB 更新可在 NULL 检查之后和“port_no”取消引用之前更改“f->dst”，从而导致 NULL-ptr-deref。通过在每个受影响的 RCU 读取器中拍摄“f->dst”的单个“READ_ONCE（）”快照并将该快照用于访问序列的其余部分来修复此问题。还将就位的“f->dst”更新发布在内的“fdb_delete_local（）”中使用“WRITE_ONCE（）”以便读写器使用匹配的访问模式。
    (CVE-2026-46086)

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

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

  - crypto：authencesn - 拒绝实例创建期间的短 ahash 摘要 authencesn 需要 0 认证大小或至少为 4 字节的认证大小，因为 ESN 加密/解密路径始终在认证数据的末尾移动 4 字节的高位序列号数据。尽管 crypto_authenc_esn_setauthsize（） 已经拒绝范围 1..3 中明确的非零 authsizes，crypto_authenc_esn_create（） 仍然将 auth->digestsize 复制到 inst->alg.maxauthsize 中，而未对其进行验证。然后，AEAD 核心会根据该值初始化 tfm 的默认认证大小。因此，选择摘要大小为 1..3 的 ahash（如 cbcmac（cipher_null）会暴露默认 authsize 无效的 authencesn 实例，即使 setauthsize（） 会拒绝相同值也是如此。然后AF_ALG可能触发具有过短标签的 ESN 末尾处理并命中越界访问。拒绝其 ahash 摘要大小处于无效的非零范围 1..3 的 authencesn 实例，以便任何 tfm 都可继承不受支持的默认认证大小。（CVE-2026-46033）

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

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

  - iio：sca3000：修复当 iio_device_register（） 失败时未释放来自 request_threaded_irq（） 的 sca3000_probe（） spi->irq 中的一个资源泄漏。添加返回值检查，并在 iio_device_register（） 失败时跳至通用错误处理程序。（CVE-2026-45883）

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

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

  - KVM：nSVM：如果在嵌套 #VMEXIT 上还原主机 CR3 失败，则会造成三重错误 如果在嵌套 #VMEXIT 上加载 L1 的 CR3 失败，则 nested_svm_vmexit（） 会返回大多数调用方忽略的错误代码，并继续以损坏的状态运行 L1。在此情况下不可能实现健全的恢复，而 HW 行为将导致关机。转而注入三重错误，并且不从 nested_svm_vmexit（） 提早返回。继续清理 vCPU 状态（如：清除待定异常），以尽可能妥善地处理失败。来自 APM：#VMEXIT 后，处理器执行以下操作以返回主机执行环境：...如果（加载了非法主机状态，或加载主机状态时出现异常）关闭，否则 执行 VMRUN 之后的第一个主机指令删除 nested_svm_vmexit（） 的返回值，其大部分情况下都未经检查。（CVE-2026-46032）

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

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

  - FastNetMon Community Edition 及之前版本 1.2.9 在 NetFlow v9 数据流集处理器中包含一个越界读取漏洞。在 src/netflow_plugin/netflow_v9_collector.cpp 中，数据模板分支（行 1695-1702）迭代流记录，而不对数据包端指针执行每次迭代的边界检查。相反，选项模板分支（行 1709-1719）在每次迭代之前正确检查“if （pkt + offset + field_template->total_length > packet_end）”。Data 分支完全省略此检查。由于模板定义是由网络对等机发送的（并且是未经认证的 UDP），攻击者可构建模板来导致解析器读取超出数据包缓冲区的任意内存。这可能会泄露敏感内存内容或造成崩溃。（CVE-2026-48683）

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

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

  - zram：不忘记为部分丢弃请求执行 endio 据 Qu Wenruo 和 Avinesh Kumar 报告，以下 getconf PAGESIZE 65536 blkdiscard -p 4k /dev/zram0 几乎需要很长时间才能完成。zram 不支持部分弃用，在此类情况下只会立即返回，而不执行任何弃用工作。
    问题是我们在离开时忘记了 endio，因此 blkdiscard 在 submit_bio_wait（） 中永久休眠。
    通过跳转到执行 bio_endio（） end_bio标签修复此问题。（CVE-2026-46089）

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

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

  - ASoC：nau8821：取消组件删除的延迟工作 在千斤顶检测工作待定时尝试卸载驱动程序可能会造成内核在最终计划执行时崩溃：[1984.896308] 缺陷：无法处理地址的页面错误：ffffffffc10c2a20 [...][ 1984.896388] 硬件名称：Valve Jupiter/Jupiter，BIOS F7A0131 2024 年 1 月 30 日 [ 1984.896396] 工作队列：事件nau8821_jdet_work [snd_soc_nau8821] [ 1984.896414] RIP：0010：__mutex_lock+0x9f/0x11d0 [...][ 1984.896504] 调用跟踪： [1984.896511] <TASK> [ 1984.896524] ？ snd_soc_dapm_disable_pin+0x26/0x60 [snd_soc_core] [ 1984.896572] ？ snd_soc_dapm_disable_pin+0x26/0x60 [snd_soc_core] [ 1984.896596] snd_soc_dapm_disable_pin+0x26/0x60 [snd_soc_core] [ 1984.896622] nau8821_jdet_work+0xeb/0x1e0 [snd_soc_nau8821] [ 1984.896636] process_one_work+0x211/0x590 [ 1984.896649] ？ srso_return_thunk+0x5/0x5f [ 1984.896670] worker_thread+0x1cd/0x3a0 取消计划外的jdet_work或等待其执行完成，然后再删除组件驱动程序。 （CVE-2026-45963）

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

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

  - media：amphion：修复 m2m job_abort 和 device_run 之间的争用 修复由争用条件引起的内核错误，其中 v4l2_m2m_ctx_release（） 释放m2m_ctx而 v4l2_m2m_try_run（） 准备调用具有相同上下文的 device_run。争用序列：v4l2_m2m_try_run（）：v4l2_m2m_ctx_release（）：锁定/解锁 v4l2_m2m_cancel_job（） job_abort（） v4l2_m2m_job_finish（） kfree（m2m_ctx） <- 释放 ctx device_run（） <- 0x538 处发生释放后使用崩溃 崩溃跟踪：无法处理从虚拟地址 0000000000000538 v4l2_m2m_try_run+0x78/0x138 v4l2_m2m_device_run_work+0x14/0x20 的不可读内存读取的内核 amphion vpu 驱动程序不依赖于 m2m 框架的device_run回调以执行编码/解码操作。通过完全阻止 m2m 框架作业计划来修复争用：- 添加返回 0 的 job_ready 回调（没有为 m2m 框架准备的作业）
    - 删除job_abort回调以避免争用条件 （CVE-2026-46058）

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

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

  - ALSA：control：在 snd_ctl_elem_init_enum_names（） 中的 strnlen（） 之前验证 buf_len snd_ctl_elem_init_enum_names（） 在递减buf_len的同时通过名称缓冲区推进指针 p。如果buf_len达到零但项目仍然存在，则下一次迭代调用 strnlen（p， 0）。当 strnlen（p， 0） 返回 0 并将命中现有 name_len == 0 错误路径时，CONFIG_FORTIFY_SOURCE 的强化 strnlen（） 首先会针对 __builtin_dynamic_object_size（） 检查 maxlen。当 Clang 在循环中丢失对 p 对象大小的跟踪时，这会在检查返回值之前触发 BRK 异常错误。在循环条目中添加 buf_len == 0 防护，以防止在耗尽的缓冲区上调用增强的 strnlen（）。通过小米智能手机的内核模糊测试发现。（CVE-2026-46088）

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

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

  - netfilter：nf_conncount：将连接清理限制增加到 64 在优化为每个 jiffy 仅执行一个 GC 之后，引入了一个新问题。如果每瞬间跟踪超过 8 个新连接，列表的清理速度不够快，从而可能错误地达到限制。为防止此问题，只有在相同 jiffy 期间已触发并且增量小于清理限制时才跳过 GC。此外，将清理限制增加到 64 个连接，以避免过于频繁地触发 GC，并执行更有效的 GC。在配置 nft_connlimit/xt_connlimit 或 OVS 限制的情况下，已使用 HTTP 服务器和多个性能工具对此进行了测试。慢速 httptest 的输出 + 52000 个连接时的 OVS 限制：第 340 秒的慢速 HTTP 测试状态：初始化中：0 待定：432 已连接：51998 错误：0 已关闭：0 可用服务：是 （CVE-2026-45860）

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

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

  - 在直到 1.2.9 版本的 FastNetMon Community Edition 中，BGP AS_PATH 属性编码器中包含一个整数溢出问题。在 src/bgp_protocol.hpp 中，IPv4UnicastAnnounce::get_attributes() 函数将 attribute_length 计算为“sizeof(bgp_as_path_segment_element_t) + this->as_path_asns.size() * sizeof(uint32_t)”，并将其存储在 uint8_t 字段（行 600-605）。由于 uint8_t 只能存储 0 到 255 之间的值，因此包含超过 63 个 ASN 的 AS_PATH (2 + 64*4 = 258 > 255) 会导致静默截断。截断后的长度用于缓冲区大小的调整，而实际写入的数据是完整的未截断长度，这会导致堆缓冲区溢出。类似地，第 621 行的 path_segment_length 字段也是 uint8_t 类型，当 ASN 超过 255 时也会被截断。(CVE-2026-48691)

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

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

  - drm/display/dp_mst：添加针对 0 vcpi 的保护 释放时隙时，如果 delayed_destroy_work 在 DP 2.1 监视器断开连接后最终开始发挥作用，导致 vcpi 变为 0，则我们很有可能会因为溢出而获得错误的负载掩码，然后我们尝试使负载 = ~BIT（vcpi - 1），这是一个负偏移。VCPI id 始终不应真正为 0，因此，如果 VCPI 为 0，则跳过更改负载掩码。否则会导致 <7> [515.287237] xe 0000：03：00.0：
    [drm：drm_dp_mst_get_port_malloc [drm_display_helper]] 端口 ffff888126ce9000 （3） <4> [515.287267]
    -----------[ 从此处剪切 ]----------- <3> [515.287268] UBSAN：../drivers/gpu/drm/display/drm_dp_mst_topology.c:4575:36 处发生移位越界 <3> [515.287271] 移位指数 -1 为负数 <4> [515.287275] CPU：7 UID：0 PID：3108 Comm：kworker/u64:33 Tainted：G S U 6.17.0-rc6-lgci-xe-xe-3795-3e79699fa1b216e92+ #1 PREEMPT（自愿）<4> [515.287279] 已污染：[S]=CPU_OUT_OF_SPEC，[U]=用户 <4> [515.287279] 硬件名称：ASUS 系统产品名称/PRIME Z790-P WIFI，BIOS 1645 2024/03/15 <4> [515.287281] 工作队列：drm_dp_mst_wq drm_dp_delayed_destroy_work [drm_display_helper] <4> [515.287303] 调用跟踪：<4> [515.287304] <TASK> <4> [515.287306] dump_stack_lvl+0xc1/0xf0 <4> [515.287313] dump_stack+0x10/0x20 <4> [515.287316] __ubsan_handle_shift_out_of_bounds+0x133/0x2e0 <4> [515.287324] ? drm_atomic_get_private_obj_state+0x186/0x1d0 <4> [515.287333] drm_dp_atomic_release_time_slots.cold+0x17/0x3d [drm_display_helper] <4> [515.287355] mst_connector_atomic_check+0x159/0x180 [xe] <4> [515.287546] drm_atomic_helper_check_modeset+0x4d9/0xfa0 <4> [515.287550] ? __ww_mutex_lock.constprop.0+0x6f/0x1a60 <4> [515.287562] intel_atomic_check+0x119/0x2b80 [xe] <4> [515.287740] ? find_held_lock+0x31/0x90 <4> [515.287747] ? lock_release+0xce/0x2a0 <4> [515.287754] drm_atomic_check_only+0x6a2/0xb40 <4> [515.287758] ? drm_atomic_add_affected_connectors+0x12b/0x140 <4> [515.287765] drm_atomic_commit+0x6e/0xf0 <4> [515.287766] ? _pfx__drm_printfn_info+0x10/0x10 <4> [515.287774] drm_client_modeset_commit_atomic+0x25c/0x2b0 <4> [515.287794] drm_client_modeset_commit_locked+0x60/0x1b0 <4> [515.287795] ? mutex_lock_nested+0x1b/0x30 <4> [515.287801] drm_client_modeset_commit+0x26/0x50 <4> [515.287804] __drm_fb_helper_restore_fbdev_mode_unlocked+0xdc/0x110 <4> [515.287810] drm_fb_helper_hotplug_event+0x120/0x140 <4> [515.287814] drm_fbdev_client_hotplug+0x28/0xd0 <4> [515.287819] drm_client_hotplug+0x6c/0xf0 <4> [515.287824] drm_client_dev_hotplug+0x9e/0xd0 <4> [515.287829] drm_kms_helper_hotplug_event+0x1a/0x30 <4> [515.287834] drm_dp_delayed_destroy_work+0x3df/0x410 [drm_display_helper] <4> [515.287861] process_one_work+0x22b/0x6f0 <4> [515.287874] worker_thread+0x1e8/0x3d0 <4> [515.287879] ? __pfx_worker_thread+0x10/0x10 <4> [515.287882] kthread+0x11c/0x250 <4> [515.287886] ? __pfx_kthread+0x10/0x10 <4> [515.287890] ret_from_fork+0x2d7/0x310 <4> [515.287894] ? __pfx_kthread+0x10/0x10 <4> [515.287897] ret_from_fork_asm+0x1a/0x30 (CVE-2025-71305)

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

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

  - mm/vmalloc：可从两条路径同时调用 Shrinker decay_va_pool_node（） 中的 take vmap_purge_lock：当清除池时调用 __purge_vmap_area_lazy（），以及通过 vmap_node_shrink_scan（） 调用 shrinker。
    但是，decay_va_pool_node（） 并发运行并不安全，并且 shrinker 路径当前缺少序列化，导致争用和可能的泄漏。通过在 shrinker 路径中进行vmap_purge_lock来保护 decay_va_pool_node（），以确保与清除用户进行序列化。（CVE-2026-46093）

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

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

  - ata：libata-scsi：避免非 NCQ 命令耗尽 在执行 NCQ 命令的同时发出非 NCQ 命令时，ata_scsi_qc_issue（） 向 SCSI 层指示应通过返回SCSI_MLQUEUE_XXX_BUSY来延迟发出命令。此命令延迟是正确的，并且符合 ACS 规范的要求，因为 NCQ 命令和非 NCQ 命令不能混合使用。然而，对于使用多个提交队列的主机适配器，当目标设备处于 NCQ 命令的持续负载下时，无法保证稍后会执行重新排队非 NCQ 命令，而且可能会反复被推迟，因为其他提交队列可在非 NCQ 命令之前不断从不同的 CPU 发出 NCQ 命令。这可能导致非 NCQ 命令执行的延迟很长，在最坏的情况下甚至会完全耗尽这些命令。由于区块层和 SCSI 层不区分可排队 （NCQ） 命令和不可排队 （non-NCQ） 命令，因此 libata-scsi SAT 实现必须确保存在 NCQ 命令流量时非 NCQ 命令的转发进度。
    这类似于具有基于硬件/固件的 SAT 实现的 SAS HBA 的功能。通过限制来自 ata_scsi_qc_issue（） 的非 NCQ 命令重新排队来实现此类向前进度保证：收到非 NCQ 命令且 NCQ 命令正在执行中时，不通过返回 SCSI_MLQUEUE_XXX_BUSY 来强制非 NCQ 命令重新排队，而是返回 0 表示该命令已被接受，但使用 struct ata_port 的新 deferred_qc 字段保留 qc。一旦所有正在传输的命令完成，将使用运行函数 ata_scsi_deferred_qc_work（） deferred_qc_work工作项发出此延迟的 qc，通过端口 qc_defer（） 回调返回值进行检查，表明不需要进一步延迟。此检查使用从 ata_scsi_qc_complete（） 调用的辅助函数 ata_scsi_schedule_deferred_qc（） 完成。因此，这会将该机制排除在 ATA EH 发出的所有内部非 NCQ 命令之外。当端口deferred_qc为非 NULL 时（即端口具有等待设备队列耗尽的命令），则使用常规忙碌机制延迟发出所有传入命令（NCQ 和非 NCQ）。这样可以简化代码，还可以避免在用户发出过多非 NCQ 命令时可能发生的拒绝服务问题。最后，无论出于何种原因，无论何时计划 ata EH，都会重新排队延迟的 qc，以便在 EH 完成后可以重试。这可以通过从 ata_eh_set_pending（） 调用函数 ata_scsi_requeue_deferred_qc（） 来完成。这避免了在 NCQ 错误、链路或设备重置或设备超时的情况下对延迟的 qc 进行任何特殊处理。
    (CVE-2026-45855)

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

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

  - apparmor：修复未设置export_binary时 rawdata 的无效取消引用 如果在运行时禁用 export_binary 参数，则在此之前加载的配置文件仍会将其 rawdata 存储在 apparmorfs 中，并带有指向策略目录中 rawdata 的符号链接。当替换其中一个配置文件时，rawdata 将设置为 NULL，但是当尝试解析该配置文件的 rawdata 的符号链接时，它将尝试取消引用 profile->rawdata->name，而 profile->rawdata 现在为 NULL，从而导致 oops。通过检查是否设置了 rawdata 来修复此问题。[ 168.653080] 缺陷：内核空指针取消引用，解决：
    0000000000000088 [ 168.657420] #PF：内核模式下的监督人读取访问权限 [ 168.660619] #PF：
    error_code（0x0000） - 不存在页面 [ 168.663613] PGD 0 P4D 0 [ 168.665450] Oops： Oops： 0000 [#1] SMP NOPTI [ 168.667836] CPU： 1 UID： 0 PID： 1729 Comm： ls 未受感染 6.19.0-rc7+ #3 PREEMPT（自愿性） [168.672308] 硬件名称：QEMU Ubuntu 24.04 PC （i440FX + PIIX， 1996）， BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 168.679327] RIP： 0010：rawdata_get_link_base.isra.0+0x23/0x330 [ 168.682768] 代码： 90 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 41 54 53 4883 EC 18 48 89 55 d0 48 85 ff 0f 84 e3 01 00 00 <48> 83 3c 25 88 00 00 00 00 0f 84 d4 01 00 00 49 89 f6 49 89 cc e8 [ 168.689818] RSP：
    0018：ffffcdcb8200fb80 EFLAGS：00010282 [ 168.690871] RAX：fffffffffaee74ec0 RBX：0000000000000000 RCX：
    ffffffffb0120158 [ 168.692251] RDX： ffffcdcb8200fbe0 RSI： ffff88c187c9fa80 RDI： ffff88c186c98a80 [168.693593] RBP： ffffcdcb8200fbc0 R08： 0000000000000000 R09： 000000000000000000 [ 168.694941] R10：
    0000000000000000 R11： 000000000000000 R12： ffff88c186c98a80 [ 168.696289] R13： 00007fff005aaa20 R14：
    0000000000000080 R15：ffff88c188f4fce0 [ 168.697637] FS：0000790e81c58280（0000） GS：ffff88c20a957000（0000） knlGS：0000000000000000 [ 168.699227] CS：0010 DS：0000 ES：0000 CR0：0000000080050033 [ 168.700349] CR2：
    0000000000000088 CR3：000000012fd3e000 CR4：0000000000350ef0 [ 168.701696] 调用跟踪：[ 168.702325] [ <TASK>168.702995] rawdata_get_link_data+0x1c/0x30 [ 168.704145] vfs_readlink+0xd4/0x160 [ 168.705152] do_readlinkat+0x114/0x180 [ 168.706214] __x64_sys_readlink+0x1e/0x30 [ 168.708653] x64_sys_call+0x1d77/0x26b0 [ 168.709525] do_syscall_64+0x81/0x500 [ 168.710348] ？ do_statx+0x72/0xb0 [168.711109] ？ putname+0x3e/0x80 [ 168.711845] ？ __x64_sys_statx+0xb7/0x100 [ 168.712711] ？ x64_sys_call+0x10fc/0x26b0 [ 168.713577] ？ do_syscall_64+0xbf/0x500 [ 168.714412] ?do_user_addr_fault+0x1d2/0x8d0 [ 168.715404] ？ irqentry_exit+0xb2/0x740 [ 168.716359] ？ exc_page_fault+0x90/0x1b0 [ 168.717307] entry_SYSCALL_64_after_hwframe+0x76/0x7e （CVE-2026-45965）

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

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

  - net：caif：清除拆卸中的客户端服务指针 “caif_connect（）”可在远程关机后，通过调用“caif_disconnect_client（）”并接着调用“caif_free_client（）”来去除现有客户端。
    “caif_free_client（）”释放“adap_layer->dn”引用的服务层，但使该指针过时。当套接字稍后遭到破坏时，“caif_sock_destructor（）”会再次调用“caif_free_client（）”并取消引用已释放的服务指针。释放服务对象之前清除客户端/服务链接，这样反复的拆卸便会变得无害。（CVE-2026-46098）

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

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

  - ALSA：usb-audio：停止在 MAX_NR_RATES parse_uac2_sample_rate_range（） 时解析 UAC2 速率将枚举速率的数量限制在 MAX_NR_RATES，但它仅中断当前速率循环。具有额外三联的畸形 UAC2 RANGE 响应继续解析剩余的三联，并在探头仍保持register_mutex时重复打印无效的 uac2 速率。达到上限后停止整个解析，并返回到目前为止收集的速率数。（CVE-2026-46018）

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

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

  - net：strparser：修复 strp_abort_strp（） 中的skb_head泄漏 流解析器中止时（例如在消息汇编超时之后），它仍然可以为 strp->skb_head 中保留对部分组装的消息的引用。strp_abort_strp（） 中未释放该 skb，这会泄漏部分组装的消息并可反复触发以耗尽内存。通过释放 strp->skb_head 并重置中止路径中的解析器状态来修复此问题。保持 strp_stop（） 不变，以便在同步工作和定时器之后仍在 strp_done（） 中进行最终清除。（CVE-2026-46102）

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

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

  - ext4：修复 ext4_xattr_inode_dec_ref_all（） 中缺少的 brelse（） 当 block_csum为 false 时，提交 c8e008b60492（ext4：忽略 xattrs 过去的结尾）引入了 refcount 泄漏。ext4_xattr_inode_dec_ref_all（） 会调用 ext4_get_inode_loc（） 以取得 iloc.bh，但从不通过 brelse（） 发布。（CVE-2026-46046）

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

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

  - 在直到 1.2.9 版本的 FastNetMon Community Edition 中，BGP NLRI（网络层可达性信息）解码器中包含一个基于堆栈的缓冲区溢出漏洞。src/bgp_protocol.cpp 中的函数 decode_bgp_subnet_encoding_ipv4_raw() 会直接从 BGP 数据包（行 99）读取 prefix_bit_length，而不验证 IPv4 前缀是否 <= 32。此值会传递给用于计算 ceil(prefix_bit_length / 8) 的 how_much_bytes_we_need_for_storing_certain_subnet_mask()，对于长度为 255 的 prefix_bit_length，最多返回 32 个字节。结果会用作 memcpy() 的长度参数（行 106），并复制到 4 字节的 uint32_t 堆栈变量 (prefix_ipv4)。这会导致长达 28 字节的堆栈缓冲区溢出，攻击者可利用此问题执行任意代码。此外，未经验证的 prefix_bit_length 会传递到 convert_cidr_to_binary_netmask_local_function_copy()（行 111），其中 (32 - cidr) 与 cidr > 32 的位移会造成未定义的行为。(CVE-2026-48686)

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

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

  - rxrpc：修复了连接级别的数据包处理，以取消共享 RESPONSE 数据包 验证 RESPONSE 数据包的安全操作会就地解密其中的位 - 但是，sk_buff可能与数据包嗅探器共享，这会导致嗅探器看到明显损坏的数据包（实际上已解密）。如果数据包是克隆的，可通过将数据包的副本交给特定的安全处理程序来修复此问题。
    (CVE-2026-46000)

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

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

  - ext4：分割盘区失败时终止盘区缓存 当拆分盘区失败时，我们可能保留仍在处理中的某些盘区并直接返回错误，这会导致过时的盘区条目保留在盘区状态树中。因此，如果拆分失败，请放弃所有剩余的潜在过时盘区。（CVE-2026-45899）

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

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

  - ceph：修复 crypto 分配失败时的num_ops差一错误 move_dirty_folio_in_page_array（） 可能会失败，前提是文件已加密、脏作品集不是批处理中的第一档，而且未能分配退回缓冲区来保存密文。发生这种情况时，ceph_process_folio_batch（） 只需对作品集进行重新污染并刷新当前批次 -- 它可以在未来的批次中重试该作品集。但是，如果这个失败的作品集与上一个进入批次的作品集不连续，则 ceph_process_folio_batch（） 已经递增了“ceph_wbc->num_ops”;因为它不会跟进并添加不连续的 folio 到数组，所以 ceph_submit_write（） -- 期望“ceph_wbc->num_ops”准确反映回写中连续范围的数量（因此所需的写入范围 ops 数量） -- 将使内核发生错误：BUG_ON（ceph_wbc->op_idx + 1 ！= req->r_num_ops）;通过以 4KiB 写入/4KiB 跳过/重复模式（总文件大小无关紧要），并逐渐增加系统的内存压力直到反弹缓冲区分配失败，即可在受影响的内核上重现此问题。当 move_dirty_folio_in_page_array（） 失败但作品集已开始计数新的（即仍然为空的）范围时，通过将“ceph_wbc->num_ops”递减回正确值来修复此崩溃。此修补程序修正的缺陷自 2022 年以来一直存在（参见第一个“补丁：”），但另一个缺陷一直阻碍多对开本加密的回写，直到最近（参见第二个“补丁：”）。第二次提交进入 6.18.16、 6.19.6和 7.0-rc1，揭露了这些版本中的错误。因此，此修补程序修复了 cac190c7674f 引入的回归（错误）。（CVE-2026-46066）

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

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

  - drm/exynos：vidi：修复以避免直接取消引用用户指针 在 vidi_connection_ioctl（） 中，vidi->edid（用户指针）会在内核中直接取消引用。这允许从用户空间访问任意内核内存，因此我们应将其修改为使用 copy_from_user（） 将 edid 复制到内核内存并使用它，而不是直接访问内核中的用户指针。（CVE-2026-45958）

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

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

  - mfd：arizona：修复 wm5102_clear_write_sequencer（） 失败时的调节器资源泄漏 wm5102_clear_write_sequencer（） 辅助函数可能返回错误然后直接返回，从而绕过清理序列并导致调节器保持启用状态，从而造成资源泄漏。更改直接返回以跳转到err_reset标签，从而正确释放资源。（CVE-2026-45875）

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

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

  - ipv4：icmp：在使用 icmp_pointers 之前验证回复类型 扩展回复使用 ICMP_EXT_ECHOREPLY 作为出站回复类型。该值超出了 覆盖的范围 icmp_pointers[]，后者仅描述最多 NR_ICMP_TYPES 的传统 ICMP 类型。避免查阅 icmp_pointers[] 该范围之外的回复类型，其余范围内的查找使用 array_index_nospec（）。普通 ICMP 回复保持其现有行为不变。（CVE-2026-46037）

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

ID	名称	严重性
317233	Linux Distros 未修补的漏洞：CVE-2026-46075	high
317232	Linux Distros 未修补的漏洞：CVE-2026-45948	medium
317231	Linux Distros 未修补的漏洞：CVE-2026-45852	high
317230	Linux Distros 未修补的漏洞：CVE-2026-46056	high
317229	Linux Distros 未修补的漏洞：CVE-2026-45912	medium
317228	Linux Distros 未修补的漏洞：CVE-2026-46062	high
317227	Linux Distros 未修补的漏洞：CVE-2026-46083	medium
317226	Linux Distros 未修补的漏洞：CVE-2026-45970	high
317225	Linux Distros 未修补的漏洞：CVE-2026-46004	high
317224	Linux Distros 未修补的漏洞：CVE-2026-45954	medium
317223	Linux Distros 未修补的漏洞：CVE-2026-45994	high
317222	Linux Distros 未修补的漏洞：CVE-2026-46054	high
317221	Linux Distros 未修补的漏洞：CVE-2026-45885	high
317220	Linux Distros 未修补的漏洞：CVE-2026-48685	medium
317219	Linux Distros 未修补的漏洞：CVE-2026-45870	medium
317218	Linux Distros 未修补的漏洞：CVE-2026-48693	medium
317217	Linux Distros 未修补的漏洞：CVE-2026-45960	medium
317216	Linux Distros 未修补的漏洞：CVE-2026-46064	high
317215	Linux Distros 未修补的漏洞：CVE-2026-46006	high
317214	Linux Distros 未修补的漏洞：CVE-2026-45996	high
317213	Linux Distros 未修补的漏洞：CVE-2025-71304	medium
317212	Linux Distros 未修补的漏洞：CVE-2026-46052	high
317211	Linux Distros 未修补的漏洞：CVE-2026-46079	medium
317210	Linux Distros 未修补的漏洞：CVE-2026-45987	medium
317209	Linux Distros 未修补的漏洞：CVE-2026-46086	medium
317208	Linux Distros 未修补的漏洞：CVE-2026-46033	high
317207	Linux Distros 未修补的漏洞：CVE-2026-45883	medium
317206	Linux Distros 未修补的漏洞：CVE-2026-46032	medium
317205	Linux Distros 未修补的漏洞：CVE-2026-48683	medium
317204	Linux Distros 未修补的漏洞：CVE-2026-46089	medium
317203	Linux Distros 未修补的漏洞：CVE-2026-45963	medium
317202	Linux Distros 未修补的漏洞：CVE-2026-46058	high
317201	Linux Distros 未修补的漏洞：CVE-2026-46088	medium
317200	Linux Distros 未修补的漏洞：CVE-2026-45860	high
317199	Linux Distros 未修补的漏洞：CVE-2026-48691	critical
317198	Linux Distros 未修补的漏洞：CVE-2025-71305	medium
317197	Linux Distros 未修补的漏洞：CVE-2026-46093	high
317196	Linux Distros 未修补的漏洞：CVE-2026-45855	medium
317195	Linux Distros 未修补的漏洞：CVE-2026-45965	medium
317194	Linux Distros 未修补的漏洞：CVE-2026-46098	medium
317193	Linux Distros 未修补的漏洞：CVE-2026-46018	medium
317192	Linux Distros 未修补的漏洞：CVE-2026-46102	high
317191	Linux Distros 未修补的漏洞：CVE-2026-46046	medium
317190	Linux Distros 未修补的漏洞：CVE-2026-48686	critical
317189	Linux Distros 未修补的漏洞：CVE-2026-46000	medium
317188	Linux Distros 未修补的漏洞：CVE-2026-45899	medium
317187	Linux Distros 未修补的漏洞：CVE-2026-46066	medium
317186	Linux Distros 未修补的漏洞：CVE-2026-45958	high
317185	Linux Distros 未修补的漏洞：CVE-2026-45875	medium
317184	Linux Distros 未修补的漏洞：CVE-2026-46037	high

检测

Nessus 的 Misc. 系列

high

medium

high

high

medium

high

medium

high

high

medium

high

high

high

medium

medium

medium

medium

high

high

high

medium

high

medium

medium

medium

high

medium

medium

medium

medium

medium

high

medium

high

critical

medium

high

medium

medium

medium

medium

high

medium

critical

medium

medium

medium

high

medium

high