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

  - 已修复 Linux 内核中的下列漏洞：wwan_hwsim: fix possible memory leak in wwan_hwsim_dev_new() Inject fault while probing module, if device_register() fails, but the refcount of kobject is not decreased to 0, the name allocated in dev_set_name() is leaked. Fix this by calling put_device(), so that name can be freed in callback function kobject_cleanup(). unreferenced object 0xffff88810152ad20 (size 8): comm modprobe, pid 252, jiffies 4294849206 (age 22.713s) hex dump (first 8 bytes): 68 77 73 69 6d 30 00 ff hwsim0.. backtrace: [<000000009c3504ed>]
    __kmalloc_node_track_caller+0x44/0x1b0 [<00000000c0228a5e>] kvasprintf+0xb5/0x140 [<00000000cff8c21f>] kvasprintf_const+0x55/0x180 [<0000000055a1e073>] kobject_set_name_vargs+0x56/0x150 [<000000000a80b139>] dev_set_name+0xab/0xe0 (CVE-2022-50331)

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

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

  - driversseriajsm修复探测中的一些泄漏此错误路径需要展开而不仅仅是直接返回。 (CVE-2022-50312)

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

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

  - erofs修复原子上下文的检测对原子上下文的当前检查不充分因为可在 rcu 锁定下从 blk_mq_flush_plug_list() 调用 z_erofs_decompressqueue_endio。请参阅堆栈跟踪 [1] 在这种情况下我们应该移交异步处理的解压缩工作而不是尝试在当前上下文中执行同步解压缩。修补程序通过检查 rcu_read_lock_any_held() 来修复检测 当它使用比 in_atomic() 更适当的 !in_task() 检查时。
    背景：历史上erofs 将始终计划 kworker 进行解压缩，这将导致计划成本与上下文无关。但是 z_erofs_decompressqueue_endio() 可能并不总是在原子上下文中如果在线程上下文中例如通过 dm-verity 运行时我们实际上可以从在 z_erofs_decompressqueue_endio() 中执行解压缩中受益。此优化后来添加到修补程序 [2] 中其显示了性能基准方面的改进。
    ============================================== [1] 问题stacktrace [name:core&]BUG从 kernel/locking/mutex.c:291 的无效上下文调用的休眠函数 [name:core&]in_atomic()0, irqs_disabled(): 0, non_block: 0, pid: 1615, name CpuMonitorServi [名称：core&]preempt_count0，预期：0 [名称：core&]RCU 嵌套深度：1，预期：0 CPU：7 PID：1615 Comm：CpuMonitorServi Tainted：GSW OE 6.1.25-android14-5-maybe -dirty-mainline #1 硬件名称 MT6897 (DT) 调用跟踪
    dump_backtrace+0x108/0x15c show_stack+0x20/0x30 dump_stack_lvl+0x6c/0x8c dump_stack+0x20/0x48
    __might_resched+0x1fc/0x308 __might_sleep+0x50/0x88 mutex_lock+0x2c/0x110 z_erofs_decompress_queue+0x11c/0xc10 z_erofs_decompress_kickoff+0x110/0x1a4 z_erofs_decompressqueue_endio+0x154/0x180 bio_endio+0x1b0/0x1d8 __dm_io_complete+0x22c/0x280 clone_endio+0xe4/0x280 bio_endio+0x1b0/0x1d8 blk_update_request+0x138/0x3a4 blk_mq_plug_issue_direct+0xd4/0x19c blk_mq_flush_plug_list+0x2b0/0x354 __blk_flush_plug+0x110/0x160 blk_finish_plug+0x30/0x4c read_pages+0x2fc/0x370 page_cache_ra_unbounded+0xa4/0x23c page_cache_ra_order+0x290/0x320 do_sync_mmap_readahead+0x108/0x2c0 filemap_fault+0x19c/0x52c
    __do_fault+0xc4/0x114 handle_mm_fault+0x5b4/0x1168 do_page_fault+0x338/0x4b4 do_translation_fault+0x40/0x60 do_mem_abort+0x60/0xc8 el0_da+0x4c/0xe0 el0t_64_sync_handler+0xd4/0xfc el0t_64_sync+0x1a0/0x1a4 [2] Link:
    https://lore.kernel.org/all/20210317035448.13921-1-huangjianan@oppo.com/ (CVE-2023-53231)

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

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

  - wifi: ath9k不允许覆盖 ENDPOINT0 属性不良 USB 设备能够构建服务连接响应消息其目标端点是 ENDPOINT0其专为 HTC_CTRL_RSVD_SVC 保留且不应修改为用于任何其他服务。拒绝此类服务连接响应。
    由 Linux Verification Center (linuxtesting.org) 通过 Syzkaller 发现。 (CVE-2023-53185)

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

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

  - 已修复 Linux 内核中的下列漏洞：skbuff: Fix a race between coalescing and releasing SKBs Commit 1effe8ca4e34 (skbuff: fix coalescing for page_pool fragment recycling) allowed coalescing to proceed with non page pool page and page pool page when @from is cloned, i.e. to->pp_recycle
    --> false from->pp_recycle --> true skb_cloned(from) --> true However, it actually requires skb_cloned(@from) to hold true until coalescing finishes in this situation. If the other cloned SKB is released while the merging is in process, from_shinfo->nr_frags will be set to 0 toward the end of the function, causing the increment of frag page _refcount to be unexpectedly skipped resulting in inconsistent reference counts. Later when SKB(@to) is released, it frees the page directly even though the page pool page is still in use, leading to use-after-free or double-free errors. So it should be prohibited. The double-free error message below prompted us to investigate: BUG: Bad page state in process swapper/1 pfn:0e0d1 page:00000000c6548b28 refcount:-1 mapcount:0 mapping:0000000000000000 index:0x2 pfn:0xe0d1 flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff) raw: 000fffffc0000000 0000000000000000 ffffffff00000101 0000000000000000 raw: 0000000000000002 0000000000000000 ffffffffffffffff 0000000000000000 page dumped because: nonzero _refcount CPU: 1 PID: 0 Comm: swapper/1 Tainted: G E 6.2.0+ Call Trace: <IRQ> dump_stack_lvl+0x32/0x50 bad_page+0x69/0xf0 free_pcp_prepare+0x260/0x2f0 free_unref_page+0x20/0x1c0 skb_release_data+0x10b/0x1a0 napi_consume_skb+0x56/0x150 net_rx_action+0xf0/0x350 ? __napi_schedule+0x79/0x90 __do_softirq+0xc8/0x2b1 __irq_exit_rcu+0xb9/0xf0 common_interrupt+0x82/0xa0 </IRQ> <TASK> asm_common_interrupt+0x22/0x40 RIP: 0010:default_idle+0xb/0x20 (CVE-2023-53186)

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

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

  - netfilterx_tables修复创建新 netns 时错误路径上的 percpu 计数器块泄漏 这是我们在其中分配 percpu 计数器块 +-< __alloc_percpu +-< xt_percpu_counter_alloc +-< find_check_entry # {arp,ip,ip6}_tables 的堆栈。 c +-< translate_table 并且可以在此代码路径上泄漏 +-> ip6t_register_table +-> translate_table # allocates percpu counter block +-> xt_register_table # failed no release of the counter block on xt_register_table 失败。注意应调用 xt_percpu_counter_free 以释放该内存就像在 do_replace 中通过 cleanup_entry 辅助函数或在 __ip6t_unregister_table 中一样。
    AFAICS 命中此错误路径的可能性较低xt_register_table 在此只能返回 ENOMEM因为它不会替换任何内容因为我们正在创建新的 netns并且很难想像以前的所有分配都成功然后 xt_register_table 中的这个分配失败了。但是即使是罕见的泄漏也值得修复。 (CVE-2023-53200)

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

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

  - mmcvub300修复 mmc_add_host() 的返回值检查如果忽略其返回值mmc_add_host() 可能返回错误则在 mmc_alloc_host() 中分配的内存将泄漏并因未添加的删除而导致内核崩溃删除路径中的设备。因此通过检查返回值并转到将调用 mmc_free_host() 的错误路径来修复此问题此外需要删除在 mmc_add_host() 之前添加的定时器。
    此修补程序修复了另一个在 usb_control_msg() 失败时缺少的 mmc_free_host() 调用。 (CVE-2022-50251)

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

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

  - spiimx不跳过删除的错误路径中的清理 在平台驱动程序的删除回调中过早返回是错误的。这种情况下错误路径中的 dma 资源不会释放。此后绝不会重试因此这是永久泄漏。若要修复此问题仅在唤醒设备失败时才跳过硬件禁用。
    (CVE-2023-53225)

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

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

  - 9p将 req refcount 设置为零以避免未初始化的使用。分配新请求时如果重新使用 refcount 将会为零但如果该请求是从 slab 中新分配的则在被添加到 idr 之前不会完全初始化。p9_read_work 是否在引用计数启动之前得到响应。它将使用未初始化的 req从而导致错误的请求数据结构。以下是来自 syzbot 的日志。位于 0xffff88807eade00b 的内存损坏 [ 0xff 0x07 0x00 0x00 0x00 0x00 0x00 0x00 。 。 。 。 。 。 。 。 ] 中 kfence-#110
    p9_fcall_fini net/9p/client.c:248 [内联] p9_req_put net/9p/client.c:396 [内联] p9_req_put+0x208/0x250 net/9p/client.c:390 p9_client_walk+0x247/0x540 net/9p/client .c:1165 clone_fid fs/9p/fid.h:21 [内联] v9fs_fid_xattr_set+0xe4/0x2b0 fs/9p/xattr.c:118 v9fs_xattr_set fs/9p/xattr.c:100 [内联] v9fs_xattr_handler_set+0x6f/0x120 fs /9p/xattr.c:159 __vfs_setxattr+0x119/0x180 fs/xattr.c:182
    __vfs_setxattr_noperm+0x129/0x5f0 fs/xattr.c:216 __vfs_setxattr_locked+0x1d3/0x260 fs/xattr.c:277 vfs_setxattr+0x143/0x340 fs/xattr.c:309 setxattr+0x146/0x1attr+c:309 setxattr+0x146/0x1attr+c:609 0x197/0x1c0 fs/xattr.c:636 __do_sys_setxattr fs/xattr.c:652 [内联] __se_sys_setxattr fs/xattr.c:648 [内联]
    __ia32_sys_setxattr+0xc0/0x160 fs/xattr.c:648 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [内联]
    __do_fast_syscall_32+0x65/0xf0 arch/x86/entry/common.c:178 do_fast_syscall_32+0x33/0x70 arch/x86/entry/common.c:203 entry_SYSENTER_compat_after_hwframe+0x70/0x82 以下是类似的情况syzbot 日志中的情况看起来比这个问题更复杂但此修补程序可对其进行修复。 T21124 p9_read_work ======================== 第二个事务 ===================== ============ p9_client_walk p9_client_rpc p9_client_prepare_req p9_tag_alloc req = kmem_cache_alloc(p9_req_cache, GFP_NOFS); tag = idr_alloc << preempted >> req->tc.tag = tag; /* req->[refcount/tag] == 未初始化 */ m->rreq = p9_tag_lookup(m->client, m->rc.tag); /* 递增未初始化的 refcount */ refcount_set(&req->refcount, 2); /* cb 丢弃一个 ref */ p9_client_cb(req) /* reader 线程丢弃其 ref 请求被错误地释放
    */ p9_req_put(req) /* 释放后使用和引用下溢 */ p9_req_put(req) 要修复此问题可在添加到 idr 之前将 refcount 初始化为零。 (CVE-2022-50335)

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

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

  - 已修复 Linux 内核中的下列漏洞：usb: dwc3: qcom: Fix potential memory leak Function dwc3_qcom_probe() allocates memory for resource structure which is pointed by parent_res pointer. This memory is not freed. This leads to memory leak. Use stack memory to prevent memory leak.
    Found by Linux Verification Center (linuxtesting.org) with SVACE. (CVE-2023-53196)

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

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

  - 已修复 Linux 内核中的下列漏洞：ASoC: qcom: Add checks for devm_kcalloc As the devm_kcalloc may return NULL, the return value needs to be checked to avoid NULL poineter dereference. (CVE-2022-50308)

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

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

  - serial8250重新初始化端口特定驱动程序取消绑定上的 port->pm 当我们取消绑定串行端口硬件特定的 8250 驱动程序时通用 serial8250 驱动程序会接管端口。大约 10 秒后我们会看到 oops。这会产生至少在某些 TI SoC 上的以下错误未处理的错误不精确的外部中止 (0x1406) 内部错误1406 [#1] SMP ARM 发现 中可能仍然存在串行端口硬件特定的驱动程序 port->pm使用，并且 serial8250_pm() 在端口特定驱动消失后尝试调用它serial8250_pm [8250_base] from uart_change_pm+0x54/0x8c [serial_base] uart_change_pm [serial_base] from uart_hangup+0x154/0x198 [serial_base] uart_hangup [serial_base] from
    __tty_hangup.part.0+0x328/0x37c __tty_hangup.part.0来自 disassociate_ctty+0x154/0x20c disassociate_ctty来自 do_exit+0x744/0xaac do_exit来自 do_group_exit+0x40/0x8c do_group_exit来自调用 serial_set_default8250set_default8250在 serial8250_unregister_port() 中。此操作会将端口设置回 serial8250 默认函数并将 port->pm 设置为指向 serial8250_pm。
    (CVE-2023-53176)

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

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

  - 已修复 Linux 内核中的下列漏洞：power: supply: fix null pointer dereferencing in power_supply_get_battery_info when kmalloc() fail to allocate memory in kasprintf(), propname will be NULL, strcmp() called by of_get_property() will cause null pointer dereference. So return ENOMEM if kasprintf() return NULL pointer. (CVE-2022-50276)

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

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

  - 已修复 Linux 内核中的下列漏洞：drm/tests: helpers: Avoid a driver uaf when using __drm_kunit_helper_alloc_drm_device() the driver may be dereferenced by device-managed resources up until the device is freed, which is typically later than the kunit-managed resource code frees it. Fix this by simply make the driver device-managed as well. In short, the sequence leading to the UAF is as follows: INIT: Code allocates a struct device as a kunit-managed resource. Code allocates a drm driver as a kunit-managed resource. Code allocates a drm device as a device-managed resource. EXIT: Kunit resource cleanup frees the drm driver Kunit resource cleanup puts the struct device, which starts a device-managed resource cleanup device-managed cleanup calls drm_dev_put() drm_dev_put() dereferences the (now freed) drm driver -> Boom. Related KASAN message: [55272.551542] ================================================================== [55272.551551] BUG: KASAN: slab-use-after-free in drm_dev_put.part.0+0xd4/0xe0 [drm] [55272.551603] Read of size 8 at addr ffff888127502828 by task kunit_try_catch/10353 [55272.551612] CPU: 4 PID: 10353 Comm: kunit_try_catch Tainted: G U N 6.5.0-rc7+ #155 [55272.551620] Hardware name: ASUS System Product Name/PRIME B560M-A AC, BIOS 0403 01/26/2021 [55272.551626] Call Trace: [55272.551629] <TASK> [55272.551633] dump_stack_lvl+0x57/0x90 [55272.551639] print_report+0xcf/0x630 [55272.551645] ? _raw_spin_lock_irqsave+0x5f/0x70 [55272.551652] ? drm_dev_put.part.0+0xd4/0xe0 [drm] [55272.551694] kasan_report+0xd7/0x110 [55272.551699] ? drm_dev_put.part.0+0xd4/0xe0 [drm] [55272.551742] drm_dev_put.part.0+0xd4/0xe0 [drm] [55272.551783] devres_release_all+0x15d/0x1f0 [55272.551790] ? __pfx_devres_release_all+0x10/0x10 [55272.551797] device_unbind_cleanup+0x16/0x1a0 [55272.551802] device_release_driver_internal+0x3e5/0x540 [55272.551808] ? kobject_put+0x5d/0x4b0 [55272.551814] bus_remove_device+0x1f1/0x3f0 [55272.551819] device_del+0x342/0x910 [55272.551826] ? __pfx_device_del+0x10/0x10 [55272.551830] ? lock_release+0x339/0x5e0 [55272.551836] ? kunit_remove_resource+0x128/0x290 [kunit] [55272.551845] ?
    __pfx_lock_release+0x10/0x10 [55272.551851] platform_device_del.part.0+0x1f/0x1e0 [55272.551856] ?
    _raw_spin_unlock_irqrestore+0x30/0x60 [55272.551863] kunit_remove_resource+0x195/0x290 [kunit] [55272.551871] ? _raw_spin_unlock_irqrestore+0x30/0x60 [55272.551877] kunit_cleanup+0x78/0x120 [kunit] [55272.551885] ? __kthread_parkme+0xc1/0x1f0 [55272.551891] ? __pfx_kunit_try_run_case_cleanup+0x10/0x10 [kunit] [55272.551900] ? __pfx_kunit_generic_run_threadfn_adapter+0x10/0x10 [kunit] [55272.551909] kunit_generic_run_threadfn_adapter+0x4a/0x90 [kunit] [55272.551919] kthread+0x2e7/0x3c0 [55272.551924] ?
    __pfx_kthread+0x10/0x10 [55272.551929] ret_from_fork+0x2d/0x70 [55272.551935] ? __pfx_kthread+0x10/0x10 [55272.551940] ret_from_fork_asm+0x1b/0x30 [55272.551948] </TASK> [55272.551953] Allocated by task 10351:
    [55272.551956] kasan_save_stack+0x1c/0x40 [55272.551962] kasan_set_track+0x21/0x30 [55272.551966]
    __kasan_kmalloc+0x8b/0x90 [55272.551970] __kmalloc+0x5e/0x160 [55272.551976] kunit_kmalloc_array+0x1c/0x50 [kunit] [55272.551984] drm_exec_test_init+0xfa/0x2c0 [drm_exec_test] [55272.551991] kunit_try_run_case+0xdd/0x250 [kunit] [55272.551999] kunit_generic_run_threadfn_adapter+0x4a/0x90 [kunit] [55272.552008] kthread+0x2e7/0x3c0 [55272.552012] ret_from_fork+0x2d/0x70 [55272.552017] ret_from_fork_asm+0x1b/0x30 [55272.552024] Freed by task 10353: [55272.552027] kasan_save_stack+0x1c/0x40 [55272.552032] kasan_set_track+0x21/0x30 [55272.552036] kasan_save_free_info+0x27/0x40 [55272.552041]
    __kasan_slab_free+0x106/0x180 [55272.552046] slab_free_freelist_hook+0xb3/0x160 [55272.552051]
    __kmem_cache_free+0xb2/0x290 [55272.552056] kunit_remove_resource+0x195/0x290 [kunit] [55272.552064] kunit_cleanup+0x7 ---truncated--- (CVE-2023-53235)

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

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

  - hugetlbfs修复 hugetlbfs_parse_param() 中的 null-ptr-deref Syzkaller 报告一个 null-ptr-deref 缺陷========================== ============================= KASAN范围 [0x0000000000000000-0x0000000000000007] 中存在 null-ptr-deref RIP0010:hugetlbfs_parse_param+0x1dd /0x8e0 fs/hugetlbfs/inode.c:1380 [...] 调用跟踪 <TASK> vfs_parse_fs_param fs/fs_context.c:148 [inline] vfs_parse_fs_param+0x1f9/0x3c0 fs/fs_context.c:129 vfs_parse_fs_string+0xdb/0x170 fs /fs_context.c:191 generic_parse_monolithic+0x16f/0x1f0 fs/fs_context.c:231 do_new_mount fs/namespace.c:3036 [内联] path_mount+0x12de/0x1e20 fs/namespace.c:3370 do_mount fs/namespace.c:3383 [ inline] __do_sys_mount fs/namespace.c:3591 [内联] __se_sys_mount fs/namespace.c:3568 [内联] __x64_sys_mount+0x27f/0x300 fs/namespace.c:3568 do_syscall_x64 arch/x86/entry/common.c:50 [内联] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd [...] </TASK> ===================== ================================ = 根据提交 vfs: parse处理零长度字符串值如果 fs 字符串具有零长度内核会将 vfs_parse_fs_string() 中的 param->string 设置为空指针。但问题是hugetlbfs_parse_param() 将取消引用 param->string而不检查它是否为空指针。更具体而言如果 hugetlbfs_parse_param() 解析非法挂载参数如 size=,则内核将在 vfs_parse_fs_string() 中构建带有空指针的 struct fs_parameter然后将此结构 fs_parameter 传递至 hugetlbfs_parse_param()其可触发上述空指针ptr-deref 缺陷。此修补程序通过在 hugetlbfs_parse_param() 中的 param->string 添加健全性检查来解决此问题。 (CVE-2022-50334)

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

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

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

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

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

  - wifirtlwifi修复 _rtl8812ae_phy_set_txpower_limit() 中的全局越界缺陷 KASAN 报告一个全局越界缺陷BUGKASAN_rtl8812ae_eq_n_byte.0+ 中存在全局越界0x3d/0x84 [rtl8821ae] 由任务 NetworkManager/411 CPU6 在地址 ffffffffa0773c43 读取大小 1的 PID411 Comm
    NetworkManager 受感染GD 6.1.0-rc8+ #144 e15588508517267d37 硬件名称QEMU Standard PCQ35 + ICH92009调用追踪 <TASK>... kasan_report+0xbb/0x1c0 _rtl8812ae_eq_n_byte.part.0+0x3d/0x84 [ rtl8821ae] rtl8821ae_phy_bb_config.cold+0x346/0x641 [rtl8821ae] rtl8821ae_hw_init+0x1f5e/0x79b0 [rtl8821ae] ...</TASK> 问题的根本原因是 中的 prate_section 的比较顺序不同
    _rtl8812ae_phy_set_txpower_limit() 错误。_rtl8812ae_eq_n_byte() 用于比较两个字符串从尾到头的前 n 个字节从而导致该问题。在
    _rtl8812ae_phy_set_txpower_limit() 中最初打算通过仔细设计比较顺序来满足此要求。例如，pregulation 和 pbandwidth 会按长度从小到大的顺序进行比较，first 为 3，last 为 4。但是 prate_section 的比较顺序不遵守此顺序要求因此当 prate_section 为 HT 时从 tail 到 进行比较时头则会导致访问 _rtl8812ae_eq_n_byte() 中的越界。上文已提及
    _rtl8812ae_eq_n_byte() 与 strcmp() 具有相同的函数因此仅 strcmp() 便足够。通过删除来修复此问题
    _rtl8812ae_eq_n_byte() 和仅使用 strcmp()。虽然可通过调整 prate_section 的比较顺序来修复此问题但是这可导致 rate_section 的值不在 0 到 5 之间。此外 commit 21e4b0726dc6 不仅将驱动程序从临时树移动到常规树而且还添加了设置 txpower limit 函数因此问题是由此提交引入的。 (CVE-2022-50279)

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

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

  - sched/fair不平衡任务使其当前运行的 CPU 我们遇到过这样一种情况平衡器尝试平衡迁移已禁用的任务并在如下所示的 set_task_cpu() 中触发警告------- -----[在此处剪切 ]------------ WARNING: CPU: 7 PID: 0 at kernel/sched/core.c:3115 set_task_cpu+0x188/0x240 模块中链接的 hclgevf xt_CHECKSUM ipt_REJECT nf_reject_ipv4 <...snip> CPU7 PID0 Commswapper/7 Kdump
    已加载 TaintedGO 6.1.0-rc4+ #1 硬件名称Huawei TaiShan 2280 V2/BC82AMDC、BIOS 2280-V2 CS V5。B221.01 12/09/2021 pstate: 604000c9 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc
    set_task_cpu+0x188/0x240 lr load_balance+0x5d0/0xc60 spffff80000803bc70 x29ffff80000803bc70 x28
    ffff004089e190e8 x27: ffff004089e19040 x26: ffff007effcabc38 x25: 0000000000000000 x24: 0000000000000001 x23: ffff80000803be84 x22: 000000000000000c x21: ffffb093e79e2a78 x20: 000000000000000c x19:
    ffff004089e19040 x18: 0000000000000000 x17: 0000000000001fad x16: 0000000000000030 x15: 0000000000000000 x14: 0000000000000003 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000001 x10:
    0000000000000400 x9 : ffffb093e4cee530 x8 : 00000000fffffffe x7 : 0000000000ce168a x6 : 000000000000013e x5 : 00000000ffffffe1 x4 : 0000000000000001 x3 : 0000000000000b2a x2 : 0000000000000b2a x1 :
    ffffb093e6d6c510 x0 : 0000000000000001 调用跟踪 set_task_cpu+0x188/0x240 load_balance+0x5d0/0xc60 rebalance_domains+0x26c/0x380 _nohz_idle_balance.isra.0+0x1e0/0x370 run_rebalance_domains+0x806c
    __do_softirq+0x128/0x3d8 ____do_softirq+0x18/0x24 call_on_irq_stack+0x2c/0x38 do_softirq_own_stack+0x24/0x3c __irq_exit_rcu+0xcc/0xf4 irq_exit_rcu+0x18/0x24 el1_interrupt+0x4c/0xe4 el1h_64_irq_handler+0x18/0x2c el1h_64_irq+0x74/0x78 arch_cpu_idle+0x18/0x4c default_idle_call+0x58/0x194 do_idle+0x244/0x2b0 cpu_startup_entry+0x30/0x3c Secondary_start_kernel+0x14c/0x190
    __secondary_switched+0xb0/0xb4 ---[ end trace 0000000000000000]--- 进一步调查显示该警告是多余迁移禁用的任务将迁移到其当前正在运行的 CPU。这是因为在负载平衡时如果任务不允许使用 dst_cpu我们将重新选择 new_dst_cpu 作为候选。如果没有可以平衡到 dst_cpu 的任务我们将尝试将任务平衡到 new_dst_cpu。在这种情况下当迁移禁用的任务不在 CPU 上时它只允许在其当前的 CPU 上运行负载平衡将选择其当前的 CPU 作为 new_dst_cpu并在稍后触发上述警告。new_dst_cpu 是从 env->dst_grpmask 中选择的。目前其在 sched_group_span() 中包含 CPU如果有重叠的群组则可能遇到此情况。此修补程序利用 group_balance_mask() 的 env->dst_grpmask从最忙碌的组中排除任何 CPU并解决问题。对于在没有重叠组的域中进行平衡的行为与以前保持相同。
    (CVE-2023-53215)

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

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

  - 已修复 Linux 内核中的下列漏洞：mlxsw: minimal: fix potential memory leak in mlxsw_m_linecards_init The line cards array is not freed in the error path of mlxsw_m_linecards_init(), which can lead to a memory leak. Fix by freeing the array in the error path, thereby making the error path identical to mlxsw_m_linecards_fini(). (CVE-2023-53195)

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

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

  - drm/meson在聚合驱动程序解除绑定时间时删除 drm 桥未在模块卸载时手动删除 meson_encoder_hdmi_init 和 meson_encoder_cvbs_init 添加的 drm 桥造成对已释放内存的悬摆引用在全局 bridge_list 中保持链接状态。当重新加载驱动程序模块时相同的函数将再次调用 drm_bridge_add当遍历全局 bridge_list 时最终会查看已释放的内存。KASAN 再次揭示问题 [ +0.000095] ====================================== ======================= [ +0.000008] 缺陷KASAN中的释放后使用
    __list_add_valid+0x9c/0x120 [ +0.000018] 通过任务 modprobe/2483 在 addr ffff00003da291f0 进行大小 8 的读取 [+0.000018] CPU: 3 PID: 2483 Comm: modprobe 被污染: GCO 5.19.0-rc6-lrmbkasan+ #1 [ +0.000011] 硬件名称：Hardkernel ODROMID-N2Plus (DT) [ +0.000008] 调用跟踪[ +0.000006] dump_backtrace+0x1ec/0x280 [+0.000012] show_stack+0x24/0x80 [ +0.000008] dump_stack_lvl+0x98/ 0xd4 [ +0.000011] print_address_description.constprop.0+0x80/0x520 [ +0.000011] print_report+0x128/0x260 [ +0.000008] kasan_report+0xb8/0xfc [ +0.000008] __asan_report_load8_noabort+0x3c/0x50 [ +0.000009]
    __list_add_valid+0x9c/0x120 [ +0.000009] drm_bridge_add+0x6c/0x104 [drm] [ +0.000165] dw_hdmi_probe+0x1900/0x2360 [dw_hdmi] [ +0.000022] meson_dw_hdmi_bind+0x520/0x814 [component_dw_hdmi] [0.000014d +bin_hdmi] +0x174/0x520 [ +0.000012]component_bind_all+0x1a8/0x38c [ +0.000010] meson_drv_bind_master+0x5e8/0xb74 [meson_drm] [ +0.000032] meson_drv_bind+0x20/0x2c [meson_drm] [+0.000027] try_to_bring_up_aggregate_device+0x39c/0x39c [ +0.000010]component_master_add_with_match+0x1c8/0x284 [ +0.000009] meson_drv_probe+0x274/0x280 [meson_drm] [+0.000026] platform_probe+0xd0/0x220 [ +0.000009] real_probe+0x3ac/0xa80 [ +0.000009]
    __driver_probe_device+0x1f8/0x400 [ +0.000009] driver_probe_device+0x68/0x1b0 [ +0.000009]
    __driver_attach+0x20c/0x480 [ +0.000008] bus_for_each_dev+0x114/0x1b0 [ +0.000009] driver_attach+0x48/0x64 [ +0.000008] bus_add_driver+0x390/0x564 [ +0.000009] driver_register+0x1a8/0x3e4 [ +0.000009]
    __platform_driver_register+0x6c/0x94 [ +0.000008] meson_drm_platform_driver_init+0x3c/0x1000 [meson_drm] [+0.000027] do_one_initcall+0xc4/0x2b0 [ +0.000011] do_init_module+0x154/0x570 [ +0.000011] load_module+0x1a78/0x1ea4 [ +0.000008] __do_sys_init_module+0x184/0x1cc [ +0.000009]
    __arm64_sys_init_module+0x78/0xb0 [ +0.000009] invoke_syscall+0x74/0x260 [ +0.000009] el0_svc_common.constprop.0+0xcc/0x260 [ +0.000008] do_el0_svc+0x50/0x70 [ +0.000007] el0_svc+0x68/0x1a0 [ +0.000012] el0t_64_sync_handler+0x11c/0x150 [ +0.000008] el0t_64_sync+0x18c/0x190 [ +0.000016] 由任务 879 分配[ +0.000008] kasan_save_stack+0x2c/0x5c [ +0.000011] __kasan_kmalloc+0x90/0xd0 [ +0.000007]
    __kmalloc+0x278/0x4a0 [ +0.000011] mpi_resize+0x13c/0x1d0 [ +0.000011] mpi_powm+0xd24/0x1570 [ +0.000009] rsa_enc+0x1a4/0x30c [ +0.000009] pkcs1pad_verify+0x3f0/0x580 [ +0.000009] public_key_verify_signature+0x7a8/0xba4 [ +0.000010] public_key_verify_signature_2+0x40/0x60 [ +0.000008] verify_signature+0xb4/0x114 [ +0.000008] pkcs7_validate_trust_one.constprop.0+0x3b8/0x574 [ +0.000009] pkcs7_validate_trust+0xb8/0x15c [ +0.000008] verify_pkcs7_message_sig+0xec/0x1b0 [ +0.000012] verify_pkcs7_signature+0x78/0xac [ +0.000007] mod_verify_sig+0x110/0x190 [ +0.000009] module_sig_check+0x114/0x1e0 [ +0.000009] load_module+0xa0/0x1ea4 [ +0.000008]
    __do_sys_init_module+0x184/0x1cc [ +0.000008] __arm64_sys_init_module+0x78/0xb0 [ +0.000008] invoke_syscall+0x74/0x260 [ +0.000009] el0_svc_common.constprop.0+0x1a8/0x260 [ +0.000008] do_el0_svc+0x50/0x70 [ +0.000007] el0_svc+0x68/0x1a0 [ +0.000009] el0t_64_sync_handler+0x11c/0x150 [+0.000009] el0t_64 ---truncated--- (CVE-2022-50256)

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

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

  - btrfsbtrfs_cont_expand 中的 read_folio 之后的 set_page_extent_mapped 在尝试运行子页面块大小测试时我在 generic/476 断言失败上发生了下列错误PagePrivate(page) && page->private其在 fs/btrfs/subpage.c:229 fs/btrfs/subpage.c:229! 的内核缺陷内部错误Oops - BUG
    00000000f2000800 [#1] SMP CPU1 PID1453 Commfsstress Not tainted 6.4.0-rc7+ #12 硬件名称QEMU KVM 虚拟机BIOS edk2-20230301gitf80f052277c8-26.fc38 03/01/2023 pstate daif +PAN
    -UAO -TCO +DIT -SSBS BTYPE=--) pc : btrfs_subpage_assert+0xbc/0xf0 lr : btrfs_subpage_assert+0xbc/0xf0 Call trace: btrfs_subpage_assert+0xbc/0xf0 btrfs_subpage_clear_checked+0x38/0xc0 btrfs_page_clear_checked+0x48/0x98 btrfs_truncate_block+0x5d0/0x6a8 btrfs_cont_expand+0x5c/0x528 btrfs_write_check.isra.0+0xf8/0x150 btrfs_buffered_write+0xb4/0x760 btrfs_do_write_iter+0x2f8/0x4b0 btrfs_file_write_iter+0x1c/0x30 do_iter_readv_writev+0xc8/0x158 do_iter_write+0x9c/0x210 vfs_iter_write+0x24/0x40 iter_file_splice_write+0x224/0x390 direct_splice_actor +0x38/0x68 splice_direct_to_actor+0x12c/0x260 do_splice_direct+0x90/0xe8 generic_copy_file_range+0x50/0x90 vfs_copy_file_range+0x29c/0x470 __arm64_sys_copy_file_range+0xcc/0x498 invoke_syscall.constprop.0+0x80/0xd8 do_el0_svc+0x6c/0x168 el0_svc+0x50/0x1b0 el0t_64_sync_handler+ 0x114/0x120 el0t_64_sync+0x194/0x198 发生这种情况的原因是在 btrfs_cont_expand 期间我们会获取页面并将其设置为已映射如果该页面不是最新我们会读取它。然而在读取和重新锁定页面之间我们本可以在页面上调用 release_folio()但将页面留在文件映射中。 release_folio() 可将页面清除为私有因此当我们修改子页面位时会发生进一步崩溃。通过在读取之后放置 set_page_extent_mapped() 可以修复此问题。这是安全的因为 read_folio() 会在读取之前调用 set_page_extent_mapped()然后如果我们清除页面私有但将其保留在映射上我们就可以完全安全地重新设置 set_page_extent_mapped()。利用此修补程序我现在可以运行 generic/476而不会发生错误。 (CVE-2023-53247)

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

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

  - ACPItablesFPDT请勿在无效的 phys 地址上调用 acpi_os_map_memory() Packard Bell Dot SCIntel Atom [] 型号Packard Bell Dot SCIntel Atom N2600 型号中有一个 FPDT 表其中包含无效的物理地址其高位集超出了允许的范围CPU-s 支持的物理地址范围。在此类无效的 phys 地址上调用 acpi_os_map_memory()会在 ioremap 触发中导致以下 WARN_ON从而导致 oops/stacktrace。添加代码以在调用 acpi_os_map_memory() 之前验证物理地址以修复/避免 oops。 [ 1.226900] ioremap无效的物理地址 3001000000000000 [ 1.226949] ------------[ cut here ]------------ [ 1.226962] WARNING: CPU 1 PID: 1 at arch/x86/mm/ioremap.c:200 __ioremap_caller.cold+0x43/0x5f [ 1.226996] 中链接的模块 [ 1.227016] CPU
    1 PID11 Commswapper/0 未受感染 6.0.0-rc3+ #490 [ 1.227029] 硬件名称Packard Bell dot s/SJE01_CTBIOS V1.10 07/23/2013 [ 1.227038] RIP: 0010:__ioremap_caller .cold+0x43/0x5f [ 1.227054] Code
    96 00 00 e9 f8 af 24 ff 89 c6 48 c7 c7 d8 0c 84 99 e8 6a 96 00 00 e9 76 af 24 ff 48 89 fe 48 c7 c7 a8 0c 84 99 e8 56 96 00 00 <0f> 0b e9 60 af 24 ff 48 8b 34 24 48 c7 c7 40 0d 84 99 e8 3f 96 00 [ 1.227067] RSP
    0000:ffffb18c40033d60 EFLAGS00010286 [ 1.227084] RAX: 0000000000000032 RBX: 3001000000000000 RCX
    0000000000000000 [ 1.227095] RDX: 0000000000000001 RSI: 00000000ffffdfff RDI: 00000000ffffffff [ 1.227105] RBP: 3001000000000000 R08: 0000000000000000 R09: ffffb18c40033c18 [ 1.227115] R10: 0000000000000003 R11:
    ffffffff99d62fe8 R120000000000000008 [ 1.227124] R130003001000000000 R140000000000001000 R15
    3001000000000000 [ 1.227135] FS: 0000000000000000(0000) GS:ffff913a3c080000(0000) knlGS:0000000000000000 [1.227146] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1.227156] CR2: 0000000000000000 CR3:
    0000000018c26000 CR4: 00000000000006e0 [ 1.227167] 调用跟踪 [ 1.227176] <TASK> [ 1.227185] ? acpi_os_map_iomem+0x1c9/0x1e0 [ 1.227215] ? kmem_cache_alloc_trace+0x187/0x370 [ 1.227254] acpi_os_map_iomem+0x1c9/0x1e0 [ 1.227288] acpi_init_fpdt+0xa8/0x253 [ 1.227308] ? acpi_debugfs_init+0x1f/0x1f [ 1.227339] do_one_initcall+0x5a/0x300 [ 1.227406] ? rcu_read_lock_sched_held+0x3f/0x80 [ 1.227442] kernel_init_freeable+0x28b/0x2cc [ 1.227512] ? rest_init+0x170/0x170 [ 1.227538] kernel_init+0x16/0x140 [ 1.227552] ret_from_fork+0x1f/0x30 [ 1.227639] </TASK> [ 1.227647] irq 事件标记 186819 [ 1.227656] hardirqs last enabled at (186825):
    [<ffffffff98184a6e>] __up_console_sem+0x5e/0x70 [ 1.227672] hardirqs 上次禁用于 (186830)
    [<ffffffff98184a53>] __up_console_sem+0x43/0x70 [ 1.227686] softirqs 启用时间 (186576)
    [<ffffffff980fbc9d>] __irq_exit_rcu+0xed/0x160 [ 1.227701] softirqs 最后禁用于 (186569)
    [<ffffffff980fbc9d>] __irq_exit_rcu+0xed/0x160 [ 1.227715] ---[ 结束跟踪 0000000000000000 ]--- (CVE-2022-50320)

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

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

  - rxrpc设置为可中止等待的进程当 sendmsg() 创建 rxrpc 调用时会将其排队等待分配连接和通道然后等待然后才能开始将数据作为加密的 DATA 数据包内容进行抓取包括连接参数的摘要。但是sendmsg() 可能会在分配连接之前中断并且在进行分配之前进一步的 sendmsg() 调用将会因 EBUSY 而失败。修复此问题以便至少可以中止调用而不在 EBUSY 上失败。此处必须小心谨慎如果调用尚未分配连接则不得允许 sendmsg() 启动调用定时器否则此后不久可能会发生 oops。 (CVE-2023-53218)

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

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

  - drm/amdgpu修复 amddrm_buddy_fini 中的 calltrace 警告 删除 amdgpu 驱动程序时会发现以下调用追踪现象这是因为为 psp 分配的 BO直到删除才释放所导致。
    [61811.450562] RIP: 0010:amddrm_buddy_fini.cold+0x29/0x47 [amddrm_buddy] [61811.450577] 调用跟踪
    [61811.450577] <TASK> [61811.450579] amdgpu_vram_mgr_fini+0x135/0x1c0 [amdgpu] [61811.450728] amdgpu_ttm_fini+0x207/0x290 [amdgpu] [61811.450870] amdgpu_bo_fini+0x27/0xa0 [amdgpu] [61811.451012] gmc_v9_0_sw_fini+0x4a/fini+0x207/0x290 0x60 [amdgpu] [61811.451166] amdgpu_device_fini_sw+0x117/0x520 [amdgpu] [61811.451306] amdgpu_driver_release_kms+0x16/0x30 [amdgpu] [61811.451447] devm_drm_dev_init_release+0x4d/0x80 [drm] [61811.451466] devm_action_release+0x15/0x20 [61811.451469] release_nodes+0x40/0xb0 [61811.451471] devres_release_all+0x9b/0xd0 [61811.451473]
    __device_release_driver+0x1bb/0x2a0 [61811.451476] driver_detach+0xf3/0x140 [61811.451479] bus_remove_driver+0x6c/0xf0 [61811.451481] driver_unregister+0x31/0x60 [61811.451483] pci_unregister_driver+0x40/0x90 [61811.451486] amdgpu_exit+0x15/0x447 [amdgpu] 对于 smu v13_0_2如果 GPU 支持 xgmi请参阅提交 f5c7e7797060drm/amdgpu调整 smu v13_0_2 的移除控制流它会在移除时在 AMDGPU_RESET_FOR_DEVICE_REMOVE 模式下运行 gpu 恢复这使得 hive 列表中的所有设备除基本 ip 块外hw 重置但不恢复则其他 ip 块将不会根据 ip_block.status.hw 调用 .hw_fini。由于 psp_free_shared_bufs 仅包含一些软件操作因此将其移动到 psp_sw_fini。 (CVE-2023-53152)

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

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

  scsistorvsc修复虚拟光纤通道超时的处理 Hyper-V 能够将光纤通道 LUN 连接到主机系统并将其在客户机 VM 中作为 SCSI 设备显示。vFC 设备的 I/O 由 storvsc 驱动程序处理。storvsc 驱动程序包含与在 Linux SCSI 子系统的通用部分中实现的 FC 传输的部分集成以便可以在 /sys 中显示 FC 属性。但是，部分集成意味着 vFC 的某些方面无法正常工作。
    遗憾的是由于 Hyper-V 为来宾机提供的内容存在限制无法进行完整且正确的集成。特别是在 Hyper-V storvsc 上下文中FC 传输超时函数 fc_eh_timed_out() 会导致内核错误因为它找不到 rport 并取消引用空指针。
    将 storvsc_eh_timed_out() 的调用添加到 fc_eh_timed_out() 的原始修补程序在这方面有错误。在许多情况下超时是由暂时性情况造成的因此这种情况可通过像处理 storvsc 发出的其他 I/O 请求一样继续等待并避免保证的错误来改善。对于永久失败继续等待可能导致挂起线程而不是错误该情况可能会更好。因此可通过删除对 fc_eh_timed_out() 的 storvsc 调用来修复错误。这允许 storvsc 继续等待响应。此变更已由在 fc_eh_timed_out() 中经历过由于暂时性超时而造成的错误的用户测试过其解决了他们的问题。将来我们可能想要弃用 storvsc 中的 vFC 功能因为无法完全修复。但它在当前用户中运行良好，因此它可能应该多保留一段时间。 (CVE-2023-53245)

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

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

  - 已修复 Linux 内核中的下列漏洞：vhost/vsock: Use kvmalloc/kvfree for larger packets. When copying a large file over sftp over vsock, data size is usually 32kB, and kmalloc seems to fail to try to allocate 32 32kB regions. vhost-5837: page allocation failure: order:4, mode:0x24040c0 Call Trace: [<ffffffffb6a0df64>] dump_stack+0x97/0xdb [<ffffffffb68d6aed>] warn_alloc_failed+0x10f/0x138 [<ffffffffb68d868a>] ? __alloc_pages_direct_compact+0x38/0xc8 [<ffffffffb664619f>] __alloc_pages_nodemask+0x84c/0x90d [<ffffffffb6646e56>] alloc_kmem_pages+0x17/0x19 [<ffffffffb6653a26>] kmalloc_order_trace+0x2b/0xdb [<ffffffffb66682f3>] __kmalloc+0x177/0x1f7 [<ffffffffb66e0d94>] ? copy_from_iter+0x8d/0x31d [<ffffffffc0689ab7>] vhost_vsock_handle_tx_kick+0x1fa/0x301 [vhost_vsock] [<ffffffffc06828d9>] vhost_worker+0xf7/0x157 [vhost] [<ffffffffb683ddce>] kthread+0xfd/0x105 [<ffffffffc06827e2>] ? vhost_dev_set_owner+0x22e/0x22e [vhost] [<ffffffffb683dcd1>] ? flush_kthread_worker+0xf3/0xf3 [<ffffffffb6eb332e>] ret_from_fork+0x4e/0x80 [<ffffffffb683dcd1>] ? flush_kthread_worker+0xf3/0xf3 Work around by doing kvmalloc instead.
    (CVE-2022-50271)

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

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

  - coresight修复 acpi_buffer->pointer 中的内存泄漏kmemleak 报告内存泄漏...
    未引用的对象 0xffff00213c141000 (大小 1024): comm systemd-udevd, pid 2123, jiffies 4294909467 (age 6062.160s) 十六进制转储 (前 32 字节): 04 00 00 00 02 00 00 00 18 10 14 3c 21 00 ff ff ... ......
    [<000000004b7c9001>] __kmem_cache_alloc_node+0x2f8/0x348 [<00000000b0fc7ceb>] __kmalloc+0x58/0x108 [<0000000064ff4695>] acpi_os_allocate+0x2c/0x68 [<000000007d57d116>] acpi_ut_initialize_buffer+0x54/0xe0 [<0000000024583908>] acpi_evaluate_object+0x388/0x438 [<0000000017b2e72b> ] acvalued +0xe8/0x240 [<000000005df0eac2>] coresight_get_platform_data+0x1b4/0x988 [coresight] ... 应释放 ACPI 缓冲区内存 (buf.pointer)。但从 acpi_get_dsd_graph() 返回之后也会使用该缓冲区。将临时变量 buf 移动到 acpi_coresight_parse_graph()并在函数返回之前将其释放以防止内存泄漏。 (CVE-2023-53261)

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

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

  - RDMA/bnxt_re回绕 mbox 生产者索引驱动程序未正确处理回绕 mbox 生产者索引。目前回绕会在达到 u32 max 后发生。生产者索引寄存器的第 31 位比较特殊只能在第一个命令中设置一次。由于生产者索引在很长时间后溢出设置 bit31因此 FW 会进入初始化序列这会造成 FW 挂起。修复是在 mbox 生产者索引达到 u16 最大值后回绕。 (CVE-2023-53201)

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

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

  - drm/amdgpu将 stub 隔离安装到可能未使用的隔离指针中使用 cpu 更新页面表时未使用 vm 更新隔离。将 stub fence 安装到这些 fence 指针而不是 NULL 中以避免在调用 dma_fence_wait() 时发生 NULL 取消引用。 (CVE-2023-53248)

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

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

  - mm修复 zswap 回写争用条件 zswap 回写机制可造成争用条件从而导致内存损坏即换出的页面被写入其他页面的数据换入。争用是这样展开的 1. 包含数据 A 和交换偏移 X 的页面存储在 zswap 中 2. 在 zswap-shrink 工作中zpool 驱动程序从 LRU 中删除页面 A 以进行回写zpool 驱动程序映射 A 的数据3 . 用户空间程序发生错误并使页面条目 A 无效偏移 X 被视为空闲 4. kswapd 在 zswap 中的偏移 X 处存储页面 Bzswap 也可能已满如果是这样页面 B 将被 IO 至 X然后跳过步骤 5 5. 在 tree->rbroot 中条目 A 被 B 替换这不影响 zswap-shrink 工作保留的本地引用 6. zswap-shrink 工作在 X 处写回 A并释放 zswap 条目 A 7. swapin的插槽 X 将 A 引入内存而不是 B 修复分配交换页面缓存后情况 ZSWAP_SWAPCACHE_NEWzswap-shrink 工作仅检查本地 zswap_entry 引用是否仍与树中的引用相同。如果不同则表示已无效或已替换在这两种情况下回写都会中止因为本地条目包含过时数据。Re生产者：我最初是通过夜间运行“stress”以验证我在 zswap 回写机制上的工作时发现此问题的，该问题在几小时后才会出现在我的测试计算机上。实现此目的的关键是拥有 zswap 回写因此无论设置 pump /sys/kernel/debug/zswap/written_back_pages 都可以实现此目的。为了在虚拟机上更快地重现此问题，我设置了一个具有 ~100M 可用内存和 500M 交换文件的系统，然后运行“stress --vm 1 --vm-bytes 300000000 --vm-stride 4000”，此问题在大约数十分钟内完成。通过在例如 20 和 1 之间向上和向下移动 /sys/module/zswap/parameters/max_pool_percent可以进一步加快处理速度这会使其在数十秒内重现。将 `--vm-stride` 设置为 4096 以外的其他选项这一点至关重要，否则 `stress` 将无法意识到内存已损坏，因为所有页面都将具有相同的数据。 (CVE-2023-53178)

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

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

  - 在 1618ca7 之前的 GNU Guix 的 guix-daemon 中可写入 content-addressed-mirrors 文件以创建 setuid 程序允许常规用户获取运行它的构建用户的权限即使在构建结束后。 (CVE-2025-59378)

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

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

  - # Active Storage 允许可能不安全的转换方法 Active Storage 默认尝试阻止使用可能不安全的图像转换方法和参数。默认允许列表包含三种可避开安全默认设置的方法，在用户任意提供的输入被接受为有效转换方法或参数的情况下这可能导致命令注入漏洞。影响 ------ 此漏洞会影响使用 Active Storage 和 image_processing 处理 gem以及 mini_magick 作为图像处理器的应用程序。存在漏洞的代码将如下所示如下所示 <%= image_tag blob.variant(params[:t] => params[:v]) %> " 其中转换方法或其参数为不受信任的任意输入。所有运行受影响版本的用户应立即升级或使用其中一个变通方案。变通方案 ----------- 使用用户提供的输入作为图像转换方法或其参数是不受支持的行为且应将其视为危险。应对用户提供的方法和参数执行严格的验证并部署强大的 [ImageMagick 安全策略](https://imagemagick.org/script/security-policy.php)。致谢 ------- 感谢 [lio346](https://hackerone.com/lio346) 报告此问题(CVE-2025-24293)

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

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

  - Angular 是一个开发平台，用于使用 TypeScript/JavaScript 和其他语言构建移动和桌面 Web 应用程序。Angular 在服务器端渲染期间使用 DI 容器平台注入器来保存请求特定的状态。由于历史原因容器被存储为 JavaScript 模块范围的全局变量。当同时处理多个请求时这些请求可能会无意间共享或覆盖全局注入器状态。实际上这可能导致一个请求使用针对完全不同请求的数据进行响应从而泄漏所呈现页面或响应标头中包含的数据或标记。只要攻击者拥有网络访问权限以发送任何收到已呈现响应的流量就可能发送大量请求然后检查响应是否存在信息泄漏。API“bootstrapApplication”、“getPlatform”和“destroyPlatform”容易受到攻击且仅需要 SSR 重大更改。所有有效版本以及 v21 预发行版本中已修补此问题。修补后的程序包包括 `@angle/platform-server` 21.0.0-next.3、 20.3.0、 19.2.15和 18.2.14 以及 `@angle/ssr` 21.0.0-next.3、 20.3.0、 19.2.16和 18.2.21。有多个变通方案可用。通过服务器路由或构建器选项禁用 SSR、删除自定义“bootstrap”函数中的任何异步行为、删除应用程序代码中对“getPlatform()”的使用和/或确保服务器版本将“ngJitMode”定义为 false。 (CVE-2025-59052)

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

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

  - Android 版、Linux 版、ChromeOS 版 Google Chrome 140.0.7339.127 之前版本的 Mojo 中存在不当实现漏洞，远程攻击者可利用此漏洞，通过构建的 HTML 页面绕过网站隔离策略。（Chromium 安全严重性：
    高）(CVE-2025-10201)

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

在远程主机上检测到 Dell Data Domain 操作系统的 Web 界面。

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

  - 桌面版 Google Chrome 140.0.7339.127 之前版本的 Serviceworker 中存在释放后使用漏洞，远程攻击者可能利用此漏洞，通过构建的 HTML 页面来利用堆损坏。（Chromium 安全严重性：
    严重）(CVE-2025-10200)

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

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

  - curl 的 websocket 代码未按照规范所述更新每个新传出帧的 32 位掩码模式。而是使用在整个连接过程中持续使用的固定掩码。可预测的掩码模式允许恶意服务器在两个通信方之间引发流量这些流量可被所涉及的代理配置或透明解释为真实、真实的 HTTP 流量内容并因此使其缓存中毒。然后可以将该缓存的中毒内容提供给该代理的所有用户。 (CVE-2025-10148)

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

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

  1. 使用“https://target` ”的“secure”关键词设置 Cookie。2.使用相同的 Cookie 集 curl 被重定向到“http://target` ”或与之对话“[]”相同主机名，但使用明文 HTTP。
    设置相同的 Cookie 名称 - 但仅使用斜线作为路径(`path=\/\,`)。由于此站点不安全**应*只是忽略 cookie。 4. 路径比较逻辑中的缺陷造成 curl 读取堆缓冲区边界之外该缺陷要么造成崩溃要么可能使比较得出错误的结论并让明文站点违背安全 Cookie 的内容与预期不同 并取决于紧接着用于保存路径的单字节分配的内存内容。默认且正确的行为为忽略第二组 Cookie，因为已在安全主机上将其设置为安全的，因此不应在不安全的主机上替代该 Cookie。 (CVE-2025-9086)

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

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

  - 当 Shibboleth 服务提供商 (SP) 的重放缓存配置为使用 SQL 数据库作为存储服务时在 SAML 响应的 ID 属性中发现了 SQL 注入漏洞。未经身份验证的攻击者可通过 SQL 盲注利用此问题从而允许从数据库提取任意数据如果数据库连接配置为使用 ODBC 插件。漏洞由 SQLString 类中的单引号转义不充分文件 odbc-store.cpp第 253-271行引起。此问题通过 Shibboleth Service Provider 3.5.0造成影响。
    (CVE-2025-9943)

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

远程主机上安装了业务分析解决方案 Oracle Essbase。

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

  - [此 CNA 信息记录与多个 CVE 相关文本说明了哪些方面/漏洞对应于哪个 CVE。] 存在多个与处理和访问 viridian 代码中客户机内存页面相关的问题 1. 更新引用 TSC 区域时出现空指针取消引用。这是 CVE-2025-27466。 2. 当必须提供合成定时器消息时假设已映射 SIM 页会导致空指针取消引用。这是 CVE-2025-58142。 3. 引用 TSC 页面的映射中存在争用客户机可使 Xen 释放某个页面同时该页面仍然存在于客户机物理到机器 (p2m) 页表中。这是 CVE-2025-58143。 (CVE-2025-58142)

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

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

  - 低于 1.0.3 版本的“sanitize-html”容易受到跨站脚本 (XSS) 的影响。“naughtyHref”函数未正确验证定位标记 (`<a>`) 中的超级引用 (`href`) 属性从而允许包含不同大小写、空白字符或十六进制编码的绕过。
    (CVE-2014-125128)

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

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

  - [此 CNA 信息记录与多个 CVE 相关文本说明了哪些方面/漏洞对应于哪个 CVE。] 存在多个与处理和访问 viridian 代码中客户机内存页面相关的问题 1. 更新引用 TSC 区域时出现空指针取消引用。这是 CVE-2025-27466。 2. 当必须提供合成定时器消息时假设已映射 SIM 页会导致空指针取消引用。这是 CVE-2025-58142。 3. 引用 TSC 页面的映射中存在争用客户机可使 Xen 释放某个页面同时该页面仍然存在于客户机物理到机器 (p2m) 页表中。这是 CVE-2025-58143。 (CVE-2025-27466)

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

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

  - 低于版本 2.0.0-beta 的“sanitize-html”容易受到跨站脚本 (XSS) 的影响。“index.js”中的“sanitizeHtml()”函数不会在使用自定义“transformTags”选项该选项用于将属性值转换为文本时不审查内容。因此可将恶意输入转换为可执行代码。 (CVE-2019-25225)

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

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

  - netgso当在包含扩展标头的 IPv6 数据包上执行 Generic Segmentation Offload (GSO) 时如果出口设备仅公告 NETIF_F_IPV6_CSUM 功能该功能具有严格的约定仅支持 IPv6 上的普通 TCP 或 UDP 的校验和卸载并且明确不支持具有扩展标头的数据包。当前 GSO 逻辑违反了此合同因为无法禁用具有扩展标头的数据包的功能如 GREoIPv6 隧道中使用的数据包。此违规导致设备被要求执行其不支持的操作从而导致“skb_warn_bad_offload”警告和网络吞吐量崩溃。虽然设备 TSO/USO 被正确绕过以支持这些数据包的软件 GSO但必须明确告知 GSO 堆栈不要请求校验和卸载。如果 IPv6 标头包含用于计算软件中的校验和的扩展标头则在 gso_features_check 中掩码 NETIF_F_IPV6_CSUM、NETIF_F_TSO6 和 NETIF_F_GSO_UDP_L4。BIG TCP 扩展是一个例外正如提交 68e068cabd2c6c53 (net重新启用 BIG TCP 数据包的 NETIF_F_IPV6_CSUM 卸载) 中所述 此功能仅在支持 BIG TCP TSO 的设备上启用。标头仅针对 PF_PACKET tap像 tcpdump 存在并且不会由物理设备传输。内核日志输出（已截断）WARNING: CPU: 1 PID: 5273 at net/core/dev.c:3535 skb_warn_bad_offload+0x81/0x140 ... Call Trace: <TASK> skb_checksum_help+0x12a/0x1f0 validate_xmit_skb+0x1a3/0x2d0 validate_xmit_skb_list+0x4f/0x80 sch_direct_xmit+0x1a2/0x380 __dev_xmit_skb+0x242/0x670 __dev_queue_xmit+0x3fc/0x7f0 ip6_finish_output2+0x25e/0x5d0 ip6_finish_output+0x1fc/0x3f0 ip6_tnl_xmit+0x608/0xc00 [ip6_tunnel] ip6gre_tunnel_xmit+0x1c0/0x390 [ip6_gre] dev_hard_start_xmit+0x63/0x1c0 __dev_queue_xmit+0x6d0/0x7f0 ip6_finish_output2+0x214/0x5d0 ip6_finish_output+0x1fc/0x3f0 ip6_xmit+0x2ca/0x6f0 ip6_finish_output+0x1fc/0x3f0 ip6_xmit+0x2ca/0x6f0 inet6_csk_xmit+0xeb/ 0x150
    __tcp_transmit_skb+0x555/0xa80 tcp_write_xmit+0x32a/0xe90 tcp_sendmsg_locked+0x437/0x1110 tcp_sendmsg+0x2f/0x50 ... skb linear: 00000000: e4 3d 1a 7d ec 30 e4 3d 1a 7e 5d 90 86 dd 60 0e skb linear: 00000010: 00 0a 1b 34 3c 40 20 11 00 00 00 00 00 00 00 00 skb linear: 00000020: 00 00 00 00 00 12 20 11 00 00 00 00 00 00 00 00 skb linear: 00000030: 00 00 00 00 00 11 2f 00 04 01 04 01 01 00 00 00 skb linear: 00000040: 86 dd 60 0e 00 0a 1b 00 06 40 20 23 00 00 00 00 skb linear: 00000050: 00 00 00 00 00 00 00 00 00 12 20 23 00 00 00 00 skb线性的 00000060: 00 00 00 00 00 00 00 00 00 11 bf 96 14 51 13 f9 skb 线性的 00000070: ae 27 a0 a8 2b e3 80 18 00 40 5b 6f 00 00 01 01 skb 4 04 02 04 da: 000 50 d5 4b 70 f8 1a (CVE-2025-39770)

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

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

  - 已修复 Linux 内核中的下列漏洞：bnxt_en: Fix lockdep warning during rmmod The commit under the Fixes tag added a netdev_assert_locked() in bnxt_free_ntp_fltrs(). The lock should be held during normal run-time but the assert will be triggered (see below) during bnxt_remove_one() which should not need the lock. The netdev is already unregistered by then. Fix it by calling netdev_assert_locked_or_invisible() which will not assert if the netdev is unregistered. WARNING:
    CPU: 5 PID: 2241 at ./include/net/netdev_lock.h:17 bnxt_free_ntp_fltrs+0xf8/0x100 [bnxt_en] Modules linked in: rpcrdma rdma_cm iw_cm ib_cm configfs ib_core bnxt_en(-) bridge stp llc x86_pkg_temp_thermal xfs tg3 [last unloaded: bnxt_re] CPU: 5 UID: 0 PID: 2241 Comm: rmmod Tainted: G S W 6.16.0 #2 PREEMPT(voluntary) Tainted: [S]=CPU_OUT_OF_SPEC, [W]=WARN Hardware name: Dell Inc. PowerEdge R730/072T6D, BIOS 2.4.3 01/17/2017 RIP: 0010:bnxt_free_ntp_fltrs+0xf8/0x100 [bnxt_en] Code: 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 48 8b 47 60 be ff ff ff ff 48 8d b8 28 0c 00 00 e8 d0 cf 41 c3 85 c0 0f 85 2e ff ff ff <0f> 0b e9 27 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 RSP: 0018:ffffa92082387da0 EFLAGS: 00010246 RAX:
    0000000000000000 RBX: ffff9e5b593d8000 RCX: 0000000000000001 RDX: 0000000000000001 RSI: ffffffff83dc9a70 RDI: ffffffff83e1a1cf RBP: ffff9e5b593d8c80 R08: 0000000000000000 R09: ffffffff8373a2b3 R10:
    000000008100009f R11: 0000000000000001 R12: 0000000000000001 R13: ffffffffc01c4478 R14: dead000000000122 R15: dead000000000100 FS: 00007f3a8a52c740(0000) GS:ffff9e631ad1c000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055bb289419c8 CR3: 000000011274e001 CR4: 00000000003706f0 Call Trace: <TASK> bnxt_remove_one+0x57/0x180 [bnxt_en] pci_device_remove+0x39/0xc0 device_release_driver_internal+0xa5/0x130 driver_detach+0x42/0x90 bus_remove_driver+0x61/0xc0 pci_unregister_driver+0x38/0x90 bnxt_exit+0xc/0x7d0 [bnxt_en] (CVE-2025-39769)

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

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

  - 已修复 Linux 内核中的下列漏洞：drm/hisilicon/hibmc: fix irq_request()'s irq name variable is local The local variable is passed in request_irq (), and there will be use after free problem, which will make request_irq failed. Using the global irq name instead of it to fix. (CVE-2025-39785)

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

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

  - rcu修复 IRQ 工作造成的 rcu_read_unlock() 死循环 在 rcu_read_unlock_special() 期间如果此问题发生在 irq_exit() 期间可在发出 IPI 时锁定。这是因为 IPI 本身会触发 irq_exit() 路径从而导致递归锁定。这正好是 Xiongfeng 在 trace_tick_stop() 跟踪点上调用 BPF 程序时发现的内容 如下面的跟踪代码所示。通过正确管理 irq_work 状态修复。 irq_exit() __irq_exit_rcu() /* in_hardirq() 此后将返回 false */ preempt_count_sub(HARDIRQ_OFFSET) tick_irq_exit() tick_nohz_irq_exit() tick_nohz_stop_sched_tick() trace_tick_stop() /* a bpf prog is hooked在此跟踪点上 */ __bpf_trace_trace_trace_stop() bpf_trace_trace_stop() () rcu_read_unlock_special() /* 将向其自身发送 IPI */ irq_work_queue_on(&rdp->defer_qs_iw, rdp->cpu);
    也可通过在 tick_irq_exit() 中执行以下操作来获得简单的重现程序。如果没有修补程序它将在引导时挂起 static inline void tick_irq_exit(void) { + rcu_read_lock(); + WRITE_ONCE(current->rcu_read_unlock_special.b.need_qs, true); + rcu_read_unlock(); + [neeraj应用 Frederic 建议的 PREEMPT_RT 补丁] (CVE-2025-39744

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

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

  - gfs2在 gfs2_{rgrp,meta}_aops 中设置 .migrate_folio 清除 7ee3647243e5 中添加的警告迁移
    删除对 ->writepage 的调用其在各种 xfstests 中发生进而导致某些在 dmesg 失败中找到。
    [ 341.136573] gfs2_meta_aops 未实现 migrate_folio [ 341.136953] 警告CPU:1 PID: 36 at mm/migrate.c:944 move_to_new_folio+0x2f8/0x300 (CVE-2025-39753)

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

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

  - net: bridge修复 br_multicast_query_expired() 中的软锁定将multicast_query_interval 设置为较大的值时br_multicast_send_query() 中的本地变量“time”可能溢出。如果该时间小于 jiffies定时器将立即到期然后再次调用 mod_timer()这样会造成循环并可能触发以下软锁定问题。 watchdog缺陷软锁定 - CPU#1 卡住达 221 秒[rb_consumer:66] CPU: 1 UID: 0 PID: 66 Comm: rb_consumer Not tainted 6.16.0+ #259 PREEMPT(none) 调用跟踪 <IRQ> __netdev_alloc_skb+0x2e/0x3a0 br_ip6_multicast_alloc_query+0x212/0x1b70
    __br_multicast_send_query+0x376/0xac0 br_multicast_send_query+0x299/0x510 br_multicast_query_expired.constprop.0+0x16d/0x1b0 call_timer_fn+0x3b/0x2a0 __run_timers+0x619/0x950 run_timer_softirq+0x11c/0x220 handle_softirqs+0x18e/0x560 __irq_exit_rcu+0x158/0x1a0 sysvec_apic_timer_interrupt+0x76/0x90 </IRQ> 此问题可通过 ip link add br0 type bridge echo 1 > /sys/class/net/br0/bridge/multicast_querier echo 0xffffffffffffffff > /sys/class/net/br0/bridge/multicast_query_interval ip link set dev br0 up multicast_startup_query_interval 也会导致此问题。与提交 99b40610956a 类似 (net
    bridgemcast添加并强制执行查询间隔最小值添加对查询间隔最大值的检查以修复此问题。 (CVE-2025-39773)

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

ID	名称	严重性
264933	Linux Distros 未修补的漏洞：CVE-2022-50331	medium
264932	Linux Distros 未修补的漏洞：CVE-2022-50312	medium
264931	Linux Distros 未修补的漏洞：CVE-2023-53231	medium
264930	Linux Distros 未修补的漏洞：CVE-2023-53185	medium
264929	Linux Distros 未修补的漏洞：CVE-2023-53186	medium
264928	Linux Distros 未修补的漏洞：CVE-2023-53200	medium
264927	Linux Distros 未修补的漏洞：CVE-2022-50251	medium
264926	Linux Distros 未修补的漏洞：CVE-2023-53225	medium
264925	Linux Distros 未修补的漏洞：CVE-2022-50335	medium
264924	Linux Distros 未修补的漏洞：CVE-2023-53196	medium
264923	Linux Distros 未修补的漏洞：CVE-2022-50308	medium
264922	Linux Distros 未修补的漏洞：CVE-2023-53176	medium
264921	Linux Distros 未修补的漏洞：CVE-2022-50276	medium
264920	Linux Distros 未修补的漏洞：CVE-2023-53235	high
264919	Linux Distros 未修补的漏洞：CVE-2022-50334	medium
264918	Linux Distros 未修补的漏洞：CVE-2023-53244	medium
264917	Linux Distros 未修补的漏洞：CVE-2022-50279	high
264916	Linux Distros 未修补的漏洞：CVE-2023-53215	high
264915	Linux Distros 未修补的漏洞：CVE-2023-53195	medium
264914	Linux Distros 未修补的漏洞：CVE-2022-50256	high
264913	Linux Distros 未修补的漏洞：CVE-2023-53247	medium
264912	Linux Distros 未修补的漏洞：CVE-2022-50320	high
264911	Linux Distros 未修补的漏洞：CVE-2023-53218	high
264910	Linux Distros 未修补的漏洞：CVE-2023-53152	medium
264909	Linux Distros 未修补的漏洞：CVE-2023-53245	medium
264908	Linux Distros 未修补的漏洞：CVE-2022-50271	medium
264907	Linux Distros 未修补的漏洞：CVE-2023-53261	medium
264906	Linux Distros 未修补的漏洞：CVE-2023-53201	medium
264905	Linux Distros 未修补的漏洞：CVE-2023-53248	medium
264904	Linux Distros 未修补的漏洞：CVE-2023-53178	medium
264903	Linux Distros 未修补的漏洞：CVE-2025-59378	medium
264902	Linux Distros 未修补的漏洞：CVE-2025-24293	critical
264809	Linux Distros 未修补的漏洞：CVE-2025-59052	high
264808	Linux Distros 未修补的漏洞：CVE-2025-10201	high
264807	Dell Data Domain 操作系统 Web 界面检测	info
264806	Linux Distros 未修补的漏洞：CVE-2025-10200	high
264805	Linux Distros 未修补的漏洞：CVE-2025-10148	medium
264804	Linux Distros 未修补的漏洞：CVE-2025-9086	high
264803	Linux Distros 未修补的漏洞：CVE-2025-9943	critical
264796	安装了 Oracle Essbase(Linux	info
264778	Linux Distros 未修补的漏洞：CVE-2025-58142	critical
264777	Linux Distros 未修补的漏洞：CVE-2014-125128	medium
264776	Linux Distros 未修补的漏洞：CVE-2025-27466	critical
264775	Linux Distros 未修补的漏洞：CVE-2019-25225	medium
264774	Linux Distros 未修补的漏洞：CVE-2025-39770	medium
264773	Linux Distros 未修补的漏洞：CVE-2025-39769	medium
264772	Linux Distros 未修补的漏洞：CVE-2025-39785	medium
264771	Linux Distros 未修补的漏洞：CVE-2025-39744	high
264770	Linux Distros 未修补的漏洞：CVE-2025-39753	medium
264769	Linux Distros 未修补的漏洞：CVE-2025-39773	medium

检测

Nessus 的 Misc. 系列

medium

medium

medium

medium

medium

medium

medium

medium

medium

medium

medium

medium

medium

high

medium

medium

high

high

medium

high

medium

high

high

medium

medium

medium

medium

medium

medium

medium

medium

critical

high

high

info

high

medium

high

critical

info

critical

medium

critical

medium

medium

medium

medium

high

medium

medium