远程 CentOS Linux 9 主机上安装的程序包受到 libxml2-2.9.13-10.el9 版本变更日志中提及的多个漏洞的影响。

  - 在 libxml2 中发现一个漏洞。处理输入 XML 文件中的某些 sch:name 元素会触发内存损坏问题。此缺陷允许攻击者构建可导致 libxml 崩溃的恶意 XML 输入文件从而导致拒绝服务或其他可能因内存中损坏的敏感数据而导致的未定义行为。 (CVE-2025-49796)

  - 在 libxml2 中发现一个释放后使用漏洞。当 XML schematron 有<sch:name path=.../>方案元素。此缺陷允许恶意执行者构建用作 libxml 输入的恶意 XML 文档从而导致使用 libxml 的程序崩溃或其他可能的未定义行为。 (CVE-2025-49794)

  - 在 libxml2 的 xmlBuildQName 函数中发现一个缺陷其中缓冲区大小计算中的整数溢出可导致基于堆栈的缓冲区溢出。在处理构建的输入时，此问题可导致内存损坏或拒绝服务。(CVE-2025-6021)

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

远程 CentOS Linux 9 主机上存在安装的程序包该程序包受到 kernel-5.14.0-598.el9 版本变更日志中提及的多个漏洞的影响。

  - 已修复 Linux 内核中的下列漏洞：udf: Fix a slab-out-of-bounds write bug in udf_find_entry() Syzbot reported a slab-out-of-bounds Write bug: loop0: detected capacity change from 0 to 2048 ================================================================== BUG: KASAN: slab-out-of-bounds in udf_find_entry+0x8a5/0x14f0 fs/udf/namei.c:253 Write of size 105 at addr ffff8880123ff896 by task syz-executor323/3610 CPU: 0 PID: 3610 Comm: syz-executor323 Not tainted 6.1.0-rc2-syzkaller-00105-gb229b6ca5abb #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 10/11/2022 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106 print_address_description+0x74/0x340 mm/kasan/report.c:284 print_report+0x107/0x1f0 mm/kasan/report.c:395 kasan_report+0xcd/0x100 mm/kasan/report.c:495 kasan_check_range+0x2a7/0x2e0 mm/kasan/generic.c:189 memcpy+0x3c/0x60 mm/kasan/shadow.c:66 udf_find_entry+0x8a5/0x14f0 fs/udf/namei.c:253 udf_lookup+0xef/0x340 fs/udf/namei.c:309 lookup_open fs/namei.c:3391 [inline] open_last_lookups fs/namei.c:3481 [inline] path_openat+0x10e6/0x2df0 fs/namei.c:3710 do_filp_open+0x264/0x4f0 fs/namei.c:3740 do_sys_openat2+0x124/0x4e0 fs/open.c:1310 do_sys_open fs/open.c:1326 [inline] __do_sys_creat fs/open.c:1402 [inline] __se_sys_creat fs/open.c:1396 [inline] __x64_sys_creat+0x11f/0x160 fs/open.c:1396 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:0x7ffab0d164d9 Code: 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:00007ffe1a7e6bb8 EFLAGS: 00000246 ORIG_RAX: 0000000000000055 RAX: ffffffffffffffda RBX:
    0000000000000000 RCX: 00007ffab0d164d9 RDX: 00007ffab0d164d9 RSI: 0000000000000000 RDI: 0000000020000180 RBP: 00007ffab0cd5a10 R08: 0000000000000000 R09: 0000000000000000 R10: 00005555573552c0 R11:
    0000000000000246 R12: 00007ffab0cd5aa0 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 </TASK> Allocated by task 3610: kasan_save_stack mm/kasan/common.c:45 [inline] kasan_set_track+0x3d/0x60 mm/kasan/common.c:52 ____kasan_kmalloc mm/kasan/common.c:371 [inline] __kasan_kmalloc+0x97/0xb0 mm/kasan/common.c:380 kmalloc include/linux/slab.h:576 [inline] udf_find_entry+0x7b6/0x14f0 fs/udf/namei.c:243 udf_lookup+0xef/0x340 fs/udf/namei.c:309 lookup_open fs/namei.c:3391 [inline] open_last_lookups fs/namei.c:3481 [inline] path_openat+0x10e6/0x2df0 fs/namei.c:3710 do_filp_open+0x264/0x4f0 fs/namei.c:3740 do_sys_openat2+0x124/0x4e0 fs/open.c:1310 do_sys_open fs/open.c:1326 [inline] __do_sys_creat fs/open.c:1402 [inline] __se_sys_creat fs/open.c:1396 [inline]
    __x64_sys_creat+0x11f/0x160 fs/open.c:1396 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 The buggy address belongs to the object at ffff8880123ff800 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 150 bytes inside of 256-byte region [ffff8880123ff800, ffff8880123ff900) The buggy address belongs to the physical page: page:ffffea000048ff80 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x123fe head:ffffea000048ff80 order:1 compound_mapcount:0 compound_pincount:0 flags: 0xfff00000010200(slab|head|node=0|zone=1|lastcpupid=0x7ff) raw:
    00fff00000010200 ffffea00004b8500 dead000000000003 ffff888012041b40 raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected page_owner tracks the page as allocated page last allocated via order 0, migratetype Unmovable, gfp_mask 0x0(), pid 1, tgid 1 (swapper/0), ts 1841222404, free_ts 0 create_dummy_stack mm/page_owner.c: ---truncated--- (CVE-2022-49846)

  - 已修复 Linux 内核中的下列漏洞：bpf: Fix deadlock when freeing cgroup storage The following commit bc235cdb423a (bpf: Prevent deadlock from recursive bpf_task_storage_[get|delete]) first introduced deadlock prevention for fentry/fexit programs attaching on bpf_task_storage helpers. That commit also employed the logic in map free path in its v6 version. Later bpf_cgrp_storage was first introduced in c4bcfb38a95e (bpf: Implement cgroup storage available to non-cgroup-attached bpf progs) which faces the same issue as bpf_task_storage, instead of its busy counter, NULL was passed to bpf_local_storage_map_free() which opened a window to cause deadlock: <TASK> (acquiring local_storage->lock) _raw_spin_lock_irqsave+0x3d/0x50 bpf_local_storage_update+0xd1/0x460 bpf_cgrp_storage_get+0x109/0x130 bpf_prog_a4d4a370ba857314_cgrp_ptr+0x139/0x170 ?
    __bpf_prog_enter_recur+0x16/0x80 bpf_trampoline_6442485186+0x43/0xa4 cgroup_storage_ptr+0x9/0x20 (holding local_storage->lock) bpf_selem_unlink_storage_nolock.constprop.0+0x135/0x160 bpf_selem_unlink_storage+0x6f/0x110 bpf_local_storage_map_free+0xa2/0x110 bpf_map_free_deferred+0x5b/0x90 process_one_work+0x17c/0x390 worker_thread+0x251/0x360 kthread+0xd2/0x100 ret_from_fork+0x34/0x50 ret_from_fork_asm+0x1a/0x30 </TASK> Progs: - A: SEC(fentry/cgroup_storage_ptr) - cgid (BPF_MAP_TYPE_HASH) Record the id of the cgroup the current task belonging to in this hash map, using the address of the cgroup as the map key. - cgrpa (BPF_MAP_TYPE_CGRP_STORAGE) If current task is a kworker, lookup the above hash map using function parameter @owner as the key to get its corresponding cgroup id which is then used to get a trusted pointer to the cgroup through bpf_cgroup_from_id(). This trusted pointer can then be passed to bpf_cgrp_storage_get() to finally trigger the deadlock issue. - B:
    SEC(tp_btf/sys_enter) - cgrpb (BPF_MAP_TYPE_CGRP_STORAGE) The only purpose of this prog is to fill Prog A's hash map by calling bpf_cgrp_storage_get() for as many userspace tasks as possible. Steps to reproduce: - Run A; - while (true) { Run B; Destroy B; } Fix this issue by passing its busy counter to the free procedure so it can be properly incremented before storage/smap locking. (CVE-2024-58088)

  - 已修复 Linux 内核中的下列漏洞：mm: zswap: properly synchronize freeing resources during CPU hotunplug In zswap_compress() and zswap_decompress(), the per-CPU acomp_ctx of the current CPU at the beginning of the operation is retrieved and used throughout. However, since neither preemption nor migration are disabled, it is possible that the operation continues on a different CPU. If the original CPU is hotunplugged while the acomp_ctx is still in use, we run into a UAF bug as some of the resources attached to the acomp_ctx are freed during hotunplug in zswap_cpu_comp_dead() (i.e.
    acomp_ctx.buffer, acomp_ctx.req, or acomp_ctx.acomp). The problem was introduced in commit 1ec3b5fe6eec (mm/zswap: move to use crypto_acomp API for hardware acceleration) when the switch to the crypto_acomp API was made. Prior to that, the per-CPU crypto_comp was retrieved using get_cpu_ptr() which disables preemption and makes sure the CPU cannot go away from under us. Preemption cannot be disabled with the crypto_acomp API as a sleepable context is needed. Use the acomp_ctx.mutex to synchronize CPU hotplug callbacks allocating and freeing resources with compression/decompression paths. Make sure that acomp_ctx.req is NULL when the resources are freed. In the compression/decompression paths, check if acomp_ctx.req is NULL after acquiring the mutex (meaning the CPU was offlined) and retry on the new CPU.
    The initialization of acomp_ctx.mutex is moved from the CPU hotplug callback to the pool initialization where it belongs (where the mutex is allocated). In addition to adding clarity, this makes sure that CPU hotplug cannot reinitialize a mutex that is already locked by compression/decompression. Previously a fix was attempted by holding cpus_read_lock() [1]. This would have caused a potential deadlock as it is possible for code already holding the lock to fall into reclaim and enter zswap (causing a deadlock). A fix was also attempted using SRCU for synchronization, but Johannes pointed out that synchronize_srcu() cannot be used in CPU hotplug notifiers [2]. Alternative fixes that were considered/attempted and could have worked: - Refcounting the per-CPU acomp_ctx. This involves complexity in handling the race between the refcount dropping to zero in zswap_[de]compress() and the refcount being re-initialized when the CPU is onlined. - Disabling migration before getting the per-CPU acomp_ctx [3], but that's discouraged and is a much bigger hammer than needed, and could result in subtle performance issues.
    [1]https://lkml.kernel.org/20241219212437.2714151-1-yosryahmed@google.com/[2]https://lkml.kernel.org/20250107074724.1756696-2-yosryahmed@google.com/[3]https://lkml.kernel.org/20250107222236.2715883-2-yosryahmed@google.com/ [yosryahmed@google.com: remove comment] (CVE-2025-21693)

  - 已修复 Linux 内核中的下列漏洞：bpf: Send signals asynchronously if !preemptible BPF programs can execute in all kinds of contexts and when a program running in a non-preemptible context uses the bpf_send_signal() kfunc, it will cause issues because this kfunc can sleep.
    Change `irqs_disabled()` to `!preemptible()`. (CVE-2025-21728)

  - 已修复 Linux 内核中的下列漏洞：ipv6: mcast: extend RCU protection in igmp6_send() igmp6_send() can be called without RTNL or RCU being held. Extend RCU protection so that we can safely fetch the net pointer and avoid a potential UAF. Note that we no longer can use sock_alloc_send_skb() because ipv6.igmp_sk uses GFP_KERNEL allocations which can sleep. Instead use alloc_skb() and charge the net->ipv6.igmp_sk socket under RCU protection. (CVE-2025-21759)

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

远程 CentOS Linux 9 主机上安装的程序包受到 bzip2-1.0.8-10.el9 版本变更日志中提及的漏洞影响。

  - 在 bzip2 1.0.6 及之前版本中的 decompress.c 中，BZ2_decompress 会在存在多个选择器时出现越界写入。(CVE-2019-12900)

请注意，Nessus 尚未测试此问题，而是只依据应用程序自我报告的版本号进行判断。

远程 CentOS Linux 9 主机上安装的多个程序包受到 ncurses-6.2-12.20210508.el9 版本变更日志中提及的多个漏洞影响。

  - 6.4 20230408 之前的 ncurses，当由 setuid 应用程序使用时，允许本地用户通过在 $HOME/.terminfo 中找到或通过 TERMINFO 或 TERM 环境变量获取的 terminfo 数据库文件中的畸形数据触发与安全相关的内存损坏。(CVE-2023-29491)

  - 在修补程序 20220416 之前的 ncurses 6.3 中，terminfo 库中 tinfo/read_entry.c 的 convert_strings 中存在越界读取和分段冲突问题。(CVE-2022-29458)

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

远程 CentOS Linux 9 主机上安装的多个程序包受到 libarchive-3.5.3-5.el9 版本变更日志中提及的一个漏洞影响。

  - 在 libarchive 3.7.7 以及更早版本中，tar/util.c 的 list_item_verbose 未检查 strftime 返回值，攻击者可通过特制的 TAR 存档（以 verbose 值为 2 进行读取）造成拒绝服务或其他不明影响。例如，100 字节缓冲区对于自定义区域设置可能不足。
    (CVE-2025-25724)

请注意，Nessus 尚未测试此问题，而是只依据应用程序自我报告的版本号进行判断。

远程 CentOS Linux 9 主机上安装的多个程序包受到 kernel-5.14.0-587.el9 版本变更日志中提及的多个漏洞影响。

  - 已修复 Linux 内核中的下列漏洞：io_uring: prevent opcode speculation sqe->opcode is used for different tables, make sure we santitise it against speculations. (CVE-2025-21863)

  - 当用户调用第一个 gru_file_unlocked_ioctl 函数时，在 Linux 内核的 SGI GRU 驱动程序中发现一个释放后使用缺陷，其中 gru_check_chiplet_assignment 函数发生故障传递。本地用户可利用此缺陷导致系统崩溃或可能升级其系统权限。(CVE-2022-3424)

  - 已修复 Linux 内核中的下列漏洞：tracing/histograms: Fix memory leak problem This reverts commit 46bbe5c671e06f070428b9be142cc4ee5cedebac. As commit 46bbe5c671e0 (tracing:
    fix double free) said, the double free problem reported by clang static analyzer is: > In parse_var_defs() if there is a problem allocating > var_defs.expr, the earlier var_defs.name is freed. > This free is duplicated by free_var_defs() which frees > the rest of the list. However, if there is a problem allocating N-th var_defs.expr: + in parse_var_defs(), the freed 'earlier var_defs.name' is actually the N-th var_defs.name; + then in free_var_defs(), the names from 0th to (N-1)-th are freed; IF ALLOCATING PROBLEM HAPPENED HERE!!! -+ \ | 0th 1th (N-1)-th N-th V +-------------+-------------+-----+-------------+----------- var_defs: | name | expr | name | expr | ... | name | expr | name | /// +-------------+-------------+-----+-------------+----------- These two frees don't act on same name, so there was no double free problem before. Conversely, after that commit, we get a memory leak problem because the above N-th var_defs.name is not freed. If enable CONFIG_DEBUG_KMEMLEAK and inject a fault at where the N-th var_defs.expr allocated, then execute on shell like: $ echo 'hist:key=call_site:val=$v1,$v2:v1=bytes_req,v2=bytes_alloc' > \ /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger Then kmemleak reports: unreferenced object 0xffff8fb100ef3518 (size 8): comm bash, pid 196, jiffies 4295681690 (age 28.538s) hex dump (first 8 bytes): 76 31 00 00 b1 8f ff ff v1...... backtrace: [<0000000038fe4895>] kstrdup+0x2d/0x60 [<00000000c99c049a>] event_hist_trigger_parse+0x206f/0x20e0 [<00000000ae70d2cc>] trigger_process_regex+0xc0/0x110 [<0000000066737a4c>] event_trigger_write+0x75/0xd0 [<000000007341e40c>] vfs_write+0xbb/0x2a0 [<0000000087fde4c2>] ksys_write+0x59/0xd0 [<00000000581e9cdf>] do_syscall_64+0x3a/0x80 [<00000000cf3b065c>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 (CVE-2022-49648)

  - 已修复 Linux 内核中的下列漏洞：security/keys: fix slab-out-of-bounds in key_task_permission KASAN reports an out of bounds read: BUG: KASAN: slab-out-of-bounds in __kuid_val include/linux/uidgid.h:36 BUG: KASAN: slab-out-of-bounds in uid_eq include/linux/uidgid.h:63 [inline] BUG:
    KASAN: slab-out-of-bounds in key_task_permission+0x394/0x410 security/keys/permission.c:54 Read of size 4 at addr ffff88813c3ab618 by task stress-ng/4362 CPU: 2 PID: 4362 Comm: stress-ng Not tainted 5.10.0-14930-gafbffd6c3ede #15 Call Trace: __dump_stack lib/dump_stack.c:82 [inline] dump_stack+0x107/0x167 lib/dump_stack.c:123 print_address_description.constprop.0+0x19/0x170 mm/kasan/report.c:400 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560 kasan_report+0x3a/0x50 mm/kasan/report.c:585 __kuid_val include/linux/uidgid.h:36 [inline] uid_eq include/linux/uidgid.h:63 [inline] key_task_permission+0x394/0x410 security/keys/permission.c:54 search_nested_keyrings+0x90e/0xe90 security/keys/keyring.c:793 This issue was also reported by syzbot. It can be reproduced by following these steps(more details [1]): 1. Obtain more than 32 inputs that have similar hashes, which ends with the pattern '0xxxxxxxe6'. 2. Reboot and add the keys obtained in step 1. The reproducer demonstrates how this issue happened: 1. In the search_nested_keyrings function, when it iterates through the slots in a node(below tag ascend_to_node), if the slot pointer is meta and node->back_pointer != NULL(it means a root), it will proceed to descend_to_node. However, there is an exception. If node is the root, and one of the slots points to a shortcut, it will be treated as a keyring. 2. Whether the ptr is keyring decided by keyring_ptr_is_keyring function. However, KEYRING_PTR_SUBTYPE is 0x2UL, the same as ASSOC_ARRAY_PTR_SUBTYPE_MASK. 3. When 32 keys with the similar hashes are added to the tree, the ROOT has keys with hashes that are not similar (e.g. slot 0) and it splits NODE A without using a shortcut. When NODE A is filled with keys that all hashes are xxe6, the keys are similar, NODE A will split with a shortcut. Finally, it forms the tree as shown below, where slot 6 points to a shortcut. NODE A +------>+---+ ROOT | | 0 | xxe6 +---+ | +---+ xxxx | 0 | shortcut : : xxe6 +---+ | +---+ xxe6 : : | | | xxe6 +---+ | +---+ | 6 |---+ : : xxe6 +---+ +---+ xxe6 : : | f | xxe6 +---+ +---+ xxe6 | f | +---+ 4. As mentioned above, If a slot(slot 6) of the root points to a shortcut, it may be mistakenly transferred to a key*, leading to a read out-of-bounds read. To fix this issue, one should jump to descend_to_node if the ptr is a shortcut, regardless of whether the node is root or not. [1] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@huaweicloud.com/ [jarkko: tweaked the commit message a bit to have an appropriate closes tag.] (CVE-2024-50301)

  - 已修复 Linux 内核中的下列漏洞：af_packet: fix vlan_get_protocol_dgram() vs MSG_PEEK Blamed commit forgot MSG_PEEK case, allowing a crash [1] as found by syzbot. Rework vlan_get_protocol_dgram() to not touch skb at all, so that it can be used from many cpus on the same skb. Add a const qualifier to skb argument. [1] skbuff: skb_under_panic: text:ffffffff8a8ccd05 len:29 put:14 head:ffff88807fc8e400 data:ffff88807fc8e3f4 tail:0x11 end:0x140 dev:<NULL> ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:206 ! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 UID: 0 PID: 5892 Comm: syz-executor883 Not tainted 6.13.0-rc4-syzkaller-00054-gd6ef8b40d075 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP:
    0010:skb_panic net/core/skbuff.c:206 [inline] RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216 Code: 0b 8d 48 c7 c6 86 d5 25 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 5a 69 79 f7 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 RSP:
    0018:ffffc900038d7638 EFLAGS: 00010282 RAX: 0000000000000087 RBX: dffffc0000000000 RCX: 609ffd18ea660600 RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000 RBP: ffff88802483c8d0 R08:
    ffffffff817f0a8c R09: 1ffff9200071ae60 R10: dffffc0000000000 R11: fffff5200071ae61 R12: 0000000000000140 R13: ffff88807fc8e400 R14: ffff88807fc8e3f4 R15: 0000000000000011 FS: 00007fbac5e006c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2:
    00007fbac5e00d58 CR3: 000000001238e000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> skb_push+0xe5/0x100 net/core/skbuff.c:2636 vlan_get_protocol_dgram+0x165/0x290 net/packet/af_packet.c:585 packet_recvmsg+0x948/0x1ef0 net/packet/af_packet.c:3552 sock_recvmsg_nosec net/socket.c:1033 [inline] sock_recvmsg+0x22f/0x280 net/socket.c:1055 ____sys_recvmsg+0x1c6/0x480 net/socket.c:2803 ___sys_recvmsg net/socket.c:2845 [inline] do_recvmmsg+0x426/0xab0 net/socket.c:2940 __sys_recvmmsg net/socket.c:3014 [inline] __do_sys_recvmmsg net/socket.c:3037 [inline] __se_sys_recvmmsg net/socket.c:3030 [inline]
    __x64_sys_recvmmsg+0x199/0x250 net/socket.c:3030 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f (CVE-2024-57901)

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

远程 CentOS Linux 9 主机上安装的多个程序包受到 kernel-5.14.0-585.el9 版本变更日志中提及的多个漏洞影响。

  - 已修复 Linux 内核中的下列漏洞：ext4: fix OOB read when checking dotdot dir Mounting a corrupted filesystem with directory which contains '.' dir entry with rec_len == block size results in out-of-bounds read (later on, when the corrupted directory is removed).
    ext4_empty_dir() assumes every ext4 directory contains at least '.' and '..' as directory entries in the first data block. It first loads the '.' dir entry, performs sanity checks by calling ext4_check_dir_entry() and then uses its rec_len member to compute the location of '..' dir entry (in ext4_next_entry). It assumes the '..' dir entry fits into the same data block. If the rec_len of '.' is precisely one block (4KB), it slips through the sanity checks (it is considered the last directory entry in the data block) and leaves struct ext4_dir_entry_2 *de point exactly past the memory slot allocated to the data block. The following call to ext4_check_dir_entry() on new value of de then dereferences this pointer which results in out-of-bounds mem access. Fix this by extending __ext4_check_dir_entry() to check for '.' dir entries that reach the end of data block. Make sure to ignore the phony dir entries for checksum (by checking name_len for non-zero). Note: This is reported by KASAN as use-after-free in case another structure was recently freed from the slot past the bound, but it is really an OOB read. This issue was found by syzkaller tool. Call Trace: [ 38.594108] BUG: KASAN: slab-use-after-free in
    __ext4_check_dir_entry+0x67e/0x710 [ 38.594649] Read of size 2 at addr ffff88802b41a004 by task syz-executor/5375 [ 38.595158] [ 38.595288] CPU: 0 UID: 0 PID: 5375 Comm: syz-executor Not tainted 6.14.0-rc7 #1 [ 38.595298] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 38.595304] Call Trace: [ 38.595308] <TASK> [38.595311] dump_stack_lvl+0xa7/0xd0 [ 38.595325] print_address_description.constprop.0+0x2c/0x3f0 [38.595339] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595349] print_report+0xaa/0x250 [ 38.595359] ?
    __ext4_check_dir_entry+0x67e/0x710 [ 38.595368] ? kasan_addr_to_slab+0x9/0x90 [ 38.595378] kasan_report+0xab/0xe0 [ 38.595389] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595400]
    __ext4_check_dir_entry+0x67e/0x710 [ 38.595410] ext4_empty_dir+0x465/0x990 [ 38.595421] ?
    __pfx_ext4_empty_dir+0x10/0x10 [ 38.595432] ext4_rmdir.part.0+0x29a/0xd10 [ 38.595441] ?
    __dquot_initialize+0x2a7/0xbf0 [ 38.595455] ? __pfx_ext4_rmdir.part.0+0x10/0x10 [ 38.595464] ?
    __pfx___dquot_initialize+0x10/0x10 [ 38.595478] ? down_write+0xdb/0x140 [ 38.595487] ?
    __pfx_down_write+0x10/0x10 [ 38.595497] ext4_rmdir+0xee/0x140 [ 38.595506] vfs_rmdir+0x209/0x670 [38.595517] ? lookup_one_qstr_excl+0x3b/0x190 [ 38.595529] do_rmdir+0x363/0x3c0 [ 38.595537] ?
    __pfx_do_rmdir+0x10/0x10 [ 38.595544] ? strncpy_from_user+0x1ff/0x2e0 [ 38.595561]
    __x64_sys_unlinkat+0xf0/0x130 [ 38.595570] do_syscall_64+0x5b/0x180 [ 38.595583] entry_SYSCALL_64_after_hwframe+0x76/0x7e (CVE-2025-37785)

  - 已修复 Linux 内核中的下列漏洞：RDMA/rxe: Fix the qp flush warnings in req When the qp is in error state, the status of WQEs in the queue should be set to error. Or else the following will appear. [ 920.617269] WARNING: CPU: 1 PID: 21 at drivers/infiniband/sw/rxe/rxe_comp.c:756 rxe_completer+0x989/0xcc0 [rdma_rxe] [ 920.617744] Modules linked in: rnbd_client(O) rtrs_client(O) rtrs_core(O) rdma_ucm rdma_cm iw_cm ib_cm crc32_generic rdma_rxe ip6_udp_tunnel udp_tunnel ib_uverbs ib_core loop brd null_blk ipv6 [ 920.618516] CPU: 1 PID: 21 Comm: ksoftirqd/1 Tainted: G O 6.1.113-storage+ #65 [ 920.618986] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 [ 920.619396] RIP: 0010:rxe_completer+0x989/0xcc0 [rdma_rxe] [ 920.619658] Code: 0f b6 84 24 3a 02 00 00 41 89 84 24 44 04 00 00 e9 2a f7 ff ff 39 ca bb 03 00 00 00 b8 0e 00 00 00 48 0f 45 d8 e9 15 f7 ff ff <0f> 0b e9 cb f8 ff ff 41 bf f5 ff ff ff e9 08 f8 ff ff 49 8d bc 24 [ 920.620482] RSP:
    0018:ffff97b7c00bbc38 EFLAGS: 00010246 [ 920.620817] RAX: 0000000000000000 RBX: 000000000000000c RCX:
    0000000000000008 [ 920.621183] RDX: ffff960dc396ebc0 RSI: 0000000000005400 RDI: ffff960dc4e2fbac [920.621548] RBP: 0000000000000000 R08: 0000000000000001 R09: ffffffffac406450 [ 920.621884] R10:
    ffffffffac4060c0 R11: 0000000000000001 R12: ffff960dc4e2f800 [ 920.622254] R13: ffff960dc4e2f928 R14:
    ffff97b7c029c580 R15: 0000000000000000 [ 920.622609] FS: 0000000000000000(0000) GS:ffff960ef7d00000(0000) knlGS:0000000000000000 [ 920.622979] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 920.623245] CR2:
    00007fa056965e90 CR3: 00000001107f1000 CR4: 00000000000006e0 [ 920.623680] Call Trace: [ 920.623815] <TASK> [ 920.623933] ? __warn+0x79/0xc0 [ 920.624116] ? rxe_completer+0x989/0xcc0 [rdma_rxe] [ 920.624356] ? report_bug+0xfb/0x150 [ 920.624594] ? handle_bug+0x3c/0x60 [ 920.624796] ? exc_invalid_op+0x14/0x70 [920.624976] ? asm_exc_invalid_op+0x16/0x20 [ 920.625203] ? rxe_completer+0x989/0xcc0 [rdma_rxe] [920.625474] ? rxe_completer+0x329/0xcc0 [rdma_rxe] [ 920.625749] rxe_do_task+0x80/0x110 [rdma_rxe] [920.626037] rxe_requester+0x625/0xde0 [rdma_rxe] [ 920.626310] ? rxe_cq_post+0xe2/0x180 [rdma_rxe] [920.626583] ? do_complete+0x18d/0x220 [rdma_rxe] [ 920.626812] ? rxe_completer+0x1a3/0xcc0 [rdma_rxe] [920.627050] rxe_do_task+0x80/0x110 [rdma_rxe] [ 920.627285] tasklet_action_common.constprop.0+0xa4/0x120 [920.627522] handle_softirqs+0xc2/0x250 [ 920.627728] ? sort_range+0x20/0x20 [ 920.627942] run_ksoftirqd+0x1f/0x30 [ 920.628158] smpboot_thread_fn+0xc7/0x1b0 [ 920.628334] kthread+0xd6/0x100 [920.628504] ? kthread_complete_and_exit+0x20/0x20 [ 920.628709] ret_from_fork+0x1f/0x30 [ 920.628892] </TASK> (CVE-2024-53229)

  - 已修复 Linux 内核中的下列漏洞：vsock: Keep the binding until socket destruction Preserve sockets bindings; this includes both resulting from an explicit bind() and those implicitly bound through autobind during connect(). Prevents socket unbinding during a transport reassignment, which fixes a use-after-free: 1. vsock_create() (refcnt=1) calls vsock_insert_unbound() (refcnt=2) 2. transport->release() calls vsock_remove_bound() without checking if sk was bound and moved to bound list (refcnt=1) 3. vsock_bind() assumes sk is in unbound list and before
    __vsock_insert_bound(vsock_bound_sockets()) calls __vsock_remove_bound() which does:
    list_del_init(&vsk->bound_table); // nop sock_put(&vsk->sk); // refcnt=0 BUG: KASAN: slab-use-after-free in __vsock_bind+0x62e/0x730 Read of size 4 at addr ffff88816b46a74c by task a.out/2057 dump_stack_lvl+0x68/0x90 print_report+0x174/0x4f6 kasan_report+0xb9/0x190 __vsock_bind+0x62e/0x730 vsock_bind+0x97/0xe0 __sys_bind+0x154/0x1f0 __x64_sys_bind+0x6e/0xb0 do_syscall_64+0x93/0x1b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 2057: kasan_save_stack+0x1e/0x40 kasan_save_track+0x10/0x30 __kasan_slab_alloc+0x85/0x90 kmem_cache_alloc_noprof+0x131/0x450 sk_prot_alloc+0x5b/0x220 sk_alloc+0x2c/0x870 __vsock_create.constprop.0+0x2e/0xb60 vsock_create+0xe4/0x420
    __sock_create+0x241/0x650 __sys_socket+0xf2/0x1a0 __x64_sys_socket+0x6e/0xb0 do_syscall_64+0x93/0x1b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 2057: kasan_save_stack+0x1e/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x60 __kasan_slab_free+0x4b/0x70 kmem_cache_free+0x1a1/0x590 __sk_destruct+0x388/0x5a0 __vsock_bind+0x5e1/0x730 vsock_bind+0x97/0xe0
    __sys_bind+0x154/0x1f0 __x64_sys_bind+0x6e/0xb0 do_syscall_64+0x93/0x1b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e refcount_t: addition on 0; use-after-free. WARNING: CPU: 7 PID:
    2057 at lib/refcount.c:25 refcount_warn_saturate+0xce/0x150 RIP: 0010:refcount_warn_saturate+0xce/0x150
    __vsock_bind+0x66d/0x730 vsock_bind+0x97/0xe0 __sys_bind+0x154/0x1f0 __x64_sys_bind+0x6e/0xb0 do_syscall_64+0x93/0x1b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e refcount_t: underflow; use-after-free.
    WARNING: CPU: 7 PID: 2057 at lib/refcount.c:28 refcount_warn_saturate+0xee/0x150 RIP:
    0010:refcount_warn_saturate+0xee/0x150 vsock_remove_bound+0x187/0x1e0 __vsock_release+0x383/0x4a0 vsock_release+0x90/0x120 __sock_release+0xa3/0x250 sock_close+0x14/0x20 __fput+0x359/0xa80 task_work_run+0x107/0x1d0 do_exit+0x847/0x2560 do_group_exit+0xb8/0x250 __x64_sys_exit_group+0x3a/0x50 x64_sys_call+0xfec/0x14f0 do_syscall_64+0x93/0x1b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e (CVE-2025-21756)

  - 已修复 Linux 内核中的下列漏洞：smb: client: Add check for next_buffer in receive_encrypted_standard() Add check for the return value of cifs_buf_get() and cifs_small_buf_get() in receive_encrypted_standard() to prevent null pointer dereference. (CVE-2025-21844)

  - 已修复 Linux 内核中的下列漏洞：net: ppp: Add bound checking for skb data on ppp_sync_txmung Ensure we have enough data in linear buffer from skb before accessing initial bytes. This prevents potential out-of-bounds accesses when processing short packets. When ppp_sync_txmung receives an incoming package with an empty payload: (remote) gef p *(struct pppoe_hdr *) (skb->head + skb->network_header) $18 = { type = 0x1, ver = 0x1, code = 0x0, sid = 0x2, length = 0x0, tag = 0xffff8880371cdb96 } from the skb struct (trimmed) tail = 0x16, end = 0x140, head = 0xffff88803346f400 4, data = 0xffff88803346f416 :\377, truesize = 0x380, len = 0x0, data_len = 0x0, mac_len = 0xe, hdr_len = 0x0, it is not safe to access data[2]. [pabeni@redhat.com: fixed subj typo] (CVE-2025-37749)

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

远程 CentOS Linux 9 主机上安装的多个程序包受到 kernel-5.14.0-583.el9 版本变更日志中提及的多个漏洞影响。

  - 已修复 Linux 内核中的下列漏洞：blk-cgroup: Fix class @block_class's subsystem refcount leakage blkcg_fill_root_iostats() iterates over @block_class's devices by class_dev_iter_(init|next)(), but does not end iterating with class_dev_iter_exit(), so causes the class's subsystem refcount leakage. Fix by ending the iterating with class_dev_iter_exit(). (CVE-2025-21745)

  - 已修复 Linux 内核中的下列漏洞：io_uring/uring_cmd: unconditionally copy SQEs at prep time This isn't generally necessary, but conditions have been observed where SQE data is accessed from the original SQE after prep has been done and outside of the initial issue. Opcode prep handlers must ensure that any SQE related data is stable beyond the prep phase, but uring_cmd is a bit special in how it handles the SQE which makes it susceptible to reading stale data. If the application has reused the SQE before the original completes, then that can lead to data corruption. Down the line we can relax this again once uring_cmd has been sanitized a bit, and avoid unnecessarily copying the SQE.
    (CVE-2025-21837)

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

远程 CentOS Linux 9 主机上安装的多个程序包受到 kernel-5.14.0-582.el9 版本变更日志中提及的多个漏洞影响。

  - 已修复 Linux 内核中的下列漏洞：ipv6: Fix memleak of nhc_pcpu_rth_output in fib_check_nh_v6_gw(). fib_check_nh_v6_gw() expects that fib6_nh_init() cleans up everything when it fails. Commit 7dd73168e273 (ipv6: Always allocate pcpu memory in a fib6_nh) moved fib_nh_common_init() before alloc_percpu_gfp() within fib6_nh_init() but forgot to add cleanup for fib6_nh->nh_common.nhc_pcpu_rth_output in case it fails to allocate fib6_nh->rt6i_pcpu, resulting in memleak. Let's call fib_nh_common_release() and clear nhc_pcpu_rth_output in the error path. Note that we can remove the fib6_nh_release() call in nh_create_ipv6() later in net-next.git. (CVE-2025-22005)

  - 已修复 Linux 内核中的下列漏洞：igb: Fix potential invalid memory access in igb_init_module() The pci_register_driver() can fail and when this happened, the dca_notifier needs to be unregistered, otherwise the dca_notifier can be called when igb fails to install, resulting to invalid memory access. (CVE-2024-52332)

  - 已修复 Linux 内核中的下列漏洞：nfsd: release svc_expkey/svc_export with rcu_work The last reference for `cache_head` can be reduced to zero in `c_show` and `e_show`(using `rcu_read_lock` and `rcu_read_unlock`). Consequently, `svc_export_put` and `expkey_put` will be invoked, leading to two issues: 1. The `svc_export_put` will directly free ex_uuid. However, `e_show`/`c_show` will access `ex_uuid` after `cache_put`, which can trigger a use-after-free issue, shown below.
    ================================================================== BUG: KASAN: slab-use-after-free in svc_export_show+0x362/0x430 [nfsd] Read of size 1 at addr ff11000010fdc120 by task cat/870 CPU: 1 UID: 0 PID: 870 Comm: cat Not tainted 6.12.0-rc3+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x53/0x70 print_address_description.constprop.0+0x2c/0x3a0 print_report+0xb9/0x280 kasan_report+0xae/0xe0 svc_export_show+0x362/0x430 [nfsd] c_show+0x161/0x390 [sunrpc] seq_read_iter+0x589/0x770 seq_read+0x1e5/0x270 proc_reg_read+0xe1/0x140 vfs_read+0x125/0x530 ksys_read+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 830:
    kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0
    __kmalloc_node_track_caller_noprof+0x1bc/0x400 kmemdup_noprof+0x22/0x50 svc_export_parse+0x8a9/0xb80 [nfsd] cache_do_downcall+0x71/0xa0 [sunrpc] cache_write_procfs+0x8e/0xd0 [sunrpc] proc_reg_write+0xe1/0x140 vfs_write+0x1a5/0x6d0 ksys_write+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 868: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x37/0x50 kfree+0xf3/0x3e0 svc_export_put+0x87/0xb0 [nfsd] cache_purge+0x17f/0x1f0 [sunrpc] nfsd_destroy_serv+0x226/0x2d0 [nfsd] nfsd_svc+0x125/0x1e0 [nfsd] write_threads+0x16a/0x2a0 [nfsd] nfsctl_transaction_write+0x74/0xa0 [nfsd] vfs_write+0x1a5/0x6d0 ksys_write+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e 2. We cannot sleep while using `rcu_read_lock`/`rcu_read_unlock`.
    However, `svc_export_put`/`expkey_put` will call path_put, which subsequently triggers a sleeping operation due to the following `dput`. ============================= WARNING: suspicious RCU usage 5.10.0-dirty #141 Not tainted ----------------------------- ... Call Trace: dump_stack+0x9a/0xd0
    ___might_sleep+0x231/0x240 dput+0x39/0x600 path_put+0x1b/0x30 svc_export_put+0x17/0x80 e_show+0x1c9/0x200 seq_read_iter+0x63f/0x7c0 seq_read+0x226/0x2d0 vfs_read+0x113/0x2c0 ksys_read+0xc9/0x170 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x67/0xd1 Fix these issues by using `rcu_work` to help release `svc_expkey`/`svc_export`. This approach allows for an asynchronous context to invoke `path_put` and also facilitates the freeing of `uuid/exp/key` after an RCU grace period. (CVE-2024-53216)

  - 已修复 Linux 内核中的下列漏洞：Bluetooth: iso: Fix circular lock in iso_conn_big_sync This fixes the circular locking dependency warning below, by reworking iso_sock_recvmsg, to ensure that the socket lock is always released before calling a function that locks hdev. [ 561.670344] ====================================================== [ 561.670346] WARNING: possible circular locking dependency detected [ 561.670349] 6.12.0-rc6+ #26 Not tainted [ 561.670351]
    ------------------------------------------------------ [ 561.670353] iso-tester/3289 is trying to acquire lock: [ 561.670355] ffff88811f600078 (&hdev->lock){+.+.}-{3:3}, at: iso_conn_big_sync+0x73/0x260 [bluetooth] [ 561.670405] but task is already holding lock: [ 561.670407] ffff88815af58258 (sk_lock-AF_BLUETOOTH){+.+.}-{0:0}, at: iso_sock_recvmsg+0xbf/0x500 [bluetooth] [ 561.670450] which lock already depends on the new lock. [ 561.670452] the existing dependency chain (in reverse order) is: [ 561.670453]
    -> #2 (sk_lock-AF_BLUETOOTH){+.+.}-{0:0}: [ 561.670458] lock_acquire+0x7c/0xc0 [ 561.670463] lock_sock_nested+0x3b/0xf0 [ 561.670467] bt_accept_dequeue+0x1a5/0x4d0 [bluetooth] [ 561.670510] iso_sock_accept+0x271/0x830 [bluetooth] [ 561.670547] do_accept+0x3dd/0x610 [ 561.670550]
    __sys_accept4+0xd8/0x170 [ 561.670553] __x64_sys_accept+0x74/0xc0 [ 561.670556] x64_sys_call+0x17d6/0x25f0 [ 561.670559] do_syscall_64+0x87/0x150 [ 561.670563] entry_SYSCALL_64_after_hwframe+0x76/0x7e [561.670567] -> #1 (sk_lock-AF_BLUETOOTH-BTPROTO_ISO){+.+.}-{0:0}: [ 561.670571] lock_acquire+0x7c/0xc0 [561.670574] lock_sock_nested+0x3b/0xf0 [ 561.670577] iso_sock_listen+0x2de/0xf30 [bluetooth] [ 561.670617]
    __sys_listen_socket+0xef/0x130 [ 561.670620] __x64_sys_listen+0xe1/0x190 [ 561.670623] x64_sys_call+0x2517/0x25f0 [ 561.670626] do_syscall_64+0x87/0x150 [ 561.670629] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 561.670632] -> #0 (&hdev->lock){+.+.}-{3:3}: [ 561.670636]
    __lock_acquire+0x32ad/0x6ab0 [ 561.670639] lock_acquire.part.0+0x118/0x360 [ 561.670642] lock_acquire+0x7c/0xc0 [ 561.670644] __mutex_lock+0x18d/0x12f0 [ 561.670647] mutex_lock_nested+0x1b/0x30 [561.670651] iso_conn_big_sync+0x73/0x260 [bluetooth] [ 561.670687] iso_sock_recvmsg+0x3e9/0x500 [bluetooth] [ 561.670722] sock_recvmsg+0x1d5/0x240 [ 561.670725] sock_read_iter+0x27d/0x470 [ 561.670727] vfs_read+0x9a0/0xd30 [ 561.670731] ksys_read+0x1a8/0x250 [ 561.670733] __x64_sys_read+0x72/0xc0 [561.670736] x64_sys_call+0x1b12/0x25f0 [ 561.670738] do_syscall_64+0x87/0x150 [ 561.670741] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 561.670744] other info that might help us debug this: [561.670745] Chain exists of: &hdev->lock --> sk_lock-AF_BLUETOOTH-BTPROTO_ISO --> sk_lock-AF_BLUETOOTH [561.670751] Possible unsafe locking scenario: [ 561.670753] CPU0 CPU1 [ 561.670754] ---- ---- [561.670756] lock(sk_lock-AF_BLUETOOTH); [ 561.670758] lock(sk_lock AF_BLUETOOTH-BTPROTO_ISO); [561.670761] lock(sk_lock-AF_BLUETOOTH); [ 561.670764] lock(&hdev->lock); [ 561.670767] *** DEADLOCK *** (CVE-2024-54191)

  - 已修复 Linux 内核中的下列漏洞：RDMA/mlx5: Fix implicit ODP use after free Prevent double queueing of implicit ODP mr destroy work by using __xa_cmpxchg() to make sure this is the only time we are destroying this specific mr. Without this change, we could try to invalidate this mr twice, which in turn could result in queuing a MR work destroy twice, and eventually the second work could execute after the MR was freed due to the first work, causing a user after free and trace below.
    refcount_t: underflow; use-after-free. WARNING: CPU: 2 PID: 12178 at lib/refcount.c:28 refcount_warn_saturate+0x12b/0x130 Modules linked in: bonding ib_ipoib vfio_pci ip_gre geneve nf_tables ip6_gre gre ip6_tunnel tunnel6 ipip tunnel4 ib_umad rdma_ucm mlx5_vfio_pci vfio_pci_core vfio_iommu_type1 mlx5_ib vfio ib_uverbs mlx5_core iptable_raw openvswitch nsh rpcrdma ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm ib_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay zram zsmalloc fuse [last unloaded: ib_uverbs] CPU: 2 PID: 12178 Comm: kworker/u20:5 Not tainted 6.5.0-rc1_net_next_mlx5_58c644e #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org04/01/2014 Workqueue: events_unbound free_implicit_child_mr_work [mlx5_ib] RIP:
    0010:refcount_warn_saturate+0x12b/0x130 Code: 48 c7 c7 38 95 2a 82 c6 05 bc c6 fe 00 01 e8 0c 66 aa ff 0f 0b 5b c3 48 c7 c7 e0 94 2a 82 c6 05 a7 c6 fe 00 01 e8 f5 65 aa ff <0f> 0b 5b c3 90 8b 07 3d 00 00 00 c0 74 12 83 f8 01 74 13 8d 50 ff RSP: 0018:ffff8881008e3e40 EFLAGS: 00010286 RAX: 0000000000000000 RBX:
    0000000000000000 RCX: 0000000000000027 RDX: ffff88852c91b5c8 RSI: 0000000000000001 RDI: ffff88852c91b5c0 RBP: ffff8881dacd4e00 R08: 00000000ffffffff R09: 0000000000000019 R10: 000000000000072e R11:
    0000000063666572 R12: ffff88812bfd9e00 R13: ffff8881c792d200 R14: ffff88810011c005 R15: ffff8881002099c0 FS: 0000000000000000(0000) GS:ffff88852c900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f5694b5e000 CR3: 00000001153f6003 CR4: 0000000000370ea0 DR0:
    0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? refcount_warn_saturate+0x12b/0x130 free_implicit_child_mr_work+0x180/0x1b0 [mlx5_ib] process_one_work+0x1cc/0x3c0 worker_thread+0x218/0x3c0 kthread+0xc6/0xf0 ret_from_fork+0x1f/0x30 </TASK> (CVE-2025-21714)

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

远程 CentOS Linux 9 主机上安装的多个程序包受到 kernel-5.14.0-580.el9 版本变更日志中提及的多个漏洞影响。

  - 已修复 Linux 内核中的下列漏洞：ipvlan: ensure network headers are in skb linear part syzbot found that ipvlan_process_v6_outbound() was assuming the IPv6 network header isis present in skb->head [1] Add the needed pskb_network_may_pull() calls for both IPv4 and IPv6 handlers. [1] BUG: KMSAN: uninit-value in __ipv6_addr_type+0xa2/0x490 net/ipv6/addrconf_core.c:47
    __ipv6_addr_type+0xa2/0x490 net/ipv6/addrconf_core.c:47 ipv6_addr_type include/net/ipv6.h:555 [inline] ip6_route_output_flags_noref net/ipv6/route.c:2616 [inline] ip6_route_output_flags+0x51/0x720 net/ipv6/route.c:2651 ip6_route_output include/net/ip6_route.h:93 [inline] ipvlan_route_v6_outbound+0x24e/0x520 drivers/net/ipvlan/ipvlan_core.c:476 ipvlan_process_v6_outbound drivers/net/ipvlan/ipvlan_core.c:491 [inline] ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:541 [inline] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:605 [inline] ipvlan_queue_xmit+0xd72/0x1780 drivers/net/ipvlan/ipvlan_core.c:671 ipvlan_start_xmit+0x5b/0x210 drivers/net/ipvlan/ipvlan_main.c:223
    __netdev_start_xmit include/linux/netdevice.h:5150 [inline] netdev_start_xmit include/linux/netdevice.h:5159 [inline] xmit_one net/core/dev.c:3735 [inline] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3751 sch_direct_xmit+0x399/0xd40 net/sched/sch_generic.c:343 qdisc_restart net/sched/sch_generic.c:408 [inline] __qdisc_run+0x14da/0x35d0 net/sched/sch_generic.c:416 qdisc_run+0x141/0x4d0 include/net/pkt_sched.h:127 net_tx_action+0x78b/0x940 net/core/dev.c:5484 handle_softirqs+0x1a0/0x7c0 kernel/softirq.c:561 __do_softirq+0x14/0x1a kernel/softirq.c:595 do_softirq+0x9a/0x100 kernel/softirq.c:462 __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:389 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline] __dev_queue_xmit+0x2758/0x57d0 net/core/dev.c:4611 dev_queue_xmit include/linux/netdevice.h:3311 [inline] packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3132 [inline] packet_sendmsg+0x93e0/0xa7e0 net/packet/af_packet.c:3164 sock_sendmsg_nosec net/socket.c:718 [inline] (CVE-2025-21891)

  - 已修复 Linux 内核中的下列漏洞：ima: Fix potential memory leak in ima_init_crypto() On failure to allocate the SHA1 tfm, IMA fails to initialize and exits without freeing the ima_algo_array. Add the missing kfree() for ima_algo_array to avoid the potential memory leak.
    (CVE-2022-49627)

  - 已修复 Linux 内核中的下列漏洞：pfifo_tail_enqueue: Drop new packet when sch->limit == 0 Expected behaviour: In case we reach scheduler's limit, pfifo_tail_enqueue() will drop a packet in scheduler's queue and decrease scheduler's qlen by one. Then, pfifo_tail_enqueue() enqueue new packet and increase scheduler's qlen by one. Finally, pfifo_tail_enqueue() return `NET_XMIT_CN` status code. Weird behaviour: In case we set `sch->limit == 0` and trigger pfifo_tail_enqueue() on a scheduler that has no packet, the 'drop a packet' step will do nothing. This means the scheduler's qlen still has value equal 0. Then, we continue to enqueue new packet and increase scheduler's qlen by one. In summary, we can leverage pfifo_tail_enqueue() to increase qlen by one and return `NET_XMIT_CN` status code. The problem is: Let's say we have two qdiscs: Qdisc_A and Qdisc_B. - Qdisc_A's type must have '->graft()' function to create parent/child relationship. Let's say Qdisc_A's type is `hfsc`. Enqueue packet to this qdisc will trigger `hfsc_enqueue`. - Qdisc_B's type is pfifo_head_drop. Enqueue packet to this qdisc will trigger `pfifo_tail_enqueue`. - Qdisc_B is configured to have `sch->limit == 0`. - Qdisc_A is configured to route the enqueued's packet to Qdisc_B. Enqueue packet through Qdisc_A will lead to: - hfsc_enqueue(Qdisc_A) -> pfifo_tail_enqueue(Qdisc_B) - Qdisc_B->q.qlen += 1 - pfifo_tail_enqueue() return `NET_XMIT_CN` - hfsc_enqueue() check for `NET_XMIT_SUCCESS` and see `NET_XMIT_CN` => hfsc_enqueue() don't increase qlen of Qdisc_A. The whole process lead to a situation where Qdisc_A->q.qlen == 0 and Qdisc_B->q.qlen == 1. Replace 'hfsc' with other type (for example: 'drr') still lead to the same problem. This violate the design where parent's qlen should equal to the sum of its childrens'qlen. Bug impact: This issue can be used for user->kernel privilege escalation when it is reachable. (CVE-2025-21702)

  - 已修复 Linux 内核中的下列漏洞：ipv6: use RCU protection in ip6_default_advmss() ip6_default_advmss() needs rcu protection to make sure the net structure it reads does not disappear. (CVE-2025-21765)

  - 已修复 Linux 内核中的下列漏洞：vxlan: check vxlan_vnigroup_init() return value vxlan_init() must check vxlan_vnigroup_init() success otherwise a crash happens later, spotted by syzbot. Oops: general protection fault, probably for non-canonical address 0xdffffc000000002c:
    0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000160-0x0000000000000167] CPU: 0 UID: 0 PID: 7313 Comm: syz-executor147 Not tainted 6.14.0-rc1-syzkaller-00276-g69b54314c975 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP:
    0010:vxlan_vnigroup_uninit+0x89/0x500 drivers/net/vxlan/vxlan_vnifilter.c:912 Code: 00 48 8b 44 24 08 4c 8b b0 98 41 00 00 49 8d 86 60 01 00 00 48 89 c2 48 89 44 24 10 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 4d 04 00 00 49 8b 86 60 01 00 00 48 ba 00 00 00 RSP: 0018:ffffc9000cc1eea8 EFLAGS:
    00010202 RAX: dffffc0000000000 RBX: 0000000000000001 RCX: ffffffff8672effb RDX: 000000000000002c RSI:
    ffffffff8672ecb9 RDI: ffff8880461b4f18 RBP: ffff8880461b4ef4 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000020000 R13: ffff8880461b0d80 R14:
    0000000000000000 R15: dffffc0000000000 FS: 00007fecfa95d6c0(0000) GS:ffff88806a600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fecfa95cfb8 CR3:
    000000004472c000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> vxlan_uninit+0x1ab/0x200 drivers/net/vxlan/vxlan_core.c:2942 unregister_netdevice_many_notify+0x12d6/0x1f30 net/core/dev.c:11824 unregister_netdevice_many net/core/dev.c:11866 [inline] unregister_netdevice_queue+0x307/0x3f0 net/core/dev.c:11736 register_netdevice+0x1829/0x1eb0 net/core/dev.c:10901 __vxlan_dev_create+0x7c6/0xa30 drivers/net/vxlan/vxlan_core.c:3981 vxlan_newlink+0xd1/0x130 drivers/net/vxlan/vxlan_core.c:4407 rtnl_newlink_create net/core/rtnetlink.c:3795 [inline] __rtnl_newlink net/core/rtnetlink.c:3906 [inline] (CVE-2025-21790)

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

远程 CentOS Linux 9 主机上安装的多个程序包受到 kernel-5.14.0-578.el9 版本变更日志中提及的多个漏洞影响。

  - 已修复 Linux 内核中的下列漏洞：soc: qcom: socinfo: Avoid out of bounds read of serial number On MSM8916 devices, the serial number exposed in sysfs is constant and does not change across individual devices. It's always: db410c:/sys/devices/soc0$ cat serial_number 2644893864 The firmware used on MSM8916 exposes SOCINFO_VERSION(0, 8), which does not have support for the serial_num field in the socinfo struct. There is an existing check to avoid exposing the serial number in that case, but it's not correct: When checking the item_size returned by SMEM, we need to make sure the *end* of the serial_num is within bounds, instead of comparing with the *start* offset. The serial_number currently exposed on MSM8916 devices is just an out of bounds read of whatever comes after the socinfo struct in SMEM. Fix this by changing offsetof() to offsetofend(), so that the size of the field is also taken into account. (CVE-2024-58007)

  - 已修复 Linux 内核中的下列漏洞：padata: avoid UAF for reorder_work Although the previous patch can avoid ps and ps UAF for _do_serial, it can not avoid potential UAF issue for reorder_work. This issue can happen just as below: crypto_request crypto_request crypto_del_alg padata_do_serial ... padata_reorder // processes all remaining // requests then breaks while (1) { if (!padata) break; ... } padata_do_serial // new request added list_add // sees the new request queue_work(reorder_work) padata_reorder queue_work_on(squeue->work) ... <kworker context> padata_serial_worker // completes new request, // no more outstanding // requests crypto_del_alg // free pd <kworker context> invoke_padata_reorder // UAF of pd To avoid UAF for 'reorder_work', get 'pd' ref before put 'reorder_work' into the 'serial_wq' and put 'pd' ref until the 'serial_wq' finish.
    (CVE-2025-21726)

  - 已修复 Linux 内核中的下列漏洞：nfsd: clear acl_access/acl_default after releasing them If getting acl_default fails, acl_access and acl_default will be released simultaneously. However, acl_access will still retain a pointer pointing to the released posix_acl, which will trigger a WARNING in nfs3svc_release_getacl like this: ------------[ cut here ]------------ refcount_t: underflow; use-after-free. WARNING: CPU: 26 PID: 3199 at lib/refcount.c:28 refcount_warn_saturate+0xb5/0x170 Modules linked in: CPU: 26 UID: 0 PID: 3199 Comm: nfsd Not tainted 6.12.0-rc6-00079-g04ae226af01f-dirty #8 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 RIP: 0010:refcount_warn_saturate+0xb5/0x170 Code: cc cc 0f b6 1d b3 20 a5 03 80 fb 01 0f 87 65 48 d8 00 83 e3 01 75 e4 48 c7 c7 c0 3b 9b 85 c6 05 97 20 a5 03 01 e8 fb 3e 30 ff <0f> 0b eb cd 0f b6 1d 8a3 RSP: 0018:ffffc90008637cd8 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff83904fde RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88871ed36380 RBP:
    ffff888158beeb40 R08: 0000000000000001 R09: fffff520010c6f56 R10: ffffc90008637ab7 R11: 0000000000000001 R12: 0000000000000001 R13: ffff888140e77400 R14: ffff888140e77408 R15: ffffffff858b42c0 FS:
    0000000000000000(0000) GS:ffff88871ed00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0:
    0000000080050033 CR2: 0000562384d32158 CR3: 000000055cc6a000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
    0000000000000400 Call Trace: <TASK> ? refcount_warn_saturate+0xb5/0x170 ? __warn+0xa5/0x140 ? refcount_warn_saturate+0xb5/0x170 ? report_bug+0x1b1/0x1e0 ? handle_bug+0x53/0xa0 ? exc_invalid_op+0x17/0x40 ? asm_exc_invalid_op+0x1a/0x20 ? tick_nohz_tick_stopped+0x1e/0x40 ? refcount_warn_saturate+0xb5/0x170 ? refcount_warn_saturate+0xb5/0x170 nfs3svc_release_getacl+0xc9/0xe0 svc_process_common+0x5db/0xb60 ? __pfx_svc_process_common+0x10/0x10 ? __rcu_read_unlock+0x69/0xa0 ?
    __pfx_nfsd_dispatch+0x10/0x10 ? svc_xprt_received+0xa1/0x120 ? xdr_init_decode+0x11d/0x190 svc_process+0x2a7/0x330 svc_handle_xprt+0x69d/0x940 svc_recv+0x180/0x2d0 nfsd+0x168/0x200 ?
    __pfx_nfsd+0x10/0x10 kthread+0x1a2/0x1e0 ? kthread+0xf4/0x1e0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x60 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> Kernel panic - not syncing: kernel: panic_on_warn set ... Clear acl_access/acl_default after posix_acl_release is called to prevent UAF from being triggered. (CVE-2025-21796)

  - 已修复 Linux 内核中的下列漏洞：tcp: drop secpath at the same time as we currently drop dst Xiumei reported hitting the WARN in xfrm6_tunnel_net_exit while running tests that boil down to: - create a pair of netns - run a basic TCP test over ipcomp6 - delete the pair of netns The xfrm_state found on spi_byaddr was not deleted at the time we delete the netns, because we still have a reference on it. This lingering reference comes from a secpath (which holds a ref on the xfrm_state), which is still attached to an skb. This skb is not leaked, it ends up on sk_receive_queue and then gets defer-free'd by skb_attempt_defer_free. The problem happens when we defer freeing an skb (push it on one CPU's defer_list), and don't flush that list before the netns is deleted. In that case, we still have a reference on the xfrm_state that we don't expect at this point. We already drop the skb's dst in the TCP receive path when it's no longer needed, so let's also drop the secpath. At this point, tcp_filter has already called into the LSM hooks that may require the secpath, so it should not be needed anymore.
    However, in some of those places, the MPTCP extension has just been attached to the skb, so we cannot simply drop all extensions. (CVE-2025-21864)

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

远程 CentOS Linux 9 主机上安装的多个程序包受到 kernel-5.14.0-575.el9 版本变更日志中提及的多个漏洞影响。

  - 在 Linux 内核中，以下漏洞已解决：vrf：在 l3mdev_l3_out() 中使用 RCU 保护 l3mdev_l3_out() 可能在未持有 RCU 的情况下被调用：raw_sendmsg() ip_push_pending_frames() ip_send_skb() ip_local_out() __ip_local_out() l3mdev_ip_out( ) 添加 rcu_read_lock() / rcu_read_unlock() 对，以避免潜在的 UAF 问题。(CVE-2025-21791)

  - 在 Linux 内核中，以下漏洞已解决：tpm：在 eventlog/acpi.c 中改为使用 kvalloc() 据报告，在 HPE ProLiant D320上发生以下故障：[ 10.693310][ T1] tpm_tis STM0925:00：2.0 TPM（设备 id 0x3，rev-id 0）[ 10.848132][ T1]------------[在此处切断 ]----------- [10.853559][ T1] 警告：CPU：59 PID：1 在 mm/page_alloc.c:4727 __alloc_pages_noprof+0x2ca/0x330 [10.862827][ T1] 模块链接于：[ 10.866671][ T1] CPU：59 UID：0 PID: 1 Comm: swapper/0 未损坏 6.12.0-lp155.2.g52785e2-default #1 openSUSE Tumbleweed（未发布）588cd98293a7c9eba9013378d807364c088c9375 [ 10.882741][ T1] 硬件名称：HPE ProLiant DL320 Gen12/ProLiant DL320 Gen12 、BIOS 1.20 10/28/2024 [ 10.892170][ T1] RIP：
    0010:__alloc_pages_noprof+0x2ca/0x330 [ 10.898103][ T1] 代码：24 08 e9 4a fe ff ff e8 34 36 fa ff e9 88 fe ff ff 83 fe 0a 0f 86 b3 fd ff ff 80 3d 01 e7 ce 01 00 75 09 c6 05 f8 e6 ce 01 01 <0f> 0b 45 31 ff e9 e5 fe ff ff f7 c2 00 00 08 00 75 42 89 d9 80 e1 [ 10.917750][ T1] RSP：0000:ffffb7cf40077980 EFLAGS：00010246 [10.923777] [ T1] RAX：0000000000000000 RBX：0000000000040cc0 RCX：0000000000000000 [ 10.931727][ T1] RDX：
    0000000000000000 RSI: 000000000000000c RDI: 0000000000040cc0 以上脚本显示，ACPI 为日志事件指向了一个 16 MiB 的缓冲区，这是因为 RSI 映射到 __alloc_pages_noprof() 的“order”参数所致。
    通过从 devm_kmalloc() 转向使用 devm_add_action()、kvmalloc() 和 devm_add_action() 来解决缺陷。
    (CVE-2024-58005)

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

远程 CentOS Linux 9 主机上安装的多个程序包受到 kernel-5.14.0-573.el9 版本变更日志中提及的多个漏洞影响。

  - 在 Linux 内核中，已解决以下漏洞: scsi: sg: 修复 sg_release() 中的 slab 释放后使用读取漏洞。修复 sg_release() 中的释放后使用缺陷，此缺陷是由搭载 KASAN 的 syzbot 检测到的: 缺陷: KASAN: lock_release+0x151/0xa30 kernel/locking/lockdep.c:5838
    __mutex_unlock_slowpath+0xe2/0x750 kernel/locking/mutex.c:912 sg_release+0x1f4/0x2e0 drivers/scsi/sg.c:407 中的 slab 释放后使用漏洞。在 sg_release() 中，首先调用函数 kref_put(&sfp->f_ref, sg_remove_sfp)，然后再释放 open_rel_lock mutex。kref_put() 调用可能会将 sfp 的引用计数递减为零，从而触发通过 sg_remove_sfp() 执行的清理作业。这项清理作业包括通过 sg_remove_sfp_usercontext() 安排推迟的作业，并最终释放 sfp。在执行 kref_put() 调用后，sg_release() 会继续解锁 open_rel_lock 并可能引用 sfp 或 sdp。如已释放 sfp，这将会导致 slab 释放后使用错误。在解锁 open_rel_lock mutex 后，移动 kref_put(&sfp->f_ref, sg_remove_sfp) 调用。这可确保: - 引用计数递减后，不会再发生引用 sfp 或 sdp 的情况。- sg_remove_sfp() 和 sg_remove_sfp_usercontext() 等清理函数可安全执行，且不会影响 sg_release() 中的互斥体处理。此修复程序已经过 syzbot 测试和验证。此补丁可修复以下 syzkaller 链接中报告的缺陷，并确保资源清理和互斥体操作的顺序正确无误，从而消除 sg_release() 中发生释放后使用错误的风险。(CVE-2024-56631)

  - 在 Linux 内核中，已解决以下漏洞: can: isotp : 清理 isotp_bind() 中的 CAN ID 检查。Syzbot 创建的环境会导致状态机进入采用合规 CAN ID 地址配置时无法达到的状态。提供的地址信息由 CAN ID 0x6000001 和 0xC28001 组成，两者在发送和接收期间都会归结为 11 位 CAN ID 0x001。在执行地址检查之前，清理 SFF/EFF CAN ID 值。(CVE-2022-49269)

  - 在 Linux 内核中，已解决以下漏洞: can: bcm: 修复 bcm_proc_show() 中的 UAF。缺陷: KASAN: bcm_proc_show+0x969/0xa80 中的 slab 释放后使用漏洞。通过 cat/7862 任务，在地址 ffff888155846230 读取 8 个字节 CPU: 1 PID: 7862 命令: cat 不会污染 6.5.0-rc1-00153-gc8746099c197 #230 硬件名称:
    QEMU Standard PC (i440FX + PIIX，1996 年)，BIOS 1.15.0-1 04/01/2014 调用跟踪: <TASK> dump_stack_lvl+0xd5/0x150 print_report+0xc1/0x5e0 kasan_report+0xba/0xf0 bcm_proc_show+0x969/0xa80 seq_read_iter+0x4f6/0x1260 seq_read+0x165/0x210 proc_reg_read+0x227/0x300 vfs_read+0x1d5/0x8d0 ksys_read+0x11e/0x240 do_syscall_64+0x35/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcd Allocated by task 7846: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 __kasan_kmalloc+0x9e/0xa0 bcm_sendmsg+0x264b/0x44e0 sock_sendmsg+0xda/0x180 ____sys_sendmsg+0x735/0x920 ___sys_sendmsg+0x11d/0x1b0
    __sys_sendmsg+0xfa/0x1d0 do_syscall_64+0x35/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcd 已由任务 7846 释放: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 kasan_save_free_info+0x27/0x40
    在 bcm_release() 中删除 procfs 条目之前释放 ____kasan_slab_free+0x161/0x1c0 slab_free_freelist_hook+0x119/0x220 __kmem_cache_free+0xb4/0x2e0 rcu_core+0x809/0x1bd0 bcm_op，这会导致 bcm_proc_show() 可能读取已释放的 bcm_op。(CVE-2023-52922)

  - 在 Linux 内核中，已解决以下漏洞: x86/xen: 不通过超级调用页面执行 PV iret 超级调用。直接在 xen-asm.S 中对所需序列进行编码，而不是跳至 Xen 超级调用页面执行 iret 超级调用。这样做是为了完全不再使用超级调用页面，因为经证实这会导致推测缓解措施出现问题。这是 XSA-466/CVE-2024-53241 的一部分。(CVE-2024-53241)

  - 在 Linux 内核中，已解决以下漏洞: scsi：scsi: megaraid_sas: 修复潜在的死锁。这修复了“检测到可能的循环锁定依存关系”警告 CPU0 CPU1 ----
    ---- lock(&instance->reset_mutex); lock(&shost->scan_mutex); lock(&instance->reset_mutex);
    lock(&shost->scan_mutex)；通过临时释放 reset_mutex 修复此问题。(CVE-2024-57807)

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

远程 CentOS Linux 9 主机上安装的多个程序包受到 kernel-5.14.0-572.el9 版本变更日志中提及的多个漏洞影响。

  - 在 Linux 内核中，已解决以下漏洞：arm64: cacheinfo: 避免越界写入 cacheinfo 数组。检测或填充缓存信息的循环已在数组大小上存在边界检查，但不会考虑具有单独数据或指令缓存的缓存级别。通过增加任何填充的叶（而非任意填充的级别）的索引修复此问题。 (CVE-2025-21785)

  - 在 Linux 内核中，已解决以下漏洞：powerpc/xive/spapr: correct bitmap allocation size kasan detects access beyond the end of the xibm->bitmap allocation: BUG: KASAN: slab-out-of-bounds in _find_first_zero_bit+0x40/0x140 Read of size 8 at addr c00000001d1d0118 by task swapper/0/1 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.19.0-rc2-00001-g90df023b36dd #28 调用跟踪：
    [c00000001d98f770] [c0000000012baab8] dump_stack_lvl+0xac/0x108 (unreliable) [c00000001d98f7b0] [c00000000068faac] print_report+0x37c/0x710 [c00000001d98f880] [c0000000006902c0] kasan_report+0x110/0x354 [c00000001d98f950] [c000000000692324] __asan_load8+0xa4/0xe0 [c00000001d98f970] [c0000000011c6ed0]
    _find_first_zero_bit+0x40/0x140 [c00000001d98f9b0] [c0000000000dbfbc] xive_spapr_get_ipi+0xcc/0x260 [c00000001d98fa70] [c0000000000d6d28] xive_setup_cpu_ipi+0x1e8/0x450 [c00000001d98fb30] [c000000004032a20] pSeries_smp_probe+0x5c/0x118 [c00000001d98fb60] [c000000004018b44] smp_prepare_cpus+0x944/0x9ac [ c00000001d98fc90] [c000000004009f9c] kernel_init_freeable+0x2d4/0x640 [c00000001d98fd90] [c0000000000131e8] kernel_init+0x28/0x1d0 [c00000001d98fe10] [c00000000000cd54] ret_from_kernel_thread+0x5c/0x64 Allocated by task 0: kasan_save_stack+0x34/0x70 __kasan_kmalloc+0xb4/0xf0
    __kmalloc+0x268/0x540 xive_spapr_init+0x4d0/0x77c pseries_init_irq+0x40/0x27c init_IRQ+0x44/0x84 start_kernel+0x2a4/0x538 start_here_common+0x1c/0x20 该缺陷地址所属的对象位于 c00000001d1d0118， 属于大小为 8 的缓存 kmalloc-8 该缺陷地址位于 8 字节区域内的 0 个字节 [c00000001d1d0118, c00000001d1d0120) 该缺陷地址所属的实体页面为：page:c00c000000074740 refcount:1 mapcount:0 mapping:0000000000000000 index:0xc00000001d1d0558 pfn:0x1d1d flags: 0x7ffff000000200(slab|node=0|zone=0|lastcpupid=0x7ffff) raw: 007ffff000000200 c00000001d0003c8 c00000001d0003c8 c00000001d010480 raw: c00000001d1d0558 0000000001e1000a 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address:
    c00000001d1d0000： fc 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc c00000001d1d0080： fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >c00000001d1d0100： fc fc fc fc fc fc 02 fc fc fc fc fc ^ c00000001d1d0180： fc fc fc fc 04 fc fc fc fc fc fc fc fc fc fc fc c00000001d1d0200： fc fc fc fc fc 04 fc fc fc fc fc fc fc fc fc fc 出现这种情况是因为使用了错误的分配单位（位），而不是通过 (BITS_TO_LONGS(count) * sizeof(long)) 或同等条件。对于少量位，分配的对象可能小于 sizeof(long)，从而导致无效访问。使用 bitmap_zalloc() 分配和初始化 irq 位图，与 bitmap_free() 配对使用以确保一致性。 (CVE-2022-49623)

  - 在 Linux 内核中，已解决以下漏洞：soc: qcom: cmd-db: 将共享内存映射为 WC，而非 WB。Linux 不写入 cmd-db 区域。此内存区域受到 XPU 的写入保护。
    XPU 有时误将干净缓存清理检测为写入受保护区域，导致安全中断，从而在信任区中的某处出现死循环。XPU 现在正常工作的唯一原因是 Qualcomm Hypervisor 将相同的区域映射为 Stage 2 转换表中的 Non-Cacheable 内存。如使用对此类特定映射一无所知的其他管理程序（如 Xen 或 KVM），则会出现此问题。将 cmd-db 内存的映射从 MEMREMAP_WB 更改为 MEMREMAP_WT/WC 可移除对 Stage 2 表中正确映射的依赖关系。此修补程序通过更新映射到 MEMREMAP_WC 来修复该问题。我在 SA8155P 上使用 Xen 进行了测试。 (CVE-2024-46689)

  - 在 Linux 内核中，已解决以下漏洞：io_uring: 检查溢出刷新期间是否需要重新计划。通常，此列表为空或仅包含少量条目。如应用程序的确发生了溢出，此列表也会产生部分条目。但是，像 syzbot 这样的模糊测试工具会生成大量的溢出条目，导致刷新过程需要很长时间。在刷新时检查是否需要重新安排，并在必要时解锁。
    由于溢出总是从列表头部删除，因此不需要维护复杂的状态，从而可以安全地在每次循环迭代结束时暂时释放并重新获取锁。(CVE-2024-50060)

  - 在 Linux 内核中，已解决以下漏洞：io_uring/rw：修复 O_DIRECT 开始写入所缺少的 NOWAIT 检查。当 io_uring 启动写入时，会调用 kiocb_start_write() 函数来获取超级块的读写信号量，从而防止文件系统在写入过程中冻结。然而，冻结进程将读写信号量置于写入模式，阻止新的写入开始并等待正在进行的写入完成。但是 io_uring 总是调用 kiocb_start_write() 函数，从而在冻结进程已经运行的情况下导致该函数阻塞的问题。该问题会进一步造成死锁，即冻结进程正在等待写入完成，但是写入无法完成，因为调用的函数一直处于阻塞状态。最终导致以下进程卡住，使其在尝试启动新的写入时受到阻止：task:fio state:D stack:0 pid:886 tgid:886 ppid:876 调用跟踪：__switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_rwsem_wait+0x1e8/0x3f8
    __percpu_down_read+0xe8/0x500 io_write+0xbb8/0xff8 io_issue_sqe+0x10c/0x1020 io_submit_sqes+0x614/0x2110
    __arm64_sys_io_uring_enter+0x524/0x1038 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 INFO:
    任务 fsfreeze:7364 阻断超过 15 秒。Not tainted 6.12.0-rc5-00063-g76aaf945701c #7963 with the attempting freezer stuck trying to grab the rwsem: task:fsfreeze state:D stack:0 pid:7364 tgid:7364 ppid:995 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_down_write+0x2b0/0x680 freeze_super+0x248/0x8a8 do_vfs_ioctl+0x149c/0x1b18
    __arm64_sys_ioctl+0xd0/0x1a0 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 使 io_uring 遵循 IOCB_NOWAIT 标志进行修复，且在设置标志时避免阻塞锁，如果未设置标志，则允许获取阻塞锁。对于始终设置 IOCB_NOWAIT 的正常问题，此函数返回 -EAGAIN，会使 io_uring 核心发出阻断的写入尝试。这反过来也会让完成运行，确保转发进度。由于冻结首先需要 CAP_SYS_ADMIN，因此普通用户无法触发。 (CVE-2024-53052)

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

远程 CentOS Linux 9 主机上安装的多个程序包受到 libxml2-2.9.13-9.el9 版本变更日志中提及的一个漏洞影响。

  - 对于 2.12.10 之前的 libxml2 和 2.13.6 之前的 2.13.x，valid.c 中的 xmlSnprintfElements 存在基于堆栈的缓冲区溢出。要利用此问题，必须对不受信任的文档或不受信任的 DTD 进行 DTD 验证。注意:
    此问题类似于 CVE-2017-9047。(CVE-2025-24928)

请注意，Nessus 尚未测试此问题，而是只依据应用程序自我报告的版本号进行判断。

远程 CentOS Linux 9 主机上安装的一个程序包受到 microcode_ctl-20250211-1.el9 版本变更日志中提及的多个漏洞影响。

  - 某些 Intel(R) 处理器的 UEFI 固件中存在不正确的输入验证，可能允许特权用户通过本地访问实现特权升级。 (CVE-2023-43758)

  - 某些 Intel(R) 处理器的 UEFI 固件中存在不正确的输入验证，可能允许特权用户通过本地访问实现特权升级。 (CVE-2023-34440、CVE-2024-28127)

  - 某些 Intel(R) 处理器的 UEFI 固件的 XmlCli 功能中存在不正确的输入验证，可能允许特权用户通过本地访问实现特权升级。 (CVE-2024-24582)

  - 某些 Intel(R) 处理器的 UEFI 固件中存在输入验证不当的情况，可能允许特权用户通过本地访问权泄漏信息。(CVE-2024-28047)

  - 某些 Intel(R) 处理器的 UEFI 固件 CseVariableStorageSmm 中存在不正确的输入验证，可能允许特权用户通过本地访问实现特权升级。 (CVE-2024-29214)

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

远程 CentOS Linux 9 主机上安装的多个程序包受到 openssh-8.7p1-45.el9 版本变更日志中提及的一个漏洞影响。

  - 启用 VerifyHostKeyDNS 选项时，在 OpenSSH 中发现漏洞。恶意计算机可通过冒充合法服务器执行中间机攻击。发生此问题的原因是 OpenSSH 在验证主机密钥时，会在特定情况下错误处理错误代码。要使攻击成功，攻击者需要先耗尽客户端的内存资源，这使得此攻击的复杂性变高。(CVE-2025-26465)

请注意，Nessus 尚未测试此问题，而是只依据应用程序自我报告的版本号进行判断。

远程 CentOS Linux 9 主机上安装的多个程序包受到 gcc-11.5.0-5.el9 版本变更日志中提及的一个漏洞影响。

  - 在高于或等于 1.0.3 版以及 3.5.0 版之前的 jQuery 中，如果将包含 <option> 元素的 HTML 从不受信任的来源传递至 jQuery 的任一 DOM 操作方法（即 .html()、append() 和其他方法），即使经过审查，也可能执行不受信任的代码。已在 jQuery 3.5.0 中修补此问题。
    (CVE-2020-11023)

请注意，Nessus 尚未测试此问题，而是只依据应用程序自我报告的版本号进行判断。

远程 CentOS Linux 9 主机上安装的多个程序包受到 kernel-5.14.0-565.el9 版本变更日志中提及的多个漏洞影响。

  - 在 Linux 内核中，以下漏洞已得到解决：Bluetooth: btmtk：避免 btmtk_process_coredump 中的 UAF hci_devcd_append 可能会导致 skb 的释放，因此在调用后无法对其进行访问。 ================================================== ================ 缺陷：KASAN: btmtk_process_coredump+0x2a7/0x2d0 中的 slab-use-after-free [btmtk] 任务 kworker/0:3/82 读取位于地址 ffff888033cfabb0 的大小为 4 的数据 CPU：0 PID：82 Comm：kworker/0:3 已受污染：G U 6.6.40-lockdep-03464-g1d8b4eb3060e #1 b0b3c1cc0c842735643fb411799d97921d1f688c 硬件名称：Google Yaviks_Ufs/Yaviks_Ufs，BIOS Google_Yaviks_Ufs.15217.552.0 05/07/2024 工作队列：events btusb_rx_work [btusb] 调用追踪：<TASK> dump_stack_lvl+0xfd/0x150 print_report+0x131/0x780 kasan_report+0x177/0x1c0 btmtk_process_coredump+0x2a7/0x2d0 [btmtk 03edd567dd71a65958807c95a65db31d433e1d01] btusb_recv_acl_mtk+0x11c/0x1a0 [btusb 675430d1e87c4f24d0c1f80efe600757a0f32bec] btusb_rx_work+0x9e/0xe0 [btusb 675430d1e87c4f24d0c1f80efe600757a0f32bec] worker_thread+0xe44/0x2cc0 kthread+0x2ff/0x3a0 ret_from_fork+0x51/0x80 ret_from_fork_asm+0x1b/0x30 </TASK> 由任务 82 分配：
    stack_trace_save+0xdc/0x190 kasan_set_track+0x4e/0x80 __kasan_slab_alloc+0x4e/0x60 kmem_cache_alloc+0x19f/0x360 skb_clone+0x132/0xf70 btusb_recv_acl_mtk+0x104/0x1a0 [btusb] btusb_rx_work+0x9e/0xe0 [btusb] worker_thread+0xe44/0x2cc0 kthread+0x2ff/ 0x3a0 ret_from_fork+0x51/0x80 ret_from_fork_asm+0x1b/0x30 Freed by task 1733: stack_trace_save+0xdc/0x190 kasan_set_track+0x4e/0x80 kasan_save_free_info+0x28/0xb0 ____kasan_slab_free+0xfd/0x170 kmem_cache_free+0x183/0x3f0 hci_devcd_rx+0x91a/0x2060 [bluetooth] worker_thread +0xe44/0x2cc0 kthread+0x2ff/0x3a0 ret_from_fork+0x51/0x80 ret_from_fork_asm+0x1b/0x30 有缺陷的地址属于 ffff888033cfab40 处的对象，该对象属于大小为 232 的缓存 skbuff_head_cache。有缺陷的地址位于已释放的 232 字节区域内 112 字节处 [ffff888033cfab40, ffff888033cfac28) 有缺陷的地址属于以下物理页面：page:00000000a174ba93 refcount:1 mapcount:0 mapping:000000000000000 index:0x0 pfn:0x33cfa head:00000000a174ba93 order:1e ntire_mapcount:0 nr_pages_mapped:0 pincount:0 anon flags:
    0x4000000000000840(slab|head|zone=1) page_type: 0xffffffff() raw: 4000000000000840 ffff888100848a00 0000000000000000 0000000000000001 raw: 0000000000000000 0000000080190019 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888033cfaa80:
    fb fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc ffff888033cfab00: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb >ffff888033cfab80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888033cfac00： fb fb fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc ffff888033cfac80： fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ========== ================================================== ====== 检查在调用 hci_devcd_append 之前是否需要调用 hci_devcd_complete。这要求我们检查 data->cd_info.cnt >= MTK_COREDUMP_NUM 而不是 data->cd_info.cnt > MTK_COREDUMP_NUM，因为我们仅在对 hci_devcd_append 的调用成功后才会增加 data->cd_info.cnt。(CVE-2024-56653)

  - 在 Linux 内核中，解决了以下漏洞：Bluetooth: MGMT：修复 set_powered_sync 中的 slab-use-after-free 读取 这修复了以下崩溃情况：
    ================================================================== 缺陷：KASAN：set_powered_sync+0x3a/0xc0 net/bluetooth/mgmt.c:1353 中的 slab-use-after-free 任务 kworker/u9:0/54 读取位于地址 ffff888029b4dd18 的大小为 8 的数据 CPU：1 UID：0 PID：54 Comm：kworker/u9:0 Not tainted 6.11.0-rc6-syzkaller-01155-gf723224742fc #0 硬件名称：Google Google Compute Engine/Google Compute Engine，BIOS Google 08/06/2024 工作队列：hci0 hci_cmd_sync_work 调用跟踪：<TASK> __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 q kasan_report+0x143/0x180 mm/kasan/report.c:601 set_powered_sync+0x3a/0xc0 net/bluetooth/mgmt.c:1353 hci_cmd_sync_work+0x22b/0x400 net/bluetooth/hci_sync.c:328 process_one_work kernel/workqueue.c:3231 [inline] process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312 worker_thread+0x86d/0xd10 kernel/workqueue.c:3389 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK> 由任务 5247 分配：kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:370 [inline] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387 kasan_kmalloc include/linux/kasan.h:211 [inline] __kmalloc_cache_noprof+0x19c/0x2c0 mm/slub.c:4193 kmalloc_noprof include/linux/slab.h:681 [inline] kzalloc_noprof include/linux/slab.h:807 [inline] mgmt_pending_new+0x65/0x250 net/bluetooth/mgmt_util.c:269 mgmt_pending_add+0x36/0x120 net/bluetooth/mgmt_util.c:296 set_powered+0x3cd/0x5e0 net/bluetooth/mgmt.c:1394 hci_mgmt_cmd+0xc47/0x11d0 net/bluetooth/hci_sock.c:1712 hci_sock_sendmsg+0x7b8/0x11c0 net/bluetooth/hci_sock.c:1832 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:745 sock_write_iter+0x2dd/0x400 net/socket.c:1160 new_sync_write fs/read_write.c:497 [inline] vfs_write+0xa72/0xc90 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+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 5246: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object+0xe0/0x150 mm/kasan/common.c:240 __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2256 [inline] slab_free mm/slub.c:4477 [inline] kfree+0x149/0x360 mm/slub.c:4598 settings_rsp+0x2bc/0x390 net/bluetooth/mgmt.c:1443 mgmt_pending_foreach+0xd1/0x130 net/bluetooth/mgmt_util.c:259
    __mgmt_power_off+0x112/0x420 net/bluetooth/mgmt.c:9455 hci_dev_close_sync+0x665/0x11a0 net/bluetooth/hci_sync.c:5191 hci_dev_do_close net/bluetooth/hci_core.c:483 [inline] hci_dev_close+0x112/0x210 net/bluetooth/hci_core.c:508 sock_do_ioctl+0x158/0x460 net/socket.c:1222 sock_ioctl+0x629/0x8e0 net/socket.c:1341 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83gv entry_SYSCALL_64_after_hwframe+0x77/0x7f (CVE-2024-53208)

  - 在 Linux 内核中，解决了以下漏洞：Bluetooth：修复 device_for_each_child() 中的 use-after-free 问题 Syzbot 报告了以下 KASAN 事件：缺陷：KASAN：device_for_each_child+0x18f/0x1a0 中的 slab-use-after-free 任务 kbnepd bnep0/4980 读取地址 ffff88801f605308 处的大小为 8 的数据 CPU：0 UID：0 PID：4980 Comm：kbnepd bnep0 Not tainted 6.12.0-rc4-00161-gae90f6a6170d #1 硬件名称：QEMU Standard PC (i440FX + PIIX, 1996)，BIOS 1.16.3-2.fc40 04/01/2014 调用跟踪：<TASK> dump_stack_lvl+0x100/0x190 ? device_for_each_child+0x18f/0x1a0 print_report+0x13a/0x4cb ?
    __virt_addr_valid+0x5e/0x590 ? __phys_addr+0xc6/0x150 ? device_for_each_child+0x18f/0x1a0 kasan_report+0xda/0x110 ? device_for_each_child+0x18f/0x1a0 ? __pfx_dev_memalloc_noio+0x10/0x10 device_for_each_child+0x18f/0x1a0 ? __pfx_device_for_each_child+0x10/0x10 pm_runtime_set_memalloc_noio+0xf2/0x180 netdev_unregister_kobject+0x1ed/0x270 unregister_netdevice_many_notify+0x123c/0x1d80 ? __mutex_trylock_common+0xde/0x250 ?
    __pfx_unregister_netdevice_many_notify+0x10/0x10 ? trace_contention_end+0xe6/0x140 ?
    __mutex_lock+0x4e7/0x8f0 ? __pfx_lock_acquire.part.0+0x10/0x10 ? rcu_is_watching+0x12/0xc0 ? unregister_netdev+0x12/0x30 unregister_netdevice_queue+0x30d/0x3f0 ?
    __pfx_unregister_netdevice_queue+0x10/0x10 ? __pfx_down_write+0x10/0x10 unregister_netdev+0x1c/0x30 bnep_session+0x1fb3/0x2ab0 ? __pfx_bnep_session+0x10/0x10 ? __pfx_lock_release+0x10/0x10 ?
    __pfx_woken_wake_function+0x10/0x10 ? __kthread_parkme+0x132/0x200 ? __pfx_bnep_session+0x10/0x10 ? kthread+0x13a/0x370 ? __pfx_bnep_session+0x10/0x10 kthread+0x2b7/0x370 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x48/0x80 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> 由任务 4974 分配：kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0
    __kmalloc_noprof+0x1d1/0x440 hci_alloc_dev_priv+0x1d/0x2820 __vhci_create_device+0xef/0x7d0 vhci_write+0x2c7/0x480 vfs_write+0x6a0/0xfc0 ksys_write+0x12f/0x260 do_syscall_64+0xc7/0x250 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 4979: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x4f/0x70 kfree+0x141/0x490 hci_release_dev+0x4d9/0x600 bt_host_release+0x6a/0xb0 device_release+0xa4/0x240 kobject_put+0x1ec/0x5a0 put_device+0x1f/0x30 vhci_release+0x81/0xf0 __fput+0x3f6/0xb30 task_work_run+0x151/0x250 do_exit+0xa79/0x2c30 do_group_exit+0xd5/0x2a0 get_signal+0x1fcd/0x2210 arch_do_signal_or_restart+0x93/0x780 syscall_exit_to_user_mode+0x140/0x290 do_syscall_64+0xd4/0x250 entry_SYSCALL_64_after_hwframe+0x77/0x7f 在“hci_conn_del_sysfs()”中，当底层 (kobject) 引用计数器大于 1 时，可能会调用“device_unregister()”。这意味着重定父级（在设备实际释放时发生）被延迟，并且在此延迟期间，父级控制器设备 (hciX) 可能会被删除。由于后者可能会创建指向已释放父项的悬摆指针，因此请通过明确将父级重定为 NULL 来避免这种情况。(CVE-2024-53237)

  - 在 Linux 内核中，以下漏洞已得到解决：Bluetooth: iso：始终在 iso_listen_bis 结束时释放 hdev 由于 hci_get_route 在返回之前会保留设备，因此即使函数返回错误，也应在 iso_listen_bis 结束时使用 hci_dev_put 释放 hdev。
    (CVE-2024-57879)

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

远程 CentOS Linux 9 主机上安装的多个程序包受到 kernel-kernel-5.14.0-559.el9 版本变更日志中提及的多个漏洞影响。

  - 解决了 Linux 内核中的以下漏洞：iommu/vt-d：禁用 ATS 前删除缓存标签。当前实现会在禁用 ATS 后删除缓存标签，从而可能导致内存流失和内核崩溃问题。具体而言，即使在释放域之后，CACHE_TAG_DEVTLB 类型的缓存标签可能仍保留在列表中，从而导致释放后使用条件。当来自不同 PF 的多个 VF 通过 vfio-pci 传递到单个用户空间进程时，确实会出现此问题。在此类情况下，内核可能会崩溃并出现如下内核消息：BUG: kernel NULL pointer dereference, address:
    0000000000000014 PGD 19036a067 P4D 1940a3067 PUD 136c9b067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 74 UID: 0 PID: 3183 Comm: testCli Not tainted 6.11.9 #2 RIP: 0010:cache_tag_flush_range+0x9b/0x250 Call Trace: <TASK> ? __die+0x1f/0x60 ? page_fault_oops+0x163/0x590 ? exc_page_fault+0x72/0x190 ? asm_exc_page_fault+0x22/0x30 ? cache_tag_flush_range+0x9b/0x250 ? cache_tag_flush_range+0x5d/0x250 intel_iommu_tlb_sync+0x29/0x40 intel_iommu_unmap_pages+0xfe/0x160 __iommu_unmap+0xd8/0x1a0 vfio_unmap_unpin+0x182/0x340 [vfio_iommu_type1] vfio_remove_dma+0x2a/0xb0 [vfio_iommu_type1] vfio_iommu_type1_ioctl+0xafa/0x18e0 [vfio_iommu_type1] 在 iommu_disable_pci_caps() 之前移动 cache_tag_unassign_domain() 以修复此问题。(CVE-2024-56669)

  - 解决了 Linux 内核中的以下漏洞：erofs：修复了 UP 平台上的 pcluster 释放后使用问题 在 CONFIG_SMP 禁用的情况下进行压力测试期间，KASAN 报告如下：
    ================================================================== BUG: KASAN: use-after-free in
    __mutex_lock+0xe5/0xc30 Read of size 8 at addr ffff8881094223f8 by task stress/7789 CPU: 0 PID: 7789 Comm:
    stress Not tainted 6.0.0-rc1-00002-g0d53d2e882f9 #3 Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 Call Trace: <TASK> .. __mutex_lock+0xe5/0xc30 .. z_erofs_do_read_page+0x8ce/0x1560 ..
    z_erofs_readahead+0x31c/0x580 .. Freed by task 7787 kasan_save_stack+0x1e/0x40 kasan_set_track+0x20/0x30 kasan_set_free_info+0x20/0x40 __kasan_slab_free+0x10c/0x190 kmem_cache_free+0xed/0x380 rcu_core+0x3d5/0xc90 __do_softirq+0x12d/0x389 Last potentially related work creation:
    kasan_save_stack+0x1e/0x40 __kasan_record_aux_stack+0x97/0xb0 call_rcu+0x3d/0x3f0 erofs_shrink_workstation+0x11f/0x210 erofs_shrink_scan+0xdc/0x170 shrink_slab.constprop.0+0x296/0x530 drop_slab+0x1c/0x70 drop_caches_sysctl_handler+0x70/0x80 proc_sys_call_handler+0x20a/0x2f0 vfs_write+0x555/0x6c0 ksys_write+0xbe/0x160 do_syscall_64+0x3b/0x90 根本原因是 erofs_workgroup_unfreeze() 未重置为 orig_val，因而造成争用条件，pcluster 在释放前意外重复使用了该争用条件。由于 UP 平台现在相当罕见，因此不必使用此路径。我们可以直接弃用此类特别设计的路径。(CVE-2022-48674)

  - 解决了 Linux 内核中的以下漏洞：erofs：修复 LZMA 全局压缩重复数据时的内存流失问题。在新的全局压缩重复数据功能启用 (`-Ededupe`) 的情况下压缩 microLZMA EROFS 图片时，我发现有些短期有效的暂存页面未被正确释放，这会在数小时后逐渐造成意外的内存溢出问题。我们现在就来修复此问题（LZ4 和 DEFLATE 没有此问题）。(CVE-2023-52526)

  - 解决了 Linux 内核中的以下漏洞：iommu/s390：实施阻止域 这修复了意外热拔出 PCI 设备时会发生崩溃的问题。造成崩溃的原因是，在热插拔期间，
    由于设备已移除，平台不再识别该设备，因而附加默认域的 __iommu_group_set_domain_nofail() 会失败，并最终造成域指针为空和 UAF。
    这完全是 __iommu_device_set_domain() 的第二条注释中提及的情况，正如该处所述，如果我们能够改为附加阻止域，就可以防止 UAF 问题，因为这可以处理已移除的设备。实施阻止域以使用此处理方式。我们已经通过此更改修复崩溃问题，但在尝试更改被阻止设备上的 DMA 所有权时仍遇到警告。(CVE-2024-53232)

  - 解决了 Linux 内核中的以下漏洞：i3c：master：Fix miss free init_dyn_addr at i3c_master_put_i3c_addrs() if (dev->boardinfo && dev->boardinfo->init_dyn_addr) ^^^ here check init_dyn_addr i3c_bus_set_addr_slot_status(&master->bus, dev->info.dyn_addr, ...) ^^^^ free dyn_addr Fix copy/paste error dyn_addr by replacing it with init_dyn_addr。 (CVE-2024-56562)

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

远程 CentOS Linux 9 主机上安装的多个程序包受到 kernel-5.14.0-554.el9 版本变更日志中提及的多个漏洞影响。

  - 在 Linux 内核中，解决了下列漏洞：ALSA：asihpi：修复潜在的 OOB 数组访问 ASIHPI 驱动程序在收到驱动程序的响应时，将一些值存储在静态数组中，其索引取决于固件。我们不应盲目信任它。此修补程序添加数组索引的健全性检查以适合数组大小。(CVE-2024-50007)

  - 在 Linux 内核中解决了以下漏洞：ALSA：hda：cs35l41：cs35l41_hda_unbind() 中可能存在的空指针取消引用漏洞 cs35l41_hda_unbind() 函数会清除与其索引匹配的 hda_component 条目，然后取消引用 hda_component 数组第一个元素中保留的编解码器指针，当设备索引为 0 时便会出现此问题。请改用隐藏在 cs35l41_hda 结构中的编解码器指针，因为它仍然有效。(CVE-2024-40964)

  - 在 Linux 内核中，解决了以下漏洞：ASoC：SOF：Intel：hda：修复了系统暂停条目上的空取消引用当系统因活动流进入暂停状态时，SOF 核心调用 hw_params_upon_resume()。在以 HDA DMA 管理 link DMA 的 Intel 平台上，这会导致首先运行调用链 hda_dsp_set_hw_params_upon_resume() -> hda_dsp_dais_suspend() -> hda_dai_suspend() -> hda_ipc4_post_trigger()，而这会清除 hext_stream->link_substream，然后使用空 snd_pcm_substream 指针调用 hda_ipc4_post_trigger()。(CVE-2024-41037)

  - 在 Linux 内核中，解决了以下漏洞：ASoC：topology：修复对已释放内存的引用 大多数用户在解析拓扑文件后，会释放其所使用的内存，因此将指针引用直接指向拓扑文件内容是错误操作。使用 devm_kmemdup() 根据需要分配内存。(CVE-2024-41069)

  - 在 Linux 内核中，解决了以下漏洞：ASoC：amd： acp：为 chip_pdev 结构添加空检查 跳过 acp 平台设备创建时，chip->chip_pdev 值将保持为空。
    为 snd_acp_resume() 函数中的 chip->chip_pdev 结构添加 NULL 检查，以避免空指针取消引用。(CVE-2024-42074)

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

远程 CentOS Linux 9 主机上安装的一个程序包受到 microcode_ctl-20241112-1.el9 版本变更日志中提及的多个漏洞影响。

  - 使用 Intel(R) SGX 时，某些 Intel(R) Xeon(R) 处理器的内存控制器配置中存在不正确的条件检查，这可能允许特权用户通过本地访问实现特权提升。
    (CVE-2024-23918)

  - 使用 Intel(R) SGX 时，某些 Intel(R) Xeon(R) 处理器的内存控制器配置中存在不正确的默认权限，这可能允许特权用户通过本地访问实现特权提升。(CVE-2024-21820)

  - 某些第 4 代和第 5 代 Intel(R) Xeon(R) 处理器的硬件逻辑中不正确的有限状态机 (FSM) 可能允许授权用户通过本地访问造成拒绝服务。
    (CVE-2024-21853)

  - 某些 Intel(R) 处理器的 RAPL 接口中存在可见差异，特权用户可能会利用此差异，通过本地访问造成信息泄露。(CVE-2024-23984)

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

远程 CentOS Linux 9 主机上安装的多个程序包受到 kernel-5.14.0-547.el9 版本变更日志中提及的多个漏洞影响。

  - 在 Linux 内核中，以下漏洞已解决：netfilter：nfnetlink：先将 extack 初始化，然后再在 ACK 中使用 在对 BATCH_BEGIN 和 BATCH_END 做 ACK 处理时，添加缺少的 extack 初始化。
    (CVE-2024-44945)

  - 在 Linux 内核中，以下漏洞已解决：net：修复了配置小 gso_max_size/gso_ipv4_max_size 小时发生的崩溃 配置小 gso_max_size/gso_ipv4_max_size 将导致 sk_dst_gso_max_size() 中发生下溢，这可能触发 BUG_ON 崩溃，因为 sk-> sk_gso_max_size 远远大于设备限制。调用跟踪：tcp_write_xmit tso_segs = tcp_init_tso_segs(skb, mss_now);
    tcp_set_skb_tso_segs tcp_skb_pcount_set // skb->len = 524288, mss_now = 8 // u16 tso_segs = 524288/8 = 65535 -> 0 tso_segs = DIV_ROUND_UP(skb->len, mss_now) BUG_ON(!tso_segs) 添加对 gso_max_size 和 gso_ipv4_max_size 最小值的检查。(CVE-2024-50258)

  - 在 Linux 内核中，以下漏洞已解决：mm：解决有错误的 mmap_region() 错误路径行为 mmap_region() 函数有些可怕，由于有错综复杂的控制流和许多可能导致问题的方法，因而可能导致出现状态不完整、内存泄漏和其他不愉快的情况。大量的复杂性源于在映射 VMA 的过程中尝试延迟处理错误，这构成了最近发现的资源泄漏和可观察到的不一致状态问题的基础。利用本系列中之前的补丁，我们将大量检查工作前移至代码阶段，通过将核心逻辑移至静态内部函数 __mmap_region() 来简化操作。如此一来，我们不仅可以在进行任何实际工作之前预先执行多项检查，还可以根据需要无条件展开可写 unmap 检查，以及无条件执行 CONFIG_DEBUG_VM_MAPLE_TREE 验证。我们将多项操作移至此处：1. 在调用文件支持的内存挂钩之前，已经为迭代器预分配了内存，这样我们就可以提前退出，避免执行复杂且容易出错的关闭/释放逻辑。我们谨慎释放成功和错误路径上的迭代器状态。2. 封闭的 mmap_region() 函数会提早处理 mapping_map_writable() 逻辑。以前，针对映射新分配的文件支持的 VMA，逻辑会使用 mapping_map_writable()；针对成功和错误路径，则使用匹配的 mapping_unmap_writable()。如果是文件支持的共享可写映射，我们现在将无条件执行此操作。如果驱动程序更改标记以删除 VM_MAYWRITE，但这样做不会使我们刚执行的密封检查失效，并且我们在任何情况下都始终会减少封装程序中的计数器。我们执行调试断言以确保驱动程序不会尝试执行相反操作。
    3. 我们还将 arch_validate_flags() 上移到 mmap_region() 函数中。这仅与 arm64 和 sparc64 有关，该检查仅对已启用 ADI 的 SPARC 有意义。如果驱动程序使此检查无效，我们会明确添加针对此 arch 的警告，不过代码最终应该会得到修复，以消除这种需求。采取所有这些措施后，我们不再需要明确关闭错误路径中的 VMA，因为我们在调用任何驱动程序 mmap 挂钩之前已设置各项可能失败的检查。这样可以消除一整类错误，让代码更易于推理并且更可靠。
    (CVE-2024-53096)

  - 在 Linux 内核中，以下漏洞已解决：media：uvcvideo：对 uvc_parse_format 中类型为 UVC_VS_UNDEFINED 的帧跳过解析 这可导致越界写入，因为在计算 uvc_parse_streaming 中的帧缓冲区的大小时，此类型的帧不在考虑范围内。
    (CVE-2024-53104)

  - 在 Linux 内核中，以下漏洞已解决：mm：修复 alloc_pages_bulk_noprof 中的空指针取消引用 当任务在 cpuset 之间迁移时，我们为 alloc_pages_bulk_noprof() 中的 ac.preferred_zoneref->zone 触发了空指针取消引用。当启用 cpuset 时，在 prepare_alloc_pages() 中，ac->nodemask 可能是 t->mems_allowed。调用 first_zones_zonelist() 以查找 preferred_zoneref 时，如果任务在不同 cpuset 之间迁移，ac->nodemask 也会被同时修改。假设我们有 2 个 NUMA 节点，在遍历 ac->zonelist 中的 Node1 时，节点掩码为 2；在遍历 ac->zonelist 中的 Node2 时，节点掩码为 1。因此，ac->preferred_zoneref 会指向空区域。在 alloc_pages_bulk_noprof() 中，for_each_zone_zonelist_nodemask() 会查找可允许的区域并调用 zonelist_node_idx(ac.preferred_zoneref)，从而导致空指针取消引用。
    __alloc_pages_noprof() 会检查提交 ea57485af8f4（mm，page_alloc：
    修复对空 preferred_zone 的检查）和提交 df76cee6bbeb（mm，page_alloc：移除 alloc 快速路径中的冗余检查）中是否存在空指针，以修复此问题。要修复此问题，请检查 preferred_zoneref->zone 中是否存在空指针。(CVE-2024-53113)

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

远程 CentOS Linux 9 主机上安装的多个程序包受到 kernel-5.14.0-542.el9 版本变更日志中提及的多个漏洞影响。

  - Linux 内核中的以下漏洞已得到修复：nfsd：使用 nfs4_state_shutdown_net 中的同步模式取消 nfsd_shrinker_work 。一般情况下，当我们执行 `echo 0 > /proc/fs/nfsd/threads` 时， `nfs4_state_shutdown_net` 中的 `nfs4_state_destroy_net` 函数将释放与哈希 `nfs4_client` 相关的所有资源。如果 “nfsd_client_shrinker” 处于并发运行，“expire_client” 函数将首先反哈希此客户端并将其破坏。由此可能出现以下警告。
    此外，也可能会发生大量释放后使用的错误。 nfsd_client_shrinker echo 0 > /proc/fs/nfsd/threads expire_client nfsd_shutdown_net unhash_client ... nfs4_state_shutdown_net /* won't wait shrinker exit */ /* cancel_work(&nn->nfsd_shrinker_work) * nfsd_file for this /* won't destroy unhashed client1 */ * client1 still alive nfs4_state_destroy_net */ nfsd_file_cache_shutdown /* trigger warning */ kmem_cache_destroy(nfsd_file_slab) kmem_cache_destroy(nfsd_file_mark_slab) /* release nfsd_file and mark */ __destroy_client ==================================================================== BUG nfsd_file (Not tainted): Objects remaining in nfsd_file on __kmem_cache_shutdown()
    -------------------------------------------------------------------- CPU: 4 UID: 0 PID: 764 Comm: sh Not tainted 6.12.0-rc3+  #1 dump_stack_lvl+0x53/0x70 slab_err+0xb0/0xf0 __kmem_cache_shutdown+0x15c/0x310 kmem_cache_destroy+0x66/0x160 nfsd_file_cache_shutdown+0xac/0x210 [nfsd] nfsd_destroy_serv+0x251/0x2a0 [nfsd] nfsd_svc+0x125/0x1e0 [nfsd] write_threads+0x16a/0x2a0 [nfsd] nfsctl_transaction_write+0x74/0xa0 [nfsd] vfs_write+0x1a5/0x6d0 ksys_write+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e ==================================================================== BUG nfsd_file_mark (Tainted: G B W ):
    Objects remaining nfsd_file_mark on __kmem_cache_shutdown()
    -------------------------------------------------------------------- dump_stack_lvl+0x53/0x70 slab_err+0xb0/0xf0 __kmem_cache_shutdown+0x15c/0x310 kmem_cache_destroy+0x66/0x160 nfsd_file_cache_shutdown+0xc8/0x210 [nfsd] nfsd_destroy_serv+0x251/0x2a0 [nfsd] nfsd_svc+0x125/0x1e0 [nfsd] write_threads+0x16a/0x2a0 [nfsd] nfsctl_transaction_write+0x74/0xa0 [nfsd] vfs_write+0x1a5/0x6d0 ksys_write+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e To resolve this issue, cancel `nfsd_shrinker_work` using synchronous mode in nfs4_state_shutdown_net. (CVE-2024-50121)

  - Linux 内核中的以下漏洞已得到修复：fscache：修复因 cookie_lru 和 use_cookie 的争用而导致的错误。如果 LRU 的 cookie 过期并且设置了 LRU_DISCARD 标记，但是状态机尚未运行，可能是因为另一个线程可调用 fscache_use_cookie 并开始使用的原因。
    当 cookie_worker 最终运行时，其会发现 LRU_DISCARD 标记已设置，并将 cookie->state 转换为 LRU_DISCARDING，然后 LRU_DISCARDING 会撤回 cookie。在 cookie 撤回后，对象会被移除，并因为与 cookie 关联的对象现在为 NULL 而出现且以下错误。如果另一线程在 cookie_worker 运行之前使用 cookie，则通过清除 LRU_DISCARD 位来修复错误。BUG: kernel NULL pointer dereference, address: 0000000000000008 ... CPU: 31 PID: 44773 Comm: kworker/u130:1 Tainted: G E 6.0.0-5.dneg.x86_64 #1 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 08/26/2022 Workqueue: events_unbound netfs_rreq_write_to_cache_work [netfs] RIP:
    0010:cachefiles_prepare_write+0x28/0x90 [cachefiles] ... 调用跟踪：
    netfs_rreq_write_to_cache_work+0x11c/0x320 [netfs] process_one_work+0x217/0x3e0 worker_thread+0x4a/0x3b0 kthread+0xd6/0x100 (CVE-2022-48989)

  - Linux 内核中的以下漏洞已得到修复：scsi: aacraid：修复探测失败时的双重释放 aac_probe_one() 通过 aac_driver_ident::init 指针调用硬件特定的 init 函数，所有这些函数最终会调用 aac_init_adapter( ）。如果 aac_init_adapter() 在为 aac_dev::queues 分配内存之后失败，内存会被释放，但不会清除该成员。在硬件特定的 init 函数返回错误后，aac_probe_one() 进入错误路径，释放 aac_dev::queues 指向的内存，导致双重释放。 (CVE-2024-46673)

  - Linux 内核中的以下漏洞已得到修复：cachefiles：修复 cachefiles_open_file() 中的 dentry 泄漏并发查找 cookie 和挑选时可能导致 dentry 泄漏：P1 | P2
    ----------------------------------------------------------- cachefiles_lookup_cookie cachefiles_look_up_object lookup_one_positive_unlocked // get dentry cachefiles_cull inode->i_flags |= S_KERNEL_FILE; cachefiles_open_file cachefiles_mark_inode_in_use __cachefiles_mark_inode_in_use can_use = false if (!(inode->i_flags & S_KERNEL_FILE)) can_use = true return false return false // 返回错误，但不会放置 dentry 之后，当卸载后端文件夹时，将触发以下警告： ================================================================== BUG: Dentry 000000008ad87947{i=7a,n=Dx_1_1.img} still in use (1) [unmount of ext4 sda] WARNING: CPU: 4 PID: 359261 at fs/dcache.c:1767 umount_check+0x5d/0x70 CPU: 4 PID: 359261 Comm: umount Not tainted 6.6.0-dirty #25 RIP:
    0010:umount_check+0x5d/0x70 Call Trace: <TASK> d_walk+0xda/0x2b0 do_one_tree+0x20/0x40 shrink_dcache_for_umount+0x2c/0x90 generic_shutdown_super+0x20/0x160 kill_block_super+0x1a/0x40 ext4_kill_sb+0x22/0x40 deactivate_locked_super+0x35/0x80 cleanup_mnt+0x104 /0x160 ================================================ ================== 无论 cachefiles_open_file() 返回 true 或 false，都应释放 cachefiles_look_up_object() 中 lookup_positive_unlocked() 获取的引用计数。因此，释放 cachefiles_look_up_object() 中的引用计数以修复上述问题并简化代码。 (CVE-2024-49870)

  - Linux 内核中的以下漏洞已得到修复：uprobes：修复通过 [uprobes] vma xol_add_vma() 将 __create_xol_area() 分配到用户空间的未初始化页面映射到用户空间的内核信息泄漏。
    在某些架构 (x86) 上，即使没有 VM_READ，此内存也可读取，VM_EXEC 会导致与 VM_EXEC|VM_READ 相同的 pgprot_t，尽管该影响不大，调试程序仍可读取此内存。
    (CVE-2024-49975)

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

远程 CentOS Linux 9 主机上安装的多个程序包受到 kernel-5.14.0-539.el9 版本变更日志中提及的多个漏洞影响。

  - 已解决 Linux 内核中的以下漏洞：ntb：intel：修复 debugfs_create_dir() 的 NULL 和 IS_ERR() 缺陷 debugfs_create_dir() 函数会返回错误指针，从不返回 NULL。因此，使用 IS_ERR() 对其进行检查。(CVE-2023-52917)

  - 解决了 Linux 内核中的以下漏洞：Bluetooth：MGMT：修复处理 mgmt_index_removed 时可能发生崩溃的问题 如果在 cmd_sync 上有命令排队时调用 mgmt_index_removed，可能导致诸如以下跟踪的崩溃问题：0x0000053D：__list_del_entry_valid_or_report+0x98/0xdc 0x0000053D：
    mgmt_pending_remove+0x18/0x58 [蓝牙] 0x0000053E：mgmt_remove_adv_monitor_complete+0x80/0x108 [蓝牙] 0x0000053E：hci_cmd_sync_work+0xbc/0x164 [蓝牙] 因此，在处理 mgmt_index_removed 时，此程序会将命令取消排队，并作为 user_data 传递至 cmd_sync。(CVE-2024-49951)

  - 解决了 Linux 内核中的以下漏洞：sctp：正确验证 sctp_sf_ootb() 中的区块大小。sctp_sf_ootb() 中也需要与 Commit 50619dbf8db7 中相似的大小验证补丁（sctp：遍历区块时添加大小验证），以解决 syzbot 报告的崩溃问题：缺陷：
    KMSAN: uninit-value in sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_do_sm+0x181/0x93d0 net/sctp/sm_sideeffect.c:1166 sctp_endpoint_bh_rcv+0xc38/0xf90 net/sctp/endpointola.c:407 sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88 sctp_rcv+0x3831/0x3b20 net/sctp/input.c:243 sctp4_rcv+0x42/0x50 net/sctp/protocol.c:1159 ip_protocol_deliver_rcu+0xb51/0x13d0 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233 (CVE-2024-50299)

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

远程 CentOS Linux 9 主机上安装的多个程序包受到 kernel-5.14.0-536.el9 版本变更日志中提及的多个漏洞影响。

  - 在 Linux 内核中，解决了下列漏洞：蓝牙：HCI：修复潜在的 null-ptr-deref 修复 hci_le_big_sync_established_evt() 中潜在的 null-ptr-deref。(CVE-2024-36011)

  - 在 Linux 内核中，解决了以下漏洞：蓝牙：L2CAP：修复 l2cap_connect 中的 uaf [Syzbot 报告] 缺陷：KASAN：l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/ 中的 slab-use-after-free-free net/bluetooth/l2cap_core.c:3949 任务 kworker/u9:0/54 对地址 ffff8880241e9800 上的大小 8 的读取 CPU：0 UID：0 PID：54 Comm： kworker/u9:0 未感染 6.11.0-rc6-syzkaller-00268-g788220eee30d #0 硬件名称：
    Google Google Compute Engine/Google Compute Engine、BIOS Google 2024 年 8 月 6 日 Workqueue：hci2 hci_rx_work 调用跟踪： <TASK> __dump_stack lib/dump_stack.c:93 [内联] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:119 print_address_description mm /kasan/report.c:377 [内联] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 l2cap_connect.constprop.0+0x10d8/0x1270 net/ bluetooth/l2cap_core.c:3949 l2cap_connect_req net/bluetooth/l2cap_core.c:4080 [内联] l2cap_bredr_sig_cmd net/bluetooth/l2cap_core.c:4772 [内联] l2cap_sig_channel net/bluetooth/l2cap_core.c:5543 [内联] l2cap_recv_frame+0xf0b/ 0x8eb0 net/bluetooth/l2cap_core.c:6825 l2cap_recv_acldata+0x9b4/0xb70 net/bluetooth/l2cap_core.c:7514 hci_acldata_packet net/bluetooth/hci_core.c:3791 [内联] hci_rx_work+0xaab/0x1610 net/bluetooth/hci_core.c:4028 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [内联] worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 ... 由任务 5245 释放：
    kasan_save_stack+0x33/0x60 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:579 poison_slab_object+0xf7/0x160 mm/kasan /common.c:240
    __kasan_slab_free+0x32/0x50 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [内联] slab_free_hook mm/slub.c:2256 [内联] slab_free mm/slub.c:4477 [内联] kfree +0x12a/0x3b0 mm/slub.c:4598 l2cap_conn_free net/bluetooth/l2cap_core.c:1810 [内联] kref_put include/linux/kref.h:65 [内联] l2cap_conn_put net/bluetooth/l2cap_core.c:1822 [内联] l2cap_conn_del+0x59d/0x730 net/bluetooth/l2cap_core.c:1802 l2cap_connect_cfm+0x9e6/0xf80 net/bluetooth/l2cap_core.c:7241 hci_connect_cfm include/net/bluetooth/hci_core.h:1960 [内联] hci_conn_failed+0x1c3/0x370/0x370 bluetooth/hci_conn.c:1265 hci_abort_conn_sync+0x75a/0xb50 net/bluetooth/hci_sync.c:5583 abort_conn_sync+0x197/0x360 net/bluetooth/hci_conn.c:2917 hci_cmd_sync_work+0x1a4/0x410 net/bluetooth/hci_conn_work3.sync_sync +0x9c5/0x1b40 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [内联] worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0 x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 (CVE-2024-49950)

  - 在 Linux 内核中，解决了以下漏洞：蓝牙：hci_conn：修复 hci_enhanced_setup_sync 中的 UAF 这会检查 ACL 连接是否仍然有效，因为 hci_enhanced_setup_sync 在 cmd_sync 上待定时，连接可能会被破坏，从而导致以下跟踪：缺陷：KASAN：hci_enhanced_setup_sync+0x91b/0xa60 中的 slab-use-after-free 由任务 kworker/u5:2/37 在地址 ffff888002328ffd 读取大小 1 CPU：0 UID：0 PID：37 Comm: kworker/u5:2 未感染 6.11.0-rc6-01300-g810be445d8d6 #7099 硬件名称：QEMU Standard PC (Q35 + ICH9, 2009)，BIOS 1.16.3-2.fc40 2014 年 4 月 1 日 工作队列：hci0 hci_cmd_sync_work 调用跟踪：<TASK> dump_stack_lvl+0x5d/0x80 ? hci_enhanced_setup_sync+0x91b/0xa60 print_report+0x152/0x4c0 ？ hci_enhanced_setup_sync+0x91b/0xa60 ? __virt_addr_valid+0x1fa/0x420 ？ hci_enhanced_setup_sync+0x91b/0xa60 kasan_report+0xda/0x1b0 ？ hci_enhanced_setup_sync+0x91b/0xa60 hci_enhanced_setup_sync+0x91b/0xa60 ? __pfx_hci_enhanced_setup_sync+0x10/0x10 ？
    __pfx___mutex_lock+0x10/0x10 hci_cmd_sync_work+0x1c2/0x330 process_one_work+0x7d9/0x1360 ?
    __pfx_lock_acquire+0x10/0x10 ? __pfx_process_one_work+0x10/0x10 ? assign_work+0x167/0x240 worker_thread+0x5b7/0xf60 ? __kthread_parkme+0xac/0x1c0 ? __pfx_worker_thread+0x10/0x10 ?
    __pfx_worker_thread+0x10/0x10 kthread+0x293/0x360 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2f/0x70 ?
    __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> 由任务 34 分配：
    kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0
    __hci_conn_add+0x187/0x17d0 hci_connect_sco+0x2e1/0xb90 sco_sock_connect+0x2a2/0xb80
    __sys_connect+0x227/0x2a0 __x64_sys_connect+0x6d/0xb0 do_syscall_64+0x71/0x140 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 37: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x101/0x160 kfree+0xd0/0x250 device_release+0x9a/0x210 kobject_put+0x151/0x280 hci_conn_del+0x448/0xbf0 hci_abort_conn_sync+0x46f/0x980 hci_cmd_sync_work+0x1c2/0x330 process_one_work+0x7d9/0x1360 worker_thread+0x5b7/0xf60 kthread+0x293/0x360 ret_from_fork+0x2f/0x70 ret_from_fork_asm+0x1a/0x30 (CVE-2024-50029)

  - 在 Linux 内核中，已解决以下漏洞：蓝牙：RFCOMM：修复 rfcomm_sk_state_change 中可能发生的死锁 rfcomm_sk_state_change 尝试使用 sock_lock，因此绝不能在锁定时调用它，但 rfcomm_sock_ioctl 始终尝试锁定它，从而导致以下跟踪：
    ====================================================== 警告：检测到可能存在循环锁定依存关系 6.8.0-syzkaller-08951-gfe46a7dd189e #0 未感染
    ------------------------------------------------------ syz-executor386/5093 正在尝试获取锁定：
    ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1671 [内联] ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at:
    rfcomm_sk_state_change+0x5b/0x310 net/bluetooth/rfcomm/sock.c:73 但任务已在保持锁定：
    ffff88807badfd28 (&d->lock){+.+.}-{3:3}, at: __rfcomm_dlc_close+0x226/0x6a0 net/bluetooth/rfcomm/core.c:491 (CVE-2024-50044)

  - 在 Linux 内核中，解决了以下漏洞：uprobe：避免提取 args 时的越界内存访问 Uprobe 需要将 args 提取到 percpu 缓冲区，然后复制到环缓冲区以避免非原子上下文问题。有时用户空间字符串、数组可能非常大，但 percpu 缓冲区的大小只是页面大小。而 store_trace_args() 不会检查这些数据是否超过单个页面，从而造成越界内存访问。通过以下步骤可重现此问题：1. 在启用 CONFIG_KASAN 的情况下构建内核 2. 将后续程序另存为 test.c ``` \#include <stdio.h> \#include <stdlib.h> \#include <string.h> // 如果字符串长度大于 MAX_STRING_SIZE，fetch_store_strlen() // 将返回 0，造成 __get_data_size() 返回更小的大小，并且 // store_trace_args() 不会触发越界访问。// 因此使字符串长度小于 4096。\#define STRLEN 4093 void generate_string(char *str, int n) { int i; for (i = 0; i < n; ++i) { char c = i % 26 + 'a'; str[i] = c; } str[n-1] = '\0'; } void print_string(char *str) { printf(%s\n, str); } int main() { char tmp[STRLEN];
    generate_string(tmp, STRLEN); print_string(tmp); return 0; } ``` 3. 编译程序 `gcc -o test test.c` 4. 获得 `print_string()` 的偏移 ``` objdump -t test | grep -w print_string 0000000000401199 g F .text 000000000000001b print_string ``` 5. 使用偏移 0x1199 配置 uprobe ``` off=0x1199 cd /sys/kernel/debug/tracing/ echo p /root/test:${off} arg1=+ 0(%di):ustring arg2=\$comm arg3=+0(%di):ustring > uprobe_events echo 1 > events/uprobes/enable echo 1 > tracing_on ``` 6. 运行 `test`，kasan 将报告错误。 ================================================== ================ 缺陷：KASAN：strncpy_from_user+0x1d6/0x1f0 中的释放后使用 由任务 test/499 在地址 ffff88812311c004 写入大小 8 CPU：0 UID：0 PID：499 Comm：test 未感染 6.12.0-rc3+ #18 硬件名称：Red Hat KVM，BIOS 1.16.0-4.al8 04/01/2014 调用跟踪：<TASK> dump_stack_lvl+0x55/0x70 print_address_description.constprop.0+0x27/0x310 kasan_report+0x10f/0x120 ? strncpy_from_user+0x1d6/0x1f0 strncpy_from_user+0x1d6/0x1f0 ? rmqueue.constprop.0+0x70d/0x2ad0 process_fetch_insn+0xb26/0x1470 ?
    __pfx_process_fetch_insn+0x10/0x10 ? _raw_spin_lock+0x85/0xe0 ? __pfx__raw_spin_lock+0x10/0x10 ?
    __pte_offset_map+0x1f/0x2d0 ? unwind_next_frame+0xc5f/0x1f80 ? arch_stack_walk+0x68/0xf0 ? is_bpf_text_address+0x23/0x30 ? kernel_text_address.part.0+0xbb/0xd0 ? __kernel_text_address+0x66/0xb0 ? unwind_get_return_address+0x5e/0xa0 ? __pfx_stack_trace_consume_entry+0x10/0x10 ? arch_stack_walk+0xa2/0xf0 ? _raw_spin_lock_irqsave+0x8b/0xf0 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? depot_alloc_stack+0x4c/0x1f0 ? _raw_spin_unlock_irqrestore+0xe/0x30 ? stack_depot_save_flags+0x35d/0x4f0 ? kasan_save_stack+0x34/0x50 ? kasan_save_stack+0x24/0x50 ? mutex_lock+0x91/0xe0 ?
    __pfx_mutex_lock+0x10/0x10 prepare_uprobe_buffer.part.0+0x2cd/0x500 uprobe_dispatcher+0x2c3/0x6a0？
    __pfx_uprobe_dispatcher+0x10/0x10 ? __kasan_slab_alloc+0x4d/0x90 handler_chain+0xdd/0x3e0 handle_swbp+0x26e/0x3d0 ? __pfx_handle_swbp+0x10/0x10 ? uprobe_pre_sstep_notifier+0x151/0x1b0 irqentry_exit_to_user_mode+0xe2/0x1b0 asm_exc_int3+0x39/0x40 RIP: 0033:0x401199 Code: 01 c2 0f b6 45 fb 88 02 83 45 fc 01 8b 45 fc 3b 45 e4 7c b7 8b 45 e4 48 98 48 8d 50 ff 48 8b 45 e8 48 01 d0 ce RSP:
    002b:00007ffdf00576a8 EFLAGS：00000206 RAX：00007ffdf00576b0 RBX：0000000000000000 RCX：0000000000000ff2 RDX：0000000000000ffc RSI：0000000000000ffd RDI：00007ffdf00576b0 RBP：00007ffdf00586b0 R08：
    00007feb2f9c0d20 R09：00007feb2f9c0d20 R10：0000000000000001 R11：0000000000000202 R12：0000000000401040 R13：00007ffdf0058780 R14：0000000000000000 R15：0000000000000000 </TASK> 此提交执行小于页面大小的缓冲区的 maxlen，以避免 store_trace_args() 内存不足访问。(CVE-2024-50067)

  - 在 Linux 内核中，已解决以下漏洞：蓝牙：ISO：在禁用 debugfs 时修复多个 init 如果没有成功创建 bt_debugfs（如果未设置 CONFIG_DEBUG_FS 或 CONFIG_DEBUG_FS_ALLOW_ALL，则会发生这种情况），则 iso_init() 会提前返回，并且不会将 iso_inited 设为 true。
    这意味着对 iso_init() 的后续调用将导致对 proto_register()、bt_sock_register() 等内容的重复调用。启用 CONFIG_LIST_HARDENED 和 CONFIG_BUG_ON_DATA_CORRUPTION 时，对 proto_register() 的重复调用会触发此 BUG()：list_add 双重添加：new=ffffffffc0b280d0、prev=ffffffffbab56250、next=ffffffffc0b280d0。 ------------[在此处剪切 ]---------------- lib/list_debug.c:35! 的内核缺陷Oops：无效 操作码：0000 [#1] PREEMPT SMP PTI CPU:2 PID: 887 Comm：bluetoothd 未感染 6.10.11-1-ao-desktop #1 RIP：0010:__list_add_valid_or_report+0x9a/0xa0 ...
    __list_add_valid_or_report+0x9a/0xa0 proto_register+0x2b5/0x340 iso_init+0x23/0x150 [bluetooth] set_iso_socket_func+0x68/0x1b0 [bluetooth] kmem_cache_free+0x308/0x330 hci_sock_sendmsg+0x990/0x9e0 [bluetooth] __sock_sendmsg+0x7b/0x80 sock_write_iter+0x9a/0x110 do_iter_readv_writev+0x11d/0x220 vfs_writev+0x180/0x3e0 do_writev+0xca/0x100 ... 此更改会移除提前返回标志。不需要检查 iso_debugfs 是否为空，当 iso_inited 为 false 时它始终为空。(CVE-2024-50077)

  - 在 Linux 内核中，解决了以下漏洞：蓝牙：卸载模块时调用 iso_exit() 如果已调用 iso_init()，则必须在卸载模块时调用 iso_exit()。如果不修复此漏洞，则 iso_init() 向 proto_register() 注册的 struct proto 将失效，这可能在以后造成无法预测的问题。就我遇到的情况而言，在启用 CONFIG_LIST_HARDENED 和 CONFIG_BUG_ON_DATA_CORRUPTION 的情况下，再次加载模块通常会触发此 BUG()：list_add 损坏。next->prev 应是 prev (ffffffffb5355fd0)，但实际上是 0000000000000068。(next=ffffffffc0a010d0)。 ------------[在此处剪切]--------------- lib/list_debug.c:29! 的内核缺陷Oops：无效 操作码：0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 4159 Comm：modprobe 未感染 6.10.11-4+bt2-ao-desktop #1 RIP：
    0010:__list_add_valid_or_report+0x61/0xa0 ... __list_add_valid_or_report+0x61/0xa0 proto_register+0x299/0x320 hci_sock_init+0x16/0xc0 [蓝牙] bt_init+0x68/0xd0 [蓝牙]
    __pfx_bt_init+0x10/0x10 [蓝牙] do_one_initcall+0x80/0x2f0 do_init_module+0x8b/0x230
    __do_sys_init_module+0x15f/0x190 do_syscall_64+0x68/0x110 ... (CVE-2024-50078)

  - 在 Linux 内核中，解决了以下漏洞：蓝牙：SCO：修复 sco_sock_timeout 上的 UAF 在等待 sco_conn_lock 时可能已经取消链接/释放 conn->sk，因此这通过检查 conn->sk 是否是 sco_sk_list 的一部分来检查 conn->sk 是否仍然有效。(CVE-2024-50125)

  - 在 Linux 内核中，解决了以下漏洞：蓝牙：bnep：修复 proto_unregister 中的 wild-memory-access。存在如下问题：KASAN：可能是范围 [0xdead...108-0xdead.. .10f] 中的 wild-memory-access。CPU: 3 UID: 0 PID: 2805 Comm: rmmod 已感染: GW RIP：
    0010:proto_unregister+0xee/0x400 调用跟踪：<TASK> __do_sys_delete_module+0x318/0x580 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f 由于 bnep_init() 忽略 bnep_sock_init() 的返回值，bnep_sock_init() 将清理所有资源。然后，当删除 bnep 模块时，系统将调用 bnep_sock_cleanup() 以清理 sock 的资源。要解决上述问题，只需在 bnep_exit() 中返回 bnep_sock_init() 的返回值。(CVE-2024-50148)

  - 在 Linux 内核中，已解决以下漏洞：蓝牙：hci：修复 hci_read_supported_codecs 中的 null-ptr-deref，修复 __hci_cmd_sync_sk() 以针对未知的操作码返回非 NULL。
    如果命令返回状态事件，则 __hci_cmd_sync_sk() 返回 NULL。但是，它也会在 hci_cc 表中不存在操作码的情况下返回 NULL，因为 hci_cmd_complete_evt() 对未知操作码假设 status = skb->data[0]。这会导致 cmd_sync 中 HCI_OP_READ_LOCAL_CODECS 发生 null-ptr-deref，因为 HCI_OP_READ_LOCAL_CODECS 没有 hci_cc，会始终假设 status = skb->data[0]。KASAN：范围 [0x0000000000000070-0x0000000000000077] 中的 null-ptr-deref CPU：1 PID：2000 Comm：kworker/u9:5 未感染 6.9.0-ga6bcb805883c-dirty #10 硬件名称：QEMU 标准 PC (i440FX + PIIX, 1996 )、BIOS 1.15.0-1 2014 年 4 月 1 日 Workqueue：hci7 hci_power_on RIP：0010:hci_read_supported_codecs+0xb9/0x870 net/bluetooth/hci_codec.c:138 代码：08 48 89 ef e8 b8 c1 8f fd 48 8b 75 00 e9 96 00 00 00 49 89 c6 48 ba 00 00 00 00 00 fc ff df 4c 8d 60 70 4c 89 e3 48 c1 eb 03 <0f> b6 04 13 84 c0 0f 85 82 06 00 00 41 83 3c 24 02 77 0a e8 bf 78 RSP：0018:ffff888120bafac8 EFLAGS：00010212 RAX：0000000000000000 RBX：000000000000000e RCX：ffff8881173f0040 RDX：dffffc0000000000 RSI：ffffffffa58496c0 RDI：ffff88810b9ad1e4 RBP：
    ffff88810b9ac000 R08：ffffffffa77882a7 R09：1ffffffff4ef1054 R10：dffffc0000000000 R11：fffffbfff4ef1055 R12：0000000000000070 R13：0000000000000000 R14：0000000000000000 R15：ffff88810b9ac000 FS：
    0000000000000000(0000) GS:ffff8881f6c00000(0000) knlGS:0000000000000000 CS：0010 DS：0000 ES：0000 CR0：
    0000000080050033 CR2：00007f6ddaa3439e CR3：0000000139764003 CR4：0000000000770ef0 PKRU：55555554 调用跟踪：<TASK> hci_read_local_codecs_sync net/bluetooth/hci_sync.c:4546 [内联] hci_init_stage_sync net/bluetooth/hci_sync.c:3441 [inline] hci_init4_sync net/bluetooth/hci_sync .c:4706 [内联] hci_init_sync net/bluetooth/hci_sync.c:4742 [内联] hci_dev_init_sync net/bluetooth/hci_sync.c:4912 [内联] hci_dev_open_sync+0x19a9/0x2d30 net/bluetooth/hci_sync.c:4994 hci_dev_do_open net/ bluetooth/hci_core.c:483 [内联] hci_power_on+0x11e/0x560 net/bluetooth/hci_core.c:1015 process_one_work kernel/workqueue.c:3267 [内联] process_scheduled_works+0x8ef/0x14f0 kernel/workqueue.c:3348 worker_thread+0x91f /0xe50 kernel/workqueue.c:3429 kthread+0x2cb/0x360 kernel/kthread.c:388 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64. S:244 (CVE-2024-50255)

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

远程 CentOS Linux 9 主机上安装的多个程序包受到 tuned-2.24.0-2.el9 版本变更日志中提及的多个漏洞影响。

  - 在 Tuned 程序包中发现一个脚本注入漏洞。本地登录的用户可在未经身份验证的情况下调用 `instance_create()` D-Bus 函数。此缺陷允许本地非特权用户通过 `script_pre` 或 `script_post` 选项执行 D-Bus 调用，从而允许传递任意脚本及其绝对路径。Tuned 然后以根特权执行这些用户或攻击者控制的可执行脚本或程序，这可允许攻击者进行本地特权提升。(CVE-2024-52336)

  - 由于未正确审查某些 API 参数，在 Tuned 程序包中发现日志欺骗缺陷。
    此缺陷允许攻击者传递受控制的字符序列；可在日志中插入换行符。攻击者可以伪造有效的 TuneD 日志行并诱骗管理员，而不是伪造“evil”。引号 '' 通常在 TuneD 日志中引用原始用户输入，因此欺骗输入始终以 ' 字符结束，管理员很容易忽略这一点。记录的字符串稍后用于日志记录和实用工具的输出中，例如 `tuned-adm get_instances` 或使用 Tuned 的 D-Bus 接口执行此类操作的其他第三方程序。(CVE-2024-52337)

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

远程 CentOS Linux 9 主机上安装的多个程序包受到 kernel-5.14.0-529.el9 版本变更日志中提及的多个漏洞影响。

  - Linux 内核中的以下漏洞已修复：ipvs: ip_vs_add_service 中正确取消引用 pe。直接使用 pe 解决稀疏警告：net/netfilter/ipvs/ip_vs_ctl.c:1471:27：
    警告：noderef 表达式取消引用 (CVE-2024-42322)

  - Linux 内核中的以下漏洞已修复：fscache：退出 fscache 时删除 fscache_cookie_lru_timer 以避免 UAF fscache_cookie_lru_timer 在插入 fscache 模块时会初始化，但在移除 fscache 模块时未删除。如果在删除 fscache 模块之前调用 timer_reduce()，fscache_cookie_lru_timer 将添加到当前 cpu 的定时器列表中。之后，删除 fscache 模块之后，将在 softIRQ 中触发释放重引用，如下所示：=========================== ======================================= 缺陷：无法处理以下地址的页面错误：ffffbfff803c9e9 PF：内核模式 PF：
    error_code(0x0000) - 不存在页面 PGD 21ffea067 P4D 21ffea067 PUD 21ffe6067 PMD 110a7c067 PTE 0 Oops：
    Oops: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Tainted: G W 6.11.0-rc3 #855 Tainted: [W]=WARN RIP: 0010:__run_timer_base.part.0+0x254/0x8a0 Call Trace: <IRQ> tmigr_handle_remote_up+0x627/0x810 __walk_groups.isra.0+0x47/0x140 tmigr_handle_remote+0x1fa/0x2f0 handle_softirqs+0x180/0x590 irq_exit_rcu+0x84/0xb0 sysvec_apic_timer_interrupt+0x6e/0x90 </IRQ> <TASK> asm_sysvec_apic_timer_interrupt+0x1a/0x20 RIP: 0010:default_idle+0xf/0x20 default_idle_call+0x38/0x60 do_idle+0x2b5/0x300 cpu_startup_entry+0x54/0x60 start_secondary+0x20d/0x280 common_startup_64+0x13e/0x148 </TASK> Modules linked in: [last unloaded: netfs] ================================================== ============= 因此，在删除 fscahe 模块时会删除 fscache_cookie_lru_timer。 (CVE-2024-46786)

  - Linux 内核中的以下漏洞已修复：NFSD：限制并发异步 COPY 操作的数量。似乎没有任何内容可以限制客户端可启动的并发异步 COPY 操作的数量。此外，AFAICT 每个异步 COPY 可复制无限数量的 4MB 区块，因此可以运行很长时间。因此，IMO 异步 COPY 可转变为 DoS 矢量。添加限制机制，限制并发后台 COPY 操作的数量。简单开始，力争公平 -- 此补丁将对各命名空间进行限制。超出此限制时发生的异步 COPY 请求将返回 NFS4ERR_DELAY。
    发出请求的客户端可以选择在延迟后再次发送请求，或回退到使用传统的读取/写入式复制。如需使该机制更复杂，可在以后的补丁中加以利用。 (CVE-2024-49974)

  - Linux 内核中的以下漏洞已修复：netfilter：xtables：在需要的情况下避免 NFPROTO_UNSPEC syzbot 设法通过 ebtables 调用 xt_cluster 匹配：警告：CPU：0 PID：11 at net/netfilter/xt_cluster.c:72 xt_cluster_mt+ 0x196/0x780 [..] ebt_do_table+0x174b/0x2a40 模块注册到 NFPROTO_UNSPEC，但其假设处理的是 ipv4/ipv6 数据包。由于此项仅可用于限制本地终止 TCP/UDP 流量，因此仅为 ipv4 和 ipv6 系列注册此项。Pablo 指出这是一个普遍的问题，因为 set/getsockopt 接口的直接用户可能调用只与 ip(6) 表一起使用的目标/匹配。检查所有 UNSPEC 匹配和目标中的类似问题： - 匹配和目标正常，除非假设 skb_network_header() 有效 -- 仅当从 inet 层调用时才有效：ip(6) 堆栈将 ip/ipv6 标头提取到线性中数据区。 - 返回 XT_CONTINUE 或其他 xtables 判定的目标也必须受到限制，它们与 ebtables 遍历器不兼容，例如 EBT_CONTINUE 是与 XT_CONTINUE 完全不同的值。大多数 matches/target 都已更改为针对 NFPROTO_IPV4/IPV6 进行注册，因为其本身就为 ip(6)tables 所使用。MARK 目标也由 arptables 使用，因此也为 NFPROTO_ARP 注册。此时，如果 connbytes 无法启用相应的 conntrack 系列，则终止操作 。此变更通过 iptables.git 中的自我测试。 (CVE-2024-50038)

  - Linux 内核中的以下漏洞已修复：platform/x86/intel/pmc：修复 pmc_core_iounmap 为有效地址调用 iounmap：当 iounmap 的地址范围无效时，提交 50c6dbdfd16e（x86/ioremap：改进 iounmap() 地址范围检查）引入一个 WARN。该情况在 Thinkpad P1 Gen 7 (Meteor Lake-P) 上会造成出现以下警告：WARNING: CPU: 7 PID: 713 at arch/x86/mm/ioremap.c:461 iounmap+0x58/0x1f0 Modules linked in: rfkill(+) snd_timer(+) fjes(+) snd soundcore intel_pmc_core(+) int3403_thermal(+) int340x_thermal_zone intel_vsec pmt_telemetry acpi_pad pmt_class acpi_tad int3400_thermal acpi_thermal_rel joydev loop nfnetlink zram xe drm_suballoc_helper nouveau i915 mxm_wmi drm_ttm_helper gpu_sched drm_gpuvm drm_exec drm_buddy i2c_algo_bit crct10dif_pclmul crc32_pclmul ttm crc32c_intel polyval_clmulni rtsx_pci_sdmmc ucsi_acpi polyval_generic mmc_core hid_multitouch drm_display_helper ghash_clmulni_intel typec_ucsi nvme sha512_ssse3 video sha256_ssse3 nvme_core intel_vpu sha1_ssse3 rtsx_pci cec typec nvme_auth i2c_hid_acpi i2c_hid wmi pinctrl_meteorlake serio_raw ip6_tables ip_tables fuse CPU: 7 UID: 0 PID: 713 Comm: (udev-worker) Not tainted 6.12.0-rc2iounmap+ #42 Hardware name: LENOVO 21KWCTO1WW/21KWCTO1WW, BIOS N48ET19W (1.06 ) 07/18/2024 RIP:
    0010:iounmap+0x58/0x1f0 Code: 85 6a 01 00 00 48 8b 05 e6 e2 28 04 48 39 c5 72 19 eb 26 cc cc cc 48 ba 00 00 00 00 00 00 32 00 48 8d 44 02 ff 48 39 c5 72 23 <0f> 0b 48 83 c4 08 5b 5d 41 5c c3 cc cc cc cc 48 ba 00 00 00 00 00 RSP: 0018:ffff888131eff038 EFLAGS: 00010207 RAX: ffffc90000000000 RBX: 0000000000000000 RCX:
    ffff888e33b80000 RDX: dffffc0000000000 RSI: ffff888e33bc29c0 RDI: 0000000000000000 RBP: 0000000000000000 R08: ffff8881598a8000 R09: ffff888e2ccedc10 R10: 0000000000000003 R11: ffffffffb3367634 R12:
    00000000fe000000 R13: ffff888101d0da28 R14: ffffffffc2e437e0 R15: ffff888110b03b28 FS:
    00007f3c1d4b3980(0000) GS:ffff888e33b80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0:
    0000000080050033 CR2: 00005651cfc93578 CR3: 0000000124e4c002 CR4: 0000000000f70ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7:
    0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? __warn.cold+0xb6/0x176 ? iounmap+0x58/0x1f0 ? report_bug+0x1f4/0x2b0 ? handle_bug+0x58/0x90 ? exc_invalid_op+0x17/0x40 ? asm_exc_invalid_op+0x1a/0x20 ? iounmap+0x58/0x1f0 pmc_core_ssram_get_pmc+0x477/0x6c0 [intel_pmc_core] ?
    __pfx_pmc_core_ssram_get_pmc+0x10/0x10 [intel_pmc_core] ? __pfx_do_pci_enable_device+0x10/0x10 ? pci_wait_for_pending+0x60/0x110 ? pci_enable_device_flags+0x1e3/0x2e0 ? __pfx_mtl_core_init+0x10/0x10 [intel_pmc_core] pmc_core_ssram_init+0x7f/0x110 [intel_pmc_core] mtl_core_init+0xda/0x130 [intel_pmc_core] ? __mutex_init+0xb9/0x130 pmc_core_probe+0x27e/0x10b0 [intel_pmc_core] ? _raw_spin_lock_irqsave+0x96/0xf0 ? __pfx_pmc_core_probe+0x10/0x10 [intel_pmc_core] ? __pfx_mutex_unlock+0x10/0x10 ?
    __pfx_mutex_lock+0x10/0x10 ? device_pm_check_callbacks+0x82/0x370 ? acpi_dev_pm_attach+0x234/0x2b0 platform_probe+0x9f/0x150 really_probe+0x1e0/0x8a0 __driver_probe_device+0x18c/0x370 ?
    __pfx___driver_attach+0x10/0x10 driver_probe_device+0x4a/0x120 __driver_attach+0x190/0x4a0 ?
    __pfx___driver_attach+0x10/0x10 bus_for_each_dev+0x103/0x180 ? __pfx_bus_for_each_dev+0x10/0x10 ? klist_add_tail+0x136/0x270 bus_add_driver+0x2fc/0x540 driver_register+0x1a5/0x360 ?
    __pfx_pmc_core_driver_init+0x10/0x10 [intel_pmc_core] do_one_initcall+0xa4/0x380 ?
    __pfx_do_one_initcall+0x10/0x10 ? kasan_unpoison+0x44/0x70 do_init_module+0x296/0x800 load_module+0x5090/0x6ce0 ? __pfx_load_module+0x10/0x10 ? ima_post_read_file+0x193/0x200 ?
    __pfx_ima_post_read_file+0x10/0x10 ? rw_verify_area+0x152/0x4c0 ? kernel_read_file+0x257/0x750 ?
    __pfx_kernel_read_file+0x10/0x10 ? __pfx_filemap_get_read_batch+0x10/0x10 ? init_module_from_file+0xd1/0x130 init_module_from_file+0xd1/0x130 ? __pfx_init_module_from_file+0x10/0
    ---truncated--- (CVE-2024-50107)

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

远程 CentOS Linux 9 主机上安装的多个程序包受到 expat-2.5.0-4.el9 版本变更日志中提及的一个漏洞影响。

  - 在低于 2.6.4 的 libexpat 中发现一个问题。XML_ResumeParser 函数中发生崩溃，因为 XML_StopParser 可停止/暂停未启动的解析器。(CVE-2024-50602)

请注意，Nessus 尚未测试此问题，而是只依据应用程序自我报告的版本号进行判断。

远程 CentOS Linux 9 主机上安装的多个程序包受到 kernel-5.14.0-527.el9 版本变更日志中提及的多个漏洞影响。

  - 在 Linux 内核中，解决了以下漏洞：USB：core：通过清除描述符中的保留位来修复重复的端点缺陷 Syzbot 已发现 usbcore（请参阅下面的 Closes: 标记）中有一个缺陷，这是因为我们端点描述符的 bEndpointAddress 字段中的位将始终为 0。由于该缺陷，config.c 中的 endpoint_is_duplicate() 例程（以及可能的其他例程）可能认为两个描述符来自不同的端点，即使它们具有相同的方向和端点编号。这可导致混淆，包括由 syzbot 识别的缺陷（具有相符端点编号和方向的两个描述符，其中一个为中断，另一个为批量）。为修复缺陷，我们将在解析描述符时清除 bEndpointAddress 中的保留位。
    （请注意，USB-2.0 和 USB-3.1 规范都表示这些位为保留位，并重置为零。）这需要我们在 usb_parse_endpoint() 之前创建描述符的副本，并在检查项。(CVE-2024-41035)

  - 在 Linux 内核中，解决了以下漏洞：USB：serial：mos7840：修复恢复时崩溃的问题 自提交 c49cfa917025（USB：串行：如果 USB 串行层未提供替代方法，则使用通用方法）以来，USB 串行核心会在驱动程序未提供通用恢复实现时调用该实现。这可在使用 mos7840 恢复时触发崩溃，因为在 2011 年已添加多种读取 URB 支持。具体而言，现在会在恢复已打开的端口时提交两个端口读取 URB，但第二个 URB 的上下文指针仍设置为核心，而非 mos7840 端口结构。实现 mos7840 的专用挂起和恢复函数可修复此问题。使用 Delock 87414 USB 2.0 至 4x 串行适配器进行测试。[ johan：分析崩溃并重写提交消息；在恢复中设置忙碌标记；终止大量传入检查；删除不必要的 usb_kill_urb() ] (CVE-2024-42244)

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

远程 CentOS Linux 9 主机上安装的多个程序包受到 kernel-5.14.0-516.el9 版本变更日志中提及的多个漏洞影响。

  - 在 Linux 内核中，已解决以下漏洞： r8169: Fix possible ring buffer corruption on fragmented Tx packets. An issue was found on the RTL8125b when transmitting small fragmented packets, whereby invalid entries were inserted into the transmit ring buffer, subsequently leading to calls to dma_unmap_single() with a null address. This was caused by rtl8169_start_xmit() not noticing changes to nr_frags which may occur when small packets are padded (to work around hardware quirks) in rtl8169_tso_csum_v2(). To fix this, postpone inspecting nr_frags until after any padding has been applied.
    (CVE-2024-38586)

  - 在 Linux 内核中，已解决以下漏洞： dmaengine: idxd: Avoid unnecessary destruction of file_ida file_ida is allocated during cdev open and is freed accordingly during cdev release. This sequence is guaranteed by driver file operations. Therefore, there is no need to destroy an already empty file_ida when the WQ cdev is removed. Worse, ida_free() in cdev release may happen after destruction of file_ida per WQ cdev. This can lead to accessing an id in file_ida after it has been destroyed, resulting in a kernel panic. Remove ida_destroy(&file_ida) to address these issues.
    (CVE-2024-38629)

  - 在 Linux 内核中，已解决以下漏洞： ionic: fix kernel panic in XDP_TX action In the XDP_TX path, ionic driver sends a packet to the TX path with rx page and corresponding dma address. After tx is done, ionic_tx_clean() frees that page. But RX ring buffer isn't reset to NULL. So, it uses a freed page, which causes kernel panic. BUG: unable to handle page fault for address:
    ffff8881576c110c PGD 773801067 P4D 773801067 PUD 87f086067 PMD 87efca067 PTE 800ffffea893e060 Oops: Oops:
    0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN NOPTI CPU: 1 PID: 25 Comm: ksoftirqd/1 Not tainted 6.9.0+ #11 Hardware name: ASUS System Product Name/PRIME Z690-P D4, BIOS 0603 11/01/2021 RIP:
    0010:bpf_prog_f0b8caeac1068a55_balancer_ingress+0x3b/0x44f Code: 00 53 41 55 41 56 41 57 b8 01 00 00 00 48 8b 5f 08 4c 8b 77 00 4c 89 f7 48 83 c7 0e 48 39 d8 RSP: 0018:ffff888104e6fa28 EFLAGS: 00010283 RAX:
    0000000000000002 RBX: ffff8881576c1140 RCX: 0000000000000002 RDX: ffffffffc0051f64 RSI: ffffc90002d33048 RDI: ffff8881576c110e RBP: ffff888104e6fa88 R08: 0000000000000000 R09: ffffed1027a04a23 R10:
    0000000000000000 R11: 0000000000000000 R12: ffff8881b03a21a8 R13: ffff8881589f800f R14: ffff8881576c1100 R15: 00000001576c1100 FS: 0000000000000000(0000) GS:ffff88881ae00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff8881576c110c CR3: 0000000767a90000 CR4: 00000000007506f0 PKRU: 55555554 Call Trace: <TASK> ? __die+0x20/0x70 ? page_fault_oops+0x254/0x790 ?
    __pfx_page_fault_oops+0x10/0x10 ? __pfx_is_prefetch.constprop.0+0x10/0x10 ? search_bpf_extables+0x165/0x260 ? fixup_exception+0x4a/0x970 ? exc_page_fault+0xcb/0xe0 ? asm_exc_page_fault+0x22/0x30 ? 0xffffffffc0051f64 ? bpf_prog_f0b8caeac1068a55_balancer_ingress+0x3b/0x44f ? do_raw_spin_unlock+0x54/0x220 ionic_rx_service+0x11ab/0x3010 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] ? ionic_tx_clean+0x29b/0xc60 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] ? __pfx_ionic_tx_clean+0x10/0x10 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] ? __pfx_ionic_rx_service+0x10/0x10 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] ? ionic_tx_cq_service+0x25d/0xa00 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] ? __pfx_ionic_rx_service+0x10/0x10 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] ionic_cq_service+0x69/0x150 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] ionic_txrx_napi+0x11a/0x540 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] __napi_poll.constprop.0+0xa0/0x440 net_rx_action+0x7e7/0xc30 ?
    __pfx_net_rx_action+0x10/0x10 (CVE-2024-40907)

  - 在 Linux 内核中，已解决以下漏洞： net/mlx5: Fix missing lock on sync reset reload On sync reset reload work, when remote host updates devlink on reload actions performed on that host, it misses taking devlink lock before calling devlink_remote_reload_actions_performed() which results in triggering lock assert like the following: WARNING: CPU: 4 PID: 1164 at net/devlink/core.c:261 devl_assert_locked+0x3e/0x50 CPU: 4 PID: 1164 Comm: kworker/u96:6 Tainted: G S W 6.10.0-rc2+ #116 Hardware name: Supermicro SYS-2028TP-DECTR/X10DRT-PT, BIOS 2.0 12/18/2015 Workqueue: mlx5_fw_reset_events mlx5_sync_reset_reload_work [mlx5_core] RIP: 0010:devl_assert_locked+0x3e/0x50 Call Trace: <TASK> ?
    __warn+0xa4/0x210 ? devl_assert_locked+0x3e/0x50 ? report_bug+0x160/0x280 ? handle_bug+0x3f/0x80 ? exc_invalid_op+0x17/0x40 ? asm_exc_invalid_op+0x1a/0x20 ? devl_assert_locked+0x3e/0x50 devlink_notify+0x88/0x2b0 ? mlx5_attach_device+0x20c/0x230 [mlx5_core] ? __pfx_devlink_notify+0x10/0x10 ? process_one_work+0x4b6/0xbb0 process_one_work+0x4b6/0xbb0 [] (CVE-2024-42268)

  - 在 Linux 内核中，已解决以下漏洞： tipc: Return non-zero value from tipc_udp_addr2str() on error tipc_udp_addr2str() should return non-zero value if the UDP media address is invalid. Otherwise, a buffer overflow access can occur in tipc_media_addr_printf(). Fix this by returning 1 on an invalid UDP media address. (CVE-2024-42284)

  - 在 Linux 内核中，已解决以下漏洞： dma: fix call order in dmam_free_coherent dmam_free_coherent() frees a DMA allocation, which makes the freed vaddr available for reuse, then calls devres_destroy() to remove and free the data structure used to track the DMA allocation.
    Between the two calls, it is possible for a concurrent task to make an allocation with the same vaddr and add it to the devres list. If this happens, there will be two entries in the devres list with the same vaddr and devres_destroy() can free the wrong entry, triggering the WARN_ON() in dmam_match. Fix by destroying the devres entry before freeing the DMA allocation. kokonut //net/encryption http://sponge2/b9145fe6-0f72-4325-ac2f-a84d81075b03 (CVE-2024-43856)

  - 在 Linux 内核中，已解决以下漏洞： net/mlx5e: Fix CT entry update leaks of modify header context The cited commit allocates a new modify header to replace the old one when updating CT entry. But if failed to allocate a new one, eg. exceed the max number firmware can support, modify header will be an error pointer that will trigger a panic when deallocating it. And the old modify header point is copied to old attr. When the old attr is freed, the old modify header is lost. Fix it by restoring the old attr to attr when failed to allocate a new modify header context. So when the CT entry is freed, the right modify header context will be freed. And the panic of accessing error pointer is also fixed. (CVE-2024-43864)

  - 在 Linux 内核中，已解决以下漏洞： net/mlx5: Always drain health in shutdown callback There is no point in recovery during device shutdown. if health work started need to wait for it to avoid races and NULL pointer access. Hence, drain health WQ on shutdown callback.
    (CVE-2024-43866)

  - 在 Linux 内核中，已解决以下漏洞： memcg: protect concurrent access to mem_cgroup_idr Commit 73f576c04b94 (mm: memcontrol: fix cgroup creation failure after many small jobs) decoupled the memcg IDs from the CSS ID space to fix the cgroup creation failures. It introduced IDR to maintain the memcg ID space. The IDR depends on external synchronization mechanisms for modifications. For the mem_cgroup_idr, the idr_alloc() and idr_replace() happen within css callback and thus are protected through cgroup_mutex from concurrent modifications. However idr_remove() for mem_cgroup_idr was not protected against concurrency and can be run concurrently for different memcgs when they hit their refcnt to zero. Fix that. We have been seeing list_lru based kernel crashes at a low frequency in our fleet for a long time. These crashes were in different part of list_lru code including list_lru_add(), list_lru_del() and reparenting code. Upon further inspection, it looked like for a given object (dentry and inode), the super_block's list_lru didn't have list_lru_one for the memcg of that object. The initial suspicions were either the object is not allocated through kmem_cache_alloc_lru() or somehow memcg_list_lru_alloc() failed to allocate list_lru_one() for a memcg but returned success. No evidence were found for these cases.
    Looking more deeply, we started seeing situations where valid memcg's id is not present in mem_cgroup_idr and in some cases multiple valid memcgs have same id and mem_cgroup_idr is pointing to one of them. So, the most reasonable explanation is that these situations can happen due to race between multiple idr_remove() calls or race between idr_alloc()/idr_replace() and idr_remove(). These races are causing multiple memcgs to acquire the same ID and then offlining of one of them would cleanup list_lrus on the system for all of them. Later access from other memcgs to the list_lru cause crashes due to missing list_lru_one. (CVE-2024-43892)

  - 在 Linux 内核中，已解决以下漏洞： net/mlx5e: SHAMPO, Fix invalid WQ linked list unlink When all the strides in a WQE have been consumed, the WQE is unlinked from the WQ linked list (mlx5_wq_ll_pop()). For SHAMPO, it is possible to receive CQEs with 0 consumed strides for the same WQE even after the WQE is fully consumed and unlinked. This triggers an additional unlink for the same wqe which corrupts the linked list. Fix this scenario by accepting 0 sized consumed strides without unlinking the WQE again. (CVE-2024-44970)

  - 在 Linux 内核中，已解决以下漏洞： bnxt_en: Fix double DMA unmapping for XDP_REDIRECT Remove the dma_unmap_page_attrs() call in the driver's XDP_REDIRECT code path. This should have been removed when we let the page pool handle the DMA mapping. This bug causes the warning: WARNING:
    CPU: 7 PID: 59 at drivers/iommu/dma-iommu.c:1198 iommu_dma_unmap_page+0xd5/0x100 CPU: 7 PID: 59 Comm:
    ksoftirqd/7 Tainted: G W 6.8.0-1010-gcp #11-Ubuntu Hardware name: Dell Inc. PowerEdge R7525/0PYVT1, BIOS 2.15.2 04/02/2024 RIP: 0010:iommu_dma_unmap_page+0xd5/0x100 Code: 89 ee 48 89 df e8 cb f2 69 ff 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 31 d2 31 c9 31 f6 31 ff 45 31 c0 e9 ab 17 71 00 <0f> 0b 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 31 d2 31 c9 RSP: 0018:ffffab1fc0597a48 EFLAGS: 00010246 RAX:
    0000000000000000 RBX: ffff99ff838280c8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffab1fc0597a78 R08: 0000000000000002 R09: ffffab1fc0597c1c R10:
    ffffab1fc0597cd3 R11: ffff99ffe375acd8 R12: 00000000e65b9000 R13: 0000000000000050 R14: 0000000000001000 R15: 0000000000000002 FS: 0000000000000000(0000) GS:ffff9a06efb80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000565c34c37210 CR3: 00000005c7e3e000 CR4: 0000000000350ef0 ? show_regs+0x6d/0x80 ? __warn+0x89/0x150 ? iommu_dma_unmap_page+0xd5/0x100 ? report_bug+0x16a/0x190 ? handle_bug+0x51/0xa0 ? exc_invalid_op+0x18/0x80 ? iommu_dma_unmap_page+0xd5/0x100 ? iommu_dma_unmap_page+0x35/0x100 dma_unmap_page_attrs+0x55/0x220 ? bpf_prog_4d7e87c0d30db711_xdp_dispatcher+0x64/0x9f bnxt_rx_xdp+0x237/0x520 [bnxt_en] bnxt_rx_pkt+0x640/0xdd0 [bnxt_en] __bnxt_poll_work+0x1a1/0x3d0 [bnxt_en] bnxt_poll+0xaa/0x1e0 [bnxt_en]
    __napi_poll+0x33/0x1e0 net_rx_action+0x18a/0x2f0 (CVE-2024-44984)

  - 在 Linux 内核中，已解决以下漏洞： KVM: s390: fix validity interception issue when gisa is switched off We might run into a SIE validity if gisa has been disabled either via using kernel parameter kvm.use_gisa=0 or by setting the related sysfs attribute to N (echo N >/sys/module/kvm/parameters/use_gisa). The validity is caused by an invalid value in the SIE control block's gisa designation. That happens because we pass the uninitialized gisa origin to virt_to_phys() before writing it to the gisa designation. To fix this we return 0 in kvm_s390_get_gisa_desc() if the origin is 0. kvm_s390_get_gisa_desc() is used to determine which gisa designation to set in the SIE control block. A value of 0 in the gisa designation disables gisa usage. The issue surfaces in the host kernel with the following kernel message as soon a new kvm guest start is attemted. kvm: unhandled validity intercept 0x1011 WARNING: CPU: 0 PID: 781237 at arch/s390/kvm/intercept.c:101 kvm_handle_sie_intercept+0x42e/0x4d0 [kvm] Modules linked in: vhost_net tap tun xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT xt_tcpudp nft_compat x_tables nf_nat_tftp nf_conntrack_tftp vfio_pci_core irqbypass vhost_vsock vmw_vsock_virtio_transport_common vsock vhost vhost_iotlb kvm nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables sunrpc mlx5_ib ib_uverbs ib_core mlx5_core uvdevice s390_trng eadm_sch vfio_ccw zcrypt_cex4 mdev vfio_iommu_type1 vfio sch_fq_codel drm i2c_core loop drm_panel_orientation_quirks configfs nfnetlink lcs ctcm fsm dm_service_time ghash_s390 prng chacha_s390 libchacha aes_s390 des_s390 libdes sha3_512_s390 sha3_256_s390 sha512_s390 sha256_s390 sha1_s390 sha_common dm_mirror dm_region_hash dm_log zfcp scsi_transport_fc scsi_dh_rdac scsi_dh_emc scsi_dh_alua pkey zcrypt dm_multipath rng_core autofs4 [last unloaded: vfio_pci] CPU: 0 PID: 781237 Comm:
    CPU 0/KVM Not tainted 6.10.0-08682-gcad9f11498ea #6 Hardware name: IBM 3931 A01 701 (LPAR) Krnl PSW :
    0704c00180000000 000003d93deb0122 (kvm_handle_sie_intercept+0x432/0x4d0 [kvm]) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3 Krnl GPRS: 000003d900000027 000003d900000023 0000000000000028 000002cd00000000 000002d063a00900 00000359c6daf708 00000000000bebb5 0000000000001eff 000002cfd82e9000 000002cfd80bc000 0000000000001011 000003d93deda412 000003ff8962df98 000003d93de77ce0 000003d93deb011e 00000359c6daf960 Krnl Code: 000003d93deb0112: c020fffe7259 larl %r2,000003d93de7e5c4 000003d93deb0118:
    c0e53fa8beac brasl %r14,000003d9bd3c7e70 #000003d93deb011e: af000000 mc 0,0 >000003d93deb0122: a728ffea lhi %r2,-22 000003d93deb0126: a7f4fe24 brc 15,000003d93deafd6e 000003d93deb012a: 9101f0b0 tm 176(%r15),1 000003d93deb012e: a774fe48 brc 7,000003d93deafdbe 000003d93deb0132: 40a0f0ae sth %r10,174(%r15) Call Trace: [<000003d93deb0122>] kvm_handle_sie_intercept+0x432/0x4d0 [kvm] ([<000003d93deb011e>] kvm_handle_sie_intercept+0x42e/0x4d0 [kvm]) [<000003d93deacc10>] vcpu_post_run+0x1d0/0x3b0 [kvm] [<000003d93deaceda>] __vcpu_run+0xea/0x2d0 [kvm] [<000003d93dead9da>] kvm_arch_vcpu_ioctl_run+0x16a/0x430 [kvm] [<000003d93de93ee0>] kvm_vcpu_ioctl+0x190/0x7c0 [kvm] [<000003d9bd728b4e>] vfs_ioctl+0x2e/0x70 [<000003d9bd72a092>] __s390x_sys_ioctl+0xc2/0xd0 [<000003d9be0e9222>] __do_syscall+0x1f2/0x2e0 [<000003d9be0f9a90>] system_call+0x70/0x98 Last Breaking-Event-Address: [<000003d9bd3c7f58>]
    __warn_printk+0xe8/0xf0 (CVE-2024-45005)

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

远程 CentOS Linux 7 主机上安装的程序包受到 RHSA-2020:0028 公告中提及的多个漏洞影响。

  - 多款 Intel(R) 处理器虚拟客户机操作系统的页表更新不当失效，经过身份验证的用户可利用此漏洞，通过本地访问，造成主机系统拒绝服务。(CVE-2018-12207)

  - 某些利用推测执行的 CPU 上存在 TSX 异步中止情况，经过身份验证的用户可利用此漏洞，通过具有本地访问权的边信道，造成信息泄露。(CVE-2019-11135)

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

远程 CentOS Linux 7 主机上安装的一个程序包受到 RHSA-2020:5561 公告中提及的多个漏洞影响。

  - Google Chrome 87.0.4280.88 之前版本的 V8 中存在未初始化利用漏洞，该漏洞让远程攻击者可以通过构建的 HTML 页面从进程内存中获取敏感信息。(CVE-2020-16042)

  - 系统未正确限制用户提供的某些 blit 值，从而导致某些视频驱动程序上出现堆缓冲区溢出漏洞。此漏洞会影响 Firefox < 84、Thunderbird < 78.6 和 Firefox ESR < 78.6。(CVE-2020-26971)

  - CSS 审查器的某些输入将其混淆，从而导致删除不正确的组件。这可被用作审查器绕过。此漏洞会影响 Firefox < 84、Thunderbird < 78.6 和 Firefox ESR < 78.6。(CVE-2020-26973)

  - 在表封装程序上使用 flex-basis 时，StyleGenericFlexBasis 对象可能已被错误地转换为错误类型。这会导致堆释放后使用、内存损坏和潜在可利用的崩溃。此漏洞会影响 Firefox < 84、Thunderbird < 78.6 和 Firefox ESR < 78.6。
    (CVE-2020-26974)

  - 恶意网页可以使用根据滑流研究构建的技术，暴露内部网络的主机以及用户本机上运行的服务。此漏洞会影响 Firefox < 84、Thunderbird < 78.6 和 Firefox ESR < 78.6。(CVE-2020-26978)

  - 注册具有代理权限的扩展以接收 <all_urls> 时，未针对 view-source URL 触发 proxy.onRequest 回调。尽管 Web 内容无法导航到此类 URL，但打开 View Source 的用户会在无意间泄露其 IP 地址。此漏洞会影响 Firefox < 84、Thunderbird < 78.6 和 Firefox ESR < 78.6。(CVE-2020-35111)

  - Mozilla 开发人员报告 Firefox 83 和 Firefox ESR 78.5 中存在内存安全错误。其中某些错误展示出内存损坏迹象，我们推测如果攻击者进行足够的尝试，则可以利用此漏洞运行任意代码。此漏洞会影响 Firefox < 84、Thunderbird < 78.6 和 Firefox ESR < 78.6。(CVE-2020-35113)

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

远程 CentOS Linux 7 主机上安装的程序包受到 RHSA-2021:3381 公告中提及的多个漏洞影响。

  - 在 net/netfilter/x_tables.c 中发现堆越界写入漏洞，此漏洞影响 Linux v2.6.19-rc1 之后版本。
    攻击者可利用此漏洞，通过用户命名空间获取权限或造成 DoS（通过堆内存损坏）(CVE-2021-22555)

  - Linux 内核 5.12.2 及之前版本中的 net/bluetooth/hci_request.c 存在删除 HCI 控制器的争用条件。(CVE-2021-32399)

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

远程 CentOS Linux 7 主机上安装的一个程序包受到 RHSA-2022:1302 公告中提及的多个漏洞影响。

  - <code>NSSToken</code> 对象通过直接点进行引用，并且可在不同线程上以不安全的方式访问，从而导致释放后使用问题和可能被利用的程序崩溃问题。此漏洞会影响 Thunderbird < 91.8、Firefox < 99 和 Firefox ESR < 91.8。(CVE-2022-1097)

  - VR 进程被破坏后，对该进程的引用可能会被保留及使用，从而导致释放后使用问题和可能被利用的程序崩溃问题。此漏洞会影响 Thunderbird < 91.8 和 Firefox ESR < 91.8。(CVE-2022-1196)

  - 导入将密钥泄露指定为吊销原因的已吊销密钥时，Thunderbird 未更新尚未吊销的密钥的现有副本，并将现有密钥保留为未吊销密钥。使用其他吊销原因或未指定吊销原因的吊销语句未受影响。此漏洞会影响 Thunderbird < 91.8。(CVE-2022-1197)

  - regex 用于实现 Rust 语言的正则表达式。regex crate 具有内置的缓解措施，可防止由不可信正则表达式或受信任的正则表达式匹配的不可信输入造成的拒绝服务攻击。这些（可调整的）缓解措施已提供合理的默认设置来防御攻击。此保证已记录在案，并且被视为 crate 的 API 的一部分。不幸的是，在专用于防止不受信任的正则表达式在解析过程中占用任意时间长度的缓解措施中发现一个缺陷，并且此类缓解措施可以通过构建正则表达式来绕过。因此，攻击者可以通过向接受用户控制的不可信 regex 的服务发送特别构建的 regex 来执行拒绝服务攻击。所有低于或同于 1.5.4 版本的 regex crate 都会受到此问题影响。自 regex 1.5.5 开始，加入补丁。建议接受用户控制的 regex 的所有用户立即升级到最新版 regex crate。不幸的是，目前没有一组固定的问题 regex，攻击者几乎可通过构建无限 regex 来利用此漏洞。
    因此，我们不建议拒绝已知的问题 regex。(CVE-2022-24713)

  - 如果遭入侵的内容进程利用 Register 命令向父进程发送非预期数量的 WebAuthN 扩展，会引发越界写入，从而导致内存损坏和可能遭利用的程序崩溃问题。此漏洞会影响 Thunderbird < 91.8、Firefox < 99 和 Firefox ESR < 91.8。(CVE-2022-28281)

  - 使用带 <code>rel=localization</code> 的链接时，使用者可能会在执行 JavaScript 期间破坏对象，然后通过释放的指针引用该对象，从而触发释放后使用漏洞，最终导致可能遭到利用的崩溃问题。此漏洞会影响 Thunderbird < 91.8、Firefox < 99 和 Firefox ESR < 91.8。(CVE-2022-28282)

  - 为 <code>MLoadTypedArrayElementHole</code> 生成汇编代码时，使用了错误的 AliasSet。与另一个漏洞结合利用时，可造成越界内存读取问题。此漏洞会影响 Thunderbird < 91.8、Firefox < 99 和 Firefox ESR < 91.8。
    (CVE-2022-28285)

  - 由于布局变更，iframe 内容可能在其边框之外呈现。这可导致用户混淆或伪造攻击。此漏洞会影响 Thunderbird < 91.8、Firefox < 99 和 Firefox ESR < 91.8。(CVE-2022-28286)

  - Mozilla 开发人员和社区成员 Nika Layzell、Andrew McCreight、Gabriele Svelto 以及 Mozilla Fuzzing 团队报告 Thunderbird 91.7 中存在内存安全错误。其中某些错误展示出内存损坏迹象，我们推测如果攻击者进行足够的尝试，则可以利用此漏洞运行任意代码。此漏洞会影响 Thunderbird < 91.8、Firefox < 99 和 Firefox ESR < 91.8。
    (CVE-2022-28289)

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

远程 CentOS Linux 6 主机上安装的程序包受到 RHSA-2020:3548 公告中提及的多个漏洞的影响。

  - 在低于 3.18 的 Linux 内核版本中，本地用户可利用 KEYS 子系统，通过涉及特定匹配字段空值的向量，获取权限，或造成拒绝服务（空指针取消引用和系统崩溃），此问题与 keyring.c 中的 keyring_search_iterator 函数相关。(CVE-2017-2647)

  - 在版本为 2.6.32 的 Linux 内核中的 Marvell WiFi 芯片驱动程序中，发现基于堆的缓冲区溢出漏洞。在 STA 连接到 AP 后调用 lbs_ibss_join_existing 函数时，远程攻击者可造成拒绝服务（系统崩溃），或可能执行任意代码。
    (CVE-2019-14896)

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

远程 CentOS Linux 6 主机上存在安装的程序包，该程序包受到 RHSA-2020:4235 公告中所述多个漏洞的影响。

  - 86.0.4240.75 之前版本的 Google Chrome 中支付中的释放后使用，可能允许远程攻击者通过特制的 HTML 页面执行沙盒逃逸。 (CVE-2020-15967)

  - 86.0.4240.75 之前版本的 Google Chrome 的 Blink 中的释放后使用，允许远程攻击者通过构造的 HTML 页面利用堆损坏。 (CVE-2020-15968)

  - 在 Google Chrome 86.0.4240.75 之前的版本中，WebRTC 中存在释放后使用漏洞，使远程攻击者有可能通过构建的 HTML 页面来利用堆损坏。(CVE-2020-15969)

  - 86.0.4240.75 之前版本的 Google Chrome 的 NFC 中释放后使用，可能会允许入侵渲染器进程的远程攻击者通过特制的 HTML 页面执行沙盒逃逸。 (CVE-2020-15970)

  - 在 86.0.4240.75 之前的 Google Chrome 中打印时的释放后使用，会允许破坏渲染器进程的远程攻击者通过特别构建的 HTML 页面执行沙盒逃逸。
    (CVE-2020-15971)

  - 86.0.4240.75 之前版本的 Google Chrome 的音频中释放后使用，允许远程攻击者通过构造的 HTML 页面可能利用堆损坏。 (CVE-2020-15972)

  - 在低于 86.0.4240.75 的版本中，Google Chrome 的扩展中的策略执行不充分，允许攻击者诱使用户安装恶意扩展，从而通过构建的 Chrome Extension 绕过同源策略。 (CVE-2020-15973)

  - 在低于 的 Google Chrome 中，Blink 86.0.4240.75 中的整数溢出允许远程攻击者通过构造的 HTML 页面绕过站点隔离。 (CVE-2020-15974)

  - 在 86.0.4240.75 之前的 Google Chrome 的 SwiftShader 中的整数溢出允许远程攻击者通过构建的 HTML 页面可能利用堆损坏。 (CVE-2020-15975)

  - 低于 86.0.4240.75 的 Android 上 Google Chrome 的 WebXR 的释放后使用允许远程攻击者可能通过构建的 HTML 页面利用堆损坏。 (CVE-2020-15976)

  - 在低于 86.0.4240.75 的 OS X 上，Google Chrome 的对话框中数据验证不充分，允许远程攻击者通过构建的 HTML 页面从磁盘获取敏感信息。 (CVE-2020-15977)

  - 低于 86.0.4240.75 的 Android 上 Google Chrome 的导航中数据验证不足，允许危害渲染器进程的远程攻击者通过构建的 HTML 页面绕过导航限制。 (CVE-2020-15978)

  - 在 86.0.4240.75 之前版本的 Google Chrome 中，V8 中存在不当实现漏洞，远程攻击者可利用此漏洞，通过构建的 HTML 页面恶意利用堆损坏。(CVE-2020-15979)

  - 在低于 86.0.4240.75 的版本中，Android 上的 Google Chrome 的 Intent 策略执行不充分，允许本地攻击者通过构建的 Intent 绕过导航限制。 (CVE-2020-15980)

  - 86.0.4240.75 之前的 Google Chrome 中的音频越界读取允许远程攻击者通过构建的 HTML 页面从进程内存获取潜在敏感信息。 (CVE-2020-15981)

  - 之前的 86.0.4240.75 版本的 Google Chrome 中存在不正确的缓存实现，允许远程攻击者通过构造的 HTML 页面从进程内存获取潜在敏感信息。 (CVE-2020-15982)

  - 在 ChromeOS 之前的版本 86.0.4240.75 中，Google Chrome 的 webUI 数据验证不足，允许本地攻击者通过构造的 HTML 页面绕过内容安全策略。 (CVE-2020-15983)

  - 在 86.0.4240.75 之前的 iOS 上，Google Chrome 中 Omnibox 的策略执行不充分，允许远程攻击者通过构建的 URL 欺骗 Omnibox（URL 栏）的内容。 (CVE-2020-15984)

  - 86.0.4240.75 之前的 Google Chrome 中 Blink 中的不适当实现允许远程攻击者通过构建的 HTML 页面欺骗安全 UI。 (CVE-2020-15985)

  - 86.0.4240.75 之前版本的 Google Chrome 中媒体的整数溢出允许远程攻击者通过构建的 HTML 页面可能利用堆损坏。 (CVE-2020-15986)

  - 86.0.4240.75 之前的 Google Chrome 的 WebRTC 中的释放后使用漏洞允许远程攻击者通过构建的 WebRTC 流可能利用堆损坏。 (CVE-2020-15987)

  - 在 86.0.4240.75 之前的 Windows 上，Google Chrome 中的下载内容策略执行不充分，允许远程攻击者通过构建的 HTML 页面诱骗用户打开文件执行任意代码。
    (CVE-2020-15988)

  - 86.0.4240.75 之前的 Google Chrome 中 PDFium 中的未初始化数据允许远程攻击者通过构建的 PDF 文件从进程内存获取潜在敏感信息。 (CVE-2020-15989)

  - 86.0.4240.75 之前的 Google Chrome 的自动填充中的释放后使用，允许危害渲染器进程的远程攻击者通过构建的 HTML 页面执行沙盒逃逸。
    (CVE-2020-15990)

  - 在 86.0.4240.75 之前版本的 Google Chrome 密码管理器中，释放后使用会允许破坏渲染器进程的远程攻击者通过特别构建的 HTML 页面执行沙盒逃逸。
    (CVE-2020-15991)

  - 在低于 86.0.4240.75 的 Google Chrome 网络中，策略执行不充分，允许危害渲染器进程的远程攻击者通过构造的 HTML 页面绕过同源策略。
    (CVE-2020-15992)

  - 在低于 86.0.4240.75 的 Google Chrome 中，网络中的不当实现允许远程攻击者通过构造的 HTML 页面执行域欺骗。 (CVE-2020-6557)

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

远程 CentOS Linux 7 主机上安装的程序包受到 RHSA-2021:0346 公告中提及的多个漏洞影响。

  - 在 QEMU 5.0.0 及之前所有版本中，处理网络数据包的过程中可能发生断言失败。该问题会影响 e1000e 和 vmxnet3 网络设备。恶意的客户机用户/进程可利用此缺陷中止主机上的 QEMU 进程，导致 hw/net/net_tx_pkt.c 的 net_tx_pkt_add_raw_fragment 中出现拒绝服务情况。(CVE-2020-16092)

  - libslirp 4.2.0 及之前版本的 ip_input.c 内的 ip_reass() 中存在释放后使用漏洞，允许构建的数据包造成拒绝服务。(CVE-2020-1983)

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

远程 CentOS Linux 7 主机上安装的程序包受到 RHSA-2021:0354 公告中提及的多个漏洞影响。

  - 在 5.8 之前的 Linux 内核中，fs/block_dev.c 中的释放后使用漏洞允许本地用户通过利用某些错误字段的不当访问权限，获取特权或造成拒绝服务。
    (CVE-2020-15436)

  - 在 Linux 内核中，IPsec 内的某些网络协议（例如，IPv6 上的 VXLAN 和 GENEVE 隧道）的实现中发现缺陷。在两台主机之间创建加密隧道时，内核未通过加密链接正确地路由隧道数据；而是未经加密即发送数据。这将允许两个端点之间的任何人读取未加密的流量。此漏洞主要威胁数据机密性。(CVE-2020-1749)

  - 在 Linux 内核 5.9.13 及之前版本的 tty 子系统中发现一个锁定问题。
    drivers/tty/tty_jobctrl.c 可允许对 TIOCSPGRP 发动释放后使用攻击，也称为 CID-54ffccbf053b。
    (CVE-2020-29661)

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

正如 RHSA-2020:2516 中所述，远程 CentOS Linux 6 主机上存在安装的程序包，该程序包受到漏洞的影响。

  - 在 libexif 0.6.22 之前的版本中发现问题。EXIF MakerNote 处理中存在多个缓冲区过读，可导致信息泄露和崩溃。这与 CVE-2020-0093 不同。(CVE-2020-13112)

请注意，Nessus 尚未测试此问题，而是只依据应用程序自我报告的版本号进行判断。

远程 CentOS Linux 7 主机上安装的一个程序包受到 RHSA-2020:4163 公告中提及的多个漏洞影响。

  - Mozilla 开发人员报告 Firefox 80 和 Firefox ESR 78.2 中存在内存安全错误。其中某些错误展示出内存损坏迹象，我们推测如果攻击者进行足够的尝试，则可以利用此漏洞运行任意代码。此漏洞会影响 Firefox < 81、Thunderbird < 78.3 和 Firefox ESR < 78.3。(CVE-2020-15673)

  - Firefox 有时会为 DOM 审查器决定删除的 SVG 元素运行 onload 处理程序，从而导致在将攻击者控制的数据粘贴到可编辑内容的元素后执行 JavaScript。此漏洞会影响 Firefox < 81、Thunderbird < 78.3 和 Firefox ESR < 78.3。
    (CVE-2020-15676)

  - 通过利用网站上的开放重定向漏洞，攻击者可以伪造下载文件对话框中显示的站点，以显示原始站点（遭受开放重定向的站点），而不是实际下载文件的站点。此漏洞会影响 Firefox < 81、Thunderbird < 78.3 和 Firefox ESR < 78.3。(CVE-2020-15677)

  - 在滚动过程中递归图形层时，迭代器可能会无效，从而导致潜在的释放后使用。发生这种情况的原因是，函数 APZCTreeManager::ComputeClippedCompositionBounds 未遵守迭代器无效规则。此漏洞会影响 Firefox < 81、Thunderbird < 78.3 和 Firefox ESR < 78.3。(CVE-2020-15678)

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

远程 CentOS Linux 7 主机上安装的程序包受到 RHSA-2020:2104 公告中提及的多个漏洞影响。

  - 在版本低于 4.14.15 的 Linux 内核中的 drivers/i2c/i2c-core-smbus.c 中发现问题。函数 i2c_smbus_xfer_emulated 中存在越界写入。(CVE-2017-18551)

  - 在 Linux 内核 4.14.11 之前的版本中发现问题。kernel/trace/trace.c 文件中的 allocate_trace_buffer 函数可能导致双重释放。(CVE-2017-18595)

  - 在 Linux 内核 5.1.6 及之前的所有版本中，在 arch/powerpc/platforms/pseries/dlpar.c 的 dlpar_parse_cc_property 中发现一个问题。prop->name 中存在未经检查的 kstrdup，攻击者可借此造成拒绝服务（空指针取消引用和系统崩溃）。(CVE-2019-12614)

  - 在 5.2.9 及之前的 Linux 内核的 xfs_setattr_nonsize in fs/xfs/xfs_iops.c 中发现问题。chgrp 因超出磁盘配额限制失败时，XFS 部分插入。xfs_qm_vop_chown_reserve 调用失败后，xfs_setattr_nonsize 无法解锁 ILOCK。其主要为本地 DoS 攻击载体，不过要是 XFS 文件系统通过 NFS 被导出作为实例，也可导致远程 DoS。
    (CVE-2019-15538)

  - 在 Linux 内核 5.0.21 中，挂载构建的 ext4 文件系统图像、执行某些操作及卸载可在 fs/ext4/super.c 的 ext4_put_super 中导致释放后使用，此漏洞与 fs/ext4/super.c 中的 dump_orphan_list 有关。(CVE-2019-19447)

  - 在 Linux 内核 5.3.12 之前的版本中，drivers/input/ff-memless.c 驱动程序中存在恶意 USB 设备造成的释放后使用错误（又称为 CID-fa3a5a1880c9）。(CVE-2019-19524)

  - 在 Linux 内核 5.4.0-rc2 中，kernel/trace/blktrace.c 的 __blk_add_trace 函数中存在释放后使用（读取）（用于填充 blk_io_trace 结构，并将其置于 per-CPU 子缓冲区）。(CVE-2019-19768)

  - 在 i2c 驱动程序的 Android 内核中，由于内存损坏，可能存在越界写入漏洞。这可能会导致本地权限提升，并需要系统执行权限。无需用户交互即可利用漏洞。(CVE-2019-9454)

  - 在 Linux 内核 SELinux 子系统 5.7 之前的版本中，发现空指针取消引用缺陷。
    通过“ebitmap_netlbl_import”例程将商业 IP 安全选项 (CIPSO) 协议的类别位图导入 SELinux 可扩展位图时出现此缺陷。在处理“cipso_v4_parsetag_rbm”例程中的 CIPSO 限制位图标签时，会设置安全属性以指示存在类别位图，即使尚未分配。此问题导致将相同类别位图导入 SELinux 时出现空指针取消引用问题。此缺陷允许远程网络用户造成系统内核崩溃，进而导致拒绝服务。(CVE-2020-10711)

  - 在 Linux 内核 3.16 至 5.5.6 版本中发现一个问题。drivers/block/floppy.c 中的 set_fdc 会导致 wait_til_ready 越界读取，这是因为在分配 FDC 索引前未检查其是否存在错误，也称为 CID-2e90ca68b0d2。(CVE-2020-9383)

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

远程 CentOS Linux 7 主机上安装的程序包受到 RHSA-2021:3293 公告中提及的多个漏洞影响。

  - Oracle Java SE 的 Java SE、Oracle GraalVM Enterprise Edition 产品中的漏洞（组件：
    Networking）。支持的版本中受影响的是 Java SE：7u301、8u291、11.0.11、16.0.1；Oracle GraalVM Enterprise Edition：20.3.2 和 21.1.0。此漏洞较难受到攻击，其允许未经身份验证的攻击者通过多种协议进行网络访问，从而破坏 Java SE 和 Oracle GraalVM Enterprise Edition。除攻击者以外的他人进行交互是实现成功攻击的必要条件。成功利用此漏洞进行攻击可导致在未经授权的情况下，对 Java SE、Oracle GraalVM Enterprise Edition 可访问数据的子集进行读取访问。注意：此漏洞适用于需加载并运行不可信代码（如来自互联网的代码）且安全性依赖于 Java 沙盒的 Java 部署，该部署通常在需在沙盒中运行 Java Web Start 应用程序或需在沙盒中运行 Java 小程序的客户端上。此漏洞不适用于仅加载并运行可信代码（如管理员安装的代码）的 Java 部署，此部署通常存在于服务器上。(CVE-2021-2341)

  - Oracle Java SE 的 Java SE、Oracle GraalVM Enterprise Edition 产品中的漏洞（组件：
    Library）。支持的版本中受影响的是 Java SE：7u301、8u291、11.0.11、16.0.1；Oracle GraalVM Enterprise Edition：20.3.2 和 21.1.0。此漏洞较容易受到攻击，其允许未经身份验证的攻击者通过多种协议进行网络访问，从而破坏 Java SE 和 Oracle GraalVM Enterprise Edition。
    除攻击者以外的他人进行交互是实现成功攻击的必要条件。成功利用此漏洞进行攻击可导致在未经授权的情况下更新、插入或删除某些 Java SE、Oracle GraalVM Enterprise Edition 可访问数据的访问权限。注意：此漏洞适用于需加载并运行不可信代码（如来自互联网的代码）且安全性依赖于 Java 沙盒的 Java 部署，该部署通常在需在沙盒中运行 Java Web Start 应用程序或需在沙盒中运行 Java 小程序的客户端上。此漏洞不适用于仅加载并运行可信代码（如管理员安装的代码）的 Java 部署，此部署通常存在于服务器上。(CVE-2021-2369)

  - Oracle Java SE 的 Java SE 产品中的漏洞（组件：JNDI）。受影响的支持版本为 Java SE: 7u301。难以利用的漏洞允许未经身份验证的攻击者通过多种协议进行网络访问，从而破坏 Java SE。成功利用此漏洞进行攻击可导致在未经授权的情况下造成 Java SE 部分拒绝服务（部分 DOS）。注意：此漏洞适用于需加载并运行不可信代码（如来自互联网的代码）且安全性依赖于 Java 沙盒的 Java 部署，该部署通常在需在沙盒中运行 Java Web Start 应用程序或需在沙盒中运行 Java 小程序的客户端上。此漏洞也可通过使用指定组件中的 API 加以利用，如通过向 API 提供数据的 Web 服务。
    (CVE-2021-2432)

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

远程 CentOS Linux 7 主机上安装的多个程序包受到 RHSA-2020:1209 公告中提及的一个漏洞影响。

  - 在 QEMU 4.2.0 所使用的 libslirp 4.1.0 中，tcp_subr.c 误用 snprintf 返回值，导致随后的代码中出现缓冲区溢出。(CVE-2020-8608)

请注意，Nessus 尚未测试此问题，而是只依据应用程序自我报告的版本号进行判断。

远程 CentOS Linux 7 主机上安装的多个程序包受到 RHSA-2021:3439 公告中提及的一个漏洞影响。

  - 在 Linux 内核的流量控制网络子系统更改分类过滤时，于路由决策分类器发现一个可导致释放后使用问题的缺陷。
    本地非特权用户可利用此缺陷升级其在系统中的权限。此漏洞最大的威胁在于机密性、完整性，以及系统可用性。(CVE-2021-3715)

请注意，Nessus 尚未测试此问题，而是只依据应用程序自我报告的版本号进行判断。

远程 CentOS Linux 7 主机上安装的一个程序包受到 RHSA-2022:9079 公告中提及的多个漏洞影响。

  - 如果 Thunderbird 用户从 HTML 电子邮件引用（例如通过回复电子邮件），并且该电子邮件包含具有 POSTER 属性的 VIDEO 标记或具有 DATA 属性的 OBJECT 标记，则无论阻断远程内容的配置如何，都可以对引用的远程 URL 执行网络请求。
    从 POSTER 属性加载的图像显示在编辑器窗口中。攻击者可以利用这些问题获得更多功能，从而对尚未修复大约 3 个月前所报告的 CVE-2022-3033 漏洞的版本执行攻击。此漏洞会影响 Thunderbird < 102.5.1。
    (CVE-2022-45414)

  - 危害内容进程的攻击者可通过与剪贴板相关的 IPC 消息部分转义沙盒以读取任意文件。<br>*此缺陷仅影响 Linux 系统上的 Thunderbird。其他操作系统不受影响。* 此漏洞会影响 Firefox < 108、Firefox ESR < 102.6 和 Thunderbird < 102.6。(CVE-2022-46872)

  - 具有长文件名的文件可被截断以删除有效的扩展名，而在其位置留下恶意的扩展名。这可能导致混淆用户和执行恶意代码。<br/>*注意*：此问题最初包含在针对 Thunderbird 102.6的公告中，但是由于省略了一个修补程序（特定于 Thunderbird），导致此问题实际上已在 Thunderbird 102.6.1中得到修复。此漏洞会影响 Firefox < 108、Thunderbird < 102.6.1、Thunderbird < 102.6 和 Firefox ESR < 102.6。(CVE-2022-46874)

  - Mozilla 开发人员 Randell Jesup、Valentin Gosu、Olli Pettay 及 Mozilla Fuzzing 团队报告 Thunderbird 102.5 中存在内存安全错误。其中某些错误展示出内存损坏迹象，我们推测如果攻击者进行足够的尝试，则可以利用此漏洞运行任意代码。此漏洞会影响 Firefox < 108、Firefox ESR < 102.6 和 Thunderbird < 102.6。(CVE-2022-46878)

  - 缺少与 tex 单位有关的检查，可能导致释放后使用和可能被利用的崩溃。<br />*注意*：在深入了解 问题的影响后，此公告已于 2022 年 12 月 13 日添加。此补丁包含在 Firefox 105 的原始版本中。该漏洞影响 Firefox ESR < 102.6、Firefox < 105 和 Thunderbird < 102.6。(CVE-2022-46880)

  - WebGL 中的一项优化在某些情况下不正确，并且可能导致内存损坏和潜在可利用的崩溃。 *注意*：在深入了解 问题的影响后，此公告于 2022 年 12 月 13 日添加。此补丁包含在 Firefox 106 的原始版本中。此漏洞会影响 Firefox < 106、Firefox ESR < 102.6 和 Thunderbird < 102.6。(CVE-2022-46881)

  - WebGL 扩展程序中的释放后使用可能导致潜在的可利用崩溃。此漏洞会影响 Firefox < 107、Firefox ESR < 102.6 和 Thunderbird < 102.6。(CVE-2022-46882)

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

远程 CentOS Linux 7 主机上安装的程序包受到 RHSA-2021:0336 公告中提及的多个漏洞影响。

  - 在 5.8 之前的 Linux 内核中，fs/block_dev.c 中的释放后使用漏洞允许本地用户通过利用某些错误字段的不当访问权限，获取特权或造成拒绝服务。
    (CVE-2020-15436)

  - 在 Linux 内核 NFS（网络文件系统）功能中进行文件或目录修改期间，在用户使用 NFSv4.2 版或更高版本（如果两者同时通过非使用新 NFSv4.2 的另一进程访问 NFS）创建和删除对象的方式中发现 umask 错误缺陷。具有 NFS 访问权限的用户可利用此缺陷耗尽资源，从而导致拒绝服务。(CVE-2020-35513)

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

远程 CentOS Linux 7 主机上安装的程序包受到 RHSA-2020:2117 公告中提及的多个漏洞影响。

  - 在 1.14.5之前的版本 Buildah 中发现一个路径遍历缺陷。此缺陷可让攻击者诱骗用户构建在 HTTP(s) 服务器上托管的恶意容器图像，然后将文件写入至用户系统中该用户拥有权限的任何位置。 (CVE-2020-10696)

  - GPGME 库在 0.1.1 之前的 proglottis Go 封装程序存在释放后使用，这一点已由 Docker 或 CRI-O 用于容器映像拉取证实。这会导致 GPG 签名验证期间发生崩溃或潜在的代码执行。 (CVE-2020-8945)

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

远程 CentOS Linux 7 主机上安装的程序包受到 RHSA-2021:2260 公告中提及的多个漏洞影响。

  - 在 1.0.1 之前版本的 libwebp 中，PutLE16() 中发现基于堆的缓冲区溢出。 (CVE-2018-25011)

  - 在版本 1.0.1 之前的 libwebp 中发现一个缺陷。函数 WebPDecodeRGBInto 中可能存在基于堆的缓冲区溢出，这是无效的缓冲区大小检查所致。此漏洞最大的威胁在于数据机密性和完整性，以及系统可用性。(CVE-2020-36328)

  - 在版本 1.0.1 之前的 libwebp 中发现一个缺陷。发现一个释放后使用缺陷，这是线程过早终止所致。此漏洞最大的威胁在于数据机密性和完整性，以及系统可用性。(CVE-2020-36329)

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

远程 CentOS Linux 7 主机上安装的多个程序包受到 RHSA-2024:3304 公告中提及的一个漏洞影响。

  - 文档基金会 LibreOffice 的 GStreamer 集成中存在不正确的输入验证漏洞，允许攻击者执行任意 GStreamer 插件。在受影响的版本中，在向 GStreamer 传递嵌入视频的文件名时未对其进行充分转义，从而使攻击者能够根据目标系统上安装的插件运行任意 gstreamer 插件。(CVE-2023-6185)

请注意，Nessus 尚未测试此问题，而是只依据应用程序自我报告的版本号进行判断。

ID	名称	严重性
242071	CentOS 9libxml2-2.9.13-10.el9	critical
242070	CentOS 9kernel-5.14.0-598.el9	high
241518	CentOS 9bzip2-1.0.8-10.el9	critical
241454	CentOS 9：ncurses-6.2-12.20210508.el9	high
238237	CentOS 9：libarchive-3.5.3-5.el9	medium
237260	CentOS 9：kernel-5.14.0-587.el9	high
236987	CentOS 9：kernel-5.14.0-585.el9	high
235716	CentOS 9：kernel-5.14.0-583.el9	medium
235376	CentOS 9：kernel-5.14.0-582.el9	medium
234895	CentOS 9：kernel-5.14.0-580.el9	medium
234322	CentOS 9：kernel-5.14.0-578.el9	high
233578	CentOS 9 : kernel-5.14.0-575.el9	high
233298	CentOS 9 : kernel-5.14.0-573.el9	high
232849	CentOS 9: kernel-5.14.0-572.el9	high
217011	CentOS 9 : libxml2-2.9.13-9.el9	high
217010	CentOS 9：microcode_ctl-20250211-1.el9	high
216704	CentOS 9：openssh-8.7p1-45.el9	medium
215234	CentOS 9：gcc-11.5.0-5.el9	medium
215233	CentOS 9：kernel-5.14.0-565.el9	high
214888	CentOS 9：kernel-5.14.0-559.el9	high
214579	CentOS 9：kernel-5.14.0-554.el9	high
213504	CentOS 9：microcode_ctl-20241112-1.el9	high
213467	CentOS 9：kernel-5.14.0-547.el9	high
213059	CentOS 9: kernel-5.14.0-542.el9	high
212193	CentOS 9：kernel-5.14.0-539.el9	medium
212094	CentOS 9：kernel-5.14.0-536.el9	high
212093	CentOS 9：tuned-2.24.0-2.el9	high
211516	1CentOS 9: kernel-5.14.0-529.el9	high
210768	CentOS 9：expat-2.5.0-4.el9	medium
210767	CentOS 9：kernel-5.14.0-527.el9	medium
208962	CentOS 9：kernel-5.14.0-516.el9	high
208653	CentOS 7：kpatch-patch (RHSA-2020:0028)	medium
208652	CentOS 7: firefox (RHSA-2020:5561)	high
208651	CentOS 7：kpatch-patch (RHSA-2021:3381)	high
208650	CentOS 7：thunderbird (RHSA-2022:1302)	high
208649	CentOS 6：内核 (RHSA-2020:3548)	critical
208648	CentOS 6：chromium-browser (RHSA-2020:4235)	high
208647	CentOS 7：qemu-kvm-ma (RHSA-2021:0346)	medium
208646	CentOS 7：kernel-alt (RHSA-2021:0354)	high
208645	CentOS 6：libexif (RHSA-2020:2516)	critical
208644	CentOS 7：thunderbird (RHSA-2020:4163)	high
208643	CentOS 7：kernel-alt (RHSA-2020:2104)	high
208642	CentOS 7：java-1.7.1-ibm (RHSA-2021:3293)	low
208641	CentOS 7：qemu-kvm-ma (RHSA-2020:1209)	medium
208640	CentOS 7：kernel-rt (RHSA-2021:3439)	high
208639	CentOS 7：thunderbird (RHSA-2022:9079)	critical
208638	CentOS 7：内核 (RHSA-2021:0336)	medium
208637	CentOS 7：podman (RHSA-2020:2117)	high
208636	CentOS 7：libwebp (RHSA-2021:2260)	critical
208635	CentOS 7：libreoffice (RHSA-2024:3304)	high

检测

Nessus 的 CentOS Local Security Checks 系列

critical

high

critical

high

medium

high

high

medium

medium

medium

high

high

high

high

high

high

medium

medium

high

high

high

high

high

high

medium

high

high

high

medium

medium

high

medium

high

high

high

critical

high

medium

high

critical

high

high

low

medium

high

critical

medium

high

critical

high