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

  - 已修复 Linux 内核中的下列漏洞：soundwire: qcom: fix storing port config out-of-bounds The 'qcom_swrm_ctrl->pconfig' has size of QCOM_SDW_MAX_PORTS (14), however we index it starting from 1, not 0, to match real port numbers. This can lead to writing port config past 'pconfig' bounds and overwriting next member of 'qcom_swrm_ctrl' struct. Reported also by smatch:
    drivers/soundwire/qcom.c:1269 qcom_swrm_get_port_config() error: buffer overflow 'ctrl->pconfig' 14 <= 14 (CVE-2023-53465)

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

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

  - Storage 中的边信道信息泄露。(CVE-2025-11207)

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

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

  - ACPICA修复 acpi_ut_copy_ipackage_to_ipackage() 中的释放后使用 KASAN 报告存在一个释放后使用缺陷KASAN通过任务 modprobe在 addr ffff888112afc460 处的 acpi_ut_remove_reference+0x3b/0x82 读取中发现释放后使用大小 1 /2111 CPU0 PID2111 Commmodprobe Not tainted 6.1.0-rc7-dirty Hardware nameQEMU Standard PC (i440FX + PIIX,1996)Call Trace <TASK> kasan_report+0xae/0xe0 acpi_ut_remove_reference+0x3b/0x82 acpi_ut_copy_iobject_to_iobject +0x3be/0x3d5 acpi_ds_store_object_to_local+0x15d/0x3a0 acpi_ex_store+0x78d/0x7fd acpi_ex_opcode_1A_1T_1R+0xbe4/0xf9b acpi_ps_parse_aml+0x217/0x8d5 ...</TASK> 问题的根本原因是当 acpi_ut_copy_ipackage_to_ipackage() 中的 acpi_ut_walk_package_tree() 失败时会释放 acpi_operand_object导致 acpi_ut_copy_iobject_to_iobject() 中重复释放。该问题由 8aa5e56eeb61 提交引入此提交用于修复 acpi_ut_copy_iobject_to_iobject() 中的内存泄漏重复添加删除操作导致释放后使用 acpi_operand_object。通过删除 acpi_ut_copy_ipackage_to_ipackage() 中的 acpi_ut_remove_reference() 来修复此问题。会调用 acpi_ut_copy_ipackage_to_ipackage() 以将内部程序包对象复制到另一个内部程序包对象中。此操作失败时调用程序应释放 acpi_operand_object 的内存。 (CVE-2022-50423)

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

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

  - 已修复 Linux 内核中的下列漏洞：RDMA/bnxt_re: Properly order ib_device_unalloc() to avoid UAF ib_dealloc_device() should be called only after device cleanup. Fix the dealloc sequence. (CVE-2023-53504)

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

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

  - 已修复 Linux 内核中的下列漏洞：thunderbolt: Fix memory leak in tb_handle_dp_bandwidth_request() The memory allocated in tb_queue_dp_bandwidth_request() needs to be released once the request is handled to avoid leaking it. (CVE-2023-53527)

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

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

  - virtio_net修复 XDP 初始化的错误展开在 virtnet_open() 中初始化 XDP 时某些 rq xdp 初始化可能会发生错误从而导致网络设备打开失败。但是之前的 rqs 已初始化 XDP 并启用了 NAPI这不是预期的行为。需要回滚之前的 rq 初始化以避免在 init 代码的错误展开中发生泄漏。还提取禁用和启用队列对的 helper 函数。使用新引入的禁用错误展开和 virtnet_close 中的辅助函数。
    在 virtnet_open 中使用启用辅助函数。 (CVE-2023-53499)

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

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

  - Storage 中不适当的实现。 (CVE-2025-11216)

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

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

  - mt76mt7915修复 mt7915_pci_init_hif2() 中的 PCI 设备引用计数泄漏 正如 pci_get_device() 的注释所述其会返回引用计数增加的 pci_device。我们需要调用 pci_dev_put() 以减少 refcount。保存 pci_get_device() 的返回值并调用 pci_dev_put() 以减少 refcount。
    (CVE-2022-50464)

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

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

  - 已修复 Linux 内核中的下列漏洞：clk: tegra: Fix refcount leak in tegra210_clock_init of_find_matching_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak.
    (CVE-2022-50458)

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

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

  - 已修复 Linux 内核中的下列漏洞：x86/platform/uv: Use alternate source for socket to node data The UV code attempts to build a set of tables to allow it to do bidirectional socket<=>node lookups. But when nr_cpus is set to a smaller number than actually present, the cpu_to_node() mapping information for unused CPUs is not available to build_socket_tables(). This results in skipping some nodes or sockets when creating the tables and leaving some -1's for later code to trip.
    over, causing oopses. The problem is that the socket<=>node lookups are created by doing a loop over all CPUs, then looking up the CPU's APICID and socket. But if a CPU is not present, there is no way to start this lookup. Instead of looping over all CPUs, take CPUs out of the equation entirely. Loop over all APICIDs which are mapped to a valid NUMA node. Then just extract the socket-id from the APICID. This avoid tripping over disabled CPUs. (CVE-2023-53496)

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

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

  - scsiqla4xxx解析 nlattrs 时添加长度检查 qla4xxx 在三个位置解析 nlattrs - qla4xxx_set_chap_entry() - qla4xxx_iface_set_param() - qla4xxx_sysfs_ddb_set_param() 其中每个位置都将 nlattr 直接转换为结构的特定指针而不进行长度检查。这可能是危险的因为这些属性未经验证而且畸形的 nlattr如长度为 0可能会导致泄漏堆脏数据的 OOB 读取。添加在访问 nlattr 数据之前进行的 nla_len 检查如果长度检查失败则返回 EINVAL。 (CVE-2023-53456)

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

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

  - tcp/udp修复具有 TX 时间戳的 sk 和 zerocopy skbs 的内存泄漏。 syzkaller 报告了 UDP 套接字和 ZEROCOPY skbs 的 [0] 内存泄漏。可以使用这些序列重现此问题 sk = socket(AF_INET, SOCK_DGRAM, 0) sk.setsockopt(SOL_SOCKET, SO_TIMESTAMPING, SOF_TIMESTAMPING_TX_SOFTWARE) sk.setsockopt(SOL_SOCKET, SO_ZEROCOPY, 1) sk.sendto(b'', MSG_ZEROCOPY, ( “127.0.0.1”, 53)) sk.close() sendmsg() 调用 msg_zerocopy_alloc()分配 skb将 skb->cb->ubuf.refcnt 设为 1并调用 sock_hold()。此处 struct ubuf_info_msgzc 间接保存套接字的 refcnt。当发送 skb 时
    __skb_tstamp_tx() 对其进行克隆并将克隆到具有 TX 时间戳的套接字的错误队列中。本地接收原始 skb 时skb_copy_ubufs() 调用 skb_unclone()且 pskb_expand_head() 递增 skb->cb->ubuf.refcnt。此额外计数会在释放 skb 时递减但 struct ubuf_info_msgzc 仍有 refcnt因此不会调用 __msg_zerocopy_callback()。除非我们通过 recvmsg() 检索带有 TX 时间戳的 skb否则不会发布最后一个 refcnt。由于我们在套接字的 refcnt 达到 0 之后清除了 inet_sock_destruct() 中的错误队列因此存在循环依存关系。如果我们 close() 持有此类 skb 的套接字绝不会调用 sock_put() 并会泄漏 count、sk 和 skb。TCP 有相同的问题并且 commit e0c8bccd40fc (net: stream: sk_stream_kill_queues() 中的清除 sk_error_queue) 尝试通过在 close() 期间调用 skb_queue_purge() 来修复该问题。然而在 qdisc 或设备中排队的 skb 有小可能在 skb_queue_purge() 调用后被放入错误队列。在 __skb_tstamp_tx() 中克隆的 skb 不应具有对 ubuf 的引用以删除循环依存关系但 skb_clone() 不会针对 zerocopy skb 调用 skb_copy_ubufs()。因此我们需要为克隆的 skb 调用 skb_orphan_frags_rx() 以调用 skb_copy_ubufs()。 [0]缺陷缺陷内存泄漏未引用对象 0xffff88800c6d2d00大小 1152
    comm syz-executor392、pid 264、jiffies 4294785440 (age 13.044s) 十六进制转储前 32 字节00 00 00 00 00 00 00 00 cd af e8 81 00 00 00 00 ...... ...... 02 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............ 回溯[<0000000055636812>] sk_prot_alloc+0x64/0x2a0 net/ core/sock.c:2024 [<0000000054d77b7a>] sk_alloc+0x3b/0x800 net/core/sock.c:2083 [<0000000066f3c7e0>] inet_create net/ipv4/af_inet.c:319 [inline] [<0000000066f3c7e0>] inet_create+0x31e/ 0xe40 net/ipv4/af_inet.c:245 [<000000009b83af97>] __sock_create+0x2ab/0x550 net/socket.c:1515 [<00000000b9b11231>] sock_create net/socket.c:1566 [inline] [<00000000b9b11231>] __sys_socket_create net/socket。 c:1603 [内联] [<00000000b9b11231>] __sys_socket_create net/socket.c:1588 [内联] [<00000000b9b11231>]
    __sys_socket+0x138/0x250 net/socket.c:1636 [<000000004fb45142>] __do_sys_socket net/socket.c:1649 [内联] [<000000004fb45142>] __se_sys_socket net/socket.c:1647 [内联] [<000000004fb45142>]
    __x64_sys_socket+0x73/0xb0 net/socket.c:1647 [<0000000066999e0e>] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [<0000000066999e0e>] do_syscall_64+0x38/0x90 arch/x86/entry/common.c 80 [<0000000017f238c1>] entry_SYSCALL_64_after_hwframe+0x63/0xcd BUG内存泄漏未引用对象 0xffff888017633a00(大小 240)comm syz-executor392、pid 264、jiffies 4294785440(age 13.044s) 十六进制转储前 32 字节00 0 00 00 00 00 00 00 00 00 00 00 00 00..
    00 00 00 00 00 00 00 00 00 2d 6d 0c 80 88 ff ff ...-m... 回溯[<000000002b1c4368>]
    __alloc_skb+0x229/0x320 net/core/skbuff.c:497 [<00000000143579a6>] alloc_skb include/linux/skbuff.h:1265 [内联] [<00000000143579a6>] sock_omalloc+0xaa/0x190 net/core/sock.c:2596 [<00000000be626478>] msg_zerocopy_alloc net/core/skbuff.c:1294 [inline] [<00000000be626478>] ---truncated--- (CVE-2023-53489)

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

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

  - mediav4l2-mem2mem添加锁定以保护参数 num_rdy 使用 KCSAN 检查驱动程序时出现以下错误。通过 function:
    v4l2_m2m_num_src_bufs_ready/v4l2_m2m_num_dst_bufs_ready。 kworker/u16:3[name:report&]BUGKCSANv4l2_m2m_buf_queue 中的数据争用 kworker/u16:3[name:report&] kworker/u16:3:[name:report&]读写至 0xffffff8105f35b94 共 1 字节按 cpu 7: kworker/u16:3 v4l2_m2m_buf_queue+0xd8/0x10c 上的任务 20865 执行 (CVE-2023-53519)

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

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

  - clktegrategra124-emc修复潜在的内存泄漏 错误处理路径中需要释放 tegra 和 tegra否则将会泄漏。 (CVE-2023-53505)

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

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

  - xfrm修复 decode_session6 中的 slab-use-after-free。xfrm 设备设置为 sfb 类型的 qdisc 时已发送 skb 的 cb 字段可能会在排队期间被修改。随后当 xfrm 设备发送 IPv6 数据包时可发生 slab-use-after-free。堆栈信息如下 BUG: KASAN: decode_session6+0x103f/0x1890 在 addr ffff8881111458ef 进行大小 1 的读取中存在释放后使用漏洞 swapper/3/0 CPU: 3 PID: 0 Comm: swapper/3 Not受感染 6.4.0-next-20230707 #409 硬件名称QEMU Standard PC (i440FX + PIIX, 1996)BIOS 1.14.0-1.fc33 04/01/2014 调用跟踪 <IRQ> dump_stack_lvl+0xd9/0x150 print_address_description.constprop .0+0x2c/0x3c0 kasan_report+0x11d/0x130 decode_session6+0x103f/0x1890
    __xfrm_decode_session+0x54/0xb0 xfrmi_xmit+0x173/0x1ca0 dev_hard_start_xmit+0x187/0x700 sch_direct_xmit+0x1a3/0xc30 __qdisc_run+0x510/0x17a0 __dev_queue_xmit+0x2215/0x3b10 neigh_connected_output+0x3c2/0x550 ip6_finish_output2+0x55a/0x1550 ip6_finish_output+0x6b9/0x1270 ip6_output+0x1f1/0x540 ndisc_send_skb+0xa63/0x1890 ndisc_send_rs+0x132/0x6f0 addrconf_rs_timer+0x3f1/0x870 call_timer_fn+0x1a0/0x580 expire_timers+0x29b/0x4b0 run_timer_softirq+0x326/0x910 __do_softirq+0x1d4/0x905 irq_exit_rcu+0xb7/0x120 sysvec_apic_timer_interrupt+0x97/0xc0 </IRQ> <TASK> asm_sysvec_apic_timer_interrupt+0x1a /0x20 RIP0010:intel_idle_hlt+0x23/0x30 代码1f 84 00 00 00 00 00 f3 0f 1e fa 41 54 41 89 d4 0f 1f 44 00 00 66 90 0f 1f 44 00 00 0f 0f0fb 0f 0f09 2d ab 4 44 00 00 fb f4 <fa> 44 89 e0 41 5c c3 66 0f 1f 44 00 00 f3 0f 1e fa 41 54 41 89 d4 RSP: 0018:ffffc90000197d78 EFLAGS: 00000246 RAX: 00000000000a83c3 RBX: ffffe8ffffd09c50 RCX: ffffffff8a22d8e5 RDX: 0000000000000001 RSI:
    ffffffff8d3f8080 RDI: ffffe8ffffd09c50 RBP: ffffffff8d3f8080 R08: 0000000000000001 R09: ffffed1026ba6d9d R10: ffff888135d36ceb R11: 0000000000000001 R12: 0000000000000001 R13: ffffffff8d3f8100 R14:
     R150000000000000001  : 0000000000000000 cpuidle_enter_state+0xd3/0x6f0 cpuidle_enter+0x4e/0xa0 do_idle+0x2fe/0x3c0 cpu_startup_entry+0x18/0x20 start_secondary+0x200/0x290 secondary_startup_64_no_verify+0x167/0x16b </TASK> Allocated by task 939: kasan_save_stack+0x22/0x40 kasan_set_track+0x25 /0x30 __kasan_slab_alloc+0x7f/0x90 kmem_cache_alloc_node+0x1cd/0x410 kmalloc_reserve+0x165/0x270 __alloc_skb+0x129/0x330 inet6_ifa_notify+0x118/0x230
    __ipv6_ifa_notify+0x177/0xbe0 addrconf_dad_completed+0x133/0xe00 addrconf_dad_work+0x764/0x1390 process_one_work+0xa32/0x16f0 worker_thread+0x67d/0x10c0 kthread+0x344/0x440 ret_from_fork+0x1f/0x30 The buggy address belongs to the object at ffff888111145800 which belongs to the cache skbuff_small_head ... 传输期间未设置 IP6CB(skb)->nhoff。因此需在发送数据包前将 skb 中的 cb 字段设置为 0。 (CVE-2023-53500)

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

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

  - 已修复 Linux 内核中的下列漏洞：ext4: fix leaking uninitialized memory in fast-commit journal When space at the end of fast-commit journal blocks is unused, make sure to zero it out so that uninitialized memory is not leaked to disk. (CVE-2022-50465)

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

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

  - 已修复 Linux 内核中的下列漏洞：scsi: iscsi_tcp: Check that sock is valid before iscsi_set_param() The validity of sock should be checked before assignment to avoid incorrect values. Commit 57569c37f0ad (scsi: iscsi: iscsi_tcp: Fix null-ptr-deref while calling getpeername()) introduced this change which may lead to inconsistent values of tcp_sw_conn->sendpage and conn->datadgst_en. Fix the issue by moving the position of the assignment. (CVE-2023-53464)

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

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

  - 已修复 Linux 内核中的下列漏洞：jbd2: check 'jh->b_transaction' before removing it from checkpoint Following process will corrupt ext4 image: Step 1:
    jbd2_journal_commit_transaction __jbd2_journal_insert_checkpoint(jh, commit_transaction) // Put jh into trans1->t_checkpoint_list journal->j_checkpoint_transactions = commit_transaction // Put trans1 into journal->j_checkpoint_transactions Step 2: do_get_write_access test_clear_buffer_dirty(bh) // clear buffer dirtyset jbd dirty __jbd2_journal_file_buffer(jh, transaction) // jh belongs to trans2 Step 3: drop_cache journal_shrink_one_cp_list jbd2_journal_try_remove_checkpoint if (!trylock_buffer(bh)) // lock bh, true if (buffer_dirty(bh)) // buffer is not dirty __jbd2_journal_remove_checkpoint(jh) // remove jh from trans1->t_checkpoint_list Step 4: jbd2_log_do_checkpoint trans1 = journal->j_checkpoint_transactions // jh is not in trans1->t_checkpoint_list jbd2_cleanup_journal_tail(journal) // trans1 is done Step 5: Power cut, trans2 is not committed, jh is lost in next mounting. Fix it by checking 'jh->b_transaction' before remove it from checkpoint. (CVE-2023-53526)

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

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

  - scsimpt3sas修复内存泄漏 添加被忘记的 kfree()。 (CVE-2023-53512)

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

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

  - 已修复 Linux 内核中的下列漏洞：net/mlx5: Unregister devlink params in case interface is down Currently, in case an interface is down, mlx5 driver doesn't unregister its devlink params, which leads to this WARN[1]. Fix it by unregistering devlink params in that case as well. [1] [295.244769 ] WARNING: CPU: 15 PID: 1 at net/core/devlink.c:9042 devlink_free+0x174/0x1fc [ 295.488379 ] CPU: 15 PID: 1 Comm: shutdown Tainted: G S OE 5.15.0-1017.19.3.g0677e61-bluefield #g0677e61 [ 295.509330 ] Hardware name: https://www.mellanox.com BlueField SoC/BlueField SoC, BIOS 4.2.0.12761 Jun 6 2023 [295.543096 ] pc : devlink_free+0x174/0x1fc [ 295.551104 ] lr : mlx5_devlink_free+0x18/0x2c [mlx5_core] [295.561816 ] sp : ffff80000809b850 [ 295.711155 ] Call trace: [ 295.716030 ] devlink_free+0x174/0x1fc [295.723346 ] mlx5_devlink_free+0x18/0x2c [mlx5_core] [ 295.733351 ] mlx5_sf_dev_remove+0x98/0xb0 [mlx5_core] [ 295.743534 ] auxiliary_bus_remove+0x2c/0x50 [ 295.751893 ]
    __device_release_driver+0x19c/0x280 [ 295.761120 ] device_release_driver+0x34/0x50 [ 295.769649 ] bus_remove_device+0xdc/0x170 [ 295.777656 ] device_del+0x17c/0x3a4 [ 295.784620 ] mlx5_sf_dev_remove+0x28/0xf0 [mlx5_core] [ 295.794800 ] mlx5_sf_dev_table_destroy+0x98/0x110 [mlx5_core] [295.806375 ] mlx5_unload+0x34/0xd0 [mlx5_core] [ 295.815339 ] mlx5_unload_one+0x70/0xe4 [mlx5_core] [295.824998 ] shutdown+0xb0/0xd8 [mlx5_core] [ 295.833439 ] pci_device_shutdown+0x3c/0xa0 [ 295.841651 ] device_shutdown+0x170/0x340 [ 295.849486 ] __do_sys_reboot+0x1f4/0x2a0 [ 295.857322 ]
    __arm64_sys_reboot+0x2c/0x40 [ 295.865329 ] invoke_syscall+0x78/0x100 [ 295.872817 ] el0_svc_common.constprop.0+0x54/0x184 [ 295.882392 ] do_el0_svc+0x30/0xac [ 295.889008 ] el0_svc+0x48/0x160 [ 295.895278 ] el0t_64_sync_handler+0xa4/0x130 [ 295.903807 ] el0t_64_sync+0x1a4/0x1a8 [ 295.911120 ] ---[ end trace 4f1d2381d00d9dce ]--- (CVE-2023-53507)

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

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

  - wifimt76mt7915修复 mt7915_mcu_exit 中的内存泄漏 即使 mt7915_firmware_state 失败也始终清除 mt7915_mcu_exit 例程中的 mcu skb 队列。 (CVE-2023-53466)

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

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

  - 已修复 Linux 内核中的下列漏洞：memory: of: Fix refcount leak bug in of_lpddr3_get_ddr_timings() We should add the of_node_put() when breaking out of for_each_child_of_node() as it will automatically increase and decrease the refcount. (CVE-2022-50429)

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

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

  - iommu修复 iommu_group_alloc() 中的错误展开如果其中一个 iommu_group_grate_file() 失败则将泄漏 iommu_group。在这些错误路径上将其销毁。由 kselftest/iommu/iommufd_fail_nth 发现 (CVE-2023-53482)

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

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

  - drm/amd/display修复潜在的空取消引用 adev->dm.dc 指针可能为空并在 amdgpu_dm_fini() 中取消引用而不进行检查。添加调用 dc_dmub_srv_destroy() 之前的空指针检查。由 Linux Verification Center (linuxtesting.org) 和 SVACE 发现。(CVE-2023-53498)

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

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

  - 已修复 Linux 内核中的下列漏洞：scsi: iscsi: iscsi_tcp: Fix null-ptr-deref while calling getpeername() Fix a NULL pointer crash that occurs when we are freeing the socket at the same time we access it via sysfs. The problem is that: 1. iscsi_sw_tcp_conn_get_param() and iscsi_sw_tcp_host_get_param() take the frwd_lock and do sock_hold() then drop the frwd_lock. sock_hold() does a get on the struct sock. 2. iscsi_sw_tcp_release_conn() does sockfd_put() which does the last put on the struct socket and that does __sock_release() which sets the sock->ops to NULL. 3.
    iscsi_sw_tcp_conn_get_param() and iscsi_sw_tcp_host_get_param() then call kernel_getpeername() which accesses the NULL sock->ops. Above we do a get on the struct sock, but we needed a get on the struct socket. Originally, we just held the frwd_lock the entire time but in commit bcf3a2953d36 (scsi: iscsi:
    iscsi_tcp: Avoid holding spinlock while calling getpeername()) we switched to refcount based because the network layer changed and started taking a mutex in that path, so we could no longer hold the frwd_lock.
    Instead of trying to maintain multiple refcounts, this just has us use a mutex for accessing the socket in the interface code paths. (CVE-2022-50459)

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

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

  - xfrm通过工作队列重新注入传输模式数据包 对 LTP 测试套件的 tcp6-multi-diffip11 压力测试案例进行测试时会显示以下警告 watchdog: BUG: soft lockup - CPU#0 卡住达 22s! [ns-tcpserver:48198] CPU0 PID48198 Commns-tcpserver Kdump 已加载未受感染 6.0.0-rc6+ #39 硬件名称QEMU KVM 虚拟机、BIOS 0.0.0 02/06/2015 pstate80400005 Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : des3_ede_encrypt+0x27c/0x460 [libdes] lr : 0x3f sp
    ffff80000ceaa1b0 x29: ffff80000ceaa1b0 x28: ffff0000df056100 x27: ffff0000e51e5280 x26: ffff80004df75030 x25: ffff0000e51e4600 x24: 000000000000003b x23: 0000000000802080 x22: 000000000000003d x21:
    0000000000000038 x20: 0000000080000020 x19: 000000000000000a x18: 0000000000000033 x17: ffff0000e51e4780 x16: ffff80004e2d1448 x15: ffff80004e2d1248 x14: ffff0000e51e4680 x13: ffff80004e2d1348 x12:
    ffff80004e2d1548 x11: ffff80004e2d1848 x10: ffff80004e2d1648 x9 : ffff80004e2d1748 x8 : ffff80004e2d1948 x7 : 000000000bcaf83d x6 : 000000000000001b x5 : ffff80004e2d1048 x4 : 00000000761bf3bf x3 :
    000000007f1dd0a3 x2 : ffff0000e51e4780 x1 : ffff0000e3b9a2f8 x0 : 00000000db44e872 调用跟踪
    des3_ede_encrypt+0x27c/0x460 [libdes] crypto_des3_ede_encrypt+0x1c/0x30 [des_generic] crypto_cbc_encrypt+0x148/0x190 crypto_skcipher_encrypt+0x2c/0x40 crypto_authenc_encrypt+0xc8/0xfc [authenc] crypto_aead_encrypt+0x2c/0x40 echainiv_encrypt+0x144/0x1a0 [echainiv] crypto_aead_encrypt+0x2c /0x40 esp6_output_tail+0x1c8/0x5d0 [esp6] esp6_output+0x120/0x278 [esp6] xfrm_output_one+0x458/0x4ec xfrm_output_resume+0x6c/0x1f0 xfrm_output+0xac/0x4ac
    __xfrm6_output+0x130/0x270 xfrm6_output+0x60/0xec ip6_xmit+0x2ec/0x5bc inet6_csk_xmit+0xbc/0x10c
    __tcp_transmit_skb+0x460/0x8c0 tcp_write_xmit+0x348/0x890 __tcp_push_pending_frames+0x44/0x110 tcp_rcv_established+0x3c8/0x720 tcp_v6_do_rcv+0xdc/0x4a0 tcp_v6_rcv+0xc24/0xcb0 ip6_protocol_deliver_rcu+0xf0/0x574 ip6_input_finish+0x48/0x7c ip6_input+0x48/0xc0 ip6_rcv_finish+0x80/0x9c xfrm_trans_reinject+0xb0/0xf4 tasklet_action_common.constprop.0+0xf8/0x134 tasklet_action+0x30/0x3c __do_softirq+0x128/0x368 do_softirq+0xb4/0xc0 __local_bh_enable_ip+0xb0/0xb4 put_cpu_fpsimd_context+0x40/0x70 kernel_neon_end+0x20/0x40 sha1_base_do_update.constprop.0. isra.0+0x11c/0x140 [sha1_ce] sha1_ce_finup+0x94/0x110 [sha1_ce] crypto_shash_finup+0x34/0xc0 hmac_finup+0x48/0xe0 crypto_shash_finup+0x34/0xc0 shash_digest_unaligned+0x74/0x90 crypto_shash_digest+0x4c/0x9c shash_ahash_digest+0xc8/0xf0 shash_async_digest+ 0x28/0x34 crypto_ahash_digest+0x48/0xcc crypto_authenc_nomicv+0x88/0xcc [authenc] crypto_authenc_encrypt+0xd8/0xfc [authenc] crypto_aad_encrypt+0x2c/0x40 echainiv_encrypt+0x144/0x1a0 [echainiv] crypto_aead_encrypt+0x2c/0x40 esp6_output_tail+0x1c8/0x5d0 [esp6] esp6_output+0x120/0x278 [esp6] xfrm_output_one+0x458/0x4ec xfrm_output_resume+0x6c/0x1f0 xfrm_output+0xac/0x4ac
    __xfrm6_output+0x130/0x270 xfrm6_output+0x60/0xec ip6_xmit+0x2ec/0x5bc inet6_csk_xmit+0xbc/0x10c
    __tcp_transmit_skb+0x460/0x8c0 tcp_write_xmit+0x348/0x890 __tcp_push_pending_frames+0x44/0x110 tcp_push+0xb4/0x14c tcp_sendmsg_locked+0x71c/0xb64 tcp_sendmsg+0x40/0x6c inet6_sendmsg+0x4c/0x80 sock_sendmsg+0x5c/0x6c __sys_sendto+0x128/0x15c __arm64_sys_sendto+0x30/0x40 invoke_syscall+0x50/0x120 el0_svc_common.constprop.0+0x170/0x194 do_el0_svc+0x38/0x4c el0_svc+0x28/0xe0 el0t_64_sync_handler+0xbc/0x13c el0t_64_sync+0x180/0x184 通过 bcc softqirqirqnttracing -180/0x184 获取 softirq 信息。事件时间... 按 Ctrl-C 结束。 15:34:34 SOFTIRQ TOTAL_nsecs 块 158990 timer 20030920 sched 46577080 net_rx 676746820 tasklet 9906067650 15:34:45 SOFTIRQ TOTAL_nsecs 块 86100 sched 38849790 net_rx ---truncated--- (CVE-2022-50445)

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

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

  - fs/ntfs3当解析索引时验证缓冲区长度 当某些 NTFS 目录操作需要来自索引缓冲区的更多信息时会调用 indx_read。这会添加健全性检查以确保返回的索引缓冲区长度合法否则可能会发生一些越界内存访问问题。 [ 560.897595] BUGKASANhdr_find_e.isra.0+0x10c/0x320 中的 slab 越界 [ 560.898321] 通过任务 exp/245 在地址 ffff888009497238 读取大小为 2 的数据 [ 560.898760] [ 560.899129] CPU 0 PID: 245 Commexp 未受感染 6.0.0-rc6 #37 [ 560.899505] 硬件名称QEMU Standard PC (i440FX + PIIX,1996)BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu。 org 04/01/2014 [ 560.900170] 调用跟踪[ 560.900407] <TASK> [560.900732] dump_stack_lvl+0x49/0x63 [ 560.901108] print_report.cold+0xf5/0x689 [ 560.901395] ? hdr_find_e.isra.0+0x10c/0x320 [ 560.901716] kasan_report+0xa7/0x130 [ 560.901950] ? hdr_find_e.isra.0+0x10c/0x320 [ 560.902208] __asan_load2+0x68/0x90 [ 560.902427] hdr_find_e.isra.0+0x10c/0x320 [ 560.902846] ? cmp_uints+0xe0/0xe0 [ 560.903363] ? cmp_sdh+0x90/0x90 [560.903883] ? ntfs_bread_run+0x190/0x190 [ 560.904196] ? rwsem_down_read_slowpath+0x750/0x750 [560.904969] ? ntfs_fix_post_read+0xe0/0x130 [ 560.905259] ? __kasan_check_write+0x14/0x20 [ 560.905599] ? up_read+0x1a/0x90 [ 560.905853] ? indx_read+0x22c/0x380 [ 560.906096] indx_find+0x2ef/0x470 [ 560.906352] ? indx_find_buffer+0x2d0/0x2d0 [ 560.906692] ? __kasan_kmalloc+0x88/0xb0 [ 560.906977] dir_search_u+0x196/0x2f0 [ 560.907220] ? ntfs_nls_to_utf16+0x450/0x450 [ 560.907464] ?
    __kasan_check_write+0x14/0x20 [ 560.907747] ? mutex_lock+0x8f/0xe0 [ 560.907970] ?
    __mutex_lock_slowpath+0x20/0x20 [ 560.908214] ? kmem_cache_alloc+0x143/0x4b0 [ 560.908459] ntfs_lookup+0xe0/0x100 [ 560.908788] __lookup_slow+0x116/0x220 [ 560.909050] ? lookup_fast+0x1b0/0x1b0 [560.909309] ? lookup_fast+0x13f/0x1b0 [ 560.909601] walk_component+0x187/0x230 [ 560.909944] link_path_walk.part.0+0x3f0/0x660 [ 560.910285] ? handle_lookup_down+0x90/0x90 [ 560.910618] ? path_init+0x642/0x6e0 [ 560.911084] ? percpu_counter_add_batch+0x6e/0xf0 [ 560.912559] ?
    __alloc_file+0x114/0x170 [ 560.913008] path_openat+0x19c/0x1d10 [ 560.913419] ? getname_flags+0x73/0x2b0 [560.913815] ? kasan_save_stack+0x3a/0x50 [ 560.914125] ? kasan_save_stack+0x26/0x50 [ 560.914542] ?
    __kasan_slab_alloc+0x6d/0x90 [ 560.914924] ? kmem_cache_alloc+0x143/0x4b0 [ 560.915339] getname_flags+0x73/0x2b0 [ 560.915647] ? getname+0x12/0x20 [ 560.916114] ? __x64_sys_open+0x4c/0x60 [560.916460] ? path_lookupat.isra.0+0x230/0x230 [ 560.916867] ? __isolate_free_page+0x2e0/0x2e0 [560.917194] do_filp_open+0x15c/0x1f0 [ 560.917448] ? may_open_dev+0x60/0x60 [ 560.917696] ? expand_files+0xa4/0x3a0 [ 560.917923] ? __kasan_check_write+0x14/0x20 [ 560.918185] ?
    _raw_spin_lock+0x88/0xdb [ 560.918409] ? _raw_spin_lock_irqsave+0x100/0x100 [ 560.918783]
    _find_next_bit+0x4a/0x130 [ 560.919026] ? _raw_spin_unlock+0x19/0x40 [ 560.919276] ? alloc_fd+0x14b/0x2d0 [ 560.919635] do_sys_openat2+0x32a/0x4b0 [ 560.920035] ? file_open_root+0x230/0x230 [ 560.920336] ?
    __rcu_read_unlock+0x5b/0x280 [ 560.920813] do_sys_open+0x99/0xf0 [ 560.921208] ? filp_open+0x60/0x60 [560.921482] ? exit_to_user_mode_prepare+0x49/0x180 [ 560.921867] __x64_sys_open+0x4c/0x60 [ 560.922128] do_syscall_64+0x3b/0x90 [ 560.922369] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 560.923030] RIP
    0033:0x7f7dff2e4469 [ 560.923681] Code00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8 [8b 4c 24 560.924451] RSP002b:00007ffd41a210b8 EFLAGS
    00000206 ORIG_RAX: 0000000000000002 [ 560.925168] RAX: ffffffffffffffda RBX: 0000000000000000 RCX:
    00007f7dff2e4469 [ 560.925655] RDX: 000000000000000 RSI: 0000000000000002 RDI ---truncated--- (CVE-2022-50442)

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

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

  - drm/amdgpu/gfx仅当启用旧 gfx ras 时禁用 gfx9 cp_ecc_error_irq仅当断言旧 gfx ras 时启用 gfx9 cp_ecc_error_irq。因此在 gfx_v9_0_hw_fini 中此类情况下应执行针对 cp_ecc_error_irq 的中断禁用否则将发生 amdgpu_irq_put calltrace。 [ 7283.170322] RIP: 0010:amdgpu_irq_put+0x45/0x70 [amdgpu] [ 7283.170964] RSP
    0018:ffff9a5fc3967d00 EFLAGS00010246 [ 7283.170967] RAX: ffff98d88afd3040 RBX: ffff98d89da20000 RCX
    0000000000000000 [ 7283.170969] RDX: 0000000000000000 RSI: ffff98d89da2bef8 RDI: ffff98d89da20000 [7283.170971] RBP: ffff98d89da20000 R08[]: ffff98d89da2ca18  : 00000000 R09[000] [000] [000] [000] [000 7283.170973R10[000]
    ffffd5764243c008 R110000000000000000 R120000000000001050 [ 7283.170975] R13ffff98d89da38978 R14
     R15ffffffff999ae15a  : ffff98d880130105 [ 7283.170978] FS: 0000000000000000(0000) GS:ffff98d996f00000(0000) knlGS:0000000000000000 [ 7283.170981] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 7283.170983] CR2:
    00000000f7a9d178 CR3: 00000001c42ea000 CR4: 00000000003506e0 [ 7283.170986] Call Trace: [ 7283.170988] <TASK> [ 7283.170989] gfx_v9_0_hw_fini+0x1c/0x6d0 [amdgpu] [ 7283.171655] amdgpu_device_ip_suspend_phase2+0x101/0x1a0 [amdgpu] [ 7283.172245] amdgpu_device_suspend+ 0x103/0x180 [amdgpu] [ 7283.172823] amdgpu_pmops_freeze+0x21/0x60 [amdgpu] [ 7283.173412] pci_pm_freeze+0x54/0xc0 [7283.173419] ? __pfx_pci_pm_freeze+0x10/0x10 [ 7283.173425] dpm_run_callback+0x98/0x200 [ 7283.173430]
    __device_suspend+0x164/0x5f0 v2终止 gfx11因为其他解决方案中已通过停用 cp_ecc_irq funcs(Hawking) 对其进行了修复CVE-2023-53471

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

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

  - wifirtw88修复 rtw88_usb 中的内存泄漏 Kmemleak 在 usb 探测例程中显示因例程引起的以下泄漏未引用对象 0xffff895cb29bba00 (size 512)comm (udev-worker), pid 534, jiffies 4294903932 (age 102751.088s) hex转储前 32 字节77 30 30 30 00 00 00 00 02 2f 2d 2b 30 00 00 00 w000.../-+0... 02 00 2a 28 00 00 00 00 ff 55 ff ff ff 00 00 00 ..*(...U... 回溯
    [<ffffffff9265fa36>] kmalloc_trace+0x26/0x90 [<ffffffffc17eec41>] rtw_usb_probe+0x2f1/0x680 [rtw_usb] [<ffffffffc03e19fd>] usb_probe_interface+0xdd/0x2e0 [usbcore] [<ffffffff92b4f2fe>] real_probe+0x18e/0x3d0 [<ffffffff92b4f5b8>] __driver_probe_device+0x78/ 0x160 [<ffffffff92b4f6bf>] driver_probe_device+0x1f/0x90 [<ffffffff92b4f8df>] __driver_attach+0xbf/0x1b0 [<ffffffff92b4d350>] bus_for_each_dev+0x70/0xc0 [<ffffffff92b4e51e>] bus_add_driver+0x10e/0x210 [<ffffffff92b50935>] driver_register+0x55/0xf0 [<ffffffffc03e0708>] usb_register_driver+0x88/0x140 [usbcore] [<ffffffff92401153>] do_one_initcall+0x43/0x210 [<ffffffff9254f42a>] do_init_module+0x4a/0x200 [<ffffffff92551d1c>] __do_sys_finit_module+0xac/0x120 [<ffffffff92ee6626>] do_syscall_64+0x56/0x80 [<ffffffff9300006a>] entry_SYSCALL_hwframe+after 0x46/0xb0 通过卸载驱动程序验证该泄漏确实存在导致分配的悬摆指针。已分配内存在 rtw_usb_intf_deinit() 中释放。 (CVE-2023-53529)

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

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

  - 已修复 Linux 内核中的下列漏洞：wifi: rtw89: fix potential leak in rtw89_append_probe_req_ie() Do `kfree_skb(new)` before `goto out` to prevent potential leak.
    (CVE-2023-53467)

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

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

  - scsiqla2xxx使用 raw_smp_processor_id() 而不是 smp_processor_id() 发现了以下调用跟踪本地主机内核nvme nvme0: NVME-FC{0}控制器连接完成本地主机内核缺陷
    在可抢占的 [00000000] 代码中使用 smp_processor_id()kworker/u129:4/75092 localhost kernel: nvme nvme0: NVME-FC{0}: new ctrlNQN nqn.1992-08.com.netapp:sn.b42d198afb4d11ecad6d00a098d6abfa:subsystem。 PR_Channel2022_RH84_subsystem_291 localhost kernel: 调用者为 qla_nvme_post_cmd+0x216/0x1380 [qla2xxx] localhost kernel: CPU: 6 PID: 75092 Comm: kworker/u129:4 Kdump:已加载 Tainted: GBW OE --------- --- 5.14 .0-70.22.1.el9_0.x86_64+debug #1 localhost 内核硬件名称HPE ProLiant XL420 Gen10/ProLiant XL420 Gen10、BIOS U39 01/13/2022 localhost 内核工作队列nvme-wq nvme_async_event_work [nvme_core ] localhost 内核调用跟踪
    localhost 内核dump_stack_lvl+0x57/0x7d localhost 内核check_preemption_disabled+0xc8/0xd0 localhost 内核qla_nvme_post_cmd+0x216/0x1380 [qla2xxx] 使用 raw_smp_processor_id() 而不是 smp_processor_id()。
    同样在驱动程序中使用 queue_work() 而不是 queue_work_on()从而避免在启用 CONFIG_DEBUG_PREEMPT 时使用 smp_processor_id()。 (CVE-2023-53530)

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

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

  - stagingrtl8723bs修复 rtw_init_drv_sw() 中可能的内存泄漏。在 rtw_init_drv_sw() 中存在调用多种 init 函数以填充 padapter 结构以及对其返回值的一些检查。
    但是，除了第一个错误路径之外，其他五个错误路径都未正确释放之前分配的资源，从而导致各种内存泄漏。此 修补程序可修复这些问题并使成功与错误保持分离。请注意这些更改保留了 drivers/staging/r8188eu/os_dep/os_intfs.c 中“rtw_init_drv_sw()”的形式。由于没有可测试的适当设备，因此未执行任何运行时测试。 (CVE-2022-50469)

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

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

  - 已修复 Linux 内核中的下列漏洞：hsr: Fix uninit-value access in fill_frame_info() Syzbot reports the following uninit-value access problem.
    ===================================================== BUG: KMSAN: uninit-value in fill_frame_info net/hsr/hsr_forward.c:601 [inline] BUG: KMSAN: uninit-value in hsr_forward_skb+0x9bd/0x30f0 net/hsr/hsr_forward.c:616 fill_frame_info net/hsr/hsr_forward.c:601 [inline] hsr_forward_skb+0x9bd/0x30f0 net/hsr/hsr_forward.c:616 hsr_dev_xmit+0x192/0x330 net/hsr/hsr_device.c:223 __netdev_start_xmit include/linux/netdevice.h:4889 [inline] netdev_start_xmit include/linux/netdevice.h:4903 [inline] xmit_one net/core/dev.c:3544 [inline] dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3560
    __dev_queue_xmit+0x34d0/0x52a0 net/core/dev.c:4340 dev_queue_xmit include/linux/netdevice.h:3082 [inline] packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3087 [inline] packet_sendmsg+0x8b1d/0x9f30 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [inline] sock_sendmsg net/socket.c:753 [inline] __sys_sendto+0x781/0xa30 net/socket.c:2176 __do_sys_sendto net/socket.c:2188 [inline] __se_sys_sendto net/socket.c:2184 [inline] __ia32_sys_sendto+0x11f/0x1c0 net/socket.c:2184 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline]
    __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178 do_fast_syscall_32+0x37/0x80 arch/x86/entry/common.c:203 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:246 entry_SYSENTER_compat_after_hwframe+0x70/0x82 Uninit was created at: slab_post_alloc_hook+0x12f/0xb70 mm/slab.h:767 slab_alloc_node mm/slub.c:3478 [inline] kmem_cache_alloc_node+0x577/0xa80 mm/slub.c:3523 kmalloc_reserve+0x148/0x470 net/core/skbuff.c:559 __alloc_skb+0x318/0x740 net/core/skbuff.c:644 alloc_skb include/linux/skbuff.h:1286 [inline] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6299 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2794 packet_alloc_skb net/packet/af_packet.c:2936 [inline] packet_snd net/packet/af_packet.c:3030 [inline] packet_sendmsg+0x70e8/0x9f30 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [inline] sock_sendmsg net/socket.c:753 [inline] __sys_sendto+0x781/0xa30 net/socket.c:2176 __do_sys_sendto net/socket.c:2188 [inline]
    __se_sys_sendto net/socket.c:2184 [inline] __ia32_sys_sendto+0x11f/0x1c0 net/socket.c:2184 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178 do_fast_syscall_32+0x37/0x80 arch/x86/entry/common.c:203 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:246 entry_SYSENTER_compat_after_hwframe+0x70/0x82 It is because VLAN not yet supported in hsr driver. Return error when protocol is ETH_P_8021Q in fill_frame_info() now to fix it. (CVE-2023-53462)

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

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

  - scsiufscore修复对 lrbp->cmd 的处理 在 SCSI 命令完成之前可针对 SCSI 命令连续调用两次 ufshcd_queuecommand()。因此进行以下更改- 在提交命令的函数中不检查 lrbp->cmd 的旧值也不清除错误路径中的 lrbp->cmd。- 在 ufshcd_release_scsi_cmd() 中不清除 lrbp->cmd。另请参阅 scsi_send_eh_cmnd()。此提交可防止在命令超时时出现以下内容WARNING: at drivers/ufs/core/ufshcd.c:2965 ufshcd_queuecommand+0x6f8/0x9a8 Call traceufshcd_queuecommand+0x6f8/0x9a8 scsi_send_eh_cmnd+0x2c0/0x960 scsi_eh_test_devices+0x100/0x314 scsi_eh_ready_devs+0xd90/0x114c scsi_error_handler+0x2b4/0xb70 kthread+0x16c/0x1e0 (CVE-2023-53510)

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

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

  - scsilpfc修复 GFT_ID 的异常退出路径中的空 ndlp ptr 取消引用。在错误情况下从 lpfc_cmpl_ct_cmd_gft_id() 退出会导致对 lpfc_nlp_put() 的调用带有节点列表结构的空指针。
    更改了 lpfc_cmpl_ct_cmd_gft_id() 以在进入时初始化 nodelist 指针。 (CVE-2022-50467)

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

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

  - virtio-mmio不中断 vm_dev 的生命周期 vm_dev 具有单独的生命周期因为它嵌入了“struct device”。因此为其提供发布回调是正确的。但是为具有 devres 的 vm_dev struct 分配会完全破坏此保护。删除 platform_device 时会释放内存，而不是等待 vm_dev 释放回调。最终调用回调时导致释放后使用。若要轻松发现此问题请使用 CONFIG_DEBUG_KOBJECT_RELEASE 编译内核并使用 sysfs 取消绑定。修复方法很简单在此情况下不使用 devres 即可。在我研究对象生命周期问题的过程中发现。 (CVE-2023-53515)

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

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

  - cangs_usb修复时间戳计数器初始化 如果在关闭接口之前卸载gs_usb 设备驱动程序则 USB 堆栈会首先调用 struct usb_driver::disconnect然后调用 struct net_device_ops::ndo_stop 回调。在 gs_usb_disconnect() 中所有待定的批量 URB 均终止即 USB 设备不再将任何经过 RX'ed 的 CAN 帧从 USB 设备发送到主机。稍后在 gs_can_close() 中系统会向每个 CAN 通道发送重置控制消息以从 CAN 总线删除控制器。在此争用窗口中USB 设备仍可从总线接收 CAN 帧并在内部将其排入队列以便发送到主机。
    至少在当前版本的 candlelight 固件中在重置命令期间不会清空接收到的 CAN 帧队列。加载（或绑定）gs_usb 驱动程序后在 struct net_device_ops::ndo_open 回调期间提交新的 URB并且 candlelight 固件开始将其已排队的 CAN 帧发送到主机。但是，在实现硬件时间戳函数时未考虑这种情况。周期计数器/时间计数器基础架构在 USB 提交之后设置 (gs_usb_timestamp_init())如果执行 timecounter_cyc2time() 通过调用链 gs_usb_receive_bulk_callback() -> gs_usb_set_timestamp() -> gs_usb_skb_set_timestamp()则导致空指针取消引用) 调用过早。在提交 URB 之前移动 gs_usb_timestamp_init() 函数以修复此问题。对于全面的解决方案我们需要考虑具有超过 1 个通道的 gs_usb 设备。周期计数器/时间计数器基础设施是按通道设置的，但 RX URB 是按设备设置的。调用 a_ 通道的 gs_can_open() 并且提交 URB后即可针对_all_可用通道调用 gs_usb_receive_bulk_callback()即使通道目前尚未运行。由于周期计数器/时间计数器尚未设置因此这将再次导致空指针取消引用。将周期计数器/时间计数器从每个通道的功能转换为每个设备的功能。
    您也可以在向 设备提交任何 URB 之前对其进行设置。此外在 gs_usb_receive_bulk_callback() 中也不处理未启动的 CAN 通道的任何 URB而仅重新提交 URB。 (CVE-2023-53523)

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

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

  - ACPI处理器检查 fch_misc_setup() 中 devm_kzalloc() 的空返回 devm_kzalloc() 可能会失败clk_data->name 可能为 NULL并将在之后造成空指针取消引用。 [ rjw主题和变更日志编辑 ] (CVE-2023-53483)

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

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

  - kobject当我以下列方式注册 kset 时为 kset_register() 中的 kset->kobj.ktype 添加健全性检查static struct kset my_kset kobject_set_name(&my_kset.kobj, my_kset); ret = kset_register(&my_kset);发生空指针取消引用异常[ 4453.568337] 无法处理 \ 虚拟地址 0000000000000028 处的内核空指针取消引用 ... ... [ 4453.810361] 调用跟踪[4453.813062] kobject_get_ownership+0xc/0x34 [ 4453.817493] kobject_add_internal+0x98/0x274 [ 4453.822005] kset_register+0x5c/0xb4 [ 4453.825820] my_kobj_init+0x44/0x1000 [my_kset] ... ... 因为我没有初始化 my_kset.kobj.ktype。根据 Documentation/core-api/kobject.rst 中的描述 - ktype 是嵌入 kobject 的对象类型。每个嵌入 kobject 的结构都需要相应的 ktype。因此添加健全性检查以确保 kset->kobj.ktype 不为 NULL。 (CVE-2023-53480)

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

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

  - io_uring退出时中断等待请求完成当退出环时，会完成清理并由 io_ring_exit_work 完成最终取消和等待。该函数由不采用任何信号的 kworker 调用。因此在 TASK_INTERRUPTIBLE 或 TASK_UNINTERRUPTIBLE 状态中等待完成实际上并不重要。但是，这对挂起任务检测检查程序而言确实如此。通常我们预计取消和完成会很快发生。但是有些测试用例会退出环并保留已停止的任务例如通过 SIGSTOP。如果拥有的任务需要运行 task_work 以完成请求则 io_ring_exit_work 将不会取得任何进度直到该任务再次可运行。因此 io_ring_exit_work 可以触发挂起任务检测这在启用 panic-on-hung-task 时特别成问题。由于环退出一开始不会接受信号请使其以可中断的方式而非不间断地等待。 io_uring 有一个无论如何都会独立触发的单独的卡住退出警告因此我们进行此切换并没有真正错过任何内容。 (CVE-2023-53461)

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

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

  - 已修复 Linux 内核中的下列漏洞：s390/dasd: Fix potential memleak in dasd_eckd_init() `dasd_reserve_req` is allocated before `dasd_vol_info_req`, and it also needs to be freed before the error returns, just like the other cases in this function. (CVE-2023-53449)

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

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

  - Omnibox 中的不当实现。 (CVE-2025-11213)

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

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

  - Omnibox 中的不当实现。 (CVE-2025-11209)

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

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

  - ext4在 DIO 写入之后创建内联数据时避免崩溃使用直接 IO 创建和写入 inode 时不执行任何操作清除 EXT4_STATE_MAY_INLINE_DATA 标记。因此当 inode 稍后被截断为 1 个字节并使用正常写入方式写入时我们将尝试将数据存储为内联数据。这会混淆之后的代码因为 inode 现在同时分配了普通块和内联数据并且混淆会显示为 kernel BUG at fs/ext4/inode.c:2721!无效 opcode0000 [#1] PREEMPT SMP KASAN CPU: 0 PID: 359 Comm: repro Not tainted 5.19.0-rc8-00001-g31ba1e3b8305-dirty #15 硬件名称
    QEMU Standard PC (i440FX + PIIX, 1996)、BIOS 1.16.0-1.fc36 04/01/2014 RIP
    0010:ext4_writepages+0x363d/0x3660 RSP0018:ffffc90000ccf260 EFLAGS00010293 RAX: ffffffff81e1abcd RBX
    0000008000000000 RCX: ffff88810842a180 RDX: 0000000000000000 RSI: 0000008000000000 RDI: 0000000000000000 RBP: ffffc90000ccf650 R08: ffffffff81e17d58 R09: ffffed10222c680b R10: dfffe910222c680c R11:
     R121ffff110222c680a  : ffff888111634128 R13: ffffc90000ccf880 R14: 0000008410000000 R15: 0000000000000001 FS: 00007f72635d2640(0000) GS:ffff88811b000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000565243379180 CR3: 000000010aa74000 CR4: 0000000000150eb0 Call Trace: <TASK> do_writepages+0x397/0x640 filemap_fdatawrite_wbc+0x151/0x1b0 file_write_and_wait_range+0x1c9/0x2b0 ext4_sync_file+0x19e/0xa00 vfs_fsync_range+0x17b/0x190 ext4_buffered_write_iter+0x488/0x530 ext4_file_write_iter+0x449/0x1b90 vfs_write+0xbcd/0xf40 ksys_write+ 0x198/0x2c0 __x64_sys_write+0x7b/0x90 do_syscall_64+0x3d/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> 通过对文件执行直接 IO 写入通过清除 EXT4_STATE_MAY_INLINE_DATA 来修复此问题。 (CVE-2022-50435)

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

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

  - ext4修复快速提交区块填充中的差一错误 由于多个不同的差一错误或者可能由于后期的设计变更未完全反映在实际合并的代码中关于如何用 tlv 条目填充快速提交区块有几个很奇怪的限制- 即使最小 tlv 长度为 8仍必须在区块结束前至少 10 个字节开始。
    否则，重放代码将忽略它们。缺陷如果使用长度为 blocksize - 9 或 blocksize - 8 的调用ext4_fc_reserve_space() 可能会违反此要求。幸运的是目前似乎不会发生这种情况。 - tlvs 必须在区块结束前至少 1 个字节结束。否则回放代码将认为它们无效。此 quirk 导致了一个缺陷已由较早的提交修复其中未初始化的内存在区块的最后一个字节中被泄漏到磁盘。此外奇怪的是这些限制不适用于 e2fsprogs 中的重放代码该代码将接受区块中的任何 tlvs完全没有边界检查但这是一个单独的问题...。鉴于这似乎都是一个缺陷我们来通过以自然方式使用 tlv 条目填充区块来修复它请注意旧内核将无法重播具有此提交的内核所创建的快速提交日志。 (CVE-2022-50428)

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

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

  - mediacx23885修复 buffer_prepare() 和 buffer_finish() 中的 null-ptr-deref 缺陷当驱动程序调用 cx23885_risc_buffer() 以准备缓冲区时函数调用 dma_alloc_coherent 可能会失败从而导致空缓冲区 risc->cpu。稍后释放缓冲区或访问缓冲区时会触发空指针取消引用。
    此缺陷类似于以下缺陷
    https://git.linuxtv.org/media_stage.git/commit/?id=2b064d91440b33fba5b452f2d1b31f13ae911d71。我们认为也可从用户端动态触发此缺陷。同样，我们通过在缓冲区释放之前检查 cx23885_risc_buffer() 的返回值和 risc->cpu 的值来修复此问题。 (CVE-2023-53458)

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

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

  - 在 4.2.25 版之前的 Django 4.2、5.1.13 版之前的 Django 5.1 以及 5.2.7 版之前的 Django 5.2 中发现一个问题。startapp --template 和 startproject --template 命令使用的 django.utils.archive.extract() 函数允许通过文件路径与目标目录共享通用前缀的存档进行部分目录遍历。 (CVE-2025-59682)

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

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

  - nbd修复 ioctl arg 的不完整验证。我们测试后发现未经验证的 nbd_ioctl arg 会引起警报。类似下面的 UBSAN 警告 calltrace： UBSAN: Undefined Behaviour in fs/buffer.c:1709:35 signed Integer溢出: -9223372036854775808 - 1 cannot be present in type 'long long int' CPU: 3 PID: 2523 Comm: syz-executor .0 未受感染 4.19.90 #1 硬件名称linux,dummy-virt (DT) 调用跟踪
    dump_backtrace+0x0/0x3f0 arch/arm64/kernel/time.c:78 show_stack+0x28/0x38 arch/arm64/kernel/traps.c:158
    __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x170/0x1dc lib/dump_stack.c:118 ubsan_epilogue+0x18/0xb4 lib/ubsan.c:161 handle_overflow+0x188/0x1dc lib/ubsan.c:192
    __ubsan_handle_sub_overflow+0x34/0x44 lib/ubsan.c:206 __block_write_full_page+0x94c/0xa20 fs/buffer.c:1709 block_write_full_page+0x1f0/0x280 fs/buffer.c:2934 blkdev_writepage+0x34/0x40 fs/block_dev.c:607
    __writepage+0x68/0xe8 mm/page-writeback.c:2305 write_cache_pages+0x44c/0xc70 mm/page-writeback.c:2240 generic_writepages+0xdc/0x148 mm/page-writeback.c:2329 blkdev_writepages+0x2c/0x38 fs/block_dev .c:2114 do_writepages+0xd4/0x250 mm/page-writeback.c:2344 触发此警告的原因是
    __block_write_full_page() -> i_size_read(inode) - 1 溢出。 inode->i_size 在 __nbd_ioctl() 中分配
    -> nbd_set_size() -> bytesize。我们认为有必要限制 arg 的大小以防止错误。
    此外__nbd_ioctl() -> nbd_add_socket()arg 将转换为 int。假设 arg 的值为 0x80000000000000001)64 位计算机在执行强制转换后将变为 1这将返回意外结果。通过添加检查防止传递过大数字来修复此问题。 (CVE-2023-53513)

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

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

  - wifirtw88修复 rtw_usb_probe() drivers/net/wireless/realtek/rtw88/usb.c:876 rtw_usb_probe() 警告中的内存泄漏未在行上释放 ieee80211_alloc_hw() 的 'hw'811 通过修改返回来修复此问题跳转到 goto 语句。 (CVE-2023-53460)

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

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

  - mmcvub300修复警告 - 当 !TASK_RUNNING vub300_enable_sdio_irq() 用于互斥体并需要 TASK_RUNNING 时不调用阻断 ops。确保将当前标记为可休眠上下文的 TASK_RUNNING。 [77.554641] !TASK_RUNNING; 时不调用阻断 ops在 [<ffffffff92a72c1d>] sdio_irq_thread+0x17d/0x5b0 设置的 state=1 [ 77.554652] 警告CPU:2 PID1983在 kernel/sched/core.c:9813
    __might_sleep+0x116/0x160 [ 77.554905] CPU2 PID1983 Comm: ksdioirqd/mmc1 受感染: G OE 6.1.0-rc5 #1 [77.554910] 硬件名称Intel(R) Client Systems NUC8i7BEH/NUC8BEB、BIOS BECFL357.86A.0081.2020.0504.1834 05/04/2020 [ 77.554912] RIP: 0010:__might_sleep+0x116/0x160 [ 77.554920] RSP: 0018:ffff888107b7fdb8 EFLAGS: 00010282 [ 77.554923] RAX: 0000000000000000 RBX: ffff888118c1b740 RCX: 0000000000000000 [77.554926] RDX: 0000000000000001 RSI: 0000000000000004 RDI: ffffed1020f6ffa9 [ 77.554928] RBP
    ffff888107b7fde0 R080000000000000001 R09ffffed1043ea60ba [ 77.554930] R10ffff88821f5305cb R11
    ffffed1043ea60b9 R12ffffffff93aa3a60 [ 77.554932] R13000000000000011b R147ffffffffffffff R15
    ffffffffc0558660 [ 77.554934] FS: 0000000000000000(0000) GS:ffff88821f500000(0000) knlGS:0000000000000000 [ 77.554937] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 77.554939] CR2: 00007f8a44010d68 CR3:
    000000024421a003 CR4: 00000000003706e0 [ 77.554942] 调用跟踪[ 77.554944] <TASK> [ 77.554952] mutex_lock+0x78/0xf0 [ 77.554973] vub300_enable_sdio_irq+0x103/0x3c0 [vub300] [ 77.554981] [ 77.555006/] sdio_irq_thread+0x25c ] kthread+0x2b8/0x370 [ 77.555017] ret_from_fork+0x1f/0x30 [77.555023] </TASK> [ 77.555025] ---[ 结束跟踪 0000000000000000 ]--- (CVE-2022-50430)

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

ID	名称	严重性
269629	Linux Distros 未修补的漏洞：CVE-2023-53465	high
269628	Linux Distros 未修补的漏洞：CVE-2025-11207	critical
269627	Linux Distros 未修补的漏洞：CVE-2022-50423	high
269626	Linux Distros 未修补的漏洞：CVE-2023-53504	medium
269625	Linux Distros 未修补的漏洞：CVE-2023-53527	medium
269623	Linux Distros 未修补的漏洞：CVE-2023-53499	medium
269622	Linux Distros 未修补的漏洞：CVE-2025-11216	critical
269621	Linux Distros 未修补的漏洞：CVE-2022-50464	high
269620	Linux Distros 未修补的漏洞：CVE-2022-50458	high
269619	Linux Distros 未修补的漏洞：CVE-2023-53496	medium
269618	Linux Distros 未修补的漏洞：CVE-2023-53456	high
269617	Linux Distros 未修补的漏洞：CVE-2023-53489	medium
269616	Linux Distros 未修补的漏洞：CVE-2023-53519	medium
269615	Linux Distros 未修补的漏洞：CVE-2023-53505	medium
269614	Linux Distros 未修补的漏洞：CVE-2023-53500	high
269613	Linux Distros 未修补的漏洞：CVE-2022-50465	high
269612	Linux Distros 未修补的漏洞：CVE-2023-53464	medium
269611	Linux Distros 未修补的漏洞：CVE-2023-53526	high
269610	Linux Distros 未修补的漏洞：CVE-2023-53512	medium
269609	Linux Distros 未修补的漏洞：CVE-2023-53507	medium
269608	Linux Distros 未修补的漏洞：CVE-2023-53466	medium
269607	Linux Distros 未修补的漏洞：CVE-2022-50429	high
269606	Linux Distros 未修补的漏洞：CVE-2023-53482	medium
269605	Linux Distros 未修补的漏洞：CVE-2023-53498	medium
269604	Linux Distros 未修补的漏洞：CVE-2022-50459	medium
269603	Linux Distros 未修补的漏洞：CVE-2022-50445	medium
269602	Linux Distros 未修补的漏洞：CVE-2022-50442	high
269601	Linux Distros 未修补的漏洞：CVE-2023-53471	high
269600	Linux Distros 未修补的漏洞：CVE-2023-53529	medium
269599	Linux Distros 未修补的漏洞：CVE-2023-53467	high
269598	Linux Distros 未修补的漏洞：CVE-2023-53530	high
269597	Linux Distros 未修补的漏洞：CVE-2022-50469	medium
269596	Linux Distros 未修补的漏洞：CVE-2023-53462	medium
269595	Linux Distros 未修补的漏洞：CVE-2023-53510	high
269594	Linux Distros 未修补的漏洞：CVE-2022-50467	medium
269593	Linux Distros 未修补的漏洞：CVE-2023-53515	high
269592	Linux Distros 未修补的漏洞：CVE-2023-53523	medium
269591	Linux Distros 未修补的漏洞：CVE-2023-53483	medium
269590	Linux Distros 未修补的漏洞：CVE-2023-53480	medium
269589	Linux Distros 未修补的漏洞：CVE-2023-53461	medium
269588	Linux Distros 未修补的漏洞：CVE-2023-53449	medium
269587	Linux Distros 未修补的漏洞：CVE-2025-11213	critical
269586	Linux Distros 未修补的漏洞：CVE-2025-11209	critical
269585	Linux Distros 未修补的漏洞：CVE-2022-50435	high
269584	Linux Distros 未修补的漏洞：CVE-2022-50428	medium
269583	Linux Distros 未修补的漏洞：CVE-2023-53458	medium
269582	Linux Distros 未修补的漏洞：CVE-2025-59682	low
269581	Linux Distros 未修补的漏洞：CVE-2023-53513	high
269580	Linux Distros 未修补的漏洞：CVE-2023-53460	medium
269579	Linux Distros 未修补的漏洞：CVE-2022-50430	medium

检测

Nessus 的 Misc. 系列

high

critical

high

medium

medium

medium

critical

high

high

medium

high

medium

medium

medium

high

high

medium

high

medium

medium

medium

high

medium

medium

medium

medium

high

high

medium

high

high

medium

medium

high

medium

high

medium

medium

medium

medium

medium

critical

critical

high

medium

medium

low

high

medium

medium