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

  - wifimt76mt7921修复 AMSDU 中缺少 txs 造成的 skb 泄漏如果帧在 AMSDU 中聚合则 txs 可能会被丢弃。当问题出现时一些 SKB 会保留在驱动程序中造成网络暂时停止。
    即使问题可通过 txs 超时处理来恢复mt7921 仍需要禁用 AMSDU 中的 txs 以避免此问题。 (CVE-2023-54052)

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

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

  - rcu修复 rcu_force_quiescent_state() 中的 __this_cpu_read() lockdep 警告。在通过 CONFIG_PREEMPTION=y 构建的内核中运行具有非零 fqs_duration 模块参数的 rcutorture 时出现以下错误消息
    缺陷在可抢占的 [00000000] 代码中使用 __this_cpu_read()rcu_torture_fqs/398 调用程序是
    __this_cpu_preempt_check+0x13/0x20 CPU: 3 PID: 398 Comm: rcu_torture_fqs未受感染 6.0.0-rc1-yoctodev-standard+ 调用追踪 <TASK> dump_stack_lvl+0x5b/0x86 dump_stack+0x10/0x16 check_preemption_disabled+0xe5/0xf0 __this_cpu_preempt/0x20x20x20x20x20x20x20x20x20x20x20x20x20x20 rcu_force_quiescent_state.part.0+0x1c/0x170 rcu_force_quiescent_state+0x1e/0x30 rcu_torture_fqs+0xca/0x160 rcu_torture_boost+0x430/0x430 kthread+0x192/0x1d0 ? kthread_complete_and_exit+0x30/0x30 ret_from_fork+0x22/0x30 </TASK> 问题在于 rcu_force_quiescent_state() 使用可抢占代码中的 __this_cpu_read() 而非正确的 raw_cpu_read()。因此该提交将 __this_cpu_read() 更改为 raw_cpu_read()。 (CVE-2022-50771)

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

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

  - fs删除命名空间锁定下的对等组 id 清除故障路径中的对等组 id 时需要确保按住命名空间锁定。否则另一个线程可能会同时将共享挂载变成非共享挂载。 (CVE-2023-54128)

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

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

  - powerpc/iommu修复被 PCI 和 VIO 总线共享的通知程序 fail_iommu_setup() 会同时将 fail_iommu_bus_notifier struct 注册到 PCI 和 VIO 总线。 struct notifier_block 是链接列表节点因此这会导致之后注册到其中一个总线类型的任何通知程序也注册到另一个因为它们共享相同的节点。这至少会导致注册 PCI 总线通知器的 vgaarb 代码出现问题。 pci_notify() 最终会在 vio 设备上调用由 to_pci_dev() 转换即使它不是 PCI 设备最后在 vga_arbiter_add_pci_device() 中进行错误访问正如 KASAN 所发现
    缺陷KASAN由任务 swapper/0/1 调用跟踪在 addr c000000264c26fdc 的大小 4 的 vga_arbiter_add_pci_device+0x60/0xe00 读取中发生 slab 越界调用跟踪 dump_stack_lvl+0x1bc/0x2b8不可靠 print_report+0x3f4/0xc60 kasan_report+0x244 /0x698 __asan_load4+0xe8/0x250 vga_arbiter_add_pci_device+0x60/0xe00 pci_notify+0x88/0x444 notifier_call_chain+0x104/0x320 blocking_notifier_call_chain+0xa0/0x140 device_add+0xac8/0x1d30 device_register+0x58/0x80 vio_register_device_node+0x9ac/0xce0 vio_bus_scan_register_devices+0xc4/0x13c
    __machine_initcall_pseries_vio_device_init+0x94/0xf0 do_one_initcall+0x12c/0xaa8 kernel_init_freeable+0xa48/0xba8 kernel_init+0x64/0x400 ret_from_kernel_thread+0x5c/0x64 通过为每种总线类型创建单独的 notifier_block struct 来修复此问题。 [mpe添加 #ifdef 以修复 CONFIG_IBMVIO=n 版本] (CVE-2023-54095)

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

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

  - scsiqedi修复 qedi_remove() 中的释放后使用缺陷在 qedi_probe() 中调用 __qedi_probe()后者通过 qedi_recovery_handler() 初始化 &qedi->recovery_work通过 qedi_board_disable_work() 初始化 &qedi->board_disable_work。调用 qedi_schedule_recovery_handler() 时 schedule_delayed_work() 将最终开始工作。在为删除驱动程序而调用的 qedi_remove() 中可能会发现以下序列在 qedi_remove() 中进行清理之前通过完成工作来修复此问题。qedi_remove | CPU0 CPU1 |qedi_recovery_handler __qedi_remove | | iscsi_host_free | scsi_host_put | //free shhost | |iscsi_host_for_each_session |//使用 qedi->shost 中的取消 Recovery_work 和board_disable_work
    __qedi_remove()。 (CVE-2023-54100)

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

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

  - s390/dcssblk修复 list_add 损坏的内核崩溃提交 fb08a1908cb1dax简化 dax_device <-> gendisk 关联引入 gendisk 关联的新逻辑需要驱动程序显式调用 dax_add_host() 和 dax_remove_host()。对于 dcssblk 驱动程序缺少某些 dax_remove_host() 调用例如在设备删除路径中。此提交还中断了设备添加路径中 out_dax 情况的错误处理从而导致该情况下出现额外的 put_device() 而没有之前的 get_device()。这会导致在设备添加/删除周期之后产生过时的 xarray 条目。在要再次使用先前使用的 struct gendisk 指针xarray 索引的情况下由于 blk_alloc_disk() 刚好返回此指针dax_add_host() 中的 xa_insert() 将失败并转至 out_dax执行额外的 put_device( ) 在错误路径中。结合 dcssblk 中已有缺陷的错误处理device_register() 清理需要在单独的修补程序中解决需要使用单独的修补程序解决此问题导致 device_del() / klist_del() 缺失并最终导致内核崩溃list_add 损坏后续的 device_add() / klist_add()。通过添加缺少的 dax_remove_host() 调用来修复此问题并且移动错误路径中的 put_device() 以还原之前的逻辑。 (CVE-2023-54117)

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

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

  - virtio_pmem为刷新 bio 添加缺失的 REQ_OP_WRITE 在 pmem 设备上执行 mkfs.xfs 时以下警告 ------------[在此剪切 ]---------- -- WARNINGCPU:2 PID: 384 at block/blk-core.c:751 submit_bio_noacct 链接到的模块CPU: 2 PID: 384 Comm: mkfs.xfs 未受感染 6.4.0-rc7+ #154 硬件名称 QEMU Standard PC（i440FX + PIIX，1996）RIP: 0010:submit_bio_noacct+0x340/0x520 ...... 调用跟踪 <TASK> ? submit_bio_noacct+0xd5/0x520 submit_bio+0x37/0x60 async_pmem_flush+0x79/0xa0 nvdimm_flush+0x17/0x40 pmem_submit_bio+0x370/0x390 __submit_bio+0xbc/0x190 submit_bio_noacct_nocheck+0x14d/0x370 submit_bio_noacct+0x1ef/0x520 submit_bio+0x55/0x60 submit_bio_wait+0x5a/0xc0 blkdev_issue_flush+0x44/0x60 根本原因是 submit_bio_noacct() 需要 bio_op() 是 WRITE 或 ZONE_APPEND 才能刷新 bio 并且 async_pmem_flush() 在分配刷新 bio 时未分配 REQ_OP_WRITE因此 submit_bio_noacct 无法刷新 bio。只需通过为刷新 bio 添加缺少的 REQ_OP_WRITE 即可修复此问题。我们可以修复刷新顺序问题并在稍后执行刷新优化。 (CVE-2023-54089)

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

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

  - wifirt2x00修复处理调查时的内存泄漏删除 rt2x00 设备时未释放其相关联的信道调查造成使用 kmemleak 可观察到的内存泄漏未引用的对象 0xffff9620f0881a00大小 512comm systemd-udevd、pid 2290、jiffies 4294906974 (age 33.768s) hex dump前 32 字节70 44 12 00 00 00 00 00 92 8a 00 00 00 00 00 00 pD........00 00 00 00 00 00 00 00 ab 87<ffffffffc1b0f29b>01 00 00<ffffffffb0ed858b>00 00 00 ... [<ffffffffc1a9496e>] rt2800usb_probe_hw+0xe/0x60 [rt2800usb] [<ffffffffc1ae491a>] rt2x00lib_probe_dev+0x21a/0x7d0 [rt2x00lib] [<ffffffffc1b3b83e>] rt2x00usb_probe+0x1be/0x980 [rt2x00usb] [<ffffffffc05981e2>core  ] [/] usb_usb_interface+0x31e2 [<ffffffffb13be2d5>] ] ] real_probe+0x1a5/0x410 [<ffffffffb13be5c8>] __driver_probe_device+0x78/0x180 [<ffffffffb13be6fe>] driver_probe_device+0x1e/0x90 [<ffffffffb13be972>] __driver_attach+0xd2/0x1c0 [<ffffffffb13bbc57>] bus_for_each_dev+0x77/0xd0 [<ffffffffb13bd2a2>] bus_add_driver+0x112 /0x210 [<ffffffffb13bfc6c>] driver_register+0x5c/0x120 [<ffffffffc0596ae8>] usb_register_drive r+0x88/0x150 [usbcore] [<ffffffffb0c011c4>] do_one_initcall+0x44/0x220 [<ffffffffb0d6134c>] do_init_module+0x4c/0x220 通过在删除设备时释放通道调查来修复此问题。已使用基于 RT3070 的 USB 无线适配器进行测试。 (CVE-2023-54131)

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

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

  - s390/lcs修复 lcs_start_xmit() 的返回类型 借助 clang 的内核控制流完整性kCFI、CONFIG_CFI_CLANG系统会针对预期的函数指针原型验证间接调用目标以确保调用目标有效从而帮助缓解 ROP 攻击。如果它们不同，则运行时会出错，表现为内核错误或线程被终止。clang 中提议的警告旨在在编译时捕获这些错误该警告揭示drivers/s390/net/lcs.c:2090:21: error
    不兼容的函数指针类型使用类型“int (struct sk_buff *)”的表达式初始化“netdev_tx_t (*)(struct sk_buff *, struct net_device *)”又称为“enum netdev_tx (*)(struct sk_buff *, struct net_device *)” , struct net_device *)' [-Werror,-Wincompatible-function-pointer-types-strict] .ndo_start_xmit = lcs_start_xmit^~ ~ ~ ~ ~ ~ ~ ~ ~ drivers/s390/net/lcs.c 2097:21错误使用 / 类型的表达式初始化“netdev_tx_t (*)(struct sk_buff *, struct net_device *)”又称为“enum netdev_tx (*)(struct sk_buff *, struct net_device *)”时不兼容的函数指针类型“int (struct sk_buff *, struct net_device *)”[-Werror,-Wincompatible-function-pointer-types-strict] .ndo_start_xmit = lcs_start_xmit^----------------------------------------
    “struct net_device_ops”中的 ->ndo_start_xmit() 预期返回类型为“netdev_tx_t”而非“int”。调整 lcs_start_xmit() 的返回类型以匹配原型的类型从而解决此警告和潜在的 CFI 失败如果 s390 将来选择 ARCH_SUPPORTS_CFI_CLANG。 (CVE-2022-50728)

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

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

  - wifi rtw88使用工作更新速率以避免 RCU 警告 ieee80211_ops::sta_rc_update 必须是原子性的因为 ieee80211_chan_bw_change() 在调用 drv_sta_rc_update() 时会保留 rcu_read 锁定因此创建一个工作来执行原始操作。RCU 读取端关键区段中的主动上下文切换WARNING: CPU: 0 PID: 4621 at kernel/rcu/tree_plugin.h:318 rcu_note_context_switch+0x571/0x5d0 CPU: 0 PID: 4621 Comm
    kworker/u16:2 受感染的GW OE Workqueuephy3 ieee80211_chswitch_work [mac80211] RIP
    0010:rcu_note_context_switch+0x571/0x5d0 调用跟踪 <TASK> __schedule+0xb0/0x1460
    __mod_timer+0x116/0x360 schedule+0x5a/0xc0 schedule_timeout+0x87/0x150 ? trace_raw_output_tick_stop+0x60/0x60 wait_for_completion_timeout+0x7b/0x140 usb_start_wait_urb+0x82/0x160 [usbcore usb_control_msg+0xe3/0x140 [usbcore rtw_usb_read+0x88/0xe0 [rtw_usb rtw_usb_read8+0xf/0x10 [rtw_usb rtw_fw_send_h2c_command+0xa0/0x170 [rtw_core rtw_fw_send_ra_info+0xc9/0xf0 [rtw_core drv_sta_rc_update+0x7c/0x160 [mac80211 ieee80211_chan_bw_change+0xfb/0x110 [mac80211 ieee80211_change_chanctx+0x38/0x130 [mac80211 ieee80211_vif_use_reserved_switch+0x34e/0x900 [mac80211 ieee80211_link_use_reserved_context+0x88/0xe0 [mac80211 ieee80211_chswitch_work+0x95/0x170 [mac80211 process_one_work+0x201/0x410 worker_thread +0x4a/0x3b0 ? process_one_work+0x410/0x410 kthread+0xe1/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 </TASK> (CVE-2023-54071)

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

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

  - usbrndis_host防止 int 溢出的安全 rndis_query 检查。在 rndis_query 函数中作为 uint32 键入的变量 off 和 len 受到传入 RNDIS 响应消息的控制因此其值可能会被操纵。将 off 设置为意外的大值将导致 len 与 8 之和溢出并通过已实现的验证步骤。因此响应指针将指向超出预期缓冲区边界的位置从而允许信息泄漏例如通过 RNDIS_OID_802_3_PERMANENT_ADDRESS OID。 (CVE-2023-54110)

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

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

  - igb在提交 50f303496d92 之后启用 SR-IOV时在所有错误路径中清理在重新初始化后启用 SR-IOV如果在模块已使用max_vfs 参数设置为某个值 != 0。如果测试计算机具有双端口 82580则会发生此挂起[ 232.480687] igb 0000:41:00.1删除 enp65s0f1 上的 PHC [ 233.093257] igb 0000:41 00.1禁用 IOV [ 233.329969] pcieport 0000:40:01.0: AER多个未修正的非致命错误0 [ 233.340302] igb 0000:41:00.0: PCIe 总线错误severity=Uncorrected非 Fata [ 233.352248] igb 0000:41:00.0: 设备 [8086:1516] error status/mask=00100000 [ 233.361088] igb 0000:41:00.0: [20] UnsupReq (First) [ 233.368183] igb 0000:41:00.0: AER TLP 标头40000001 0000040f cdbfc00c [ 233.376846] igb 0000:41:00.1PCIe 总线错误严重程度=未修正非 Fata [ 233.388779] igb 0000:41:00.1 设备 [8086:1516] 错误状态/mask=00100000 [ 233.397629] igb 0000:41:00.1: [20] UnsupReq首先 [ 233.404736] igb 0000:41:00.1: AER: TLP Header40000001 0000040f cdbfc00c c [ 233.538214] pci 0000:41:00.1AER无法恢复无 error_detected 回调[ 233.538401] igb 0000:41:00.0删除 enp65s0f0 上的 PHC [233.546197] pcieport 0000:40:01.0: AER: 设备恢复失败 [ 234.157244] igb 0000:41:00.0: IOV 禁用 [ 371.619705] INFO任务 irq/35-aerdrv:257 阻止超过 122 秒。 [ 371.627489] 未受感染 6.4.0-dirty #2 [ 371.632257] echo 0 > /proc/sys/kernel/hung_task_timeout_secs 禁用此功能。 [371.641000] task:irq/35-aerdrv state:D stack:0 pid:257 ppid:2 f0 [ 371.650330] Call Trace[ 371.653061] <TASK> [ 371.655407] __schedule+0x20e/0x660 [ 371.659313] schedule+0x5a/0xd0 [ 371.662824] schedule_preempt_disabled+0x11/0x20 [ 371.667983] __mutex_lock.constprop.0+0x372/0x6c0 [ 371.673237] ?
    __pfx_aer_root_reset+0x10/0x10 [ 371.678105] report_error_detected+0x25/0x1c0 [ 371.682974] ?
    __pfx_report_normal_detected+0x10/0x10 [ 371.688618] pci_walk_bus+0x72/0x90 [ 371.692519] pcie_do_recovery+0xb2/0x330 [ 371.696899] aer_process_err_devices+0x117/0x170 [ 371.702055] aer_isr+0x1c0/0x1e0 [ 371.705661] ? __set_cpus_allowed_ptr+0x54/0xa0 [ 371.710723] ?
    __pfx_irq_thread_fn+0x10/0x10 [ 371.715496] irq_thread_fn+0x20/0x60 [ 371.719491] irq_thread+0xe6/0x1b0 [371.723291] ? __pfx_irq_thread_dtor+0x10/0x10 [ 371.728255] ? __pfx_irq_thread+0x10/0x10 [ 371.732731] kthread+0xe2/0x110 [ 371.736243] ? __pfx_kthread+0x10/0x10 [ 371.740430] ret_from_fork+0x2c/0x50 [371.744428</TASK> ] 重现程序是一个简单的脚本#!/bin/sh for `seq 1 5` 中的 i; do modprobe -rv igb modprobe -v igb max_vfs=1 sleep 1 modprobe -rv igb did 事实证明此问题只能在 82580四端口和双端口上重现而不能在 82576、i350 和 i210 上重现。进一步的调试显示 igb_enable_sriov() 对 pci_enable_sriov() 的调用失败因为 82580 上的 dev->is_physfn 为 0。在提交 50f303496d92 igb重新初始化后启用 SR-IOV之前igb_enable_sriov() 跳至 err_out cleanup 分支。在此提交后它仅返回错误代码。因此未发生清除且 igb_adapter 结构中不正确的 VF 设置欺骗 igb 驱动程序使其假设已设置 VF但实际上不存在 VF。通过在 pci_enable_sriov() 失败时再次清理来修复此问题。
    (CVE-2023-54070)

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

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

  - vhost-vdpa修复一个 iotlb 内存泄漏在提交 3d5698793897 之前vhost-vdpa引入基于 asid 的 IOTLB我们在处理用户 IOTLB 消息时在释放期间调用了 vhost_vdpa_iotlb_unmap(v, iotlb, 0ULL, 0ULL - 1)以释放分配的所有资源通过 vhost_vdpa_process_iotlb_update()。该提交稍微更改了 IOTLB 的处理我们意外删除了在发布期间调用的一些代码。我们已通过 commit 037d4305569avhost-vdpa在发布期间调用 vhost_vdpa_cleanup但已部分修复此问题如 kmemleak 所示如果应用程序不发送 VHOST_IOTLB_INVALIDATE 或崩溃则仍然存在潜在的内存泄漏未引用的对象 0xffff888007fbaa30大小 16comm blkio -bench, pid 914, jiffies 4294993521(age 885.500s) 十六进制转储前 16 字节40 73 41 07 80 88 ff ff 00 00 00 00 00 00 00 00 @sA ....... .. backtrace[<0000000087736d2a>] kmem_cache_alloc_trace+0x142/0x1c0 [<0000000060740f50>] vhost_vdpa_process_iotlb_msg+0x68c/0x901 [vhost_vdpa] [<0000000083e8e205>] vhost_chr_write_iter+0xc0/0x4a0 [vhost<000000008f2f414a>] [  ] vhost_vdpa_chr_write_iter +0x18<00000000de1cd4a0>] vfs_write+0x216/0x4b0 [<00000000a2850200>] ksys_write+0x71/0xf0 [<00000000de8e720b>] __x64_sys_write+0x19/0x20 [<0000000018b12cbb>] do_syscall_64+0x3f/0x90 [<00000000986ec465>] entry_SYSCALL_64_after_hwframe+0x63/0xcd 让我们修复此调用 vhost_vmap_iotlb_map_(在 vhost_vdpa_remove_as() 中的整个范围。我们将该调用移到 vhost_dev_cleanup() 之前因为我们在 vhost_vdpa_pa_unmap() 中需要有效的 v->vdev.mm。可删除 vhost_iotlb_reset() 调用因为整个范围上的 vhost_vdpa_iotlb_unmap() 会删除所有条目。报告的 kmemleak 日志是通过将“use_va”设置为 true 的 vDPA 设备如 VDUSE观察到的。此修补程序已经过使用这两种类型的设备的测试。 (CVE-2022-50738)

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

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

  - ALSAfirewire-digi00x防止潜在的释放后使用 如果 init_stream() 失败此代码本应返回错误代码但它反而释放了 dg00x->rx_stream 并返回成功。这可能导致释放后使用。 (CVE-2023-54084)

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

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

  - md/raid10修复“conf->bio_split”的内存泄漏在 raid10_run() 的错误路径中需要释放“conf”但是缺少“conf->bio_split”因此将会泄漏内存。由于有 3 个位置需要释放“conf”分解帮助程序来修复此问题。 (CVE-2023-54123)

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

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

  - dmaengine qcom-adm修复 prep_slave_sg 的错误调用约定 pre_slave_sg 的调用约定将在出错时返回 NULL 并向系统提供错误日志。而 Qcom-adm 会在错误发生时提供错误指针。这会间接导致例如仅检查 device_prep_slave_sg 返回的指针是否不为空的 nandc 驱动程序的内核错误。返回错误指针会使 nandc 认为 device_prep_slave_sg 函数已正确完成并使内核稍后在代码中发生错误。尽管 nandc 是造成内核崩溃的原因但有人指出真正的问题是 qcom-adm 没有遵循该函数的调用约定。若要修复此问题请终止返回错误指针并使用错误日志返回 NULL。 (CVE-2022-50721)

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

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

  - soundwire修复枚举完成 soundwire 子系统使用两个完成结构这两个完成结构允许驱动程序等待 soundwire 设备分别由其驱动程序在总线上枚举和初始化。实现信号的代码当前已损坏因为它未向所有当前和未来的等待程序发送信号并且还使用了错误的重新初始化函数如果队列中仍有等待程序可能导致内存损坏。没有专门向未来的等待程序发送信号会中断声卡探测延迟因为编解码器驱动程序在被重新探测时无法判断 soundwire 设备已连接。一些编解码器运行时 PM 实现受到类似的问题的影响因为尽管设备已被枚举但在恢复期间等待枚举也可能超时。
    (CVE-2023-54096)

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

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

  - net/mlx5e将表示器邻居清除移动到配置文件 cleanup_tx 对于 ECMP等成本多路径模式下的 IP 隧道封装当流复制到对等 eswitch 对等机上行链路表示器时也会创建相关邻居信息。在引用的提交中，eswitch devcom 取消配对已移动到上行链路卸载 API，特别是 profile->cleanup_tx。如果在 ECMP 模式下存在卸载的 encap 规则则当一个 eswitch 取消配对例如因为卸载驱动程序并且要删除来自对等 eswitch 的对等规则时会触发释放后使用错误在访问邻居信息时因为该信息已在上行链路的 profile->disable 中清除且位于其 profile->cleanup_tx 之前。
    要修复此问题请将邻居清理移动到配置文件的 cleanup_tx 回调和 mlx5e_cleanup_uplink_rep_tx 之后。出于对称性邻居 init 已移动到 init_tx。 [ 2453.376299] BUGKASAN mlx5e_rep_neigh_entry_release+0x109/0x3a0 中的 slab-use-after-free [mlx5_core] [ 2453.379125] 通过任务 modprobe/2496 在 addr ffff888127af9008 处对大小 4 的读取 [ 2453.381542] CPU: 7 PID: 2496 Comm
    modprobe 受感染GB 6.4.0-rc7+ #15 [ 2453.383386] 硬件名称QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/ 2014 [ 2453.384335] 调用跟踪 [ 2453.384625] <TASK> [ 2453.384891] dump_stack_lvl+0x33/0x50 [ 2453.385285] print_report+0xc2/0x610 [ 2453.385667] ?
    __virt_addr_valid+0xb1/0x130 [ 2453.386091] ? mlx5e_rep_neigh_entry_release+0x109/0x3a0 [mlx5_core] [2453.386757] kasan_report+0xae/0xe0 [ 2453.387123] ? mlx5e_rep_neigh_entry_release+0x109/0x3a0 [mlx5_core] [ 2453.387798] mlx5e_rep_neigh_entry_release+0x109/0x3a0 [mlx5_core] [ 2453.388465] mlx5e_rep_encap_entry_detach+0xa6/0xe0 [mlx5_core] [ 2453.389111] mlx5e_encap_dealloc+0xa7/0x100 [mlx5_core] [ 2453.389706] mlx5e_tc_tun_encap_dests_unset+ 0x61/0xb0 [mlx5_core] [ 2453.390361] mlx5_free_flow_attr_actions+0x11e/0x340 [mlx5_core] [ 2453.391015] ? complete_all+0x43/0xd0 [ 2453.391398] ? free_flow_post_acts+0x38/0x120 [mlx5_core] [ 2453.392004] mlx5e_tc_del_fdb_flow+0x4ae/0x690 [mlx5_core] [ 2453.392618] mlx5e_tc_del_fdb_peers_flow+0x308/0x370 [mlx5_core] [ 2453.393276] mlx5e_tc_clean_fdb_peer_flows+0xf5/0x140 [mlx5_core] [ 2453.393925] mlx5_esw_offloads_unpair+ 0x86/0x540 [mlx5_core] [ 2453.394546]? mlx5_esw_offloads_set_ns_peer.isra.0+0x180/0x180 [mlx5_core] [ 2453.395268] ? down_write+0xaa/0x100 [ 2453.395652] mlx5_esw_offloads_devcom_event+0x203/0x530 [mlx5_core] [ 2453.396317] mlx5_devcom_send_event+0xbb/0x190 [mlx5_core] [ 2453.396917] mlx5_esw_offloads_devcom_cleanup+0xb0/0xd0 [mlx5_core] [ 2453.397582] mlx5e_tc_esw_cleanup+0x42/0x120 [mlx5_core] [ 2453.398182] mlx5e_rep_tc_cleanup+0x15/0x30 [mlx5_core] [ 2453.398768] mlx5e_cleanup_rep_tx+0x6c/0x80 [mlx5_core] [2453.399367] mlx5e_detach_netdev+0xee/0x120 [mlx5_core] [ 2453.399957] mlx5e_netdev_rep_tx+0x6c/0x80 [mlx5_core] [ [] ] mlx5e_netdev_change_profile ] [ 2453.400598] mlx5e_vport_rep_unload+0xe0/0xf0 [mlx5_core] [ 2453.403781] mlx5_eswitch_unregister_vport_reps+0x15e/0x190 [mlx5_core] [ 2453.404479] ? mlx5_eswitch_register_vport_reps+0x200/0x200 [mlx5_core] [ 2453.405170] ? up_write+0x39/0x60 [2453.405529] ? kernfs_remove_by_name_ns+0xb7/0xe0 [ 2453.405985] auxiliary_bus_remove+0x2e/0x40 [2453.406405] device_release_driver_internal+0x243/0x2d0 [ 2453.406900] ? kobject_put+0x42/0x2d0 [2453.407284] bus_remove_device+0x128/0x1d0 [ 2453.407687] device_del+0x240/0x550 [ 2453.408053] ? waiting_for_supplier_show+0xe0/0xe0 [ 2453.408511] ? kobject_put+0xfa/0x2d0 [ 2453.408889] ?
    __kmem_cache_free+0x14d/0x280 [ 2453.409310] mlx5_rescan_drivers_locked.part.0+0xcd/0x2b0 [mlx5_core] [2453.409973] mlx5_unregister_device+0x40/0x50 [mlx5_core] [ 2453.410561] mlx5_uninit_one+0x3d/0x110 [mlx5_core] [ 2453.411111] remove_one +0x89/0x130 [mlx5_core] [ 24 ---truncated--- (CVE-2023-54148)

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

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

  - md/raid1: 当 raid1 数组运行失败时停止 mdx_raid1 线程仅当使用不活动磁盘组装数组时才能运行 raid1 数组失败但 mdx_raid1 线程不会停止即使已释放相关资源。当我们执行关机时它将导致空取消引用。这将导致以下 Oops[287.587787] BUG内核空指针取消引用地址0000000000000070 [ 287.594762] #PF内核模式下的主管读取访问 [ 287.599912] #PFerror_code(0x0000) - not-present 页面 [ 287.605061] PGD 0 P4D 0 [ 287.607612] Oops: 0000 [#1] SMP NOPTI [ 287.611287] CPU: 3 PID: 5265 Comm: md0_raid1 Tainted: GU 5.10.146 #0 [ 287.619029] 硬件名称: xxxxxxx/待填写OEM 报告、BIOS 5.19 06/16/2022 [ 287.626775] RIP: 0010:md_check_recovery+0x57/0x500 [md_mod] [ 287.632357] 代码fe 01 00 00 48 83 bb 10 03 00 00 00 74 08 48 89 . ...... [ 287.651118] RSP: 0018:ffffc90000433d78 EFLAGS: 00010202 [ 287.656347] RAX:
    0000000000000000 RBX: ffff888105986800 RCX: 0000000000000000 [ 287.663491] RDX: ffffc90000433bb0 RSI
    00000000ffffefff RDIffff888105986800 [ 287.670634] RBP: ffffc90000433da0 R080000000000000000 R09
    c0000000ffffefff [ 287.677771] R10: 0000000000000001 R11: ffffc90000433ba8 R12: ffff888105986800 [287.684907] R13: 0000000000000000 R14: fffffffffffffe00 R15: 0ffffb:68510 287.692052[FS ] 0 ffff888105986800
    0000000000000000(0000) GS:ffff888277f80000(0000) knlGS:0000000000000000 [ 287.700149] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 287.705897] CR2: 0000000000000070 CR3: 000000000320a000 CR4:
    0000000000350ee0 [ 287.713033] 调用跟踪 [ 287.715498] raid1d+0x6c/0xbbb [raid1] [ 287.719256] ?
    __schedule+0x1ff/0x760 [ 287.722930] ? schedule+0x3b/0xb0 [ 287.726260] ? schedule_timeout+0x1ed/0x290 [287.730456] ? __switch_to+0x11f/0x400 [ 287.734219] md_thread+0xe9/0x140 [md_mod] [ 287.738328] ? md_thread+0xe9/0x140 [md_mod] [ 287.742601] ? wait_woken+0x80/0x80 [ 287.746097] ? md_register_thread+0xe0/0xe0 [md_mod] [ 287.751064] kthread+0x11a/0x140 [ 287.754300] ? kthread_ark+0x90/0x90 [ 287.757974] ret_from_fork+0x1f/0x30 实际上当 raid1 阵列运行失败时我们需要在 raid1_free() 之前执行 md_unregister_thread()。 (CVE-2022-50715)

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

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

  - iommufd不要将相同的 hwpt 两次添加到 ioas->hwpt_list hwpt 仅在其创建期间添加到 hwpt_list而不会再次添加。这个 hunk 是重做时遗漏的一些遗留问题。在某些情况下添加两次会损坏链接列表。它会影响 HWPT 特定附件在我们可以使用非系统 iommu 驱动程序创建合法的结构设备即我们需要从 iommu 代码中删除总线之前测试套件无法涵盖该附件 (CVE-2023-54043)

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

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

  - mediaanysee修复anysee_master_xfer 中的 null-ptr-deref 在 Anysee_master_xfer 中msg 由用户控制。
    当 msg[i].buf 为空且 msg[i].len 为零时将通过前者对 msg[i].buf 的检查。恶意数据最终到达anysee_master_xfer。如果在未进行健全性检查的情况下访问 msg[i].buf[0]会发生空指针取消引用。我们在 msg[i].len 上添加了检查以防止崩溃。Simple commit: commit 0ed554fd769a (media
    dvb-usbaz6027修复 az6027_i2c_xfer() 中的 null-ptr-deref [hverkuil在 +] 周围添加空格 (CVE-2023-54093)

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

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

  - wifiah9khif_usb修复ath9k_hif_usb_dealloc_tx_urbs() 中的 urb 内存泄漏 Syzkaller 报告 ath9k_hif_usb_dealloc_tx_urbs() 中存在许久的已知 urb 泄漏。泄露原因在于调用了 usb_get_urb() 但在 usb_kill_urb() 内未调用 usb_free_urb()或 usb_put_urb()因为 urb->dev 或 urb->ep 字段尚未初始化而 usb_kill_urb() 立即返回。该修补程序删除了尝试终止 hif_dev->tx.tx_buf 中的 urb 的操作因为 hif_dev->tx.tx_buf 不应包含处于待定状态的 urb待定 urb 存储在 hif_dev->tx.tx_pending 中。已获取 tx.tx_lock因此列表中不应有任何更改。由 Linux Verification Center (linuxtesting.org) 通过 Syzkaller 发现。 (CVE-2022-50740)

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

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

  - scsiqla2xxx修复 NVMe LS 请求上的 DMA-API 调用跟踪。在调试内核中发现以下消息和调用跟踪DMA-APIqla2xxx0000:41:00.0设备驱动程序无法检查映射错误 [设备 address=0x00000002a3ff38d8] [size=1024 字节] [映射为单个] 警告CPU: 0 PID: 2930 at kernel/dma/debug.c:1017 check_unmap+0xf42/0x1990 调用跟踪debug_dma_unmap_page+0xc9/0x100 qla_nvme_ls_unmap+0x141/0x210 [qla2xxx]从驱动程序中完全删除 DMA 映射因为它已由 FC 层完成。这可防止出现该警告。 (CVE-2023-54108)

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

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

  - nvmet-tcp在传输标签上添加边界检查将 ttag 用作获取 nvmet_tcp_handle_h2c_data_pdu() 中 cmd 的索引添加边界检查以避免越界访问。 (CVE-2022-50717)

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

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

  - smb客户端修复缺少的 ses 引用计数使用新的 cifs_smb_ses_inc_refcount() 辅助函数以获取 @ses 和 @ses->dfs_root_ses如果设置的活动引用。这会阻止 @ses->dfs_root_ses 被放入对 cifs_put_smb_ses() 的下一次调用中从而可能造成释放后使用缺陷。 (CVE-2023-54076)

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

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

  - mmcmxcmmc修复 mmc_add_host() 的返回值检查如果忽略其返回值mmc_add_host() 可能返回错误则在 mmc_alloc_host() 中分配的内存将泄漏并因未添加的删除而导致内核崩溃删除路径中的设备。因此请通过检查返回值并转到将调用 mmc_free_host() 的错误路径来修复此问题。 (CVE-2022-50769)

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

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

  - regulatorcore修复regulator_register() 中的资源泄漏 我在执行错误注入测试时收到了一些资源泄漏报告OF: 错误内存泄漏预期 refcount 为 1 而不是 100of_node_get()/of_node_put() 不平衡 - 破坏 cset 条目附加叠加节点 /i2c/pmic@64/regulators/buck1 未引用对象 0xffff88810deea000 (size 512)comm 490-i2c-rt5190a, pid 253, jiffies 4294859840 (age 5061.046s) hex 转储前 32 字节00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 ......N....... ff ff ff ff ff ff ff ff a0 1e 00 a1 ff ff ff ff ...... ......回溯
    [<00000000d78541e2>] kmalloc_trace+0x21/0x110 [<00000000b343d153>] device_private_init+0x32/0xd0 [<00000000be1f0c70>] device_add+0xb2d/0x1030 [<00000000e3e6344d>] regulator_register+0xaf2/0x12a0 [<00000000e2f5e754>] devm_regulator_register+0x57/0xb0 [<000000008b898197>] rt5190a_probe +0x52a/0x861 [rt5190a_regulator] 未引用的对象 0xffff88810b617b80（大小 32）comm 490-i2c-rt5190a, pid 253, jiffies 4294859904 (age 5060.983s) 十六进制转储（前 32 字节）：72 65 67 6175 6c 32 38 36 38 2d 53 regulator.2868-S 55 50 50 4c 59 00 ff ff 29 00 00 00 2b 00 00 00 UPPLY...+... 回溯
    [<000000009da9280d>] __kmalloc_node_track_caller+0x44/0x1b0 [<0000000025c6a4e5>] kstrdup+0x3a/0x70 [<00000000790efb69>] create_regulator+0xc0/0x4e0 [<0000000005ed203a>] regulator_resolve_supply+0x2d4/0x440 [<0000000045796214>] regulator_register+0x10b3/0x12a0 [<00000000e2f5e754>] devm_regulator_register +0x57/0xb0 [<000000008b898197>] rt5190a_probe+0x52a/0x861 [rt5190a_regulator] 调用 regulator_resolve_supply() 后通过 set_supply() 设置“rdev->supply”在此设置后错误路径中需要释放资源因此请调用调节器_put() 以避免泄漏。 (CVE-2022-50724)

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

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

  - scsilpfc防止 lpfc_debugfs_lockstat_write() 缓冲区溢出 静态代码分析工具标记了在 debugfs 条目使用 copy_from_user() 时存在缓冲区溢出的可能性。当前copy_from_user() 复制的字节可能比 mybuf char 数组适合的字节多。在 sizeof(mybuf) - 1 与从用户空间缓冲区传递的 nbytes 之间添加 min() 限制检查以防止缓冲区溢出。 (CVE-2023-54102)

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

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

  - ixgbe修复使用 > 64 个 CPU 的 XDP_TX 期间的错误 Commit 4fe815850bdcixgbe使 xdpdrv 支持超过 64 个 CPU 添加了支持通过锁定 XDP TX 环并为其编制索引允许 XDP 程序在包含超过 64 个 CPU 的系统上运行使用 cpu % 64 (IXGBE_MAX_XDP_QS)。在拥有超过 64 个核心的系统上试用此修补程序后内核发生错误并在 ixgbe.h 的 ixgbe_determine_xdp_ring 中返回 array-index-out-of-bounds 时这意味着 ixgbe_determine_xdp_q_idx 仅返回 cpu 而不是 cpu % IXGBE_MAX_XDP_QS。一个 splat 示例
    ================================================== ======================== UBSAN array-index-out-of-bounds /var/lib/dkms/ixgbe/5.18.6+focal-1/build/src/ixgbe .h:1147:26 索引 65 超出“ixgbe_ring *[64]”类型的范围 ============================= ============================================= 缺陷内核空指针取消引用地址0000000000000058 #PF内核模式下的主管读取访问 #PF
    error_code(0x0000) - not-present page PGD 0 P4D 0 Oops0000 [#1] SMP NOPTI CPU65 PID408 Comm
    ksoftirqd/65 受感染：G IOE 5.15.0-48-generic #54~20.04.1-Ubuntu 硬件名称：Dell Inc. PowerEdge R640/0W23H8、BIOS 2.5.4 01/13/2020 RIP0010:ixgbe_xmit_xdp_ring+0x1b/ 0x1c0 [ixgbe] 代码3b 52 d4 cf e9 42 f2 ff ff 66 0f 1f 44 00 00 0f 1f 44 00 00 55 b9 00 00 00 00 48 89 e5 41 57 41 56 41 55 41 54 53 48 08 ec <44> 08 0f b7 47 58 0f b7 47 5a 0f b7 57 54 44 0f b7 76 08 66 41 39 c0 RSP: 0018:ffffbc3fcd88fcb0 EFLAGS: 00010282 RAX: ffff92a253260980 RBX: ffffbc3fe68b00a0 RCX: 0000000000000000 RDX: ffff928b5f659000 RSI: ffff928b5f659000 RDI: 0000000000000000 RBP: ffffbc3fcd88fce0 R08ffff92b9dfc20580 R09
     R100000000000000001  : 3d3d3d3d3d3d3d3d R11: 3d3d3d3d3d3d3d3d R12: 0000000000000000 R13: ffff928b2f0fa8c0 R14: ffff928b9be20050 R15: 000000000000003c FS: 0000000000000000(0000) GS:ffff92b9dfc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0 0000000080050033 CR2: 0000000000000058 CR3:
    000000011dd6a002 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ixgbe_poll+0x103e/0x1280 [ixgbe] ? sched_clock_cpu+0x12/0xe0 __napi_poll+0x30/0x160 net_rx_action+0x11c/0x270 __do_softirq+0xda/0x2ee run_ksoftirqd+0x2f/0x50 smpboot_thread_fn+0xb7/0x150 ? sort_range+0x30/0x30 kthread+0x127/0x150 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x1f/0x30 </TASK> 我想事情会是这样在具有超过 64 个 CPU 的系统上加载第一个 XDP 程序时ixgbe_xdp_locking_key 在 ixgbe_xdp_setup 中递增。然而在此之后ixgbe_setup_tc 会立即重新配置环。 ixgbe_setup_tc 会调用 ixgbe_clear_interrupt_scheme后者调用 ixgbe_free_q_vectors后者在循环中调用 ixgbe_free_q_vector。若非零则每次调用 ixgbe_free_q_vector 都会减少 ixgbe_xdp_locking_key 的值。注释掉 ixgbe_free_q_vector 中的减少量使系统不再发生错误。我怀疑要使原始修补程序有效我需要加载 XDP 程序然后将其替换以便使 ixgbe_xdp_locking_key 返回到 0 以上因为当在 XDP 和非 XDP 环配置之间转换时仅调用 ixgbe_setup_tc而 ixgbe_xdp_locking_key 会在调用 ixgbe_xdp_setup 时。此外可通过 ethtool 调用 ixgbe_setup_tc --set-channels因此这成为在拥有超过 64 个 CPU 的系统上将 ixgbe_xdp_locking_key 递减为 0 的又一条路径。由于 ixgbe_xdp_locking_key 仅保护 XDP_TX 路径且受限于存在的 CPU 数量因此没有理由在卸载 XDP 程序时将其禁用。为避免混淆我已将启用 ixgbe_xdp_locking_key 移到了探测路径中的 ixgbe_sw_init 中。 (CVE-2023-54090)

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

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

  - ext4修复配额 inode 错误在 __es_tree_search 中造成的 bug_on 我们遇到的问题为流
    ================================================== ================ fs/ext4/extents_status.c:202! 的内核缺陷无效的 opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 810 Comm: mount Not tainted 6.1.0-rc1-next-g9631525255e3 #352 RIP: 0010:__es_tree_search.isra.0+0xb8/0xe0 RSP:
    0018:ffffc90001227900 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 0000000077512a0f RCX: 0000000000000000 RDX: 0000000000000002 RSI: 0000000000002a10 RDI: ffff8881004cd0c8 RBP: ffff888177512ac8 R08:
     R0947ffffffffffffff  : 0000000000000001 R10: 0000000000000001 R11: 00000000000679af R12: 0000000000002a10 R13: ffff888177512d88 R14: 0000000077512a10 R15: 0000000000000000 FS:
    00007f4bd76dbc40(0000)GS:ffff88842fd00000(0000)knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0:
    0000000080050033 CR2: 00005653bf993cf8 CR3: 000000017bfdf000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
    0000000000000400 Call Trace: <TASK> ext4_es_cache_extent+0xe2/0x210 ext4_cache_extents+0xd2/0x110 ext4_find_extent+0x5d5/0x8c0 ext4_ext_map_blocks+0x9c/0x1d30 ext4_map_blocks+0x431/0xa50 ext4_getblk+0x82/0x340 ext4_bread+0x14/0x110 ext4_quota_read+0xf0/0x180 v2_read_header+0x24/ 0x90 v2_check_quota_file+0x2f/0xa0 dquot_load_quota_sb+0x26c/0x760 dquot_load_quota_inode+0xa5/0x190 ext4_enable_quotas+0x14c/0x300 __ext4_fill_super+0x31cc/0x32c0 ext4_fill_super+0x115/0x2d0 get_tree_bdev+0x1d2/0x360 ext4_get_tree+0x19/0x30 vfs_get_tree+0x26/0xe0 path_mount+0x81d/ 0xfc0 do_mount+0x8d/0xc0 __x64_sys_mount+0xc0/0x160 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> =========================== ======================================= 上述问题可能发生的原因如下：
    ------------------------------------- ext4_fill_super ext4_orphan_cleanup ext4_enable_quotas ext4_quota_enable ext4_iget --> 获取错误 inode <5> ext4_ext_check_inode --> Wrong imode makes it escape inspection make_bad_inode(inode) --> EXT4_BOOT_LOADER_INO set imode dquot_load_quota_inode vfs_setup_quota_inode --> check pass dquot_load_quota_sb v2_check_quota_file v2_read_header ext4_quota_read ext4_bread ext4_getblk ext4_map_blocks ext4_ext_map_blocks ext4_find_extent ext4_cache_extents ext4_es_cache_extent __es_tree_search.isra.0 ext4_es_end --> Wrong extents trigger BUG_ON 在上述问题中s_usr_quota_inum 设置为 5但 inode<5> 包含错误的 imode 和无序的范围。由于版本 5 为 EXT4_BOOT_LOADER_INO因此可绕过 ext4_iget 函数中的 ext4_ext_check_inode 检查最后未检查的盘区会在 中触发 BUG_ON。
    __es_tree_search 函数。要解决此问题请检查 inode 是否为 vfs_setup_quota_inode() 中的 bad_inode。 (CVE-2022-50782)

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

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

  - canisotp检查 isotp_bind() 中的 CAN 地址系列 添加缺少的检查以阻断非 AF_CAN 绑定。Syzbot 创建了一些与正确 sockaddr 结构大小匹配的代码但在地址系列字段中使用 AF_XDP (0x2C) 而不是 AF_CAN (0x1D)bind$xdp(r2, &(0x7f0000000540)={0x2c, 0x0, r4, 0x0, r2 }、0x10) ^^^^ 这对功能没有影响但应通知用户空间错误的地址系列字段内容。 (CVE-2023-54105)

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

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

  - net修复 ops_init() 失败时 nfqnl_nf_hook_drop() 中的 UAF 问题调用 ops_init() 接口来初始化网络但 ops->init() 失败时会释放数据。但是net->gen 中的 ptr 指针无效。这种情况下调用 nfqnl_nf_hook_drop() 释放网络时，发生无效地址访问的问题。进程如下setup_net() ops_init() data = kzalloc(...) ---> alloc data net_assign_generic() --->assign date to ptr in net->gen ... ops->init( ) ---> 失败 ... kfree(data);
    ---> net->gen 中的 ptr 无效 ... ops_exit_list() ... nfqnl_nf_hook_drop() *q = nfnl_queue_pernet(net)
    ---> q 无效以下是调用跟踪信息BUGKASAN由任务 ip/15855 调用跟踪在 addr ffff88810396b240 处地址 ffff88810396b240 大小 8 的 nfqnl_nf_hook_drop+0x264/0x280 中发生释放后使用释放后使用 <TASK> dump_stack_lvl+0x8e /0xd1 print_report+0x155/0x454 kasan_report+0xba/0x1f0 nfqnl_nf_hook_drop+0x264/0x280 nf_queue_nf_hook_drop+0x8b/0x1b0 __nf_unregister_net_hook+0x1ae/0x5a0 nf_unregister_net_hooks+0xde/0x130 ops_exit_list+0xb0/0x170 setup_net+0x7ac/0xbd0 copy_net_ns+0x2e6/0x6b0 create_new_namespaces+0x382 /0xa50 unshare_nsproxy_namespaces+0xa6/0x1c0 ksys_unshare+0x3a4/0x7e0 __x64_sys_unshare+0x2d/0x40 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 </TASK> 由任务 15855 分配
    kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 __kasan_kmalloc+0xa1/0xb0 __kmalloc+0x49/0xb0 ops_init+0xe7/0x410 setup_net+0x5aa/0xbd0 copy_net_ns+0x2e6/0x6b0 create_new_namespaces+0x382/0xa50 unshare_nsproxy_namespaces+0xa6/0x1c0 ksys_unshare+0x3a4/0x7e0 __x64_sys_unshare+0x2d/0x40 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 由任务 15855 释放
    kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 kasan_save_free_info+0x2a/0x40
    ____kasan_slab_free+0x155/0x1b0 slab_free_freelist_hook+0x11b/0x220 __kmem_cache_free+0xa4/0x360 ops_init+0xb9/0x410 setup_net+0x5aa/0xbd0 copy_net_ns+0x2e6/0x6b0 create_new_namespaces+0x382/0xa50 unshare_nsproxy_namespaces+0xa6/0x1c0 ksys_unshare+0x3a4/0x7e0 __x64_sys_unshare+0x2d/0x40 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 (CVE-2022-50780)

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

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

  - KVMs390pv修复替换的 ASCE 的索引值与客户机 ASCE 对应的结构页面的索引字段应为 0。替换 s390_replace_asce() 中的 ASCE 时新 ASCE 的索引也应设置为 0 。错误的索引可能导致通知 pte 无效时传递错误的地址。如果前缀未映射且通知程序以错误地址调用最终则可能导致有效性拦截VM 崩溃。 (CVE-2023-54092)

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

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

  - maple_tree修复 mas_wr_end_piv() 中潜在的越界访问。检查写入偏移结束边界然后将其用作数据透视数组的偏移。这可在写入延伸至节点中的最后一个插槽时避免对数据透视表数组可能进行的越界访问在这种情况下应将节点最大值用作结束数据透视表。 akpm这不会影响任何当前调用程序但如果向后移植到较早的内核中mapletree 的新用户可能会遇到此问题所以我们在 - 稳定内核版本中修复此问题以防发生。 (CVE-2023-54135)

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

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

  - cryptoqat - 修复 DMA 传输方向 如果选择了 CONFIG_DMA_API_DEBUG则在 QAT 加密算法上运行加密自测试时函数 add_dma_entry() 会报告与以下内容类似的警告称不支持重叠映射。在输入和输出分散列表指向相同缓冲区即指向相同内存区块的两个不同分散列表的测试中会发生这种情况。实现映射的逻辑将标记 DMA_BIDIRECTIONAL 用于输入和输出分散列表这导致重叠写入映射。DMA 层不支持这些更改。修复方法是在映射缓冲区时指定正确的 DMA 传输方向。对于输入分散列表与输出分散列表匹配的操作会使用 DMA_BIDIRECTIONAL 映射缓冲区一次否则使用标记 DMA_TO_DEVICE 映射输入缓冲区并使用 DMA_FROM_DEVICE 映射输出缓冲区。用写入映射重叠读取映射是 dma-coherent 设备如 QAT 中的一个有效情况。已根据对映射函数的变更对释放和取消映射缓冲区的函数 qat_alg_free_bufl() 进行相应的更改。DMA-API: 4xxx 0000:06:00.0 缓存行跟踪 EEXIST不支持重叠映射警告: CPU: 53 PID: 4362 at kernel/dma/debug.c:570 add_dma_entry+0x1e9/0x270 ... 调用跟踪dma_map_page_attrs+0x82/0x2d0 ? preempt_count_add+0x6a/0x6a/0xa0 qat_alg_sgl_to_bufl+0x45b/0x990 [intel_qat] qat_alg_aead_dec+0x71/0x250 [intel_qat] crypto_aad_decrypt+0x3d/0x70 test_aead_vec_cfg+0x649/0x810 ? number+0x310/0x3a0 ? vsnprintf+0x2a3/0x550 scnprintf+0x42/0x70 ? valid_sg_divisions.constprop.0+0x86/0xa0 ? test_aead_vec+0xdf/0x120 test_aead_vec+0xdf/0x120 alg_test_aead+0x185/0x400 alg_test+0x3d8/0x500 crypto_acomp_scomp_free_ctx+0x30/0x30 ? __schedule+0x32a/0x12a0 ? ttwu_queue_wakelist+0xbf/0x110
    _raw_spin_unlock_irqrestore+0x23/0x40 ? try_to_wake_up+0x83/0x570 ? _raw_spin_unlock_irqrestore+0x23/0x40 ? __set_cpus_allowed_ptr_locked+0xea/0x1b0 ? crypto_acomp_scomp_free_ctx+0x30/0x30 cryptomgr_test+0x27/0x50 kthread+0xe6/0x110 kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30CVE-2022-50774

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

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

  - btrfs修复平衡与取消/暂停之间的争用 Syzbot 报告了看起来像这样的错误断言失败: fs_info->exclusive_operation == BTRFS_EXCLOP_BALANCE_PAUSED位于 fs/btrfs/ioctl.c:465 --------- ---[在此剪切]------------ fs/btrfs/messages.c:259! 的内核缺陷RIP0010:btrfs_assertfail+0x2c/0x30 fs/btrfs/messages.c:259 调用跟踪 <TASK> btrfs_exclop_balance fs/btrfs/ioctl.c:465 [inline] btrfs_ioctl_balance fs/btrfs/ioctl.c:3564 [inline] btrfs_ioctl +0x531e/0x5b30 fs/btrfs/ioctl.c:4632 vfs_ioctl fs/ioctl.c:51 [内联] __do_sys_ioctl fs/ioctl.c:870 [内联] __se_sys_ioctl fs/ioctl.c:856 [内联] __x64_sys_ioctl+0x197/ 0x210 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd 重现程序正在运行平衡以及并行的取消或暂停。平衡完成的方式有点奇怪如果我们暂停了我们需要在 fs_info 中保存 balance_ctl否则清除并清理。但是，我们依赖返回值是特定错误、具有取消请求或无暂停请求。如果资产平衡完成并返回 0但有暂停或取消请求我们不会执行适当的清理并且下次尝试启动资产时我们会触发此 ASSERT。此处的错误处理只是错误的我们始终要清理除非收到 -ECANCELLED 并且我们在独占 op 中设置了适当的暂停标记。安装此修补程序后重现器可以运行一个小时而不会跳变而以前它会在不到几分钟的情况下跳变。 (CVE-2023-54023)

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

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

  - udf避免 udf_rename() 中出现双重 brelse() syzbot 报告了如下所示的警告 [1]VFS brelse尝试释放自由缓冲区 WARNING: CPU: 2 PID: 7301 at fs/buffer.c:1145 __brelse+0x67 /0xa0 ... 调用跟踪：
    <TASK> invalidate_bh_lru+0x99/0x150 smp_call_function_many_cond+0xe2a/0x10c0 ? generic_remap_file_range_prep+0x50/0x50 ? __brelse+0xa0/0xa0 ? __mutex_lock+0x21c/0x12d0 ? smp_call_on_cpu+0x250/0x250 ? rcu_read_lock_sched_held+0xb/0x60 lock_release+0x587/0x810 ?
    __brelse+0xa0/0xa0 ? generic_remap_file_range_prep+0x50/0x50 on_each_cpu_cond_mask+0x3c/0x80 blkdev_flush_mapping+0x13a/0x2f0 blkdev_put_whole+0xd3/0xf0 blkdev_put+0x222/0x760 deactivate_locked_super+0x96/0x160 deactivate_super+0xda/0x100 cleanup_mnt+0x222/0x3d0 task_work_run+0x149/0x240 ? task_work_cancel+0x30/0x30 do_exit+0xb29/0x2a40 ? reacquire_held_locks+0x4a0/0x4a0 do_raw_spin_lock+0x12a/0x2b0 ? mm_update_next_owner+0x7c0/0x7c0 ? rwlock_bug.part.0+0x90/0x90 zap_other_threads+0x234/0x2d0 do_group_exit+0xd0/0x2a0
    __x64_sys_exit_group+0x3a/0x50 do_syscall_64+0x34/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcd 问题的原因是 udf_find_entry() 返回空时对 ofibh.sbh 和 ofibh.ebh 同时调用了 brelse()。不过brelse() 也会由 udf_rename() 调用。因此buffer_head 上的 b_count 变得不平衡。此修补程序通过在 udf_find_entry() 返回 NULL 时不通过 udf_rename() 调用 brelse() 来修复 问题。 (CVE-2022-50755)

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

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

  - sched/psi将 kernfs 轮询函数用于 PSI 触发轮询当从轮询进程下删除 cgroup 时破坏 cgroup_file_release 中的 psi 触发会造成 UAF 问题。发生这种情况的原因是删除 cgroup 会导致在实际文件仍然存在时对 cgroup_file_release 进行调用。在此时破坏触发器也会破坏其 waitqueue 头如果该文件上仍有轮询进程访问 waitqueue则它将占用已释放的指针 do_select vfs_poll do_rmdir cgroup_rmdir kernfs_drain_open_files cgroup_file_release cgroup_pressure_release psi_trigger_destroy wake_up_pollfree(&t->event_wait) // vfs_poll 不会阻断 syncnize_rcu kfree(t) poll_freewait -> UAF 对触发器的 waitqueue 头的访问 修补程序 [1] 已修复使用 wake_up_pollfree() 的 epoll() 情况中的此问题但是同步 poll() 情况中存在相同的问题。此问题的根本原因是 psi 触发器的 waitqueue 的生命周期不同以及与该触发器关联的文件的 waitqueue 的生命周期不同。可通过在轮询特定于 cgroup 的 psi 触发器时使用 kernfs_generic_poll 函数修复此问题。它在内部使用其生命周期与文件的生命周期相关的 kernfs_open_node->poll waitqueue 头。这也会使 [1] 中的补丁过时因此将其恢复。 [1] commit c2dbe32d5db5 (sched/psi
    修复 ep_remove_wait_queue() 中的释放后使用 (CVE-2023-54019)

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

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

  - octeontx2-af添加 lmac 类型的验证物理链路变更时固件会向内核报告变更情况以及速度、lmac_type_id 等详细信息。内核根据从固件接收的 lmac_type_id 派生 lmac_type。在少数情况下固件会返回无效的 lmac_type_id从而导致下述内核错误。此修补程序添加了缺少的 lmac_type_id 字段验证。
    内部错误Oops: 96000005 [#1] PREEMPT SMP [ 35.321595] 中链接的模块[ 35.328982] CPU0 PID
    31 Commkworker/0:1 Not tainted 5.4.210-g2e3169d8e1bc-dirty #17 [ 35.337014] Hardware name: Marvell CN103XX 板 (DT) [ 35.344297] Workqueue事件 work_for_cpu_fn [ 35.352730] pstate: 40400089 (nZcv daIf + PAN -UAO) [ 35.360267] pcstrncpy+0x10/0x30 [ 35.366595] lrcgx_link_change_handler+0x90/0x180 (CVE-2023-54129)

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

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

  - drm/i915/gvt修复 gvt debugfs 破坏 当 gvt 调试 fs 破坏时需要进行合理的检查 drm minor 的 debugfs 根是否仍然可用否则在类似通过解绑定删除设备的情况下drm minor 的 debugfs 目录已存在已删除时intel_gvt_debugfs_clean() 会像下面一样作用于悬摆指针并发生 oops。 i915 0000:00:02.0i915/gvt/vid_0x8086_did_0x1926_rid_0x0a.golden_hw_state 的直接固件加载失败并发生错误 -2 i915 0000:00:02.0MDEV
    已注册 Console切换到颜色虚拟设备 80x25 i915 0000:00:02.0: MDEV正在取消注册 BUG
    kernel 空指针取消引用, address00000000000000a0 PGD 0 P4D 0 Oops: 0002 [#1] PREEMPT SMP PTI CPU: 2 PID: 2486 Comm: gfx-unbind.sh Tainted: GI 6.1.0-rc8+ #15 Hardware name: Dell Inc . XPS 13 9350/0JXC1H、BIOS 1.13.0 02/10/2020 RIP0010:down_write+0x1f/0x90 代码1d ff ff 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 53 48 89 fb e8 62 c0 ff ff bf 01 00 00 00 e8 28 5e 31 ff 31 c0 ba 01 00 00 00 <f0> 48 0f b1 13 75 33 65 48 8b 04 25 c0 bd 01 00 48 89 43 08 bf 01 RSP: 0018:ff01ffcc8 EFGSLAX:其他
    0000000000000000 RBX: 00000000000000a0 RCX: ffffff8100000000 RDX: 0000000000000001 RSI: 0000000000000064 RDI: ffffffffa48787a8 RBP: ffff9eb3036ffd30 R08: ffffeb1fc45a0608 R09: ffffeb1fc45a05c0 R10:
     R110000000000000002  : 0000000000000000 R12: 0000000000000000 R13: ffff91acc33fa328 R14: ffff91acc033f080 R15: ffff91acced533e0 FS: 00007f6947bba740(0000) GS:ffff91ae36d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000000a0 CR3: 00000001133a2002 CR4: 00000000003706e0 调用跟踪 <TASK> simple_recursive_removal+0x9f/0x2a0 ? start_creating.part.0+0x120/0x120
    _raw_spin_lock+0x13/0x40 debugfs_remove+0x40/0x60 intel_gvt_debugfs_clean+0x15/0x30 [kvmgt] intel_gvt_clean_device+0x49/0xe0 [kvmgt] intel_gvt_driver_remove+0x2f/0xb0 i915_driver_remove+0xa4/0xf0 i915_pci_remove+0x1a/0x30 pci_device_remove+0x33/0xa0 device_release_driver_internal+0x1b2/ 0x230 unbind_store+0xe0/0x110 kernfs_fop_write_iter+0x11b/0x1f0 vfs_write+0x203/0x3d0 ksys_write+0x63/0xe0 do_syscall_64+0x37/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f6947cb5190 Code: 40 00 48 8b 15 71 9c 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 80 3d 51 24 0e 00 00 74 17 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 8300 ec 48 28 48 89 RSP002b:00007ffcbac45a28 EFLAGS00000202 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 000000000000000d RCX
    00007f6947cb5190 RDX: 000000000000000d RSI: 0000555e35c866a0 RDI: 0000000000000001 RBP: 0000555e35c866a0 R08: 0000000000000002 R09: 0000555e358cb97c R10: 0000000000000000 R11: 0000000000000202 R12:
    0000000000000001 R13000000000000000d R140000000000000000 R150000555e358cb8e0 </TASK> 链接模块kvmgt CR200000000000000a0 ---[结束跟踪 000000000] (---) [CVE-2023-5409800000 ]

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

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

  - erofs当 pcluster 块地址为零时修复其内存泄漏 syzkaller 报告了一个内存泄漏
    https://syzkaller.appspot.com/bug?id=62f37ff612f0021641eda5b17f056f1668aa9aed 未引用对象 0xffff88811009c7f8大小 136... backtrace [<ffffffff821db19b>] z_erofs_do_read_page+0x99b/0x1740 [<ffffffff821dee9e>] z_erofs_readahead+0x24e/0x580 [<ffffffff814bc0d6>] read_pages+0x86/0x3d0 ...
    syzkaller 构建了一个 case在 z_erofs_register_pcluster() 中ztailpacking = false 且 map->m_pa = zero。
    这使得 pcl->obj.index 为零尽管 pcl 不是内联 pcluster。然后跟随的路径会添加 grp 的 refcount但不会放置 refcount因为 pcl 为内联。 z_erofs_readahead() z_erofs_do_read_page() # for another page z_erofs_collector_begin() erofs_find_workgroup() erofs_workgroup_get() 由于非法非内联 pcluster 的区块地址为零因此在此处添加检查以避免注册会泄漏的 pcluster。 (CVE-2022-50743)

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

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

  - f2fs修复 LFS 中因缺少可用空间而导致的系统崩溃当 f2fs 在 LFS 模式中的前台 gc 期间尝试设置检查点时如果数据迁移生成的脏节点和 dentry 页面的数量超过可用空间则由于缺少可用空间会发生系统崩溃空间。重现顺序如下。 - 20GiB 容量块设备 (null_blk) - 以 LFS 模式格式化和挂载 - 创建文件并写入 20,000MiB - 在文件的整个范围上进行 4k 随机写入 RIP0010:new_curseg+0x48a/0x510 [f2fs] 代码55 e7 f5 89 c0 48 0f af c3 48 8b 5d c0 48 c1 e8 20 83 c0 01 89 43 6c 48 83 c4 28 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc <0f> 0b f0 41 80 4f 48 854 45 854 f6 0f 84 ba fd ff ff e9 ef fe ff ff RSP: 0018:ffff977bc397b218 EFLAGS: 00010246 RAX: 00000000000027b9 RBX: 0000000000000000 RCX: 00000000000027c00000RDX: 00000000000000000
    00000000000027b9 RDI: ffff8c25ab4e74f8 RBP: ffff977bc397b268 R08: 00000000000027b9 R09: ffff8c29e4a34b40 R10: 0000000000000001 R11: ffff977bc397b0d8 R12: 0000000000000000 R13: ffff8c25b4dd81a0 R14:
     R150000000000000000  : ffff8c2f667f9000 FS: 0000000000000000(0000) GS:ffff8c344ec80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000c00055d000 CR3:
    0000000e30810003 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> allocate_segment_by_default+0x9c/0x110 [f2fs] f2fs_allocate_data_block+0x243/0xa30 [f2fs] ?
    __mod_lruvec_page_state+0xa0/0x150 do_write_page+0x80/0x160 [f2fs] f2fs_do_write_node_page+0x32/0x50 [f2fs] __write_node_page+0x339/0x730 [f2fs] f2fs_sync_node_pages+0x5a6/0x780 [f2fs] block_operations+0x257/0x340 [f2fs] f2fs_write_checkpoint+0x102/0x1050 [f2fs] f2fs_gc+0x27c/0x630 [f2fs] ? folio_mark_dirty+0x36/0x70 f2fs_balance_fs+0x16f/0x180 [f2fs] 此修补程序在 gc 期间的检查点之前增加了空闲区段是否足够的检查。[Jaegeuk Kim代码清理] (CVE-2023-54151)

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

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

  - ntfs3修复 mi_format_new 中 mi_read 失败后的未初始化内存 修复由 syzkaller 发现的 KMSAN 未初始化缺陷。
    ntfs_get_bh() 预期从 sb_getblk() 获得缓冲区该缓冲区可能不是最新的。在将缓冲区设置为最新之前我们没有使其更新。如果缓冲区不是最新的则可能意味着将具有未初始化数据的缓冲区添加到 mi 记录。尝试加载该记录将触发 KMSAN。通过覆盖将缓冲区设置为最新版本如果还不是最新版本可以避免这种情况。 (CVE-2025-68728)

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

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

  - socmediatekmtk-svs稍后启用 IRQ 如果系统未完成重置如通过 kexec() 引导时外设可能在数据结构初始化之前触发 IRQ。 [ 0.227710] 无法处理虚拟地址 0000000000000f08 处的内核空指针取消引用 [ 0.227913] 调用跟踪[ 0.227918] svs_isr+0x8c/0x538 (CVE-2023-54059)

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

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

  - 互连修复 runpm 与回收的锁定 对于在 callbaths 中调用 icc_bw_set()可能会针对 shrinker/reclaim 造成死锁的情况例如 runpm resume我们需要分离 icc 锁定。
    针对需要序列化 bw 聚合和更新的情况引入新的 icc_bw_lock以将其与需要内存分配的路径例如节点/链接创建/销毁分离。修复此 lockdep 崩溃============================================= ========= 警告已检测到潜在的循环锁定依赖关系 6.2.0-rc8-debug+ #554 未受感染
    -------------------------------------------------- ---- ring0/132 正在尝试获取锁定
    ffffff80871916d0 (&gmu->lock){+.+.}-{3:3}a6xx_pm_resume+0xf0/0x234但任务已持有锁定
    ffffffdb5aee57e8 (dma_fence_map){++++}-{0:0}, atmsm_job_run+0x68/0x150 哪些锁定已依赖于新的锁定。现有依存关系链以相反顺序排列为 -> #4 (dma_fence_map){++++}-{0:0}
    __dma_fence_might_wait+0x74/0xc0 dma_resv_lockdep+0x1f4/0x2f4 do_one_initcall+0x104/0x2bc kernel_init_freeable+0x344/0x34c kernel_init+0x30/0x134 ret_from_fork+0x10/0x20 -> #3 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}: fs_reclaim_acquire +0x80/0xa8 slab_pre_alloc_hook.constprop.0+0x40/0x25c __kmem_cache_alloc_node+0x60/0x1cc __kmalloc+0xd8/0x100 topology_parse_cpu_capacity+0x8c/0x178 get_cpu_for_node+0x88/0xc4 parse_cluster+0x1b0/0x28c parse_cluster+0x8c/0x28c init_cpu_topology+0x168/0x188 smp_prepare_cpus+ 0x24/0xf8 kernel_init_freeable+0x18c/0x34c kernel_init+0x30/0x134 ret_from_fork+0x10/0x20 -> #2 (fs_reclaim){+.+.}-{0:0}__fs_reclaim_acquire+0x3c/0x48 fs_reclaim_acquire+0x54/0xa8 slabk_altloc_slab .0+0x40/0x25c __kmem_cache_alloc_node+0x60/0x1cc __kmalloc+0xd8/0x100 kzalloc.constprop.0+0x14/0x20 icc_node_create_nolock+0x4c/0xc4 icc_node_create+0x38/0x58 qcom_icc_rpmh_probe+0x1b8/0x248 platform_probe+0x70/0xc4 really_probe+0x158/0x290
    __driver_probe_device+0xc8/0xe0 driver_probe_device+0x44/0x100 __driver_attach+0xf8/0x108 bus_for_each_dev+0x78/0xc4 driver_attach+0x2c/0x38 bus_add_driver+0xd0/0x1d8 driver_register+0xbc/0xf8
    __platform_driver_register+0x30/0x3c qnoc_driver_init+0x24/0x30 do_one_initcall+0x104/0x2bc kernel_init_freeable+0x344/0x34c kernel_init+0x30/0x134 ret_from_fork+0x10/0x20 -> #1 (icc_lock){+.+.}-{3:3}__mutex_lock +0xcc/0x3c8 mutex_lock_nested+0x30/0x44 icc_set_bw+0x88/0x2b4
    _set_opp_bw+0x8c/0xd8 _set_opp+0x19c/0x300 dev_pm_opp_set_opp+0x84/0x94 a6xx_gmu_resume+0x18c/0x804 a6xx_pm_resume+0xf8/0x234 adreno_runtime_resume+0x2c/0x38 pm_generic_runtime_resume
    __rpm_callback+0x15c/0x174 rpm_callback+0x78/0x7c rpm_resume+0x318/0x524 __pm_runtime_resume+0x78/0xbc adreno_load_gpu+0xc4/0x17c msm_open+0x50/0x120 drm_file_alloc+0x17c/0x228 drm_open_helper+0x74/0x118 drm_open+0xa0/0x144 drm_stub_open+0xd4/0xe4 chrdev_open+0x1b8/0x1e4 do_dentry_open+0x2f8/0x38c vfs_open+0x34/0x40 path_openat+0x64c/0x7b4 do_filp_open+0x54/0xc4 do_sys_openat2+0x9c/0x100 do_sys_open+0x50/0x7c __arm64_sys_openat+0x28/0x34 invoke_syscall+0x8c/0x128 el0_svc_common.constprop.0 +0xa0/0x11c do_el0_ ---truncated--- (CVE-2023-54013)

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

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

  - btrfs修复从脏 cow 根列表中删除可用空间根时的争用在删除可用空间树时我们将从列表 fs_info->dirty_cowonly_roots 中删除可用空间根而不采用对其进行保护的锁即 struct btrfs_fs_info: trans_lock。如果此列表有另一个并发操纵例如使用 ctree.c:add_root_to_dirty_list()向其添加根时此未同步列表操纵可能会造成混乱。这可导致由争用造成的各种奇怪故障例如下列崩溃[337571.278245] 一般保护错误可能因非规范地址 0xdead000000000108: 0000 [#1] PREEMPT SMP PTI [337571.278933] CPU 1 PID115447 Commbtrfs 受感染GW 6.4.0-rc6-btrfs-next-134+ #1 [337571.279153] 硬件名称QEMU Standard PC (i440FX + PIIX,1996), BIOS rel-1.14.0-0 -g155821a1990b-prebuilt.qemu.org 04/01/2014 [337571.279572] RIP
    0010commit_cowonly_roots+0x11f/0x250 [btrfs] [337571.279928] Code: 85 38 06 00 (...) [337571.280363] RSP
    0018:ffff9f63446efba0 EFLAGS00010206 [337571.280582] RAX: ffff942d98ec2638 RBX: ffff9430b82b4c30 RCX
    0000000449e1c000 [337571.280798] RDX: dead000000000100 RSI: ffff9430021e4900 RDI: 0000000000036070 [337571.281015] RBP: ffff942d98ec2000 R08: ffff942d98ec2000 R09: 000000000000 [0000000000337571.281254] [00000000000 R10
    0000000000000009 R110000000000000001 R12ffff942fe8fbf600 [337571.281476] R13ffff942dabe23040 R14
    ffff942dabe20800 R15ffff942d92cf3b48 [337571.281723] FS: 00007f478adb7340(0000) GS:ffff94349fa40000(0000) knlGS:0000000000000000 [337571.281950] CS: 0010 DS: 00000 ES: 0
    0000000080050033 [337571.282184] CR2: 00007f478ab9a3d5 CR3: 000000001e02c001 CR4: 0000000000370ee0 [337571.282416] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [337571.282647] DR3:
    0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [337571.282874] 调用跟踪 [337571.283101] <TASK> [337571.283327] ? __die_body+0x1b/0x60 [337571.283570] ? die_addr+0x39/0x60 [337571.283796] ? exc_general_protection+0x22e/0x430 [337571.284022] ? asm_exc_general_protection+0x22/0x30 [337571.284251] ? commit_cowonly_roots+0x11f/0x250 [btrfs] [337571.284531] btrfs_commit_transaction+0x42e/0xf90 [btrfs] [337571.284803] ? _raw_spin_unlock+0x15/0x30 [337571.285031] release_extent_buffer+0x103/0x130 [btrfs] [337571.285305] reset_balance_state+0x152/0x1b0 [btrfs] [337571.285578] btrfs_balance+0xa50/0x11e0 [btrfs] [337571.285864] ? __kmem_cache_alloc_node+0x14a/0x410 [337571.286086] btrfs_ioctl+0x249a/0x3320 [btrfs] [337571.286358] ? mod_objcg_state+0xd2/0x360 [337571.286577] ? refill_obj_Stock+0xb0/0x160 [337571.286798] ? seq_release+0x25/0x30 [337571.287016] ? __rseq_handle_notify_resume+0x3ba/0x4b0 [337571.287235] ? percpu_counter_add_batch+0x2e/0xa0 [337571.287455] ? __x64_sys_ioctl+0x88/0xc0 [337571.287675]
    __x64_sys_ioctl+0x88/0xc0 [337571.287901] do_syscall_64+0x38/0x90 [337571.288126] entry_SYSCALL_64_after_hwframe+0x72/0xdc [337571.288352] RIP0033:0x7f478aaff9b因此通过在删除其中的可用空间根之前锁定 struct btrfs_fs_info::trans_lock来修复此问题列表。 (CVE-2023-54067)

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

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

  - ice通过 ethtool 创建新的 Tx 环时设置 tx_tstamps 用户通过 ethtool 更改队列数时驱动程序会分配新环。此分配未初始化 tx_tstamps。这导致 tx_tstamps 字段因 kcalloc 分配为零并且在尝试在新环上传输时间戳时导致空指针取消引用。 (CVE-2022-50710)

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

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

  - drm/panthor修复设备拔出和固件事件处理之间的 UAF 争用panthor_fw_unplug() 函数将释放固件内存部分。问题是此时可能仍有待定的固件事件未处理。在这种情况下process_fw_events_work() 可尝试访问所述已释放的内存。
    只需调用 disable_work_sync() 即可耗尽并防止未来对 process_fw_events_work() 的调用。
    (CVE-2025-68748)

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

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

  - md/raid5删除 raid5_read_one_chunk() 中不必要的 bio_put() 在含有 badblock 的磁盘上运行区块大小的读取时观察到重复 bio 释放/放置
    ================================================== =========================== BUG bio-200未受感染
    对象已释放-------------------------------------------- ------------------------------ 在 mempool_alloc_slab+0x17/0x20 age=3 cpu=2 pid=7504 __slab_alloc.constprop 中分配。 0+0x5a/0xb0 kmem_cache_alloc+0x31e/0x330 mempool_alloc_slab+0x17/0x20 mempool_alloc+0x100/0x2b0 bio_alloc_bioset+0x181/0x460 do_mpage_readpage+0x776/0xd00 mpage_readahead+0x166/0x320 blkdev_readahead+0x15/0x20 read_pages+0x13f/0x5f0 page_cache_ra_unbounded+0x18d/0x220 force_page_cache_ra+0x181/0x1c0 page_cache_sync_ra+0x65/0xb0 filemap_get_pages+0x1df/0xaf0 filemap_read+0x1e1/0x700 blkdev_read_iter+0x1e5/0x330 vfs_read+0x42a/0x570 Freed in mempool_free_slab+0x17/0x20 age=3 cpu=2 pid=7504 kmem_cache_free+0x46d/ 0x490 mempool_free_slab+0x17/0x20 mempool_free+0x66/0x190 bio_free+0x78/0x90 bio_put+0x100/0x1a0 raid5_make_request+0x2259/0x2450 md_handle_request+0x402/0x600 md_submit_bio+0xd9/0x120 __submit_bio+0x11f/0x1b0 submit_bio_noacct_nocheck+0x204/0x480 submit_bio_noacct+0x32e/ 0xc70 submit_bio+0x98/0x1a0m page_readahead+0x250/0x320 blkdev_readahead+0x15/0x20 read_pages+0x13f/0x5f0 page_cache_ra_unbounded+0x18d/0x220 Slab 0xffffea000481b600 objects=21 used=0 fp=0xffff8881206d8940 flags=0x17ffffc0010201(locked|slab|head|node=0|zone=2|lastcpupid=0x1fffff] CPU: 0 PID: 34525 Comm
    kworker/u24:2 Not tainted 6.0.0-rc2-localyes-265166-gf11c5343fa3f #143 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Workqueue raid5wq raid5_do_work Call Trace: <TASK> dump_stack_lvl+0x5a/0x78 dump_stack+0x10/0x16 print_trailer+0x158/0x165 object_err+0x35/0x50 free_debug_processing.cold+0xb7/0xbe __slab_free+0x1ae/0x330 kmem_cache_free+0x46d/0x490 mempool_free_slab+0x17/0x20 mempool_free +0x66/0x190 bio_free+0x78/0x90 bio_put+0x100/0x1a0 mpage_end_io+0x36/0x150 bio_endio+0x2fd/0x360 md_end_io_acct+0x7e/0x90 bio_endio+0x2fd/0x360 handle_failed_stripe+0x960/0xb80 handle_stripe+0x1348/0x3760 handle_active_stripes.constprop.0+ 0x72a/0xaf0 raid5_do_work+0x177/0x330 process_one_work+0x616/0xb20 worker_thread+0x2bd/0x6f0 kthread+0x179/0x1b0 ret_from_fork+0x22/0x30 </TASK> 双重释放是由 if(is_badblock(... )) raid5_read_one_chunk() 中的错误路径。在 c82aa1b76787c 中将错误路径移到 bio_alloc_clone() 之前md/raid5在 raid5_read_one_chunk 中克隆 bio 之前移动 badblock 检查。之前的代码检查并释放 align_bio 其需要 bio_put。移动之后不再需要的内容作为 raid_bio 返回至通用 io 路径的控制该路径执行其自己的 endio 导致在错误设备区块上发生双重释放。 (CVE-2022-50752)

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

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

  - net防止 frag 列表分段上的 skb 损坏 Ian 报告了多个由 rx-gro-list 触发的 skb 损坏收集不同的 oops alike[ 62.624003] 缺陷内核空指针取消引用解决
    00000000000000c0 [ 62.631083] #PF内核模式中的主管读取访问权限 [ 62.636312] #PF
    error_code(0x0000) - not-present 页面 [ 62.641541] PGD 0 P4D 0 [ 62.644174] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 62.648629] CPU: 1 PID: 913 Commnapi/eno2-79 未受感染 6.4.0 #364 [ 62.655162] 硬件名称
    Supermicro Super Server/A2SDi-12C-HLN4F, BIOS 1.7a 10/13/2022 [ 62.663344] RIP: 0010:__udp_gso_segment (./include/linux/skbuff.h:2858 ./include/linux/udp.h:23 net/ipv4/udp_offload.c:228 net/ipv4/udp_offload.c:261 net/ipv4/udp_offload.c:277) [ 62.687193] RSP: 0018:ffffbd3a83b4f868 EFLAGS
    00010246 [ 62.692515] RAX: 00000000000000ce RBX: 0000000000000000 RCX: 0000000000000000 [ 62.699743] RDX:
    ffffa124def8a000 RSI0000000000000079 RDIffffa125952a14d4 [ 62.706970] RBPffffa124def8a000 R08
    0000000000000022 R0900002000001558c9 [ 62.714199] R100000000000000000 R1100000000be554639 R12
    00000000000000e2 [ 62.721426] R13: ffffa125952a1400 R14: ffffa125952a1400 R15: 00002000001558c9 [62.728654] FS: 0000000000000000(0000) GS:ffffa127efa40000(0000) knlGS:0000000000000000 [ 62.736852] CS:
    0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 62.742702] CR2: 00000000000000c0 CR3: 00000001034b0000 CR4:
    00000000003526e0 [ 62.749948] 调用跟踪[ 62.752498] <TASK> [ 62.779267] inet_gso_segment (net/ipv4/af_inet.c:1398) [ 62.787605] skb_mac_gso_segment (net/core/gro.c:141) [ 62.791906]
    __skb_gso_segment (net/core/dev.c:3403标识符 2) [ 62.800492] validate_xmit_skb (./include/linux/netdevice.h:4862 net/core/dev.c:3659) [ 62.804695] validate_xmit_skb_list (net /core/dev.c:3710) [ 62.809158] sch_direct_xmit (net/sched/sch_generic.c:330) [ 62.813198]
    __dev_queue_xmit (net/core/dev.c:3805 net/core/dev.c:4210) net/netfilter/core.c:626) [ 62.821093] br_dev_queue_push_xmit (net/bridge/br_forward.c:55) [ 62.825652]maybe_deliver (net/bridge/br_forward.c:193) [ 62.829420] br_flood (net/bridge/br_forward.c:233) [ 62.832758] br_handle_frame_finish (net/bridge/br_input.c:215) [ 62.837403] br_handle_frame (net/bridge/br_input.c:298 net/bridge/br_input.c:416) [ 62.851417] __netif_receive_skb_core.constprop.0 (net/core/dev.c:5387) [62.866114] __netif_receive_skb_list_core (net/core/ dev.c:5570) [ 62.871367] netif_receive_skb_list_internal (net/core/dev.c:5638 net/core/dev.c:5727) [ 62.876795napi_complete_done (./include/linux/list.h:37 ./ include/net/gro.h:434 ./include/net/gro.h:429 net/core/dev.c:6067[62.881004] ixgbe_poll (drivers/net/ethernet/intel/ixgbe/ixgbe_main.c) 3191) [ 62.893534] __napi_poll (net/core/dev.c:6498) [ 62.897133] napi_threaded_poll (./include/linux/netpoll.h:89 net/core/dev.c:6640) [62.905276] kthread (kernel/kthread.c:379) [ 62.913435] ret_from_fork (arch/x86/entry/entry_64.S:314) [62.917119] </TASK> 在危急情况下rx-gro-list GRO-ed 数据包会通过桥接被馈送到本地输入路径和出口设备 (tun)。此类数据包的分段会不安全地写入具有共享头的克隆的 skb。此变更通过根据需要取消克隆将要分段的 skb来解决 问题。 (CVE-2023-54094)

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

ID	名称	严重性
279888	Linux Distros 未修补的漏洞：CVE-2023-54052	medium
279887	Linux Distros 未修补的漏洞：CVE-2022-50771	medium
279886	Linux Distros 未修补的漏洞：CVE-2023-54128	medium
279885	Linux Distros 未修补的漏洞：CVE-2023-54095	high
279884	Linux Distros 未修补的漏洞：CVE-2023-54100	high
279883	Linux Distros 未修补的漏洞：CVE-2023-54117	medium
279882	Linux Distros 未修补的漏洞：CVE-2023-54089	high
279881	Linux Distros 未修补的漏洞：CVE-2023-54131	medium
279880	Linux Distros 未修补的漏洞：CVE-2022-50728	high
279879	Linux Distros 未修补的漏洞：CVE-2023-54071	medium
279878	Linux Distros 未修补的漏洞：CVE-2023-54110	high
279877	Linux Distros 未修补的漏洞：CVE-2023-54070	medium
279876	Linux Distros 未修补的漏洞：CVE-2022-50738	medium
279875	Linux Distros 未修补的漏洞：CVE-2023-54084	high
279874	Linux Distros 未修补的漏洞：CVE-2023-54123	high
279873	Linux Distros 未修补的漏洞：CVE-2022-50721	medium
279872	Linux Distros 未修补的漏洞：CVE-2023-54096	high
279871	Linux Distros 未修补的漏洞：CVE-2023-54148	high
279870	Linux Distros 未修补的漏洞：CVE-2022-50715	medium
279869	Linux Distros 未修补的漏洞：CVE-2023-54043	high
279868	Linux Distros 未修补的漏洞：CVE-2023-54093	medium
279867	Linux Distros 未修补的漏洞：CVE-2022-50740	medium
279866	Linux Distros 未修补的漏洞：CVE-2023-54108	medium
279865	Linux Distros 未修补的漏洞：CVE-2022-50717	high
279864	Linux Distros 未修补的漏洞：CVE-2023-54076	high
279863	Linux Distros 未修补的漏洞：CVE-2022-50769	medium
279862	Linux Distros 未修补的漏洞：CVE-2022-50724	medium
279861	Linux Distros 未修补的漏洞：CVE-2023-54102	high
279860	Linux Distros 未修补的漏洞：CVE-2023-54090	medium
279859	Linux Distros 未修补的漏洞：CVE-2022-50782	high
279858	Linux Distros 未修补的漏洞：CVE-2023-54105	high
279856	Linux Distros 未修补的漏洞：CVE-2022-50780	high
279855	Linux Distros 未修补的漏洞：CVE-2023-54092	medium
279854	Linux Distros 未修补的漏洞：CVE-2023-54135	high
279853	Linux Distros 未修补的漏洞：CVE-2022-50774	high
279852	Linux Distros 未修补的漏洞：CVE-2023-54023	medium
279851	Linux Distros 未修补的漏洞：CVE-2022-50755	medium
279850	Linux Distros 未修补的漏洞：CVE-2023-54019	medium
279849	Linux Distros 未修补的漏洞：CVE-2023-54129	medium
279848	Linux Distros 未修补的漏洞：CVE-2023-54098	medium
279847	Linux Distros 未修补的漏洞：CVE-2022-50743	medium
279846	Linux Distros 未修补的漏洞：CVE-2023-54151	medium
279845	Linux Distros 未修补的漏洞：CVE-2025-68728	high
279844	Linux Distros 未修补的漏洞：CVE-2023-54059	medium
279843	Linux Distros 未修补的漏洞：CVE-2023-54013	medium
279842	Linux Distros 未修补的漏洞：CVE-2023-54067	medium
279841	Linux Distros 未修补的漏洞：CVE-2022-50710	medium
279840	Linux Distros 未修补的漏洞：CVE-2025-68748	medium
279839	Linux Distros 未修补的漏洞：CVE-2022-50752	high
279838	Linux Distros 未修补的漏洞：CVE-2023-54094	medium

检测

Nessus 的 Misc. 系列

medium

medium

medium

high

high

medium

high

medium

high

medium

high

medium

medium

high

high

medium

high

high

medium

high

medium

medium

medium

high

high

medium

medium

high

medium

high

high

high

medium

high

high

medium

medium

medium

medium

medium

medium

medium

high

medium

medium

medium

medium

medium

high

medium