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

  - wifirtw89修复 rtw89_append_probe_req_ie() 中的潜在泄漏在“goto out”之前执行“kfree_skb(new)”以防止潜在泄漏。 (CVE-2023-53467)

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

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

  - scsiqla2xxx使用 raw_smp_processor_id() 而不是 smp_processor_id() 发现了以下调用跟踪本地主机内核nvme nvme0: NVME-FC{0}控制器连接完成本地主机内核缺陷
    在可抢占的 [00000000] 代码中使用 smp_processor_id()kworker/u129:4/75092 localhost kernel: nvme nvme0: NVME-FC{0}: new ctrlNQN nqn.1992-08.com.netapp:sn.b42d198afb4d11ecad6d00a098d6abfa:subsystem。 PR_Channel2022_RH84_subsystem_291 localhost kernel: 调用者为 qla_nvme_post_cmd+0x216/0x1380 [qla2xxx] localhost kernel: CPU: 6 PID: 75092 Comm: kworker/u129:4 Kdump:已加载 Tainted: GBW OE --------- --- 5.14 .0-70.22.1.el9_0.x86_64+debug #1 localhost 内核硬件名称HPE ProLiant XL420 Gen10/ProLiant XL420 Gen10、BIOS U39 01/13/2022 localhost 内核工作队列nvme-wq nvme_async_event_work [nvme_core ] localhost 内核调用跟踪
    localhost 内核dump_stack_lvl+0x57/0x7d localhost 内核check_preemption_disabled+0xc8/0xd0 localhost 内核qla_nvme_post_cmd+0x216/0x1380 [qla2xxx] 使用 raw_smp_processor_id() 而不是 smp_processor_id()。
    同样在驱动程序中使用 queue_work() 而不是 queue_work_on()从而避免在启用 CONFIG_DEBUG_PREEMPT 时使用 smp_processor_id()。 (CVE-2023-53530)

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

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

  - stagingrtl8723bs修复 rtw_init_drv_sw() 中可能的内存泄漏。在 rtw_init_drv_sw() 中存在调用多种 init 函数以填充 padapter 结构以及对其返回值的一些检查。
    但是，除了第一个错误路径之外，其他五个错误路径都未正确释放之前分配的资源，从而导致各种内存泄漏。此 修补程序可修复这些问题并使成功与错误保持分离。请注意这些更改保留了 drivers/staging/r8188eu/os_dep/os_intfs.c 中“rtw_init_drv_sw()”的形式。由于没有可测试的适当设备，因此未执行任何运行时测试。 (CVE-2022-50469)

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

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

  - hsr修复 fill_frame_info() 中的 uninit-value 访问。 Syzbot 报告以下 uninit-value 访问问题。 ================================================== === BUGKMSANfill_frame_info net/hsr/hsr_forward.c:601 [内联] 缺陷中的 uninit-value hsr_forward_skb+0x9bd/0x30f0 net/hsr/hsr_forward.c:616 fill_frame_info net/hsr 中存在 uninit-value /hsr_forward.c:601 [内联] hsr_forward_skb+0x9bd/0x30f0 net/hsr/hsr_forward.c:616 hsr_dev_xmit+0x192/0x330 net/hsr/hsr_device.c:223 __netdev_start_xmit include/linux/netdevice.h:4889 [内联] netdev_start_xmit include/linux/netdevice.h:4903 [inline] xmit_one net/core/dev.c:3544 [inline] dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3560
    __dev_queue_xmit+0x34d0/0x52a0 net/core/dev.c:4340 dev_queue_xmit include/linux/netdevice.h:3082 [inline] packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c 3087 [inline] packet_sendmsg+0x8b1d/0x9f30 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [inline] sock_sendmsg net/socket.c:753 [inline] __sys_sendto+0x781/0xa30 net/socket.c 2176 __do_sys_sendto net/socket.c:2188 [内联] __se_sys_sendto net/socket.c:2184 [内联] __ia32_sys_sendto+0x11f/0x1c0 net/socket.c:2184 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [内联]
    __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178 do_fast_syscall_32+0x37/0x80 arch/x86/entry/common.c:203 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:246 entry_SYSENTER_compat_after_hwframe+ 0x70/0x82 Uninit 创建于 slab_post_alloc_hook+0x12f/0xb70 mm/slab.h:767 slab_alloc_node mm/slub.c:3478 [inline] kmem_cache_alloc_node+0x577/0xa80 mm/slub.c:3523 kmalloc_reserve+0x148/0x470 net/ core/skbuff.c:559 __alloc_skb+0x318/0x740 net/core/skbuff.c:644 alloc_skb include/linux/skbuff.h:1286 [内联] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6299 sock_alloc_send_pskb+ 0xa80/0xbf0 net/core/sock.c:2794 packet_alloc_skb net/packet/af_packet.c:2936 [内联] packet_snd net/packet/af_packet.c:3030 [内联] packet_sendmsg+0x70e8/0x9f30 net/packet/af_packet.c :3119 sock_sendmsg_nosec net/socket.c:730 [内联] sock_sendmsg net/socket.c:753 [内联] __sys_sendto+0x781/0xa30 net/socket.c:2176 __do_sys_sendto net/socket.c:2188 [内联]
    __se_sys_sendto net/socket.c:2184 [内联] __ia32_sys_sendto+0x11f/0x1c0 net/socket.c:2184 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [内联] __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common .c:178 do_fast_syscall_32+0x37/0x80 arch/x86/entry/common.c:203 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:246 entry_SYSENTER_compat_after_hwframe+0x70/0x82这是因为 hsr 中尚不支持 VLAN driver。现在当协议为 ETH_P_8021Q 时在 fill_frame_info() 中返回错误现已修复。 (CVE-2023-53462)

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

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

  - scsiufscore修复对 lrbp->cmd 的处理 在 SCSI 命令完成之前可针对 SCSI 命令连续调用两次 ufshcd_queuecommand()。因此进行以下更改- 在提交命令的函数中不检查 lrbp->cmd 的旧值也不清除错误路径中的 lrbp->cmd。- 在 ufshcd_release_scsi_cmd() 中不清除 lrbp->cmd。另请参阅 scsi_send_eh_cmnd()。此提交可防止在命令超时时出现以下内容WARNING: at drivers/ufs/core/ufshcd.c:2965 ufshcd_queuecommand+0x6f8/0x9a8 Call traceufshcd_queuecommand+0x6f8/0x9a8 scsi_send_eh_cmnd+0x2c0/0x960 scsi_eh_test_devices+0x100/0x314 scsi_eh_ready_devs+0xd90/0x114c scsi_error_handler+0x2b4/0xb70 kthread+0x16c/0x1e0 (CVE-2023-53510)

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

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

  - scsilpfc修复 GFT_ID 的异常退出路径中的空 ndlp ptr 取消引用。在错误情况下从 lpfc_cmpl_ct_cmd_gft_id() 退出会导致对 lpfc_nlp_put() 的调用带有节点列表结构的空指针。
    更改了 lpfc_cmpl_ct_cmd_gft_id() 以在进入时初始化 nodelist 指针。 (CVE-2022-50467)

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

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

  - virtio-mmio不中断 vm_dev 的生命周期 vm_dev 具有单独的生命周期因为它嵌入了“struct device”。因此为其提供发布回调是正确的。但是为具有 devres 的 vm_dev struct 分配会完全破坏此保护。删除 platform_device 时会释放内存，而不是等待 vm_dev 释放回调。最终调用回调时导致释放后使用。若要轻松发现此问题请使用 CONFIG_DEBUG_KOBJECT_RELEASE 编译内核并使用 sysfs 取消绑定。修复方法很简单在此情况下不使用 devres 即可。在我研究对象生命周期问题的过程中发现。 (CVE-2023-53515)

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

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

  - cangs_usb修复时间戳计数器初始化 如果在关闭接口之前卸载gs_usb 设备驱动程序则 USB 堆栈会首先调用 struct usb_driver::disconnect然后调用 struct net_device_ops::ndo_stop 回调。在 gs_usb_disconnect() 中所有待定的批量 URB 均终止即 USB 设备不再将任何经过 RX'ed 的 CAN 帧从 USB 设备发送到主机。稍后在 gs_can_close() 中系统会向每个 CAN 通道发送重置控制消息以从 CAN 总线删除控制器。在此争用窗口中USB 设备仍可从总线接收 CAN 帧并在内部将其排入队列以便发送到主机。
    至少在当前版本的 candlelight 固件中在重置命令期间不会清空接收到的 CAN 帧队列。加载（或绑定）gs_usb 驱动程序后在 struct net_device_ops::ndo_open 回调期间提交新的 URB并且 candlelight 固件开始将其已排队的 CAN 帧发送到主机。但是，在实现硬件时间戳函数时未考虑这种情况。周期计数器/时间计数器基础架构在 USB 提交之后设置 (gs_usb_timestamp_init())如果执行 timecounter_cyc2time() 通过调用链 gs_usb_receive_bulk_callback() -> gs_usb_set_timestamp() -> gs_usb_skb_set_timestamp()则导致空指针取消引用) 调用过早。在提交 URB 之前移动 gs_usb_timestamp_init() 函数以修复此问题。对于全面的解决方案我们需要考虑具有超过 1 个通道的 gs_usb 设备。周期计数器/时间计数器基础设施是按通道设置的，但 RX URB 是按设备设置的。调用 a_ 通道的 gs_can_open() 并且提交 URB后即可针对_all_可用通道调用 gs_usb_receive_bulk_callback()即使通道目前尚未运行。由于周期计数器/时间计数器尚未设置因此这将再次导致空指针取消引用。将周期计数器/时间计数器从每个通道的功能转换为每个设备的功能。
    您也可以在向 设备提交任何 URB 之前对其进行设置。此外在 gs_usb_receive_bulk_callback() 中也不处理未启动的 CAN 通道的任何 URB而仅重新提交 URB。 (CVE-2023-53523)

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

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

  - ACPI处理器检查 fch_misc_setup() 中 devm_kzalloc() 的空返回 devm_kzalloc() 可能会失败clk_data->name 可能为 NULL并将在之后造成空指针取消引用。 [ rjw主题和变更日志编辑 ] (CVE-2023-53483)

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

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

  - kobject当我以下列方式注册 kset 时为 kset_register() 中的 kset->kobj.ktype 添加健全性检查static struct kset my_kset kobject_set_name(&my_kset.kobj, my_kset); ret = kset_register(&my_kset);发生空指针取消引用异常[ 4453.568337] 无法处理 \ 虚拟地址 0000000000000028 处的内核空指针取消引用 ... ... [ 4453.810361] 调用跟踪[4453.813062] kobject_get_ownership+0xc/0x34 [ 4453.817493] kobject_add_internal+0x98/0x274 [ 4453.822005] kset_register+0x5c/0xb4 [ 4453.825820] my_kobj_init+0x44/0x1000 [my_kset] ... ... 因为我没有初始化 my_kset.kobj.ktype。根据 Documentation/core-api/kobject.rst 中的描述 - ktype 是嵌入 kobject 的对象类型。每个嵌入 kobject 的结构都需要相应的 ktype。因此添加健全性检查以确保 kset->kobj.ktype 不为 NULL。 (CVE-2023-53480)

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

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

  - io_uring退出时中断等待请求完成当退出环时，会完成清理并由 io_ring_exit_work 完成最终取消和等待。该函数由不采用任何信号的 kworker 调用。因此在 TASK_INTERRUPTIBLE 或 TASK_UNINTERRUPTIBLE 状态中等待完成实际上并不重要。但是，这对挂起任务检测检查程序而言确实如此。通常我们预计取消和完成会很快发生。但是有些测试用例会退出环并保留已停止的任务例如通过 SIGSTOP。如果拥有的任务需要运行 task_work 以完成请求则 io_ring_exit_work 将不会取得任何进度直到该任务再次可运行。因此 io_ring_exit_work 可以触发挂起任务检测这在启用 panic-on-hung-task 时特别成问题。由于环退出一开始不会接受信号请使其以可中断的方式而非不间断地等待。 io_uring 有一个无论如何都会独立触发的单独的卡住退出警告因此我们进行此切换并没有真正错过任何内容。 (CVE-2023-53461)

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

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

  - 已修复 Linux 内核中的下列漏洞：s390/dasd: Fix potential memleak in dasd_eckd_init() `dasd_reserve_req` is allocated before `dasd_vol_info_req`, and it also needs to be freed before the error returns, just like the other cases in this function. (CVE-2023-53449)

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

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

  - Omnibox 中的不当实现。 (CVE-2025-11213)

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

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

  - Omnibox 中的不当实现。 (CVE-2025-11209)

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

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

  - ext4在 DIO 写入之后创建内联数据时避免崩溃使用直接 IO 创建和写入 inode 时不执行任何操作清除 EXT4_STATE_MAY_INLINE_DATA 标记。因此当 inode 稍后被截断为 1 个字节并使用正常写入方式写入时我们将尝试将数据存储为内联数据。这会混淆之后的代码因为 inode 现在同时分配了普通块和内联数据并且混淆会显示为 kernel BUG at fs/ext4/inode.c:2721!无效 opcode0000 [#1] PREEMPT SMP KASAN CPU: 0 PID: 359 Comm: repro Not tainted 5.19.0-rc8-00001-g31ba1e3b8305-dirty #15 硬件名称
    QEMU Standard PC (i440FX + PIIX, 1996)、BIOS 1.16.0-1.fc36 04/01/2014 RIP
    0010:ext4_writepages+0x363d/0x3660 RSP0018:ffffc90000ccf260 EFLAGS00010293 RAX: ffffffff81e1abcd RBX
    0000008000000000 RCX: ffff88810842a180 RDX: 0000000000000000 RSI: 0000008000000000 RDI: 0000000000000000 RBP: ffffc90000ccf650 R08: ffffffff81e17d58 R09: ffffed10222c680b R10: dfffe910222c680c R11:
     R121ffff110222c680a  : ffff888111634128 R13: ffffc90000ccf880 R14: 0000008410000000 R15: 0000000000000001 FS: 00007f72635d2640(0000) GS:ffff88811b000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000565243379180 CR3: 000000010aa74000 CR4: 0000000000150eb0 Call Trace: <TASK> do_writepages+0x397/0x640 filemap_fdatawrite_wbc+0x151/0x1b0 file_write_and_wait_range+0x1c9/0x2b0 ext4_sync_file+0x19e/0xa00 vfs_fsync_range+0x17b/0x190 ext4_buffered_write_iter+0x488/0x530 ext4_file_write_iter+0x449/0x1b90 vfs_write+0xbcd/0xf40 ksys_write+ 0x198/0x2c0 __x64_sys_write+0x7b/0x90 do_syscall_64+0x3d/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> 通过对文件执行直接 IO 写入通过清除 EXT4_STATE_MAY_INLINE_DATA 来修复此问题。 (CVE-2022-50435)

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

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

  - ext4修复快速提交区块填充中的差一错误 由于多个不同的差一错误或者可能由于后期的设计变更未完全反映在实际合并的代码中关于如何用 tlv 条目填充快速提交区块有几个很奇怪的限制- 即使最小 tlv 长度为 8仍必须在区块结束前至少 10 个字节开始。
    否则，重放代码将忽略它们。缺陷如果使用长度为 blocksize - 9 或 blocksize - 8 的调用ext4_fc_reserve_space() 可能会违反此要求。幸运的是目前似乎不会发生这种情况。 - tlvs 必须在区块结束前至少 1 个字节结束。否则回放代码将认为它们无效。此 quirk 导致了一个缺陷已由较早的提交修复其中未初始化的内存在区块的最后一个字节中被泄漏到磁盘。此外奇怪的是这些限制不适用于 e2fsprogs 中的重放代码该代码将接受区块中的任何 tlvs完全没有边界检查但这是一个单独的问题...。鉴于这似乎都是一个缺陷我们来通过以自然方式使用 tlv 条目填充区块来修复它请注意旧内核将无法重播具有此提交的内核所创建的快速提交日志。 (CVE-2022-50428)

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

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

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

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

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

  - 在 4.2.25 版之前的 Django 4.2、5.1.13 版之前的 Django 5.1 以及 5.2.7 版之前的 Django 5.2 中发现一个问题。startapp --template 和 startproject --template 命令使用的 django.utils.archive.extract() 函数允许通过文件路径与目标目录共享通用前缀的存档进行部分目录遍历。 (CVE-2025-59682)

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

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

  - nbd修复 ioctl arg 的不完整验证。我们测试后发现未经验证的 nbd_ioctl arg 会引起警报。类似下面的 UBSAN 警告 calltrace： UBSAN: Undefined Behaviour in fs/buffer.c:1709:35 signed Integer溢出: -9223372036854775808 - 1 cannot be present in type 'long long int' CPU: 3 PID: 2523 Comm: syz-executor .0 未受感染 4.19.90 #1 硬件名称linux,dummy-virt (DT) 调用跟踪
    dump_backtrace+0x0/0x3f0 arch/arm64/kernel/time.c:78 show_stack+0x28/0x38 arch/arm64/kernel/traps.c:158
    __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x170/0x1dc lib/dump_stack.c:118 ubsan_epilogue+0x18/0xb4 lib/ubsan.c:161 handle_overflow+0x188/0x1dc lib/ubsan.c:192
    __ubsan_handle_sub_overflow+0x34/0x44 lib/ubsan.c:206 __block_write_full_page+0x94c/0xa20 fs/buffer.c:1709 block_write_full_page+0x1f0/0x280 fs/buffer.c:2934 blkdev_writepage+0x34/0x40 fs/block_dev.c:607
    __writepage+0x68/0xe8 mm/page-writeback.c:2305 write_cache_pages+0x44c/0xc70 mm/page-writeback.c:2240 generic_writepages+0xdc/0x148 mm/page-writeback.c:2329 blkdev_writepages+0x2c/0x38 fs/block_dev .c:2114 do_writepages+0xd4/0x250 mm/page-writeback.c:2344 触发此警告的原因是
    __block_write_full_page() -> i_size_read(inode) - 1 溢出。 inode->i_size 在 __nbd_ioctl() 中分配
    -> nbd_set_size() -> bytesize。我们认为有必要限制 arg 的大小以防止错误。
    此外__nbd_ioctl() -> nbd_add_socket()arg 将转换为 int。假设 arg 的值为 0x80000000000000001)64 位计算机在执行强制转换后将变为 1这将返回意外结果。通过添加检查防止传递过大数字来修复此问题。 (CVE-2023-53513)

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

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

  - wifirtw88修复 rtw_usb_probe() drivers/net/wireless/realtek/rtw88/usb.c:876 rtw_usb_probe() 警告中的内存泄漏未在行上释放 ieee80211_alloc_hw() 的 'hw'811 通过修改返回来修复此问题跳转到 goto 语句。 (CVE-2023-53460)

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

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

  - mmcvub300修复警告 - 当 !TASK_RUNNING vub300_enable_sdio_irq() 用于互斥体并需要 TASK_RUNNING 时不调用阻断 ops。确保将当前标记为可休眠上下文的 TASK_RUNNING。 [77.554641] !TASK_RUNNING; 时不调用阻断 ops在 [<ffffffff92a72c1d>] sdio_irq_thread+0x17d/0x5b0 设置的 state=1 [ 77.554652] 警告CPU:2 PID1983在 kernel/sched/core.c:9813
    __might_sleep+0x116/0x160 [ 77.554905] CPU2 PID1983 Comm: ksdioirqd/mmc1 受感染: G OE 6.1.0-rc5 #1 [77.554910] 硬件名称Intel(R) Client Systems NUC8i7BEH/NUC8BEB、BIOS BECFL357.86A.0081.2020.0504.1834 05/04/2020 [ 77.554912] RIP: 0010:__might_sleep+0x116/0x160 [ 77.554920] RSP: 0018:ffff888107b7fdb8 EFLAGS: 00010282 [ 77.554923] RAX: 0000000000000000 RBX: ffff888118c1b740 RCX: 0000000000000000 [77.554926] RDX: 0000000000000001 RSI: 0000000000000004 RDI: ffffed1020f6ffa9 [ 77.554928] RBP
    ffff888107b7fde0 R080000000000000001 R09ffffed1043ea60ba [ 77.554930] R10ffff88821f5305cb R11
    ffffed1043ea60b9 R12ffffffff93aa3a60 [ 77.554932] R13000000000000011b R147ffffffffffffff R15
    ffffffffc0558660 [ 77.554934] FS: 0000000000000000(0000) GS:ffff88821f500000(0000) knlGS:0000000000000000 [ 77.554937] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 77.554939] CR2: 00007f8a44010d68 CR3:
    000000024421a003 CR4: 00000000003706e0 [ 77.554942] 调用跟踪[ 77.554944] <TASK> [ 77.554952] mutex_lock+0x78/0xf0 [ 77.554973] vub300_enable_sdio_irq+0x103/0x3c0 [vub300] [ 77.554981] [ 77.555006/] sdio_irq_thread+0x25c ] kthread+0x2b8/0x370 [ 77.555017] ret_from_fork+0x1f/0x30 [77.555023] </TASK> [ 77.555025] ---[ 结束跟踪 0000000000000000 ]--- (CVE-2022-50430)

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

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

  - 已修复 Linux 内核中的下列漏洞：wifi: mt76: mt7921: resource leaks at mt7921_check_offload_capability() Fixed coverity issue with resource leaks at variable fw going out of scope leaks the storage it points to mt7921_check_offload_capability(). Addresses-Coverity-ID: 1527806 (Resource leaks) (CVE-2022-50424)

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

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

  - start_kernel添加 __no_stack_protector 函数属性 Back 在讨论提交 a9a3ed1eff36x86修复 gcc-10 中的过早启动崩溃第三次尝试时我们讨论了对函数属性来按每个函数控制堆栈保护程序忽略的需求;此时 Clang 支持 no_stack_protector 但 GCC 不支持。此问题已在 gcc-11 中修复。现在 function 属性已经可用了让我们开始使用它。除非 boot_init_stack_canary 的调用程序由 -fno-stack-protector 编译否则需要使用此函数属性否则调用程序堆栈槽中存储的 canary 在调用 boot_init_stack_canary 时将有所不同。这将导致调用 __stack_chk_fail() 然后发生错误。 (CVE-2023-53491)

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

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

  - kernfs修复 __kernfs_remove 中的释放后使用 Syzkaller 设法针对同一个文件触发对 kernfs_remove_by_name_ns() 的并发调用从而导致 KASAN 检测到释放后使用。在 kernfs_drain() 期间释放根节点时会发生争用。为防止这种情况获取在调用 __kernfs_remove() 之前删除的对树根的额外引用。由 syzkaller 通过以下重现器发现需要 slab_nomergesyz_mount_image$ext4(0x0, &(0x7f0000000100)='./file0\x00', 0x100000, 0x0, 0x0, 0x0, 0x0) r0 = openat(0xffffffffffffff9c, & (0x7f0000000080)='/proc/self/exe\x00', 0x0, 0x0) close(r0) pipe2(&(0x7f0000000140)={0xffffffffffffffff,<r1=> 0xffffffffffffffff}、0x800mount$9p_fd(0x0, &(0x7f0000000040)='./file0\x00', &(0x7f00000000c0)、0x408、 &(0x7f0000000280)={'trans=fd,', {'rfdno', 0x3d 、r0}、0x2c、{'wfdno'、0x3d、r1}、0x2c、{[{@cache_loose}、{@mmap}、{@loose}、{@loose}、{@mmap}]、[{@mask ={'mask', 0x3d, '^MAY_EXEC'}}, {@fsmagic={'fsmagic', 0x3d, 0x10001}}, {@dont_hash}]}}) 报告示例
    ================================================== ================ 缺陷KASANkernfs_type include/linux/kernfs.h:335 中存在释放后使用 [内联] 缺陷KASANkernfs_leftmost_descendant 中存在释放后使用fs/kernfs/dir.c:1261 [内联] 缺陷KASAN__kernfs_remove.part.0+0x843/0x960 中的释放后使用 fs/kernfs/dir.c:1369 通过任务 syz 在地址 ffff8880088807f0 处执行大小为 2 的读取-executor.2/857 CPU0 PID857 Commsyz-executor.2 Not tainted 6.0.0-rc3-00363-g7726d4c3e60b #5 硬件名称QEMU Standard PC (i440FX + PIIX,1996)、BIOS 1.15.0-1 04 /01/2014 调用跟踪 <TASK> __dump_stack lib/dump_stack.c:88 [内联] dump_stack_lvl+0x6e/0x91 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:317 [内联] print_report.cold+0x5e /0x5e5 mm/kasan/report.c:433 kasan_report+0xa3/0x130 mm/kasan/report.c:495 kernfs_type include/linux/kernfs.h:335 [内联] kernfs_leftmost_descendant fs/kernfs/dir.c:1261 [内联]
    __kernfs_remove.part.0+0x843/0x960 fs/kernfs/dir.c:1369 __kernfs_remove fs/kernfs/dir.c:1356 [inline] kernfs_remove_by_name_ns+0x108/0x190 fs/kernfs/dir.c:1589 sysfs_slab_add+0x103/ mm/slub.c:5943
    __kmem_cache_create+0x3e0/0x550 mm/slub.c:4899 create_cache mm/slab_common.c:229 [内联] kmem_cache_create_usercopy+0x167/0x2a0 mm/slab_common.c:335 p9_client_create+0xd4d/0x1190 net/9p/client.c:993 v9fs_session_init +0x1e6/0x13c0 fs/9p/v9fs.c:408 v9fs_mount+0xb9/0xbd0 fs/9p/vfs_super.c:126旧有_get_tree+0xf1/0x200 fs/fs_context.c:610 vfs_get_tree+0x85/0x2e0 fs/super.c 1530 do_new_mount fs/namespace.c:3040 [inline] path_mount+0x675/0x1d00 fs/namespace.c:3370 do_mount fs/namespace.c:3383 [inline] __do_sys_mount fs/namespace.c:3591 [inline] __se_sys_mount fs/namespace .c:3568 [inline] __x64_sys_mount+0x282/0x300 fs/namespace.c:3568 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x38/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP0033:0x7f725f983aed 代码02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 8c 4c 4c 48 9 ca 89 4d 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 0 1 48 RSP: 002b:00007f725f0f7028 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5 RAX: ffffffffffffffda RBX: 00007f725faa3f80 RCX: 00007f725f983aed RDX
    00000000200000c0 RSI: 0000000020000040 RDI: 0000000000000000 RBP: 00007f725f9f419c R08: 0000000020000280 R09: 0000000000000000 R10: 0000000000000408 R11: 0000000000000246 R12: 0000000000000000 R13:
    0000000000000006 R1400007f725faa3f80 R1500007f725f0d7000 </TASK> 由任务 855 分配
    kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38 kasan_set_track mm/kasan/common.c:45 [内联] set_alloc_info mm/kasan/common.c:437 [内联] __kasan_slab_alloc+0x66/0x80 mm/kasan/common .c:470 kasan_slab_alloc include/linux/kasan.h:224 [inline] slab_post_alloc_hook mm/slab.h:7 ---truncated--- (CVE-2022-50432)

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

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

  - ipv6在 nexthop 计算中添加所有同级的 lwtunnel encap 大小在函数 rt6_nlmsg_size() 中nexthop 的长度可通过将 fib6_info 的 nexthop 长度乘以同级进行计算计算。
    但是如果 fib6_info 没有 lwtunnel但同级有 lwtunnel则 nexthop 长度小于其应有的长度并将在 inet6_rt_notify() 中触发警告如下所示 WARNING: CPU: 0 PID: 6082 at net/ipv6/route .c:6180 inet6_rt_notify+0x120/0x130 ...... Call Trace: <TASK> fib6_add_rt2node+0x685/0xa30 fib6_add+0x96/0x1b0 ip6_route_add+0x50/0xd0 inet6_rtm_newroute+0x97/0xa0 rtnetlink_rcv_msg+0x156/0x3d0 netlink_rcv_skb+0x5a/0x110 netlink_unicast+0x246/0x350 netlink_sendmsg+0x250/0x4c0 sock_sendmsg+0x66/0x70
    ___sys_sendmsg+0x7c/0xd0 __sys_sendmsg+0x5d/0xb0 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc 此缺陷可通过脚本重现 ip -6 addr add 2002::2/64 dev ens2 ip -6 route add 100::/ 64 通过 2002::1 dev ens2 metric 100 for i in 10 20 30 40 50 60 70 do ip link add link ens2 name ipv_$i type ipvlan ip -6 addr add 2002::$i/64 dev ipv_$i ifconfig ipv_$i up did for i in 10 20 30 40 50 60;执行 ip -6 route append 100::/64 encap ip6 dst 2002::$i 通过 2002::1 dev ipv_$i metric 100 通过 2002::1 dev ipv_70 metric 100 完成 ip -6 route append 100::/64此修补程序通过添加使用 rt6_nh_nlmsg_size() 的每个同级的 nexthop_len 以修复此问题。 (CVE-2023-53477)

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

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

  - 在 4.2.25 版之前的 Django 4.2、5.1.13 版之前的 Django 5.1 以及 5.2.7 版之前的 Django 5.2 中发现一个问题。
    当使用带有字典扩展的适当构建的字典作为
    传递到这些方法的 **kwargs在 MySQL 和 MariaDB 中。 (CVE-2025-59681)

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

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

  - 已修复 Linux 内核中的下列漏洞：Bluetooth: hci_conn: Fix crash on hci_create_cis_sync When attempting to connect multiple ISO sockets without using DEFER_SETUP may result in the following crash: BUG: KASAN: null-ptr-deref in hci_create_cis_sync+0x18b/0x2b0 Read of size 2 at addr 0000000000000036 by task kworker/u3:1/50 CPU: 0 PID: 50 Comm: kworker/u3:1 Not tainted 6.0.0-rc7-02243-gb84a13ff4eda #4373 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-1.fc36 04/01/2014 Workqueue: hci0 hci_cmd_sync_work Call Trace: <TASK> dump_stack_lvl+0x19/0x27 kasan_report+0xbc/0xf0 ? hci_create_cis_sync+0x18b/0x2b0 hci_create_cis_sync+0x18b/0x2b0 ? get_link_mode+0xd0/0xd0 ? __ww_mutex_lock_slowpath+0x10/0x10 ? mutex_lock+0xe0/0xe0 ? get_link_mode+0xd0/0xd0 hci_cmd_sync_work+0x111/0x190 process_one_work+0x427/0x650 worker_thread+0x87/0x750 ? process_one_work+0x650/0x650 kthread+0x14e/0x180 ? kthread_exit+0x50/0x50 ret_from_fork+0x22/0x30 </TASK> (CVE-2022-50447)

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

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

  - HIDmultitouch修正 hidinput input_dev 名称的 devm 设备引用 为 input_dev 名称的 devm 分配引用 HID 设备而不是输入设备。引用 input_dev 会在未注册 input_dev 时导致释放后使用并随后触发依赖于该名称的 uevent。在触发 uevent 时devres 管理部门将释放该名称。使用 devm_kasprintf 以简化分配内存和格式化 input_dev 名称字符串的逻辑。
    (CVE-2023-53454)

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

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

  - RDMA/rxe修复了不安全的耗尽工作队列代码 如果 create_qp 未完全成功qp 清除代码可能会在创建队列之前尝试耗尽 send 或 recv 工作队列从而导致 seg 错误。此修补程序会在尝试耗尽队列之前检查以了解队列是否存在。
    (CVE-2023-53528)

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

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

  - mptcp修复断开与接受争用 尽管提交 0ad529d9fd2b (mptcp修复 recvmsg() 中可能存在的除零)mptcp 协议仍然容易在 disconnect()（或关闭）与 accept 之间发生争用。
    根本原因是上述提交会检查 msk 级别标记，但 mptcp_stream_accept() 确实获取 msk 级别锁定因为它可直接依赖第一个子流锁定。据 Christoph 报告可导致争用其中在 mptcp_subflow_queue_clean() 释放侦听器套接字锁定之后且就在其采取导致以下 splat: BUG 的破坏性操作之前接受 msk 套接字
    kernel 空指针取消引用地址0000000000000012 PGD 5a4ca067 P4D 5a4ca067 PUD 37d4c067 PMD 0 Oops0000 [#1] PREEMPT SMP CPU:2 PID10955 Comm:syz-executor.5 Not tainted 6.5.0-rc1-gdc7b #37 257 Hardware名称QEMU Standard PC (i440FX + PIIX,1996)BIOS 1.11.0-2.el7 04/01/2014 RIP
    0010:mptcp_stream_accept+0x1ee/0x2f0 include/net/inet_sock.h:330 代码0a 09 00 48 8b 1b 4c 39 e3 74 07 e8 bc 7c 7f fe eb a1 e8 b5 7c 7f fe 4c 8b 6c 24 08 eb 05 e8 a9 7c 7f fe 49 8b 85 d8 09 00 00 <0f> b6 40 12 88 44 24 07 0f b6 6c 24 07 bf 07 00 00 00 89 ee e8 89 RSP: 0018:ffffc90000d07dc0 EFLAGS: 00010293 RAX
    0000000000000000 RBX: ffff888037e8d020 RCX: ffff88803b093300 RDX: 0000000000000000 RSI: ffffffff833822c5 RDI: ffffffff8333896a RBP: 0000607f82031520 R08: ffff88803b093300 R09: 0000000000000000 R10:
     R110000000000000000  : 0000000000003e83 R12: ffff888037e8d020 R13: ffff888037e8c680 R14: ffff888009af7900 R15: ffff888009af6880 FS: 00007fc26d708640(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000012 CR3: 0000000066bc5001 CR4: 0000000000370ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 00000000000 DR3: 0000000 DR3: 0000000 DR3: 0000000 DR3: 000000000000000000
    00000000fffe0ff0 DR70000000000000400 调用跟踪 <TASK> do_accept+0x1ae/0x260 net/socket.c:1872
    __sys_accept4+0x9b/0x110 net/socket.c:1913 __do_sys_accept4 net/socket.c:1954 [内联] __se_sys_accept4 net/socket.c:1951 [内联] __x64_sys_accept4+0x20/0x30 net/socket.c:1951 do_syscall_x64 arch/x86 /entry/common.c:50 [inline] do_syscall_64+0x47/0xa0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 通过暂时从接受队列中删除待定请求套接字解决此问题使争用的套接字不再会争用accept() 无法接触它们。耗尽 msk - ssk 仍然存在后作为普通 TCP 套接字将它们重新插入接受队列以便稍后 inet_csk_listen_stop() 将完成 tcp 套接字处置。 (CVE-2023-53490)

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

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

  - cifs修复 cifs_flock() 中的 xid 泄漏 如果不是 flock应在返回 -ENOLCK 之前释放 xid否则xid将被泄漏。 (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 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - iommu/amd/iommu_v2修复 pasid 取消绑定的 pasid_state refcount dec hit 0 警告。在取消绑定 pasid 时 - 存在一个争用条件与未解决的页面错误。为防止发生这种情况pasid_state 对象包含了 refcount。 * 在 pasid 绑定时设置为 1 * 在每个 ppr 通知开始时递增 * 在每个 ppr 通知完成时递减 * 在 pasid 取消绑定时递减 由于 refcount_dec 假设 refcount 永不达到 0当前实现导致在 pasid 取消绑定时调用以下内容: REFCOUNT_WARN递减命中 0泄露内存通过将 refcount_dec 更改为 refcount_dec_and_test 以明确处理 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 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - rpmsgchar避免默认端点的双重破坏 rpmsg_core 中的 rpmsg_dev_remove() 是释放此默认端点的位置。因此需要避免破坏 rpmsg_chrdev_eptdev_destroy() 中的默认端点这应与 rpmsg_eptdev_release() 相同。否则将会出现 ept->refcount 报告警告refcount_t下溢的双重破坏问题。释放后使用。调用跟踪
    refcount_warn_slurate+0xf8/0x150 virtio_rpmsg_destroy_ept+0xd4/0xec rpmsg_dev_remove+0x60/0x70 通过在关闭 /dev/rpmsgX 之前停止 remoteproc可以重现此问题。 (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 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - ext4不在 jbd2 事务提交期间设置加密密钥 a80f7fcf1867ext4修复 ext4_fc_track_* 函数的签名将 ext4_unlink() 中的事务范围扩展得太远使其包括对 ext4_find_entry() 的调用。但是当从事务内调用 ext4_find_entry() 时其可能会死锁原因是可能需要设置目录的加密密钥。通过将事务还原到其原始范围来修复此问题。 (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 依赖供应商报告的程序包是否存在进行判断。

ID	名称	严重性
269599	Linux Distros 未修补的漏洞：CVE-2023-53467	high
269598	Linux Distros 未修补的漏洞：CVE-2023-53530	high
269597	Linux Distros 未修补的漏洞：CVE-2022-50469	medium
269596	Linux Distros 未修补的漏洞：CVE-2023-53462	medium
269595	Linux Distros 未修补的漏洞：CVE-2023-53510	high
269594	Linux Distros 未修补的漏洞：CVE-2022-50467	medium
269593	Linux Distros 未修补的漏洞：CVE-2023-53515	high
269592	Linux Distros 未修补的漏洞：CVE-2023-53523	medium
269591	Linux Distros 未修补的漏洞：CVE-2023-53483	medium
269590	Linux Distros 未修补的漏洞：CVE-2023-53480	medium
269589	Linux Distros 未修补的漏洞：CVE-2023-53461	medium
269588	Linux Distros 未修补的漏洞：CVE-2023-53449	medium
269587	Linux Distros 未修补的漏洞：CVE-2025-11213	critical
269586	Linux Distros 未修补的漏洞：CVE-2025-11209	critical
269585	Linux Distros 未修补的漏洞：CVE-2022-50435	high
269584	Linux Distros 未修补的漏洞：CVE-2022-50428	medium
269583	Linux Distros 未修补的漏洞：CVE-2023-53458	medium
269582	Linux Distros 未修补的漏洞：CVE-2025-59682	low
269581	Linux Distros 未修补的漏洞：CVE-2023-53513	high
269580	Linux Distros 未修补的漏洞：CVE-2023-53460	medium
269579	Linux Distros 未修补的漏洞：CVE-2022-50430	medium
269578	Linux Distros 未修补的漏洞：CVE-2022-50424	medium
269577	Linux Distros 未修补的漏洞：CVE-2023-53491	medium
269576	Linux Distros 未修补的漏洞：CVE-2022-50432	high
269575	Linux Distros 未修补的漏洞：CVE-2023-53477	high
269574	Linux Distros 未修补的漏洞：CVE-2025-59681	critical
269573	Linux Distros 未修补的漏洞：CVE-2022-50447	medium
269572	Linux Distros 未修补的漏洞：CVE-2023-53454	high
269571	Linux Distros 未修补的漏洞：CVE-2023-53528	high
269570	Linux Distros 未修补的漏洞：CVE-2023-53490	medium
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

检测

Nessus 的 Misc. 系列

high

high

medium

medium

high

medium

high

medium

medium

medium

medium

medium

critical

critical

high

medium

medium

low

high

medium

medium

medium

medium

high

high

critical

medium

high

high

medium

medium

critical

medium

high

high

medium

medium

medium

medium

medium

high

medium

medium

high

medium

medium

high

high

medium

medium