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

  - kheaders使用数组声明而不是字符 在 CONFIG_FORTIFY_SOURCE 下memcpy() 将检查目标和源缓冲区的大小。将 kernel_headers_data 定义为 char 会使此检查失效。由于这些地址会被当作字节数组处理请将其定义为数组如同在其他地方一样。$ cat /sys/kernel/kheaders.tar.xz >> /dev/null 在 lib/string_helpers.c:1027! 的 memcpy 内核 BUG 中检测到缓冲区溢出... RIP: 0010:fortify_panic+0xf/0x20 [...] 调用跟踪 <TASK> ikheaders_read+0x45/0x50 [kheaders] kernfs_fop_read_iter+0x1a4/0x2f0 ... (CVE-2023-54056)

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

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

  - ALSA第 6 行修复 line6_midi_transmit 中的堆栈溢出正确计算可用空间包括区块缓冲区的大小。这修复了当将多个 MIDI sysex 消息发送到 PODxt 设备时发生的缓冲区溢出。 (CVE-2022-50719)

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

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

  - ipmi:ssif扫描适配器时修复一个内存泄漏 如果适配器信息来自 SMBIOS则适配器扫描 ssif_info_find() 会设置 info->adapter_name因为在这种情况下不会设置它。但是可以多次调用此函数并且如果已经设置它将泄漏适配器名称。因此在设置 NULL 之前请先检查 NULL。 (CVE-2023-54064)

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

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

  - RDMA/irdma修复 PBLE 对象的内存泄漏 在 irdma 的 rmmod 中没有释放 PBLE 对象内存。
    与其他 HMC 对象不同的是，PBLE 对象内存并未在函数初始化时静态预分配。可在向上扩展期间动态分配 PBLE 对象及其段描述符 (SD)，并且 SD 在函数取消初始化之前保持分配状态。通过将 IRDMA_HMC_IW_PBLE 添加至 iw_hmc_obj_types[] 表并跳过 irdma_create_hmc_obj 中的 pble而非 irdma_del_hmc_objects() 中的 pble来修复此泄露。
    (CVE-2023-54055)

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

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

  - iommu/amd添加 ivrs_acpihid 命令行参数的长度限制 parse_ivrs_acpihid 函数中的“acpiid”缓冲区可能溢出因为格式字符串 sscanf() 中的字符串说明符没有宽度限制。由 InfoTeCS 代表 Linux Verification Center (linuxtesting.org) 通过 SVACE 发现。 (CVE-2023-54057)

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

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

  - cryptoessiv - 正确处理 EBUSY 由于它是 essiv 仅处理 EINPROGERSS 的特殊返回值这意味着在所有其他情况下它将释放与请求相关的数据。但是，由于 essiv 的调用程序可能指定 MAY_BACKLOG，因此我们还需要预期 EBUSY 并以相同方式对其进行处理。
    否则积压的请求将触发释放后使用。 (CVE-2023-54046)

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

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

  - powerpc/64s修复 VAS mm 释放后使用 mm 上的 refcount 在分离协处理器之前已终止。
    (CVE-2023-54042)

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

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

  - vdpa_sim如果 device_register() 在 vdpasim_net_init() 或 vdpasim_blk_init() 中失败但 kobject 的 refcount 未减少至 0即 中分配的名称则探测模块时注入错误vdpasim_net_init() 和 vdpasim_blk_init() 中可能存在的内存泄漏dev_set_name() 被泄漏。调用 put_device() 修复此问题以便可在回调函数 kobject_cleanup() 中释放名称。 (vdpa_sim_net) 未引用的对象 0xffff88807eebc370 (大小 16): comm modprobe, pid 3848, jiffies 4362982860 (age 18.153s) 十六进制转储前 16 个字节76 64 70 61 73 69 6d 5f 6e 65 74 00 6b a5 6b vdpasim_net. kkk。
    backtrace[<ffffffff8174f19e>] __kmalloc_node_track_caller+0x4e/0x150 [<ffffffff81731d53>] kstrdup+0x33/0x60 [<ffffffff83a5d421>] kobject_set_name_vargs+0x41/0x110 [<ffffffff82d87aab>] dev_set_name+0xab/0xe0 [<ffffffff82d91a23>] device_add+0xe3/0x1a80 [<ffffffffa0270013>] 0xffffffffa0270013 [<ffffffff81001c27>] do_one_initcall+0x87/0x2e0 [<ffffffff813739cb>] do_init_module+0x1ab/0x640 [<ffffffff81379d20>] load_module+0x5d00/0x77f0 [<ffffffff8137bc40>] __do_sys_finit_module+0x110/0x1b0 [<ffffffff83c4d505>] do_syscall_64+0x80 [/0x35 [<ffffffff83e0006a>/] ] entry_SYSCALL_64_after_hwframe+0x46/0xb0 (vdpa_sim_blk) unreferenced object 0xffff8881070c1250 (size 16): comm modprobe, pid 6844, jiffies 4364069319 (age 17.572s) hex dump (first 16 bytes): 76 64 70 61 73 69 6d 5f 62 6c 6b 00 6b 6b 6b a5 vdpasim_blk.kkk。 backtrace[<ffffffff8174f19e>] __kmalloc_node_track_caller+0x4e/0x150 [<ffffffff81731d53>] kstrdup+0x33/0x60 [<ffffffff83a5d421>] kobject_set_name_vargs+0x41/0x110 [<ffffffff82d87aab>] dev_set_name+0xab/0xe0 [<ffffffff82d91a23>] device_add+0xe3/0x1a80 [<ffffffffa0220013>] 0xffffffffa0220013 [<ffffffff81001c27>] do_one_initcall+0x87/0x2e0 [<ffffffff813739cb>] do_init_module+0x1ab/0x640 [<ffffffff81379d20>] load_module+0x5d00/0x77f0 [<ffffffff8137bc40>] __do_sys_finit_module+0x110/0x1b0 [<ffffffff83c4d505>] do_syscall_64+0x80 [/0x35 [<ffffffff83e0006a>/] ] entry_SYSCALL_64_after_hwframe+0x46/0xb0 (CVE-2022-50702)

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

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

  - wifimt76mt7921e修复驱动程序重新加载测试中的 rmmod 崩溃。在 insmod/rmmod 压力测试中立即显示以下崩溃转储。该问题是由于 mt7921_pci_remove() 中缺少 mt76_dev 所造成。我们应确保在 probe() 完成之前 drvdata 已准备就绪。 [168.862789] ============================================== ==================== [168.862797] BUGKASANtry_to_grab_pending+0x59/0x480 中的 user-memory-access [168.862805] 地址 0000000000006df0 处大小为 8 的写入按任务 rmmod/5361 [168.862812] CPU: 7 PID: 5361 Comm: rmmod 感染:G OE 5.19.0-rc6 #1 [168.862816] 硬件名称Intel(R) Client Systems NUC8i7BEH/NUC8BEB05/04/ 2020 [168.862820] 调用跟踪[168.862822] <TASK> [ [168.862825] dump_stack_lvl+0x49/0x63 [168.862832] print_report.cold+0x493/0x6b7 [168.862845] kasan_report+0xa7/0x120 [168.862857] kasan_check_range+0x163 /0x200 [168.862861]
    __kasan_check_write+0x14/0x20 [168.862866] try_to_grab_pending+0x59/0x480 [168.862870]
    __cancel_work_timer+0xbb/0x340 [168.862898] cancel_work_sync+0x10/0x20 [168.862902] mt7921_pci_remove+0x61/0x1c0 [mt7921e] [168.862909] pci_device_remove+0xa3/0x1d0 [168.862914] device_remove+0xc4/0x170 [_inter+driver_release168.862920] device_remove 0x163/0x300 [168.862925] driver_detach+0xc7/0x1a0 [168.862930] bus_remove_driver+0xeb/0x2d0 [168.862935] driver_unregister+0x71/0xb0 [168.862939] pci_unregister_driver+0x30/0x230 [168.862944] mt7921_pci_driver_exit+0x10/0x10/0x21e ] [168.862949] __x64_sys_delete_module+0x2f9/0x4b0 [168.862968] do_syscall_64+0x38/0x90 [168.862973] entry_SYSCALL_64_after_hwframe+0x63/0xcd 测试步骤1. insmode 2. 请勿 ifup 3. 快速 rmmod1 秒内(CVE-2022-50714)

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

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

  - wifirtl8xxxu修复 RTL8723BU、RTL8192EU 的内存泄漏 当 wifi + 蓝牙组合芯片 RTL8723BU 连接到蓝牙音频设备时其会泄漏内存。忙碌的蓝牙流量生成大量未正确释放的 C2H卡到主机消息。若要修复此问题请将 rtl8xxxu_c2hcmd_callback() 中的 dev_kfree_skb() 调用移动到调用 skb_dequeue() 的循环内部。RTL8192EU 会泄漏内存因为 C2H 消息会添加至队列并永远留存在该处。这在过去很好因为在提交 e542e66b7c2e (wifi
    rtl8xxxugen2打开速率控制。由于该提交当 TX 速率更改时它会发送 C2H 消息。) 要修复此问题请删除对 rf_paths > 1 和 goto 的检查。函数处理来自 RTL8192EU 的 C2H 消息就像处理处理其他芯片的消息一样。理论上RTL8188FU 也可能像 RTL8723BU 一样发生泄漏问题但它很可能发送 C2H 消息的频率不够。此变更已由 Erhard F 经受过 RTL8723BU 的测试。我也已使用 RTL8188FU 和 RTL8192EU 进行过测试。 (CVE-2023-54036)

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

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

  - iommufd执行批处理进位时正确设置端即使测试套件涵盖了此问题但它仍会以某种方式被掩盖而不反映此问题。测试 iommufd_ioas.mock_domain.access_domain_destory 会在极少数情况下崩溃。 end 应设置为 1因为这只是将项目进位推送到 pfns 列表。有时测试会崩溃并显示以下错误缺陷内核空指针取消引用地址0000000000000000 #PF
    内核模式中的主管读取访问 #PFerror_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] SMP CPU5 PID584 Commiommufd 未受感染 6.5.0-rc1-dirty #1236 硬件名称QEMU Standard PC (Q35 + ICH92009)BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP
    0010:batch_unpin+0xa2/0x100 [iommufd] 代码17 48 81 fe ff ff 07 00 77 70 48 8b 15 b7 be 97 e2 48 85 d2 74 14 48 8b 14 fa 48 85 d2 74 0b 40 0f b6 f6 48 04 48 01 f2 <48> 8b 3a 48 c1 e0 06 89 ca 48 89 de 48 83 e7 f0 48 01 c7 e8 96 dc RSP0018:ffffc90001677a58 EFLAGS00010246 RAX: 00007f7e2646f000 RBX
    0000000000000000 RCX: 0000000000000001 RDX: 0000000000000000 RSI: 00000000fefc4c8d RDI: 0000000000fefc4c RBP: ffffc90001677a80 R08: 0000000000000048 R09: 0000000000000200 R10: 0000000000030b98 R11:
     R12ffffffff81f3bb40  : 0000000000000001 R13: ffff888101f75800 R14: ffffc90001677ad0 R15: 00000000000001fe FS: 00007f9323679740(0000) GS:ffff8881ba540000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000000105ede003 CR4: 00000000003706a0 DR0
    0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 调用跟踪 <TASK> ? show_regs+0x5c/0x70 ? __die+0x1f/0x60 ? page_fault_oops+0x15d/0x440 ? lock_release+0xbc/0x240 ? exc_page_fault+0x4a4/0x970 ? asm_exc_page_fault+0x27/0x30 atch_unpin+0xa2/0x100 [iommufd] ? atch_unpin+0xba/0x100 [iommufd]
    __iopt_area_unfill_domain+0x198/0x430 [iommufd] ? __mutex_lock+0x8c/0xb80 ? __mutex_lock+0x6aa/0xb80 ? xa_erase+0x28/0x30 ? iopt_table_remove_domain+0x162/0x320 [iommufd] ? lock_release+0xbc/0x240 iopt_area_unfill_domain+0xd/0x10 [iommufd] iopt_table_remove_domain+0x195/0x320 [iommufd] iommufd_hw_pagetable_destroy+0xb3/0x110 [iommufd] iommufd_object_destroy_user+0x8e/0xf0 [iommufd] iommufd_device_detach+0xc5/0x140 [iommufd] iommufd_selftest_destroy+0x1f/0x70 [iommufd] iommufd_object_destroy_user+0x8e/0xf0 [iommufd] iommufd_destroy+0x3a/0x50 [iommufd] iommufd_fops_ioctl+0xfb/0x170 [iommufd] __x64_sys_ioctl+0x40d/0x9a0 do_syscall_64+0x3c/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 (CVE-2023-54060)

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

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

  - netipv4修复 __inet_del_ifa() 中的一个内存泄漏 当进行模糊测试时收到以下警告
    unregister_netdevice正在等待 bond0 释放。使用计数 = 2 可通过以下方式重现： ip link add bond0 type bond sysctl -w net.ipv4.conf.bond0.promote_secondaries=1 ip addr add 4.117.174.103/0 scope 0x40 dev bond0 ip addr add 192.168.100.111/255.255.255.254 scope 0 dev bond0 ip addr add 0.0.0.4/0 scope 0x40 Secondary dev bond0 ip addr del 4.117.174.103/0 scope 0x40 dev bond0 ip link delete bond0 type bond 在此重现测试案例中在 __inet_del_ifa() 中发现不正确的“last_prim”。因此会丢失辅助地址 (0.0.0.4/0 scope 0x40)。次要地址的内存泄漏以及对 in_device 和 net_device 的引用泄漏。修复此问题从已删除的 IP 的位置开始查找“last_prim”并将升级的 IP 插入“last_prim”的位置。
    (CVE-2023-53995)

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

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

  - drm/amdgpu修复 pci 设备引用计数泄漏 正如 pci_get_domain_bus_and_slot() 的注释所述其会返回 refcount 递增的 pci 设备当完成使用时调用程序必须通过调用 pci_dev_put() 来递减引用计数。因此在从 amdgpu_device_resume|suspend_display_audio() 返回之前会调用 pci_dev_put() 以避免 refcount 泄漏。 (CVE-2022-50718)

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

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

  - cryptoakcipher - 设置私钥来自 v1 的变更的默认实现* 删除了 set_pub_key 的默认实现假设实现必须始终定义此回调因为算法没有用例不会影响需要公钥 许多 akcipher 实现如 ECDSA仅支持签名验证因此并未定义所有回调。提交 78a0324f4a53cryptoakcipher - 请求回调的默认实现为签名/验证操作引入了默认回调该操作仅返回错误代码。但是，这些还不够，因为在调用 sign 之前，调用方可能会在实例化转换上首先调用 set_priv_key（内核内 testmgr 会这样做）。此函数没有默认存根因此尝试在不支持签名生成的 akcipher 上设置私钥时内核会崩溃。当尝试将 ECDSA 签名的 KAT 矢量添加到 testmgr 时我注意到了这一点。通过此修补程序testmgr 在 dmesg 中返回一个错误这是理所应当的而不是造成内核空指针取消引用崩溃。 (CVE-2022-50731)

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

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

  - ASoC da7219修复 da7219_register_dai_clks() 中的错误处理路径如果 clk_hw_register() 失败则不应取消注册相应的 clk。若要处理循环错误请在执行 goto 之前清除部分迭代。因此添加 clk_hw_unregister()。然后在展开部分使用 while (--i >= 0) 循环。 (CVE-2022-50698)

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

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

  - ext4正确设置 ext4_mb_normalize_request 中的目标开始 我们需要设置 ac_g_ex 以通知 ext4_mb_find_by_goal 中使用的目标开始。在 ext4_mb_normalize_request 中设置 ac_g_ex 而非 ac_f_ex。此外我们应确保目标起始地址与 ext4_mb_initialize_context 一样在 [first_data_block,blocks_count) 范围内。[已添加检查以确保大小小于 ar->pright否则我们最终可能会将 ar->pright - 大小的下溢值传递到 ext4_get_group_no_and_offset()这将在稍后触发 BUG_ON。- TYT ] (CVE-2023-54021)

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

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

  - vdpa向 vdpa_nl_policy 添加队列索引属性以进行 nlattr 长度检查 vdpa_nl_policy 结构用于在解析传入的 nlmsg 时验证 nlattr。将确保进入 vdpa_nl_ops 中的每个处理程序之前所描述的属性在 info->attrs 中生成有效的 nlattr 指针。即vdpa_nl_policy 中缺失部分可能导致解析后出现不合法的 nlattr从而可导致 OOB 读取就像 CVE-2023-3773一样。此修补程序添加了 vdpa 队列索引属性缺少的 nla_policy以避免此类缺陷。 (CVE-2023-54031)

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

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

  - af_unix修复有关 unix_tot_inflight 的数据争用。 unix_tot_inflight 在 spin_lock(unix_gc_lock) 下被更改但 unix_release_sock() 以无锁方式读取。假设我们对 unix_tot_inflight 使用 READ_ONCE()。请注意编写器端已由提交 9d6d7f1cb67c (af_unix注释对 unix_tot_inflight 和 gc_in_progress 的无锁访问) 标记缺陷KCSANunix_inflight / unix_release_sock 中的数据争用由 cpu 1 上的任务 123 写入标记为 0xffffffff871852b8 共 4 个字节
    unix_inflight+0x130/0x180 net/unix/scm.c:64 unix_attach_fds+0x137/0x1b0 net/unix/scm.c:123 unix_scm_to_skb net/unix/af_unix.c:1832 [内联] unix_dgram_sendmsg+0x46a/0x14f0 net/unix/ af_unix.c:1955 sock_sendmsg_nosec net/socket.c:724 [内联] sock_sendmsg+0x148/0x160 net/socket.c:747
    ____sys_sendmsg+0x4e4/0x610 net/socket.c:2493 ___sys_sendmsg+0xc6/0x140 net/socket.c:2547
    __sys_sendmsg+0x94/0x140 net/socket.c:2576 __do_sys_sendmsg net/socket.c:2585 [内联] __se_sys_sendmsg net/socket.c:2583 [内联] __x64_sys_sendmsg+0x45/0x50 net/socket.c:2583 do_syscall_x64 arch/x864 /entry/common.c:50 [inline] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x72/0xdc 由 cpu 0 上的任务 4891 读取 4 字节的 0xffffffff871852b8
    unix_release_sock+0x608/0x910 net/unix/af_unix.c:671 unix_release+0x59/0x80 net/unix/af_unix.c:1058
    __sock_release+0x7d/0x170 net/socket.c:653 sock_close+0x19/0x30 net/socket.c:1385 __fput+0x179/0x5e0 fs/file_table.c:321____fput+0x15/0x20 fs/file_table.c:349 task_work_run+ 0x116/0x1a0 kernel/task_work.c:179 resume_user_mode_work include/linux/resume_user_mode.h:49 [内联] exit_to_user_mode_loop kernel/entry/common.c:171 [内联] exit_to_user_mode_prepare+0x174/0x180 kernel/entry/common.c:204 __syscall_exit_to_user_mode_work kernel/entry/common.c:286 [内联] syscall_exit_to_user_mode+0x1a/0x30 kernel/entry/common.c:297 do_syscall_64+0x4b/0x90 arch/x86/entry/common.c:86 entry_SYSCALL_64_after_hwframe+0x72/0xdc 值已更改0x00000000 -> 0x00000001 已由 CPU: 0 PID: 4891 Comm: systemd-coredum Not tainted 6.4.0-rc5-01219-gfa0e21fa4443 #5 硬件名称QEMU Standard PCi440FX + PIIX, 1996 BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 (CVE-2023-54006)

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

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

  - selinux启用 convert_context() 中同时使用 GFP_KERNEL 和 GFP_ATOMIC 在硬件环境中触发了以下警告SELinux正在转换 162 SID 表条目... BUG从 __might_sleep+0x60/0x74 0x0 的无效上下文调用的休眠函数 in_atomic()1、irqs_disabled()128、non_block:0、pid:5943、name:tar CPU:7 PID:5943 Comm:tar 受感染的:PO 5.10.0 #1 调用跟踪
    dump_backtrace+0x0/0x1c8 show_stack+0x18/0x28 dump_stack+0xe8/0x15c ___might_sleep+0x168/0x17c
    __might_sleep+0x60/0x74 __kmalloc_track_caller+0xa0/0x7dc kstrdup+0x54/0xac convert_context+0x48/0x2e4 sidtab_context_to_sid+0x1c4/0x36c security_context_to_sid_core+0x168/0x238 security_context_to_sid_default+0x14/0x24 inode_doinit_use_xattr+0x164/0x1e4 inode_doinit_with_dentry+0x1c0/0x488 selinux_d_instantiate+0x20/0x34 security_d_instantiate+0x70/0xbc d_splice_alias+0x4c/0x3c0 ext4_lookup+0x1d8/0x200 [ext4] __lookup_slow+0x12c/0x1e4 walk_component+0x100/0x200 path_lookupat+0x88/0x118 filename_lookup+0x98/0x130 user_path_at_empty+0x48/0x60 vfs_statx+0x84/0x140 vfs_fstatat+ 0x20/0x30 __se_sys_newfstatat+0x30/0x74
    __arm64_sys_newfstatat+0x1c/0x2c el0_svc_common.constprop.0+0x100/0x184 do_el0_svc+0x1c/0x2c el0_svc+0x20/0x34 el0_sync_handler+0x80/0x17c el0_sync+0x13c/0x140 SELinux: Context system_u:object_r:pssp_rsyslog_log_t:s0:c0 is not valid (未映射。已发现在 sidtab_context_to_sid() 中 spin_lock_irqsave 的关键区段内convert_context()被 sidtab_convert_params.func 挂钩可能通过用 GFP_KERNEL 分配内存造成进程休眠这是有问题的。正如 Ondrej 所指出的 [1]convert_context()/sidtab_convert_params.func 有另一个调用程序 sidtab_convert_tree()这对 GFP_KERNEL 没有问题。因此请通过为 convert_context()/sidtab_convert_params.func 添加 gfp_t 参数来修复此问题并在各个调用程序中正确传递 GFP_KERNEL/_ATOMIC。[PM封装长 BUG() 输出行调整主题行] (CVE-2022-50699)

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

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

  - io_uring/rw推迟 fsnotify 调用至任务上下文 我们无法在 kiocb 完成时取消这些调用因为这可能关闭软/硬 irq 上下文。我们处理此请求的 task_work 时将调用推迟到 。
    这可避免类似 stack backtrace: CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.0.0-rc6-syzkaller-00321-g105a36f3694e #0 Hardware name: Google Google Compute Engine/Google Compute Engine、BIOS Google 08 的有效投诉/26/2022 调用跟踪 <IRQ> __dump_stack lib/dump_stack.c:88 [内联] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_usage_bug kernel/locking/lockdep.c:3961 [inline] valid_state kernel/locking/ lockdep.c:3973 [inline] mark_lock_irq kernel/locking/lockdep.c:4176 [inline] mark_lock.part.0.cold+0x18/0xd8 kernel/locking/lockdep.c:4632 mark_lock kernel/locking/lockdep.c 4596 [inline] mark_usage kernel/locking/lockdep.c:4527 [inline] __lock_acquire+0x11d9/0x56d0 kernel/locking/lockdep.c:5007 lock_acquire kernel/locking/lockdep.c:5666 [inline] lock_acquire+0x1ab/0x570 内核/locking/lockdep.c:5631 __fs_reclaim_acquire mm/page_alloc.c:4674 [内联] fs_reclaim_acquire+0x115/0x160 mm/page_alloc.c:4688 might_alloc include/linux/sched/mm.h:271 [内联] slab_pre_alloc_hook mm/slab .h 700 [内联] slab_alloc mm/slab.c:3278 [inline] __kmem_cache_alloc_lru mm/slab.c:3471 [内联] kmem_cache_alloc+0x39/0x520 mm/slab.c:3491 fanotify_alloc_fid_event fs/notify/fanotify/fanotify.c:580 [内联] fanotify_alloc_event fs/notify/fanotify/fanotify.c:813 [内联] fanotify_handle_event+0x1130/0x3f40 fs/notify/fanotify/fanotify.c:948 send_to_group fs/notify/fsnotify.c:360 [内联] fsnotify+0xafb /0x1680 fs/notify/fsnotify.c:570
    __fsnotify_parent+0x62f/0xa60 fs/notify/fsnotify.c:230 fsnotify_parent include/linux/fsnotify.h:77 [inline] fsnotify_file include/linux/fsnotify.h:99 [inline] fsnotify_access include/linux/fsnotify.h:309 [内联] __io_complete_rw_common+0x485/0x720 io_uring/rw.c:195 io_complete_rw+0x1a/0x1f0 io_uring/rw.c:228 iomap_dio_complete_work fs/iomap/direct-io.c:144[内联] iomap_dio_bio_end_io+0x438/0x5e0 fs/iomap /direct-io.c:178 bio_endio+0x5f9/0x780 block/bio.c:1564 req_bio_endio block/blk-mq.c:695 [inline] blk_update_request+0x3fc/0x1300 block/blk-mq.c:825 scsi_end_request+0x7a /0x9a0 drivers/scsi/scsi_lib.c:541 scsi_io_completion+0x173/0x1f70 drivers/scsi/scsi_lib.c:971 scsi_complete+0x122/0x3b0 drivers/scsi/scsi_lib.c:1438 blk_complete_reqs+0xad/0xe0 block/blk-mq. c:1022 __do_softirq+0x1d3/0x9c6 kernel/softirq.c:571 invoke_softirq kernel/softirq.c:445 [inline] __irq_exit_rcu+0x123/0x180 kernel/softirq.c:650 irq_exit_rcu+0x5/0x20 kernel/softirq.c:662 common_interrupt+0xa9/0xc0 arch/x86/kern el/irq.c:240 (CVE-2022-50705)

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

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

  - net/mlx5e失效期间使用正确的 encap 属性引入操作后基础架构后大部分 encap 属性的用户已修改以便通过调用 mlx5e_tc_get_encap_attr() 辅助函数而不是假设 encap 操作始终针对默认属性来获取正确的属性。但是，引用的提交未修改 mlx5e_invalidate_encap()，从而防止其破坏导致警告的正确修改标头操作 [0]。使用正确的属性修复此问题。 [0]2 月 21 日 09:47:35 c-237-177-40-045 kernel: WARNING: CPU: 17 PID: 654 at drivers/net/ethernet/mellanox/mlx5/core/en_tc.c:684 mlx5e_tc_attach_mod_hdr+0x1cc/0x230 [mlx5_core] 21 09:47:35 c-237-177-40-045 内核RIP
    0010:mlx5e_tc_attach_mod_hdr+0x1cc/0x230 [mlx5_core] 2 月 21 日 09:47:35 c-237-177-40-045 内核调用跟踪
    2 月 21 日 09:47:35 c-237-177-40-045 内核 <TASK> 2 月 21 日 09:47:35 c-237-177-40-045 内核
    mlx5e_tc_fib_event_work+0x8e3/0x1f60 [mlx5_core] 2 月 21 日 09:47:35 c-237-177-40-045 内核mlx5e_take_all_encap_flows+0xe0/0xe0 [mlx5_core] 2 月 21 日 09:47:35 c-237-177-40-045 内核lock_downgrade+0x6d0/0x6d0 2 月 21 日 09:47:35 c-237-177-40-045 内核？ lockdep_hardirqs_on_prepare+0x273/0x3f0 2 月 21 日 09:47:35 c-237-177-40-045 内核lockdep_hardirqs_on_prepare+0x273/0x3f0 2 月 21 日 09:47:35 c-237-177-40-045 kernel
    process_one_work+0x7c2/0x1310 2 月 21 日 09:47:35 c-237-177-40-045 内核lockdep_hardirqs_on_prepare+0x3f0/0x3f0 2 月 21 日 09:47:35 c-237-177-40-045 内核pwq_dec_nr_in_flight+0x230/0x230 2 月 21 日 09:47:35 c-237-177-40-045 内核? rwlock_bug.part.0+0x90/0x90 Feb 21 09:47:35 c-237-177-40-045 kernelworker_thread+0x59d/0xec0 Feb 21 09:47:35 c-237-177-40-045kernel? __kthread_arkme+0xd9/0x1d0 (CVE-2023-54074)

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

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

  - ext4使用 dioread_nolock 驱逐 inode 时关闭警告信息使用默认 dioread_nolock 驱逐 inode 时可能会在回写某些新分配的脏块之后受到转换 kworker 的未写入盘区争用。会将未写入的盘区转换为已写入这些盘区可以合并到高级和释放盘区区块因此它可以再次将该 inode 标记为脏即使这个 inode 被标记为 I_FREEING。但是 ext4_evict_inode() 中的 inode->i_io_list 检查和警告会缺少此极端情况。
    幸运的是ext4_evict_inode() 会等待所有盘区转换完成之后再进行此项检查因此不会导致 inode 释放后使用问题除了此警告一切都正常。WARN_ON_ONCE 最初设计用于提前查找 inode 释放后使用问题但如果我们在 中添加当前的 dioread_nolock 情况则将变得不太有用因此通过删除此检查来修复此警告。
    ====== 警告CPU: 7 PID: 1092 at fs/ext4/inode.c:227 ext4_evict_inode+0x875/0xc60 ... RIP
    0010ext4_evict_inode+0x875/0xc60 ... Call Trace: <TASK> evict+0x11c/0x2b0 iput+0x236/0x3a0 do_unlinkat+0x1b4/0x490 __x64_sys_unlinkat+0x4c/0xb0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7fa933c1115b ====== rm kworker ext4_end_io_end( ) vfs_unlink() ext4_unlink() ext4_convert_unwritten_io_end_vec() ext4_convert_unwritten_extents() ext4_map_blocks() ext4_ext_map_blocks() ext4_ext_try_to_merge_up() __mark_inode_dirty() check !I_FREEING locked_inode_to_wb_and_lock_list() iput() iput_final() evict() ext4_evict_inode() truncate_inode_pages_final() //wait release io_end inode_io_list_move_locked() ext4_release_io_end() 触发 WARN_ON_ONCE() (CVE-2022-50730)

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

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

  - wifiiwlwifipcie修复可能的空指针取消引用 iwl_pci_probe() 可能会失败并释放事务然后将调用 iwl_pci_remove() 并通过尝试访问已释放的事务而崩溃修复之。 iwlwifi 0000:01:00.0检测到 crf-id 0xa5a5a5a2、cnv-id 0xa5a5a5a2 wfpm id 0xa5a5a5a2 iwlwifi 0000:01:00.0无法找到 crf id 0x5a2 的正确 rfid ... 缺陷内核空指针取消引用地址0000000000000028 ... RIP: 0010:iwl_pci_remove+0x12/0x30 [iwlwifi] pci_device_remove+0x3e/0xb0 device_release_driver_internal+0x103/0x1f0 driver_detach+0x4c/0x90 bus_remove_driver+0x5c/0xd0 driver_unregister+0x31/0x50 pci_unregister_driver+0x40/0x90 iwl_pci_unregister_driver+0x15/0x20 [iwlwifi] __exit_compat+0x9/0x98 [iwlwifi]
    __x64_sys_delete_module+0x147/0x260 (CVE-2023-54053)

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

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

  - devlink刷新快照时保持区域锁定 Netdevsim 在销毁带有待定快照的区域时会触发重新加载的 splat警告CPU1 PID787net/core/devlink.c:6291 devlink_region_snapshot_del+0x12e/0x140 CPU1 PID: 787 Comm: devlink Not tainted 6.1.0-07460-g7ae9888d6e1c #580 RIP: 0010:devlink_region_snapshot_del+0x12e/0x140 Call Trace: <TASK> devl_region_destroy+0x70/0x140 nsim_dev_reload_down+0x2f/0x60 [netdevsim] devlink_reload+0x1f7/0x360 devlink_nl_cmd_reload +0x6ce/0x860 genl_family_rcv_msg_doit.isra.0+0x145/0x1c0 这是 devlink_region_snapshot_del() 中的锁定断言我们假设在此保留 region->snapshot_lock。
    (CVE-2022-50712)

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

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

  - io_uring修复删除提供的缓冲区时的内存泄漏情况。删除提供的缓冲区时不处置 io_buffer struct 可能会导致内存泄漏。无法单独释放它们因为它们是在页面大小的组中分配的。需要将它们添加到某些空闲列表中例如 io_buffers_cache。
    所有调用方都已持有对其进行保护的锁定（销毁缓冲区时除外），因此必须在此处扩展锁定。 (CVE-2023-54041)

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

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

  - 244644d 之前的 C-Kermit又称 ckermit到 10.0 Beta.12又称 416-beta12允许远程 Kermit 系统覆盖本地系统上的文件或从本地系统检索任意文件。
    (CVE-2025-68920)

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

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

  - mediadvb-usb-v2gl861修复 gl861_i2c_master_xfer 中的 null-ptr-deref 在 gl861_i2c_master_xfer 中msg 由用户控制。当 msg[i].buf 为空且 msg[i].len 为零时将通过前者对 msg[i].buf 的检查。恶意数据最终到达 gl861_i2c_master_xfer。如果在未进行健全性检查的情况下访问 msg[i].buf[0]会发生空指针取消引用。我们在 msg[i].len 上添加了检查以防止崩溃。类似提交提交 0ed554fd769a (media: dvb-usb: az6027修复 az6027_i2c_xfer() 中的 null-ptr-deref) (CVE-2023-54066)

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

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

  - usbidmouse修复 idmouse_open 中的 uninit-value 在 idmouse_create_image 中如果有任何 ftip_command 失败它将转至重置标签。然而这会导致bulk_in_buffer[HEADER..IMGSIZE] 中的数据未初始化。并且对有效图像的检查引发未初始化的取消引用。通过在重置标签前移动检查来修复此问题因为此检查仅在bulk_in_buffer[HEADER] 之后的数据具有具体数据时有效。请注意这是由 KMSAN 发现的因此仅测试内核编译。 (CVE-2022-50733)

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

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

  - ALSApcm修复 PCM 内存分配帮助程序中潜在的数据争用 PCM 内存分配帮助程序具有针对过多缓冲区分配的健全性检查。然而，在没有适当锁定的情况下执行检查并且分配未序列化这允许用户分配比预定义最大大小更多的内存。
    实际上这并不是什么大问题因为它或多或少是一种作为健全性检查的软限制并且不可能进行无限分配。但为获得行为的一致性，最好仍解决此问题。修补程序使用 card->memory_mutex 说明 do_alloc_pages() 中的大小检查并增加其中的分配大小以防止进一步溢出。当实际分配失败时，大小会相应减小。 (CVE-2023-54072)

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

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

  - stagingr8712修复 _r8712_init_xmit_priv() 中的内存泄漏 在上述例程中在多个位置分配了内存。如果第一个成功而后面一个失败则例程将泄漏内存。
    此修补程序可修复 commit 2865d42c78a9 stagingr8712u将新驱动程序添加至干线内核。r8712_xmit_resource_alloc() 中潜在的内存泄漏问题也已解决。 (CVE-2023-54001)

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

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

  - bnxt_en修复在成功路径中返回之前 bnxt_nvm_test() 释放 kzalloc 的缓冲区中的内存泄漏。 (CVE-2022-50723)

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

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

  - RDMA/siw修复完成队列的即时工作请求刷新。在 post sendqueue 操作中即时工作请求刷新期间如果 QP 处于 ERROR 状态请正确设置发送队列元素 opcode。一个未定义的 ocode 值导致对用于在工作生成中在 siw 内部和 RDMA 核心表示之间映射 opcode 的数组进行越界访问。这会导致 NFSoRDMA 测试期间出现“global-out-of-bounds”类型的 KASAN 缺陷报告。此修补程序还修复了一个潜在情况如果 CQ 内存映射到用户登陆则恶意用户可能会向完成队列元素状态或操作码写入未定义的值。与上述相同可避免对状态和操作码映射的数组进行越界访问。 (CVE-2022-50736)

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

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

  - wifimt76mt7921s修复 sdio 主机中的 slab 越界访问 SDIO 可能需要额外的 511 字节以配合总线操作。如果此 skb 的 tailroom 不够大我们将访问无效的内存区域。对于低级操作增加 skb 大小以便在 SDIO 主机中保持有效的内存访问。错误消息 [69.951] BUGKASAN: sg_copy_buffer+0xe9/0x1a0 中的 slab 越界 [69.951] 由任务 kworker/u16:7/451 读取地址 ffff88811c9cf000 处的大小 64 的内存 [69.951] CPU 4 PID451 Comm: kworker/u16:7 Tainted: GW OE 6.1.0-rc5 #1 [69.951] Workqueue: kvub300c vub300_cmndwork_thread [vub300] [69.951] 调用跟踪 [69.951] <TASK> [69.952] dump_stack_lvl+0x49/0x63 [69.952] print_report+0x171/0x4a8 [69.952] kasan_report+0xb4/0x130 [69.952] kasan_check_range+0x149/0x1e0 [69.952] memcpy+0x24/0x70 [69.952] sg_copy_buffer+0xe9/0x1a0 [69.952] sg_copy_to_buffer+0x12/0x20 [69.952]
    __command_write_data.isra.0+0x23c/0xbf0 [vub300] [69.952] vub300_cmndwork_thread+0x17f3/0x58b0 [vub300] [69.952] process_one_work+0x7ee/0x1320 [69.952] worker_thread+0x53c/0x1240 [69.952] kthread+0x2b8/ 0x370 [69.952] ret_from_fork+0x1f/0x30 [69.952] </TASK> [69.952] 由任务 854 分配[69.952] kasan_save_stack+0x26/0x50 [69.952] kasan_set_track+0x25/0x30 [69.952] kasan_save_alloc_info+0x1b /0x30 [69.952] __kasan_kmalloc+0x87/0xa0 [69.952] __kmalloc_node_track_caller+0x63/0x150 [69.952] kmalloc_reserve+0x31/0xd0 [69.952] __alloc_skb+0xfc/0x2b0 [69.952] __mt76_mcu_msg_alloc+0xbf/0x230]69.952[  ] mt76_mcu_send_and_get_msg+0xab/0x110 [mt76] [69.952] __mt76_mcu_send_firmware.cold+0x94/0x15d [mt76] [69.952] mt76_connac_mcu_send_ram_firmware+0x415/0x54d [mt76_connac_lib] [69.952] mt76_connac2_load_ram.cold+0x118/0x4bc [ mt76_connac_lib] [69.952] mt7921_run_firmware.cold+0x2e9/0x405 [mt7921_common] [69.952] mt7921s_mcu_init+0x45/0x80 [mt7921s] [69.953] mt7921_init_work+0xe1/0x2a0 [mt7921_common] [69.953] process_one_work+0x7ee/0x1320 [69.953] worker_thread+0x53c/0x1240 [69.953] kthread+0x2b8/0x370 [69.953] ret_from_fork+0x1f/0x30 [69.953] 有缺陷的地址属于 ffff88811c9ce800 的对象该地址属于大小 2048 的缓存 kmalloc-2k [69.953] 有缺陷的地址位于 2048 字节区域右侧 0 字节 [ffff88811c9ce800、ffff88811c9cf000) [69.953] 有缺陷的地址周围的内存状态 [69.953] ffff88811c9cef00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [69.953] ffff88811c9cef80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [69.953] >ffff88811c9cf000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc [69.953] ^ [69.953] ffff88811c9cf080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [69.953] ffff88811c9cf100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc (CVE-2022-50701)

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

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

  - net/ieee802154不警告 zero-sized raw_sendmsg() syzbot 在 命中 skb_assert_len() 警告
    __dev_queue_xmit() [1]用于 PF_IEEE802154 套接字的 zero-sized raw_sendmsg() 请求命中
    skb->len == 0 的 __dev_queue_xmit()。由于 PF_IEEE802154 套接字的大小为零的 raw_sendmsg() 请求能够返回 0所以如果数据包长度为 0则不会调用 __dev_queue_xmit()。--------- - #include<sys/socket.h> #include<netinet/in.h> int main(int argc, char *argv[]) { struct sockaddr_in addr = { .sin_family = AF_INET, .sin_addr.s_addr = htonl(INADDR_LOOPBACK) }; struct iovec iov = { }; struct msghdr hdr = {.msg_name = &addr, .msg_namelen = sizeof(addr), .msg_iov = &iov, .msg_iovlen = 1 };
    sendmsg(socket(PF_IEEE802154, SOCK_RAW, 0), &hdr, 0); return 0 ---------- 请注意这可能是一个迹象表明应恢复提交 fd1894224407c484bpf不要使用无效的 pkt_len 重定向数据包因为 skb->len == 0 在 内是可以接受的PF_IEEE802154 套接字。 (CVE-2022-50706)

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

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

  - ext4修复 ext4_xattr_move_to_block() 中的无效释放跟踪在 ext4_xattr_move_to_block() 中如果值存储在外部 inode 中需要移动至外部区块的扩展属性值可能由 kvmalloc() 分配。因此在函数末尾代码会通过测试 entry->e_value_inum 来尝试检查是否如此。但是此时指向 xattr 条目的指针不再有效因为该指针已从其存储的原始位置删除。因此我们最终可能在不是由 kvmalloc() 分配的指针上调用 kvfree()否则我们也可能通过在应该释放缓冲区时未将其释放来泄漏内存。通过将是否应释放存储在单独的变量中来修复此问题。 (CVE-2023-54062)

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

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

  - ice修复 FDIR 的错误回退逻辑添加 FDIR 过滤器时如果 ice_vc_fdir_set_irq_ctx 返回失败则不会删除插入的 fdir 条目如果 ice_vc_fdir_write_fltr 返回失败则不会清除 irq 处理程序的 fdir 上下文信息这可能导致不一致或内存泄漏问题。
    此修补程序优化了失败案例以解决此问题。 (CVE-2023-54040)

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

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

  - bpf修复 LRU 和 LRU_PERCPU 哈希映射中的内存泄漏 LRU 和 LRU_PERCPU 映射在更新时分配一个新元素先于锁定目标哈希表存储段。之后映射会立即尝试锁定存储段。如果此操作失败，则 映射会将 -EBUSY 返回给调用程序，而不释放分配的元素。这使得元素处于不明状态其不属于任何一个空闲列表也不属于哈希表因此无法重新使用这最终导致非预期的 LRU 映射更新上出现永久 -ENOMEM。如果存储桶锁定失败可通过将元素返回到本地空闲列表来修复此问题。
    (CVE-2023-54033)

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

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

  - RDMA/core修复 create_ah 失败时的 GID 条目引用泄漏如果 AH 创建请求失败释放 sgid_attr 以避免释放 GID 表时报告的 GID 条目引用泄漏 (CVE-2023-54003)

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

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

  - fs保护 sb 读取-写入的重新配置以防写入争用 重新配置/重新挂载代码需要花费大量精力来保护文件系统的重新配置代码以防在重新挂载只读时写入争用。但是在将只读文件系统重新挂载到读写模式期间在清除 SB_RDONLY 标记后用户空间写入可立即开始。这是不方便的例如对于 ext4 而言因为我们需要先对文件系统执行一些写入例如配额文件的准备然后才能进行用户空间写入所以我们要在完全准备好接受用户空间写入之前清除 SB_RDONLY 标记并且 syzbot 已发现一种利用此问题的方法 [1]。此外就我正在读取的代码而言，通过挂载的 MNT_READONLY 标记可以保护文件系统重新挂载代码防止旧挂载路径中的争用写入，因此这是一个相对较新的问题。实际上相当容易使用 sb->s_readonly_remount 标记来保护重新挂载读写免受争用写入影响因此让我们这样做而不必在文件系统代码中解决这些争用。 [1] https://lore.kernel.org/all/00000000000006a0df05f6667499@google.com/T/ (CVE-2023-54099)

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

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

  - inotify避免报告具有无效 wd 的事件 inotify_freeing_mark() 与 inotify_handle_inode_event() 争用时会发生 inotify_handle_inode_event() 发现 i_mark->wd 已重置为 -1 并向用户空间报告此值可能会混淆 inotify 侦听器。通过验证 wd 合理避免 问题避免 问题并假装在 生成事件前标记已删除。 (CVE-2023-54119)

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

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

  - x86/xen修复 xen_init_lock_cpu() 中的内存泄漏在 xen_init_lock_cpu() 中@name 已通过 kasprintf() 分配新字符串如果 bind_ipi_to_irqhandler() 失败应将其释放否则可能导致内存泄漏问题修复它。 (CVE-2022-50761)

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

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

  - mptcp为 IPv6 使用正确的 req 析构函数。在此之前即使子流是 IPv6也仅从 IPv4 中的 TCP 请求 sock 中调用析构函数。请务必使用正确的析构函数以避免某些高级 IPv6 功能发生内存泄漏例如当请求 sock 包含特定 IPv6 选项时。
    (CVE-2022-50783)

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

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

  - amdgpu/pm防止 vega20_odn_edit_dpm_table() 中发生数组下溢在 PP_OD_EDIT_DDC_CURVE 的情况下input_index 变量的上限为 2但未检查负值因此导致越界读取。此值来自用户通过 sysfs 提供的值。 (CVE-2022-50781)

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

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

  - serial: sc16is7xx稍后在探测中设置 GPIO 控制器 sc16is7xx 驱动程序的 GPIO 控制器组件设置过早可能会造成争用条件使另一设备在 sc16is7xx 设备完成初始化之前尝试使用 GPIO 线路。配置 GPIO 行时此问题表现为 Oops无法处理从位于虚拟地址 ... 的无法读取的内存进行的内核读取 pc sc16is7xx_gpio_direction_output+0x68/0x108 [sc16is7xx] lr
    sc16is7xx_gpio_direction_output+0x4c/0x108 [sc16is7xx] ... 调用跟踪
    sc16is7xx_gpio_direction_output+0x68/0x108 [sc16is7xx] gpiod_direction_output_raw_commit+0x64/0x318 gpiod_direction_output+0xb0/0x170 create_gpio_led+0xec/0x198 gpio_led_probe+0x16c/0x4f0 platform_drv_probe+0x5c/0xb0 really_probe+0xe8/0x448 driver_probe_device+0xe8/0x138
    __device_attach_driver+0x94/0x118 bus_for_each_drv+0x8c/0xe0 __device_attach+0x100/0x1b8 device_initial_probe+0x28/0x38 bus_probe_device+0xa4/0xb0 deferred_probe_work_func+0x90/0xe0 process_one_work+0x1c4/0x480 worker_thread+0x54/0x430 kthread+0x138/0x150 ret_from_fork+0x10/0x1c此修补程序将探测函数中的 GPIO 控制器函数的设置移到了后期从而确保到其他设备尝试使用 GPIO 线时sc16is7xx 设备已经完成初始化。错误处理也已重新排序以反映新的初始化顺序。
    (CVE-2023-54118)

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

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

  - drm/amdgpu修复 amdgpu_atrm_get_bios() 中的 PCI 设备引用计数泄漏如 pci_get_class() 的注释所述将返回其引用计数增加和减少的 pci_device如果输入参数 @from不为空则其引用计数会减少。如果我们在“pdev”不为空的情况下中断 amdgpu_atrm_get_bios() 中的循环则需要调用 pci_dev_put() 以减少 refcount。添加缺少的 pci_dev_put() 以避免 refcount 泄漏。
    (CVE-2022-50760)

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

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

  - sfc修复在 ethtool 自我测试期间可调用 NIC 重置 efx_net_stats() 期间读取统计信息时发生崩溃的问题 (.ndo_get_stats64)在此期间 nic_data->mc_stats 为空因为 NIC 已被完成。在这种情况下请勿尝试从硬件中获取最新的统计数据否则我们将在空取消引用时崩溃BUG内核空指针取消引用地址0000000000000038 RIP efx_nic_update_stats 省略的调用跟踪efx_ef10_update_stats_pf efx_net_stats dev_get_stats dev_seq_printf_stats 跳过读取是安全的我们将仅给出过时的统计数据。为确保 efx_ef10_fini_nic() 中的释放不会与 efx_ef10_update_stats_pf() 争用可导致 TOCTTOU 缺陷请采取 fini_nic 中的 efx->stats_lock它已跨 update_stats 保持。 (CVE-2023-54156)

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

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

  - audit修复 __audit_inode_child() 中可能的软锁定。Tracefs 或 debugfs 可能造成数百至数千条 PATH 记录过多的 PATH 记录可能造成软锁定。例如： 1. CONFIG_KASAN=y && CONFIG_PREEMPTION=n 2. auditctl -a exit,always -S open -k key 3. sysctl -w kernel.watchdog_thresh=5 4.
    mkdir /sys/kernel/debug/tracing/instances/test 可能存在如下软锁定 watchdog: 缺陷软锁定 - CPU#45 卡住达 7s! [mkdir:15498] 内核错误 - 不同步softlockup挂起任务调用跟踪
    dump_backtrace+0x0/0x30c show_stack+0x20/0x30 dump_stack+0x11c/0x174 panic+0x27c/0x494 watchdog_timer_fn+0x2bc/0x390 __run_hrtimer+0x148/0x4fc __hrtimer_run_queues+0x154/0x210 hrtimer_interrupt+0x2c4/0x760 arch_timer_handler_phys+0x48/0x60 handle_percpu_devid_irq+0xe0/0x340
    __handle_domain_irq+0xbc/0x130 gic_handle_irq+0x78/0x460 el1_irq+0xb8/0x140
    __audit_inode_child+0x240/0x7bc tracefs_create_file+0x1b8/0x2a0 trace_create_file+0x18/0x50 event_create_dir+0x204/0x30c __trace_add_new_event+0xac/0x100 event_trace_add_tracer+0xa0/0x130 trace_array_create_dir+0x60/0x140 trace_array_create+0x1e0/0x370 instance_mkdir+0x90/0xd0 tracefs_syscall_mkdir+0x68/0xa0 vfs_mkdir+0x21c/0x34c do_mkdirat+0x1b4/0x1d4 __arm64_sys_mkdirat+0x4c/0x60 el0_svc_common.constprop.0+0xa8/0x240 do_el0_svc+0x8c/0xc0 el0_svc+0x20/0x30 el0_sync_handler+0xb0/0xb4 el0_sync+0x160/0x180 Therefore, we add cond_resched( ) 添加到 __audit_inode_child() 以进行修复。 (CVE-2023-54045)

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

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

  - ext4修复 ext4_mb_new_inode_pa() 中因溢出导致的缺陷 当计算 ext4_free_extent 的结束位置时此位置可能正好是 ext4_lblk_t即 uint溢出的位置。例如如果 ac_g_ex.fe_logical 为 4294965248 ac_orig_goal_len 为 2048则计算的结尾为 0x100000000即 0。如果 ac->ac_o_ex.fe_logical 不是调整最佳范围的第一个情况即 new_bex_end > 0将触发以下 BUG_ON =========================================== ============== fs/ext4/mballoc.c:5116! 的内核缺陷无效的 opcode0000 [#1] PREEMPT SMP PTI CPU: 3 PID: 673 Comm
    xfs_io Tainted: GE 6.5.0-rc1+ #279 RIP: 0010:ext4_mb_new_inode_pa+0xc5/0x430 Call Trace: <TASK> ext4_mb_use_best_found+0x203/0x2f0 ext4_mb_try_best_found+0x163/0x240 ext4_mb_regular_allocator+0x158/0x1550 ext4_mb_new_blocks+0x86a/0xe10 ext4_ext_map_blocks+0xb0c/0x13a0 ext4_map_blocks+0x2cd/0x8f0 ext4_iomap_begin+0x27b/0x400 iomap_iter+0x222/0x3d0 __iomap_dio_rw+0x243/0xcb0 iomap_dio_rw+0x16/0x80 ========================= ================================ 演示问题的简单重现器 mkfs.ext4 -F /dev/sda -b 4096 100M mount /dev/sda /tmp/test fallocate -l1M /tmp/test/tmp fallocate -l10M /tmp/test/file fallocate -i -o 1M -l16777203M /tmp/test/file fsstress -d /tmp/test -l 0 -n 100000 -p 8 & sleep 10 && killall -9 fsstress rm -f /tmp/test/tmp xfs_io -c open -ad /tmp/test/file -c pwrite -S 0xff 0 8192通过添加临时 ext4_free_extent ex 调整最佳范围的逻辑并使用 extent_logical_end() 以避免溢出这也简化了代码。 (CVE-2023-54069)

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

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

  - net/mlx5修复异步命令中可能的释放后使用接口 mlx5_cmd_cleanup_async_ctx 应仅在其所有回调处理程序完成后返回。在此修补程序之前mlx5_cmd_cleanup_async_ctx 与 mlx5_cmd_exec_cb_handler 之间可能发生以下争用并导致释放后使用1。
    当 num_inflight 为 2 即提高 1单个 inflight 回调时 mlx5_cmd_cleanup_async_ctx 被调用。 2. mlx5_cmd_cleanup_async_ctx 将 num_inflight 减少为 1。3. 调用了 mlx5_cmd_exec_cb_handler将 num_inflight 减少为 0且即将调用 wake_up()。 4. mlx5_cmd_cleanup_async_ctx 调用 wait_event其会在条件 (num_inflight == 0) 成立时立即返回。 5.
    mlx5_cmd_cleanup_async_ctx 返回。 6。mlx5_cmd_cleanup_async_ctx 的调用程序释放 mlx5_async_ctx 对象。 7. mlx5_cmd_exec_cb_handler 继续操作并在已释放对象上调用 wake_up()。通过使用完成对象进行同步来修复此问题。当 num_inflight 达到 0 时将其标记为已完成。Trace: BUG: KASAN:未受感染 6.0.0-rc3_for_upstream_debug_2022_08_30_13_10 #1 硬件名称QEMU Standard PC (Q35 + ICH92009)BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 调用跟踪
    <IRQ> dump_stack_lvl+0x57/0x7d print_report.cold+0x2d5/0x684 do_raw_spin_lock+0x23d/0x270 kasan_report+0xb1/0x1a0 do_raw_spin_lock+0x23d/0x270 do_raw_spin_lock+0x23d/0x270 ? rwlock_bug.part.0+0x90/0x90 __delete_object+0xb8/0x100 ? lock_downgrade+0x6e0/0x6e0
    _raw_spin_lock_irqsave+0x43/0x60 ? __wake_up_common_lock+0xb9/0x140 __wake_up_common_lock+0xb9/0x140
    __wake_up_common+0x650/0x650 ? destroy_tis_callback+0x53/0x70 [mlx5_core] ? kasan_set_track+0x21/0x30 destroy_tis_callback+0x53/0x70 [mlx5_core] ? kfree+0x1ba/0x520 ? do_raw_spin_unlock+0x54/0x220 mlx5_cmd_exec_cb_handler+0x136/0x1a0 [mlx5_core] ? mlx5_cmd_cleanup_async_ctx+0x220/0x220 [mlx5_core] ? mlx5_cmd_cleanup_async_ctx+0x220/0x220 [mlx5_core] mlx5_cmd_comp_handler+0x65a/0x12b0 [mlx5_core] ? dump_command+0xcc0/0xcc0 [mlx5_core] ? lockdep_hardirqs_on_prepare+0x400/0x400 ? cmd_comp_notifier+0x7e/0xb0 [mlx5_core] cmd_comp_notifier+0x7e/0xb0 [mlx5_core] atomic_notifier_call_chain+0xd7/0x1d0 mlx5_eq_async_int+0x3ce/0xa20 [mlx5_core] atomic_notifier_call_chain+0xd7/0x1d0 ? irq_release+0x140/0x140 [mlx5_core] irq_int_handler+0x19/0x30 [mlx5_core] __handle_irq_event_percpu+0x1f2/0x620 handle_irq_event+0xb2/0x1d0 handle_edge_irq+0x21e/0xb00
    __common_interrupt+0x79/0x1a0 common_interrupt+0x78/0xa0 </IRQ> <TASK> asm_common_interrupt+0x22/0x40 RIP
    0010:default_idle+0x42/0x60 代码c1 83 e0 07 48 c1 e9 03 83 c0 03 0f b6 14 11 38 d0 7c 04 84 d2 75 14 8b 05 eb 47 22 02 85 c0 7e 07 0f 00 2d e0 48 9f 0fb e0 48 <c3> f4  48 c7 c7 80 08 7f 85 e8 d1 d3 3e fe eb de 66 66 2e 0f 1f 84 00 RSP: 0018:ffff888100dbfdf0 EFLAGS: 00000242 RAX: 0000000000000001 RBX: ffffffff84ecbd48 RCX: 1ffffffff0afe110 RDX: 0000000000000004 RSI: 0000000000000000 RDI: ffffffff835cc9bc RBP
     R080000000000000005  : 0000000000000001 R09: ffff88881dec4ac3 R10: ffffed1103bd8958 R11: 0000017d0ca571c9 R12: 0000000000000005 R13: ffffffff84f024e0 R14: 0000000000000000 R15: dffffc0000000000 ? default_idle_call+0xcc/0x450 default_idle_call+0xec/0x450 do_idle+0x394/0x450 ? arch_cpu_idle_exit+0x40/0x40 do_idle+0x17/0x450 cpu_startup_entry+0x19/0x20 start_secondary+0x221/0x2b0 ? set_cpu_sibling_map+0x2070/0x2070 secondary_startup_64_no_verify+0xcd/0xdb </TASK> Allocated by task 49502: kasan_save_stack+0x1e/0x40 __kasan_kmalloc+0x81/0xa0 kvmalloc_node+0x48/0xe0 mlx5e_bulk_async_init+0x35/0x110 [mlx5_core] mlx5e_tls_priv_tx_list_cleanup+0x84/0x3e0 [mlx5_core] mlx5e_ktls_cleanup_tx+ 0x38f/0x760 [mlx5_core] mlx5e_cleanup_nic_tx+0xa7/0x100 [mlx5_core] mlx5e_detach_netdev+0x1c ---truncated---CVE-2022-50726]

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

ID	名称	严重性
279952	Linux Distros 未修补的漏洞：CVE-2023-54056	high
279951	Linux Distros 未修补的漏洞：CVE-2022-50719	high
279950	Linux Distros 未修补的漏洞：CVE-2023-54064	medium
279949	Linux Distros 未修补的漏洞：CVE-2023-54055	medium
279948	Linux Distros 未修补的漏洞：CVE-2023-54057	high
279947	Linux Distros 未修补的漏洞：CVE-2023-54046	high
279946	Linux Distros 未修补的漏洞：CVE-2023-54042	high
279945	Linux Distros 未修补的漏洞：CVE-2022-50702	medium
279944	Linux Distros 未修补的漏洞：CVE-2022-50714	medium
279943	Linux Distros 未修补的漏洞：CVE-2023-54036	medium
279942	Linux Distros 未修补的漏洞：CVE-2023-54060	medium
279941	Linux Distros 未修补的漏洞：CVE-2023-53995	medium
279940	Linux Distros 未修补的漏洞：CVE-2022-50718	high
279939	Linux Distros 未修补的漏洞：CVE-2022-50731	high
279938	Linux Distros 未修补的漏洞：CVE-2023-54058	medium
279937	Linux Distros 未修补的漏洞：CVE-2022-50698	medium
279936	Linux Distros 未修补的漏洞：CVE-2023-54021	medium
279934	Linux Distros 未修补的漏洞：CVE-2023-54031	medium
279933	Linux Distros 未修补的漏洞：CVE-2023-54006	high
279932	Linux Distros 未修补的漏洞：CVE-2022-50699	medium
279931	Linux Distros 未修补的漏洞：CVE-2022-50705	medium
279930	Linux Distros 未修补的漏洞：CVE-2023-54074	medium
279929	Linux Distros 未修补的漏洞：CVE-2022-50730	high
279928	Linux Distros 未修补的漏洞：CVE-2023-54053	medium
279927	Linux Distros 未修补的漏洞：CVE-2022-50712	medium
279926	Linux Distros 未修补的漏洞：CVE-2023-54041	medium
279925	Linux Distros 未修补的漏洞：CVE-2025-68920	high
279924	Linux Distros 未修补的漏洞：CVE-2023-54066	medium
279923	Linux Distros 未修补的漏洞：CVE-2022-50733	medium
279922	Linux Distros 未修补的漏洞：CVE-2023-54072	medium
279921	Linux Distros 未修补的漏洞：CVE-2023-54001	medium
279920	Linux Distros 未修补的漏洞：CVE-2022-50723	medium
279919	Linux Distros 未修补的漏洞：CVE-2022-50736	high
279918	Linux Distros 未修补的漏洞：CVE-2022-50701	medium
279917	Linux Distros 未修补的漏洞：CVE-2022-50706	medium
279916	Linux Distros 未修补的漏洞：CVE-2023-54062	high
279915	Linux Distros 未修补的漏洞：CVE-2023-54040	medium
279914	Linux Distros 未修补的漏洞：CVE-2023-54033	medium
279913	Linux Distros 未修补的漏洞：CVE-2023-54003	medium
279899	Linux Distros 未修补的漏洞：CVE-2023-54099	high
279898	Linux Distros 未修补的漏洞：CVE-2023-54119	medium
279897	Linux Distros 未修补的漏洞：CVE-2022-50761	medium
279896	Linux Distros 未修补的漏洞：CVE-2022-50783	medium
279895	Linux Distros 未修补的漏洞：CVE-2022-50781	high
279894	Linux Distros 未修补的漏洞：CVE-2023-54118	high
279893	Linux Distros 未修补的漏洞：CVE-2022-50760	medium
279892	Linux Distros 未修补的漏洞：CVE-2023-54156	medium
279891	Linux Distros 未修补的漏洞：CVE-2023-54045	medium
279890	Linux Distros 未修补的漏洞：CVE-2023-54069	high
279889	Linux Distros 未修补的漏洞：CVE-2022-50726	high

检测

Nessus 的 Misc. 系列

high

high

medium

medium

high

high

high

medium

medium

medium

medium

medium

high

high

medium

medium

medium

medium

high

medium

medium

medium

high

medium

medium

medium

high

medium

medium

medium

medium

medium

high

medium

medium

high

medium

medium

medium

high

medium

medium

medium

high

high

medium

medium

medium

high

high