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 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - netfilternft_set_rbtree修复元素插入时的空取消引用 不保证 rb_prev() 不会在 nft_rbtree_gc_elem() 中返回空一般保护错误可能针对非规范地址 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN KASAN范围 [0x00000000000000001f] nft_add_set_elem+0x14b0/0x2990 nf_tables_newsetelem+0x528/0xb30 中存在 null-ptr-deref 此外迭代时可能存在释放后使用“node”可能会被释放因此我们需要缓存下一个要使用的值。 (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 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - sctp在 sctp_stream_priorities 中添加 refcnt 以避免嵌套循环在 sctp_stream_priorities 中添加此 refcnt后我们在 sctp_sched_prio_free_sid() 中释放一个流的 prio 时不需要遍历所有流来检查 prio 是否由其他流使用。此可避免嵌套循环最多 65535 * 65535该循环可造成卡住如 Ying 所报告watchdog: BUGsoft lockup - CPU#23 卡住达 26s! [ksoftirqd/23:136] 调用跟踪 <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] 请注意不需要为此计数器使用 refcount_t 类型因为其访问始终受到 sock 锁定的保护。 v1->v2 - 在 sctp_sched_prio_set 中添加检查以避免可能的 prio_head refcnt 溢出。 (CVE-2023-53590)

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

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

  - s390/zcrypt如果 dev_set_name() 失败则不泄漏内存 dev_set_name() 失败时zcdn_create() 不会释放新分配的资源。照做。 (CVE-2023-53568)

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

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

  - blk-crypto使 blk_crypto_evict_key() 更可靠如果 blk_crypto_evict_key() 发现密钥仍在使用中由于缺陷或者 ->keyslot_evict 失败则其目前仅返回同时将密钥链接至键槽管理有关的矢量影响可用性。但是blk_crypto_evict_key() 仅在诸如 inode 逐出其中不包含失败的选项的上下文中调用。因此实际上调用程序会继续释放 blk_crypto_key而不管 blk_crypto_evict_key() 的返回值如何。这两个假设不匹配进而导致在发生这些错误之一之后blk_crypto_reprogram_all_keys() 中可能存在释放后使用。请注意这些错误“不应该”*发生我们只是在讨论如果它们发生了会发生什么。)修复此错误的方法是使 blk_crypto_evict_key() 在失败时取消与 keyslot 管理结构的密钥链接。还改进了一些注释。 (CVE-2023-53536)

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

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

  - iommu/amd修复 ppr_notifier() 中的 pci 设备引用计数泄漏 正如 pci_get_domain_bus_and_slot() 的注释所述它将返回 refcount 递增的 pci 设备当完成使用时调用程序必须通过调用 pci_dev_put() 来递减引用计数。因此请在从 ppr_notifier() 返回之前调用它以避免 refcount 泄漏。 (CVE-2022-50505)

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

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

  - cpufreq在 cpufreq_policy_alloc() 中的 kobject_init_and_add() 之前完成初始化当 kobject_init_and_add() 失败时它将调用 cpufreq_sysfs_release() 中的未初始化完成。并且这将造成崩溃例如以下的页面错误 complete: 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 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - clkimxscu使用 _safe 列表迭代器以避免释放后使用 此循环由于释放 clk因此需要使用 list_for_each_entry_safe()。否则它会取消引用已释放的变量以获取循环中的下一项。 (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 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - coresightcti修复 cti_disable_hw() 中的挂起从原子上下文调用 cti_enable_hw() 和 cti_disable_hw()因此不应使用运行时 PM因为它可在与固件通信时导致休眠。自 提交 3c6656337852恢复固件 arm_scmi向 SCMI 电源域添加时钟管理起运行 Perf Coresight 测试或运行 perf record -e cs_etm//u -- ls 命令时这会造成 Juno 挂起 perf record -e cs_etm//u -- ls错过了直到恢复提交因为在提交 692c9a499b28 之前使用错误的设备调用了 pm_runtime_put()coresightcti更正 pm_runtime_put 的参数锁定和计划程序调试启用了以下输出coresight cti_sys0
    cti_enable_hw -- dev:cti_sys0 parent20020000.cti BUG从 drivers/base/power/runtime.c:1151 的无效上下文调用的休眠函数 in_atomic()1、irqs_disabled()128、non_block: 0、pid: 330名称
    perf-exec preempt_count: 2、预期: 0 RCU 嵌套深度: 0、预期: 0 INFOlockdep 已关闭。 irq 事件标记0 hardirqs 上次启用的时间 (0): [<0000000000000000>] 0x0 hardirqs 上次禁用的时间 (0)
    [<ffff80000822b394>] copy_process+0xa0c/0x1948 softirqs 上次启用的时间为 (0): [<ffff80000822b394>] copy_process+0xa0c/0x1948 softirqs 上次禁用的时间为 (0)[<0000000000000000>] 0x0 CPU: 3 PID: 330 Comm
    perf-exec Not tainted 6.0.0-00053-g042116d99298 #7 硬件名称ARMLTD ARM Juno Development Platform/ARM Juno Development PlatformBIOS EDK II 2022 年 9 月 13 日调用跟踪 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完全可以。此处不需要它们因为在构建跟踪的路径时它们一定已经完成。[修复版本警告] (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 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - irqchip修复 platform_irqchip_probe 中的引用计数泄漏 of_irq_find_parent() 返回引用计数递增的节点指针不再需要时应使用 of_node_put()。添加缺少的 of_node_put() 以避免 refcount 泄漏。 (CVE-2023-53610)

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

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

  - net/mlx5e修复 tc 路由查询代码中的死锁。在保留 devcom rw 信号量的同时创建对等流时被引用的提交会导致 ABBA 死锁[0]。由于对等流卸载实现的原因已在调用链的上游取得锁定并且没有明显的方法可以轻松修复死锁。而是由于 tc 路由查询代码需要对等 eswitch 结构以在 xarray 中执行查找而不会执行任何休眠操作请通过以下方式重构代码以进行无锁执行- RCUify devcom“data”指针。当重置指针时请在返回前同步等待 RCU 宽限期。这没有问题因为 devcom 当前仅用于 eswitch 的配对/取消配对同步这种情况很少见而且本身成本就已经很高。- 在 {READ|WRITE}_ONCE() 中封装“paired”布尔值的所有使用。已在某些未锁定的上下文中使用该标记而无正确的注释例如 mlx5_devcom_is_paired() 函数的用户但这不是问题因为所有相关的代码路径在获取 devcom 信号量后会再次对其进行检查。现在它也被 mlx5_devcom_get_peer_data_rcu() 用作尽力检查在 devcom 取消配对时返回 NULL。请注意虽然 RCU 读取锁定不能阻止同时更改不配对标记但其仍保证读取器可继续使用“数据”。- 重构 mlx5e_tc_query_route_vport() 函数以使用新的 mlx5_devcom_get_peer_data_rcu() API其修复了死锁。 [0][ 164.599612] ========================================== ============ [ 164.600142] 警告检测到可能的循环锁定依赖 [ 164.600667] 6.3.0-rc3+ #1 未受感染 [ 164.601021]
    -------------------------------------------------- ---- [ 164.601557] handler1/3456 正在尝试获取锁定[ 164.601998] ffff88811f1714b0 (&esw->offloads.encap_tbl_lock){+.+.}-{3:3}位于
    mlx5e_attach_encap+0xd8/0x8b0 [mlx5_core] [ 164.603078] 但任务已持有锁定[ 164.603617] ffff88810137fc98 (&comp->sem){++++}-{3:3}位于 mlx5_devcom_get_peer_data+0x37/0x80 [ mlx5_core] [164.604459] 哪个锁已依赖于新锁。 [ 164.605190] 现有依存关系链逆序为[ 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 164.609063/ 0xc0 [mlx5_core] [ 164.607914] mlx5e_tc_tun_route_lookup+0x1a4/0x1d0 [mlx5_core] 164.608495mlx5e_attach_decap_route [x5e_attach_decap_route] [x5e_attach_decap_route]  ] 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_af ter_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 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - ethalx恢复时进行 rtnl_lock Zbynek 报告 alx 在 resume: RTNL:
    net/core/dev.c 上的断言失败 (2891) RIP0010:netif_set_real_num_tx_queues+0x1ac/0x1c0 调用跟踪
    <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确实驱动程序在暂停/恢复期间在其内部关闭和重新打开期间未保持 rtnl_lock 。请注意这不是一个大缺陷因为驱动程序会实现其自己的锁定并且不会实现队列数的更改但我们需要使 splat 停止显示。
    (CVE-2022-50498)

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

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

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

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

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

  - netqrtr修复了 qrtr_tx_resume() 中的 uninit 变量访问缺陷 Syzbot 报告了如下缺陷
    ================================================== === BUGKMSANqrtr_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. 中的 uninit-value。 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 [内联]
    __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 [内联] do_syscall_64+0x3d/0xb0 arch/x86/entry/ common.c:80 entry_SYSCALL_after_hwframe+0x63/0xcd Uninit 被创建于 slab_post_alloc_hook mm/slab.h:766 [内联] slab_alloc_node mm/slub.c:3452 [内联] __kmem_cache_alloc_node+0x71f/0xce0 mm/slub.c:3491
    __do_kmalloc_node mm/slab_common.c:967 [内联] __kmalloc_node_track_caller+0x114/0x3b0 mm/slab_common.c:988 kmalloc_reserve net/core/skbuff.c:492 [内联] __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 [内联] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd 是因为 skb->len 要求 qrtr_tx_resume() 中至少具有 sizeof(struct qrtr_ctrl_pkt)。skb->len 等于 qrtr_endpoint_post() 中的大小。但在 syzbot 情况下当 qrtr_cb->type 等于 qrtr_endpoint_post() 中的 QRTR_TYPE_RESUME_TX 时大小小于 sizeof(struct qrtr_ctrl_pkt)。这会触发 uninit 变量访问缺陷。当 qrtr_cb->type 等于 qrtr_endpoint_post() 中的 QRTR_TYPE_RESUME_TX 时添加大小检查以修复 缺陷。 (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 依赖供应商报告的程序包是否存在进行判断。

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

  - 已修复 Linux 内核中的下列漏洞：media: dvb-core: Fix double free in dvb_register_device() In function dvb_register_device() -> dvb_register_media_device() -> dvb_create_media_entity(), dvb->entity is allocated and initialized. If the initialization fails, it frees the dvb->entity, and return an error code. The caller takes the error code and handles the error by calling dvb_media_device_free(), which unregisters the entity and frees the field again if it is not NULL.
    As dvb->entity may not NULLed in dvb_create_media_entity() when the allocation of dvbdev->pad fails, a double free may occur. This may also cause an Use After free in media_device_unregister_entity(). Fix this by storing NULL to dvb->entity when it is freed. (CVE-2022-50499)

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

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

  - 解析 DHAV 文件的标头时在偏移计算中存在整数下溢这会导致读取来自分配的缓冲区开始之前的持续时间。如果加载的 DHAV 文件大于 MAX_DURATION_BUFFER_SIZE 字节 (0x100000)例如 0x101000 字节则在 [0] 时大小为 0x101000。在 [1] 中end_buffer_size = 0x100000在 [2] 中end_buffer_pos = 0x1000。然后该循环会向后扫描整个缓冲区以查找 dhav 标签找到时我们将根据从缓冲区读取的 32 位偏移来计算 end_pos。随后会检查 [3]确保 end_pos 是否在已复制到 end_buffer 中的文件部分内但它仅正确处理 end_pos 在文件开始之前或在复制到 end_buffer 中的部分之后的情况而不是end_pos 在文件内但在复制到 end_buffer 中的部分之前的情况。如果提供此类偏移end_pos - end_buffer_pos 可能会下溢导致在开始分配之前发生 [4] 的后续访问。建议升级到版本 8.0 或更高版本。
    (CVE-2025-59729)

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

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

  - 已修复 Linux 内核中的下列漏洞：crypto: ccp - Always pass in an error pointer to __sev_platform_shutdown_locked() When 9770b428b1a2 (crypto: ccp - Move dev_info/err messages for SEV/SNP init and shutdown) moved the error messages dumping so that they don't need to be issued by the callers, it missed the case where __sev_firmware_shutdown() calls __sev_platform_shutdown_locked() with a NULL argument which leads to a NULL ptr deref on the shutdown path, during suspend to disk: #PF:
    supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops:
    0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 983 Comm: hib.sh Not tainted 6.17.0-rc4+ #1 PREEMPT(voluntary) Hardware name: Supermicro Super Server/H12SSL-i, BIOS 2.5 09/08/2022 RIP:
    0010:__sev_platform_shutdown_locked.cold+0x0/0x21 [ccp] That rIP is: 00000000000006fd <__sev_platform_shutdown_locked.cold>: 6fd: 8b 13 mov (%rbx),%edx 6ff: 48 8b 7d 00 mov 0x0(%rbp),%rdi 703:
    89 c1 mov %eax,%ecx Code: 74 05 31 ff 41 89 3f 49 8b 3e 89 ea 48 c7 c6 a0 8e 54 a0 41 bf 92 ff ff ff e8 e5 2e 09 e1 c6 05 2a d4 38 00 01 e9 26 af ff ff <8b> 13 48 8b 7d 00 89 c1 48 c7 c6 18 90 54 a0 89 44 24 04 e8 c1 2e RSP: 0018:ffffc90005467d00 EFLAGS: 00010282 RAX: 00000000ffffff92 RBX: 0000000000000000 RCX:
    0000000000000000 ^^^^^^^^^^^^^^^^ and %rbx is nice and clean. Call Trace: <TASK>
    __sev_firmware_shutdown.isra.0 sev_dev_destroy psp_dev_destroy sp_destroy pci_device_shutdown device_shutdown kernel_power_off hibernate.cold state_store kernfs_fop_write_iter vfs_write ksys_write do_syscall_64 entry_SYSCALL_64_after_hwframe Pass in a pointer to the function-local error var in the caller. With that addressed, suspending the ccp shows the error properly at least: ccp 0000:47:00.1: sev command 0x2 timed out, disabling PSP ccp 0000:47:00.1: SEV: failed to SHUTDOWN error 0x0, rc -110 SEV-SNP:
    Leaking PFN range 0x146800-0x146a00 SEV-SNP: PFN 0x146800 unassigned, dumping non-zero entries in 2M PFN region: [0x146800 - 0x146a00] ... ccp 0000:47:00.1: SEV-SNP firmware shutdown failed, rc -16, error 0x0 ACPI: PM: Preparing to enter system sleep state S5 kvm: exiting hardware virtualization reboot: Power down Btw, this driver is crying to be cleaned up to pass in a proper I/O struct which can be used to store information between the different functions, otherwise stuff like that will happen in the future again.
    (CVE-2025-39936)

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

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

  - 已修复 Linux 内核中的下列漏洞：net: enetc: avoid buffer leaks on xdp_do_redirect() failure Before enetc_clean_rx_ring_xdp() calls xdp_do_redirect(), each software BD in the RX ring between index orig_i and i can have one of 2 refcount values on its page. We are the owner of the current buffer that is being processed, so the refcount will be at least 1. If the current owner of the buffer at the diametrically opposed index in the RX ring (i.o.w, the other half of this page) has not yet called kfree(), this page's refcount could even be 2. enetc_page_reusable() in enetc_flip_rx_buff() tests for the page refcount against 1, and [ if it's 2 ] does not attempt to reuse it. But if enetc_flip_rx_buff() is put after the xdp_do_redirect() call, the page refcount can have one of 3 values.
    It can also be 0, if there is no owner of the other page half, and xdp_do_redirect() for this buffer ran so far that it triggered a flush of the devmap/cpumap bulk queue, and the consumers of those bulk queues also freed the buffer, all by the time xdp_do_redirect() returns the execution back to enetc. This is the reason why enetc_flip_rx_buff() is called before xdp_do_redirect(), but there is a big flaw with that reasoning: enetc_flip_rx_buff() will set rx_swbd->page = NULL on both sides of the enetc_page_reusable() branch, and if xdp_do_redirect() returns an error, we call enetc_xdp_free(), which does not deal gracefully with that. In fact, what happens is quite special. The page refcounts start as 1.
    enetc_flip_rx_buff() figures they're reusable, transfers these rx_swbd->page pointers to a different rx_swbd in enetc_reuse_page(), and bumps the refcount to 2. When xdp_do_redirect() later returns an error, we call the no-op enetc_xdp_free(), but we still haven't lost the reference to that page. A copy of it is still at rx_ring->next_to_alloc, but that has refcount 2 (and there are no concurrent owners of it in flight, to drop the refcount). What really kills the system is when we'll flip the rx_swbd->page the second time around. With an updated refcount of 2, the page will not be reusable and we'll really leak it.
    Then enetc_new_page() will have to allocate more pages, which will then eventually leak again on further errors from xdp_do_redirect(). The problem, summarized, is that we zeroize rx_swbd->page before we're completely done with it, and this makes it impossible for the error path to do something with it. Since the packet is potentially multi-buffer and therefore the rx_swbd->page is potentially an array, manual passing of the old pointers between enetc_flip_rx_buff() and enetc_xdp_free() is a bit difficult. For the sake of going with a simple solution, we accept the possibility of racing with xdp_do_redirect(), and we move the flip procedure to execute only on the redirect success path. By racing, I mean that the page may be deemed as not reusable by enetc (having a refcount of 0), but there will be no leak in that case, either. Once we accept that, we have something better to do with buffers on XDP_REDIRECT failure. Since we haven't performed half-page flipping yet, we won't, either (and this way, we can avoid enetc_xdp_free() completely, which gives the entire page to the slab allocator). Instead, we'll call enetc_xdp_drop(), which will recycle this half of the buffer back to the RX ring. (CVE-2022-50483)

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

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

  - ASoC 编解码器sma1307修复 sma1307_setting_loaded() 中的内存损坏 sma1307->set.header_size 是指标头中所含整数的数量有 8 但我们没有分配 8 个整数的空间而是分配 8 个字节。当我们在下一行复制数据时这会导致内存损坏
    memcpy(sma1307->set.header, data, sma1307->set.header_size * sizeof(int));此外由于我们立即复制 ->set.header 中的内存因此无需在分配器中将其归零。改用 devm_kmalloc_array() 分配内存。 (CVE-2025-39935)

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

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

  - mtdlpddr2_nvm修复可能的 null-ptr-deref 当 resource_size(add_range) 调用时如果 platform_get_resource() 返回 NULL它将导致 null-ptr-deref。 (CVE-2022-50503)

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

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

  - 已修复 Linux 内核中的下列漏洞：Input: raspberrypi-ts - fix refcount leak in rpi_ts_probe rpi_firmware_get() take reference, we need to release it in error paths as well. Use devm_rpi_firmware_get() helper to handling the resources. Also remove the existing rpi_firmware_put().
    (CVE-2023-53533)

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

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

  - stagingks7010ks_wlan_set_encode_ext() 中存在缓冲区溢出 exc->key_len 是来自 user 的 u16 密钥。超过 IW_ENCODING_TOKEN_MAX (64) 可导致内存损坏。
    (CVE-2023-53554)

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

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

  - 解码使用 DWAA 或 DWAB 压缩的 OpenEXR 文件时存在高度和宽度可被 8 整除的隐式假设。如果图像的高度或宽度不可被 8 整除则复制会在 [0] 和 [ 1] 将继续写入直到下一个 8 的倍数。缓冲区 td->uncompressed_data 是根据图像的精确高度和宽度在 decode_block 中分配的因此复制循环中向上舍入的 8 的倍数可能会超过缓冲区界，并且在 [2] 处开始的写入区块会损坏后续的堆内存。建议升级到版本 8.0 或更高版本。 (CVE-2025-59732)

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

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

  - 解码使用 DWAA 或 DWAB 压缩的 OpenEXR 文件时在使用游程长度编码数据计算输出数据时未检查游程长度编码数据的指定原始长度。我们从 [0] 的输入文件读取 rle_raw_size我们会解压缩并解码到 [1] 的 rle_raw_size 大小的缓冲区 td->rle_raw_data然后在 [2] 我们将访问此缓冲区中直到 td-> xsize - 1) * (td->ysize - 1) + rle_raw_size / 2可能超过 rle_raw_size。建议升级到版本 8.0 或更高版本。
    (CVE-2025-59731)

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

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

  - 已修复 Linux 内核中的下列漏洞：usb: gadget: u_serial: Add null pointer check in gserial_resume Consider a case where gserial_disconnect has already cleared gser->ioport.
    And if a wakeup interrupt triggers afterwards, gserial_resume gets called, which will lead to accessing of gser->ioport and thus causing null pointer dereference.Add a null pointer check to prevent this. Added a static spinlock to prevent gser->ioport from becoming null after the newly added check. (CVE-2023-53551)

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

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

  - nilfs2修复 nilfs_segctor_thread() 中 struct nilfs_sc_info 的潜在 UAF nilfs_segctor_thread() 的最终实现可与 nilfs_segctor_kill_thread() 争用从而终止该线程从而可能造成 KASAN 检测到的释放后使用缺陷。在 nilfs_segctor_thread() 结束时先向结构 nilfs_sc_info 的 sc_task 成员分配 NULL 以指示线程已完成然后使用结构 nilfs_sc_info 上的等待队列 sc_wait_task 将此情况通知 nilfs_segctor_kill_thread()。然而在此紧接着将空值分配给 sc_task 之后nilfs_segctor_kill_thread() 可能会检测到并返回以继续解除分配从而在线程进行通知之前释放 nilfs_sc_info 结构。这通过使用 struct nilfs_sc_info 的旋转锁 sc_state_lock 保护 sc_task 的空分配及其通知来修复此问题。由于 nilfs_segctor_kill_thread() 会在 sc_state_lock 锁定的情况下进行最终检查查看 sc_task 是否为空因此这可以消除争用。
    (CVE-2023-53608)

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

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

  - 对使用 DWAA 或 DWAB 压缩的 OpenEXR 文件进行解码时存在一个隐式假设所有图像通道都具有相同的像素类型和大小并且如果有四个通道则前四个为 B、G、R 和 A 。通道解析代码可在 decode_header 中找到。会在 decode_block 中根据 xsize、ysize 和计算得到的 current_channel_offset 在 decode_block 中分配缓冲区 td->uncompressed_data。然后函数 dwa_uncompress在 [5] 中假设如果有 4 个通道即 B、G、R 和 A并且在 [6] 和 [7] 中的计算中假设所有通道均为相同类型该类型与主要颜色通道的类型。如果将主颜色通道设置为 4 字节类型并添加 2 字节 EXR_HALF 类型的重复或未知通道则 [7] 中的添加会将指针增加 4 字节 * xsize * nb_channels这将超过分配的缓冲区。建议升级到版本 8.0 或更高版本。 (CVE-2025-59733)

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

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

  - Litestar 是一个异步服务器网关接口 (ASGI) 框架。在版本 2.17.0中通过操纵 X-Forwarded-For 标头可完全绕过速率限制。这使得基于 IP 的速率限制对既定的攻击者无效。Litestar 的 RateLimitMiddleware 使用“cache_key_from_request()”来生成缓存密钥以进行速率限制。存在 X-Forwarded-For 标头时中间件会无条件信任该标头并使用其值作为客户端标识符的一部分。由于客户端可设置任意 X-Forwarded-For 值因此每个不同的伪造 IP 都会创建单独的速率限制存储段。攻击者可以轮换不同的标头值以避免达到任何单个存储段的限制。这会影响以默认设置使用 RateLimitMiddleware 的所有 Litestar 应用程序其中可能包括实现速率限制的大多数应用程序。 2.18.0 版中包含针对 漏洞的修补程序。
    (CVE-2025-59152)

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

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

  - 已修复 Linux 内核中的下列漏洞：perf: RISC-V: Remove PERF_HES_STOPPED flag checking in riscv_pmu_start() Since commit 096b52fd2bb4 (perf: RISC-V: throttle perf events) the perf_sample_event_took() function was added to report time spent in overflow interrupts. If the interrupt takes too long, the perf framework will lower the sysctl_perf_event_sample_rate and max_samples_per_tick.
    When hwc->interrupts is larger than max_samples_per_tick, the hwc->interrupts will be set to MAX_INTERRUPTS, and events will be throttled within the __perf_event_account_interrupt() function.
    However, the RISC-V PMU driver doesn't call riscv_pmu_stop() to update the PERF_HES_STOPPED flag after perf_event_overflow() in pmu_sbi_ovf_handler() function to avoid throttling. When the perf framework unthrottled the event in the timer interrupt handler, it triggers riscv_pmu_start() function and causes a WARN_ON_ONCE() warning, as shown below: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 240 at drivers/perf/riscv_pmu.c:184 riscv_pmu_start+0x7c/0x8e Modules linked in: CPU: 0 PID: 240 Comm: ls Not tainted 6.4-rc4-g19d0788e9ef2 #1 Hardware name: SiFive (DT) epc : riscv_pmu_start+0x7c/0x8e ra :
    riscv_pmu_start+0x28/0x8e epc : ffffffff80aef864 ra : ffffffff80aef810 sp : ffff8f80004db6f0 gp :
    ffffffff81c83750 tp : ffffaf80069f9bc0 t0 : ffff8f80004db6c0 t1 : 0000000000000000 t2 : 000000000000001f s0 : ffff8f80004db720 s1 : ffffaf8008ca1068 a0 : 0000ffffffffffff a1 : 0000000000000000 a2 :
    0000000000000001 a3 : 0000000000000870 a4 : 0000000000000000 a5 : 0000000000000000 a6 : 0000000000000840 a7 : 0000000000000030 s2 : 0000000000000000 s3 : ffffaf8005165800 s4 : ffffaf800424da00 s5 :
    ffffffffffffffff s6 : ffffffff81cc7590 s7 : 0000000000000000 s8 : 0000000000000006 s9 : 0000000000000001 s10: ffffaf807efbc340 s11: ffffaf807efbbf00 t3 : ffffaf8006a16028 t4 : 00000000dbfbb796 t5 :
    0000000700000000 t6 : ffffaf8005269870 status: 0000000200000100 badaddr: 0000000000000000 cause:
    0000000000000003 [<ffffffff80aef864>] riscv_pmu_start+0x7c/0x8e [<ffffffff80185b56>] perf_adjust_freq_unthr_context+0x15e/0x174 [<ffffffff80188642>] perf_event_task_tick+0x88/0x9c [<ffffffff800626a8>] scheduler_tick+0xfe/0x27c [<ffffffff800b5640>] update_process_times+0x9a/0xba [<ffffffff800c5bd4>] tick_sched_handle+0x32/0x66 [<ffffffff800c5e0c>] tick_sched_timer+0x64/0xb0 [<ffffffff800b5e50>] __hrtimer_run_queues+0x156/0x2f4 [<ffffffff800b6bdc>] hrtimer_interrupt+0xe2/0x1fe [<ffffffff80acc9e8>] riscv_timer_interrupt+0x38/0x42 [<ffffffff80090a16>] handle_percpu_devid_irq+0x90/0x1d2 [<ffffffff8008a9f4>] generic_handle_domain_irq+0x28/0x36 After referring other PMU drivers like Arm, Loongarch, Csky, and Mips, they don't call *_pmu_stop() to update with PERF_HES_STOPPED flag after perf_event_overflow() function nor do they add PERF_HES_STOPPED flag checking in *_pmu_start() which don't cause this warning. Thus, it's recommended to remove this unnecessary check in riscv_pmu_start() function to prevent this warning. (CVE-2023-53583)

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

ID	名称	严重性
269363	Linux Distros 未修补的漏洞：CVE-2023-53535	medium
269362	Linux Distros 未修补的漏洞：CVE-2023-53587	high
269361	Linux Distros 未修补的漏洞：CVE-2023-53581	medium
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
269328	Linux Distros 未修补的漏洞：CVE-2022-50499	medium
269327	Linux Distros 未修补的漏洞：CVE-2025-59729	medium
269326	Linux Distros 未修补的漏洞：CVE-2025-39936	medium
269325	Linux Distros 未修补的漏洞：CVE-2022-50483	medium
269324	Linux Distros 未修补的漏洞：CVE-2025-39935	high
269323	Linux Distros 未修补的漏洞：CVE-2022-50503	medium
269322	Linux Distros 未修补的漏洞：CVE-2023-53533	medium
269321	Linux Distros 未修补的漏洞：CVE-2023-53554	high
269320	Linux Distros 未修补的漏洞：CVE-2025-59732	high
269319	Linux Distros 未修补的漏洞：CVE-2025-59731	medium
269318	Linux Distros 未修补的漏洞：CVE-2023-53551	medium
269317	Linux Distros 未修补的漏洞：CVE-2023-53608	medium
269316	Linux Distros 未修补的漏洞：CVE-2025-59733	high
269315	Linux Distros 未修补的漏洞：CVE-2025-59152	high
269314	Linux Distros 未修补的漏洞：CVE-2023-53583	medium

检测

Nessus 的 Misc. 系列

medium

high

medium

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

medium

medium

medium

medium

high

medium

medium

high

high

medium

medium

medium

high

high

medium