检测

Ubuntu 22.04 LTS：Linux 内核 (OEM) 漏洞 (USN-6688-1)

high Nessus 插件 ID 191796

语言：

简介

远程 Ubuntu 主机缺少一个或多个安全更新。

描述

远程 Ubuntu 22.04 LTS 主机上安装的程序包受到 USN-6688-1 公告中提及的多个漏洞的影响。

 - Xen 的虚拟网络协议中的传输请求可由多个部分组成。尽管这些部分在实际上并不实用，但除初始部分外，它们中的任何一个长度都可能为零，即完全不携带任何数据。除了要传输的数据的某个初始部分，这些部分还会直接转换为 Linux 所称的 SKB 片段。当此类转换后的请求部分对于特定 SKB 而言长度均为零时，可导致在核心网络代码中出现空指针取消引用漏洞。(CVE-2023-46838)

 - 在 6.6.5 及之前的 Linux 内核中，由于 info->pad0 未被初始化，drivers/accel/habanalabs/common/habanalabs_ioctl.c 中的 sec_attest_info 可导致信息泄露至用户空间。(CVE-2023-50431)

 - 在 Linux 内核中，以下漏洞已修复：f2fs：明确使 xattr 列表以 null 结尾 设置 xattr 时，明确使 xattr 列表以 null 结尾。这使得未使用的 xattr 空间始终为零这一经不起推敲的假设无效。(CVE-2023-52436)

 - 在 Linux 内核中，以下漏洞已修复：binder：修复 shinker 回调中的释放后使用 在 shrinker 回调期间使用 mmap 读取锁定意味着使用 alloc->vma 指针不安全，因为它会与 munmap() 发生争用。自提交 dd2283f2605e（mm：mmap：munmap 中含有读取 mmap_sem 的 zap 页面）起，mmap 锁定在 vma 被隔离之后发生降级。通过 shrinker 的调试 sysfs，我能够手动添加一些延迟并触发页面回收来重现此问题。以下 KASAN 报告证实了 UAF：
 ================================================== ================ 缺陷：KASAN：zap_page_range_single+0x470/0x4b8 中存在 slab-use-after-free-with 读取大小为 8 位置：addr ffff356ed50e50f0 按任务 bash/478 CPU：1 PID：478 命令：bash 未感染 6.6.0-rc5-00055-g1c8b86a3799f-dirty #70 硬件名称：linux,dummy-virt (DT) 调用跟踪：zap_page_range_single+0x470/0x4b8 binder_alloc_free_page+0x608/0xadc
 __list_lru_walk_one+0x130/0x3b0 list_lru_walk_node+0xc4/0x22c binder_shrink_scan+0x108/0x1dc shrinker_debugfs_scan_write+0x2b4/0x500 full_proxy_write+0xd4/0x140 vfs_write+0x1ac/0x758 ksys_write+0xf0/0x1dc __arm64_sys_write+0x6c/0x9c 根据任务 492 分配：kmem_cache_alloc+0x130/0x368 vm_area_alloc+0x2c/0x190 mmap_region+0x258/0x18bc do_mmap+0x694/0xa60 vm_mmap_pgoff+0x170/0x29c ksys_mmap_pgoff+0x290/0x3a0 __arm64_sys_mmap+0xcc/0x144 根据任务 491 释放：kmem_cache_free+0x17c/0x3c8 vm_area_free_rcu_cb+0x74/0x98 rcu_core+0xa38/0x26d4 rcu_core_si+0x10/0x1c __do_softirq+0x2fc/0xd24 上次可能相关的工作创建：__call_rcu_common.constprop.0+0x6c/0xba0 call_rcu+0x10/0x1c vm_area_free+0x18/0x24 remove_vma+0xe4/0x118 do_vmi_align_munmap.isra.0+0x718/0xb5c do_vmi_munmap+0xdc/0x1fc __vm_munmap+0x10c/0x278 __arm64_sys_munmap+0x58/0x7c 通过执行 vma_lookup() 来解决此问题，此函数在 mmap 锁定降级之后才能找到被隔离的 vma。
 请注意，与升级至 mmap 写入锁定（会增加争夺概率）相比，此选项的效果更好。此外，mmap_write_trylock() 已于近期删除。(CVE-2023-52438)

 - 在 Linux 内核中，以下漏洞已修复：uio：修复 uio_open core-1 core-2 中的释放后使用 ------------------------------------------------------- uio_unregister_device uio_open idev = idr_find() device_unregister(&idev->dev) put_device(&idev->dev) uio_device_release get_device(&idev->dev) kfree(idev) uio_free_minor(minor) uio_release put_device(&idev->dev) kfree(idev)
 ------------------------------------------------------- 在 core-1 uio_unregister_device() 中，如果 idev->dev kobject ref 为 1，device_unregister 将 kfree idev。但在执行 core-1 device_unregister、put_device 与 kfree 之间，core-2 可能会 get_device。然后：1. 在 core-1 kfree idev 之后，core-2 将会为 idev 执行释放后使用。2. core-2 执行 uio_release 和 put_device 后，idev 将被双重释放。要解决此问题，我们可通过 minor_lock 获取 idev atomic 和 inc idev 引用。
 (CVE-2023-52439)

 - 在 Linux 内核中，以下漏洞已修复：apparmor：避免解析的配置文件名称为空时发生崩溃 处理 unpack_profile() 中的打包配置文件时，如配置文件 :ns::samba-dcerpcd /usr/lib*/samba/{,samba/}samba-dcerpcd {...} 所述，字符串 :samba-dcerpcd 被解包为完全限定名称，然后传递至 aa_splitn_fqname()。aa_splitn_fqname() 视 :samba-dcerpcd 仅包含命名空间。因此，它会为 tmpname 返回 NULL，同时 tmpns 为非 NULL。稍后，aa_alloc_profile() 崩溃，因为新的配置文件名称现在为 NULL。一般保护错误，可能适用于非规范地址 0xdffffc0000000000：0000 [#1] PREEMPT SMP KASAN NOPTI KASAN：null-ptr-deref 在范围内 [0x0000000000000000-0x0000000000000007] CPU：6 PID：1657 命令：apparmor_parser 未感染 6.7.0-rc2-dirty #16 硬件名称：QEMU Standard PC（i440FX + PIIX，1996），BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014 RIP: 0010:strlen+0x1e/0xa0 调用跟踪：<TASK> ? strlen+0x1e/0xa0 aa_policy_init+0x1bb/0x230 aa_alloc_profile+0xb1/0x480 unpack_profile+0x3bc/0x4960 aa_unpack+0x309/0x15e0 aa_replace_profiles+0x213/0x33c0 policy_update+0x261/0x370 profile_replace+0x20e/0x2a0 vfs_write+0x2af/0xe00 ksys_write+0x126/0x250 do_syscall_64+0x46/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0x76 </TASK> ---[结束跟踪 0000000000000000]--- RIP：
 0010:strlen+0x1e/0xa0 aa_splitn_fqname() 的此类行为似乎在预期之中，并在被调用的其他位置（例如 aa_remove_profiles）进行检查。内部有一个明确的注释：可以使用不含以下配置文件的 ns 名称。AFAICS，没有什么能够阻止解包名称采用类似 :samba-dcerpcd 的格式，因为名称从用户空间传递而来。拒绝在此类情况下替换整个配置文件设置，并通过 EPROTO 向用户发送解释消息通知。由 Linux 验证中心 (linuxtesting.org) 发现。
 (CVE-2023-52443)

 - 在 Linux 内核中，以下漏洞已修复：f2fs：经过修复，可避免 dirent 损坏 如 Al 在 link[1] 中所报告的那样：f2fs_rename() ... 如果 (old_dir != new_dir && !whiteout) f2fs_set_link(old_inode, old_dir_entry, old_dir_page, new_dir); 否则 f2fs_put_page(old_dir_page, 0); 您需要修正 .. 链接中的编号。而且跨目录重命名会将来源移动到新的父项，即使系统要求您在旧地方留下 whiteout。[1] https://lore.kernel.org/all/20231017055040.GN800259@ZenIV/ 使用下面的测试案例时，可能导致 dirent 损坏，因为它未调用 f2fs_set_link() 来更新…
 链接到新目录。- mkdir -p dir/foo - renameat2 -w dir/foo bar [ASSERT] (__chk_dots_dentry:1421)
 --> '..' 的错误 inode 编号 [0x4]，父 ino 为 [0x3] [FSCK] 其他损坏缺陷 [失败] (CVE-2023-52444)

 - 在 Linux 内核中，以下漏洞已修复：media：pvrusb2：修复上下文断开连接时发生的释放后使用 在模块加载时，系统为 pvr2_context_thread_func 函数创建了一个 kthread，该函数可以调用 pvr2_context_destroy，因而也能调用上下文对象上的 kfree()。不过，这可能发生在 usb hub_event 处理程序通知驱动程序之前。在 syzbot 报告无效读取之前，此补丁已在上下文断开连接调用堆栈内添加健全性检查。(CVE-2023-52445)

 - 在 Linux 内核中，以下漏洞已修复：bpf：必要时，延迟释放内部映射 更新或删除映射数组或映射 htab 中的内部映射时，不休眠程序或休眠程序仍可能访问该映射。但是，如果 ref-counter 排在最后（大多数情况下为 true），bpf_map_fd_put_ptr() 会直接通过 bpf_map_put() 减少内部映射的 ref-counter，并且内部映射将被 kworker 中的 ops->map_free() 释放。但目前，大多数 .map_free() 回调不会使用 synchronize_rcu() 或其变体来等待 RCU 宽限期过去，因此在 ops->map_free 调用完成后，访问内部映射的 bpf 程序可能会引发释放后使用问题。通过在一个 RCU 宽限期和一个任务跟踪 RCU 宽限期之后调用 bpf_map_free_deferred()（如果之前已从外部映射中删除内部映射），修复内部映射释放。如果要释放 bpf 映射的最后一个 ref-counter，可使用 call_rcu() 或 call_rcu_tasks_trace() 来达到延迟释放的目的。bpf_map 中新增的 rcu_head 字段与 work 字段共用同一存储空间，以减小 bpf_map 的大小。(CVE-2023-52447)

 - 在 Linux 内核中，以下漏洞已修复：gfs2：修复 gfs2_rgrp_dump 中的内核空指针取消引用 据 Syzkaller 报告，访问 gfs2_rgrp_dump() 中的 rgd->rd_rgl 时发生空指针取消引用。在 read_rindex_entry() 中创建 rgd->rd_gl 失败时，会发生这种情况。在 gfs2_rgrp_dump() 中添加空指针检查，以防出现该问题。(CVE-2023-52448)

 - 在 Linux 内核中，以下漏洞已修复：mtd：修复 ftl 通知程序造成的 gluebi 空指针取消引用 如果 ftl.ko 和 gluebi.ko 都已加载，尝试访问 gluebi_read() 中的 gluebi->desc' 时，ftl 的通知程序会触发空指针取消引用。ubi_gluebi_init ubi_register_volume_notifier ubi_enumerate_volumes ubi_notify_all gluebi_notify nb->notifier_call() gluebi_create mtd_device_register mtd_device_parse_register add_mtd_device blktrans_notify_add not->add() ftl_add_mtd tr->add_mtd() scan_header mtd_read mtd_read_oob mtd_read_oob_std gluebi_read mtd->read() gluebi->desc - NULL 如需再现问题详情，请访问链接 [1]。正常情况下，请在 gluebi_get_device() 中获取 gluebi->desc，并在 gluebi_read() 中访问 gluebi->desc。但是，gluebi_get_device() 不会提前在 ftl_add_mtd() 进程中执行，导致发生空指针取消引用。适用于 gluebi 模块的解决方案是在 UBI 卷上运行 jffs2，而不考虑使用 ftl 或 mtdblock [2]。因此，通过阻止 gluebi 在创建类型 MTD_UBIVOLUME 的 mtd 分区后创建 mtdblock 设备，可避免此问题。(CVE-2023-52449)

 - 在 Linux 内核中，以下漏洞已修复：powerpc/pseries/memhp：修复超出 drmem 数组结尾的访问 如果 LMB 查找无法将条目与给定的 DRC 索引匹配，dlpar_memory_remove_by_index() 可能会越界访问 drmem lmb 数组。如果搜索失败，光标仍会指向 &drmem_info->lmbs[drmem_info->n_lmbs]，即数组中最后一个有效条目之后的元素。函数末尾的调试消息随后可取消引用此指针：
 pr_debug（无法热删除 %llx\n 的内存，lmb->base_addr）；检查时发现了问题，并通过 KASAN 进行了确认：pseries-hotplug-mem：尝试热删除 LMB，drc 索引 1234 ======================== ========================================== 缺陷：KASAN：dlpar_memory+0x298/0x1658 中存在 slab-out-of-bounds 读取大小为 8 位置：addr c000000364e97fd0 按任务 bash/949 dump_stack_lvl+0xa4/0xfc (unreliable) print_report+0x214/0x63c kasan_report+0x140/0x2e0
 __asan_load8+0xa8/0xe0 dlpar_memory+0x298/0x1658 handle_dlpar_errorlog+0x130/0x1d0 dlpar_store+0x18c/0x3e0 kobj_attr_store+0x68/0xa0 sysfs_kf_write+0xc4/0x110 kernfs_fop_write_iter+0x26c/0x390 vfs_write+0x2d4/0x4e0 ksys_write+0xac/0x1a0 system_call_exception+0x268/0x530 system_call_vectored_common+0x15c/0x2ec 由任务 1 分配：kasan_save_stack+0x48/0x80 kasan_set_track+0x34/0x50 kasan_save_alloc_info+0x34/0x50 __kasan_kmalloc+0xd0/0x120 __kmalloc+0x8c/0x320 kmalloc_array.constprop.0+0x48/0x5c drmem_init+0x2a0/0x41c do_one_initcall+0xe0/0x5c0 kernel_init_freeable+0x4ec/0x5a0 kernel_init+0x30/0x1e0 ret_from_kernel_user_thread+0x14/0x1c 有缺陷的地址属于 c000000364e80000 中的对象（属于大小为 131072 的缓存 kmalloc-128k）。有缺陷的地址位于被分配 98256 字节的区域的右侧 0 字节处 [c000000364e80000, c000000364e97fd0) ================================================================== pseries-hotplug-mem：
 无法删除 0 处的内存 系统无法记录通过单独的消息执行的查找，并且仅当光标指向有效条目时才能取消引用。(CVE-2023-52451)

 - 在 Linux 内核中，以下漏洞已修复：nvmet-tcp：修复主机发送无效 H2C PDU 长度时发生的内核错误 如果主机发送含有无效 DATAL 的 H2CData 命令，内核在 nvmet_tcp_build_pdu_iovec() 中可能会崩溃。无法处理虚拟地址 0000000000000000 中发生的内核空指针取消引用 lr：nvmet_tcp_io_work+0x6ac/0x718 [nvmet_tcp] 调用跟踪：
 process_one_work+0x174/0x3c8 worker_thread+0x2d0/0x3e8 kthread+0x104/0x110 如果 DATAL 与数据包大小不一致，则通过触发致命错误来修复此缺陷。此外，PDU 长度不应超过 MAXH2CDATA 参数，该参数已在 nvmet_tcp_handle_icreq() 中传递给主机。(CVE-2023-52454)

 - 在 Linux 内核中，以下漏洞已修复：serial：imx：修复 tx 状态机死锁 串行端口用作 RS485 端口时，tx 状态机用于控制 RTS pin，以驱动 RS485 收发器 TX_EN pin。如果 TTY 端口在传输过程中关闭（例如，在 userland 应用程序崩溃期间），imx_uart_shutdown 会禁用接口并禁用“传输完成”中断。之后，imx_uart_stop_tx 会结束 TC 中断重新触发的不完整传输。此中断已禁用，因此 tx 状态机永不转换出 SEND。状态机现在处于死锁状态，并且 TX_EN 仍然很低，导致接口无法使用。imx_uart_stop_tx 现在会在重新触发退出之前检查是否有不完整的传输以及 TC 中断是否已启用。这可确保状态机被处理并正确设置为 WAIT_AFTER_SEND。(CVE-2023-52456)

 - 在 Linux 内核中，以下漏洞已修复：serial：8250：omap：如果 pm_runtime_resume_and_get() 失败，则不跳过资源释放 从 .remove() 返回错误代码可使驱动程序核心发出“几乎无用”的错误消息：移除回调返回了非零值。系统会忽略此消息，然后仍然移除设备。因此，在这种情况下，所有未释放的资源都会被泄露。
 跳过 serial8250_unregister_port() 可能会保留足够的 UART，从而触发释放后使用。因此，以更有用的错误消息替换返回的错误（以及“几乎无用”的错误消息）并继续清理。(CVE-2023-52457)

 - 在 Linux 内核中，以下漏洞已修复：block：添加对分区长度是否需要与区块大小保持一致的检查 调用“添加分区”或“调整分区大小”之前，未检查长度是否与逻辑区块大小保持一致。如果磁盘的逻辑区块大小超过 512 字节，则分区大小可能不是逻辑区块大小的倍数。此外，读取最后一个扇区时，bio_truncate() 将调整 bio 大小，如果读取命令的大小小于逻辑区块大小，则会导致 IO 错误。如果支持完整性数据，这还将导致调用 bio_integrity_free 时发生空指针取消引用。(CVE-2023-52458)

 - 在 Linux 内核中，以下漏洞已修复：bpf：修复对尝试损坏溢出指针的检查 当寄存器作为 1/2/4 字节寄存器在堆栈上溢出时，我们会设置 slot_type[BPF_REG_SIZE - 1]（以及其下方可能发生更多少量溢出，具体取决于实际溢出大小）。因此，要检查某个堆栈槽是否发生了寄存器溢出，我们需要查询 slot_type[7]，而非 slot_type[0]。为避免以后需要记住和仔细检查此项，只需使用 is_spilled_reg() 辅助函数即可。
 (CVE-2023-52462)

 - 在 Linux 内核中，以下漏洞已修复：efivarfs：如果不支持 SetVariable，在重新挂载时会强制执行 RO 如果固件不支持运行时的 SetVariable，我们绝不会为该函数分配回调。同时将 efivarfs 挂载为 RO，让任何人都无法调用。但是，我们从不会检查权限标记，除非有人将文件系统重新挂载为 RW。因此，这会导致崩溃，具体如下所示：$ mount -o remount,rw /sys/firmware/efi/efivars $ efi-updatevar -f PK.auth PK [303.279166] 无法处理虚拟地址 0000000000000000 的内核空指针取消引用 [303.280482] 内存中止信息：[ 303.280854] ESR = 0x0000000086000004 [ 303.281338] EC = 0x21：IABT（当前 EL），IL = 32 位 [ 303.282016] SET = 0，FnV = 0 [ 303.282414] EA = 0，S1PTW = 0 [ 303.282821] FSC = 0x04：
 0 级转换错误 [ 303.283771] 用户 pgtable：4k 页面，48 位虚拟机，pgdp=000000004258c000 [303.284913] [0000000000000000] pgd=0000000000000000、p4d=0000000000000000 [ 303.286076] 内部错误：
 Oops：0000000086000004 [#1] PREEMPT SMP [ 303.286936] 模块链接位置：qrtr tpm_tis tpm_tis_core crct10dif_ce arm_smccc_trng rng_core drm fuse ip_tables x_tables ipv6 [ 303.288586] CPU：1 PID：755 命令：
 efi-updatevar 未感染 6.3.0-rc1-00108-gc7d0c4695c68 #1 [ 303.289748] 硬件名称：未知 未知产品/未知产品，BIOS 2023.04-00627-g88336918701d 04/01/2023 [ 303.291150] pstate：60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 303.292123] pc：0x0 [ 303.292443] lr：
 efivar_set_variable_locked+0x74/0xec [ 303.293156] sp：ffff800008673c10 [ 303.293619] x29：
 ffff800008673c10 x28：ffff0000037e8000 x27：0000000000000000 [ 303.294592] x26：0000000000000800 x25：
 ffff000002467400 x24：0000000000000027 [ 303.295572] x23：ffffd49ea9832000 x22：ffff0000020c9800 x21：
 ffff000002467000 [ 303.296566] x20：0000000000000001 x19：00000000000007fc x18：0000000000000000 [303.297531] x17：0000000000000000 x16：0000000000000000 x15：0000aaaac807ab54 [ 303.298495] x14：
 ed37489f673633c0 x13：71c45c606de13f80 x12：47464259e219acf4 [ 303.299453] x11：ffff000002af7b01 x10：
 0000000000000003 x9：0000000000000002 [ 303.300431] x8：0000000000000010 x7：ffffd49ea8973230 x6：
 0000000000a85201 [ 303.301412] x5：0000000000000000 x4：ffff0000020c9800 x3：00000000000007fc [303.302370] x2：0000000000000027 x1：ffff000002467400 x0：ffff000002467000 [ 303.303341] 调用跟踪：[303.303679] 0x0 [ 303.303938] efivar_entry_set_get_size+0x98/0x16c [ 303.304585] efivarfs_file_write+0xd0/0x1a4 [ 303.305148] vfs_write+0xc4/0x2e4 [ 303.305601] ksys_write+0x70/0x104 [303.306073] __arm64_sys_write+0x1c/0x28 [ 303.306622] invoke_syscall+0x48/0x114 [ 303.307156] el0_svc_common.constprop.0+0x44/0xec [ 303.307803] do_el0_svc+0x38/0x98 [ 303.308268] el0_svc+0x2c/0x84 [303.308702] el0t_64_sync_handler+0xf4/0x120 [ 303.309293] el0t_64_sync+0x190/0x194 [ 303.309794] 代码：
 ???????? ???????? ???????? ???????? (????????) [ 303.310612] ---[结束跟踪 0000000000000000]--- 通过向 fs 操作添加 .reconfigure() 函数修复此漏洞，我们可以使用此函数检查请求的标记，并拒绝不是 RO 的任何内容（前提是固件在运行时未实施 SetVariable）。(CVE-2023-52463)

 - 在 Linux 内核中，以下漏洞已修复：EDAC/thunderx：修复可能存在的越界字符串访问 如果在全局范围启用 -Wstringop-overflow，系统会针对使用 strncat() 时存在的常见缺陷显示警告消息：drivers/edac /thunderx_edac.c：在函数“thunderx_ocx_com_threaded_isr”中：
 drivers/edac/thunderx_edac.c:1136:17：错误：“strncat”指定的边界 1024 等于目标大小 [-Werror=stringop-overflow=] 1136 | strncat(msg, other, OCX_MESSAGE_SIZE); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ... 1145 | strncat(msg, other, OCX_MESSAGE_SIZE); ... 1150 | strncat(msg, other, OCX_MESSAGE_SIZE); ... 显然，此驱动程序的作者预期 strncat() 会以 strlcat() 的方式运行，后者使用目标缓冲区的大小而不是源缓冲区的长度作为第三个参数。结果就是系统不会检查已分配缓冲区的大小，而是将其更改为 strlcat()。[ bp：调整编译器输出，修复提交消息。] (CVE-2023-52464)

 - 在 Linux 内核中，以下漏洞已修复：mfd：syscon：修复 of_syscon_register() 中的空指针取消引用 kasprintf() 会向动态分配内存返回一个指针，此指针在发生故障时会变为空。(CVE-2023-52467)

 - 在 Linux 内核中，以下漏洞已修复：drivers/amd/pm：修复 kv_parse_power_table 中的释放后使用 如果 kzalloc 分配的 ps 为空，kv_parse_power_table 会释放之前分配的 adev->pm.dpm.ps。但是，在控制流经过以下调用链之后：kv_parse_power_table |-> kv_dpm_init |-> kv_dpm_sw_init |-> kv_dpm_fini 在 kv_parse_power_table 中第一次释放后，adev->pm.dpm.ps 用于 kv_dpm_fini 的 for 循环，并且会造成释放后使用缺陷。(CVE-2023-52469)

 - 在 Linux 内核中，以下漏洞已修复：drm/radeon：检查 radeon_crtc_init() 中的 alloc_workqueue 返回值 检查 radeon_crtc_init() 中的 alloc_workqueue 返回值，以避免 null-ptr-deref。(CVE-2023-52470)

 - 在 Linux 内核中，以下漏洞已修复：ceph：修复因滥用 dget() 而造成的死锁或死代码 denty 与其父项之间的锁定顺序不正确，我们应始终确保父项先被锁定。但由于从未使用过此死代码且始终通过调用程序设置父目录，我们只需将其移除即可。(CVE-2023-52583)

 - 在 Linux 内核中，以下漏洞已修复：spmi：mediatek：修复移除设备时出现的 UAF 包含时钟的 pmif 驱动程序数据会与 spmi_controller 一起被分配。移除设备时，会首先释放 spmi_controller，然后再清理 devres，包括时钟。这会导致 UAF，因为放置时钟将访问 pmif 驱动程序数据中的时钟，而此数据已随 spmi_controller 一起释放。启用 DEBUG_TEST_DRIVER_REMOVE 并利用 KASAN 构建内核可重现此问题。通过使用非托管的 clk_bulk_get() 并在释放 spmi_controller 之前放置时钟即可解决 UAF 问题。(CVE-2023-52584)

 - 在 Linux 内核中，以下漏洞已修复：IB/ipoib：修复 mcast 列表锁定 在迭代“ipoib_mcast_join_task()”中的“priv->multicast_list”的同时释放“priv->lock”会为“ipoib_mcast_dev_flush()”打开窗口，导致项目在迭代过程中被移除。如果在解除锁定的同时移除 mcast，for 循环会永不停止，从而导致硬锁定（正如 RHEL 4.18.0-372.75.1.el8_6 内核中所报告的那样）：任务 A（下方的 kworker/u72:2）| 任务 B（下方的 kworker/u72:0）
 -----------------------------------+----------------------------------- ipoib_mcast_join_task(work) | ipoib_ib_dev_flush_light(work) spin_lock_irq(&priv->lock) | __ipoib_ib_dev_flush(priv, ...) list_for_each_entry(mcast, | ipoib_mcast_dev_flush(dev = priv->dev) &priv->multicast_list, list) | ipoib_mcast_join(dev, mcast) | spin_unlock_irq(&priv->lock) | | spin_lock_irqsave(&priv->lock, flags) | list_for_each_entry_safe(mcast, tmcast, | &priv->multicast_list, list) | list_del(&mcast->list); | list_add_tail(&mcast->list, &remove_list) | spin_unlock_irqrestore(&priv->lock, flags) spin_lock_irq(&priv->lock) | | ipoib_mcast_remove_list(&remove_list) (Here, `mcast` is no longer on the | list_for_each_entry_safe(mcast, tmcast, `priv->multicast_list` and we keep | remove_list, list) spinning on the `remove_list` of | >>> wait_for_completion(&mcast->done) the other thread which is blocked | and the list is still valid on | it's stack.) 通过保持锁定并变更为 GFP_ATOMIC 来解决此问题，以防最终休眠。遗憾的是，我们无法重现锁定问题并确认此修复，但根据代码审查，我认为此修复应该可以解决此类锁定问题。crash> bc 31 PID：747 TASK：ff1c6a1a007e8000 CPU：31 命令：kworker/u72:2 -- [异常 RIP：ipoib_mcast_join_task+0x1b1] RIP：ffffffffc0944ac1 RSP：ff646f199a8c7e00 RFLAGS：00000002 RAX：0000000000000000 RBX：ff1c6a1a04dc82f8 RCX：0000000000000000 work (&priv->mcast_task{,.work}) RDX：ff1c6a192d60ac68 RSI：0000000000000286 RDI：ff1c6a1a04dc8000 &mcast->list RBP：ff646f199a8c7e90 R8：ff1c699980019420 R9：ff1c6a1920c9a000 R10：ff646f199a8c7e00 R11：
 ff1c6a191a7d9800 R12：ff1c6a192d60ac00 mcast R13：ff1c6a1d82200000 R14：ff1c6a1a04dc8000 R15：
 ff1c6a1a04dc82d8 dev priv (&priv->lock) &priv->multicast_list（即 head）ORIG_RAX：ffffffffffffffff CS：
 0010 SS：0018 --- <NMI exception stack> --- #5 [ff646f199a8c7e00] ffffffffc0944ac1 中的 ipoib_mcast_join_task+0x1b1 [ib_ipoib] #6 [ff646f199a8c7e98] ffffffff9bf10967 中的 process_one_work+0x1a7 crash> rx ff646f199a8c7e68 ff646f199a8c7e68：ff1c6a1a04dc82f8 <<< work = &priv->mcast_task.work crash> list -hO ipoib_dev_priv.multicast_list ff1c6a1a04dc8000 (empty) crash> ipoib_dev_priv.mcast_task.work.func,mcast_mutex.owner.counter ff1c6a1a04dc8000 mcast_task.work.func = 0xffffffffc0944910 <ipoib_mcast_join_task>, mcast_mutex.owner.counter = 0xff1c69998efec000 crash> b 8 PID：
 8 任务：ff1c69998efec000 CPU：33 命令：kworker/u72:0 -- #3 [ff646f1980153d50] ffffffff9c7d7646 中的 wait_for_completion+0x96 #4 [ff646f1980153d90] ffffffffc0944dc6 中的 ipoib_mcast_remove_list+0x56 [ib_ipoib] #5 [ff646f1980153de8] ffffffffc09455a7 中的 ipoib_mcast_dev_flush+0x1a7 [ib_ipoib] #6 [ff646f1980153e58] ffffffffc09431a4 中的 __ipoib_ib_dev_flush+0x1a4 [ib_ipoib] #7 [ff
 ---truncated--- (CVE-2023-52587)

 - 在 Linux 内核中，以下漏洞已修复：f2fs：经过修复，可在区块迁移期间在页面上添加 gcing 标记 在区块迁移期间，在页面上添加缺少的 gcing 标记才能保证迁移的数据在检查点期间持续存在，否则数据和节点之间持久存在的乱序问题可能会在 SPOR 后造成数据损坏。类似的问题已通过提交 2d1fe8a86bf5 解决（f2fs：经过修复，可在文件碎片整理期间在页面上添加 gcing 标记）。(CVE-2023-52588)

 - 在 Linux 内核中，以下漏洞已修复：media：rkisp1：解决 IRQ 禁用争用问题 在 rkisp1_isp_stop() 和 rkisp1_csi_disable() 中，驱动程序会屏蔽中断，然后理所当然地假设中断处理程序不会运行并继续执行停止程序。实际情况并非如此，因为中断处理程序可能已经在运行，导致 ISP 在中断处理程序处理捕获的帧时被禁用。这会带来两个问题：1) ISP 在中断处理程序仍在运行并访问寄存器的情况下被关闭，从而导致板锁定，以及 2) 中断处理程序代码和用于禁用流的代码可能发生冲突。我不清楚 2) 是否会造成真正的问题，但发现 1) 会导致中断处理程序出现适当的延迟（在本例中为 printk），进而导致板锁定。(CVE-2023-52589)

 - 在 Linux 内核中，以下漏洞已修复：wifi：wfx：修复 wfx_set_mfp_ap() 中可能存在的空指针取消引用 由于“ieee80211_beacon_get()”可以返回空值，所以“wfx_set_mfp_ap()”应在检查 skb 数据之前检查返回值。因此，转换后者可返回相应的错误代码，并进行传播，从而也从“wfx_start_ap()”返回。仅测试编译文件。(CVE-2023-52593)

 - 在 Linux 内核中，以下漏洞已修复：wifi：ath9k：修复 ath9k_htc_txstatus() 中潜在的 array-index-out-of-bounds 读取 修复 ath9k_htc_txstatus() 中的 array-index-out-of-bounds 读取。如果 txs->cnt（来自 USB 设备提供的 URB 数据）大于数组 txs->txstatus 的大小（即 HTC_MAX_TX_STATUS）时，会发生此缺陷。WARN_ON() 已对其进行检查，但是检查之后未发现缺陷处理代码。如果是这样，请返回函数。此问题由 syzkaller 的修改版本发现。UBSAN：htc_drv_txrx.c 索引 13 中的 array-index-out-of-bounds 超出类型“__wmi_event_txstatus [12]”的范围 调用跟踪：ath9k_htc_txstatus ath9k_wmi_event_tasklet tasklet_action_common __do_softirq irq_exit_rxu sysvec_apic_timer_interrupt (CVE-2023-52594)

 - 在 Linux 内核中，以下漏洞已修复：wifi：rt2x00：硬件重置时，重新启动信标队列 触发硬件重置时，所有寄存器都会被重置，因此硬件接口中的所有队列都会被强制停止。但是，mac80211 不会自动停止队列。如果我们不手动停止信标队列，队列将被死锁并且无法再次启动。此补丁修复了 Apple 设备调用 ieee80211_restart_hw() 后无法连接到 AP 的问题。
 (CVE-2023-52595)

 - 在 Linux 内核中，以下漏洞已修复：KVM：s390：修复 fpc 寄存器的设置 kvm_arch_vcpu_ioctl_set_fpu() 允许设置客户机 cpu 的浮点控制 (fpc) 寄存器。通过将新值临时加载到 fpc 寄存器中来测试新值是否有效。这可能导致主机进程中的 fpc 寄存器在发生损坏：如果在将值临时加载到 fpc 寄存器中时发生中断，并且在中断上下文内使用了浮点或矢量寄存器，则当前 fp/vx 寄存器会与 save_fpu_regs() 一并保存。假设二者都属于用户空间，则会在返回到用户空间时加载到 fp/vx 寄存器中。test_fp_ctl() 会还原原始用户空间/主机进程中的 fpc 寄存器值，但当返回用户空间时，此值将被舍弃。因此，主机进程将按预期用于客户机 cpu 的值继续错误运行。
 只需移除该测试即可解决此问题。在进入 SIE 上下文之前有另一个测试，用于处理无效值。这会导致行为变更：现在接受无效值，而非导致 ioctl 失败的 -EINVAL 值。鉴于此接口很可能不再使用，而且这与通过内存映射接口实施的行为相同（以零替换无效值），这似乎是可以接受的 - 请参阅 kvm-s390.c 中的 sync_regs()。(CVE-2023-52597)

 - 在 Linux 内核中，以下漏洞已修复：s390/ptrace：正确处理 fpc 寄存器的设置 在受跟踪的进程中，如果浮点控制 (fpc) 寄存器的内容在 ptrace 界面上被修改，则需要临时将新值加载到 fpc 寄存器中来测试其是否有效。这可能导致 fpc 寄存器在跟踪进程中发生损坏：如果在将值临时加载到 fpc 寄存器中时发生中断，并且在中断上下文内使用了浮点或矢量寄存器，则当前 fp/vx 寄存器会与 save_fpu_regs() 一并保存。假设二者都属于用户空间，则会在返回到用户空间时加载到 fp/vx 寄存器中。
 test_fp_ctl() 会还原原始用户空间的 fpc 寄存器值，但当返回用户空间时，此值将被舍弃。因此，跟踪程序将按预期用于受跟踪进程的值继续错误运行。此问题的解决方法如下：在使用 test_fp_ctl() 之前，以 save_fpu_regs() 保存 fpu 寄存器内容。(CVE-2023-52598)

 - 在 Linux 内核中，以下漏洞已修复：jfs：修复 diNewExt 中的 array-index-out-of-bounds [Syz 报告] UBSAN：fs/jfs/jfs_imap.c:2360:2 index -878706688 中的 array-index-out-of-bounds 超过类型“struct iagctl[128]”的范围 CPU：1 PID：5065 命令：syz-executor282 未感染 6.7.0-rc4-syzkaller-00009-gbee0e7762ad2 #0 硬件名称：Google Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023 调用跟踪：<TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106 ubsan_epilogue lib/ubsan.c:217 [inline]
 __ubsan_handle_out_of_bounds+0x11c/0x150 lib/ubsan.c:348 diNewExt+0x3cf3/0x4000 fs/jfs/jfs_imap.c:2360 diAllocExt fs/jfs/jfs_imap.c:1949 [inline] diAllocAG+0xbe8/0x1e50 fs/jfs/jfs_imap.c:1666 diAlloc+0x1d3/0x1760 fs/jfs/jfs_imap.c:1587 ialloc+0x8f/0x900 fs/jfs/jfs_inode.c:56 jfs_mkdir+0x1c5/0xb90 fs/jfs/namei.c:225 vfs_mkdir+0x2f1/0x4b0 fs/namei.c:4106 do_mkdirat+0x264/0x3a0 fs/namei.c:4129
 __do_sys_mkdir fs/namei.c:4149 [inline] __se_sys_mkdir fs/namei.c:4147 [inline] __x64_sys_mkdir+0x6e/0x80 fs/namei.c:4147 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x45/0x110 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x63/0x6b RIP：0033:0x7fcb7e6a0b57 代码：ff ff 77 07 31 c0 c3 0f 1f 40 00 48 c7 c2 b8 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 b8 53 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP：
 002b:00007ffd83023038 EFLAGS：00000286 ORIG_RAX：0000000000000053 RAX：ffffffffffffffda RBX：
 00000000ffffffff RCX：00007fcb7e6a0b57 RDX：00000000000a1020 RSI：00000000000001ff RDI：0000000020000140 RBP：0000000020000140 R08：0000000000000000 R09：0000000000000000 R10：0000000000000000 R11：
 0000000000000286 R12：00007ffd830230d0 R13：0000000000000000 R14：0000000000000000 R15：0000000000000000 [分析] agstart 过大会造成 agno 溢出。[修复] 获取 agno 之后，如果值无效，则退出后续进程。根据内核测试机器人 (Dan Carpenter) 的 linux-next 报告，将测试从 agno > MAXAG 改为 agno >= MAXAG。(CVE-2023-52599)

 - 在 Linux 内核中，以下漏洞已修复：jfs：修复 jfs_evict_inode 中的 uaf 执行 diMount(ipimap) 失败时，已释放的对象 ipimap 或可在 diFreeSpecial() 中进行访问。rcu_core() 调用 jfs_free_node() 时发生异步 ipimap 释放。因此，diMount(ipimap) 失败时，sbi->ipimap 不应被初始化为 ipimap。(CVE-2023-52600)

 - 在 Linux 内核中，以下漏洞已修复：jfs：修复 dbAdjTree 中的 array-index-out-of-bounds 当前，访问 dmt_stree 时，dbAdjTree 中缺少边界检查。要添加所需的检查，请根据以下提交中的建议添加确定大小所需的 bool is_ctl。https://lore.kernel.org/linux-kernel-mentees/f9475918-2186-49b8-b801-6f0f9e75f4fa@oracle.com/ (CVE-2023-52601)

 - 在 Linux 内核中，以下漏洞已修复：jfs：修复 dtSearch 中的 slab-out-of-bounds 读取 目前，在页面的已排序条目表中搜索当前页面时，会发生越界访问。已添加边界检查来修复错误。Dave：将返回代码设置为 -EIO (CVE-2023-52602)

 - 在 Linux 内核中，以下漏洞已修复：UBSAN：dtSplitRoot 中的 array-index-out-of-bounds Syzkaller 报告了以下问题：oop0：检测到容量变化范围在 0 到 32768 之间 UBSAN：
 fs/jfs/jfs_dtree.c:1971:9 索引 -2 中的 array-index-out-of-bounds 超出类型“struct dtslot [128]”的范围 CPU：0 PID：3613 命令：syz-executor270 未感染 6.0.0-syzkaller-09423-g493ffd6605b2 #0 硬件名称：Google Google Compute Engine/Google Compute Engine，BIOS Google 09/22/2022 调用跟踪：<TASK>
 __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106 ubsan_epilogue lib/ubsan.c:151 [inline] __ubsan_handle_out_of_bounds+0xdb/0x130 lib/ubsan.c:283 dtSplitRoot+0x8d8/0x1900 fs/jfs/jfs_dtree.c:1971 dtSplitUp fs/jfs/jfs_dtree.c:985 [inline] dtInsert+0x1189/0x6b80 fs/jfs/jfs_dtree.c:863 jfs_mkdir+0x757/0xb00 fs/jfs/namei.c:270 vfs_mkdir+0x3b3/0x590 fs/namei.c:4013 do_mkdirat+0x279/0x550 fs/namei.c:4038 __do_sys_mkdirat fs/namei.c:4053 [inline] __se_sys_mkdirat fs/namei.c:4051 [inline] __x64_sys_mkdirat+0x85/0x90 fs/namei.c:4051 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP：0033:0x7fcdc0113fd9 代码：ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP：002b:00007ffeb8bc67d8 EFLAGS：00000246 ORIG_RAX：0000000000000102 RAX：ffffffffffffffda RBX：0000000000000000 RCX：00007fcdc0113fd9 RDX：
 0000000000000000 RSI：0000000020000340 RDI：0000000000000003 RBP：00007fcdc00d37a0 R08：0000000000000000 R09：00007fcdc00d37a0 R10：00005555559a72c0 R11：0000000000000246 R12：00000000f8008000 R13：
 0000000000000000 R14：00083878000000f8 R15：0000000000000000 </TASK> 此问题因 fsi 的值小于 -1 所致。虽然系统可以检查 fsi 值变为 -1 是否会发生循环中断，但 syzbot 能够产生小于 -1 的值（导致错误）。此补丁只针对小于 0 的值添加更改。此补丁已经过 syzbot 测试。(CVE-2023-52603)

 - 在 Linux 内核中，以下漏洞已修复：FS:JFS:UBSAN:array-index-out-of-boundsin dbAdjTree Syzkaller 报告了以下问题：UBSAN：fs/jfs/jfs_dmap.c:2867:6 索引 196694 中的 array-index-out-of-bounds 超出类型“s8[1365]”（也称为“signed char[1365]”）的范围 CPU：1 PID：109 命令：jfsCommit 未感染 6.6.0-rc3-syzkaller #0 硬件名称：Google Google Compute Engine/Google Compute Engine，BIOS Google 08/04/2023 调用跟踪：<TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106 ubsan_epilogue lib/ubsan.c:217 [inline]
 __ubsan_handle_out_of_bounds+0x11c/0x150 lib/ubsan.c:348 dbAdjTree+0x474/0x4f0 fs/jfs/jfs_dmap.c:2867 dbJoin+0x210/0x2d0 fs/jfs/jfs_dmap.c:2834 dbFreeBits+0x4eb/0xda0 fs/jfs/jfs_dmap.c:2331 dbFreeDmap fs/jfs/jfs_dmap.c:2080 [inline] dbFree+0x343/0x650 fs/jfs/jfs_dmap.c:402 txFreeMap+0x798/0xd50 fs/jfs/jfs_txnmgr.c:2534 txUpdateMap+0x342/0x9e0 txLazyCommit fs/jfs/jfs_txnmgr.c:2664 [inline] jfs_lazycommit+0x47a/0xb70 fs/jfs/jfs_txnmgr.c:2732 kthread+0x2d3/0x370 kernel/kthread.c:388 ret_from_fork+0x48/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304 </TASK> ================================================================================ 内核错误 - 未同步：UBSAN：panic_on_warn 设置… CPU：1 PID：109 命令：jfsCommit 未感染 6.6.0-rc3-syzkaller #0 硬件名称：Google Google Compute Engine/Google Compute Engine，BIOS Google 08/04/2023 调用跟踪：
 <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106 panic+0x30f/0x770 kernel/panic.c:340 check_panic_on_warn+0x82/0xa0 kernel/panic.c:236 ubsan_epilogue lib/ubsan.c:223 [inline] __ubsan_handle_out_of_bounds+0x13c/0x150 lib/ubsan.c:348 dbAdjTree+0x474/0x4f0 fs/jfs/jfs_dmap.c:2867 dbJoin+0x210/0x2d0 fs/jfs/jfs_dmap.c:2834 dbFreeBits+0x4eb/0xda0 fs/jfs/jfs_dmap.c:2331 dbFreeDmap fs/jfs/jfs_dmap.c:2080 [inline] dbFree+0x343/0x650 fs/jfs/jfs_dmap.c:402 txFreeMap+0x798/0xd50 fs/jfs/jfs_txnmgr.c:2534 txUpdateMap+0x342/0x9e0 txLazyCommit fs/jfs/jfs_txnmgr.c:2664 [inline] jfs_lazycommit+0x47a/0xb70 fs/jfs/jfs_txnmgr.c:2732 kthread+0x2d3/0x370 kernel/kthread.c:388 ret_from_fork+0x48/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304 </TASK> 内核偏移：已禁用 86400 秒后重启… 如果 lp 的值大于 CLTREEESIZE（即 stree 的最大大小），则会导致此问题。添加一项简单的检查即可解决此问题。Dave：由于函数返回 void，如果要妥善处理错误，可能需要进行更激进的代码重组。由于缺少更明确的选项，所以我修改了目前所用的 Osama 补丁 WARN_ON_ONCE。补丁已经过 syzbot 测试。(CVE-2023-52604)

 - 在 Linux 内核中，以下漏洞已修复：ACPI：extlog：修复空指针取消引用检查 gcc 插件 -fanalyzer [1] 尝试检测各种错误行为模式。
 工具报告：drivers/acpi/acpi_extlog.c：在函数 extlog_exit 中：
 drivers/acpi/acpi_extlog.c:307:12：警告：取消引用 extlog_l1_addr 后检查其是否为空 [-Wanalyzer-deref-before-check] | | 306 | ((struct extlog_l1_head *)extlog_l1_addr)->flags &= ~FLAG_OS_OPTIN; | | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~ | | | | | (1) 指针 extlog_l1_addr' 在此处被取消引用 | 307 | if (extlog_l1_addr) | | ~ | | | | | (2) 在 (1) 中取消引用指针 extlog_l1_addr' 后，在此处检查其是否为空 | 修复 extlog_exit() 中的空指针取消引用检查。(CVE-2023-52605)

 - 在 Linux 内核中，以下漏洞已修复：powerpc/lib：验证矢量操作的大小 sstep.c 中的某些 fp/vmx 代码假设要模拟的指令有特定的最大大小。但是，这些操作的大小会在 analyse_instr() 中单独确定。添加一项检查以验证关于操作大小上限的假设，从而防止任何意外的内核堆栈损坏。(CVE-2023-52606)

 - 在 Linux 内核中，以下漏洞已修复：powerpc/mm：修复 pgtable_cache_add kasprintf() 中的空指针取消引用 kasprintf() 会向动态分配内存返回一个指针，此指针在发生故障时会变为空。通过检查指针有效性来确保分配成功。
 (CVE-2023-52607)

 - 作为 CVE-2023-33951 和 CVE-2023-33952 修复的一部分所作的引用计数更改在被用于存储表面时，暴露了内存对象处理方式存在释放后使用问题。在启用了 3D 加速的 VMware 客户机中运行时，无权限的本地用户可能会利用此缺陷来提升自身权限。(CVE-2023-5633)

 - 在 Linux 内核 fs/smb/client/smb2ops.c 的 smb2_dump_detail 中发现越界读取漏洞。利用此问题，本地攻击者可造成系统崩溃或泄露内核内部信息。
 (CVE-2023-6610)

 - 在 Linux 内核中，发现 drivers/vhost/vhost.c 的 vhost_new_msg 中存在漏洞，因未使用 vhost/vhost.c:vhost_new_msg() 函数将虚拟客户机和主机操作系统之间传递的消息中的内存正确初始化所致。利用此问题，在 /dev/vhost-net 设备文件中读取数据时，本地特权用户可以读取某些内核内存内容。(CVE-2024-0340)

 - Linux 内核 netfilter: nf_tables 组件中存在一个释放后使用漏洞，攻击者可利用此漏洞以实现本地特权提升。在释放 catch-all set 元素之前，nft_setelem_catchall_deactivate() 函数会检查其在当前生成中是否处于活动状态，而不是在新一代中仅将其标记为不活动，如此便可多次释放该元素，进而导致双重释放漏洞。我们升级过去的提交 b1db244ffd041a49ecc9618e8feb6b5c1afcdaa7。(CVE-2024-1085)

 - Linux 内核 netfilter: nf_tables 组件中存在一个释放后使用漏洞，攻击者可利用此漏洞以实现本地特权提升。nft_verdict_init() 函数允许在挂钩判定中将正值作为丢弃错误，因此，当 NF_DROP 发出类似于 NF_ACCEPT 的丢弃错误时，nf_hook_slow() 函数可造成双重释放漏洞。我们建议升级过去的提交 f342de4e2f33e0e39165d8639387aa6c19dff660。(CVE-2024-1086)

 - 在 6.7.1 及之前版本的 Linux 内核中，在 net/rds/af_rds.c 的 rds_recv_track_latency 中，RDS_MSG_RX_DGRAM_TRACE_MAX 比较中存在一个大小差一错误，会导致越界访问。(CVE-2024-23849)

 - 在 Linux 内核的蓝牙设备驱动程序的 {min,max}_key_size_set() 函数中发现争用条件漏洞。这可导致空指针取消引用问题，进而可能导致内核错误或拒绝服务问题。(CVE-2024-24860)

 - 在 Linux 内核中，以下漏洞已修复：netfilter：nft_set_rbtree：跳过 gc 中的结束间隔元素 插入时，rbtree lazy gc 可能会收集此事务中刚添加的结束间隔元素，跳过尚未生效的结束间隔元素。(CVE-2024-26581)

 - 在 Linux 内核中，已解决以下漏洞：LoongArch：BPF：防止越界内存访问 test_tag 测试会触发未处理的页面错误：# ./test_tag [ 130.640218] CPU 0 无法处理在虚拟地址 ffff80001b898004 提出的内核分页请求，era == 9000000003137f7c，ra == 9000000003139e70 [ 130.640501] Oops[#3]：[ 130.640553] CPU：0 PID：1326 命令：test_tag 已感染：G D O 6.7.0-rc4-loong-devel-gb62ab1a397cf #47 61985c1d94084daa2432f771daa45b56b10d8d2a [ 130.640764] 硬件名称：QEMU QEMU 虚拟机，BIOS 未知 2/2/2022 [ 130.640874] pc 9000000003137f7c ra 9000000003139e70 tp 9000000104cb4000 sp 9000000104cb7a40 [ 130.641001] a0 ffff80001b894000 a1 ffff80001b897ff8 a2 000000006ba210be a3 0000000000000000 [ 130.641128] a4 000000006ba210be a5 00000000000000f1 a6 00000000000000b3 a7 0000000000000000 [ 130.641256] t0 0000000000000000 t1 00000000000007f6 t2 0000000000000000 t3 9000000004091b70 [130.641387 ] t4 000000006ba210be t5 0000000000000004 t6 fffffffffffffff0 t7 90000000040913e0 [ 130.641512] t8 0000000000000005 u0 0000000000000dc0 s9 0000000000000009 s0 9000000104cb7ae0 [ 130.641641] s1 00000000000007f6 s2 0000000000000009 s3 0000000000000095 s4 0000000000000000 [ 130.641771] s5 ffff80001b894000 s6 ffff80001b897fb0 s7 9000000004090c50 s8 0000000000000000 [ 130.641900] ra: 9000000003139e70 build_body+0x1fcc/0x4988 [ 130.642007] ERA：9000000003137f7c build_body+0xd8/0x4988 [ 130.642112] CRMD：
 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) [ 130.642261] PRMD：00000004 (PPLV0 +PIE -PWE) [130.642353] EUEN：00000003 (+FPE +SXE -ASXE -BTE) [ 130.642458] ECFG：00071c1c（LIE=2-4、10-12 VS=7）[130.642554] ESTAT：00010000 [PIL] (IS= ECode=1 EsubCode=0) [ 130.642658] BADV：ffff80001b898004 [130.642719] PRID：0014c010（Loongson-64bit、Loongson-3A5000）[ 130.642815] 模块链接位置：[last unloaded: bpf_testmod(O)] [ 130.642924] 处理 test_tag（pid：1326、threadinfo=00000000f7f4015f、task=000000006499f9fd）[ 130.643062] 堆栈：0000000000000000 9000000003380724 0000000000000000 0000000104cb7be8 [ 130.643213] 0000000000000000 25af8d9b6e600558 9000000106250ea0 9000000104cb7ae0 [130.643378] 0000000000000000 0000000000000000 9000000104cb7be8 90000000049f6000 [ 130.643538] 0000000000000090 9000000106250ea0 ffff80001b894000 ffff80001b894000 [ 130.643685] 00007ffffb917790 900000000313ca94 0000000000000000 0000000000000000 [ 130.643831] ffff80001b894000 0000000000000ff7 0000000000000000 9000000100468000 [ 130.643983] 0000000000000000 0000000000000000 0000000000000040 25af8d9b6e600558 [ 130.644131] 0000000000000bb7 ffff80001b894048 0000000000000000 0000000000000000 [130.644276] 9000000104cb7be8 90000000049f6000 0000000000000090 9000000104cb7bdc [ 130.644423] ffff80001b894000 0000000000000000 00007ffffb917790 90000000032acfb0 [ 130.644572] ... [ 130.644629] 调用跟踪：[ 130.644641] [<9000000003137f7c>] build_body+0xd8/0x4988 [ 130.644785] [<900000000313ca94>] bpf_int_jit_compile+0x228/0x4ec [ 130.644891] [<90000000032acfb0>] bpf_prog_select_runtime+0x158/0x1b0 [130.645003] [<90000000032b3504>] bpf_prog_load+0x760/0xb44 [ 130.645089] [<90000000032b6744>]
 __sys_bpf+0xbb8/0x2588 [ 130.645175] [<90000000032b8388>] sys_bpf+0x20/0x2c [ 130.645259] [<9000000003f6ab38>] do_syscall+0x7c/0x94 [ 130.645369] [<9000000003121c5c>] handle_syscall+0xbc/0x158 [130.645507] [ 130.645539] 代码：380839f6 380831f9 28412bae <24000ca6> 004081ad 0014cb50 004083e8 02bff34c 58008e91 [ 130.645729] [ 130.646418] ---[结束跟踪 0000000000000000 ]--- 在我的计算机（含有 CONFIG_PAGE_SIZE_16KB=y）上，根据 2039 说明加载 BPF prog 的测试失败：prog = (struct bpf_prog *)ffff80001b894000 insn = (struct bpf_insn *)(prog->insnsi)fff ---truncated--- (CVE-2024-26588)

 - 在 Linux 内核中，以下漏洞已修复：bpf：拒绝 PTR_TO_FLOW_KEYS 上的变量偏移 alu 对于 PTR_TO_FLOW_KEYS，check_flow_keys_access() 仅使用修复的 off 进行验证。
 但是，未针对此 ptr 种类禁止变量偏移 ptr alu。因此系统不会检查变量偏移。已接受以下 prog：func#0 @0 0：R1=ctx() R10=fp0 0：(bf) r6 = r1 ; R1=ctx() R6_w=ctx() 1：(79) r7 = *(u64 *)(r6 +144) ; R6_w=ctx() R7_w=flow_keys() 2：(b7) r8 = 1024 ; R8_w=1024 3：
 (37) r8 /= 1 ; R8_w=scalar() 4：(57) r8 &= 1024 ; R8_w=scalar(smin=smin32=0, smax=umax=smax32=umax32=1024,var_off=(0x0; 0x400)) 5：(0f) r7 += r8 mark_precise: frame0: last_idx 5 first_idx 0 subseq_idx -1 mark_precise: frame0: regs=r8 stack= before 4：(57) r8 &= 1024 mark_precise:
 frame0: regs=r8 stack= before 3：(37) r8 /= 1 mark_precise: frame0: regs=r8 stack= before 2：(b7) r8 = 1024 6: R7_w=flow_keys(smin=smin32=0,smax=umax=smax32=umax32=1024,var_off =(0x0; 0x400)) R8_w=scalar(smin=smin32=0,smax=umax=smax32=umax32=1024, var_off=(0x0; 0x400)) 6：(79) r0 = *(u64 *)(r7 +0) ; R0_w=scalar() 7：(95) exit 此 prog 将 flow_keys 加载到 r7，并将变量偏移 r8 增加到 r7，最终导致越界访问：缺陷：无法处理地址页面错误：ffffc90014c80038 [...] 调用跟踪：<TASK> bpf_dispatcher_nop_func include/linux/bpf.h:1231 [inline] __bpf_prog_run include/linux/filter.h:651 [inline] bpf_prog_run include/linux/filter.h:658 [inline] bpf_prog_run_pin_on_cpu include/linux/filter.h:675 [inline] bpf_flow_dissect+0x15f/0x350 net/core/flow_dissector.c:991 bpf_prog_test_run_flow_dissector+0x39d/0x620 net/bpf/test_run.c:1359 bpf_prog_test_run kernel/bpf/syscall.c:4107 [inline] __sys_bpf+0xf8f/0x4560 kernel/bpf/syscall.c:5475
 __do_sys_bpf kernel/bpf/syscall.c:5561 [inline] __se_sys_bpf kernel/bpf/syscall.c:5559 [inline]
 __x64_sys_bpf+0x73/0xb0 kernel/bpf/syscall.c:5559 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x3f/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b 通过在 flow_keys 上拒绝使用变量偏移的 ptr alu 来修复此漏洞。应用补丁，拒绝运行“禁止在 flow_keys 上使用 R7 指针算法”的程序。(CVE-2024-26589)

 - 在 Linux 内核中，以下漏洞已修复：bpf：修复 bpf_tracing_prog_attach 中的重新附加分支 由于缺少 attach_btf，以下情况会造成崩溃：1) 加载 rawtp 程序 2) 加载将 rawtp 作为 target_fd 的 fentry 程序 3) 利用 target_fd = 0 为 fentry 程序创建跟踪链接 4) 重复 3 最后，我们有：- prog->aux->dst_trampoline == NULL - tgt_prog == NULL（因为我们没有为 link_create 提供 target_fd）- prog->aux->attach_btf == NULL（程序使用 attach_prog_fd=X 加载而来）- 已为 tgt_prog 加载程序，但我们无法找出具体是哪一个 缺陷：内核空指针取消引用，地址：0000000000000058 调用跟踪：<TASK> ? __die+0x20/0x70 ? page_fault_oops+0x15b/0x430 ? fixup_exception+0x22/0x330 ? exc_page_fault+0x6f/0x170 ? asm_exc_page_fault+0x22/0x30 ? bpf_tracing_prog_attach+0x279/0x560 ? btf_obj_id+0x5/0x10 bpf_tracing_prog_attach+0x439/0x560 __sys_bpf+0x1cf4/0x2de0 __x64_sys_bpf+0x1c/0x30 do_syscall_64+0x41/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0x76 在此情况下返回 -EINVAL。
 (CVE-2024-26591)

 - 在 Linux 内核中，以下漏洞已修复：ksmbd：修复 ksmbd_tcp_new_connection() 中的 UAF 问题 处理新的 TCP 连接与断开连接时发生争用情形。
 它会导致 ksmbd_tcp_new_connection() 函数中的“struct tcp_transport”发生 UAF。(CVE-2024-26592)

 - 在 Linux 内核中，以下漏洞已修复：ksmbd：验证会话设置中的 mech 标记 如果客户端在会话设置请求中发送无效的 mech 标记，ksmbd 会进行验证并在确定标记无效时生成错误。(CVE-2024-26594)

 - 在 Linux 内核中，以下漏洞已修复：net：qualcomm：rmnet：修复 rmnet_policy 中的全局 oob 变量 rmnet_link_ops 分配了*更大的*maxtype 漏洞，会其在解析 netlink 属性时导致发生全局越界读取。请参阅下面的缺陷跟踪：
 ================================================================== 缺陷：KASAN：validate_nla lib/nlattr.c:386 中存在 global-out-of-bounds [inline] 缺陷：KASAN：
 __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600 中存在 global-out-of-bounds 读取大小为 1 位置：addr ffffffff92c438d0 按任务 syz-executor.6/84207 CPU：0 PID：84207 命令：syz-executor.6 未感染：G N 6.1.0 #3 硬件名称：QEMU Standard PC（i440FX + PIIX，1996），BIOS 1.13.0-1ubuntu1.1 04/01/2014 调用跟踪：<TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x8b/0xb3 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:284 [inline] print_report+0x172/0x475 mm/kasan/report.c:395 kasan_report+0xbb/0x1c0 mm/kasan/report.c:495 validate_nla lib/nlattr.c:386 [inline] __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600 __nla_parse+0x3e/0x50 lib/nlattr.c:697 nla_parse_nested_deprecated include/net/netlink.h:1248 [inline] __rtnl_newlink+0x50a/0x1880 net/core/rtnetlink.c:3485 rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3594 rtnetlink_rcv_msg+0x43c/0xd70 net/core/rtnetlink.c:6091 netlink_rcv_skb+0x14f/0x410 net/netlink/af_netlink.c:2540 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] netlink_unicast+0x54e/0x800 net/netlink/af_netlink.c:1345 netlink_sendmsg+0x930/0xe50 net/netlink/af_netlink.c:1921 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg+0x154/0x190 net/socket.c:734 ____sys_sendmsg+0x6df/0x840 net/socket.c:2482
 ___sys_sendmsg+0x110/0x1b0 net/socket.c:2536 __sys_sendmsg+0xf3/0x1c0 net/socket.c:2565 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fdcf2072359 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP：002b:00007fdcf13e3168 EFLAGS：00000246 ORIG_RAX：000000000000002e RAX：ffffffffffffffda RBX：00007fdcf219ff80 RCX：00007fdcf2072359 RDX：
 0000000000000000 RSI：0000000020000200 RDI：0000000000000003 RBP：00007fdcf20bd493 R08：0000000000000000 R09：0000000000000000 R10：0000000000000000 R11：0000000000000246 R12：0000000000000000 R13：
 00007fffbb8d7bdf R14：00007fdcf13e3300 R15：0000000000022000 </TASK> 有缺陷的地址属于变量：rmnet_policy+0x30/0xe0 有缺陷的地址属于物理页：page:0000000065bdeb3c refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x155243 标记：
 0x200000000001000(reserved|node=0|zone=2) raw：0200000000001000 ffffea00055490c8 ffffea00055490c8 0000000000000000 raw：0000000000000000 0000000000000000 00000001ffffffff 0000000000000000 页面被弃用，因为：kasan：检测到不良访问 缺陷地址的内存状态：ffffffff92c43780：f9 f9 f9 f9 00 00 00 02 f9 f9 f9 f9 00 00 00 07 ffffffff92c43800：f9 f9 f9 f9 00 00 00 05 f9 f9 f9 f9 06 f9 f9 f9 >ffffffff92c43880：f9 f9 f9 f9 00 00 00 00 00 00 f9 f9 f9 f9 f9 f9 ^ ffffffff92c43900：00 00 00 00 00 00 00 00 07 f9 f9 f9 f9 f9 f9 f9 ffffffff92c43980：00 00 00 07 f9 f9 f9 f9 00 00 00 05 f9 f9 f9 f9 根据“nla_parse_nested_deprecated”的注释，maxtype 应为 len（目标数组）- 1. 因此在此处使用“IFLA_RMNET_MAX”。(CVE-2024-26597)

 - 在 Linux 内核中，以下漏洞已修复：KVM：arm64：vgic-its：避免 LPI 转换缓存中出现潜在 UAF，即如果 LPI 转换缓存与使缓存无效的操作（例如 DISCARD ITS 命令）之间存在争用，会出现潜在的 UAF。问题的根源在于 vgic_its_check_cache() 在删除可将引用计数变更序列化的锁定之前未提升 vgic_irq 上的引用计数。使 vgic_its_check_cache() 增加返回的 vgic_irq 的引用计数，并在将中断排入队列后添加相应的减少量。(CVE-2024-26598)

 - 在 Linux 内核中，以下漏洞已修复：pwm：修复 of_pwm_single_xlate() 中因 args->args_count == 2 args->args[2] 未定义而引起的越界访问。实际上，标记包含在 args->args[1] 中。(CVE-2024-26599)

 - 在 Linux 内核中，以下漏洞已修复：phy：ti：phy-omap-usb2：修复 SRP 的空指针取消引用 如果与 phy-omap-usb2 结合使用的外部 phy 未实施 send_srp()，我们可能仍会尝试进行调用。这种情况可能发生在空闲的以太网小工具触发唤醒时，例如：configfs-gadget.g1 gadget.0：ECM 暂停 configfs-gadget.g1 gadget.0：端口已暂停。
 正在触发唤醒… 执行…时，无法处理虚拟地址 00000000 处发生的内核空指针取消引用PC 位于 0x0 LR 位于 musb_gadget_wakeup+0x1d4/0x254 [musb_hdrc] ... musb_gadget_wakeup [musb_hdrc] from usb_gadget_wakeup+0x1c/0x3c [udc_core] usb_gadget_wakeup [udc_core] from eth_start_xmit+0x3b0/0x3d4 [u_ether] eth_start_xmit [u_ether] from dev_hard_start_xmit+0x94/0x24c dev_hard_start_xmit from sch_direct_xmit+0x104/0x2e4 sch_direct_xmit from __dev_queue_xmit+0x334/0xd88
 __dev_queue_xmit from arp_solicit+0xf0/0x268 arp_solicit from neigh_probe+0x54/0x7c neigh_probe from
 __neigh_event_send+0x22c/0x47c __neigh_event_send from neigh_resolve_output+0x14c/0x1c0 neigh_resolve_output from ip_finish_output2+0x1c8/0x628 ip_finish_output2 from ip_send_skb+0x40/0xd8 ip_send_skb from udp_send_skb+0x124/0x340 udp_send_skb from udp_sendmsg+0x780/0x984 udp_sendmsg from
 __sys_sendto+0xd8/0x158 __sys_sendto from ret_fast_syscall+0x0/0x58 要解决此问题，我们可以检查 send_srp() 和 set_vbus() 之后再进行调用。对于只有 USB 外设的情况，这两项都可以为空。
 (CVE-2024-26600)

 - 在 Linux 内核中，以下漏洞已修复：ext4：在 fc 重播的情况下，系统会在区块释放失败后重新生成 buddy 这主要会导致恢复提交 6bd97bf273bd（ext4：移除多余的 mb_regenerate_buddy()）并重新引入 mb_regenerate_buddy()。根据 mb_free_blocks() 中的代码，快速提交重播最终会导致区块重复被标记为已释放。这会造成 buddy 位图损坏，因此在这种情况下我们需要重新生成位图。(CVE-2024-26601)

 - 在 Linux 内核中，以下漏洞已修复：af_unix：修复 sk_diag_dump_icons() 中的 lockdep 误报 syzbot 报告了 lockdep 崩溃 [1]。Blamed 提交暗示了可能的 lockdep 违规，且代码使用了 unix_state_lock_nested() 来尝试静默 lockdep。这还不够，因为已使用 unix_state_double_lock() 中的 unix_state_lock_nested()。我们需要使用单独的子类。此补丁添加了不同的枚举来使内容更明确，也可以使用 unix_state_double_lock() 中的 swap() 进行清除。v2：向 unix_state_lock_nested() 添加缺少的内联关键字 [1] 警告：检测到可能存在循环锁定依存关系 6.8.0-rc1-syzkaller-00356-g8a696a29c690 #0 未感染 syz-executor.1/2542 正在尝试获取锁定：ffff88808b5df9e8 (rlock-AF_UNIX){+.+.}-{2:2}，位置：
 skb_queue_tail+0x36/0x120 net/core/skbuff.c:3863 但任务正在保持锁定：ffff88808b5dfe70 (&u->lock/1){+.+.}-{2:2}，位置：unix_dgram_sendmsg+0xfc7/0x2200 net/unix/af_unix.c:2089 哪项锁定依赖于新的锁定。现有的依存关系链（倒序）为：-> #1 (&u->lock/1){+.+.}-{2:2}：lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754
 _raw_spin_lock_nested+0x31/0x40 kernel/locking/spinlock.c:378 sk_diag_dump_icons net/unix/diag.c:87 [inline] sk_diag_fill+0x6ea/0xfe0 net/unix/diag.c:157 sk_diag_dump net/unix/diag.c:196 [inline] unix_diag_dump+0x3e9/0x630 net/unix/diag.c:220 netlink_dump+0x5c1/0xcd0 net/netlink/af_netlink.c:2264
 __netlink_dump_start+0x5d7/0x780 net/netlink/af_netlink.c:2370 netlink_dump_start include/linux/netlink.h:338 [inline] unix_diag_handler_dump+0x1c3/0x8f0 net/unix/diag.c:319 sock_diag_rcv_msg+0xe3/0x400 netlink_rcv_skb+0x1df/0x430 net/netlink/af_netlink.c:2543 sock_diag_rcv+0x2a/0x40 net/core/sock_diag.c:280 netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x7e6/0x980 net/netlink/af_netlink.c:1367 netlink_sendmsg+0xa37/0xd70 net/netlink/af_netlink.c:1908 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] sock_write_iter+0x39a/0x520 net/socket.c:1160 call_write_iter include/linux/fs.h:2085 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0xa74/0xca0 fs/read_write.c:590 ksys_write+0x1a0/0x2c0 fs/read_write.c:643 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b -> #0 (rlock-AF_UNIX){+.+.}-{2:2}：check_prev_add kernel/locking/lockdep.c:3134 [inline] check_prevs_add kernel/locking/lockdep.c:3253 [inline] validate_chain+0x1909/0x5ab0 kernel/locking/lockdep.c:3869
 __lock_acquire+0x1345/0x1fd0 kernel/locking/lockdep.c:5137 lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
 _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162 skb_queue_tail+0x36/0x120 net/core/skbuff.c:3863 unix_dgram_sendmsg+0x15d9/0x2200 net/unix/af_unix.c:2112 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] ____sys_sendmsg+0x592/0x890 net/socket.c:2584 ___sys_sendmsg net/socket.c:2638 [inline] __sys_sendmmsg+0x3b2/0x730 net/socket.c:2724
 __do_sys_sendmmsg net/socket.c:2753 [inline] __se_sys_sendmmsg net/socket.c:2750 [inline]
 __x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2750 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b 可能有助于我们调试此问题的其他信息：可能不安全的锁定情况：CPU0 ---truncated--- (CVE-2024-26624)

 - 在 Linux 内核中，以下漏洞已修复：llc：在发布时调用 sock_orphan() syzbot 报告了一個相關追蹤 [1]，由已关闭的 llc 套接字中过时的 sk->sk_wq 指针造成。
 在提交 ff7b11aa481f（net：socket：调用 proto_ops::release() 后，将 sock->sk 设置为空）中，Eric Biggers 提示某些协议缺少 sock_orphan()，因此我们需要执行完整审计。在 net-next 中，我计划从 sock_orphan() 清除 sock->sk 并修正 Eric 补丁以添加警告。[1] 缺陷：KASAN：
 list_empty 中的 slab-use-after-free，include/linux/list.h:373 [inline] 缺陷：KASAN：waitqueue_active 中的 slab-use-after-free，include/linux/wait.h:127 [inline] 缺陷：KASAN：sock_def_write_space_wfree 中的 slab-use-after-free，net/core/sock.c:3384 [inline] 缺陷：KASAN：sock_wfree+0x9a8/0x9d0 中的 slab-use-after-free，net/core/sock.c:2468 读取大小为 8 位置：addr ffff88802f4fc880 按任务 ksoftirqd/1/27 CPU：1 PID：27 命令：ksoftirqd/1 未感染 6.8.0-rc1-syzkaller-00049-g6098d87eaf31 #0 硬件名称：
 QEMU Standard PC（Q35 + ICH9，2009），BIOS 1.16.2-debian-1.16.2-1 04/01/2014 调用跟踪：<TASK>
 __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc4/0x620 mm/kasan/report.c:488 kasan_report+0xda/0x110 mm/kasan/report.c:601 list_empty include/linux/list.h:373 [inline] waitqueue_active include/linux/wait.h:127 [inline] sock_def_write_space_wfree net/core/sock.c:3384 [inline] sock_wfree+0x9a8/0x9d0 net/core/sock.c:2468 skb_release_head_state+0xa3/0x2b0 net/core/skbuff.c:1080 skb_release_all net/core/skbuff.c:1092 [inline] napi_consume_skb+0x119/0x2b0 net/core/skbuff.c:1404 e1000_unmap_and_free_tx_resource+0x144/0x200 drivers/net/ethernet/intel/e1000/e1000_main.c:1970 e1000_clean_tx_irq drivers/net/ethernet/intel/e1000/e1000_main.c:3860 [inline] e1000_clean+0x4a1/0x26e0 drivers/net/ethernet/intel/e1000/e1000_main.c:3801 __napi_poll.constprop.0+0xb4/0x540 net/core/dev.c:6576 napi_poll net/core/dev.c:6645 [inline] net_rx_action+0x956/0xe90 net/core/dev.c:6778
 __do_softirq+0x21a/0x8de kernel/softirq.c:553 run_ksoftirqd kernel/softirq.c:921 [inline] run_ksoftirqd+0x31/0x60 kernel/softirq.c:913 smpboot_thread_fn+0x660/0xa10 kernel/smpboot.c:164 kthread+0x2c6/0x3a0 kernel/kthread.c:388 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:242 </TASK> 由任务 5167 分配：
 kasan_save_stack+0x33/0x50 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:314 [inline] __kasan_slab_alloc+0x81/0x90 mm/kasan/common.c:340 kasan_slab_alloc include/linux/kasan.h:201 [inline] slab_post_alloc_hook mm/slub.c:3813 [inline] slab_alloc_node mm/slub.c:3860 [inline] kmem_cache_alloc_lru+0x142/0x6f0 mm/slub.c:3879 alloc_inode_sb include/linux/fs.h:3019 [inline] sock_alloc_inode+0x25/0x1c0 net/socket.c:308 alloc_inode+0x5d/0x220 fs/inode.c:260 new_inode_pseudo+0x16/0x80 fs/inode.c:1005 sock_alloc+0x40/0x270 net/socket.c:634
 __sock_create+0xbc/0x800 net/socket.c:1535 sock_create net/socket.c:1622 [inline] __sys_socket_create net/socket.c:1659 [inline] __sys_socket+0x14c/0x260 net/socket.c:1706 __do_sys_socket net/socket.c:1720 [inline] __se_sys_socket net/socket.c:1718 [inline] __x64_sys_socket+0x72/0xb0 net/socket.c:1718 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd3/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b 由任务 0 释放：kasan_save_stack+0x33/0x50 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640 poison_slab_object mm/kasan/common.c:241 [inline] __kasan_slab_free+0x121/0x1b0 mm/kasan/common.c:257 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2121 [inlin ---truncated--- (CVE-2024-26625)

 - 在 Linux 内核中，以下漏洞已修复：scsi：核心：为 scsi_host_busy() 移出主机锁定，以唤醒 EH 处理程序 在 scsi_eh_wakeup() 中，每次都会调用 scsi_host_busy() 并检查主机锁定，以决定是否需要唤醒错误处理程序 kthread。在恢复的情况下，负载可能过重，例如：- N 个硬件队列 - 每个硬件队列的队列深度为 M - 每个 scsi_host_busy() 迭代 (N * M) 个标签/请求 触发恢复需满足以下条件：所有请求都正在进行中，每个 scsi_eh_wakeup() 都经过严格的序列化，已为最后一个进行中的请求调用 scsi_eh_wakeup()，scsi_host_busy() 已运行 (N * M - 1) 次，请求已迭代 (N*M - 1) * (N * M) 次。如果 N 和 M 都足够大，则可在获取主机锁时触发硬锁定，并且可在 mpi3mr（128 hw 队列，队列深度 8169）上观察到。通过在主机锁定外调用 scsi_host_busy() 解决此问题。我们不需要通过主机锁定获取 busy 计数，因为这绝非主机锁定的功能。[mkp：删除 Bart 指出的非必要“busy”变量] (CVE-2024-26627)

 - 在 Linux 内核中，以下漏洞已修复：drm/amdkfd：修复锁定依存关系警告 ====================================================== 警告：检测到可能的循环锁定依存关系 6.5.0-kfd-fkuehlin #276 未感染
 ------------------------------------------------------ kworker/8:2/2676 正在尝试获取锁定：
 ffff9435aae95c88 ((work_completion)(&svm_bo->eviction_work)){+.+.}-{0:0}，位置：__flush_work+0x52/0x550 但任务正在保持锁定：ffff9435cd8e1720 (&svms->lock){+.+.}-{3:3}，位置：
 svm_range_deferred_list_work+0xe8/0x340 [amdgpu] 哪项锁定依赖于新的锁定。现有依存关系链（倒序）为：-> #2 (&svms->lock){+.+.}-{3:3}：__mutex_lock+0x97/0xd30 kfd_ioctl_alloc_memory_of_gpu+0x6d/0x3c0 [amdgpu] kfd_ioctl+0x1b2/0x5d0 [amdgpu] __x64_sys_ioctl+0x86/0xc0 do_syscall_64+0x39/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd -> #1 (&mm->mmap_lock){++++}-{3:3}：
 down_read+0x42/0x160 svm_range_evict_svm_bo_worker+0x8b/0x340 [amdgpu] process_one_work+0x27a/0x540 worker_thread+0x53/0x3e0 kthread+0xeb/0x120 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x11/0x20 -> #0 ((work_completion)(&svm_bo->eviction_work)){+.+.}-{0:0}：__lock_acquire+0x1426/0x2200 lock_acquire+0xc1/0x2b0 __flush_work+0x80/0x550 __cancel_work_timer+0x109/0x190 svm_range_bo_release+0xdc/0x1c0 [amdgpu] svm_range_free+0x175/0x180 [amdgpu] svm_range_deferred_list_work+0x15d/0x340 [amdgpu] process_one_work+0x27a/0x540 worker_thread+0x53/0x3e0 kthread+0xeb/0x120 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x11/0x20 可能有助于我们调试此问题的其他信息：链存在于：(work_completion)(&svm_bo->eviction_work) --> &mm->mmap_lock --> &svms->lock 可能不安全的锁定情况：CPU0 CPU1 ---- ---- lock(&svms->lock); lock(&mm->mmap_lock);
 lock(&svms->lock); lock((work_completion)(&svm_bo->eviction_work)); 我认为这实际上不会导致死锁，因为 svm_range_evict_svm_bo_worker 只有在 BO refcount 为非 0 时才仅会采用 mmap_read_lock。这意味着 svm_range_bo_release 不可能同时运行。但是，没有好的方法对此进行注解。为避免此问题，请在 svm_range_schedule_evict_svm_bo 而非工作线程中采用 BO 引用。这样，如果逐出工作搁置，BO 便无法被释放，并且 svm_range_bo_release 中的 cancel_work_sync 调用可以被消除。
 v2：使用 svm_bo_ref_unless_zero，并说明它为什么安全。还删除了已在 amdkfd_fence_enable_signaling 中完成的冗余检查。(CVE-2024-26628)

请注意，Nessus 尚未测试这些问题，而是只依靠应用程序自我报告的版本号来判断。

解决方案

更新受影响的 kernel 程序包。

另见

https://ubuntu.com/security/notices/USN-6688-1

插件详情

严重性: High

ID: 191796

文件名: ubuntu_USN-6688-1.nasl

版本: 1.3

类型: local

代理: unix

发布时间: 2024/3/11

最近更新时间: 2024/4/18

支持的传感器: Frictionless Assessment AWS, Frictionless Assessment Azure, Frictionless Assessment Agent, Nessus Agent, Agentless Assessment, Nessus

风险信息

VPR

风险因素: Critical

分数: 9.6

CVSS v2

风险因素: Medium

基本分数: 6.8

时间分数: 5.9

矢量: CVSS2#AV:L/AC:L/Au:S/C:C/I:C/A:C

CVSS 分数来源: CVE-2024-26599

CVSS v3

风险因素: High

基本分数: 7.8

时间分数: 7.5

矢量: CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

时间矢量: CVSS:3.0/E:H/RL:O/RC:C

漏洞信息

CPE: cpe:/o:canonical:ubuntu_linux:22.04:-:lts, p-cpe:/a:canonical:ubuntu_linux:linux-image-6.1.0-1035-oem

必需的 KB 项: Host/cpu, Host/Debian/dpkg-l, Host/Ubuntu, Host/Ubuntu/release

可利用: true

易利用性: Exploits are available

补丁发布日期: 2024/3/11

漏洞发布日期: 2023/10/23

参考资料信息

CVE: CVE-2023-46838, CVE-2023-50431, CVE-2023-52436, CVE-2023-52438, CVE-2023-52439, CVE-2023-52443, CVE-2023-52444, CVE-2023-52445, CVE-2023-52447, CVE-2023-52448, CVE-2023-52449, CVE-2023-52451, CVE-2023-52454, CVE-2023-52456, CVE-2023-52457, CVE-2023-52458, CVE-2023-52462, CVE-2023-52463, CVE-2023-52464, CVE-2023-52467, CVE-2023-52469, CVE-2023-52470, CVE-2023-52583, CVE-2023-52584, CVE-2023-52587, CVE-2023-52588, CVE-2023-52589, CVE-2023-52593, CVE-2023-52594, CVE-2023-52595, CVE-2023-52597, CVE-2023-52598, CVE-2023-52599, CVE-2023-52600, CVE-2023-52601, CVE-2023-52602, CVE-2023-52603, CVE-2023-52604, CVE-2023-52605, CVE-2023-52606, CVE-2023-52607, CVE-2023-5633, CVE-2023-6610, CVE-2024-0340, CVE-2024-1085, CVE-2024-1086, CVE-2024-23849, CVE-2024-24860, CVE-2024-26581, CVE-2024-26588, CVE-2024-26589, CVE-2024-26591, CVE-2024-26592, CVE-2024-26594, CVE-2024-26597, CVE-2024-26598, CVE-2024-26599, CVE-2024-26600, CVE-2024-26601, CVE-2024-26624, CVE-2024-26625, CVE-2024-26627, CVE-2024-26628

USN: 6688-1