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

  - Web Compatibility: Tooling 组件中存在缓解措施绕过。此漏洞影响 Firefox < 143 和 Thunderbird < 143。 (CVE-2025-10531

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

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

  - 已修复 Linux 内核中的下列漏洞：power: supply: axp288_fuel_gauge: Fix external_power_changed race fuel_gauge_external_power_changed() dereferences info->bat, which gets sets in axp288_fuel_gauge_probe() like this: info->bat = devm_power_supply_register(dev, &fuel_gauge_desc, &psy_cfg); As soon as devm_power_supply_register() has called device_add() the external_power_changed callback can get called. So there is a window where fuel_gauge_external_power_changed() may get called while info->bat has not been set yet leading to a NULL pointer dereference. Fixing this is easy. The external_power_changed callback gets passed the power_supply which will eventually get stored in info->bat, so fuel_gauge_external_power_changed() can simply directly use the passed in psy argument which is always valid. (CVE-2023-53310)

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

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

  - REXML 是适用于 Ruby 的 XML 工具包。REXML gems 3.3.3 到 3.4.1 在解析包含多个 XML 声明的 XML 时存在一个 DoS 漏洞。如果需要解析不受信任的 XML，您可能会受到这些漏洞的影响。REXML gem 3.4.2 或更高版本包含用于修复这些漏洞的补丁。
    (CVE-2025-58767)

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

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

  - 已修复 Linux 内核中的下列漏洞：net/mlx5: Collect command failures data only for known commands DEVX can issue a general command, which is not used by mlx5 driver. In case such command is failed, mlx5 is trying to collect the failure data, However, mlx5 doesn't create a storage for this command, since mlx5 doesn't use it. This lead to array-index-out-of-bounds error. Fix it by checking whether the command is known before collecting the failure data. (CVE-2023-53340)

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

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

  - 已修复 Linux 内核中的下列漏洞：cifs: Fix memory leak when build ntlmssp negotiate blob failed There is a memory leak when mount cifs: unreferenced object 0xffff888166059600 (size 448): comm mount.cifs, pid 51391, jiffies 4295596373 (age 330.596s) hex dump (first 32 bytes): fe 53 4d 42 40 00 00 00 00 00 00 00 01 00 82 00 .SMB@........... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000060609a61>] mempool_alloc+0xe1/0x260 [<00000000adfa6c63>] cifs_small_buf_get+0x24/0x60 [<00000000ebb404c7>] __smb2_plain_req_init+0x32/0x460 [<00000000bcf875b4>] SMB2_sess_alloc_buffer+0xa4/0x3f0 [<00000000753a2987>] SMB2_sess_auth_rawntlmssp_negotiate+0xf5/0x480 [<00000000f0c1f4f9>] SMB2_sess_setup+0x253/0x410 [<00000000a8b83303>] cifs_setup_session+0x18f/0x4c0 [<00000000854bd16d>] cifs_get_smb_ses+0xae7/0x13c0 [<000000006cbc43d9>] mount_get_conns+0x7a/0x730 [<000000005922d816>] cifs_mount+0x103/0xd10 [<00000000e33def3b>] cifs_smb3_do_mount+0x1dd/0xc90 [<0000000078034979>] smb3_get_tree+0x1d5/0x300 [<000000004371f980>] vfs_get_tree+0x41/0xf0 [<00000000b670d8a7>] path_mount+0x9b3/0xdd0 [<000000005e839a7d>] __x64_sys_mount+0x190/0x1d0 [<000000009404c3b9>] do_syscall_64+0x35/0x80 When build ntlmssp negotiate blob failed, the session setup request should be freed. (CVE-2022-50372)

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

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

  - accel/habanalabs修复捕获用户映射中的内存泄漏 此提交修复了在捕获 user_mapping 并执行硬重置之后立即打开新的上下文时清除 user_mappings 信息时导致的内存泄漏。 (CVE-2023-53367)

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

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

  - fsdlm修复 lowcomms 中的争用 此修补程序修复 _dlm_lowcomms_commit_msg() 与 srcu_read_unlock() 中 queue_work() 之间的争用。queue_work() 可能取得 dlm_msg 的最终引用因此 msg->idx 可能包含由以下警告表示的垃圾[ 676.237050]------------[在此切换]- ----------- [ 676.237052] WARNINGCPU:0 PID1060 at include/linux/srcu.h:189 dlm_lowcomms_commit_msg+0x41/0x50 [ 676.238945] 中链接的模块dlm_locktorture 审查 rpcsec_gss_krb5 intel_rapl_msr intel_rapl_common iTCO_wdt iTCO_vendor_support qxl kvm_intel drm_ttm_helper vmw_vsock_virtio_transport kvm vmw_vsock_virtio_transport_common ttm irqbypass crc32_pclmul joydev crc32c_intel serio_raw drm_kms_helper vsock virtio_scsi virtio_console virtio_balloon snd_pcm drm syscopyarea sysfillrect sysimgblt snd_timer fb_sys_fops i2c_i801 lpc_ich snd i2c_smbus soundcore pcspkr [676.244227] CPU: 0 PID: 1060 Comm: lock_torture_wr Not tainted 5.19. 0-rc3+ #1546 [ 676.245216] 硬件名称Red Hat KVM/RHEL-AV、BIOS 1.16.0-2.module+el8.7.0+15506+033991b0 04/01/2014 [ 676.246460] RIP
    0010:dlm_lowcomms_commit_msg+0x41/0x50 [ 676.247132] Codefe ff ff ff 75 24 48 c7 c6 bd 0f 49 bb 48 c7 c7 38 7c 01 bd e8 00 e7 ca ff 89 de 48 c7 c7 60 78 01 bd e8 42 3d cd ff 5b 5d c3 <0f> 0b eb d8 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 [ 676.249253] RSP: 0018:ffffa401c18ffc68 EFLAGS: 00010282 [676.249855] RAX: 0000000000000001 RBX: 00000000ffff8b76 RCX: 0000000000000006 [ 676.250713] RDX:
    0000000000000000 RSIffffffffbccf3a10 RDIffffffffbcc7b62e [ 676.251610] RBPffffa401c18ffc70 R08
    0000000000000001 R09: 0000000000000001 [ 676.252481] R10: 0000000000000001 R11: 0000000000000001 R12:
    0000000000000005 [ 676.253421] R13: ffff8b76786ec370 R14: ffff8b76786ec370 R15: ffff8b76786ec480 [676.254257] FS: 0000000000000000(0000) GS:ffff8b7777800000(0000) knlGS:0000000000000000 [ 676.255239] CS:
    0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 676.255897] CR2: 00005590205d88b8 CR3: 000000017656c003 CR4: 0000000000770ee0 [ 676.256734] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [676.257567] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 676.258397] PKRU55555554 [ 676.258729] 调用跟踪[ 676.259063] <TASK> [ 676.259354] dlm_midcomms_commit_mhandle+0xcc/0x110 [676.259964] queue_bast+0x8b/0xb0 [ 676.260423] grant_pending_locks+0x166/0x1b0 [ 676.261007]
    _unlock_lock+0x75/0x90 [ 676.261469] unlock_lock.isra.57+0x62/0xa0 [ 676.262009] dlm_unlock+0x21e/0x330 [676.262457] ? lock_torture_stats+0x80/0x80 [dlm_locktorture] [ 676.263183]torture_unlock+0x5a/0x90 [dlm_locktorture] [ 676.263815] ? preempt_count_sub+0xba/0x100 [ 676.264361] ? complete+0x1d/0x60 [676.264777] lock_torture_writer+0xb8/0x150 [dlm_locktorture] [ 676.265555] kthread+0x10a/0x130 [676.266007] ? kthread_complete_and_exit+0x20/0x20 [ 676.266616] ret_from_fork+0x22/0x30 [ 676.267097] </TASK> [ 676.267381] irq 事件标记9579855 [ 676.267824] hardirqs last enabled at (9579863):
    [<ffffffffbb14e6f8>] __up_console_sem+0x58/0x60 [ 676.268896] hardirqs 上次禁用是在 (9579872)
    [<ffffffffbb14e6dd>] __up_console_sem+0x3d/0x60 [ 676.270008] softirqs 启用于 (9579798)
    [<ffffffffbc200349>] __do_softirq+0x349/0x4c7 [ 676.271438] softirqs 上次禁用是在 (9579897):
    [<ffffffffbb0d54c0>] irq_exit_rcu+0xb0/0xf0 [ 676.272796] ---[ end trace 0000000000000000 ]--- 我使用 dlm_locktorture 测试重现了此警告该测试当前不是上游。不过此修补程序通过在 dlm_lowcomms_new_msg() 和 dlm_lowcomms_commit_msg() 之间进行额外的 refcount 修复该问题。万一发生争用dlm_lowcomms_commit_msg() 中的 kref_put() 将成为最终结果。 (CVE-2022-50373)

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

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

  - stagingpi433使用 debugfs_lookup() 修复内存泄漏调用 debugfs_lookup() 时结果必须调用 dput() 否则内存将随着时间泄漏。要使事情更简单只需调用 debugfs_lookup_and_remove()其会同时处理所有逻辑。这需要保存根目录 dentry 以便更容易地创建单个设备子目录。 (CVE-2023-53355)

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

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

  - ksmbd修复并行 smb2 树断开连接下的 racy 问题 在并行 smb2 树断开连接下存在 UAF 问题。此修补程序为 tcon 引入了 TREE_CONN_EXPIRE 标记以避免并发访问。
    (CVE-2023-53358)

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

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

  - 已修复 Linux 内核中的下列漏洞：of/fdt: run soc memory setup when early_init_dt_scan_memory fails If memory has been found early_init_dt_scan_memory now returns 1. If it hasn't found any memory it will return 0, allowing other memory setup mechanisms to carry on. Previously early_init_dt_scan_memory always returned 0 without distinguishing between any kind of memory setup being done or not. Any code path after the early_init_dt_scan memory call in the ramips plat_mem_setup code wouldn't be executed anymore. Making early_init_dt_scan_memory the only way to initialize the memory. Some boards, including my mt7621 based Cudy X6 board, depend on memory initialization being done via the soc_info.mem_detect function pointer. Those wouldn't be able to obtain memory and panic the kernel during early bootup with the message early_init_dt_alloc_memory_arch: Failed to allocate 12416 bytes align=0x40. (CVE-2023-53341)

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

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

  - 已修复 Linux 内核中的下列漏洞：NFSv4.2: Rework scratch handling for READ_PLUS (again) I found that the read code might send multiple requests using the same nfs_pgio_header, but nfs4_proc_read_setup() is only called once. This is how we ended up occasionally double-freeing the scratch buffer, but also means we set a NULL pointer but non-zero length to the xdr scratch buffer. This results in an oops the first time decoding needs to copy something to scratch, which frequently happens when decoding READ_PLUS hole segments. I fix this by moving scratch handling into the pageio read code. I provide a function to allocate scratch space for decoding read replies, and free the scratch buffer when the nfs_pgio_header is freed. (CVE-2023-53360)

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

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

  - USB修复使用 debugfs_lookup() 造成的内存泄漏调用 debugfs_lookup() 时其结果必须调用 dput()否则内存将随着时间泄漏。要使事情更简单只需调用 debugfs_lookup_and_remove()其会同时处理所有逻辑。 (CVE-2023-53359)

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

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

  - Bluetoothhci_{ldisc,serdev}检查 percpu_init_rwsem() 失败syzbot 在 hci_uart_tty_close() [1] 中报告空指针取消引用因为 hci_uart_tty_open() 忽略 percpu_init_rwsem() 失败导致在没有 rcu_sync_init() 的情况下调用 rcu_sync_enter()。在修复过程中修复 hci_uart_register_device() 忽略 percpu_init_rwsem() 失败以及 hci_uart_unregister_device() 不调用 percpu_free_rwsem()。 (CVE-2022-50374)

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

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

  - accel/habanalabs将 mem_mgr IDR 破坏推迟到 hpriv_release() 目前内存管理器 IDR 在用户释放文件描述符时遭到破坏。但是，此时可能仍会保留用户上下文，并且可能仍在使用内存缓冲区。此后调用以释放这些缓冲区将失败因为未在 IDR 中找到其句柄从而导致内存泄漏。要避免此泄漏请从内存管理器 fini 拆分 IDR 销毁并在没有用户上下文且未使用缓冲区时将其推迟到 hpriv_release()。 (CVE-2023-53353)

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

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

  - net/mlx5通过上行链路 un/load API 处理 E-switch 配对如果用户将设备从 switchdev 模式切换到旧模式则 mlx5 会首先取消与 E-switch 配对然后卸载上行链路 vport。另一方面如果用户删除或重新加载设备mlx5 会首先卸载上行链路 vport然后取消与 E-switch 的配对。后者造成缺陷 [1]因此将 E-switch 配对作为上行链路 un/load API 的一部分来处理。 [1] 如果使用 VF_LAG每个 tc fdb 流都会复制到对等 esw。但是，原始 esw（而不是对等 esw）会保留指向此重复流的指针。例如如果用户在 esw0 上创建 tc fdb 流则流会在固件/硬件中的 esw1 上复制但在软件中esw0 会保留指向复制流的指针。在对等 tc fdb 流仍处于卸载状态下的模块卸载期间如果要删除的第一个设备是对等设备在上述示例中为 esw1则对等 net-dev 将遭到破坏因此 mlx5e_priv 的 memset 为 0。此后对等设备会尝试取消自身与原始设备（上例中为 esw0）的配对。取消配对 API 调用原始设备以清除其 eswitch (esw0) 中的对等机流但存储在原始 eswitch (esw0) 上的对等机流尝试使用对等机 mlx5e_priv其 memset 为 0 并导致下列结果kernel-oops。 [ 157.964081 ] BUG无法处理地址的页面错误
    000000000002ce60 [ 157.964662 ] #PF内核模式下的主管读取访问 [ 157.965123 ] #PF
    error_code(0x0000) - 不存在页面 [ 157.965582 ] PGD 0 P4D 0 [ 157.965866 ] Oops0000 [#1] SMP [157.967670 ] RIP0010:mlx5e_tc_del_fdb_flow+0x48/0x460 [mlx5_core] [ 157.976164 ] Call Trace[157.976437 ] <TASK> [ 157.976690 ] __mlx5e_tc_del_fdb_peer_flow+0xe6/0x100 [mlx5_core] [ 157.977230 ] mlx5e_tc_clean_fdb_peer_flows+0x67/0x90 [mlx5_core] [ 157.977767 ] mlx5_esw_offloads_unpair+0x2d/0x100 [mlx5_core] [s] mlx5_esw_offloads_unpair+0x2d/0x100 [mlx5_core] [ 157.984653 s ] 0xbf/0x130 [mlx5_core] [ 157.985212 ] mlx5_devcom_send_event+0xa3/0xb0 [mlx5_core] [ 157.985714 ] esw_offloads_disable+0x5a/0x110 [mlx5_core] [157.986209 ] mlx5_eswitch_disable_locked+0x152/0x170 [mlx5_core] [ 157.986757 ] mldis5_core] [switch 0x80 [mlx5_core] [ 157.987248 ] mlx5_unload+0x2a/0xb0 [mlx5_core] [ 157.987678 ] mlx5_uninit_one+0x5f/0xd0 [mlx5_core] [ 157.988127 ] remove_one+0x64/0xe0 [mlx5_core] [ 157.988549 ] pci_device_remove+0x31/0xa0 [ 157.988933 ] device_release_driver_internal+0x18f/0x1f0 [ 157.989402 ] driver_detach+0x3f/0x80 [ 157.989754 ] bus_remove_driver+0x70/0xf0 [ 157.990129 ] pci_unregister_driver+0x34/0x90 [ 157.990537 ] mlx5_cleanup+0xc/0x1c [mlx5_core] [ 157.990972 ]
    __x64_sys_delete_module+0x15a/0x250 [ 157.991398 ] ? exit_to_user_mode_prepare+0xea/0x110 [ 157.991840 ] do_syscall_64+0x3d/0x90 [ 157.992198 ] entry_SYSCALL_64_after_hwframe+0x46/0xb0 (CVE-2023-53347)

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

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

  - 已修复 Linux 内核中的下列漏洞：i2c: designware: Fix handling of real but unexpected device interrupts Commit c7b79a752871 (mfd: intel-lpss: Add Intel Alder Lake PCH-S PCI IDs) caused a regression on certain Gigabyte motherboards for Intel Alder Lake-S where system crashes to NULL pointer dereference in i2c_dw_xfer_msg() when system resumes from S3 sleep state (deep). I was able to debug the issue on Gigabyte Z690 AORUS ELITE and made following notes: - Issue happens when resuming from S3 but not when resuming from s2idle - PCI device 00:15.0 == i2c_designware.0 is already in D0 state when system enters into pci_pm_resume_noirq() while all other i2c_designware PCI devices are in D3.
    Devices were runtime suspended and in D3 prior entering into suspend - Interrupt comes after pci_pm_resume_noirq() when device interrupts are re-enabled - According to register dump the interrupt really comes from the i2c_designware.0. Controller is enabled, I2C target address register points to a one detectable I2C device address 0x60 and the DW_IC_RAW_INTR_STAT register START_DET, STOP_DET, ACTIVITY and TX_EMPTY bits are set indicating completed I2C transaction. My guess is that the firmware uses this controller to communicate with an on-board I2C device during resume but does not disable the controller before giving control to an operating system. I was told the UEFI update fixes this but never the less it revealed the driver is not ready to handle TX_EMPTY (or RX_FULL) interrupt when device is supposed to be idle and state variables are not set (especially the dev->msgs pointer which may point to NULL or stale old data). Introduce a new software status flag STATUS_ACTIVE indicating when the controller is active in driver point of view. Now treat all interrupts that occur when is not set as unexpected and mask all interrupts from the controller. (CVE-2022-50370)

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

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

  - icmp6修复 icmp6_dev() 中 ip6_null_entry->rt6i_idev 的 null-ptr-deref。通过某些 IPv6 Ext HdrRPL、SRv6 等我们可以发送具有链接本地地址作为 src 和 dst IP 且会被转发至 IPv6 Ext Hdr 中的外部 IP 的数据包。例如，以下脚本可生成一个数据包，其 src IP 为链路本地地址，dst 更新为 11::。 # for f in $(find /proc/sys/net/ -name *seg6_enabled*); do echo 1 > $fdid # python3 >>> from socket import * >>> from socket import * >>> from scapy.all import * >>> >>> SRC_ADDR = DST_ADDR = fe80::5054:ff:fe12:3456 >>> >>> pkt = IPv6(src =SRC_ADDR, dst=DST_ADDR) >>> pkt /= IPv6ExtHdrSegmentRouting(type=4, address=[11::, 22::], segleft=1) >>> >>> sk = socket(AF_INET6, SOCK_RAW, IPPROTO_RAW ) >>> sk.sendto(bytes(pkt), (DST_ADDR, 0)) 对于此类数据包，我们会调用 ip6_route_input()，以根据标头类型在这三个函数中查找下一个目标的路由。 * ipv6_rthdr_rcv() * ipv6_rpl_srh_rcv() * ipv6_srh_rcv() 如果未找到路由ip6_null_entry 会设置为 skb且后续的 dst_input(skb) 会调用 ip6_pkt_drop()。最后，在 icmp6_dev() 中，我们取消引用 skb_rt6_info(skb)->rt6i_idev->dev，因为输入设备是环回接口。然后我们必须检查 skb_rt6_info(skb)->rt6i_idev 是否为空以避免 ip6_null_entry 的空指针取消引用。
    缺陷#1缺陷python3 未受感染 6.4.0-11996-gb121d614371c #35 硬件名称QEMU Standard PC (i440FX + PIIX,1996)BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP 0010:icmp6_send (net/ipv6/icmp.c:436 net/ipv6/icmp.c:503) 代码 fe ff ff 48 c7 40 30 c0 86 5d 83 e8 c6 44 1c 00 e9 c8 fc ff ff 49 8b 46 58 48 83 e0 fe 0f 84 4a fb ff ff 48 8b 80 d0 00 00 00 <48> 8b 00 44 8b 88 e0 00 00 00 e9 34 fb ff ff 4d 85 ed 0f 85 69 01 RSP: 0018:ffffc90000003c:70 0EFLAX8 R02AX:70 0000000000000000 RBX
    0000000000000001 RCX: 00000000000000e0 RDX: 0000000000000021 RSI: 0000000000000000 RDI: ffff888006d72a18 RBP: ffffc90000003d80 R08: 0000000000000000 R09: 0000000000000001 R10: ffffc90000003d98 R11:
     R120000000000000040  : ffff888006d72a10 R13: 0000000000000000 R14: ffff8880057fb800 R15: ffffffff835d86c0 FS: 00007f9dc72ee740(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000000057b2000 CR4: 00000000007506f0 PKRU: 55555554 调用跟踪 <IRQ> ip6_pkt_drop (net/ipv6/route.c:4513) ipv6_rthdr_rcv (net/ipv6/exthdrs.c:640 net/ipv6/exthdrs.c:686) ip6_protocol_deliver_rcu (net/ipv6/ ip6_input.c:437 (标识符 5)) ip6_input_finish (./include/linux/rcupdate.h:781 net/ipv6/ip6_input.c:483) __netif_receive_skb_one_core (net/core/dev.c:5455) process_backlog (./include /linux/rcupdate.h:781 net/core/dev.c:5895) __napi_poll (net/core/dev.c:6460) net_rx_action (net/core/dev.c:6529 net/core/dev.c:6660) () __do_softirq (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/irq.h:142 kernel/softirq.c:554) do_softirq (kernel/softirq.c:454 kernel/softirq.c:441) </IRQ> <TASK>
    __local_bh_enable_ip (kernel/softirq.c:381) __dev_queue_xmit (net/core/dev.c:4231) ip6_finish_output2 (./include/net/neighbour.h:544 net/ipv6/ip6_output.c:135) rawv6_sendmsg (./include /net/dst.h:458 ./include/linux/netfilter.h:303 net/ipv6/raw.c:656 net/ipv6/raw.c:914sock_sendmsg (net/socket.c:725 net/socket .c:748) __sys_sendto (net/socket.c:2134) __x64_sys_sendto (net/socket.c:2146 net/socket.c:2142 net/socket.c:2142) do_syscall_64 (arch/x86/entry/common.c :50 arch/x86/entry/common.c:80) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120) RIP0033:0x7f9dc751baea 代码d8 64 89 02 48 c7 c0 ff f ---truncated--- (CVE-2023-53343)

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

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

  - md/raid10检查 md_bitmap_get_counter 中的 slab 越界如果将极大的数值写入 md/bitmap_set_bitsmd_bitmap_checkpage() 将返回 -EINVAL因为“page >= bitmap->pages”但返回值并非立即在 md_bitmap_get_counter() 中进行检查以便设置 *blocks 值和 slab 越界。将“page >= bitmap->pages”的检查移动到 md_bitmap_get_counter()并在为真时直接返回。 (CVE-2023-53357)

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

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

  - lwt修复 BPF xmit ops 的返回值 BPF encap ops 可从函数 skb_do_redirect 和 bpf_lwt_xmit_reroute 返回不同类型的正值例如 NET_RX_DROP、NET_XMIT_CN、NETDEV_TX_BUSY 等。在 xmit 挂钩处此类返回值会被隐式视为 ip(6)_finish_output2 中的 LWTUNNEL_XMIT_CONTINUE。发生这种情况时已释放的 skb 将继续与邻居子系统通信从而导致释放后使用缺陷和内核崩溃。要修复不正确的行为可简单地丢弃 skb_do_redirect 返回值这与 tc-egress 行为相同。另一方面bpf_lwt_xmit_reroute 会向本地发送者返回有用的错误例如 PMTU 信息。因此请转换其返回值以避免与 LWTUNNEL_XMIT_CONTINUE 发生冲突。 (CVE-2023-53338)

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

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

  - mediaipu-bridge修复当 ipu_bridge_parse_rotation() 和 ipu_bridge_parse_orientation() 运行时 sensor->adev 尚未设置时SSDB/PLD 解析警告上的空指针取消引用。因此如果命中任一有关未知值的 dev_warn() 调用将导致空指针取消引用。提早使用借用的 ref 设置 sensor->adev以避免发生错误时更难展开以修复此问题。 (CVE-2023-53336)

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

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

  - 已修复 Linux 内核中的下列漏洞：mlx5: fix possible ptp queue fifo use-after-free Fifo indexes are not checked during pop operations and it leads to potential use-after-free when poping from empty queue. Such case was possible during re-sync action. WARN_ON_ONCE covers future cases. There were out-of-order cqe spotted which lead to drain of the queue and use-after-free because of lack of fifo pointers check. Special check and counter are added to avoid resync operation if SKB could not exist in the fifo because of OOO cqe (skb_id must be between consumer and producer index).
    (CVE-2023-53398)

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

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

  - USBdwc3使用 debugfs_lookup() 修复内存泄漏调用 debugfs_lookup() 时结果必须调用 dput() 否则随着时间的推移内存将泄漏。要使事情更简单只需调用 debugfs_lookup_and_remove()其会同时处理所有逻辑。请注意需要保存设备的 debugfs 目录的根 dentry以便我们不必继续查找它需要更多位重构以便在需要时正确创建和删除它。 (CVE-2023-53415)

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

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

  - RDMA/mlx5修复用于设备的 mlx5_ib_get_hw_stats 当前在 mlx5_ib_get_hw_stats() 用于设备 (port_num = 0) 时存在特殊处理以便使用正确的计数器但是 port_num 会在不知情的情况下向下传递堆栈的任何更改。此外某些函数假设 port_num >=1。因此可能会发生以下 oops。BUG无法处理地址的页面错误ffff89510294f1a8 #PF
    内核模式下的主管写入访问 #PFerror_code(0x0002) - not-present page PGD 0 P4D 0 Oops0002 [#1] SMP CPU: 8 PID: 1382 Commdevlink Tainted: GW 6.1.0-rc4_for_upstream_base_2022_11_10_16_12 #1 Hardware nameQEMU Standard PC (Q35 + ICH92009)BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org04/01/2014 RIP0010:_raw_spin_lock+0xc/0x20 调用跟踪 <TASK> mlx5_ib_get_native_port_mdev+ 0x73/0xe0 [mlx5_ib] do_get_hw_stats.constprop.0+0x109/0x160 [mlx5_ib] mlx5_ib_get_hw_stats+0xad/0x180 [mlx5_ib] ib_setup_device_attrs+0xf0/0x290 [ib_core] ib_register_device+0x3bb/0x510] [ib_core] [ib_core] atomic_notifier_chain_register+0x67/0x80 __mlx5_ib_add+0x2b/0x80 [mlx5_ib] mlx5r_probe+0xb8/0x150 [mlx5_ib] ? auxiliary_match_id+0x6a/0x90 auxiliary_bus_probe+0x3c/0x70 driver_sysfs_add+0x6b/0x90 real_probe+0xcd/0x380 __driver_probe_device+0x80/0x170 driver_probe_device+0x1e/0x90
    __device_attach_driver+0x7d/0x100 ? driver_allows_async_probing+0x60/0x60 ? driver_allows_async_probing+0x60/0x60 bus_for_each_drv+0x7b/0xc0 __device_attach+0xbc/0x200 bus_probe_device+0x87/0xa0 device_add+0x404/0x940 ? dev_set_name+0x53/0x70
    __auxiliary_device_add+0x43/0x60 add_adev+0x99/0xe0 [mlx5_core] mlx5_attach_device+0xc8/0x120 [mlx5_core] mlx5_load_one_devl_locked+0xb2/0xe0 [mlx5_core] devlink_reload+0x133/0x250 devlink_nl_cmd_reload+0x570/0x480 devlink_nl_pre_doit+0x44/0x2b0 genl_family_rcv_msg_doit.isra.0+0xc2/0x110 genl_rcv_msg+0x180/0x2b0 devlink_nl_cmd_region_read_dumpit+0x540/0x540 devlink_reload+0x250/0x250 ? devlink_put+0x50/0x50 genl_family_rcv_msg_doit.isra.0+0x110/0x110 netlink_rcv_skb+0x54/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x1f6/0x2c0 netlink_sendmsg+0x237/0x490 sock_sendmsg+0x33/0x40 __sys_sendto+0x103/0x100 handle_mm_fault+0x10e/0x290 ? do_user_addr_fault+0x1c0/0x5f0 __x64_sys_sendto+0x25/0x30 do_syscall_64+0x3d/0x90 entry_SYSCALL_64_after_hwframe+0x46/0xb0 通过将 port_num 设置为 1 以获取设备状态并删除未使用的变量来修复此问题。 (CVE-2023-53393)

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

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

  - ALSAhda修复 9.1 环绕通道名称 get_line_out_pfx() 中的 Oops 可能通过使静态数组溢出超过 8 个通道来触发 Oops。报告称具有 Cirrus 编解码器的 MacBookPro 12,1 存在此问题。解决方法是扩展 9.1 通道并且通过将访问相同数组的代码路径与正确的大小检查统一来修复潜在的 Oops。 (CVE-2023-53400)

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

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

  - driversbasedd使用 debugfs_lookup() 修复内存泄漏调用 debugfs_lookup() 时结果必须调用 dput()否则内存将随着时间泄漏。要使事情更简单只需调用 debugfs_lookup_and_remove()其会同时处理所有逻辑。 (CVE-2023-53390)

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

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

  - 已修复 Linux 内核中的下列漏洞：Bluetooth: Fix potential use-after-free when clear keys Similar to commit c5d2b6fa26b5 (Bluetooth: Fix use-after-free in hci_remove_ltk/hci_remove_irk). We can not access k after kfree_rcu() call. (CVE-2023-53386)

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

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

  - ttyserialfsl_lpuart在 lpuart_dma_shutdown 中禁用 dma rx/tx 使用标记 lpuart_dma_shutdown 会破坏 lpuart dma但仍会发生 lpuart_flush_buffer如果 lpuart_dma_tx_use 标记为真则其转而尝试访问 dma api。此时由于 dma 已破坏这些 dma api 可能中止。在 lpuart_dma_shutdown 中将 lpuart_dma_tx_use 和相应的 rx 标记 lpuart_dma_rx_use 设置为 false以便在释放 dmas 后不会对其进行访问。否则在尝试终止 btattach 时内核可能会发生错误。
    此修补程序可以修复此问题。 root@imx8ulpevk:~# btattach -B /dev/ttyLP2 -S 115200 ^C[ 90.182296] 内部错误同步外部中止96000210 [#1] PREEMPT SMP [ 90.189806] 链接的模块用于
    moal(O) mlan(O) [ 90.194258] CPU: 0 PID: 503 Comm: btattach 受感染GO 5.15.32-06136-g34eecdf2f9e4 #37 [90.203554] 硬件名称NXP i.MX8ULP 9X9 EVK (DT) [ 90.208513] pstate600000c5 (nZCv daIF -PAN -UAO
    -TCO -DIT -SSBS BTYPE=--) [ 90.215470] pc fsl_edma3_disable_request+0x8/0x60 [ 90.220358] lr
    fsl_edma3_terminate_all+0x34/0x20c [ 90.225237] sp : ffff800013f0bac0 [ 90.228548] x29: ffff800013f0bac0 x28: 0000000000000001 x27: ffff000008404800 [ 90.235681] x26: ffff000008404960 x25: ffff000008404a08 x24:
    ffff000008404a00 [ 90.242813] x23: ffff000008404a60 x22: 0000000000000002 x21: 0000000000000000 [90.249946] x20: ffff800013f0baf8 x19: ffff00000559c800 x18: 0000000000000000 [ 90.257078] x17:
    0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 90.264211] x14: 0000000000000003 x13:
    0000000000000000 x120000000000000040 [ 90.271344] x11ffff00000600c248 x10ffff800013f0bb10 x9
    ffff000057bcb090 [ 90.278477] x8 : fffffc0000241a08 x7 : ffff00000534ee00 x6 : ffff000008404804 [90.285609] x5 : 0000000000000000 x4 : 0000000000000000 x3 : ffff0000055b3480 [ 90.292742] x2 :
    ffff8000135c0000 x1 : ffff00000534ee00 x0 : ffff00000559c800 [ 90.299876] Call trace: [ 90.302321] fsl_edma3_disable_request+0x8/0x60 [ 90.306851] lpuart_flush_buffer+0x40/0x160 [ 90.311037] uart_flush_buffer+0x88/0x120 [ 90.315050] tty_driver_flush_buffer+0x20/0x30 [ 90.319496] hci_uart_flush+0x44/0x90 [ 90.323162] +0x34/0x12c [ 90.327253] tty_ldisc_close+0x38/0x70 [ 90.331005] tty_ldisc_release+0xa8/0x190 [ 90.335018] tty_release_struct+0x24/0x8c [ 90.339022] tty_release+ 0x3ec/0x4c0 [ 90.342593] __fput+0x70/0x234 [ 90.345652]____fput+0x14/0x20 [ 90.348790] task_work_run+0x84/0x17c [ 90.352455] do_exit+0x310/0x96c [ 90.355688] do_group_exit+0x3c/0xa0 [90.359259] __arm64_sys_exit_group+0x1c/0x20 [ 90.363609] invoke_syscall+0x48/0x114 [ 90.367362] el0_svc_common.constprop.0+0xd4/0xfc [ 90.372068] do_el0_svc+0x2c/0x94 [ 90.375379] el0_svc+0x28/0x80 [90.378438] el0t_64_sync_handler+0xa8/0x130 [ 90.382711] el0t_64_sync+0x1a0/0x1a4 [ 90.386376] Code
    17ffffda d503201f d503233f f9409802 (b9400041) [ 90.392467] ---[ 结束跟踪 2f60524b4a43f1f6 ]--- [90.397073] 注意btattach[503] 因 preempt_count 1 退出 [ 90.402636] 修复了递归错误但需要重新启动(CVE-2022-50375)

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

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

  - V8 中的类型混淆。由 Google Threat Analysis Group 于 2025 年 9 月 16 日报告。(CVE-2025-10585)

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

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

  - mediamdp3修复 of_find_device_by_node 中的资源泄漏 使用 put_device 通过 of_find_device_by_node 释放对象从而避免资源泄漏。 (CVE-2023-53385)

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

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

  - mmkmem修复 obj_Stock_flush_required() 中的一个空指针取消引用 KCSAN 在 obj_Stock_flush_required() 中发现一个问题 stock->cached_objcg 可在检查和取消引用之间重置
    ================================================== ================ BUGKCSAN由任务 19625 在 cpu 0 上drain_all_Stock /rain_obj_store 写入 0xffff888237c2a2f8 8 字节中的数据争用
    rain_obj_Stock+0x408/0x4e0 mm/memcontrol.c:3306 refill_obj_Stock+0x9c/0x1e0 mm/memcontrol.c:3340 obj_cgroup_uncharge+0xe/0x10 mm/memcontrol.c:3408 memcg_slab_free_hook mm/slab.h:587 [inline] __cache_free mm/ slab.c:3373 [inline] __do_kmem_cache_free mm/slab.c:3577 [inline] kmem_cache_free+0x105/0x280 mm/slab.c:3602 __d_free fs/dcache.c:298 [inline] dentry_free fs/dcache.c:375 [内联]
    __dentry_kill+0x422/0x4a0 fs/dcache.c:621 dentry_kill+0x8d/0x1e0 dput+0x118/0x1f0 fs/dcache.c:913
    __fput+0x3bf/0x570 fs/file_table.c:329____fput+0x15/0x20 fs/file_table.c:349 task_work_run+0x123/0x160 kernel/task_work.c:179 resume_user_mode_work include/linux/resume_user_mode.h:49 [inline] exit_to_user_mode_loop +0xcf/0xe0 kernel/entry/common.c:171 exit_to_user_mode_prepare+0x6a/0xa0 kernel/entry/common.c:203 __syscall_exit_to_user_mode_work kernel/entry/common.c:285 [内联] syscall_exit_to_user_mode+0x26/0x140 kernel/entry/common .c:296 do_syscall_64+0x4d/0xc0 arch/x86/entry/common.c:86 entry_SYSCALL_64_after_hwframe+0x63/0xcd 在 cpu 1:obj_Stock_flush_required mm/memcontrol.c:3319 上被任务 19632 读取到 0xffff888237c2a2f8（共 8 个字节） +0x174/0x2a0 mm/memcontrol.c:2361 try_charge_memcg+0x6d0/0xd10 mm/memcontrol.c:2703 try_charge mm/memcontrol.c:2837 [内联] mem_cgroup_charge_skmem+0x51/0x140 mm/memcontrol.c:7290 sock_reserve_memory+0xb1/ 0x390 net/core/sock.c:1025 sk_setsockopt+0x800/0x1e70 net/core/sock.c:1525 udp_lib_setsockopt+0x99/0x6c0 net/ipv4/udp.c:2692 udp_setsockopt+0x73/0xa0 net/ipv4/udp.c:2817 sock_common_setsockopt+0x61/0x70 net/core/sock.c:3668 __sys_setsockopt+0x1c3/0x230 net/socket.c:2271 __do_sys_setsockopt net/socket.c:2282 [内联] __se_sys_setsockopt net/socket.c:2279 [内联] __x64_sys_setsockopt+0x66/0x80 net/socket.c:2279 do_syscall_x64 arch/x86/entry/common.c:50 [内联] do_syscall_64+0x41/0xc0 arch/x86/entry/ common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd 值已更改0xffff8881382d52c0 -> 0xffff888138893740 已由位于 CPU 上的内核并发审查器报告1 PID19632 Commsyz-executor.0 Nottainted 6.3.0-rc2-syzkaller-03627father-03627a-03627a-03627a-038893893740 #0 硬件名称Google Google Compute Engine/Google Compute Engine, BIOS Google 03/02/2023 通过针对 stock->cached_objcg 的所有访问使用 READ_ONCE()/WRITE_ONCE() 来修复此问题。 (CVE-2023-53401)

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

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

  - 已修复 Linux 内核中的下列漏洞：cifs: prevent use-after-free by freeing the cfile later In smb2_compound_op we have a possible use-after-free which can cause hard to debug problems later on. This was revealed during stress testing with KASAN enabled kernel. Fixing it by moving the cfile free call to a few lines below, after the usage. (CVE-2023-53377)

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

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

  - mm/proc/pid/smaps_rollup修复 no vma 的 null-deref Commit 258f669e7e88mm/proc/pid/smaps_rollup
    转换为单值 seq_file如果 show_smaps_rollup 中的任务中没有 vma则引入 null-deref。 (CVE-2022-50380)

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

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

  - btrfs修复配额启用和配额重新扫描 ioctl 之间的争用。启用配额时在 btrfs_quota_enable() 提交事务后我们将 fs_info->quota_root 更改为指向我们创建的配额根并在 fs_info->flags 设置 BTRFS_FS_QUOTA_ENABLED。然后我们尝试启动 qgroup 重新扫描工作线程首先通过调用 qgroup_rescan_init() 将其初始化 - 但是如果启动失败我们最终会释放 quota root 但使 fs_info->quota_root 仍指向它这可在之后导致其他地方的释放后使用。我们之前已设置标记 BTRFS_FS_QUOTA_ENABLED 和 BTRFS_QGROUP_STATUS_FLAG_ON因此我们只能在 btrfs_quota_enable() 处因 -EINPROGRESS 失败而如果有人已调用配额重新扫描 ioctl并因此启动重新扫描工作线程则可能出现这种情况。因此通过忽略 -EINPROGRESS 和断言我们无法得到任何其他错误来修复此问题。 (CVE-2022-50379)

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

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

  - net/smc尝试使用 SMCRv2 失败时重置连接。我们发现将 SMCRv2 与 2 Mellanox ConnectX-4 配合使用时会发生崩溃。它<port> 可以<ip>通过以下方式重现PFerror_code(0x0000) - not-present 页面 PGD 8000000108713067 P4D 8000000108713067 PUD 151127067 PMD 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 4 PID: 2441 Comm: kworker/4:249 Kdump已加载 Tainted: GWE 6.4.0 -rc1+ #42 Workqueue: smc_hs_wq smc_listen_work [smc] RIP:
    0010smc_clc_send_confirm_accept+0x284/0x580 [smc] RSP0018:ffffb8294b2d7c78 EFLAGS00010a06 RAX
    ffff8f1873238880 RBX: ffffb8294b2d7dc8 RCX: 0000000000000000 RDX: 00000000000000b4 RSI: 0000000000000001 RDI: 0000000000b40c00 RBP: ffffb8294b2d7db8 R08: ffff8f1815c5860c R09: 0000000000000000 R10:
     R110000000000000400  : 0000000000000000 R12: ffff8f1846f56180 R13: ffff8f1815c5860c R14: 0000000000000001 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8f1aefd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000014 CR3: 00000001027a0001 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3:000000 DR3:000000000000000000000
    00000000fffe0ff0 DR7: 0000000000000400 调用跟踪 <TASK> ? mlx5_ib_map_mr_sg+0xa1/0xd0 [mlx5_ib] ? smcr_buf_map_link+0x24b/0x290 [smc] ? __smc_buf_create+0x4ee/0x9b0 [smc] smc_clc_send_accept+0x4c/0xb0 [smc] smc_listen_work+0x346/0x650 [smc] ? __schedule+0x279/0x820 process_one_work+0x1e5/0x3f0 worker_thread+0x4d/0x2f0 ? __pfx_worker_thread+0x10/0x10 kthread+0xe5/0x120 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2c/0x50 </TASK> 在 CLC 握手期间服务器会按顺序尝试 smc_listen_work() 中可用的 SMCRv2 和 SMCRv1 设备。是否找到 SMCRv2 设备。基于 SMCv2 的链接组和链接将分配给该连接。然后假设稍后在 CLC 握手中发生某些缓冲区分配错误例如 MBR 注册失败服务器将放弃 SMCRv2 并尝试使用 SMCRv1 设备。但不会重置分配给该连接的资源。服务器尝试 SMCRv1 设备时将再次执行连接创建过程。由于在尝试 SMCRv2 时已分配 conn->lnk因此不会在 smcr_lgr_conn_assign_link() 中将其设置为正确的 SMCRv1 链接。因此在这种情况下conn->lgr 会正确指向 SMCRv1 链接组但 conn->lnk 会错误地指向 SMCRv2 链接。然后在 smc_clc_send_confirm_accept() 中将会访问 conn->rmb_desc->mr[link->link_idx]。由于 link->link_idx 不正确相关 MR 可能未初始化因此会发生崩溃。 |先试用 SMCRv2 设备 | |-> conn->lgr分配已存在的 SMCRv2 链接组| |-> conn->link分配已存在的 SMCRv2 链接SMC_LGR_SYMMETRIC 中的 link_idx 可能为 1 | |-> sndbuf 和 RM 创建失败退出| |然后试用 SMCRv1 设备 | |-> conn->lgr创建 SMCRv1 链接组并分配| |-> conn->link错误地保留 SMCRv2 链接| |-> sndbuf 和RMB 创建成功仅限RMB->mr[link_idx = 0] |已初始化。 | | |则 smc_clc_send_confirm_accept() 访问conn->rmb_desc->mr[conn->link->link_idx即 1]然后崩溃。
    v 此修补程序尝试通过在分配链接之前清除 conn->lnk 来修复此问题。此外如果在创建或注册缓冲区时尝试 SMCRv2 失败最好重置连接并清理分配的资源。 (CVE-2023-53382)

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

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

  - driversbasecomponent修复内存泄漏使用 debugfs_lookup() 调用 debugfs_lookup() 时结果必须调用 dput() 否则内存将随着时间泄漏。要使事情更简单只需调用 debugfs_lookup_and_remove()其会同时处理所有逻辑。 (CVE-2023-53409)

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

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

  - 已修复 Linux 内核中的下列漏洞：sctp: fix a potential overflow in sctp_ifwdtsn_skip Currently, when traversing ifwdtsn skips with _sctp_walk_ifwdtsn, it only checks the pos against the end of the chunk. However, the data left for the last pos may be < sizeof(struct sctp_ifwdtsn_skip), and dereference it as struct sctp_ifwdtsn_skip may cause coverflow. This patch fixes it by checking the pos against the end of the chunk - sizeof(struct sctp_ifwdtsn_skip) in sctp_ifwdtsn_skip, similar to sctp_fwdtsn_skip. (CVE-2023-53372)

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

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

  - Spring Framework 批注检测机制可能无法正确解析具有无限泛型的参数化超类型的类型层次结构内方法上的批注。如果将此类注释用于授权决策这可能会成为一个问题。如果您使用 Spring Security 的 @EnableMethodSecurity 功能您的应用程序可能会受到此漏洞的影响。如果您未使用 @EnableMethodSecurity或者不在泛型超类或泛型接口的方法上使用安全注释则不受此问题影响。此 CVE 与 CVE-2025-41248 https://spring.io/security/cve-2025-41248 一并发布。 (CVE-2025-41249)

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

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

  - 在 LemonLDAP::NG 2.16.7 之前的版本以及 2.21.3 之前的 2.17 至 2.21 版中，Safe jail 中可发生 OS 命令注入。在规则评估期间，未对 _ 进行本地化处理。因此，能够编辑 Safe jail 评估的规则的管理员能够在服务器上执行命令。(CVE-2025-59518)

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

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

  - 已修复 Linux 内核中的下列漏洞：skbuff: Account for tail adjustment during pull operations Extending the tail can have some unexpected side effects if a program uses a helper like BPF_FUNC_skb_pull_data to read partial content beyond the head skb headlen when all the skbs in the gso frag_list are linear with no head_frag - kernel BUG at net/core/skbuff.c:4219! pc :
    skb_segment+0xcf4/0xd2c lr : skb_segment+0x63c/0xd2c Call trace: skb_segment+0xcf4/0xd2c
    __udp_gso_segment+0xa4/0x544 udp4_ufo_fragment+0x184/0x1c0 inet_gso_segment+0x16c/0x3a4 skb_mac_gso_segment+0xd4/0x1b0 __skb_gso_segment+0xcc/0x12c udp_rcv_segment+0x54/0x16c udp_queue_rcv_skb+0x78/0x144 udp_unicast_rcv_skb+0x8c/0xa4 __udp4_lib_rcv+0x490/0x68c udp_rcv+0x20/0x30 ip_protocol_deliver_rcu+0x1b0/0x33c ip_local_deliver+0xd8/0x1f0 ip_rcv+0x98/0x1a4 deliver_ptype_list_skb+0x98/0x1ec __netif_receive_skb_core+0x978/0xc60 Fix this by marking these skbs as GSO_DODGY so segmentation can handle the tail updates accordingly. (CVE-2022-50365)

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

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

  - block当轮询 Wei 报告应用程序使用轮询 IO 时要更小心地检查 NULL bdev: PGD 14265e067 P4D 14265e067 PUD 47ec50067 PMD 0 Oops: 0000 [#1] SMP CPU: 0 PID: 21915 Comm iocore_0 Kdump已加载被污染的GS 5.12.0-0_fbk12_clang_7346_g1bb6f2e7058f #1 硬件名称Wiwynn delta Lake MP T8/delta Lake-Class2BIOS Y3DLM08 04/10/2022 RIP0010:bio_poll+0x25/0x200代码0f 1f 44 00 00 0f 1f 44 00 00 1f 44 00 00 55 41 57 41 56 41 55 41 54 53 48 83 ec 28 65 48 8b 04 25 28 00 00 00 48 89 44 24 20 48 8b 47 08 <48> 8b 80 70 02 00 5c 6b 8b 80 70 02 00 8f0 34 31 db 83 fd ff 75 25 65 RSP
    0018:ffffc90005fafdf8 EFLAGS: 00010292 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 74b43cd65dd66600 RDX: 0000000000000003 RSI: ffffc90005fafe78 RDI: ffff8884b614e140 RBP: ffff88849964df78 R08:
     R090000000000000000  : 0000000000000008 R10: 0000000000000000 R11: 0000000000000000 R12: ffff88849964df00 R13: ffffc90005fafe78 R14: ffff888137d3c378 R15: 0000000000000001 FS: 00007fd195000640(0000) GS:ffff88903f400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES0000 CR00000000080050033 CR2
    0000000000000270 CR3: 0000000466121001 CR4: 00000000007706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: iocb_bio_iopoll+0x1d/0x30 io_do_iopoll+0xac/0x250 __se_sys_io_uring_enter+0x3c5/0x5a0 ?
    __x64_sys_write+0x89/0xd0 do_syscall_64+0x2d/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP
    0033:0x94f225d 代码24 cc 00 00 00 41 8b 84 24 d0 00 00 00 c1 e0 04 83 e0 10 41 09 c2 8b 33 8b 53 04 4c 8b 43 18 4c 63 4b 0c b8 aa 001 c0f 05 <85> [05] 0f 88 85 00 00 00 29 03 45 84 f6 0f 84 88 00 00 00 41 f6 c7 RSP002b:00007fd194ffcd88 EFLAGS00000202 ORIG_RAX:00000000000001aa RAX:ffdaffXffffff
    00007fd194ffcdc0 RCX: 00000000094f225d RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000007 RBP: 00007fd194ffcdb0 R08: 0000000000000000 R09: 0000000000000008 R10: 0000000000000001 R11:
    0000000000000202 R1200007fd269d68030 R130000000000000000 R140000000000000001 R150000000000000000 原因在于 bio->bi_bdev 为空。如果有两个任务在执行轮询 IO并且共享轮询队列任务 B 最终从任务 A 完成 IO就会发生这种情况。如果任务 B 完成 IO 并将 bio 放入缓存中则它可在任务 A 完成对该 bio 的轮询之前再次分配该 bio。由于这将需要两个任务之间的抢占因此在检查 bio->bi_bdev 是否为空时只要更仔细一些就足够了。 (CVE-2023-53366)

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

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

  -rapidio修复 rio_add_device() 失败时可能的名称泄漏 修补程序系列rapidio修复三个可能的内存泄漏。此修补程序集修复错误处理中的三个名称泄漏。 - 修补程序 #1 修复 rio_add_device() 失败时的两个名称泄漏。 - 修补程序 #2 修复 rio_register_mport() 失败时的名称泄漏。此修补程序共 2 个修补程序如果 rio_add_device() 返回错误则需要释放由 dev_set_name() 分配的名称。应使用 put_device() 放弃错误路径中的引用以便可在 kobject_cleanup() 中释放该名称并可在 rio_release_dev() 中释放“rdev”。 (CVE-2022-50343)

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

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

  - brcmfmac从加密狗获取无效 max_flowrings 时返回错误当固件在初始化时命中陷阱时主机将从加密狗读取异常的 max_flowrings 编号并且在进行 iowrite 以初始化加密狗环时造成内核错误。为了及早检测此错误我们在获取无效的 max_flowrings(>256) 时直接返回错误。 (CVE-2022-50358)

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

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

  - usbdwc3核心修复探测中的一些泄漏 dwc3_get_properties() 函数调用 dwc->usb_psy = power_supply_get_by_name(usb_psy_name);因此需要对这些错误路径进行一些额外的清理。 (CVE-2022-50357)

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

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

  - fbdev/ep93xx-fb不分配到 struct fb_info.dev 不将 Linux 设备分配到 struct fb_info.dev。
    对 register_framebuffer() 的调用会将该字段初始化为 fbdev 设备。驱动程序不应替代其值。修复了驱动程序错误地减少硬件设备的引用计数器并泄漏 fbdev 设备的缺陷。 v2* 添加修复标签 (Dan) (CVE-2023-53314)

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

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

  - nilfs2通过 iput 修复 dirtying inode 中 nilfs_root 的释放后使用错误在 nilfs2 的卸载进程中在 nilfs2 分离其在 nilfs_detach_log_writer() 中的写入器之后没有任何操作保留 nilfs_root 结构。
    以前如果 inode 留在garbage_list 中并在 nilfs_detach_log_writer() 结束时由 nilfs_dispose_list 释放nilfs_evict_inode() 可造成 nilfs_root 释放后使用读取提交 9b5a04ac3ad9 中修复了此缺陷 (nilfs2修复释放后使用nilfs_evict_inode() 中 nilfs_root 的缺陷。
    然而事实证明在从 iput() 调用 mark_inode_dirty_sync() 的调用路径中存在 UAF 的另一种可能性nilfs_detach_log_writer() nilfs_dispose_list() iput() mark_inode_dirty_sync() __mark_inode_dirty() nilfs_dirty_inode() __nilfs_mark_inode_dirty() nilfs_load_inode_block( ) --> 造成 nilfs_root 结构的 UAF 这会在提交 0ae45f63d4ef vfs添加对 lazytime 挂载选项的支持这会将 iput() 更改为如果 i_state 具有 I_DIRTY_TIME 标记且 i_nlink 为非-zero。当使用 syzbot 复制程序时提交 28a65b49eb53 (nilfs2在降级为只读后不写入脏数据) 之后出现此问题但之前可能就存在该问题。可通过以下方法修复此问题
    __nilfs_mark_inode_dirty()。与提交 9b5a04ac3ad9 不同nilfs2修复 nilfs_evict_inode() 中 nilfs_root 的释放后使用缺陷此修补程序不依赖 ns_writer 来确定是否跳过操作以便在挂载时不中断恢复。nilfs_salvage_orphan_logs 例程在附加日志编写器之前会脏抢占数据的缓冲区因此当 ns_writer 为 NULL 时变更 __nilfs_mark_inode_dirty() 以跳过该操作将造成恢复写入失败。使用 cleanup-only 标记的目的是缩小此类条件的范围。 (CVE-2023-53311)

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

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

  - 已修复 Linux 内核中的下列漏洞：rxrpc: Fix potential data race in rxrpc_wait_to_be_connected() Inside the loop in rxrpc_wait_to_be_connected() it checks call->error to see if it should exit the loop without first checking the call state. This is probably safe as if call->error is set, the call is dead anyway, but we should probably wait for the call state to have been set to completion first, lest it cause surprise on the way out. Fix this by only accessing call->error if the call is complete. We don't actually need to access the error inside the loop as we'll do that after. This caused the following report: BUG: KCSAN: data-race in rxrpc_send_data / rxrpc_set_call_completion write to 0xffff888159cf3c50 of 4 bytes by task 25673 on cpu 1: rxrpc_set_call_completion+0x71/0x1c0 net/rxrpc/call_state.c:22 rxrpc_send_data_packet+0xba9/0x1650 net/rxrpc/output.c:479 rxrpc_transmit_one+0x1e/0x130 net/rxrpc/output.c:714 rxrpc_decant_prepared_tx net/rxrpc/call_event.c:326 [inline] rxrpc_transmit_some_data+0x496/0x600 net/rxrpc/call_event.c:350 rxrpc_input_call_event+0x564/0x1220 net/rxrpc/call_event.c:464 rxrpc_io_thread+0x307/0x1d80 net/rxrpc/io_thread.c:461 kthread+0x1ac/0x1e0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308 read to 0xffff888159cf3c50 of 4 bytes by task 25672 on cpu 0:
    rxrpc_send_data+0x29e/0x1950 net/rxrpc/sendmsg.c:296 rxrpc_do_sendmsg+0xb7a/0xc20 net/rxrpc/sendmsg.c:726 rxrpc_sendmsg+0x413/0x520 net/rxrpc/af_rxrpc.c:565 sock_sendmsg_nosec net/socket.c:724 [inline] sock_sendmsg net/socket.c:747 [inline] ____sys_sendmsg+0x375/0x4c0 net/socket.c:2501 ___sys_sendmsg net/socket.c:2555 [inline] __sys_sendmmsg+0x263/0x500 net/socket.c:2641 __do_sys_sendmmsg net/socket.c:2670 [inline] __se_sys_sendmmsg net/socket.c:2667 [inline] __x64_sys_sendmmsg+0x57/0x60 net/socket.c:2667 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd value changed: 0x00000000 -> 0xffffffea (CVE-2023-53345)

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

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

  - drm/amdkfd修复 kfd_process_device_init_vm 错误处理“应仅破坏 ib_mem并让进程清理工作线程释放未完成的 BO”。重置 pdd->qpd 结构中的指针以避免进程破坏工作线程中的空指针访问。BUG: kernel NULL pointer dereference, address: 0000000000000010 Call Trace: amdgpu_amdkfd_gpuvm_unmap_gtt_bo_from_kernel+0x46/0xb0 [amdgpu] kfd_process_device_destroy_cwsr_dgpu+0x40/0x70 [amdgpu] kfd_process_destroy_pdds+0x71/0x190 [amdgpu] kfd_process_wq_release+0x2a2/0x3b0 [amdgpu] process_one_work+0x2a1/0x600 worker_thread+0x39/0x3d0CVE-2022-50354

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

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

  - trace/blktrace使用 debugfs_lookup() 修复内存泄漏调用 debugfs_lookup() 时结果必须调用 dput() 否则内存将随着时间泄漏。要使事情更简单只需调用 debugfs_lookup_and_remove()其会同时处理所有逻辑。 (CVE-2023-53408)

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

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

  - ASoCmediatekmt8183修复 mt8183_mt6358_ts3a227_max98357_dev_probe() 中的 refcount 泄漏 of_parse_phandle() 返回引用计数递增的节点使用完时需要调用 of_node_put()。因此请将其添加至 mt8183_mt6358_ts3a227_max98357_dev_probe() 的错误路径中。 (CVE-2022-50392)

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

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

  - netdcb选择正确的策略来解析 DCB_ATTR_BCN dcbnl_bcn_setcfg 使用错误的策略解析 tb[DCB_ATTR_BCN] 在提交 859ee3c43812 中引入 DCB添加对 DCB BCN 的支持。请参阅以下代码中的注释 static int dcbnl_bcn_setcfg(...) { ... ret = nla_parse_nested_deprecated(..., dcbnl_pfc_up_nest, .. ) // !!! dcbnl_pfc_up_attrs 中属性的 dcbnl_pfc_up_nest // DCB_PFC_UP_ATTR_0 至 DCB_PFC_UP_ATTR_ALL ... for (i = DCB_BCN_ATTR_RP_0; i <= DCB_BCN_ATTR_RP_7;
    i++) { // !!! enum dcbnl_bcn_attrs 中的 DCB_BCN_ATTR_RP_0 至 DCB_BCN_ATTR_RP_7 ... value_byte = nla_get_u8(data[i]); ... } ... for (i = DCB_BCN_ATTR_BCNA_0; i <= DCB_BCN_ATTR_RI; i++) { //!!! enum dcbnl_bcn_attrs 中的 DCB_BCN_ATTR_BCNA_0 更改为 DCB_BCN_ATTR_RI ... value_int = nla_get_u32(data[i]); ... } ... } 即 nla_parse_nested_deprecated 使用 dcbnl_pfc_up_nest 属性来解析 dcbnl_pfc_up_attrs 中定义的 nlattr。但以下访问代码会提取每个 nlattr 作为 dcbnl_bcn_attrs 属性。通过为 dcbnl_bcn_attrs 查找相关联的 nla_policy。可以发现这两个策略的开头部分是相同的。 static const struct nla_policy dcbnl_pfc_up_nest[...] = { [DCB_PFC_UP_ATTR_0] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_1] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_2] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_3] = { .type = NLA_U8}、[DCB_PFC_UP_ATTR_4] = {.type = NLA_U8}、[DCB_PFC_UP_ATTR_5] = {.type = NLA_U8}、[DCB_PFC_UP_ATTR_6] = {.type = NLA_U8}、[DCB_PFC_UP_ATTR_7] = {.type = NLA_U8} [DCB_PFC_UP_ATTR_ALL] = {.type = NLA_FLAG}, } static const struct nla_policy dcbnl_bcn_nest[...] = {[DCB_BCN_ATTR_RP_0] = {.type = NLA_U8}[DCB_BCN_ATTR_RP_1] = {.type = NLA_U8}[DCB_BCN_ATTR_RP_2] = {.type = NLA_U8}[DCB_BCN_ATTR_RP_3] = { .type = NLA_U8}、[DCB_BCN_ATTR_RP_4] = {.type = NLA_U8}、[DCB_BCN_ATTR_RP_5] = {.type = NLA_U8}、[DCB_BCN_ATTR_RP_6] = {.type = NLA_U8}、[DCB_BCN_ATTR_RP_7] = {.type = NLA_U8} [DCB_BCN_ATTR_RP_ALL] = {.type = NLA_FLAG}, // 此处稍有不同 [DCB_BCN_ATTR_BCNA_0] = {.type = NLA_U32}, ... [DCB_BCN_ATTR_ALL] = {.type = NLA_FLAG}, };因此当前的代码是有缺陷的而且此 nla_parse_nested_deprecated 可溢出 dcbnl_pfc_up_nest 并使用邻近的 nla_policy 来解析 DCB_BCN_ATTR_BCNA_0 的属性。因此使用正确的策略 dcbnl_bcn_nest 解析嵌套的 tb[DCB_ATTR_BCN] TLV。 (CVE-2023-53369)

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

ID	名称	严重性
265632	Linux Distros 未修补的漏洞：CVE-2025-10531	medium
265631	Linux Distros 未修补的漏洞：CVE-2023-53310	medium
265630	Linux Distros 未修补的漏洞：CVE-2025-58767	medium
265629	Linux Distros 未修补的漏洞：CVE-2023-53340	high
265628	Linux Distros 未修补的漏洞：CVE-2022-50372	medium
265627	Linux Distros 未修补的漏洞：CVE-2023-53367	medium
265626	Linux Distros 未修补的漏洞：CVE-2022-50373	medium
265625	Linux Distros 未修补的漏洞：CVE-2023-53355	medium
265624	Linux Distros 未修补的漏洞：CVE-2023-53358	high
265623	Linux Distros 未修补的漏洞：CVE-2023-53341	medium
265622	Linux Distros 未修补的漏洞：CVE-2023-53360	medium
265621	Linux Distros 未修补的漏洞：CVE-2023-53359	medium
265620	Linux Distros 未修补的漏洞：CVE-2022-50374	medium
265619	Linux Distros 未修补的漏洞：CVE-2023-53353	medium
265618	Linux Distros 未修补的漏洞：CVE-2023-53347	medium
265617	Linux Distros 未修补的漏洞：CVE-2022-50370	medium
265616	Linux Distros 未修补的漏洞：CVE-2023-53343	medium
265615	Linux Distros 未修补的漏洞：CVE-2023-53357	high
265614	Linux Distros 未修补的漏洞：CVE-2023-53338	high
265613	Linux Distros 未修补的漏洞：CVE-2023-53336	medium
265612	Linux Distros 未修补的漏洞：CVE-2023-53398	high
265611	Linux Distros 未修补的漏洞：CVE-2023-53415	medium
265610	Linux Distros 未修补的漏洞：CVE-2023-53393	medium
265609	Linux Distros 未修补的漏洞：CVE-2023-53400	medium
265608	Linux Distros 未修补的漏洞：CVE-2023-53390	medium
265607	Linux Distros 未修补的漏洞：CVE-2023-53386	high
265606	Linux Distros 未修补的漏洞：CVE-2022-50375	medium
265605	Linux Distros 未修补的漏洞：CVE-2025-10585	high
265604	Linux Distros 未修补的漏洞：CVE-2023-53385	medium
265603	Linux Distros 未修补的漏洞：CVE-2023-53401	medium
265602	Linux Distros 未修补的漏洞：CVE-2023-53377	high
265601	Linux Distros 未修补的漏洞：CVE-2022-50380	medium
265600	Linux Distros 未修补的漏洞：CVE-2022-50379	medium
265599	Linux Distros 未修补的漏洞：CVE-2023-53382	medium
265598	Linux Distros 未修补的漏洞：CVE-2023-53409	medium
265597	Linux Distros 未修补的漏洞：CVE-2023-53372	high
265596	Linux Distros 未修补的漏洞：CVE-2025-41249	high
265595	Linux Distros 未修补的漏洞：CVE-2025-59518	high
265594	Linux Distros 未修补的漏洞：CVE-2022-50365	medium
265593	Linux Distros 未修补的漏洞：CVE-2023-53366	medium
265592	Linux Distros 未修补的漏洞：CVE-2022-50343	medium
265591	Linux Distros 未修补的漏洞：CVE-2022-50358	medium
265590	Linux Distros 未修补的漏洞：CVE-2022-50357	medium
265589	Linux Distros 未修补的漏洞：CVE-2023-53314	medium
265588	Linux Distros 未修补的漏洞：CVE-2023-53311	high
265587	Linux Distros 未修补的漏洞：CVE-2023-53345	medium
265586	Linux Distros 未修补的漏洞：CVE-2022-50354	medium
265585	Linux Distros 未修补的漏洞：CVE-2023-53408	medium
265584	Linux Distros 未修补的漏洞：CVE-2022-50392	medium
265583	Linux Distros 未修补的漏洞：CVE-2023-53369	medium

检测

Nessus 的 Misc. 系列

medium

medium

medium

high

medium

medium

medium

medium

high

medium

medium

medium

medium

medium

medium

medium

medium

high

high

medium

high

medium

medium

medium

medium

high

medium

high

medium

medium

high

medium

medium

medium

medium

high

high

high

medium

medium

medium

medium

medium

medium

high

medium

medium

medium

medium

medium