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

  - dm cache修复 destroy() 中的 UAF 当 dm_resume() 和 dm_destroy() 并发时Dm_cache 也会存在相同的 UAF 问题。因此会在 destroy() 中再次取消定时器。 (CVE-2022-50496)

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

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

  - 已修复 Linux 内核中的下列漏洞：drm/i915: Make intel_get_crtc_new_encoder() less oopsy The point of the WARN was to print something, not oops straight up. Currently that is precisely what happens if we can't find the connector for the crtc in the atomic state. Get the dev pointer from the atomic state instead of the potentially NULL encoder to avoid that.
    (cherry picked from commit 3b6692357f70498f617ea1b31a0378070a0acf1c) (CVE-2023-53571)

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

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

  - hwmon(coretemp) 简化平台设备处理 Coretemp 的平台驱动程序是非常规。所有实际工作均由 initcall 和 CPU 热插拔通知程序全局完成而驱动程序实际上只是通过驱动程序核心将 hwmon 接口的分配和注册包装在冗长的往返中。动态创建和破坏平台设备以启动和关闭接口的整个逻辑容易错误因为它假定 platform_device_add() 将在其返回前同步绑定驱动程序并设置 drvdata因此在 drivers_autoprobe 关闭时导致空取消引用对于 平台总线。此外从 CPU 热插拔通知程序中执行此操作的异常方法已在其死锁暂停的代码中进行了注释这种方法也会造成其他可能希望从平台总线通知程序合法注册 CPU 热插拔通知程序的驱动程序或子系统发生 lockdep 问题。通过完全去除此异常行为、将平台设备与模块本身的使用期相关联然后直接从热插拔通知程序管理 hwmon 接口即可解决所有这些问题。有一个轻微的用户可见更改将不再出现 /sys/bus/platform/drivers/coretemp并且如果程序包 n 热插拔则 /sys/devices/platform/coretemp.n 将仍然存在但 hwmon 用户应实际上仅查找是否存在 hwmon 接口其行为保持不变。 (CVE-2023-53612)

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

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

  - 已修复 Linux 内核中的下列漏洞：bus: mhi: host: Range check CHDBOFF and ERDBOFF If the value read from the CHDBOFF and ERDBOFF registers is outside the range of the MHI register space then an invalid address might be computed which later causes a kernel panic. Range check the read value to prevent a crash due to bad data from the device. (CVE-2023-53598)

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

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

  - 已修复 Linux 内核中的下列漏洞：netfilter: ipset: Rework long task execution when adding/deleting entries When adding/deleting large number of elements in one step in ipset, it can take a reasonable amount of time and can result in soft lockup errors. The patch 5f7b51bf09ba (netfilter: ipset: Limit the maximal range of consecutive elements to add/delete) tried to fix it by limiting the max elements to process at all. However it was not enough, it is still possible that we get hung tasks. Lowering the limit is not reasonable, so the approach in this patch is as follows: rely on the method used at resizing sets and save the state when we reach a smaller internal batch limit, unlock/lock and proceed from the saved state. Thus we can avoid long continuous tasks and at the same time removed the limit to add/delete large number of elements in one step. The nfnl mutex is held during the whole operation which prevents one to issue other ipset commands in parallel. (CVE-2023-53549)

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

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

  - 已修复 Linux 内核中的下列漏洞：rtc: class: Fix potential memleak in devm_rtc_allocate_device() devm_rtc_allocate_device() will alloc a rtc_device first, and then run dev_set_name(). If dev_set_name() failed, the rtc_device will memleak. Move devm_add_action_or_reset() in front of dev_set_name() to prevent memleak. unreferenced object 0xffff888110a53000 (size 2048): comm python3, pid 470, jiffies 4296078308 (age 58.882s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 08 30 a5 10 81 88 ff ff .........0...... 08 30 a5 10 81 88 ff ff 00 00 00 00 00 00 00 00 .0..............
    backtrace: [<000000004aac0364>] kmalloc_trace+0x21/0x110 [<000000000ff02202>] devm_rtc_allocate_device+0xd4/0x400 [<000000001bdf5639>] devm_rtc_device_register+0x1a/0x80 [<00000000351bf81c>] rx4581_probe+0xdd/0x110 [rtc_rx4581] [<00000000f0eba0ae>] spi_probe+0xde/0x130 [<00000000bff89ee8>] really_probe+0x175/0x3f0 [<00000000128e8d84>] __driver_probe_device+0xe6/0x170 [<00000000ee5bf913>] device_driver_attach+0x32/0x80 [<00000000f3f28f92>] bind_store+0x10b/0x1a0 [<000000009ff812d8>] drv_attr_store+0x49/0x70 [<000000008139c323>] sysfs_kf_write+0x8d/0xb0 [<00000000b6146e01>] kernfs_fop_write_iter+0x214/0x2d0 [<00000000ecbe3895>] vfs_write+0x61a/0x7d0 [<00000000aa2196ea>] ksys_write+0xc8/0x190 [<0000000046a600f5>] do_syscall_64+0x37/0x90 [<00000000541a336f>] entry_SYSCALL_64_after_hwframe+0x63/0xcd (CVE-2022-50477)

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

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

  - scsitarget修复多个 LUN_RESET 处理 这修复了一个缺陷即发起程序认为 LUN_RESET 已清理了正在运行的命令但实际上它并未清理。缺陷已在提交 51ec502a3266 中添加目标先从处理前列表中删除 tmr。在以下情况下会发生此问题。 1. 在分布在 2 个会话的目标层中运行 NI/O cmd。 2. 发起程序为每个会话发送 LUN_RESET。 3. session1 的 LUN_RESET 会循环处理两个会话中正在运行的所有命令并将其移动到本地rain_task_list。 4.
    session2 的 LUN_RESET 没有看到来自 session1 的 LUN_RESET因为上述提交已使其自行删除。 session2 也没有看到任何命令，因为其他重置将这些命令从状态列表中删除。 5.
    session2 的 LUN_RESET 随后将完成并获得成功的响应。 6. session2 的发起程序认为由于响应成功其会话中正在运行的命令现已被清理并将从其端清理正在运行的命令。然后系统会重新启动这些 程序。 7. 命令最终会在后端完成，并且目标会开始返回其已中止的任务状态。如果 ITT 已被重新分配，发起程序将抛出无效的 ITT 错误或可能意外查找新任务。通过恢复 修补程序修复缺陷并且序列化 LUN_RESETs 及 Preempt 和 Aborts 的执行。还可防止等待 core_tmr_drain_tmr_list 中的 LUN_RESET因为事实证明原始修补程序修复了一个未提及的缺陷。由于 LUN_RESET1 core_tmr_drain_tmr_list 会发现第二个 LUN_RESET 并等待其发生。然后第二个重置将运行 core_tmr_drain_tmr_list 看到第一个重置并等待其导致死锁。 (CVE-2023-53586)

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

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

  - 已修复 Linux 内核中的下列漏洞：bpf: reject unhashed sockets in bpf_sk_assign The semantics for bpf_sk_assign are as follows: sk = some_lookup_func() bpf_sk_assign(skb, sk) bpf_sk_release(sk) That is, the sk is not consumed by bpf_sk_assign. The function therefore needs to make sure that sk lives long enough to be consumed from __inet_lookup_skb. The path through the stack for a TCPv4 packet is roughly: netif_receive_skb_core: takes RCU read lock __netif_receive_skb_core:
    sch_handle_ingress: tcf_classify: bpf_sk_assign() deliver_ptype_list_skb: deliver_skb:
    ip_packet_type->func == ip_rcv: ip_rcv_core: ip_rcv_finish_core: dst_input: ip_local_deliver:
    ip_local_deliver_finish: ip_protocol_deliver_rcu: tcp_v4_rcv: __inet_lookup_skb: skb_steal_sock The existing helper takes advantage of the fact that everything happens in the same RCU critical section: for sockets with SOCK_RCU_FREE set bpf_sk_assign never takes a reference. skb_steal_sock then checks SOCK_RCU_FREE again and does sock_put if necessary. This approach assumes that SOCK_RCU_FREE is never set on a sk between bpf_sk_assign and skb_steal_sock, but this invariant is violated by unhashed UDP sockets.
    A new UDP socket is created in TCP_CLOSE state but without SOCK_RCU_FREE set. That flag is only added in udp_lib_get_port() which happens when a socket is bound. When bpf_sk_assign was added it wasn't possible to access unhashed UDP sockets from BPF, so this wasn't a problem. This changed in commit 0c48eefae712 (sock_map: Lift socket state restriction for datagram sockets), but the helper wasn't adjusted accordingly. The following sequence of events will therefore lead to a refcount leak: 1. Add socket(AF_INET, SOCK_DGRAM) to a sockmap. 2. Pull socket out of sockmap and bpf_sk_assign it. Since SOCK_RCU_FREE is not set we increment the refcount. 3. bind() or connect() the socket, setting SOCK_RCU_FREE. 4. skb_steal_sock will now set refcounted = false due to SOCK_RCU_FREE. 5. tcp_v4_rcv() skips sock_put(). Fix the problem by rejecting unhashed sockets in bpf_sk_assign(). This matches the behaviour of __inet_lookup_skb which is ultimately the goal of bpf_sk_assign(). (CVE-2023-53585)

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

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

  - 已修复 Linux 内核中的下列漏洞：drm/i915: mark requests for GuC virtual engines to avoid use-after-free References to i915_requests may be trapped by userspace inside a sync_file or dmabuf (dma-resv) and held indefinitely across different proceses. To counter-act the memory leaks, we try to not to keep references from the request past their completion. On the other side on fence release we need to know if rq->engine is valid and points to hw engine (true for non-virtual requests). To make it possible extra bit has been added to rq->execution_mask, for marking virtual engines. (cherry picked from commit 280410677af763f3871b93e794a199cfcf6fb580) (CVE-2023-53552)

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

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

  - binfmt_misc修复 check_special_flags 中的位移越界 UBSAN 报告了位移越界警告
    “int”类型调用跟踪中无法表示左移 1 x 31 位 <TASK> __dump_stack lib/dump_stack.c:88 [内联] dump_stack_lvl+0x8d/0xcf lib/dump_stack.c:106 ubsan_epilogue+0xa/0x44 lib/ ubsan.c:151 __ubsan_handle_shift_out_of_bounds+0x1e7/0x208 lib/ubsan.c:322 check_special_flags fs/binfmt_misc.c:241 [内联] create_entry fs/binfmt_misc.c:456 [内联] bm_register_write+0x9d3/0xa20 fs/binfmt_misc.c: 654 vfs_write+0x11e/0x580 fs/read_write.c:582 ksys_write+0xcf/0x120 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x34/0x80 arch/x86/entry /common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x4194e1 由于节点的标记类型为无符号长整型因此也应使用相同类型定义这些宏。 (CVE-2022-50497)

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

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

  - 已修复 Linux 内核中的下列漏洞：RDMA/core: Make sure ib_port is valid when access sysfs node The ib_port structure must be set before adding the sysfs kobject, and reset after removing it, otherwise it may crash when accessing the sysfs node: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000050 Mem abort info: ESR = 0x96000006 Exception class = DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgdp = 00000000e85f5ba5 [0000000000000050] pgd=0000000848fd9003, pud=000000085b387003, pmd=0000000000000000 Internal error: Oops: 96000006 [#2] PREEMPT SMP Modules linked in: ib_umad(O) mlx5_ib(O) nfnetlink_cttimeout(E) nfnetlink(E) act_gact(E) cls_flower(E) sch_ingress(E) openvswitch(E) nsh(E) nf_nat_ipv6(E) nf_nat_ipv4(E) nf_conncount(E) nf_nat(E) nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) mst_pciconf(O) ipmi_devintf(E) ipmi_msghandler(E) ipmb_dev_int(OE) mlx5_core(O) mlxfw(O) mlxdevm(O) auxiliary(O) ib_uverbs(O) ib_core(O) mlx_compat(O) psample(E) sbsa_gwdt(E) uio_pdrv_genirq(E) uio(E) mlxbf_pmc(OE) mlxbf_gige(OE) mlxbf_tmfifo(OE) gpio_mlxbf2(OE) pwr_mlxbf(OE) mlx_trio(OE) i2c_mlxbf(OE) mlx_bootctl(OE) bluefield_edac(OE) knem(O) ip_tables(E) ipv6(E) crc_ccitt(E) [last unloaded: mst_pci] Process grep (pid: 3372, stack limit = 0x0000000022055c92) CPU: 5 PID: 3372 Comm: grep Tainted: G D OE 4.19.161-mlnx.47.gadcd9e3 #1 Hardware name: https://www.mellanox.com BlueField SoC/BlueField SoC, BIOS BlueField:3.9.2-15-ga2403ab Sep 8 2022 pstate: 40000005 (nZcv daif -PAN -UAO) pc : hw_stat_port_show+0x4c/0x80 [ib_core] lr :
    port_attr_show+0x40/0x58 [ib_core] sp : ffff000029f43b50 x29: ffff000029f43b50 x28: 0000000019375000 x27:
    ffff8007b821a540 x26: ffff000029f43e30 x25: 0000000000008000 x24: ffff000000eaa958 x23: 0000000000001000 x22: ffff8007a4ce3000 x21: ffff8007baff8000 x20: ffff8007b9066ac0 x19: ffff8007bae97578 x18:
    0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 :
    0000000000000000 x8 : ffff8007a4ce4000 x7 : 0000000000000000 x6 : 000000000000003f x5 : ffff000000e6a280 x4 : ffff8007a4ce3000 x3 : 0000000000000000 x2 : aaaaaaaaaaaaaaab x1 : ffff8007b9066a10 x0 :
    ffff8007baff8000 Call trace: hw_stat_port_show+0x4c/0x80 [ib_core] port_attr_show+0x40/0x58 [ib_core] sysfs_kf_seq_show+0x8c/0x150 kernfs_seq_show+0x44/0x50 seq_read+0x1b4/0x45c kernfs_fop_read+0x148/0x1d8
    __vfs_read+0x58/0x180 vfs_read+0x94/0x154 ksys_read+0x68/0xd8 __arm64_sys_read+0x28/0x34 el0_svc_common+0x88/0x18c el0_svc_handler+0x78/0x94 el0_svc+0x8/0xe8 Code: f2955562 aa1603e4 aa1503e0 f9405683 (f9402861) (CVE-2022-50475)

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

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

  - 已修复 Linux 内核中的下列漏洞：vdpa: Add max vqp attr to vdpa_nl_policy for nlattr length check The vdpa_nl_policy structure is used to validate the nlattr when parsing the incoming nlmsg. It will ensure the attribute being described produces a valid nlattr pointer in info->attrs before entering into each handler in vdpa_nl_ops. That is to say, the missing part in vdpa_nl_policy may lead to illegal nlattr after parsing, which could lead to OOB read just like CVE-2023-3773. This patch adds the missing nla_policy for vdpa max vqp attr to avoid such bugs.
    (CVE-2023-53543)

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

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

  - ALSAusb-audio修复潜在的内存泄漏当驱动程序在分配 URB 或缓冲区时命中 -ENOMEM 时它将中止并进入错误路径该路径会释放所有以前分配的资源。但是，当
    -ENOMEM 在同步 EP URB 分配循环的中间命中则部分分配的 URB 可能未释放因为 ep->nurbs 此时仍为零。通过首先设置 ep->nurbs以便错误处理程序在完整的 URB 列表上循环来修复此问题。 (CVE-2022-50484)

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

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

  - netwwaniosm修复删除设备时发生的空指针取消引用在暂停和恢复周期中删除和重新扫描设备会导致空指针取消引用。在驱动程序初始化期间如果 ipc_imem_wwan_channel_init() 无法获得有效的设备功能它会返回错误并且不会分配任何资源wwan struct。现在在这种情况下如果启动驱动程序删除程序则会导致空指针异常因为在 ipc_wwan_deinit() 内部取消引用未分配的 wwan struct。 ipc_imem_run_state_worker() 处理被调用函数的返回值并在失败时释放资源。它还会报告故障情况下的链路断开事件。用户空间应用程序可以处理此事件以执行设备重置从而恢复设备通信。
    (CVE-2023-53561)

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

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

  - 已修复 Linux 内核中的下列漏洞：fprobe: Release rethook after the ftrace_ops is unregistered While running bpf selftests it's possible to get following fault: general protection fault, probably for non-canonical address \ 0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC NOPTI ... Call Trace: <TASK> fprobe_handler+0xc1/0x270 ? __pfx_bpf_testmod_init+0x10/0x10 ? __pfx_bpf_testmod_init+0x10/0x10 ? bpf_fentry_test1+0x5/0x10 ? bpf_fentry_test1+0x5/0x10 ? bpf_testmod_init+0x22/0x80 ? do_one_initcall+0x63/0x2e0 ? rcu_is_watching+0xd/0x40 ? kmalloc_trace+0xaf/0xc0 ? do_init_module+0x60/0x250 ? __do_sys_finit_module+0xac/0x120 ? do_syscall_64+0x37/0x90 ? entry_SYSCALL_64_after_hwframe+0x72/0xdc </TASK> In unregister_fprobe function we can't release fp->rethook while it's possible there are some of its users still running on another cpu.
    Moving rethook_free call after fp->ops is unregistered with unregister_ftrace_function call.
    (CVE-2023-53557)

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

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

  - netbcmgenet添加针对超大数据包的检查 可能偶尔从硬件中获得超大数据包这些数据包超过了用于分配 SKB 的标称 2KiB 缓冲区大小。添加早期检查可丢弃数据包以避免调用 skb_over_panic()并继续处理下一个数据包。 (CVE-2023-53535)

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

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

  - ring-buffer同步 IRQ 在缓冲区破坏前运作如果就在破坏之前将某些内容写入缓冲区则可能破坏缓冲区ringbuffer 会在 IRQ 工作运行之前运行，导致此 KASAN report (or a crash without KASAN): BUGKASAN: slab-use-after-free in irq_work_run_list+0x11a/0x13a Read of size 8 at addr 000000006d640a48 by task swapper/0 CPU: 0 PID: 0 Comm: swapper Tainted: GWO 6.3.0-rc1 #7 Stack: 60c4f20f 0c203d48 41b58ab3 60f224fc 600477fa 60f35687 60c4f20f 601273dd 00000008 6101eb00 6101eab0 615be548 Call Trace: [<60047a58>] show_stack+0x25e/0x282 [<60c609e0>] dump_stack_lvl+0x96 /0xfd [<60c50d4c>] print_report+0x1a7/0x5a8 [<603078d3>] kasan_report+0xc1/0xe9 [<60308950>]
    __asan_report_load8_noabort+0x1b/0x1d [<60232844>] irq_work_run_list+0x11a/0x13a [<602328b4>] irq_work_tick+0x24/0x34 [<6017f9dc>] update_process_times+0x162/0x196 [<6019f335>] tick_sched_handle+0x1a4/0x1c3 [[]0x1c3 [<6019fd9e>[]0x1c3 []0x1c3  0x1c3 []0x1c3 [<601812b9>]
    __hrtimer_run_queues.constprop.0+0x425/0x695 [<60182913>] hrtimer_interrupt+0x16c/0x2c4 [<600486a3>] um_timer+0x164/0x183 [...] 按任务分配 411save_stack_trace+0x99/0xb5 stack_trace_save+0x81/0x9b kasan_sdave_stack_save_save /0x54 kasan_set_track+0x34/0x3e kasan_save_alloc_info+0x25/0x28
    ____kasan_kmalloc+0x8b/0x97 __kasan_kmalloc+0x10/0x12 __kmalloc+0xb2/0xe8 load_elf_phdrs+0xee/0x182 [...] 有缺陷的地址属于 000000006d640800 的对象该对象属于大小为 1024 的 kmalloc-1k 缓存 有缺陷的地址位于584 字节位于已释放的 1024 字节区域内部 [000000006d640800、000000006d640c00) 添加适当的 irq_work_sync()以便在破坏缓冲区之前完成工作。在下面的修复标签中提交之前只有一个全局 IRQ 工作因此此问题不存在。 (CVE-2023-53587)

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

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

  - net/mlx5e锁定后检查 NOT_READY 标记状态 当前会在获得必要的锁定之前执行 NOT_READY 标记检查。当工作队列任务从 unready_flows 列表中同时删除流时可能出现争用条件从而导致从列表中双重删除和崩溃 [0]。通过将标记检查移动到由 uplink_priv->unready_flows_lock 保护的部分内修复 问题。 [0][44376.389654] 一般保护错误可能为非规范地址 0xdead000000000108: 0000 [#1] SMP [44376.391665] CPU7 PID59123 Commtc Not tainted 6.4.0-rc4+ #144376.392984] Hardware nameQEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [44376.395342] RIP
    0010mlx5e_tc_del_fdb_flow+0xb3/0x340 [mlx5_core] [44376.396857] Code00 48 8b b8 68 ce 02 00 e8 8a 4d 02 00 4c 8d a8 a8 01 00 00 4c 89 ef e8 8b 79 88 00 83 98 8b 00 48 8b 93 90 06 00 00 <48> 89 42 08 48 89 10 48 b8 00 01 00 00 00 00 ad de 48 89 83 90 06 [44376.399167] RSP: 0018:ffff88812cc97570 EFLAGS
    00010246 [44376.399680] RAX: dead000000000122 RBX: ffff8881088e3800 RCX: ffff8881881bac00 [44376.400337] RDX: dead000000000100 RSI: ffff88812cc97500 RDI: ffff8881242f71b0 [44376.401001] RBP: ffff88811cbb0940 R08: 0000000000000400 R09: 0000000000000001 [44376.401663] R10: 0000000000000001 R11: 0000000000000000 R12: ffff88812c944000 [44376.402342] R13: ffff8881242f71a8 R14: ffff8881222b4000 R15: 0000000000000000 [44376.402999] FS: 00007f0451104800(0000) GS:ffff88852cb80000(0000) knlGS:0000000000000000 [44376.403787] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [44376.404343] CR2: 0000000000489108 CR3:
    0000000123a79003 CR4: 0000000000370ea0 [44376.405004] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
    0000000000000000 [44376.405665] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [44376.406339] 调用跟踪 [44376.406651] <TASK> [44376.406939] ? die_addr+0x33/0x90 [44376.407311] ? exc_general_protection+0x192/0x390 [44376.407795] ? asm_exc_general_protection+0x22/0x30 [44376.408292] ? mlx5e_tc_del_fdb_flow+0xb3/0x340 [mlx5_core] [44376.408876] __mlx5e_tc_del_fdb_peer_flow+0xbc/0xe0 [mlx5_core] [44376.409482] mlx5e_tc_del_flow+0x42/0x210 [mlx5_core] [44376.410055] mlx5e_flow_put+0x25/0x50 [mlx5_core] [44376.410529] mlx5e_delete_flower+ 0x24b/0x350 [mlx5_core] [44376.411043] tc_setup_cb_reoffload+0x22/0x80 [44376.411462] fl_reoffload+0x261/0x2f0 [cls_Flower] [44376.411907] ? mlx5e_rep_indr_setup_ft_cb+0x160/0x160 [mlx5_core] [44376.412481] ? mlx5e_rep_indr_setup_ft_cb+0x160/0x160 [mlx5_core] [44376.413044] tcf_block_playback_offloads+0x76/0x170 [44376.413497] tcf_block_unbind+0x7b/0xd0 [[] ] tcf_block_setup+0x17d/0x1c0 [44376.413881] tcf_block_playback_offloads+0x76/0x170 [[] ] tcf_block_setup+0x17d/0x1c0 [44376.41472544376.414269] tcf_block_playback_offloads+0x76/0x170  tcf_block_offload_unbind+0x43/0x70 [44376.415153]
    __tcf_block_put+0x82/0x150 [44376.415532] ingress_destroy+0x22/0x30 [sch_ingress] [44376.415986] qdisc_destroy+0x3b/0xd0 [44376.416343] qdisc_graft+0x4d0/0x620 [44376.416706] tc_get_qdisc+0x1c9/0x3b0 [44376.417074] rtnet+msglink 0x29c/0x390 [44376.419978] rep_movs_alternative+0x3a/0xa0 [44376.420399] ? rtnl_calcit.isra.0+0x120/0x120 [44376.420813] netlink_rcv_skb+0x54/0x100 [44376.421192] netlink_unicast+0x1f6/0x2c0 [44376.421573] netlink_sendmsg+0x232/0x4a0 [44376.421980] sock_sendmsg+0x38/0x60 [44376.422328]____sys_sendmsg +0x1d0/0x1e0 [44376.422709] ? copy_msghdr_from_user+0x6d/0xa0 [44376.423127] ___sys_sendmsg+0x80/0xc0 [44376.423495] ?
    ___sys_recvmsg+0x8b/0xc0 [44376.423869] __sys_sendmsg+0x51/0x90 [44376.424226] do_syscall_64+0x3d/0x90 [44376.424587] entry_SYSCALL_64_after_hwframe+0x46/0xb0 [44376.425046] RIP: 0033:0x7f045134f887 [44376.425403] 0a 代码 f70 d8 64 89 02 48 c7 c0 ff ff ff ff eb b9 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2e 00 ---truncated--- (CVE-2023-53581)

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

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

  - 已修复 Linux 内核中的下列漏洞：netfilter: nft_set_rbtree: fix null deref on element insertion There is no guarantee that rb_prev() will not return NULL in nft_rbtree_gc_elem(): general protection fault, probably for non-canonical address 0xdffffc0000000003:
    0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] nft_add_set_elem+0x14b0/0x2990 nf_tables_newsetelem+0x528/0xb30 Furthermore, there is a possible use-after-free while iterating, 'node' can be free'd so we need to cache the next value to use.
    (CVE-2023-53566)

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

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

  - null_blk始终检查 configfs 中的队列模式设置确保检查 null_validate_conf() 中的设备队列模式并返回 NULL_Q_RQ 的错误因为我们不允许旧有 I/O 路径如果不使用此修补程序我们会在设置队列模式时发生 OOP将 configfs 设为 1下列是重现步骤- modprobe null_blk nr_devices=0 mkdir config/nullb/nullb0 echo 1 > config/nullb/nullb0/memory_backed echo 4096 > config/nullb/nullb0/blocksize echo 20480 > config/nullb/nullb0 /size echo 1 > config/nullb/nullb0/queue_mode echo 1 > config/nullb/nullb0/power 在处理器 42 上输入 kdbcurrent=0xffff88810acdd080，pid 2372 Oops空因 oops @ 0xffffffffc041c329 CPU
    42 PID: 2372 Comm: sh 受感染: GON 6.3.0-rc5lblk+ #5 硬件名称 QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01 /2014 RIP
    0010null_add_dev.part.0+0xd9/0x720 [null_blk] 代码01 00 00 85 d2 0f 85 a1 03 00 00 48 83 bb 08 01 00 00 00 0f 85 f7 03 00 00 80 bb 62 01 00 00 8b 00 48 8b 75 20 0f 85 6d 02 00 00 <48> 89 6e 60 48 8b 75 20 bf 06 00 00 00 e8 f5 37 2c c1 48 8b 75 20 RSP0018:ffffc900052cbde0 EFLAGS: 00010240 RAX000000000000
    ffff88811084d800 RCX: 0000000000000001 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888100042e00 RBP: ffff8881053d8200 R08: ffffc900052cbd68 R09: ffff888105db2000 R10: 0000000000000001 R11:
     R120000000000000000  : 0000000000000002 R13: ffff888104765200 R14: ffff88810eec1748 R15: ffff88810eec1740 FS: 00007fd445fd1740(0000) GS:ffff8897dfc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000060 CR3: 0000000166a00000 CR4: 0000000000350ee0 DR0
    ffffffff8437a488 DR1: ffffffff8437a489 DR2: ffffffff8437a48a DR3: ffffffff8437a48b DR6: 00000000ffff0ff0 DR7: 0000000000000400 Call Trace: <TASK> nullb_device_power_store+0xd1/0x120 [null_blk] configfs_write_iter+0xb4/0x120 vfs_write+0x2ba/0x3c0 ksys_write+0x5f/0xe0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe +0x72/0xdc RIP0033:0x7fd4460c57a7 代码0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 b08 01 10 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24 RSP: 002b:00007ffd3792a4a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007fd4460c57a7 RDX:
    0000000000000002 RSI: 000055b43c02e4c0 RDI: 0000000000000001 RBP: 000055b43c02e4c0 R08: 000000000000000a R09: 00007fd44615b4e0 R10: 00007fd44615b3e0 R11: 0000000000000246 R12: 0000000000000002 R13:
    00007fd446198520 R140000000000000002 R1500007fd446198700 </TASK> (CVE-2023-53576)

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

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

  - 已修复 Linux 内核中的下列漏洞：sctp: add a refcnt in sctp_stream_priorities to avoid a nested loop With this refcnt added in sctp_stream_priorities, we don't need to traverse all streams to check if the prio is used by other streams when freeing one stream's prio in sctp_sched_prio_free_sid(). This can avoid a nested loop (up to 65535 * 65535), which may cause a stuck as Ying reported: watchdog: BUG: soft lockup - CPU#23 stuck for 26s! [ksoftirqd/23:136] Call Trace: <TASK> sctp_sched_prio_free_sid+0xab/0x100 [sctp] sctp_stream_free_ext+0x64/0xa0 [sctp] sctp_stream_free+0x31/0x50 [sctp] sctp_association_free+0xa5/0x200 [sctp] Note that it doesn't need to use refcount_t type for this counter, as its accessing is always protected under the sock lock. v1->v2: - add a check in sctp_sched_prio_set to avoid the possible prio_head refcnt overflow. (CVE-2023-53590)

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

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

  - 已修复 Linux 内核中的下列漏洞：s390/zcrypt: don't leak memory if dev_set_name() fails When dev_set_name() fails, zcdn_create() doesn't free the newly allocated resources.
    Do it. (CVE-2023-53568)

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

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

  - 已修复 Linux 内核中的下列漏洞：blk-crypto: make blk_crypto_evict_key() more robust If blk_crypto_evict_key() sees that the key is still in-use (due to a bug) or that ->keyslot_evict failed, it currently just returns while leaving the key linked into the keyslot management structures. However, blk_crypto_evict_key() is only called in contexts such as inode eviction where failure is not an option. So actually the caller proceeds with freeing the blk_crypto_key regardless of the return value of blk_crypto_evict_key(). These two assumptions don't match, and the result is that there can be a use-after-free in blk_crypto_reprogram_all_keys() after one of these errors occurs. (Note, these errors *shouldn't* happen; we're just talking about what happens if they do anyway.) Fix this by making blk_crypto_evict_key() unlink the key from the keyslot management structures even on failure. Also improve some comments. (CVE-2023-53536)

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

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

  - 已修复 Linux 内核中的下列漏洞：iommu/amd: Fix pci device refcount leak in ppr_notifier() As comment of pci_get_domain_bus_and_slot() says, it returns a pci device with refcount increment, when finish using it, the caller must decrement the reference count by calling pci_dev_put(). So call it before returning from ppr_notifier() to avoid refcount leak. (CVE-2022-50505)

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

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

  - 已修复 Linux 内核中的下列漏洞：cpufreq: Init completion before kobject_init_and_add() In cpufreq_policy_alloc(), it will call uninitialed completion in cpufreq_sysfs_release() when kobject_init_and_add() fails. And that will cause a crash such as the following page fault in complete: BUG: unable to handle page fault for address: fffffffffffffff8 [..] RIP:
    0010:complete+0x98/0x1f0 [..] Call Trace: kobject_put+0x1be/0x4c0 cpufreq_online.cold+0xee/0x1fd cpufreq_add_dev+0x183/0x1e0 subsys_interface_register+0x3f5/0x4e0 cpufreq_register_driver+0x3b7/0x670 acpi_cpufreq_init+0x56c/0x1000 [acpi_cpufreq] do_one_initcall+0x13d/0x780 do_init_module+0x1c3/0x630 load_module+0x6e67/0x73b0 __do_sys_finit_module+0x181/0x240 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd (CVE-2022-50473)

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

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

  - dm 完整性调用 dm_integrity_init() 错误路径中的 kmem_cache_destroy() 否则如果 dm_register_target() 失败journal_io_cache 将泄漏。 (CVE-2023-53604)

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

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

  - 已修复 Linux 内核中的下列漏洞：wifi: brcmfmac: Check for probe() id argument being NULL The probe() id argument may be NULL in 2 scenarios: 1. brcmf_pcie_pm_leave_D3() calling brcmf_pcie_probe() to reprobe the device. 2. If a user tries to manually bind the driver from sysfs then the sdio / pcie / usb probe() function gets called with NULL as id argument. 1. Is being hit by users causing the following oops on resume and causing wifi to stop working: BUG: kernel NULL pointer dereference, address: 0000000000000018 <snip> Hardware name: Dell Inc. XPS 13 9350/0PWNCR, BIDS 1.13.0 02/10/2020 Workgueue: events_unbound async_run_entry_fn RIP: 0010:brcmf_pcie_probe+Ox16b/0x7a0 [brcmfmac] <snip> Call Trace: <TASK> brcmf_pcie_pm_leave_D3+0xc5/8x1a0 [brcmfmac be3b4cefca451e190fa35be8f00db1bbec293887] ? pci_pm_resume+0x5b/0xf0 ? pci_legacy_resume+0x80/0x80 dpm_run_callback+0x47/0x150 device_resume+0xa2/0x1f0 async_resume+0x1d/0x30 <snip> Fix this by checking for id being NULL. In the PCI and USB cases try a manual lookup of the id so that manually binding the driver through sysfs and more importantly brcmf_pcie_probe() on resume will work. For the SDIO case there is no helper to do a manual sdio_device_id lookup, so just directly error out on a NULL id there.
    (CVE-2023-53565)

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

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

  - 已修复 Linux 内核中的下列漏洞：HID: hyperv: avoid struct memcpy overrun warning A previous patch addressed the fortified memcpy warning for most builds, but I still see this one with gcc-9: In file included from include/linux/string.h:254, from drivers/hid/hid-hyperv.c:8: In function 'fortify_memcpy_chk', inlined from 'mousevsc_on_receive' at drivers/hid/hid-hyperv.c:272:3:
    include/linux/fortify-string.h:583:4: error: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning] 583 | __write_overflow_field(p_size_field, size); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ My guess is that the WARN_ON() itself is what confuses gcc, so it no longer sees that there is a correct range check. Rework the code in a way that helps readability and avoids the warning. (CVE-2023-53553)

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

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

  - netusbnet修复 usbnet_start_xmit/usb_submit_urb 中的警告 syzbot fuzzer 在 usbnet 驱动程序中发现一个问题usb 1-1BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 0 PID: 754 位于 drivers/usb/ core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504 模块中链接了 CPU
    0 PID754 Commkworker/0:2 未受感染 6.4.0-rc7-syzkaller-00014-g692b7dc87ca6 #0 硬件名称Google Google Compute Engine/Google Compute Engine、BIOS Google 05/27/2023 Workqueuemld mld_ifc_work RIP
    0010:usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504 代码7c 24 18 e8 2c b4 5b fb 48 8b 7c 24 18 e8 42 07 f0 fe 41 89 d8 44 89 e1 4c 89 ea 48 89 c6 48 c7 c7 a0 c9 fc 8a e8 5a 6f 23 fb <0f> 0b e9 58 f8 ff ff e8 fe b3 5b fb 48 81 c5 c0 05 00 00 e9 84 f7 RSP0018:ffffc9000463f568 EFLAGS: 00010086 RAX
    0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000 RDX: ffff88801eb28000 RSI: ffffffff814c03b7 RDI: 0000000000000001 RBP: ffff8881443b7190 R08: 0000000000000001 R09: 0000000000000000 R10:
     R110000000000000000  : 0000000000000001 R12: 0000000000000003 R13: ffff88802a77cb18 R14: 0000000000000003 R15: ffff888018262500 FS: 0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000556a99c15a18 CR3: 0000000028c71000 CR4: 0000000000350ef0 调用跟踪 <TASK> usbnet_start_xmit+0xfe5/0x2190 drivers/net/usb/usbnet.c:1453 __netdev_start_xmit include/linux/netdevice.h:4918 include/linux/netdev:linux/net_start 4932 [inline] xmit_one net/core/dev.c:3578 [inline] dev_hard_start_xmit+0x187/0x700 net/core/dev.c:3594 ... 此缺陷的原因是 usbnet 信任其探测例程在 driver_info 结构中接收的批量端点地址但是它没有检查这些端点是否实际存在以及具有预期的类型和方向。此补丁无非是添加此类检查。 (CVE-2023-53548)

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

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

  - 已修复 Linux 内核中的下列漏洞：clk: imx: scu: use _safe list iterator to avoid a use after free This loop is freeing clk so it needs to use list_for_each_entry_safe().
    Otherwise it dereferences a freed variable to get the next item on the loop. (CVE-2023-53572)

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

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

  - nfsd清除 COPY 代码路径中潜在的 nfsd_file refcount 泄漏nfsd4_copy 结构有两种不同的风格。其中一个嵌入在复合版本中，并直接用于同步复制。另一个在客户端结构中进行动态分配、引用计数和跟踪。对于嵌入式文件系统，清理仅涉及释放代表其保留的任何 nfsd_files。对于异步，清理的难度更大，我们需要将其从列表中出列、反哈希等操作。此代码中目前至少存在潜在的引用计数泄露。如果 kthread_create 调用失败则原始 nfsd4_copy 对象中的 src 和 dst nfsd_files 都会泄漏。此代码路径中的清理也有些奇怪。在异步复制情况下我们将拥有最多四个 nfsd_file 引用同时复制结构的两种风格均为 src 和 dst。
    它们都被放置在 nfsd4_do_async_copy 的末尾即使代表嵌入函数所保留的寿命比该结构的寿命长。对其进行更改以便始终在 nfsd4_copy 返回之前清除由嵌入式副本结构保留的 nfsd_file refs。重做 cleanup_async_copy 以同时处理帧内和帧内复制。
    消除 nfsd4_cleanup_intra_ssc因其现在无法执行操作。 (CVE-2023-53606)

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

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

  - drm/mipi-dsi删除主机时分离设备每当注销 MIPI-DSI 主机时mipi_dsi_host_unregister() 的代码就会循环当前在该总线上找到的每个设备并注销。
    但是，它不会首先将设备从总线分离，如果主机希望在设备分离时执行某些清理，则会导致各种资源泄漏。 (CVE-2022-50489)

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

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

  - ALSAymfpci修复探测函数中的 BUG_ON snd_dma_buffer.bytes 字段现已包含对齐的大小此 snd_BUG_ON() 未考虑在内从而导致以下情况[ 9.625915] ---------- --[ cut here ]------------ [ 9.633440] 警告CPU: 0 PID: 126 at sound/pci/ymfpci/ymfpci_main.c:2168 snd_ymfpci_create+0x681/0x698 [snd_ymfpci] 9.648926[  ] Modules linked in: snd_ymfpci(+) snd_intel_dspcfg kvm(+) snd_intel_sdw_acpi snd_ac97_codec snd_mpu401_uart snd_opl3_lib irqbypass snd_hda_codec gameport snd_rawmidi crct10dif_pclmul crc32_pclmul cfg80211 snd_hda_core polyval_clmulni polyval_generic gf128mul snd_seq_device ghash_clmulni_intel snd_hwdep ac97_bus sha512_ssse3 rfkill snd_pcm aesni_intel tg3 snd_timer crypto_simd snd mxm_wmi libphy cryptd k10temp fam15h_power pcspkr soundcore sp5100_tco wmi acpi_cpufreq mac_hid dm_multipath sg loop fuse dm_mod bpf_preload ip_tables x_tables ext4 crc32c_generic crc16 mbcache jbd2 sr_mod cdrom ata_generic patcha_acpi firewire_ohci crc32c_intel firewire_cor e xhci_pci crc_itu_t patcha_via xhci_pci_renesas floppy [ 9.711849] CPU: 0 PID: 126 Comm: kworker/0:2 Not tainted 6.1.21-1-lts #1 08d2e5ece03136efa7c6aeea9a9c40916b1bd8da [ 9.722200] 硬件名称由 OEM 填写
    即将由 OEM/990FXExtreme4、BIOS P2.70 06/05/2014 填充 [ 9.732204] Workqueue事件 work_for_cpu_fn [ 9.736580] RIP0010:snd_ymfpci_create+0x681/0x698 [snd_ymfpci] [ 9.742594] 代码8c c0 4c 89 e2 48 89 df 48 c7 c6 92 c6 8c c0 e8 15 d0 e9 ff 48 83 c4 08 44 89 e8 5b 5d 41 5c 41 5d 41 5e 41 5f e9 d3 7a 33 e3 <0f> 0b e9 cb fd ff ff 41 bd ff ff 41 fb ff ff ff eb db 41 bd f4 ff ff ff eb [ 9.761358] RSP: 0018:ffffab64804e7da0 EFLAGS: 00010287 [ 9.766594] RAX: ffff8fa2df06c400 RBX: ffff8fa3073a8000 RCX: ffff8fa303fbc4a8 [ 9.773734] RDX: ffff8fa2df06d000 RSI: 0000000000000010 RDI: 0000000000000020 [ 9.780876] RBPffff8fa300b5d0d0 R08
    ffff8fa3073a8e50 R0900000000df06bf00 [ 9.788018] R10ffff8fa2df06bf00 R1100000000df068200 R12
    ffff8fa3073a8918 [ 9.795159] R13: 0000000000000000 R14: 0000000000000080 R15: ffff8fa2df068200 [ 9.802317] FS: 0000000000000000(0000) GS:ffff8fa9fec00000(0000) knlGS:0000000000000000 [ 9.810414] CS: 0010 DS: 0000 ES: 0000 CR0 0000000080050033 [ 9.816158] CR2: 000055febaf66500 CR3: 0000000101a2e000 CR4:
    00000000000406f0 [ 9.823301] 调用跟踪[ 9.825747] <TASK> [ 9.827889] snd_card_ymfpci_probe+0x194/0x950 [snd_ymfpci b78a5fe64b5663a6390a909c67808567e3e73615] [ 9.837030] ? finish_task_switch.isra.0+0x90/0x2d0 [9.841918] local_pci_probe+0x45/0x80 [ 9.845680] work_for_cpu_fn+0x1a/0x30 [ 9.849431] process_one_work+0x1c7/0x380 [ 9.853464] work_thread+0x1af/0x390 [ 9.857225] ? rescuer_thread+0x3b0/0x3b0 [ 9.861254] kthread+0xde/0x110 [ 9.864414] ? kthread_complete_and_exit+0x20/0x20 [ 9.869210] ret_from_fork+0x22/0x30 [ 9.872792] </TASK> [ 9.874985]
    ---[ 结束跟踪 0000000000000000]--- (CVE-2023-53607

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

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

  - scsi恢复 scsicore如果调度失败则不增加 scsi_device 的 iorequest_cnt scsi_queue_rq() 中的 atomic_inc(&cmd->device->iorequest_cnt) 将造成内核错误因为从 scsi_dispatch_cmd() 返回之后可能释放 cmd->device。这会恢复提交 cfee29ffb45b1c9798011b19d454637d1b0fe87d。 (CVE-2023-53609)

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

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

  - 已修复 Linux 内核中的下列漏洞：coresight: cti: Fix hang in cti_disable_hw() cti_enable_hw() and cti_disable_hw() are called from an atomic context so shouldn't use runtime PM because it can result in a sleep when communicating with firmware. Since commit 3c6656337852 (Revert firmware: arm_scmi: Add clock management to the SCMI power domain), this causes a hang on Juno when running the Perf Coresight tests or running this command: perf record -e cs_etm//u -- ls This was also missed until the revert commit because pm_runtime_put() was called with the wrong device until commit 692c9a499b28 (coresight: cti: Correct the parameter for pm_runtime_put) With lock and scheduler debugging enabled the following is output: coresight cti_sys0: cti_enable_hw -- dev:cti_sys0 parent:
    20020000.cti BUG: sleeping function called from invalid context at drivers/base/power/runtime.c:1151 in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 330, name: perf-exec preempt_count: 2, expected:
    0 RCU nest depth: 0, expected: 0 INFO: lockdep is turned off. irq event stamp: 0 hardirqs last enabled at (0): [<0000000000000000>] 0x0 hardirqs last disabled at (0): [<ffff80000822b394>] copy_process+0xa0c/0x1948 softirqs last enabled at (0): [<ffff80000822b394>] copy_process+0xa0c/0x1948 softirqs last disabled at (0): [<0000000000000000>] 0x0 CPU: 3 PID: 330 Comm: perf-exec Not tainted 6.0.0-00053-g042116d99298 #7 Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Sep 13 2022 Call trace: dump_backtrace+0x134/0x140 show_stack+0x20/0x58 dump_stack_lvl+0x8c/0xb8 dump_stack+0x18/0x34 __might_resched+0x180/0x228 __might_sleep+0x50/0x88
    __pm_runtime_resume+0xac/0xb0 cti_enable+0x44/0x120 coresight_control_assoc_ectdev+0xc0/0x150 coresight_enable_path+0xb4/0x288 etm_event_start+0x138/0x170 etm_event_add+0x48/0x70 event_sched_in.isra.122+0xb4/0x280 merge_sched_in+0x1fc/0x3d0 visit_groups_merge.constprop.137+0x16c/0x4b0 ctx_sched_in+0x114/0x1f0 perf_event_sched_in+0x60/0x90 ctx_resched+0x68/0xb0 perf_event_exec+0x138/0x508 begin_new_exec+0x52c/0xd40 load_elf_binary+0x6b8/0x17d0 bprm_execve+0x360/0x7f8 do_execveat_common.isra.47+0x218/0x238 __arm64_sys_execve+0x48/0x60 invoke_syscall+0x4c/0x110 el0_svc_common.constprop.4+0xfc/0x120 do_el0_svc+0x34/0xc0 el0_svc+0x40/0x98 el0t_64_sync_handler+0x98/0xc0 el0t_64_sync+0x170/0x174 Fix the issue by removing the runtime PM calls completely. They are not needed here because it must have already been done when building the path for a trace. [ Fix build warnings ] (CVE-2022-50491)

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

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

  - 已修复 Linux 内核中的下列漏洞：mm/damon/core: initialize damo_filter->list from damos_new_filter() damos_new_filter() is not initializing the list field of newly allocated filter object. However, DAMON sysfs interface and DAMON_RECLAIM are not initializing it after calling damos_new_filter(). As a result, accessing uninitialized memory is possible. Actually, adding multiple DAMOS filters via DAMON sysfs interface caused NULL pointer dereferencing. Initialize the field just after the allocation from damos_new_filter(). (CVE-2023-53555)

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

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

  - 已修复 Linux 内核中的下列漏洞：wifi: mt76: mt76x0: fix oob access in mt76x0_phy_get_target_power After 'commit ba45841ca5eb (wifi: mt76: mt76x02: simplify struct mt76x02_rate_power)', mt76x02 relies on ht[0-7] rate_power data for vht mcs{0,7}, while it uses vth[0-1] rate_power for vht mcs {8,9}. Fix a possible out-of-bound access in mt76x0_phy_get_target_power routine.
    (CVE-2022-50508)

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

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

  - ext4添加 EXT4_IGET_BAD 标记以防止意外的错误 inode 有许多地方会在 ext4_iget() 返回错误的 inode 时发生意外和崩溃。但是如果 iget 引导加载程序 inode则允许返回错误的 inode因为 inode 可能未初始化。可利用此机制绕过某些检查并造成错误。为解决此问题我们添加了一个特殊的 iget 标记 EXT4_IGET_BAD。只有使用此标记我们才会从 ext4_iget() 返回错误的 inode否则我们始终会在 inode 为错误 inode 时返回错误代码。由 Jan Kara 提议(CVE-2022-50485)

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

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

  - 已修复 Linux 内核中的下列漏洞：irqchip: Fix refcount leak in platform_irqchip_probe of_irq_find_parent() returns a node pointer with refcount incremented, We should use of_node_put() on it when not needed anymore. Add missing of_node_put() to avoid refcount leak.
    (CVE-2023-53610)

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

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

  - 已修复 Linux 内核中的下列漏洞：net/mlx5e: Fix deadlock in tc route query code Cited commit causes ABBA deadlock[0] when peer flows are created while holding the devcom rw semaphore. Due to peer flows offload implementation the lock is taken much higher up the call chain and there is no obvious way to easily fix the deadlock. Instead, since tc route query code needs the peer eswitch structure only to perform a lookup in xarray and doesn't perform any sleeping operations with it, refactor the code for lockless execution in following ways: - RCUify the devcom 'data' pointer. When resetting the pointer synchronously wait for RCU grace period before returning. This is fine since devcom is currently only used for synchronization of pairing/unpairing of eswitches which is rare and already expensive as-is. - Wrap all usages of 'paired' boolean in {READ|WRITE}_ONCE(). The flag has already been used in some unlocked contexts without proper annotations (e.g. users of mlx5_devcom_is_paired() function), but it wasn't an issue since all relevant code paths checked it again after obtaining the devcom semaphore. Now it is also used by mlx5_devcom_get_peer_data_rcu() as best effort check to return NULL when devcom is being unpaired. Note that while RCU read lock doesn't prevent the unpaired flag from being changed concurrently it still guarantees that reader can continue to use 'data'. - Refactor mlx5e_tc_query_route_vport() function to use new mlx5_devcom_get_peer_data_rcu() API which fixes the deadlock. [0]: [ 164.599612] ====================================================== [ 164.600142] WARNING:
    possible circular locking dependency detected [ 164.600667] 6.3.0-rc3+ #1 Not tainted [ 164.601021]
    ------------------------------------------------------ [ 164.601557] handler1/3456 is trying to acquire lock: [ 164.601998] ffff88811f1714b0 (&esw->offloads.encap_tbl_lock){+.+.}-{3:3}, at:
    mlx5e_attach_encap+0xd8/0x8b0 [mlx5_core] [ 164.603078] but task is already holding lock: [ 164.603617] ffff88810137fc98 (&comp->sem){++++}-{3:3}, at: mlx5_devcom_get_peer_data+0x37/0x80 [mlx5_core] [164.604459] which lock already depends on the new lock. [ 164.605190] the existing dependency chain (in reverse order) is: [ 164.605848] -> #1 (&comp->sem){++++}-{3:3}: [ 164.606380] down_read+0x39/0x50 [164.606772] mlx5_devcom_get_peer_data+0x37/0x80 [mlx5_core] [ 164.607336] mlx5e_tc_query_route_vport+0x86/0xc0 [mlx5_core] [ 164.607914] mlx5e_tc_tun_route_lookup+0x1a4/0x1d0 [mlx5_core] [ 164.608495] mlx5e_attach_decap_route+0xc6/0x1e0 [mlx5_core] [ 164.609063] mlx5e_tc_add_fdb_flow+0x1ea/0x360 [mlx5_core] [ 164.609627] __mlx5e_add_fdb_flow+0x2d2/0x430 [mlx5_core] [164.610175] mlx5e_configure_flower+0x952/0x1a20 [mlx5_core] [ 164.610741] tc_setup_cb_add+0xd4/0x200 [164.611146] fl_hw_replace_filter+0x14c/0x1f0 [cls_flower] [ 164.611661] fl_change+0xc95/0x18a0 [cls_flower] [ 164.612116] tc_new_tfilter+0x3fc/0xd20 [ 164.612516] rtnetlink_rcv_msg+0x418/0x5b0 [164.612936] netlink_rcv_skb+0x54/0x100 [ 164.613339] netlink_unicast+0x190/0x250 [ 164.613746] netlink_sendmsg+0x245/0x4a0 [ 164.614150] sock_sendmsg+0x38/0x60 [ 164.614522] ____sys_sendmsg+0x1d0/0x1e0 [ 164.614934] ___sys_sendmsg+0x80/0xc0 [ 164.615320] __sys_sendmsg+0x51/0x90 [ 164.615701] do_syscall_64+0x3d/0x90 [ 164.616083] entry_SYSCALL_64_after_hwframe+0x46/0xb0 [ 164.616568] -> #0 (&esw->offloads.encap_tbl_lock){+.+.}-{3:3}: [ 164.617210] __lock_acquire+0x159e/0x26e0 [ 164.617638] lock_acquire+0xc2/0x2a0 [ 164.618018] __mutex_lock+0x92/0xcd0 [ 164.618401] mlx5e_attach_encap+0xd8/0x8b0 [mlx5_core] [ 164.618943] post_process_attr+0x153/0x2d0 [ ---truncated--- (CVE-2023-53591)

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

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

  - 已修复 Linux 内核中的下列漏洞：eth: alx: take rtnl_lock on resume Zbynek reports that alx trips an rtnl assertion on resume: RTNL: assertion failed at net/core/dev.c (2891) RIP: 0010:netif_set_real_num_tx_queues+0x1ac/0x1c0 Call Trace: <TASK> __alx_open+0x230/0x570 [alx] alx_resume+0x54/0x80 [alx] ? pci_legacy_resume+0x80/0x80 dpm_run_callback+0x4a/0x150 device_resume+0x8b/0x190 async_resume+0x19/0x30 async_run_entry_fn+0x30/0x130 process_one_work+0x1e5/0x3b0 indeed the driver does not hold rtnl_lock during its internal close and re-open functions during suspend/resume. Note that this is not a huge bug as the driver implements its own locking, and does not implement changing the number of queues, but we need to silence the splat. (CVE-2022-50498)

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

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

  - drmamddisplay修复内存泄漏 此提交修复 dc_construct_ctx() 函数中的内存泄漏。
    (CVE-2023-53605)

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

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

  - 已修复 Linux 内核中的下列漏洞：net: qrtr: Fix an uninit variable access bug in qrtr_tx_resume() Syzbot reported a bug as following:
    ===================================================== BUG: KMSAN: uninit-value in qrtr_tx_resume+0x185/0x1f0 net/qrtr/af_qrtr.c:230 qrtr_tx_resume+0x185/0x1f0 net/qrtr/af_qrtr.c:230 qrtr_endpoint_post+0xf85/0x11b0 net/qrtr/af_qrtr.c:519 qrtr_tun_write_iter+0x270/0x400 net/qrtr/tun.c:108 call_write_iter include/linux/fs.h:2189 [inline] aio_write+0x63a/0x950 fs/aio.c:1600 io_submit_one+0x1d1c/0x3bf0 fs/aio.c:2019 __do_sys_io_submit fs/aio.c:2078 [inline]
    __se_sys_io_submit+0x293/0x770 fs/aio.c:2048 __x64_sys_io_submit+0x92/0xd0 fs/aio.c:2048 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Uninit was created at: slab_post_alloc_hook mm/slab.h:766 [inline] slab_alloc_node mm/slub.c:3452 [inline] __kmem_cache_alloc_node+0x71f/0xce0 mm/slub.c:3491
    __do_kmalloc_node mm/slab_common.c:967 [inline] __kmalloc_node_track_caller+0x114/0x3b0 mm/slab_common.c:988 kmalloc_reserve net/core/skbuff.c:492 [inline] __alloc_skb+0x3af/0x8f0 net/core/skbuff.c:565 __netdev_alloc_skb+0x120/0x7d0 net/core/skbuff.c:630 qrtr_endpoint_post+0xbd/0x11b0 net/qrtr/af_qrtr.c:446 qrtr_tun_write_iter+0x270/0x400 net/qrtr/tun.c:108 call_write_iter include/linux/fs.h:2189 [inline] aio_write+0x63a/0x950 fs/aio.c:1600 io_submit_one+0x1d1c/0x3bf0 fs/aio.c:2019 __do_sys_io_submit fs/aio.c:2078 [inline] __se_sys_io_submit+0x293/0x770 fs/aio.c:2048
    __x64_sys_io_submit+0x92/0xd0 fs/aio.c:2048 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd It is because that skb->len requires at least sizeof(struct qrtr_ctrl_pkt) in qrtr_tx_resume(). And skb->len equals to size in qrtr_endpoint_post(). But size is less than sizeof(struct qrtr_ctrl_pkt) when qrtr_cb->type equals to QRTR_TYPE_RESUME_TX in qrtr_endpoint_post() under the syzbot scenario. This triggers the uninit variable access bug. Add size check when qrtr_cb->type equals to QRTR_TYPE_RESUME_TX in qrtr_endpoint_post() to fix the bug. (CVE-2023-53578)

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

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

  - blockbfq修复“bfqq->bic”的可能 uaf我们的测试报告 5.10中存在“bfqq->bic”的 uaf
    ================================================== ================ BUGKASANbfq_select_queue+0x378/0xa30 中存在释放后使用 CPU6 PID2318352 Commfsstress Kdump supported 未受感染 5.10.0-60.18 .0.50.h602.kasan.eulerosv2r11.x86_64 #1 硬件名称QEMU Standard PC (i440FX + PIIX,1996)BIOS rel-1.12.1-0-ga5cab58-20220320_160524-szxrtosci10000 04/01/2014 调用跟踪
    bfq_select_queue+0x378/0xa30 bfq_dispatch_request+0xe8/0x130 blk_mq_do_dispatch_sched+0x62/0xb0
    __blk_mq_sched_dispatch_requests+0x215/0x2a0 blk_mq_sched_dispatch_requests+0x8f/0xd0
    __blk_mq_run_hw_queue+0x98/0x180 __blk_mq_delay_run_hw_queue+0x22b/0x240 blk_mq_run_hw_queue+0xe3/0x190 blk_mq_sched_insert_requests+0x107/0x200 blk_mq_flush_plug_list+0x330x90x26blk_mq_flush_plug_list+0x30finish
    __iomap_dio_rw+0x7b5/0x910 iomap_dio_rw+0x36/0x80 ext4_dio_read_iter+0x146/0x190 [ext4] ext4_file_read_iter+0x1e2/0x230 [ext4] new_sync_read+0x29f/0x400 vfs_read+0x24e/0x2d0 ksys_read+0xd5/0x1b0 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x61/ 0xc6 提交 3bc5e683c67dbfq在 cgroup 之间移动时拆分共享队列更改将进程移动到新的 cgroup 将分配使用新的 bfqq但是旧的 bfqq 和新的 bfqq 可指向相同的 bic1) 初始状态io 在同一个 cgroup 中的两个进程。| 进程 1 进程 2 (BIC1) (BIC2)| | | | | | | V | V | V | V bfqq1 bfqq2 2) bfqq1 已合并到 bfqq2。| 进程 1 进程 2 (BIC1) (BIC2)| | \-------------\| V bfqq1 bfqq2(coop) 3) 进程 1 退出然后从进程 2 发出新的 io(dence IOA)。(BIC2) | | | | V | V bfqq2(coop) 4) 在 IOA 完成之前将进程 2 移动至另一个 cgroup 并发出 io。进程 2 (BIC2) |\--------------\ | V bfqq2 bfqq3 此时 BIC2 指向 bfqq3而 bfqq2 和 bfqq3 都指向 BIC2。如果所有请求均完成且进程 2 退出则 BIC2 将被释放但不保证 bfqq2 将在 BIC2 之前被释放。通过在 bfqq 从 bic 分离时清除 bfqq->bic 修复问题。 (CVE-2022-50488)

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

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

  - 已修复 Linux 内核中的下列漏洞：cpufreq: amd-pstate: fix global sysfs attribute type In commit 3666062b87ec (cpufreq: amd-pstate: move to use bus_get_dev_root()) the amd_pstate attributes where moved from a dedicated kobject to the cpu root kobject. While the dedicated kobject expects to contain kobj_attributes the root kobject needs device_attributes. As the changed arguments are not used by the callbacks it works most of the time. However CFI will detect this issue: [4947.849350] CFI failure at dev_attr_show+0x24/0x60 (target: show_status+0x0/0x70; expected type:
    0x8651b1de) ... [ 4947.849409] Call Trace: [ 4947.849410] <TASK> [ 4947.849411] ? __warn+0xcf/0x1c0 [4947.849414] ? dev_attr_show+0x24/0x60 [ 4947.849415] ? report_cfi_failure+0x4e/0x60 [ 4947.849417] ? handle_cfi_failure+0x14c/0x1d0 [ 4947.849419] ? __cfi_show_status+0x10/0x10 [ 4947.849420] ? handle_bug+0x4f/0x90 [ 4947.849421] ? exc_invalid_op+0x1a/0x60 [ 4947.849422] ? asm_exc_invalid_op+0x1a/0x20 [ 4947.849424] ? __cfi_show_status+0x10/0x10 [ 4947.849425] ? dev_attr_show+0x24/0x60 [ 4947.849426] sysfs_kf_seq_show+0xa6/0x110 [ 4947.849433] seq_read_iter+0x16c/0x4b0 [ 4947.849436] vfs_read+0x272/0x2d0 [ 4947.849438] ksys_read+0x72/0xe0 [4947.849439] do_syscall_64+0x76/0xb0 [ 4947.849440] ? do_user_addr_fault+0x252/0x650 [ 4947.849442] ? exc_page_fault+0x7a/0x1b0 [ 4947.849443] entry_SYSCALL_64_after_hwframe+0x72/0xdc (CVE-2023-53550)

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

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

  - 10.1 之前的 OpenSSH 中的 ssh 允许在 ssh:// URI 中使用“\0”字符可能会导致在使用 ProxyCommand 时执行代码。 (CVE-2025-61985)

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

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

  - 10.1 之前的 OpenSSH 中的 ssh 允许在来自某些可能不受信任的来源的用户名中使用控制字符从而可能导致使用 ProxyCommand 时代码执行。不可信来源为配置文件的命令行和 % 序列扩展。提供完整文字用户名的配置文件不会被归类为不受信任的来源。(CVE-2025-61984)

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

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

  - jfs修复 diUnmount 中 JFS_IP(ipimap)->i_imap 的无效释放 syzbot 在 diUnmount 中发现无效释放
    BUGKASAN在 slab_free mm/slub.c:3661 中存在双重释放 [内联] BUGKASAN在 中存在双重释放
    __kmem_cache_free+0x71/0x110 mm/slub.c:3674 由任务 syz-executor131/3632 CPU 释放的 addr ffff888806f410000: 0 PID: 3632 Comm: syz-executor131 未受感染 6.1.0-rc7-syzkaller-00012-gca57f02295f1 #0 硬件名称Google Google Compute Engine/Google Compute Engine、BIOS Google 2022 年 10 月 26 日调用跟踪 <TASK>
    __dump_stack lib/dump_stack.c:88 [内联] dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106 print_address_description+0x74/0x340 mm/kasan/report.c:284 print_report+0x107/0x1f0 mm/kasan/report.c 395 kasan_report_invalid_free+0xac/0xd0 mm/kasan/report.c:460____kasan_slab_free+0xfb/0x120 kasan_slab_free include/linux/kasan.h:177 [inline] slab_free_hook mm/slub.c:1724 [inline] slab_free_freelist_hook+0x12e/0x1a0 mm /slub.c:1750 slab_free mm/slub.c:3661 [内联]
    __kmem_cache_free+0x71/0x110 mm/slub.c:3674 diUnmount+0xef/0x100 fs/jfs/jfs_imap.c:195 jfs_umount+0x108/0x370 fs/jfs/jfs_umount.c:63 jfs_put_super+0x86/0x190 fs/jfs/super .c:194 generic_shutdown_super+0x130/0x310 fs/super.c:492 kill_block_super+0x79/0xd0 fs/super.c:1428 deactivate_locked_super+0xa7/0xf0 fs/super.c:332 cleanup_mnt+0x494/0x520 fs/namespace.c ! 950 __do_sys_exit_group kernel/exit.c:961 [内联] __se_sys_exit_group kernel/exit.c:959 [内联] __x64_sys_exit_group+0x3b/0x40 kernel/exit.c:959 do_syscall_x64 arch/x86/entry/common.c:50 [内联] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd [...] diUnmount 中的释放后JFS_IP(ipimap)->i_imap 未设置为空。如果 jfs_remount() 释放 JFS_IP(ipimap)->i_imap但随后在 diMount() 上失败。JFS_IP(ipimap)->i_imap 将再次释放。通过将 JFS_IP(ipimap)->i_imap 设置为释放后为空修复此问题。 (CVE-2023-53616)

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

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

  - 已修复 Linux 内核中的下列漏洞：f2fs: fix to avoid use-after-free for cached IPU bio xfstest generic/019 reports a bug: kernel BUG at mm/filemap.c:1619! RIP:
    0010:folio_end_writeback+0x8a/0x90 Call Trace: end_page_writeback+0x1c/0x60 f2fs_write_end_io+0x199/0x420 bio_endio+0x104/0x180 submit_bio_noacct+0xa5/0x510 submit_bio+0x48/0x80 f2fs_submit_write_bio+0x35/0x300 f2fs_submit_merged_ipu_write+0x2a0/0x2b0 f2fs_write_single_data_page+0x838/0x8b0 f2fs_write_cache_pages+0x379/0xa30 f2fs_write_data_pages+0x30c/0x340 do_writepages+0xd8/0x1b0
    __writeback_single_inode+0x44/0x370 writeback_sb_inodes+0x233/0x4d0 __writeback_inodes_wb+0x56/0xf0 wb_writeback+0x1dd/0x2d0 wb_workfn+0x367/0x4a0 process_one_work+0x21d/0x430 worker_thread+0x4e/0x3c0 kthread+0x103/0x130 ret_from_fork+0x2c/0x50 The root cause is: after cp_error is set, f2fs_submit_merged_ipu_write() in f2fs_write_single_data_page() tries to flush IPU bio in cache, however f2fs_submit_merged_ipu_write() missed to check validity of @bio parameter, result in submitting random cached bio which belong to other IO context, then it will cause use-after-free issue, fix it by adding additional validity check. (CVE-2023-53537)

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

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

  - 已修复 Linux 内核中的下列漏洞：drm/mediatek: mtk_drm_crtc: 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-2023-53534)

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

ID	名称	严重性
269380	Linux Distros 未修补的漏洞：CVE-2022-50496	medium
269379	Linux Distros 未修补的漏洞：CVE-2023-53571	medium
269378	Linux Distros 未修补的漏洞：CVE-2023-53612	high
269377	Linux Distros 未修补的漏洞：CVE-2023-53598	medium
269376	Linux Distros 未修补的漏洞：CVE-2023-53549	high
269375	Linux Distros 未修补的漏洞：CVE-2022-50477	medium
269373	Linux Distros 未修补的漏洞：CVE-2023-53586	high
269372	Linux Distros 未修补的漏洞：CVE-2023-53585	high
269371	Linux Distros 未修补的漏洞：CVE-2023-53552	high
269370	Linux Distros 未修补的漏洞：CVE-2022-50497	high
269369	Linux Distros 未修补的漏洞：CVE-2022-50475	medium
269368	Linux Distros 未修补的漏洞：CVE-2023-53543	medium
269367	Linux Distros 未修补的漏洞：CVE-2022-50484	medium
269366	Linux Distros 未修补的漏洞：CVE-2023-53561	medium
269364	Linux Distros 未修补的漏洞：CVE-2023-53557	medium
269363	Linux Distros 未修补的漏洞：CVE-2023-53535	medium
269362	Linux Distros 未修补的漏洞：CVE-2023-53587	high
269361	Linux Distros 未修补的漏洞：CVE-2023-53581	high
269360	Linux Distros 未修补的漏洞：CVE-2023-53566	medium
269359	Linux Distros 未修补的漏洞：CVE-2023-53576	medium
269358	Linux Distros 未修补的漏洞：CVE-2023-53590	medium
269357	Linux Distros 未修补的漏洞：CVE-2023-53568	high
269356	Linux Distros 未修补的漏洞：CVE-2023-53536	high
269355	Linux Distros 未修补的漏洞：CVE-2022-50505	high
269354	Linux Distros 未修补的漏洞：CVE-2022-50473	medium
269353	Linux Distros 未修补的漏洞：CVE-2023-53604	medium
269352	Linux Distros 未修补的漏洞：CVE-2023-53565	medium
269351	Linux Distros 未修补的漏洞：CVE-2023-53553	high
269350	Linux Distros 未修补的漏洞：CVE-2023-53548	high
269349	Linux Distros 未修补的漏洞：CVE-2023-53572	high
269348	Linux Distros 未修补的漏洞：CVE-2023-53606	high
269347	Linux Distros 未修补的漏洞：CVE-2022-50489	high
269346	Linux Distros 未修补的漏洞：CVE-2023-53607	high
269345	Linux Distros 未修补的漏洞：CVE-2023-53609	medium
269344	Linux Distros 未修补的漏洞：CVE-2022-50491	medium
269343	Linux Distros 未修补的漏洞：CVE-2023-53555	medium
269342	Linux Distros 未修补的漏洞：CVE-2022-50508	high
269341	Linux Distros 未修补的漏洞：CVE-2022-50485	medium
269340	Linux Distros 未修补的漏洞：CVE-2023-53610	high
269339	Linux Distros 未修补的漏洞：CVE-2023-53591	high
269338	Linux Distros 未修补的漏洞：CVE-2022-50498	medium
269337	Linux Distros 未修补的漏洞：CVE-2023-53605	high
269336	Linux Distros 未修补的漏洞：CVE-2023-53578	high
269335	Linux Distros 未修补的漏洞：CVE-2022-50488	medium
269334	Linux Distros 未修补的漏洞：CVE-2023-53550	high
269333	Linux Distros 未修补的漏洞：CVE-2025-61985	low
269332	Linux Distros 未修补的漏洞：CVE-2025-61984	low
269331	Linux Distros 未修补的漏洞：CVE-2023-53616	high
269330	Linux Distros 未修补的漏洞：CVE-2023-53537	high
269329	Linux Distros 未修补的漏洞：CVE-2023-53534	medium

检测

Nessus 的 Misc. 系列

medium

medium

high

medium

high

medium

high

high

high

high

medium

medium

medium

medium

medium

medium

high

high

medium

medium

medium

high

high

high

medium

medium

medium

high

high

high

high

high

high

medium

medium

medium

high

medium

high

high

medium

high

high

medium

high

low

low

high

high

medium