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

  - drm/radeon驱动程序关闭时为 atombios 释放 iio 修复卸载 radeon 驱动程序时的 kmemleak 下
    未引用的对象 0xffff9f8608ede200 (size 512): comm systemd-udevd, pid 326, jiffies 4294682822 (age 716.338s) hex dump前 32 字节: 00 00 00 00 c4 aa ec aa 14 ab 00 00 00 00 00 00 ... 00 00 00 00 00 00 00 00 00 00 00 00<0000000062fadebe>00 00 00 00 .. ] kmem_cache_alloc_trace+0x2f1/0x500 [<00000000b6883cea>] atom_parse+0x117/0x230 [radeon] [<00000000158c23fd>] radeon_atombios_init+0xab/0x170 [radeon] [<00000000683f672e>] si_init+0x57/0x750 [radeon] [<00000000566cc31f>] radeon_device_init+0x559/ 0x9c0 [radeon] [<0000000046efabb3>] radeon_driver_load_kms+0xc1/0x1a0 [radeon] [<00000000b5155064>] drm_dev_register+0xdd/0x1d0 [<0000000045fec835>] radeon_pci_probe+0xbd/0x100 [radeon] [<00000000e69ecca3>] pci_device_probe+0xe1/0x160 [<0000000019484b76>] real_probe.part.0+0xc1/0x2c0 [<000000003f2649da>] __driver_probe_device+0x96/0x130 [<00000000231c5bb1>] driver_probe_device+0x24/0xf0 [<0000000000a42377>] __driver_attach+0x77/0x190 [<00000000d7574da6>] bus_for_each_dev+0x7f/0xd0 [<00000000633166d2>] driver_attach +0x1e/0x30 [<00000000313b05b8>] bus_add_driver+0x12c/0x1e0 iio 已在 atom_parse() 调用的 atom_index_iio() 中分配但在dirver 已关闭。通过在 radeon_atombios_fini() 中释放来修复此 kmemleak。 (CVE-2023-53453)

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

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

  - V8 中的差一错误。 (CVE-2025-11215)

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

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

  - 已修复 Linux 内核中的下列漏洞：net: sched: cake: fix null pointer access issue when cake_init() fails When the default qdisc is cake, if the qdisc of dev_queue fails to be inited during mqprio_init(), cake_reset() is invoked to clear resources. In this case, the tins is NULL, and it will cause gpf issue. The process is as follows: qdisc_create_dflt() cake_init() q->tins = kvcalloc(...) --->failed, q->tins is NULL ... qdisc_put() ... cake_reset() ... cake_dequeue_one() b = &q->tins[...] --->q->tins is NULL The following is the Call Trace information: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:cake_dequeue_one+0xc9/0x3c0 Call Trace: <TASK> cake_reset+0xb1/0x140 qdisc_reset+0xed/0x6f0 qdisc_destroy+0x82/0x4c0 qdisc_put+0x9e/0xb0 qdisc_create_dflt+0x2c3/0x4a0 mqprio_init+0xa71/0x1760 qdisc_create+0x3eb/0x1000 tc_modify_qdisc+0x408/0x1720 rtnetlink_rcv_msg+0x38e/0xac0 netlink_rcv_skb+0x12d/0x3a0 netlink_unicast+0x4a2/0x740 netlink_sendmsg+0x826/0xcc0 sock_sendmsg+0xc5/0x100
    ____sys_sendmsg+0x583/0x690 ___sys_sendmsg+0xe8/0x160 __sys_sendmsg+0xbf/0x160 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7f89e5122d04 </TASK> (CVE-2022-50452)

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

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

  - ASoCmediatek: mt8173pdata 就绪时启用 IRQ 如果设备重置后未直接恢复正常我们可能会在准备好处理 IRQ 之前就对其进行处理。 [ 2.334737] 无法处理来自虚拟地址 00000000000001e4 的不可读内存的内核读取 [ 2.522601] 调用跟踪[ 2.525040] regmap_read+0x1c/0x80 [ 2.528434] mt8173_afe_irq_handler+0x40/0xf0 ... [ 2.598921] start_kernel+ 0x338/0x42cCVE-2022-50439

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

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

  - 已修复 Linux 内核中的下列漏洞：cifs: Fix xid leak in cifs_flock() If not flock, before return -ENOLCK, should free the xid, otherwise, the xid will be leaked. (CVE-2022-50460)

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

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

  - 已修复 Linux 内核中的下列漏洞：usb: xhci: tegra: fix sleep in atomic call When we set the dual-role port to Host mode, we observed the following splat: [ 167.057718] BUG:
    sleeping function called from invalid context at include/linux/sched/mm.h:229 [ 167.057872] Workqueue:
    events tegra_xusb_usb_phy_work [ 167.057954] Call trace: [ 167.057962] dump_backtrace+0x0/0x210 [167.057996] show_stack+0x30/0x50 [ 167.058020] dump_stack_lvl+0x64/0x84 [ 167.058065] dump_stack+0x14/0x34 [ 167.058100] __might_resched+0x144/0x180 [ 167.058140] __might_sleep+0x64/0xd0 [ 167.058171] slab_pre_alloc_hook.constprop.0+0xa8/0x110 [ 167.058202] __kmalloc_track_caller+0x74/0x2b0 [ 167.058233] kvasprintf+0xa4/0x190 [ 167.058261] kasprintf+0x58/0x90 [ 167.058285] tegra_xusb_find_port_node.isra.0+0x58/0xd0 [ 167.058334] tegra_xusb_find_port+0x38/0xa0 [ 167.058380] tegra_xusb_padctl_get_usb3_companion+0x38/0xd0 [ 167.058430] tegra_xhci_id_notify+0x8c/0x1e0 [ 167.058473] notifier_call_chain+0x88/0x100 [ 167.058506] atomic_notifier_call_chain+0x44/0x70 [ 167.058537] tegra_xusb_usb_phy_work+0x60/0xd0 [ 167.058581] process_one_work+0x1dc/0x4c0 [ 167.058618] worker_thread+0x54/0x410 [ 167.058650] kthread+0x188/0x1b0 [ 167.058672] ret_from_fork+0x10/0x20 The function tegra_xusb_padctl_get_usb3_companion eventually calls tegra_xusb_find_port and this in turn calls kasprintf which might sleep and so cannot be called from an atomic context. Fix this by moving the call to tegra_xusb_padctl_get_usb3_companion to the tegra_xhci_id_work function where it is really needed.
    (CVE-2023-53475)

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

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

  - IB/hfi1修复热插拔删除期间可能的错误在热插拔删除期间更新计数器的工作可能会待定并且可能在内存释放后运行。释放内存前取消更新计数器工作。 (CVE-2023-53488)

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

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

  - 已修复 Linux 内核中的下列漏洞：io_uring: fix fget leak when fs don't support nowait buffered read Heming reported a BUG when using io_uring doing link-cp on ocfs2. [1] Do the following steps can reproduce this BUG: mount -t ocfs2 /dev/vdc /mnt/ocfs2 cp testfile /mnt/ocfs2/ ./link-cp /mnt/ocfs2/testfile /mnt/ocfs2/testfile.1 umount /mnt/ocfs2 Then umount will fail, and it outputs:
    umount: /mnt/ocfs2: target is busy. While tracing umount, it blames mnt_get_count() not return as expected. Do a deep investigation for fget()/fput() on related code flow, I've finally found that fget() leaks since ocfs2 doesn't support nowait buffered read. io_issue_sqe |-io_assign_file // do fget() first |-io_read |-io_iter_do_read |-ocfs2_file_read_iter // return -EOPNOTSUPP |-kiocb_done |-io_rw_done |-__io_complete_rw_common // set REQ_F_REISSUE |-io_resubmit_prep |-io_req_prep_async // override req->file, leak happens This was introduced by commit a196c78b5443 in v5.18. Fix it by don't re-assign req->file if it has already been assigned. [1] https://lore.kernel.org/ocfs2-devel/ab580a75-91c8-d68a-3455-40361be1bfa8@linux.alibaba.com/T/#t(CVE-2023-53511)

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

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

  - scsiqla2xxx修复潜在的空指针取消引用 Klocwork 工具报告的“cur_dsd”可能已取消引用。添加补丁以在取消引用指针之前验证指针。 (CVE-2023-53451)

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

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

  - qed允许 qed_mcp_trace_dump() 中的休眠 默认情况下qed_mcp_cmd_and_union() 在可运行 500K 次的循环中一次延迟 10us因此对 qed_mcp_nvm_rd_cmd() 的调用可能会将当前线程阻断 5s 以上。
    我们发现在生产环境中存在超过 700 毫秒的线程计划延迟其堆栈跟踪指向此代码为元首。从 ethtool 调用 qed_mcp_trace_dump()因此允许休眠。它已可在调用 qed_mcp_cmd() 的 qed_mcp_halt() 中休眠。向 qed_find_nvram_image() 和 qed_nvram_read() 添加休眠参数以便其在 qed_mcp_trace_dump() 期间休眠。 qed_mcp_trace_get_meta_info() 和 qed_mcp_trace_read_meta() 仅由 qed_mcp_trace_dump() 调用允许这些函数休眠。我无法判断其他调用程序 (qed_grc_dump_mcp_hw_dump()) 是否可以休眠因此在调用这些函数时请将 b_can_sleep 设置为 false。我们添加到内核的自定义警告中的一个示例堆栈跟踪，显示了一个线程尽管需要重新调度但尚未调度：[ 2745.362925,17] ------------[ 从此处剪切]------------ [ 2745.362941,17] 警告：CPU：23 PID：5640 at arch/x86/kernel/irq.c:233 do_IRQ+0x15e/0x1a0() [ 2745.362946,17] 线程在 irq 99 后 744 毫秒内未重新调度 [ 2745.362956,17] 链接的模块：... [ 2745.363339,17] CPU：23 PID：5640 通信：lldpd 污染：P O 4.4.182+ #202104120910+6d1da174272d.61x [ 2745.363343,17] 硬件名称：FOXCONN MercuryB/Quicksilver 控制器，BIOS H11P1N09 07/08/2020 [ 2745.363346,17] 0000000000000000 ffff885ec07c3ed8 ffffffff8131eb2f ffff885ec07c3f20 [ 2745.363358,17] ffffffff81d14f64 ffff885ec07c3f10 ffffffff81072ac2 ffff88be98ed0000 [2745.363369,17] 0000000000000063 0000000000000174 0000000000000074 0000000000000000 [ 2745.363379,17] 调用跟踪：[ 2745.363382,17] <IRQ> [<ffffffff8131eb2f>] dump_stack+0x8e/0xcf [ 2745.363393,17] [<ffffffff81072ac2>] warn_slowpath_common+0x82/0xc0 [ 2745.363398,17] [<ffffffff81072b4c>] warn_slowpath_fmt+0x4c/0x50 [ 2745.363404,17] [<ffffffff810d5a8e>] ? rcu_irq_exit+0xae/0xc0 [2745.363408,17] [<ffffffff817c99fe>] do_IRQ+0x15e/0x1a0 [ 2745.363413,17] [<ffffffff817c7ac9>] common_interrupt+0x89/0x89 [ 2745.363416,17] <EOI> [<ffffffff8132aa74>] ? delay_tsc+0x24/0x50 [2745.363425,17] [<ffffffff8132aa04>] __udelay+0x34/0x40 [ 2745.363457,17] [<ffffffffa04d45ff>] qed_mcp_cmd_and_union+0x36f/0x7d0 [qed] [ 2745.363473,17] [<ffffffffa04d5ced>] qed_mcp_nvm_rd_cmd+0x4d/0x90 [qed] [ 2745.363490,17] [<ffffffffa04e1dc7>] qed_mcp_trace_dump+0x4a7/0x630 [qed] [ 2745.363504,17] [<ffffffffa04e2556>] ? qed_fw_asserts_dump+0x1d6/0x1f0 [qed] [ 2745.363520,17] [<ffffffffa04e4ea7>] qed_dbg_mcp_trace_get_dump_buf_size+0x37/0x80 [qed] [ 2745.363536,17] [<ffffffffa04ea881>] qed_dbg_feature_size+0x61/0xa0 [qed] [ 2745.363551,17] [<ffffffffa04eb427>] qed_dbg_all_data_size+0x247/0x260 [qed] [ 2745.363560,17] [<ffffffffa0482c10>] qede_get_regs_len+0x30/0x40 [qede] [ 2745.363566,17] [<ffffffff816c9783>] ethtool_get_drvinfo+0xe3/0x190 [ 2745.363570,17] [<ffffffff816cc152>] dev_ethtool+0x1362/0x2140 [ 2745.363575,17] [<ffffffff8109bcc6>] ? finish_task_switch+0x76/0x260 [ 2745.363580,17] [<ffffffff817c2116>] ? __schedule+0x3c6/0x9d0 [2745.363585,17] [<ffffffff810dbd50>] ? hrtimer_start_range_ns+0x1d0/0x370 [ 2745.363589,17] [<ffffffff816c1e5b>] ? dev_get_by_name_rcu+0x6b/0x90 [ 2745.363594,17] [<ffffffff816de6a8>] dev_ioctl+0xe8/0x710 [ 2745.363599,17] [<ffffffff816a58a8>] sock_do_ioctl+0x48/0x60 [ 2745.363603,17] [<ffffffff816a5d87>] sock_ioctl+0x1c7/0x280 [ 2745.363608,17] [<ffffffff8111f393>] ? seccomp_phase1+0x83/0x220 [ 2745.363612,17] [<ffffffff811e3503>] do_vfs_ioctl+0x2b3/0x4e0 [2745.363616,17] [<ffffffff811e3771>] SyS_ioctl+0x41/0x70 [ 2745.363619,17] [<ffffffff817c6ffe>] entry_SYSCALL_64_fastpath+0x1e/0x79 [ 2745.363622,17] ---[ 结束跟踪 f6954aa440266421 ]--- (CVE-2023-53509)

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

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

  - scsises修复 ses_intf_remove() 中的 slab 越界 针对以下问题的补丁BUGKASANses_intf_remove+0x23f/0x270 中的 slab 越界 [ses] 通过任务读取 addr ffff88a10d32e5d8 中的大小 8 rmmod/12013 当 edev->components 为零时访问 edev->component[0] 成员是错误的。 (CVE-2023-53521)

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

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

  - 已修复 Linux 内核中的下列漏洞：iommu/amd/iommu_v2: Fix pasid_state refcount dec hit 0 warning on pasid unbind When unbinding pasid - a race condition exists vs outstanding page faults. To prevent this, the pasid_state object contains a refcount. * set to 1 on pasid bind * incremented on each ppr notification start * decremented on each ppr notification done * decremented on pasid unbind Since refcount_dec assumes that refcount will never reach 0: the current implementation causes the following to be invoked on pasid unbind: REFCOUNT_WARN(decrement hit 0; leaking memory) Fix this issue by changing refcount_dec to refcount_dec_and_test to explicitly handle refcount=1.
    (CVE-2023-53501)

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

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

  - Bluetooth修复 hci_suspend_sync 崩溃 如果 hci_unregister_dev() 释放了 hci_dev 对象但 hci_suspend_notifier 可能仍在访问它则可能导致程序崩溃。调用轨迹如下
    <4>[102152.653246] 调用跟踪 <4>[102152.653254] hci_suspend_sync+0x109/0x301 [蓝牙] <4>[102152.653259] hci_suspend_dev+0x78/0xcd [蓝牙] <4>[102152.653263] hci_suspend_notifier+0x42/0x7a [蓝牙] <4>[102152.653268] notifier_call_chain+0x43/0x6b <4>[102152.653271]
    __blocking_notifier_call_chain+0x48/0x69 <4>[102152.653273] __pm_notifier_call_chain+0x22/0x39 <4>[102152.653276] pm_suspend+0x287/0x57c <4>[102152.653278] state_store+0xae/0xe5 <4>[102152.653281] kernfs_fop_write+0x109/0x173 <4>[102152.653284] __vfs_write+0x16f/0x1a2 <4>[102152.653287] ? selinux_file_permission+0xca/0x16f <4>[102152.653289] ? security_file_permission+0x36/0x109 <4>[102152.653291] vfs_write+0x114/0x21d <4>[102152.653293] __x64_sys_write+0x7b/0xdb <4>[102152.653296] do_syscall_64+0x59/0x194 <4>[102152.653299] entry_SYSCALL_64_after_hwframe+0x5c/0xc1 这个在 hci_suspend_notifier 中处理 hci_dev 对象时修补程序会保留 hci_dev 对象的引用计数以避免争用条件造成的潜在崩溃。 (CVE-2023-53520)

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

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

  - netethernettiam65-cpsw修复 am65_cpsw_nuss_ndo_slave_open() 中的 PM 运行时泄漏 确保在错误路径中发出 pm_runtime_put()。 (CVE-2022-50461)

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

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

  - cgroup,freezer在 freezer_mutex syzbot 报告 cpu_hotplug_lock 和 freezer_mutex 之间的循环锁定依存关系之前保留 cpu_hotplug_lock用于提交 f5d39b020809freezer,sched重写核心 freezer 逻辑将 freezer_apply_state() 中的 atomic_inc() 替换为保存 cpu_hotplug_lock 的 static_branch_inc()。 cpu_hotplug_lock => cgroup_threadgroup_rwsem => freezer_mutex cgroup_file_write() {cgroup_procs_write() { __cgroup_procs_write() { cgroup_procs_write_start() { cgroup_attach_lock() {cpus_read_lock() { percpu_down_read(&cpu_hotplug_lock); } } percpu_down_write(&cgroup_threadgroup_rwsem); }} cgroup_attach_task() { cgroup_migrate() { cgroup_migrate_execute() { freezer_attach() {mutex_lock(&freezer_mutex); } (...snipped...) } } } }(...snipped...) } } } freezer_mutex => cpu_hotplug_lock cgroup_file_write() { freezer_write() { freezer_change_state() {mutex_lock(&freezer_mutex); } freezer_apply_state() { static_branch_inc(&freezer_active) { static_key_slow_inc() { cpus_read_lock(); } } static_key_slow_inc_cpuslocked(); cpus_read_unlock(); mutex_unlock(&freezer_mutex);通过将 freezer_apply_state() 中的 cpus_read_lock() 移动到 freezer_change_state() 中的 mutex_lock(&freezer_mutex) 之前交换锁定顺序。 (CVE-2023-53522)

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

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

  - fs/ntfs3增强属性大小检查这将溢出和边界检查相结合以便枚举属性大小时能够正确检查这些大小。 [ 169.181521] BUGKASANrun_unpack+0x2e3/0x570 中的 slab 越界 [ 169.183161] 通过任务 mount/247 在 addr ffff8880094b6240 读取大小为 1 的数据 [169.184046] [ 169.184925] CPU0 PID 247 Commmount Not tainted 6.0.0-rc7+ #3 [ 169.185908] 硬件名称QEMU Standard PC (i440FX + PIIX, 1996)、BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01 /2014 [ 169.187066] 调用跟踪[ 169.187492] <TASK> [ 169.188049] dump_stack_lvl+0x49/0x63 [ 169.188495] print_report.cold+0xf5/0x689 [ 169.188964] ? run_unpack+0x2e3/0x570 [ 169.189331] kasan_report+0xa7/0x130 [ 169.189714] ? run_unpack+0x2e3/0x570 [ 169.190079] __asan_load1+0x51/0x60 [ 169.190634] run_unpack+0x2e3/0x570 [ 169.191290] ? run_pack+0x840/0x840 [ 169.191569] ? run_lookup_entry+0xb3/0x1f0 [169.192443] ? mi_enum_attr+0x20a/0x230 [ 169.192886] run_unpack_ex+0xad/0x3e0 [ 169.193276] ? run_unpack+0x570/0x570 [ 169.193557] ? ni_load_mi+0x80/0x80 [ 169.193889] ? debug_smp_processor_id+0x17/0x20 [ 169.194236] mi_init+0x4a/0x70 [ 169.194496] attr_load_runs_vcn+0x166/0x1c0 [ 169.194851] ? attr_data_write_residue+0x250/0x250 [ 169.195188] mi_read+0x133/0x2c0 [ 169.195481] ntfs_iget5+0x277/0x1780 [ 169.196017] ? call_rcu+0x1c7/0x330 [169.196392] ? ntfs_get_block_bmap+0x70/0x70 [ 169.196708] ? evict+0x223/0x280 [ 169.197014] ?
    __kmalloc+0x33/0x540 [ 169.197305] ? wnd_init+0x15b/0x1b0 [ 169.197599] ntfs_fill_super+0x1026/0x1ba0 [169.197994] ? put_ntfs+0x1d0/0x1d0 [ 169.198299] ? vsprintf+0x20/0x20 [ 169.198583] ? mutex_unlock+0x81/0xd0 [ 169.198930] ? set_blocksize+0x95/0x150 [ 169.199269] get_tree_bdev+0x232/0x370 [169.199750] ? put_ntfs+0x1d0/0x1d0 [ 169.200094] ntfs_fs_get_tree+0x15/0x20 [ 169.200431] vfs_get_tree+0x4c/0x130 [ 169.200714] path_mount+0x654/0xfe0 [ 169.201067] ? putname+0x80/0xa0 [169.201358] ? finish_automount+0x2e0/0x2e0 [ 169.201965] ? putname+0x80/0xa0 [ 169.202445] ? kmem_cache_free+0x1c4/0x440 [ 169.203075] ? putname+0x80/0xa0 [ 169.203414] do_mount+0xd6/0xf0 [169.203719] ? path_mount+0xfe0/0xfe0 [ 169.203977] ? __kasan_check_write+0x14/0x20 [ 169.204382]
    __x64_sys_mount+0xca/0x110 [ 169.204711] do_syscall_64+0x3b/0x90 [ 169.205059] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 169.205571] RIP0033:0x7f67a80e948a [ 169.206327] Code48 8b 0d 11 fa 0d894 894 817 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 008 [ 169.208296] RSP: 002b:00007ffddf020f58 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5 [169.209253] RAX: ffffffffffffffda RBX: 000055e2547a6060 RCX: 00007f67a80e948a [ 169.209777] RDX:
    000055e2547a6260 RSI: 000055e2547a62e0 RDI: 000055e2547aeaf0 [ 169.210342] RBP: 0000000000000000 R08
    000055e2547a6280 R090000000000000020 [ 169.210843] R1000000000c0ed0000 R110000000000000202 R12
    000055e2547aeaf0 [ 169.211307] R13: 000055e2547a6260 R14: 0000000000000000 R15: 00000000ffffffff [169.211913] </TASK> [ 169.212304] [ 169.212680] 任务分配 0 [ 169.212963] 堆栈不可用 [ 169.213200] [ 169.213472] 缺陷地址属于 ffff8880094b5e00 的对象 [169.213472]该地址属于大小为 1152 的缓存 UDP [ 169.214095] ] 缺陷地址位于 [ 169.214095] 1152 字节区域 [ffff8880094b5e00, ffff8880094b6280) [ 169.214639] [169.215004] 有缺陷的地址属于物理页 [ 169.215766] page:000000002e324c8c refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x94b4 [ 169.218412] head:000000002e324c8c order 2 compound_mapcount:0 compound_pincount:0 [ 169.219078] flags
    0xfffffc0010200(slab|head|node=0|zone=1|lastcpupid=0x1fffff) [ 169.220272] raw: 000fffffc0010200
    ---truncated--- (CVE-2023-53486)

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

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

  - 已修复 Linux 内核中的下列漏洞：rpmsg: char: Avoid double destroy of default endpoint The rpmsg_dev_remove() in rpmsg_core is the place for releasing this default endpoint. So need to avoid destroying the default endpoint in rpmsg_chrdev_eptdev_destroy(), this should be the same as rpmsg_eptdev_release(). Otherwise there will be double destroy issue that ept->refcount report warning:
    refcount_t: underflow; use-after-free. Call trace: refcount_warn_saturate+0xf8/0x150 virtio_rpmsg_destroy_ept+0xd4/0xec rpmsg_dev_remove+0x60/0x70 The issue can be reproduced by stopping remoteproc before closing the /dev/rpmsgX. (CVE-2022-50421)

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

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

  - af_unix修复 unix_stream_sendpage() 中的 null-ptr-deref。Bing-Jhong Billy Jheng 报告了 unix_stream_sendpage() 中的 null-ptr-deref其中包含详细的分析和良好的重现。 unix_stream_sendpage() 尝试在不锁定队列的情况下将数据添加到对等机的 recv 队列中的最后一个 skb。如果对等机的 FD 被传递到另一个套接字并且该套接字的 FD 被传递到对等机则它们之间会形成循环。如果在未收到 FD 的情况下关闭这两个套接字则垃圾回收将清除这两个套接字。垃圾回收会迭代此类套接字并在队列锁定下取消 skb 与来自套接字接收队列的 FD 的链接。因此存在争用其中 unix_stream_sendpage() 可无锁地访问垃圾回收正在释放的 skb从而导致释放后使用。要避免 问题unix_stream_sendpage() 必须锁定对等机的 recv 队列。请注意 6.5+ 感谢最近的 sendpage() 重构中不存在 问题。此修补程序最初由 Linus Torvalds 编写。BUG：无法处理地址的页面错误：
    ffff988004dd6870 PF内核模式 PF 中的监控程序读取访问error_code (0x0000) - not-present page PGD 0 P4D 0 PREEMPT SMP PTI CPU: 4 PID: 297 Commgarbage_uaf 未受感染 6.1.46 #1 硬件名称QEMU Standard PC (i440FX + PIIX) ，1996，BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP
    0010:kmem_cache_alloc_node+0xa2/0x1e0 代码 c0 0f 84 32 01 00 00 41 83 fd ff 74 10 48 8b 00 48 c1 e8 3a 41 39 c5 0f 85 1c 01 00 00 41 8b 44 24 28 39 8b 4c 8 2d 4c 8 8 40 <49> 8b 1c 06 4c 89 f0 65 48 0f c7 0f 0f 94 c0 84 c0 74 a1 41 8b 44 RSP: 0018:ffffc9000079fac0 EFLAGS: 00000246 RAX: 0000000000000070 RBX
    0000000000000005 RCX: 000000000001a284 RDX: 000000000001a244 RSI: 0000000000400cc0 RDI: 000000000002eee0 RBP: 0000000000400cc0 R08: 0000000000400cc0 R09: 0000000000000003 R10: 0000000000000001 R11:
     R120000000000000000  : ffff888003970f00 R13: 00000000ffffffff R14: ffff988004dd6800 R15: 00000000000000e8 FS: 00007f174d6f3600(0000) GS:ffff88807db00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff988004dd6870 CR3: 00000000092be000 CR4: 00000000007506e0 PKRU: 55555554 调用跟踪 <TASK> ? __die_body.cold+0x1a/0x1f page_fault_oops+0xa9/0x1e0 fixup_exception+0x1d/0x310 ? exc_page_fault+0xa8/0x150 ? asm_exc_page_fault+0x22/0x30 ? kmem_cache_alloc_node+0xa2/0x1e0 ?
    __alloc_skb+0x16c/0x1e0 __alloc_skb+0x16c/0x1e0 alloc_skb_with_frags+0x48/0x1e0 sock_alloc_send_pskb+0x234/0x270 unix_stream_sendmsg+0x1f5/0x690 sock_sendmsg+0x5d/0x60
    ____sys_sendmsg+0x210/0x260 ___sys_sendmsg+0x83/0xd0 ? kmem_cache_alloc+0xc6/0x1c0 ? avc_disable+0x20/0x20 ? percpu_counter_add_batch+0x53/0xc0 ? alloc_empty_file+0x5d/0xb0 ? alloc_file+0x91/0x170 ? alloc_file_pseudo+0x94/0x100 ? __fget_light+0x9f/0x120 __sys_sendmsg+0x54/0xa0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x69/0xd3 RIP: 0033:0x7f174d639a7d Code: 28 89 54 24 1c 48 89 74 24 10 89 7c 24 08 e8 8a c1 f4 ff 8b 54 24 1c 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 33 44 89 c7 48 89 44 24 08 e8 de c1 f4 ff 48 RSP: 002b:000007EFLA ORIG_RAX000000000000002e RAXffffffffffffffda RBX0000000000000000 RCX00007f174d639a7d RDX
    0000000000000000 RSI: 00007ffcb563eab0 RDI: 0000000000000007 RBP: 00007ffcb563eb10 R08: 0000000000000000 R09: 00000000ffffffff R10: 00000000004040a0 R11: 0000000000000293 R12: 00007ffcb563ec28 R13:
    0000000000401398 R140000000000403e00 R1500007f174d72c000 </TASK> (CVE-2023-53469)

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

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

  - 已修复 Linux 内核中的下列漏洞：ext4: don't set up encryption key during jbd2 transaction Commit a80f7fcf1867 (ext4: fixup ext4_fc_track_* functions' signature) extended the scope of the transaction in ext4_unlink() too far, making it include the call to ext4_find_entry().
    However, ext4_find_entry() can deadlock when called from within a transaction because it may need to set up the directory's encryption key. Fix this by restoring the transaction to its original scope.
    (CVE-2022-50436)

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

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

  - fs/ntfs3修复 ntfs_fill_super() 错误路径上的内存泄漏 syzbot 报告 kmemleak 如下 BUG内存泄漏未引用对象 0xffff8880122f1540大小 32comm a.out, pid 6664, jiffies 4294939771(存在时间 25.500s) 十六进制转储前 32 字节00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ 00 00 00 00 00 00 00 00 ed ff ed ff 00<ffffffff81627e7c>00<ffffffff81b16052>00<ffffffff81626dd4>00<ffffffff8164aaa7>...  ] __x64_sys_mount+0x18c/0x1d0 [<ffffffff84593e14>] do_syscall_64+0x34/0xb0 [<ffffffff84600087>] entry_SYSCALL_64_after_hwframe+0x63/0xcd 此修补程序通过释放 ntfs_fill_super() 错误路径上的挂载选项修复此问题。 (CVE-2022-50451)

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

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

  - x86/fpu修复 copy_xstate_to_uabi() 以正确复制 init 状态。当扩展状态组件未处于 fpstate 中但处于 init 状态时函数将通过 copy_feature() 从 init_fpsstate 进行复制。但是动态状态不存在于 init_fpsate 中因为 init 状态为全零。然后从 init_fpsstate 检索它们将会像下面一样发生爆炸缺陷: 内核空指针取消引用, 地址: 0000000000000000 ...
    RIP: 0010:memcpy_erms+0x6/0x10 ? __copy_xstate_to_uabi_buf+0x381/0x870 fpu_copy_guest_fpsate_to_uabi+0x28/0x80 kvm_arch_vcpu_ioctl+0x14c/0x1460 [kvm] ?
    __this_cpu_preempt_check+0x13/0x20 ? vmx_vcpu_put+0x2e/0x260 [kvm_intel] kvm_vcpu_ioctl+0xea/0x6b0 [kvm] ? kvm_vcpu_ioctl+0xea/0x6b0 [kvm] ? __fget_light+0xd4/0x130 __x64_sys_ioctl+0xe3/0x910 ? debug_smp_processor_id+0x17/0x20 ? fpregs_assert_state_consistent+0x27/0x50 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd 针对无法通过 fpstate 和 init_fpsstate 使用的功能调整“掩码”以将用户空间缓冲区归零。动态功能依赖于压缩的 XSAVE 格式。读取 init_fpsstate 中的 XCOMP_BV 之前确保其已启用。 (CVE-2022-50425)

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

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

  - 已修复 Linux 内核中的下列漏洞：efi: ssdt: Don't free memory if ACPI table was loaded successfully Amadeusz reports KASAN use-after-free errors introduced by commit 3881ee0b1edc (efi: avoid efivars layer when loading SSDTs from variables). The problem appears to be that the memory that holds the new ACPI table is now freed unconditionally, instead of only when the ACPI core reported a failure to load the table. So let's fix this, by omitting the kfree() on success.
    (CVE-2022-50433)

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

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

  - 已修复 Linux 内核中的下列漏洞：platform/chrome: cros_usbpd_notify:
    Fix error handling in cros_usbpd_notify_init() The following WARNING message was given when rmmod cros_usbpd_notify: Unexpected driver unregister! WARNING: CPU: 0 PID: 253 at drivers/base/driver.c:270 driver_unregister+0x8a/0xb0 Modules linked in: cros_usbpd_notify(-) CPU: 0 PID: 253 Comm: rmmod Not tainted 6.1.0-rc3 #24 ... Call Trace: <TASK> cros_usbpd_notify_exit+0x11/0x1e [cros_usbpd_notify]
    __x64_sys_delete_module+0x3c7/0x570 ? __ia32_sys_delete_module+0x570/0x570 ? lock_is_held_type+0xe3/0x140 ? syscall_enter_from_user_mode+0x17/0x50 ? rcu_read_lock_sched_held+0xa0/0xd0 ? syscall_enter_from_user_mode+0x1c/0x50 do_syscall_64+0x37/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f333fe9b1b7 The reason is that the cros_usbpd_notify_init() does not check the return value of platform_driver_register(), and the cros_usbpd_notify can install successfully even if platform_driver_register() failed. Fix by checking the return value of platform_driver_register() and unregister cros_usbpd_notify_plat_driver when it failed. (CVE-2022-50468)

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

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

  - ext4改善 ext4_dirhash() 中的错误处理 ext4_dirhash() *几乎*不会失败尤其是首次引入哈希树功能时。但是，通过增加对加密的、大小写文件名的支持，该功能现在肯定会失败。因此请确保 ext4_dirhash() 的调用程序正确检查故障并将错误反映回其调用程序。
    (CVE-2023-53473)

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

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

  - cryptohisilicon/hpre - 修复删除进程中的资源泄漏在 hpre_remove() 中当 qm sriov 的禁用操作失败时应继续执行以下逻辑而不是直接返回否则将会出现资源泄漏。
    (CVE-2022-50420)

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

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

  - scsilibsas修复 smp_execute_task_sg() 中的释放后使用缺陷 当执行 SMP 任务失败时smp_execute_task_sg() 调用 del_timer() 以删除 slow_task->timer。但是如果定时器处理程序 sas_task_internal_timedout() 正在运行smp_execute_task_sg() 中的 del_timer() 将不会停止并将发生 UAF。进程如下所示：(线程 1) |线程 2smp_execute_task_sg() | smp_execute_task_sg() sas_task_internal_timedout() ... del_timer() | del_timer ... ... sas_free_task(task) | kfree(task->slow_task) //FREE| | task->slow_task->... //USE 通过在 smp_execute_task_sg() 中调用 del_timer_sync() 来修复这可确保定时器处理程序在 task->slow_task 取消分配之前已完成。 (CVE-2022-50422)

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

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

  - 已修复 Linux 内核中的下列漏洞：remoteproc: imx_dsp_rproc: Add mutex protection for workqueue The workqueue may execute late even after remoteproc is stopped or stopping, some resources (rpmsg device and endpoint) have been released in rproc_stop_subdevices(), then rproc_vq_interrupt() accessing these resources will cause kennel dump. Call trace:
    virtqueue_add_split+0x1ac/0x560 virtqueue_add_inbuf+0x4c/0x60 rpmsg_recv_done+0x15c/0x294 vring_interrupt+0x6c/0xa4 rproc_vq_interrupt+0x30/0x50 imx_dsp_rproc_vq_work+0x24/0x40 [imx_dsp_rproc] process_one_work+0x1d0/0x354 worker_thread+0x13c/0x470 kthread+0x154/0x160 ret_from_fork+0x10/0x20 Add mutex protection in imx_dsp_rproc_vq_work(), if the state is not running, then just skip calling rproc_vq_interrupt(). Also the flush workqueue operation can't be added in rproc stop for the same reason.
    The call sequence is rproc_shutdown -> rproc_stop ->rproc_stop_subdevices ->rproc->ops->stop()
    ->imx_dsp_rproc_stop ->flush_work -> rproc_vq_interrupt The resource needed by rproc_vq_interrupt has been released in rproc_stop_subdevices, so flush_work is not safe to be called in imx_dsp_rproc_stop.
    (CVE-2022-50426)

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

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

  - V8 中的释放后使用。(CVE-2025-11219)

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

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

  - libcpu_rmap避免 rmap->obj 数组条目中释放后使用在通知参数为 NULL 的情况下调用 irq_set_affinity_notifier() 时会导致释放相应数组条目中的胶水指针但将指针保留在数组中。对 free_irq_cpu_rmap() 的后续调用将尝试再次释放此条目从而可能导致释放后使用。对此进行修复的方法是将数组条目设置为 NULL并在迭代 free_irq_cpu_rmap() 中的数组时检查数组条目是否具有非零值。
    当前代码不受此问题影响因为在任何情况下都不会调用 irq_set_affinity_notifier(irq, NULL)请注意为通知参数传递的 NULL然后调用 free_irq_cpu_rmap()因此不会命中并发出 。此系列的后续修补程序解决了此流程因此需要补丁。
    (CVE-2023-53484)

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

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

  - 已修复 Linux 内核中的下列漏洞：null_blk: fix poll request timeout handling When doing io_uring benchmark on /dev/nullb0, it's easy to crash the kernel if poll requests timeout triggered, as reported by David. [1] BUG: kernel NULL pointer dereference, address:
    0000000000000008 Workqueue: kblockd blk_mq_timeout_work RIP: 0010:null_timeout_rq+0x4e/0x91 Call Trace: ? null_timeout_rq+0x4e/0x91 blk_mq_handle_expired+0x31/0x4b bt_iter+0x68/0x84 ? bt_tags_iter+0x81/0x81
    __sbitmap_for_each_set.constprop.0+0xb0/0xf2 ? __blk_mq_complete_request_remote+0xf/0xf bt_for_each+0x46/0x64 ? __blk_mq_complete_request_remote+0xf/0xf ? percpu_ref_get_many+0xc/0x2a blk_mq_queue_tag_busy_iter+0x14d/0x18e blk_mq_timeout_work+0x95/0x127 process_one_work+0x185/0x263 worker_thread+0x1b5/0x227 This is indeed a race problem between null_timeout_rq() and null_poll().
    null_poll() null_timeout_rq() spin_lock(&nq->poll_lock) list_splice_init(&nq->poll_list, &list) spin_unlock(&nq->poll_lock) while (!list_empty(&list)) req = list_first_entry() list_del_init() ...
    blk_mq_add_to_batch() // req->rq_next = NULL spin_lock(&nq->poll_lock) // rq->queuelist->next == NULL list_del_init(&rq->queuelist) spin_unlock(&nq->poll_lock) Fix these problems by setting requests state to MQ_RQ_COMPLETE under nq->poll_lock protection, in which null_timeout_rq() can safely detect this race and early return. Note this patch just fix the kernel panic when request timeout happen. [1] https://lore.kernel.org/all/3893581.1691785261@warthog.procyon.org.uk/ (CVE-2023-53531)

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

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

  - udf不打扰合并过长的范围 合并过长的范围时我们会尝试将尽可能多的长度推进第一个范围。然而这样做过于复杂而且不值得。此外逻辑中存在缺陷导致 syzbot repeater 显示的文件中的范围损坏。因此不必理会太长的盘区合并在一起。
    (CVE-2023-53506)

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

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

  - ext4允许 ext4_get_group_info() 失败 以前ext4_get_group_info() 会将无效的群组数处理为 BUG()因为理论上这种情况永远不应该发生。但是如果恶意攻击者或模糊测试者在挂载了文件系统时通过块设备修改超级块则可能将 s_first_data_block 设置为非常大的数字。在此情况下计算某个块的块组编号如预分配区域的起始块时 可能导致下溢和极大的块组编号。然后ext4_get_group_info() 中的 BUG_ON 检查会触发根用户或对区块设备具有写入访问权限的人触发的拒绝服务攻击。
    从实现质量的角度来说，最好即使系统管理员执行了他们不应该执行的操作，也不会触发 BUG。因此ext4_get_group_info() 将调用 ext4_error 并返回 NULL而不是进行 BUG'ing。我们还在其可能为空的 ext4_get_group_info() 的所有调用程序中添加了回退代码。此外由于 ext4_get_group_info() 已接近内联函数因此请将其取消内联。结果下一次将 ext4 的已编译文本大小减少大约 2k。 (CVE-2023-53503)

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

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

  - ext4删除 ext4_mb_release_group_pa() 中的 BUG_ON 如果恶意 fuzz 程序在装载时覆盖 ext4 超级块使 s_first_data_block 设置为非常大的数字则块组计算可下溢并触发 BUG_ON 检查。将此更改为 ext4_warning以便不会造成内核崩溃。 (CVE-2023-53450)

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

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

  - FSJFS修复 txBegin 中的 null-ptr-deref Read Syzkaller 报告一个问题可在只读挂载的文件系统中的超级块上调用 txBegin从而导致空指针取消引用。通过在调用 txBegin 之前检查文件系统是否为只读并返回适当的错误代码可解决此问题。
    (CVE-2023-53457)

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

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

  - 已修复 Linux 内核中的下列漏洞：net/mlx5: Lag, fix failure to cancel delayed bond work Commit 0d4e8ed139d8 (net/mlx5: Lag, avoid lockdep warnings) accidentally removed a call to cancel delayed bond work thus it may cause queued delay to expire and fall on an already destroyed work queue. Fix by restoring the call cancel_delayed_work_sync() before destroying the workqueue. This prevents call trace such as this: [ 329.230417] BUG: kernel NULL pointer dereference, address:
    0000000000000000 [ 329.231444] #PF: supervisor write access in kernel mode [ 329.232233] #PF:
    error_code(0x0002) - not-present page [ 329.233007] PGD 0 P4D 0 [ 329.233476] Oops: 0002 [#1] SMP [329.234012] CPU: 5 PID: 145 Comm: kworker/u20:4 Tainted: G OE 6.0.0-rc5_mlnx #1 [ 329.235282] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [329.236868] Workqueue: mlx5_cmd_0000:08:00.1 cmd_work_handler [mlx5_core] [ 329.237886] RIP:
    0010:_raw_spin_lock+0xc/0x20 [ 329.238585] Code: f0 0f b1 17 75 02 f3 c3 89 c6 e9 6f 3c 5f ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 0f 1f 44 00 00 31 c0 ba 01 00 00 00 <f0> 0f b1 17 75 02 f3 c3 89 c6 e9 45 3c 5f ff 0f 1f 44 00 00 0f 1f [ 329.241156] RSP: 0018:ffffc900001b0e98 EFLAGS: 00010046 [ 329.241940] RAX:
    0000000000000000 RBX: ffffffff82374ae0 RCX: 0000000000000000 [ 329.242954] RDX: 0000000000000001 RSI:
    0000000000000014 RDI: 0000000000000000 [ 329.243974] RBP: ffff888106ccf000 R08: ffff8881004000c8 R09:
    ffff888100400000 [ 329.244990] R10: 0000000000000000 R11: ffffffff826669f8 R12: 0000000000002000 [329.246009] R13: 0000000000000005 R14: ffff888100aa7ce0 R15: ffff88852ca80000 [ 329.247030] FS:
    0000000000000000(0000) GS:ffff88852ca80000(0000) knlGS:0000000000000000 [ 329.248260] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 329.249111] CR2: 0000000000000000 CR3: 000000016d675001 CR4:
    0000000000770ee0 [ 329.250133] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [329.251152] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 329.252176] PKRU: 55555554 (CVE-2022-50441)

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

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

  - 已修复 Linux 内核中的下列漏洞：fs/binfmt_elf: Fix memory leak in load_elf_binary() There is a memory leak reported by kmemleak: unreferenced object 0xffff88817104ef80 (size 224): comm xfs_admin, pid 47165, jiffies 4298708825 (age 1333.476s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 60 a8 b3 00 81 88 ff ff a8 10 5a 00 81 88 ff ff `.........Z..... backtrace: [<ffffffff819171e1>] __alloc_file+0x21/0x250 [<ffffffff81918061>] alloc_empty_file+0x41/0xf0 [<ffffffff81948cda>] path_openat+0xea/0x3d30 [<ffffffff8194ec89>] do_filp_open+0x1b9/0x290 [<ffffffff8192660e>] do_open_execat+0xce/0x5b0 [<ffffffff81926b17>] open_exec+0x27/0x50 [<ffffffff81a69250>] load_elf_binary+0x510/0x3ed0 [<ffffffff81927759>] bprm_execve+0x599/0x1240 [<ffffffff8192a997>] do_execveat_common.isra.0+0x4c7/0x680 [<ffffffff8192b078>]
    __x64_sys_execve+0x88/0xb0 [<ffffffff83bbf0a5>] do_syscall_64+0x35/0x80 If interp_elf_ex fails to allocate memory in load_elf_binary(), the program will take the out_free_ph error handing path, resulting in interpreter file resource is not released. Fix it by adding an error handing path out_free_file, which will release the file resource when interp_elf_ex failed to allocate memory.
    (CVE-2022-50466)

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

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

  - ALSAaoai2sbus修复 i2sbus_add_dev() 中可能的内存泄漏soundbus_add_one() 中的 dev_set_name() 为名称分配内存在 of_device_register() 失败时需要释放调用 soundbus_dev_put() 以放弃 device_initialize 中保持的引用()因此当 refcount 为 0 时可在 kobject_cleanup() 中将其释放。由于还在 i2sbus_release_dev() 中释放其他资源因此可直接返回 0。 (CVE-2022-50431)

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

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

  - Video 中的堆缓冲区溢出漏洞。(CVE-2025-11206)

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

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

  - ibmvnic不在重新打开设备时发生 NON_FATAL 错误时重置 dql 统计信息。所有 ibmvnic 都会重置。对 netdev_tx_reset_queue() 进行调用。 netdev_tx_reset_queue() 可重置 num_queued 和 num_completed 字节计数器。这些统计数据用于字节队列限制 (BQL) 算法。这两个统计数据之间的差异可跟踪物理 NIC 上当前占用的字节数。 ibmvnic 通过调用驱动程序 xmit 函数中的 netdev_tx_sent_queue() 增加排队的字节数。
    当 VIOS 报告其已完成字节传输时ibmvnic 设备会通过调用 netdev_tx_completed_queue() 增加已完成的字节数。请务必注意驱动程序会批处理其传输调用并且每次将 skb 添加到下一个批次时 num_queued 都会增加但不一定在将批次发送到 VIOS 进行传输时增加。与其他重置类型不同的是 NON FATAL 重置不会刷新 sub crq tx 缓冲区。因此批处理的 skb 数组可能会部分填满。因此如果在重新打开设备时存在对 netdev_tx_reset_queue() 的调用则 num_queued 的值 (0) 将不会考虑当前正在批处理的 skb。最终当将该批次发送到 VIOS 时对 netdev_tx_completed_queue() 的调用会将 num_completed 增加到大于 num_queued 的值。这会造成 BUG_ON 崩溃 ibmvnic 30000002 固件报告错误原因：适配器问题。正在启动恢复... ibmvnic 30000002: tx error 600 ibmvnic 30000002: tx error 600 ibmvnic 30000002: tx error 600 ibmvnic 30000002: tx error 600------------[ 在此处剪切 ]-------- ------- lib/dynamic_queue_limits.c:27! 的内核缺陷Oops内核模式中发生异常sig5 [....] NIP dql_completed+0x28/0x1c0 LR ibmvnic_complete_tx.isra.0+0x23c/0x420 [ibmvnic] 调用跟踪ibmvnic_complete_tx.isra.0+0x3f8/0x420 [ibmvnic] (不可靠) ibmvnic_interrupt_tx+0x40/0x70 [ibmvnic] __handle_irq_event_percpu+0x98/0x270 ---[结束跟踪 ]--- 因此执行 NON_FATAL 重置时请勿重置 dql 统计数据。 (CVE-2023-53463)

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

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

  - wifiiwlwifipcie修复 iwl_write_to_user_buf 中的整数溢出 iwl_write_to_user_buf() 函数由 iwl_dbgfs_monitor_data_read() 函数调用时发生整数溢出。 static bool iwl_write_to_user_buf(char __user *user_buf, ssize_t count, void *buf, ssize_t *size, ssize_t
    *bytes_copied) { int buf_size_left = count - *bytes_copied; buf_size_left = buf_size_left - (buf_size_left % sizeof(u32)); if (*size > buf_size_left) *size = buf_size_left;如果用户将 SIZE_MAX 值传递到 ssize_t 计数参数则 ssize_t 计数参数会分配给 int buf_size_left。然后将 *size 与 buf_size_left 进行比较。此处的 buf_size_left 为负数因此 *size 会被分配给 buf_size_left 并进入 copy_to_user 函数的第三个参数从而导致堆溢出。
    这不是安全漏洞因为 iwl_dbgfs_monitor_data_read() 是具有 0400 权限的 debugfs 操作。 (CVE-2023-53524)

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

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

  - 已修复 Linux 内核中的下列漏洞：mm/uffd: fix warning without PTE_MARKER_UFFD_WP compiled in When PTE_MARKER_UFFD_WP not configured, it's still possible to reach pte marker code and trigger an warning. Add a few CONFIG_PTE_MARKER_UFFD_WP ifdefs to make sure the code won't be reached when not compiled in. (CVE-2022-50448)

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

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

  - tipc如果 mtu 协商中的 msg_max 太小则不要更新 mtu进行链路 mtu 协商时恶意对等机可能发送 activate msgmtu 非常小例如 Shuang 的测试中为 4而不检查最小 mtul-> mtu 将在 tipc_link_proto_rcv() 中设置为 4然后 n->links[bearer_id].mtu 设置为 4294967228这是 tipc_link_mss() 中“4 - INT_H_SIZE - EMSG_OVERHEAD”的溢出。tipc_link.mtu = 4 时tipc_link_xmit() 会继续打印警告tipc消息太大正在清除 xmit 列表 1 5 0 40 4! tipc 消息过大，正在清除 xmit 列表 1 15 0 60 4! 且利用 tipc_link_entry.mtu 4294967228在 named_distribute() 中分配大型 skb并在 tipc_link_xmit() 中清除它时甚至造成崩溃一般保护错误可能针对非规范地址 0x2100001011000dd: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 0 Comm: swapper/0 Kdump已加载 未受感染 6.3.0.neta #19 RIP
    0010:kfree_skb_list_reason+0x7e/0x1f0 Call Trace: <IRQ> skb_release_data+0xf9/0x1d0 kfree_skb_reason+0x40/0x100 tipc_link_xmit+0x57a/0x740 [tipc] tipc_node_xmit+0x16c/0x5c0 [tipc] tipc_named_node_up+0x27f/0x2c0 [tipc] tipc_node_write_unlock+0x149/ 0x170 [tipc] tipc_rcv+0x608/0x740 [tipc] tipc_udp_recv+0xdc/0x1f0 [tipc] udp_queue_rcv_one_skb+0x33e/0x620 udp_unicast_rcv_skb.isra.72+0x75/0x90 __udp4_lib_rcv+0x56d/0xc20 ip_protocol_deliver_rcu+0x100/0x2d0 This patch fixes it by checking将新的 mtu 与 tipc_bearer_min_mtu() 对应如果 mtu 太小则不更新 mtu。 (CVE-2023-53517)

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

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

  - 已修复 Linux 内核中的下列漏洞：netfilter: nf_tables: do not ignore genmask when looking up chain by id When adding a rule to a chain referring to its ID, if that chain had been deleted on the same batch, the rule might end up referring to a deleted chain. This will lead to a WARNING like following: [ 33.098431] ------------[ cut here ]------------ [ 33.098678] WARNING: CPU: 5 PID: 69 at net/netfilter/nf_tables_api.c:2037 nf_tables_chain_destroy+0x23d/0x260 [ 33.099217] Modules linked in: [ 33.099388] CPU: 5 PID: 69 Comm: kworker/5:1 Not tainted 6.4.0+ #409 [ 33.099726] Workqueue:
    events nf_tables_trans_destroy_work [ 33.100018] RIP: 0010:nf_tables_chain_destroy+0x23d/0x260 [33.100306] Code: 8b 7c 24 68 e8 64 9c ed fe 4c 89 e7 e8 5c 9c ed fe 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 89 c6 89 c7 c3 cc cc cc cc <0f> 0b 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 89 c6 89 c7 [33.101271] RSP: 0018:ffffc900004ffc48 EFLAGS: 00010202 [ 33.101546] RAX: 0000000000000001 RBX:
    ffff888006fc0a28 RCX: 0000000000000000 [ 33.101920] RDX: 0000000000000000 RSI: 0000000000000000 RDI:
    0000000000000000 [ 33.102649] RBP: ffffc900004ffc78 R08: 0000000000000000 R09: 0000000000000000 [33.103018] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8880135ef500 [ 33.103385] R13:
    0000000000000000 R14: dead000000000122 R15: ffff888006fc0a10 [ 33.103762] FS: 0000000000000000(0000) GS:ffff888024c80000(0000) knlGS:0000000000000000 [ 33.104184] CS: 0010 DS: 0000 ES: 0000 CR0:
    0000000080050033 [ 33.104493] CR2: 00007fe863b56a50 CR3: 00000000124b0001 CR4: 0000000000770ee0 [33.104872] PKRU: 55555554 [ 33.104999] Call Trace: [ 33.105113] <TASK> [ 33.105214] ? show_regs+0x72/0x90 [ 33.105371] ? __warn+0xa5/0x210 [ 33.105520] ? nf_tables_chain_destroy+0x23d/0x260 [ 33.105732] ? report_bug+0x1f2/0x200 [ 33.105902] ? handle_bug+0x46/0x90 [ 33.106546] ? exc_invalid_op+0x19/0x50 [33.106762] ? asm_exc_invalid_op+0x1b/0x20 [ 33.106995] ? nf_tables_chain_destroy+0x23d/0x260 [ 33.107249] ? nf_tables_chain_destroy+0x30/0x260 [ 33.107506] nf_tables_trans_destroy_work+0x669/0x680 [ 33.107782] ? mark_held_locks+0x28/0xa0 [ 33.107996] ? __pfx_nf_tables_trans_destroy_work+0x10/0x10 [ 33.108294] ?
    _raw_spin_unlock_irq+0x28/0x70 [ 33.108538] process_one_work+0x68c/0xb70 [ 33.108755] ? lock_acquire+0x17f/0x420 [ 33.108977] ? __pfx_process_one_work+0x10/0x10 [ 33.109218] ? do_raw_spin_lock+0x128/0x1d0 [ 33.109435] ? _raw_spin_lock_irq+0x71/0x80 [ 33.109634] worker_thread+0x2bd/0x700 [ 33.109817] ? __pfx_worker_thread+0x10/0x10 [ 33.110254] kthread+0x18b/0x1d0 [33.110410] ? __pfx_kthread+0x10/0x10 [ 33.110581] ret_from_fork+0x29/0x50 [ 33.110757] </TASK> [33.110866] irq event stamp: 1651 [ 33.111017] hardirqs last enabled at (1659): [<ffffffffa206a209>]
    __up_console_sem+0x79/0xa0 [ 33.111379] hardirqs last disabled at (1666): [<ffffffffa206a1ee>]
    __up_console_sem+0x5e/0xa0 [ 33.111740] softirqs last enabled at (1616): [<ffffffffa1f5d40e>]
    __irq_exit_rcu+0x9e/0xe0 [ 33.112094] softirqs last disabled at (1367): [<ffffffffa1f5d40e>]
    __irq_exit_rcu+0x9e/0xe0 [ 33.112453] ---[ end trace 0000000000000000 ]--- This is due to the nft_chain_lookup_byid ignoring the genmask. After this change, adding the new rule will fail as it will not find the chain. (CVE-2023-53492)

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

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

  - ubiubi_wl_put_peb修复消耗平衡工作失败时的无限循环下列进程将在 ubi_wl_put_peb() 中触发无限循环ubifs_bgt ubi_bgt ubifs_leb_unmap ubi_leb_unmap ubi_eba_unmap_leb ubi_wl_put_peb break_leveling_worker e1 = rb_entry(rb_first(&ubi->used) e2 = get_ubib) ubi_io_read_vid_hdr // return errflash 错误 out_error: ubi->move_from = ubi->move_to = NULL wl_entry_destroy(ubi, e1) ubi->lookuptbl[e->pnum] = NULL retry: e = ubi->lookuptbl[pnum ]; // 返回 NULL if (e == ubi->move_from) { // NULL == NULL gets true goto retry; // 无限循环 !!! $ top PID USER PR NI VIRT RES SHR S %CPU %MEM COMMAND 7676 root 20 0 0 0 0 R 100.0 0.0 ubifs_bgt0_0 方式修复此问题1) 如果从“ubi->lookuptbl”删除earl 平衡条目则使 ubi_wl_put_peb() 直接返回。 2) 使用“ubi->wl_lock”保护 wl 条目删除以防止 ubi_wl_put_peb() 中 wl 条目出现释放后使用问题。在 [Link] 中获取复制器。 (CVE-2023-53481)

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

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

  - gpuhost1x修复设备名称的内存泄漏 dev_set_name() 分配的设备名称需要在模块卸载之前释放但实际上无法释放因为在 device_initialize() 中设置的 kobject 的 refcount 尚未减少到 0。正如 device_add() 的注释所述if it failed, use only put_device() drop the refcount,then the namewill be free in kobejct_cleanup()。 device_del() 和 put_device() 可替换为 device_unregister()因此调用此函数以取消注册已成功添加的设备并仅对未添加的设备调用 put_device()。向设备添加 release() 函数以避免空 release() 函数 device_release() 中警告其为空因为 host1x_memory_context_list_free() 中会一起释放上下文设备。 (CVE-2023-53514)

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

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

  - iw_cxgb4修复 c4iw_fill_res_cm_id_entry() 中潜在的空取消引用 此条件需要与之前的 if (epcp->state == LISTEN) { 完全匹配以避免 listen_ep 或 ep 的空取消引用。
    问题在于 epcp 已被重新分配因此第二次测试 if (epcp->state == LISTEN) { 是不够的。 (CVE-2023-53476)

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

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

  - 已修复 Linux 内核中的下列漏洞：RDMA/cma: Allow UD qp_type to join multicast only As for multicast: - The SIDR is the only mode that makes sense; - Besides PS_UDP, other port spaces like PS_IB is also allowed, as it is UD compatible. In this case qkey also needs to be set [1]. This patch allows only UD qp_type to join multicast, and set qkey to default if it's not set, to fix an uninit-value error: the ib->rec.qkey field is accessed without being initialized.
    ===================================================== BUG: KMSAN: uninit-value in cma_set_qkey drivers/infiniband/core/cma.c:510 [inline] BUG: KMSAN: uninit-value in cma_make_mc_event+0xb73/0xe00 drivers/infiniband/core/cma.c:4570 cma_set_qkey drivers/infiniband/core/cma.c:510 [inline] cma_make_mc_event+0xb73/0xe00 drivers/infiniband/core/cma.c:4570 cma_iboe_join_multicast drivers/infiniband/core/cma.c:4782 [inline] rdma_join_multicast+0x2b83/0x30a0 drivers/infiniband/core/cma.c:4814 ucma_process_join+0xa76/0xf60 drivers/infiniband/core/ucma.c:1479 ucma_join_multicast+0x1e3/0x250 drivers/infiniband/core/ucma.c:1546 ucma_write+0x639/0x6d0 drivers/infiniband/core/ucma.c:1732 vfs_write+0x8ce/0x2030 fs/read_write.c:588 ksys_write+0x28c/0x520 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __ia32_sys_write+0xdb/0x120 fs/read_write.c:652 do_syscall_32_irqs_on arch/x86/entry/common.c:114 [inline] __do_fast_syscall_32+0x96/0xf0 arch/x86/entry/common.c:180 do_fast_syscall_32+0x34/0x70 arch/x86/entry/common.c:205 do_SYSENTER_32+0x1b/0x20 arch/x86/entry/common.c:248 entry_SYSENTER_compat_after_hwframe+0x4d/0x5c Local variable ib.i created at: cma_iboe_join_multicast drivers/infiniband/core/cma.c:4737 [inline] rdma_join_multicast+0x586/0x30a0 drivers/infiniband/core/cma.c:4814 ucma_process_join+0xa76/0xf60 drivers/infiniband/core/ucma.c:1479 CPU:
    0 PID: 29874 Comm: syz-executor.3 Not tainted 5.16.0-rc3-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 ===================================================== [1] https://lore.kernel.org/linux-rdma/20220117183832.GD84788@nvidia.com/ (CVE-2023-53525)

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

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

  - 已修复 Linux 内核中的下列漏洞：HID: mcp-2221: prevent UAF in delayed work If the device is plugged/unplugged without giving time for mcp_init_work() to complete, we might kick in the devm free code path and thus have unavailable struct mcp_2221 while in delayed work. Canceling the delayed_work item is enough to solve the issue, because cancel_delayed_work_sync will prevent the work item to requeue itself. (CVE-2023-53459)

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

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

  - wifirtw89修复 napi_init 和 napi_enable 之间可能的争用条件。如果 netdev 已注册但 NAPI 尚未初始化同时用户空间启动将启用 NAPI 的 netdev则可能发生争用条件。然后命中 BUG_ON(): kernel BUG at net/core/dev.c:6423!无效 opcode0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 417 Comm: iwd Not tainted 6.2.7-slab-dirty #3 eb0f5a8a9d91 硬件名称LENOVO 21DL/LNVNB161216、BIOS JPCN20WW(V1.06) 09/ 20/2022 RIP0010:napi_enable+0x3f/0x50 代码48 89 c2 48 83 e2 f6 f6 81 89 08 00 00 02 74 0d 48 83 ... RSP0018:ffffada1414f3548 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffa01425802080 RCX: 0000000000000000 RDX: 00000000000002ff RSI: ffffada14e5000000000000002ff
    ffffa01425808dc0 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000100 R12: ffffa01425808f58 R13: 0000000000000000 R14: ffffa01423498940 R15:
    0000000000000001 FS: 00007f5577c0a740(0000) GS:ffffa0169fc00000(0000) knlGS:0000000000000000 CS: 0010 DS:
    0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f5577a19972 CR3: 0000000125a7a000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> rtw89_pci_ops_start+0x1c/0x70 [rtw89_pci 6cbc75429515c181cbc386478d5cfb32ffc5a0f8] rtw89_core_start+0xbe/0x160 [rtw89_core fe07ecb874820b6d778370d4acb6ef8a37847f22] rtw89_ops_start+0x26/0x40 [rtw89_core fe07ecb874820b6d778370d4acb6ef8a37847f22 ] drv_start+0x42/0x100 [mac80211 c07fa22af8c3cf3f7d7ab3884ca990784d72e2d2] ieee80211_do_open+0x311/0x7d0 [mac80211 c07fa22af8c3cf3f7d7ab3884ca990784d72e2d2] ieee80211_open+0x6a/0x90 [mac80211 c07fa22af8c3cf3f7d7ab3884ca990784d72e2d2] __dev_open+0xe0/0x180 __dev_change_flags+0x1da/0x250 dev_change_flags+0x26/0x70 do_setlink+0x37c/0x12c0 ? ep_poll_callback+0x246/0x290
    __nla_validate_parse+0x61/0xd00 ? __wake_up_common_lock+0x8f/0xd0 要修复此问题请按照 Jonas的建议交换这些函数的顺序并将寄存器 netdev 移至 PCI 探测的最后一步。此外修正了 rtw89_core_register_hw() 的错误处理。 (CVE-2023-53452)

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

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

  - Tab 中的边信道信息泄漏。 (CVE-2025-11210)

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

ID	名称	严重性
269568	Linux Distros 未修补的漏洞：CVE-2023-53453	medium
269567	Linux Distros 未修补的漏洞：CVE-2025-11215	critical
269566	Linux Distros 未修补的漏洞：CVE-2022-50452	medium
269565	Linux Distros 未修补的漏洞：CVE-2022-50439	high
269564	Linux Distros 未修补的漏洞：CVE-2022-50460	high
269563	Linux Distros 未修补的漏洞：CVE-2023-53475	medium
269562	Linux Distros 未修补的漏洞：CVE-2023-53488	medium
269561	Linux Distros 未修补的漏洞：CVE-2023-53511	medium
269560	Linux Distros 未修补的漏洞：CVE-2023-53451	medium
269559	Linux Distros 未修补的漏洞：CVE-2023-53509	medium
269558	Linux Distros 未修补的漏洞：CVE-2023-53521	high
269557	Linux Distros 未修补的漏洞：CVE-2023-53501	medium
269556	Linux Distros 未修补的漏洞：CVE-2023-53520	medium
269555	Linux Distros 未修补的漏洞：CVE-2022-50461	high
269554	Linux Distros 未修补的漏洞：CVE-2023-53522	medium
269553	Linux Distros 未修补的漏洞：CVE-2023-53486	medium
269552	Linux Distros 未修补的漏洞：CVE-2022-50421	high
269551	Linux Distros 未修补的漏洞：CVE-2023-53469	high
269550	Linux Distros 未修补的漏洞：CVE-2022-50436	medium
269549	Linux Distros 未修补的漏洞：CVE-2022-50451	medium
269548	Linux Distros 未修补的漏洞：CVE-2022-50425	medium
269547	Linux Distros 未修补的漏洞：CVE-2022-50433	high
269546	Linux Distros 未修补的漏洞：CVE-2022-50468	medium
269545	Linux Distros 未修补的漏洞：CVE-2023-53473	medium
269544	Linux Distros 未修补的漏洞：CVE-2022-50420	medium
269543	Linux Distros 未修补的漏洞：CVE-2022-50422	high
269542	Linux Distros 未修补的漏洞：CVE-2022-50426	medium
269541	Linux Distros 未修补的漏洞：CVE-2025-11219	critical
269540	Linux Distros 未修补的漏洞：CVE-2023-53484	high
269539	Linux Distros 未修补的漏洞：CVE-2023-53531	medium
269538	Linux Distros 未修补的漏洞：CVE-2023-53506	medium
269537	Linux Distros 未修补的漏洞：CVE-2023-53503	medium
269536	Linux Distros 未修补的漏洞：CVE-2023-53450	medium
269535	Linux Distros 未修补的漏洞：CVE-2023-53457	high
269534	Linux Distros 未修补的漏洞：CVE-2022-50441	medium
269533	Linux Distros 未修补的漏洞：CVE-2022-50466	medium
269532	Linux Distros 未修补的漏洞：CVE-2022-50431	medium
269531	Linux Distros 未修补的漏洞：CVE-2025-11206	critical
269530	Linux Distros 未修补的漏洞：CVE-2023-53463	medium
269529	Linux Distros 未修补的漏洞：CVE-2023-53524	high
269528	Linux Distros 未修补的漏洞：CVE-2022-50448	high
269527	Linux Distros 未修补的漏洞：CVE-2023-53517	medium
269526	Linux Distros 未修补的漏洞：CVE-2023-53492	high
269525	Linux Distros 未修补的漏洞：CVE-2023-53481	medium
269524	Linux Distros 未修补的漏洞：CVE-2023-53514	medium
269523	Linux Distros 未修补的漏洞：CVE-2023-53476	medium
269522	Linux Distros 未修补的漏洞：CVE-2023-53525	high
269521	Linux Distros 未修补的漏洞：CVE-2023-53459	medium
269520	Linux Distros 未修补的漏洞：CVE-2023-53452	high
269519	Linux Distros 未修补的漏洞：CVE-2025-11210	critical

检测

Nessus 的 Misc. 系列

medium

critical

medium

high

high

medium

medium

medium

medium

medium

high

medium

medium

high

medium

medium

high

high

medium

medium

medium

high

medium

medium

medium

high

medium

critical

high

medium

medium

medium

medium

high

medium

medium

medium

critical

medium

high

high

medium

high

medium

medium

medium

high

medium

high

critical