如公告 TuxCare CENTOS7：CLSA-2026：1780133416 所述，CentOS Linux 7 主机上存在安装的程序包，该漏洞会受到多个漏洞的影响。

  - 已修复 Linux 内核中的下列漏洞：nvme-rdma: fix possible use-after-free in transport error_recovery work While nvme_rdma_submit_async_event_work is checking the ctrl and queue state before preparing the AER command and scheduling io_work, in order to fully prevent a race where this check is not reliable the error recovery work must flush async_event_work before continuing to destroy the admin queue after setting the ctrl state to RESETTING such that there is no race .submit_async_event and the error recovery handler itself changing the ctrl state. (CVE-2022-48788)

  - 已修复 Linux 内核中的下列漏洞：hwmon: (ibmpex) Fix possible UAF when ibmpex_register_bmc() fails Smatch report warning as follows: drivers/hwmon/ibmpex.c:509 ibmpex_register_bmc() warn: '&data->list' not removed from list If ibmpex_find_sensors() fails in ibmpex_register_bmc(), data will be freed, but data->list will not be removed from driver_data.bmc_data, then list traversal may cause UAF. Fix by removeing it from driver_data.bmc_data before free().
    (CVE-2022-49029)

  - 已修复 Linux 内核中的下列漏洞：Input: powermate - fix use-after-free in powermate_config_complete syzbot has found a use-after-free bug [1] in the powermate driver. This happens when the device is disconnected, which leads to a memory free from the powermate_device struct.
    When an asynchronous control message completes after the kfree and its callback is invoked, the lock does not exist anymore and hence the bug. Use usb_kill_urb() on pm->config to cancel any in-progress requests upon device disconnection. [1] https://syzkaller.appspot.com/bug?extid=0434ac83f907a1dbdd1e(CVE-2023-52475)

  - 已修复 Linux 内核中的下列漏洞：cifs: Fix use-after-free in rdata->read_into_pages() When the network status is unstable, use-after-free may occur when read data from the server. BUG: KASAN: use-after-free in readpages_fill_pages+0x14c/0x7e0 Call Trace: <TASK> dump_stack_lvl+0x38/0x4c print_report+0x16f/0x4a6 kasan_report+0xb7/0x130 readpages_fill_pages+0x14c/0x7e0 cifs_readv_receive+0x46d/0xa40 cifs_demultiplex_thread+0x121c/0x1490 kthread+0x16b/0x1a0 ret_from_fork+0x2c/0x50 </TASK> Allocated by task 2535: kasan_save_stack+0x22/0x50 kasan_set_track+0x25/0x30 __kasan_kmalloc+0x82/0x90 cifs_readdata_direct_alloc+0x2c/0x110 cifs_readdata_alloc+0x2d/0x60 cifs_readahead+0x393/0xfe0 read_pages+0x12f/0x470 page_cache_ra_unbounded+0x1b1/0x240 filemap_get_pages+0x1c8/0x9a0 filemap_read+0x1c0/0x540 cifs_strict_readv+0x21b/0x240 vfs_read+0x395/0x4b0 ksys_read+0xb8/0x150 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc Freed by task 79: kasan_save_stack+0x22/0x50 kasan_set_track+0x25/0x30 kasan_save_free_info+0x2e/0x50 __kasan_slab_free+0x10e/0x1a0
    __kmem_cache_free+0x7a/0x1a0 cifs_readdata_release+0x49/0x60 process_one_work+0x46c/0x760 worker_thread+0x2a4/0x6f0 kthread+0x16b/0x1a0 ret_from_fork+0x2c/0x50 Last potentially related work creation: kasan_save_stack+0x22/0x50 __kasan_record_aux_stack+0x95/0xb0 insert_work+0x2b/0x130
    __queue_work+0x1fe/0x660 queue_work_on+0x4b/0x60 smb2_readv_callback+0x396/0x800 cifs_abort_connection+0x474/0x6a0 cifs_reconnect+0x5cb/0xa50 cifs_readv_from_socket.cold+0x22/0x6c cifs_read_page_from_socket+0xc1/0x100 readpages_fill_pages.cold+0x2f/0x46 cifs_readv_receive+0x46d/0xa40 cifs_demultiplex_thread+0x121c/0x1490 kthread+0x16b/0x1a0 ret_from_fork+0x2c/0x50 The following function calls will cause UAF of the rdata pointer. readpages_fill_pages cifs_read_page_from_socket cifs_readv_from_socket cifs_reconnect __cifs_reconnect cifs_abort_connection mid->callback() --> smb2_readv_callback queue_work(&rdata->work) # if the worker completes first, # the rdata is freed cifs_readv_complete kref_put cifs_readdata_release kfree(rdata) return rdata->... # UAF in readpages_fill_pages() Similarly, this problem also occurs in the uncache_fill_pages(). Fix this by adjusts the order of condition judgment in the return statement. (CVE-2023-52741)

  - 已修复 Linux 内核中的下列漏洞：ALSA: hda/via: Avoid potential array out-of-bound in add_secret_dac_path() snd_hda_get_connections() can return a negative error code. It may lead to accessing 'conn' array at a negative index. Found by Linux Verification Center (linuxtesting.org) with SVACE. (CVE-2023-52988)

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

CentOS Linux 8 主机上存在安装的程序包，该程序包受到 TuxCare CENTOS-STREAM8：CLSA-2026：1780132980 公告中提及的多个漏洞的影响。

  - Linux 内核 5.12.14 中的 kernel/module.c 未正确处理签名验证，又称为 CID-0c18f29aae7c。如果没有CONFIG_MODULE_SIG，则不会针对 module.sig_enforce=1 命令行参数验证内核模块已签名以通过init_module加载。（CVE-2021-35039）

  - 在 5.13.4 之前的 Linux 内核的 drivers/char/virtio_console.c 中，不受信任的设备提供超过缓冲区大小的 buf->len 值时可以触发数据损坏或丢失。注意：供应商表示，所述数据损坏在任何现有使用案例中都不属于漏洞；添加长度验证只是为了在面对主机 OS 异常行为时保持稳定 (CVE-2021-38160)

  - Linux 内核的 net/bluetooth/l2cap_core.c 的 l2cap_connect 和 l2cap_le_connect_req 函数中存在释放后使用漏洞，可能允许通过蓝牙（分别）远程执行代码和泄漏内核内存。如果在受害者附近，远程攻击者可通过蓝牙执行泄露内核内存的代码。我们建议升级过去的提交 https://www.google.com/url https://github.com/torvalds/linux/commit/711f8c3fb3db61897080468586b970c87c61d9e4 https://www.google.com/url (CVE-2022-42896)

  - 已修复 Linux 内核中的下列漏洞：tracing: Fix potential double free in create_var_ref() In create_var_ref(), init_var_ref() is called to initialize the fields of variable ref_field, which is allocated in the previous function call to create_hist_field(). Function init_var_ref() allocates the corresponding fields such as ref_field->system, but frees these fields when the function encounters an error. The caller later calls destroy_hist_field() to conduct error handling, which frees the fields and the variable itself. This results in double free of the fields which are already freed in the previous function. Fix this by storing NULL to the corresponding fields when they are freed in init_var_ref(). (CVE-2022-49410)

  - 已修复 Linux 内核中的下列漏洞：HID: elan: Fix potential double free in elan_input_configured 'input' is a managed resource allocated with devm_input_allocate_device(), so there is no need to call input_free_device() explicitly or there will be a double free. According to the doc of devm_input_allocate_device(): * Managed input devices do not need to be explicitly unregistered or
    * freed as it will be done automatically when owner device unbinds from * its driver (or binding fails).
    (CVE-2022-49508)

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

远程主机上安装的内核版本低于 5.15.104-63.140。因此，会受到 ALAS2KERNEL-5.15-2023-019 公告中提及的多个漏洞影响。

    在 Linux 内核中，以下漏洞已修复：

    ext4在 ext4_mb_clear_bb() 中使用之前必须验证块范围 (CVE-2022-50021)

    Linux 内核性能事件系统中存在一个释放后使用漏洞，攻击者可利用此漏洞实现本地特权提升。

    perf_group_detach 函数在调用 add_event_to_groups() 前未检查事件同级组件的 attach_state，但是 remove_on_exec 可以在从其群组分离之前调用 list_del_event()，从而可以使用悬摆指针造成释放后使用漏洞。

    我们建议升级过去的提交 fd0815f632c24878e325821943edccc7fde947a2。(CVE-2023-2235)

    在 6.2.8 及之前版本的 Linux 内核的 arch/x86/kvm/vmx/nested.c 中发现了一个问题。x86_64 上的 nVMX 缺少对 CR0 和 CR4 的一致性检查。(CVE-2023-30456)

    在 Linux 内核中，以下漏洞已修复：

    ftrace：修复索引为 0 时 lookup_rec() 中的无效地址访问 (CVE-2023-53075)

    在 Linux 内核中，以下漏洞已修复：

    drm/shmem-helper删除错误路径中另一个错误的放置 (CVE-2023-53084)

    在 Linux 内核中，以下漏洞已修复：

    drm/i915/active修复将非空闲屏障误用为屏障跟踪器 (CVE-2023-53087)

    在 Linux 内核中，以下漏洞已修复：

    ext4：修复 ext4_xattr_delete_inode 中任务挂起（CVE-2023-53089）

    在 Linux 内核中，以下漏洞已修复：

    ext4如果 s_journal_inum 在日志重播后发生更改则更新 s_journal_inum (CVE-2023-53091)

    在 Linux 内核中，以下漏洞已修复：

    互连修复释放节点时的内存泄漏 (CVE-2023-53096)

    在 Linux 内核中，以下漏洞已修复：

    ext4：修复 ext4_update_inline_data 中的警告 (CVE-2023-53100)

    在 Linux 内核中，以下漏洞已修复：

    ext4：初始化 bootloader inode 时，i_disksize 为零 (CVE-2023-53101)

    在 Linux 内核中，以下漏洞已修复：

    bonding如果 non-eth dev enslave 失败则还原绑定的 IFF_SLAVE 标记 (CVE-2023-53103)

    在 Linux 内核中，以下漏洞已修复：

    net：tunnels：对 dev->needed_headroom 的无锁访问进行注解 (CVE-2023-53109)

    在 Linux 内核中，以下漏洞已修复：

    loop修复释放后使用问题 (CVE-2023-53111)

    在 Linux 内核中，以下漏洞已修复：

    fs：关闭文件描述符时防止越界数组推测 (CVE-2023-53117)

    在 Linux 内核中，以下漏洞已修复：

    tcp：可从进程上下文调用 tcp_make_synack() (CVE-2023-53121)

    在 Linux 内核中，以下漏洞已修复：

    PCIs390通过按功能热插拔修复 PCI 资源的释放后使用 (CVE-2023-53123)

    在 Linux 内核中，以下漏洞已修复：

    SUNRPC：修复服务器关机泄漏 (CVE-2023-53131)

    在 Linux 内核中，以下漏洞已修复：

    bpfsockmap修复当 len 为 tcp_bpf_recvmsg_parser() 中的 0 时出现的无限循环错误 (CVE-2023-53133)

    在 Linux 内核中，以下漏洞已修复：

    af_unix修复 OOB 支持中的结构 pid 泄漏 (CVE-2023-53136)

    在 Linux 内核中，以下漏洞已修复：

    ext4：修复移动目录时可能发生损坏的问题 (CVE-2023-53137)

    在 Linux 内核中，以下漏洞已修复：

    scsicore提前删除 /proc/scsi/${proc_name} 目录 (CVE-2023-53140)

    在 Linux 内核中，以下漏洞已修复：

    ila：不在 ila_xlat_nl_cmd_get_mapping() 中生成空消息 (CVE-2023-53141)

    在 Linux 内核中，以下漏洞已修复：

    ext4：修复 1k 块文件系统上的另一个 off-by-one fsmap 错误 (CVE-2023-53143)

    在 Linux 内核中，以下漏洞已修复：

    x86/resctrl清除使用之前和之后的 staged_config[] (CVE-2023-53169)

    在 Linux 内核中，以下漏洞已修复：

    arm64efi使 efi_rt_lock 成为 raw_spinlock (CVE-2023-53216)

    在 Linux 内核中，以下漏洞已修复：

    KVMVMX修复因未初始化 current_vmcs 造成的崩溃 (CVE-2023-53756)

    在 Linux 内核中，以下漏洞已修复：

    iommu/amd为 ivrs_acpihid 命令行参数添加长度限制 (CVE-2023-54057)

Tenable 已直接从测试产品的安全公告中提取上述描述块。

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

CentOS Linux 8.5 主机上存在安装的程序包，该程序包受到 TuxCare CENTOS8.5：CLSA-2026：U 1771077729公告中提及的多个漏洞的影响。

  - 已修复 Linux 内核中的下列漏洞：pid: take a reference when initializing `cad_pid` During boot, kernel_init_freeable() initializes `cad_pid` to the init task's struct pid. Later on, we may change `cad_pid` via a sysctl, and when this happens proc_do_cad_pid() will increment the refcount on the new pid via get_pid(), and will decrement the refcount on the old pid via put_pid(). As we never called get_pid() when we initialized `cad_pid`, we decrement a reference we never incremented, can therefore free the init task's struct pid early. As there can be dangling references to the struct pid, we can later encounter a use-after-free (e.g. when delivering signals). This was spotted when fuzzing v5.13-rc3 with Syzkaller, but seems to have been around since the conversion of `cad_pid` to struct pid in commit 9ec52099e4b8 ([PATCH] replace cad_pid by a struct pid) from the pre-KASAN stone age of v2.6.19. Fix this by getting a reference to the init task's struct pid when we assign it to `cad_pid`.
    Full KASAN splat below. ================================================================== BUG: KASAN:
    use-after-free in ns_of_pid include/linux/pid.h:153 [inline] BUG: KASAN: use-after-free in task_active_pid_ns+0xc0/0xc8 kernel/pid.c:509 Read of size 4 at addr ffff23794dda0004 by task syz-executor.0/273 CPU: 1 PID: 273 Comm: syz-executor.0 Not tainted 5.12.0-00001-g9aef892b2d15 #1 Hardware name: linux,dummy-virt (DT) Call trace: ns_of_pid include/linux/pid.h:153 [inline] task_active_pid_ns+0xc0/0xc8 kernel/pid.c:509 do_notify_parent+0x308/0xe60 kernel/signal.c:1950 exit_notify kernel/exit.c:682 [inline] do_exit+0x2334/0x2bd0 kernel/exit.c:845 do_group_exit+0x108/0x2c8 kernel/exit.c:922 get_signal+0x4e4/0x2a88 kernel/signal.c:2781 do_signal arch/arm64/kernel/signal.c:882 [inline] do_notify_resume+0x300/0x970 arch/arm64/kernel/signal.c:936 work_pending+0xc/0x2dc Allocated by task 0: slab_post_alloc_hook+0x50/0x5c0 mm/slab.h:516 slab_alloc_node mm/slub.c:2907 [inline] slab_alloc mm/slub.c:2915 [inline] kmem_cache_alloc+0x1f4/0x4c0 mm/slub.c:2920 alloc_pid+0xdc/0xc00 kernel/pid.c:180 copy_process+0x2794/0x5e18 kernel/fork.c:2129 kernel_clone+0x194/0x13c8 kernel/fork.c:2500 kernel_thread+0xd4/0x110 kernel/fork.c:2552 rest_init+0x44/0x4a0 init/main.c:687 arch_call_rest_init+0x1c/0x28 start_kernel+0x520/0x554 init/main.c:1064 0x0 Freed by task 270:
    slab_free_hook mm/slub.c:1562 [inline] slab_free_freelist_hook+0x98/0x260 mm/slub.c:1600 slab_free mm/slub.c:3161 [inline] kmem_cache_free+0x224/0x8e0 mm/slub.c:3177 put_pid.part.4+0xe0/0x1a8 kernel/pid.c:114 put_pid+0x30/0x48 kernel/pid.c:109 proc_do_cad_pid+0x190/0x1b0 kernel/sysctl.c:1401 proc_sys_call_handler+0x338/0x4b0 fs/proc/proc_sysctl.c:591 proc_sys_write+0x34/0x48 fs/proc/proc_sysctl.c:617 call_write_iter include/linux/fs.h:1977 [inline] new_sync_write+0x3ac/0x510 fs/read_write.c:518 vfs_write fs/read_write.c:605 [inline] vfs_write+0x9c4/0x1018 fs/read_write.c:585 ksys_write+0x124/0x240 fs/read_write.c:658 __do_sys_write fs/read_write.c:670 [inline] __se_sys_write fs/read_write.c:667 [inline] __arm64_sys_write+0x78/0xb0 fs/read_write.c:667 __invoke_syscall arch/arm64/kernel/syscall.c:37 [inline] invoke_syscall arch/arm64/kernel/syscall.c:49 [inline] el0_svc_common.constprop.1+0x16c/0x388 arch/arm64/kernel/syscall.c:129 do_el0_svc+0xf8/0x150 arch/arm64/kernel/syscall.c:168 el0_svc+0x28/0x38 arch/arm64/kernel/entry-common.c:416 el0_sync_handler+0x134/0x180 arch/arm64/kernel/entry-common.c:432 el0_sync+0x154/0x180 arch/arm64/kernel/entry.S:701 The buggy address belongs to the object at ffff23794dda0000 which belongs to the cache pid of size 224 The buggy address is located 4 bytes inside of 224-byte region [ff
    ---truncated--- (CVE-2021-47118)

  - 已修复 Linux 内核中的下列漏洞：scsi: target: Fix WRITE_SAME No Data Buffer crash In newer version of the SBC specs, we have a NDOB bit that indicates there is no data buffer that gets written out. If this bit is set using commands like sg_write_same --ndob we will crash in target_core_iblock/file's execute_write_same handlers when we go to access the se_cmd->t_data_sg because its NULL. This patch adds a check for the NDOB bit in the common WRITE SAME code because we don't support it. And, it adds a check for zero SG elements in each handler in case the initiator tries to send a normal WRITE SAME with no data buffer. (CVE-2022-21546)

  - 已修复 Linux 内核中的下列漏洞：be2net: Fix buffer overflow in be_get_module_eeprom be_cmd_read_port_transceiver_data assumes that it is given a buffer that is at least PAGE_DATA_LEN long, or twice that if the module supports SFF 8472. However, this is not always the case.
    Fix this by passing the desired offset and length to be_cmd_read_port_transceiver_data so that we only copy the bytes once. (CVE-2022-49581)

  - 已修复 Linux 内核中的下列漏洞：dm raid: fix accesses beyond end of raid member array On dm-raid table load (using raid_ctr), dm-raid allocates an array rs->devs[rs->raid_disks] for the raid device members. rs->raid_disks is defined by the number of raid metadata and image tupples passed into the target's constructor. In the case of RAID layout changes being requested, that number can be different from the current number of members for existing raid sets as defined in their superblocks. Example RAID layout changes include: - raid1 legs being added/removed - raid4/5/6/10 number of stripes changed (stripe reshaping) - takeover to higher raid level (e.g. raid5 -> raid6) When accessing array members, rs->raid_disks must be used in control loops instead of the potentially larger value in rs->md.raid_disks. Otherwise it will cause memory access beyond the end of the rs->devs array. Fix this by changing code that is prone to out-of-bounds access. Also fix validate_raid_redundancy() to validate all devices that are added. Also, use braces to help clean up raid_iterate_devices(). The out-of-bounds memory accesses was discovered using KASAN. This commit was verified to pass all LVM2 RAID tests (with KASAN enabled). (CVE-2022-49674)

  - 已修复 Linux 内核中的下列漏洞：tracing: Fix wild-memory-access in register_synth_event() In register_synth_event(), if set_synth_event_print_fmt() failed, then both trace_remove_event_call() and unregister_trace_event() will be called, which means the trace_event_call will call __unregister_trace_event() twice. As the result, the second unregister will causes the wild-memory-access. register_synth_event set_synth_event_print_fmt failed trace_remove_event_call event_remove if call->event.funcs then __unregister_trace_event (first call) unregister_trace_event
    __unregister_trace_event (second call) Fix the bug by avoiding to call the second
    __unregister_trace_event() by checking if the first one is called. general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN PTI KASAN: maybe wild-memory-access in range [0xdead000000000120-0xdead000000000127] CPU: 0 PID: 3807 Comm: modprobe Not tainted 6.1.0-rc1-00186-g76f33a7eedb4 #299 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 RIP: 0010:unregister_trace_event+0x6e/0x280 Code:
    00 fc ff df 4c 89 ea 48 c1 ea 03 80 3c 02 00 0f 85 0e 02 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b 63 08 4c 89 e2 48 c1 ea 03 <80> 3c 02 00 0f 85 e2 01 00 00 49 89 2c 24 48 85 ed 74 28 e8 7a 9b RSP:
    0018:ffff88810413f370 EFLAGS: 00010a06 RAX: dffffc0000000000 RBX: ffff888105d050b0 RCX: 0000000000000000 RDX: 1bd5a00000000024 RSI: ffff888119e276e0 RDI: ffffffff835a8b20 RBP: dead000000000100 R08:
    0000000000000000 R09: fffffbfff0913481 R10: ffffffff8489a407 R11: fffffbfff0913480 R12: dead000000000122 R13: ffff888105d050b8 R14: 0000000000000000 R15: ffff888105d05028 FS: 00007f7823e8d540(0000) GS:ffff888119e00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2:
    00007f7823e7ebec CR3: 000000010a058002 CR4: 0000000000330ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK>
    __create_synth_event+0x1e37/0x1eb0 create_or_delete_synth_event+0x110/0x250 synth_event_run_command+0x2f/0x110 test_gen_synth_cmd+0x170/0x2eb [synth_event_gen_test] synth_event_gen_test_init+0x76/0x9bc [synth_event_gen_test] do_one_initcall+0xdb/0x480 do_init_module+0x1cf/0x680 load_module+0x6a50/0x70a0 __do_sys_finit_module+0x12f/0x1c0 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd (CVE-2022-49799)

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

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

  - ftrace修复 lookup_rec() 中索引为 0 时的无效地址访问KASAN 报告的关注问题缺陷
    KASAN通过任务 modprobe CPU: 2 Comm:
    modprobe 调用跟踪kasan_report __asan_load8 lookup_rec ftrace_location arch_check_ftrace_location check_kprobe_address_safe register_kprobe 在 lookup_rec() 中检查 pg->records[pg->index - 1].ip 时可获取新添加到 ftrace_process_locs() 中的 ftrace_pages_start 的 pg。在第一个 pg->index++ 之前index 为 0 访问 pg->records[-1].ip 将造成此问题。当 pg->index 为 0 时不检查 ip (CVE-2023-53075)

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

远程主机上安装的内核版本低于 5.10.176-157.645。因此，会受到 ALAS2KERNEL-5.10-2024-059 公告中提及的多个漏洞影响。

    在 Linux 内核中，以下漏洞已修复：

    ext4在 ext4_mb_clear_bb() 中使用之前必须验证块范围 (CVE-2022-50021)

    在 Linux 内核中，以下漏洞已修复：

    blockbfq修复“bfqq->bic”可能的 uaf (CVE-2022-50488)

    在 Linux 内核中，以下漏洞已修复：

    seccomp将 copy_seccomp() 移动到无故障路径。 (CVE-2022-50661)

    在 6.2.8 及之前版本的 Linux 内核的 arch/x86/kvm/vmx/nested.c 中发现了一个问题。x86_64 上的 nVMX 缺少对 CR0 和 CR4 的一致性检查。(CVE-2023-30456)

    在 Linux 内核中，以下漏洞已修复：

    ftrace：修复索引为 0 时 lookup_rec() 中的无效地址访问 (CVE-2023-53075)

    在 Linux 内核中，以下漏洞已修复：

    drm/shmem-helper删除错误路径中另一个错误的放置 (CVE-2023-53084)

    在 Linux 内核中，以下漏洞已修复：

    drm/i915/active修复将非空闲屏障误用为屏障跟踪器 (CVE-2023-53087)

    在 Linux 内核中，以下漏洞已修复：

    ext4：修复 ext4_xattr_delete_inode 中任务挂起（CVE-2023-53089）

    在 Linux 内核中，以下漏洞已修复：

    互连修复释放节点时的内存泄漏 (CVE-2023-53096)

    在 Linux 内核中，以下漏洞已修复：

    ext4：修复 ext4_update_inline_data 中的警告 (CVE-2023-53100)

    在 Linux 内核中，以下漏洞已修复：

    ext4：初始化 bootloader inode 时，i_disksize 为零 (CVE-2023-53101)

    在 Linux 内核中，以下漏洞已修复：

    net：tunnels：对 dev->needed_headroom 的无锁访问进行注解 (CVE-2023-53109)

    在 Linux 内核中，以下漏洞已修复：

    i40e修复适配器处于恢复模式时重新启动期间的内核崩溃 (CVE-2023-53114)

    在 Linux 内核中，以下漏洞已修复：

    nvmet：避免 nvmet_req_complete() 中潜在的 UAF (CVE-2023-53116)

    在 Linux 内核中，以下漏洞已修复：

    fs：关闭文件描述符时防止越界数组推测 (CVE-2023-53117)

    在 Linux 内核中，以下漏洞已修复：

    tcp：可从进程上下文调用 tcp_make_synack() (CVE-2023-53121)

    在 Linux 内核中，以下漏洞已修复：

    scsimpt3sas修复 mpt3sas_transport_port_add() 中的空指针访问 (CVE-2023-53124)

    在 Linux 内核中，以下漏洞已修复：

    net：usb：smsc75xx：将数据包长度限制为 skb->len (CVE-2023-53125)

    在 Linux 内核中，以下漏洞已修复：

    SUNRPC：修复服务器关机泄漏 (CVE-2023-53131)

    在 Linux 内核中，以下漏洞已修复：

    bnxt_en避免 TPA 数据的 order-5 内存分配 (CVE-2023-53134)

    在 Linux 内核中，以下漏洞已修复：

    ext4：修复移动目录时可能发生损坏的问题 (CVE-2023-53137)

    在 Linux 内核中，以下漏洞已修复：

    scsicore提前删除 /proc/scsi/${proc_name} 目录 (CVE-2023-53140)

    在 Linux 内核中，以下漏洞已修复：

    ila：不在 ila_xlat_nl_cmd_get_mapping() 中生成空消息 (CVE-2023-53141)

    在 Linux 内核中，以下漏洞已修复：

    ext4：修复 1k 块文件系统上的另一个 off-by-one fsmap 错误 (CVE-2023-53143)

    在 Linux 内核中，以下漏洞已修复：

    arm64efi使 efi_rt_lock 成为 raw_spinlock (CVE-2023-53216)

    在 Linux 内核中，以下漏洞已修复：

    KVMVMX修复因未初始化 current_vmcs 造成的崩溃 (CVE-2023-53756)

    在 Linux 内核中，以下漏洞已修复：

    iommu/amd为 ivrs_acpihid 命令行参数添加长度限制 (CVE-2023-54057)

Tenable 已直接从测试产品的安全公告中提取上述描述块。

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

远程主机上安装的内核版本低于 4.14.311-233.529。因此，该软件受到 ALAS2-2025-2892 公告中提及的多个漏洞影响。

    在 Linux 内核中，以下漏洞已修复：

    ftrace：修复索引为 0 时 lookup_rec() 中的无效地址访问 (CVE-2023-53075)

    在 Linux 内核中，以下漏洞已修复：

    ext4：修复 ext4_xattr_delete_inode 中任务挂起（CVE-2023-53089）

    在 Linux 内核中，以下漏洞已修复：

    ext4：修复 ext4_update_inline_data 中的警告 (CVE-2023-53100)

    在 Linux 内核中，以下漏洞已修复：

    ext4：初始化 bootloader inode 时，i_disksize 为零 (CVE-2023-53101)

    在 Linux 内核中，以下漏洞已修复：

    net：tunnels：对 dev->needed_headroom 的无锁访问进行注解 (CVE-2023-53109)

Tenable 已直接从测试产品的安全公告中提取上述描述块。

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

远程主机上安装的内核版本低于 5.4.238-148.347。因此，会受到 ALAS2KERNEL-5.4-2024-070 公告中提及的多个漏洞影响。

    在 6.2.8 及之前版本的 Linux 内核的 arch/x86/kvm/vmx/nested.c 中发现了一个问题。x86_64 上的 nVMX 缺少对 CR0 和 CR4 的一致性检查。(CVE-2023-30456)

    在 Linux 内核中，以下漏洞已修复：

    ftrace：修复索引为 0 时 lookup_rec() 中的无效地址访问 (CVE-2023-53075)

    在 Linux 内核中，以下漏洞已修复：

    ext4：修复 ext4_xattr_delete_inode 中任务挂起（CVE-2023-53089）

    在 Linux 内核中，以下漏洞已修复：

    ext4：修复 ext4_update_inline_data 中的警告 (CVE-2023-53100)

    在 Linux 内核中，以下漏洞已修复：

    ext4：初始化 bootloader inode 时，i_disksize 为零 (CVE-2023-53101)

    在 Linux 内核中，以下漏洞已修复：

    net：tunnels：对 dev->needed_headroom 的无锁访问进行注解 (CVE-2023-53109)

    在 Linux 内核中，以下漏洞已修复：

    i40e修复适配器处于恢复模式时重新启动期间的内核崩溃 (CVE-2023-53114)

    在 Linux 内核中，以下漏洞已修复：

    nvmet：避免 nvmet_req_complete() 中潜在的 UAF (CVE-2023-53116)

    在 Linux 内核中，以下漏洞已修复：

    fs：关闭文件描述符时防止越界数组推测 (CVE-2023-53117)

    在 Linux 内核中，以下漏洞已修复：

    tcp：可从进程上下文调用 tcp_make_synack() (CVE-2023-53121)

    在 Linux 内核中，以下漏洞已修复：

    scsimpt3sas修复 mpt3sas_transport_port_add() 中的空指针访问 (CVE-2023-53124)

    在 Linux 内核中，以下漏洞已修复：

    net：usb：smsc75xx：将数据包长度限制为 skb->len (CVE-2023-53125)

    在 Linux 内核中，以下漏洞已修复：

    bnxt_en避免 TPA 数据的 order-5 内存分配 (CVE-2023-53134)

    在 Linux 内核中，以下漏洞已修复：

    ext4：修复移动目录时可能发生损坏的问题 (CVE-2023-53137)

    在 Linux 内核中，以下漏洞已修复：

    scsicore提前删除 /proc/scsi/${proc_name} 目录 (CVE-2023-53140)

    在 Linux 内核中，以下漏洞已修复：

    ila：不在 ila_xlat_nl_cmd_get_mapping() 中生成空消息 (CVE-2023-53141)

    在 Linux 内核中，以下漏洞已修复：

    ext4：修复 1k 块文件系统上的另一个 off-by-one fsmap 错误 (CVE-2023-53143)

    在 Linux 内核中，以下漏洞已修复：

    iommu/amd为 ivrs_acpihid 命令行参数添加长度限制 (CVE-2023-54057)

Tenable 已直接从测试产品的安全公告中提取上述描述块。

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

因此，该软件受到 ALAS2023-2023-148 公告中提及的多个漏洞影响。

    在 Linux 内核中，以下漏洞已修复：

    KVMVMX将 /dev/kvm 暴露给用户空间之前进行 _all_ 初始化 (CVE-2022-49932)

    Linux 内核性能事件系统中存在一个释放后使用漏洞，攻击者可利用此漏洞实现本地特权提升。

    perf_group_detach 函数在调用 add_event_to_groups() 前未检查事件同级组件的 attach_state，但是 remove_on_exec 可以在从其群组分离之前调用 list_del_event()，从而可以使用悬摆指针造成释放后使用漏洞。

    我们建议升级过去的提交 fd0815f632c24878e325821943edccc7fde947a2。(CVE-2023-2235)

    在 Linux 内核 6.2.6 及其之前所有版本中，net/tls/tls_main.c 的 do_tls_getsockopt 缺少 lock_sock 调用，从而导致争用条件（造成释放后使用或空指针取消引用）。(CVE-2023-28466)

    在 6.2.8 及之前版本的 Linux 内核的 arch/x86/kvm/vmx/nested.c 中发现了一个问题。x86_64 上的 nVMX 缺少对 CR0 和 CR4 的一致性检查。(CVE-2023-30456)

    在 Linux 内核中，以下漏洞已修复：

    ACPIPPTT修复以避免缺少 PPTT 时 atomic 上下文中的休眠 (CVE-2023-53070)

    在 Linux 内核中，以下漏洞已修复：

    ftrace：修复索引为 0 时 lookup_rec() 中的无效地址访问 (CVE-2023-53075)

    在 Linux 内核中，以下漏洞已修复：

    ocfs2：修复写入失败后的数据损坏 (CVE-2023-53081)

    在 Linux 内核中，以下漏洞已修复：

    drm/shmem-helper删除错误路径中另一个错误的放置 (CVE-2023-53084)

    在 Linux 内核中，以下漏洞已修复：

    drm/i915/active修复将非空闲屏障误用为屏障跟踪器 (CVE-2023-53087)

    在 Linux 内核中，以下漏洞已修复：

    ext4：修复 ext4_xattr_delete_inode 中任务挂起（CVE-2023-53089）

    在 Linux 内核中，以下漏洞已修复：

    ext4如果 s_journal_inum 在日志重播后发生更改则更新 s_journal_inum (CVE-2023-53091)

    在 Linux 内核中，以下漏洞已修复：

    drm/ttm修复空指针取消引用 (CVE-2023-53095)

    在 Linux 内核中，以下漏洞已修复：

    互连修复释放节点时的内存泄漏 (CVE-2023-53096)

    在 Linux 内核中，以下漏洞已修复：

    ext4：修复 ext4_update_inline_data 中的警告 (CVE-2023-53100)

    在 Linux 内核中，以下漏洞已修复：

    ext4：初始化 bootloader inode 时，i_disksize 为零 (CVE-2023-53101)

    在 Linux 内核中，以下漏洞已修复：

    bonding如果 non-eth dev enslave 失败则还原绑定的 IFF_SLAVE 标记 (CVE-2023-53103)

    在 Linux 内核中，以下漏洞已修复：

    veth修复 XDP_REDIRECT 中的释放后使用 (CVE-2023-53107)

    在 Linux 内核中，以下漏洞已修复：

    net：tunnels：对 dev->needed_headroom 的无锁访问进行注解 (CVE-2023-53109)

    在 Linux 内核中，以下漏洞已修复：

    loop修复释放后使用问题 (CVE-2023-53111)

    在 Linux 内核中，以下漏洞已修复：

    drm/i915/sseu修复 max_subslices array-index-out-of-bounds 访问 (CVE-2023-53112)

    在 Linux 内核中，以下漏洞已修复：

    fs：关闭文件描述符时防止越界数组推测 (CVE-2023-53117)

    在 Linux 内核中，以下漏洞已修复：

    tcp：可从进程上下文调用 tcp_make_synack() (CVE-2023-53121)

    在 Linux 内核中，以下漏洞已修复：

    PCIs390通过按功能热插拔修复 PCI 资源的释放后使用 (CVE-2023-53123)

    在 Linux 内核中，以下漏洞已修复：

    SUNRPC：修复服务器关机泄漏 (CVE-2023-53131)

    在 Linux 内核中，以下漏洞已修复：

    bpfsockmap修复当 len 为 tcp_bpf_recvmsg_parser() 中的 0 时出现的无限循环错误 (CVE-2023-53133)

    在 Linux 内核中，以下漏洞已修复：

    af_unix修复 OOB 支持中的结构 pid 泄漏 (CVE-2023-53136)

    在 Linux 内核中，以下漏洞已修复：

    ext4：修复移动目录时可能发生损坏的问题 (CVE-2023-53137)

    在 Linux 内核中，以下漏洞已修复：

    scsicore提前删除 /proc/scsi/${proc_name} 目录 (CVE-2023-53140)

    在 Linux 内核中，以下漏洞已修复：

    ila：不在 ila_xlat_nl_cmd_get_mapping() 中生成空消息 (CVE-2023-53141)

    在 Linux 内核中，以下漏洞已修复：

    ext4：修复 1k 块文件系统上的另一个 off-by-one fsmap 错误 (CVE-2023-53143)

    在 Linux 内核中，以下漏洞已修复：

    x86/resctrl清除使用之前和之后的 staged_config[] (CVE-2023-53169)

Tenable 已直接从测试产品的安全公告中提取上述描述块。

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

如 TuxCare CENTOS8.4：CLSA-2026：1771078945公告所述，CentOS Linux 8.4 主机上存在安装的程序包，该漏洞会受到多个漏洞的影响。

  - 已修复 Linux 内核中的下列漏洞：pid: take a reference when initializing `cad_pid` During boot, kernel_init_freeable() initializes `cad_pid` to the init task's struct pid. Later on, we may change `cad_pid` via a sysctl, and when this happens proc_do_cad_pid() will increment the refcount on the new pid via get_pid(), and will decrement the refcount on the old pid via put_pid(). As we never called get_pid() when we initialized `cad_pid`, we decrement a reference we never incremented, can therefore free the init task's struct pid early. As there can be dangling references to the struct pid, we can later encounter a use-after-free (e.g. when delivering signals). This was spotted when fuzzing v5.13-rc3 with Syzkaller, but seems to have been around since the conversion of `cad_pid` to struct pid in commit 9ec52099e4b8 ([PATCH] replace cad_pid by a struct pid) from the pre-KASAN stone age of v2.6.19. Fix this by getting a reference to the init task's struct pid when we assign it to `cad_pid`.
    Full KASAN splat below. ================================================================== BUG: KASAN:
    use-after-free in ns_of_pid include/linux/pid.h:153 [inline] BUG: KASAN: use-after-free in task_active_pid_ns+0xc0/0xc8 kernel/pid.c:509 Read of size 4 at addr ffff23794dda0004 by task syz-executor.0/273 CPU: 1 PID: 273 Comm: syz-executor.0 Not tainted 5.12.0-00001-g9aef892b2d15 #1 Hardware name: linux,dummy-virt (DT) Call trace: ns_of_pid include/linux/pid.h:153 [inline] task_active_pid_ns+0xc0/0xc8 kernel/pid.c:509 do_notify_parent+0x308/0xe60 kernel/signal.c:1950 exit_notify kernel/exit.c:682 [inline] do_exit+0x2334/0x2bd0 kernel/exit.c:845 do_group_exit+0x108/0x2c8 kernel/exit.c:922 get_signal+0x4e4/0x2a88 kernel/signal.c:2781 do_signal arch/arm64/kernel/signal.c:882 [inline] do_notify_resume+0x300/0x970 arch/arm64/kernel/signal.c:936 work_pending+0xc/0x2dc Allocated by task 0: slab_post_alloc_hook+0x50/0x5c0 mm/slab.h:516 slab_alloc_node mm/slub.c:2907 [inline] slab_alloc mm/slub.c:2915 [inline] kmem_cache_alloc+0x1f4/0x4c0 mm/slub.c:2920 alloc_pid+0xdc/0xc00 kernel/pid.c:180 copy_process+0x2794/0x5e18 kernel/fork.c:2129 kernel_clone+0x194/0x13c8 kernel/fork.c:2500 kernel_thread+0xd4/0x110 kernel/fork.c:2552 rest_init+0x44/0x4a0 init/main.c:687 arch_call_rest_init+0x1c/0x28 start_kernel+0x520/0x554 init/main.c:1064 0x0 Freed by task 270:
    slab_free_hook mm/slub.c:1562 [inline] slab_free_freelist_hook+0x98/0x260 mm/slub.c:1600 slab_free mm/slub.c:3161 [inline] kmem_cache_free+0x224/0x8e0 mm/slub.c:3177 put_pid.part.4+0xe0/0x1a8 kernel/pid.c:114 put_pid+0x30/0x48 kernel/pid.c:109 proc_do_cad_pid+0x190/0x1b0 kernel/sysctl.c:1401 proc_sys_call_handler+0x338/0x4b0 fs/proc/proc_sysctl.c:591 proc_sys_write+0x34/0x48 fs/proc/proc_sysctl.c:617 call_write_iter include/linux/fs.h:1977 [inline] new_sync_write+0x3ac/0x510 fs/read_write.c:518 vfs_write fs/read_write.c:605 [inline] vfs_write+0x9c4/0x1018 fs/read_write.c:585 ksys_write+0x124/0x240 fs/read_write.c:658 __do_sys_write fs/read_write.c:670 [inline] __se_sys_write fs/read_write.c:667 [inline] __arm64_sys_write+0x78/0xb0 fs/read_write.c:667 __invoke_syscall arch/arm64/kernel/syscall.c:37 [inline] invoke_syscall arch/arm64/kernel/syscall.c:49 [inline] el0_svc_common.constprop.1+0x16c/0x388 arch/arm64/kernel/syscall.c:129 do_el0_svc+0xf8/0x150 arch/arm64/kernel/syscall.c:168 el0_svc+0x28/0x38 arch/arm64/kernel/entry-common.c:416 el0_sync_handler+0x134/0x180 arch/arm64/kernel/entry-common.c:432 el0_sync+0x154/0x180 arch/arm64/kernel/entry.S:701 The buggy address belongs to the object at ffff23794dda0000 which belongs to the cache pid of size 224 The buggy address is located 4 bytes inside of 224-byte region [ff
    ---truncated--- (CVE-2021-47118)

  - 已修复 Linux 内核中的下列漏洞：i2c: i801: Don't generate an interrupt on bus reset Now that the i2c-i801 driver supports interrupts, setting the KILL bit in a attempt to recover from a timed out transaction triggers an interrupt. Unfortunately, the interrupt handler (i801_isr) is not prepared for this situation and will try to process the interrupt as if it was signaling the end of a successful transaction. In the case of a block transaction, this can result in an out-of-range memory access. This condition was reproduced several times by syzbot:
    https://syzkaller.appspot.com/bug?extid=ed71512d469895b5b34e https://syzkaller.appspot.com/bug?extid=8c8dedc0ba9e03f6c79e https://syzkaller.appspot.com/bug?extid=c8ff0b6d6c73d81b610e https://syzkaller.appspot.com/bug?extid=33f6c360821c399d69eb https://syzkaller.appspot.com/bug?extid=be15dc0b1933f04b043a https://syzkaller.appspot.com/bug?extid=b4d3fd1dfd53e90afd79 So disable interrupts while trying to reset the bus. Interrupts will be enabled again for the following transaction. (CVE-2021-47153)

  - 已修复 Linux 内核中的下列漏洞：scsi: target: Fix WRITE_SAME No Data Buffer crash In newer version of the SBC specs, we have a NDOB bit that indicates there is no data buffer that gets written out. If this bit is set using commands like sg_write_same --ndob we will crash in target_core_iblock/file's execute_write_same handlers when we go to access the se_cmd->t_data_sg because its NULL. This patch adds a check for the NDOB bit in the common WRITE SAME code because we don't support it. And, it adds a check for zero SG elements in each handler in case the initiator tries to send a normal WRITE SAME with no data buffer. (CVE-2022-21546)

  - 已修复 Linux 内核中的下列漏洞：net/mlx5e: IPoIB, Block PKEY interfaces with less rx queues than parent A user is able to configure an arbitrary number of rx queues when creating an interface via netlink. This doesn't work for child PKEY interfaces because the child interface uses the parent receive channels. Although the child shares the parent's receive channels, the number of rx queues is important for the channel_stats array: the parent's rx channel index is used to access the child's channel_stats. So the array has to be at least as large as the parent's rx queue size for the counting to work correctly and to prevent out of bound accesses. This patch checks for the mentioned scenario and returns an error when trying to create the interface. The error is propagated to the user. (CVE-2022-48883)

  - 已修复 Linux 内核中的下列漏洞：ath9k_htc: fix potential out of bounds access with invalid rxstatus->rs_keyix The rxstatus->rs_keyix eventually gets passed to test_bit() so we need to ensure that it is within the bitmap. drivers/net/wireless/ath/ath9k/common.c:46 ath9k_cmn_rx_accept() error: passing untrusted data 'rx_stats->rs_keyix' to 'test_bit()' (CVE-2022-49503)

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

远程主机上安装的内核版本低于 4.14.311-233.529。因此，该软件受到 ALAS2-2025-2909 公告中提及的多个漏洞影响。

    在 Linux 内核中，以下漏洞已修复：

    ftrace：修复索引为 0 时 lookup_rec() 中的无效地址访问 (CVE-2023-53075)

    在 Linux 内核中，以下漏洞已修复：

    ext4：修复 ext4_xattr_delete_inode 中任务挂起（CVE-2023-53089）

    在 Linux 内核中，以下漏洞已修复：

    ext4：修复 ext4_update_inline_data 中的警告 (CVE-2023-53100)

    在 Linux 内核中，以下漏洞已修复：

    ext4：初始化 bootloader inode 时，i_disksize 为零 (CVE-2023-53101)

    在 Linux 内核中，以下漏洞已修复：

    net：tunnels：对 dev->needed_headroom 的无锁访问进行注解 (CVE-2023-53109)

    在 Linux 内核中，以下漏洞已修复：

    nvmet：避免 nvmet_req_complete() 中潜在的 UAF (CVE-2023-53116)

    在 Linux 内核中，以下漏洞已修复：

    fs：关闭文件描述符时防止越界数组推测 (CVE-2023-53117)

    在 Linux 内核中，以下漏洞已修复：

    tcp：可从进程上下文调用 tcp_make_synack() (CVE-2023-53121)

    在 Linux 内核中，以下漏洞已修复：

    net：usb：smsc75xx：将数据包长度限制为 skb->len (CVE-2023-53125)

    在 Linux 内核中，以下漏洞已修复：

    ila：不在 ila_xlat_nl_cmd_get_mapping() 中生成空消息 (CVE-2023-53141)

    在 Linux 内核中，以下漏洞已修复：

    ext4：修复 1k 块文件系统上的另一个 off-by-one fsmap 错误 (CVE-2023-53143)

Tenable 已直接从测试产品的安全公告中提取上述描述块。

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

AlmaLinux 9.2 主机上存在安装的程序包，该程序包受到 TuxCare ALMALINUX9.2：CLSA-2025：2025：1765463110公告中提及的多个漏洞的影响。

  - 已修复 Linux 内核中的下列漏洞：KVM: Reject attempts to consume or refresh inactive gfn_to_pfn_cache Reject kvm_gpc_check() and kvm_gpc_refresh() if the cache is inactive.
    Not checking the active flag during refresh is particularly egregious, as KVM can end up with a valid, inactive cache, which can lead to a variety of use-after-free bugs, e.g. consuming a NULL kernel pointer or missing an mmu_notifier invalidation due to the cache not being on the list of gfns to invalidate.
    Note, active needs to be set if and only if the cache is on the list of caches, i.e. is reachable via mmu_notifier events. If a relevant mmu_notifier event occurs while the cache is active but not on the list, KVM will not acquire the cache's lock and so will not serailize the mmu_notifier event with active users and/or kvm_gpc_refresh(). A race between KVM_XEN_ATTR_TYPE_SHARED_INFO and KVM_XEN_HVM_EVTCHN_SEND can be exploited to trigger the bug. 1. Deactivate shinfo cache: kvm_xen_hvm_set_attr case KVM_XEN_ATTR_TYPE_SHARED_INFO kvm_gpc_deactivate kvm_gpc_unmap gpc->valid = false gpc->khva = NULL gpc->active = false Result: active = false, valid = false 2. Cause cache refresh: kvm_arch_vm_ioctl case KVM_XEN_HVM_EVTCHN_SEND kvm_xen_hvm_evtchn_send kvm_xen_set_evtchn kvm_xen_set_evtchn_fast kvm_gpc_check return -EWOULDBLOCK because !gpc->valid kvm_xen_set_evtchn_fast return -EWOULDBLOCK kvm_gpc_refresh hva_to_pfn_retry gpc->valid = true gpc->khva = not NULL Result: active = false, valid = true 3. Race ioctl KVM_XEN_HVM_EVTCHN_SEND against ioctl KVM_XEN_ATTR_TYPE_SHARED_INFO: kvm_arch_vm_ioctl case KVM_XEN_HVM_EVTCHN_SEND kvm_xen_hvm_evtchn_send kvm_xen_set_evtchn kvm_xen_set_evtchn_fast read_lock gpc->lock kvm_xen_hvm_set_attr case KVM_XEN_ATTR_TYPE_SHARED_INFO mutex_lock kvm->lock kvm_xen_shared_info_init kvm_gpc_activate gpc->khva = NULL kvm_gpc_check [ Check passes because gpc->valid is still true, even though gpc->khva is already NULL. ] shinfo = gpc->khva pending_bits = shinfo->evtchn_pending CRASH: test_and_set_bit(..., pending_bits) (CVE-2022-49882)

  - 已修复 Linux 内核中的下列漏洞：coresight: Clear the connection field properly coresight devices track their connections (output connections) and hold a reference to the fwnode. When a device goes away, we walk through the devices on the coresight bus and make sure that the references are dropped. This happens both ways: a) For all output connections from the device, drop the reference to the target device via coresight_release_platform_data() b) Iterate over all the devices on the coresight bus and drop the reference to fwnode if *this* device is the target of the output connection, via coresight_remove_conns()->coresight_remove_match(). However, the coresight_remove_match() doesn't clear the fwnode field, after dropping the reference, this causes use-after-free and additional refcount drops on the fwnode. e.g., if we have two devices, A and B, with a connection, A -> B. If we remove B first, B would clear the reference on B, from A via coresight_remove_match(). But when A is removed, it still has a connection with fwnode still pointing to B. Thus it tries to drops the reference in coresight_release_platform_data(), raising the bells like : [ 91.990153] ------------[ cut here]------------ [ 91.990163] refcount_t: addition on 0; use-after-free. [ 91.990212] WARNING: CPU: 0 PID:
    461 at lib/refcount.c:25 refcount_warn_saturate+0xa0/0x144 [ 91.990260] Modules linked in:
    coresight_funnel coresight_replicator coresight_etm4x(-) crct10dif_ce coresight ip_tables x_tables ipv6 [last unloaded: coresight_cpu_debug] [ 91.990398] CPU: 0 PID: 461 Comm: rmmod Tainted: G W T 5.19.0-rc2+ #53 [ 91.990418] Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Feb 1 2019 [ 91.990434] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [91.990454] pc : refcount_warn_saturate+0xa0/0x144 [ 91.990476] lr : refcount_warn_saturate+0xa0/0x144 [91.990496] sp : ffff80000c843640 [ 91.990509] x29: ffff80000c843640 x28: ffff800009957c28 x27:
    ffff80000c8439a8 [ 91.990560] x26: ffff00097eff1990 x25: ffff8000092b6ad8 x24: ffff00097eff19a8 [91.990610] x23: ffff80000c8439a8 x22: 0000000000000000 x21: ffff80000c8439c2 [ 91.990659] x20:
    0000000000000000 x19: ffff00097eff1a10 x18: ffff80000ab99c40 [ 91.990708] x17: 0000000000000000 x16:
    0000000000000000 x15: ffff80000abf6fa0 [ 91.990756] x14: 000000000000001d x13: 0a2e656572662d72 x12:
    657466612d657375 [ 91.990805] x11: 203b30206e6f206e x10: 6f69746964646120 x9 : ffff8000081aba28 [91.990854] x8 : 206e6f206e6f6974 x7 : 69646461203a745f x6 : 746e756f63666572 [ 91.990903] x5 :
    ffff00097648ec58 x4 : 0000000000000000 x3 : 0000000000000027 [ 91.990952] x2 : 0000000000000000 x1 :
    0000000000000000 x0 : ffff00080260ba00 [ 91.991000] Call trace: [ 91.991012] refcount_warn_saturate+0xa0/0x144 [ 91.991034] kobject_get+0xac/0xb0 [ 91.991055] of_node_get+0x2c/0x40 [91.991076] of_fwnode_get+0x40/0x60 [ 91.991094] fwnode_handle_get+0x3c/0x60 [ 91.991116] fwnode_get_nth_parent+0xf4/0x110 [ 91.991137] fwnode_full_name_string+0x48/0xc0 [ 91.991158] device_node_string+0x41c/0x530 [ 91.991178] pointer+0x320/0x3ec [ 91.991198] vsnprintf+0x23c/0x750 [91.991217] vprintk_store+0x104/0x4b0 [ 91.991238] vprintk_emit+0x8c/0x360 [ 91.991257] vprintk_default+0x44/0x50 [ 91.991276] vprintk+0xcc/0xf0 [ 91.991295] _printk+0x68/0x90 [ 91.991315] of_node_release+0x13c/0x14c [ 91.991334] kobject_put+0x98/0x114 [ 91.991354] of_node_put+0x24/0x34 [91.991372] of_fwnode_put+0x40/0x5c [ 91.991390] fwnode_handle_put+0x38/0x50 [ 91.991411] coresight_release_platform_data+0x74/0xb0 [coresight] [ 91.991472] coresight_unregister+0x64/0xcc [coresight] [ 91.991525] etm4_remove_dev+0x64/0x78 [coresight_etm4x] [ 91.991563] etm4_remove_amba+0x1c/0x2c [coresight_etm4x] [ 91.991598] amba_remove+0x3c/0x19c ---truncated--- (CVE-2022-50214)

  - 已修复 Linux 内核中的下列漏洞：wifi: brcmfmac: Fix potential stack-out-of-bounds in brcmf_c_preinit_dcmds() This patch fixes a stack-out-of-bounds read in brcmfmac that occurs when 'buf' that is not null-terminated is passed as an argument of strsep() in brcmf_c_preinit_dcmds(). This buffer is filled with a firmware version string by memcpy() in brcmf_fil_iovar_data_get(). The patch ensures buf is null-terminated. Found by a modified version of syzkaller. [ 47.569679][ T1897] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43236b for chip BCM43236/3 [ 47.582839][ T1897] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available [ 47.601565][ T1897] ================================================================== [ 47.602574][ T1897] BUG: KASAN: stack-out-of-bounds in strsep+0x1b2/0x1f0 [ 47.603447][ T1897] Read of size 1 at addr ffffc90001f6f000 by task kworker/0:2/1897 [ 47.604336][ T1897] [ 47.604621][ T1897] CPU: 0 PID: 1897 Comm: kworker/0:2 Tainted: G O 5.14.0+ #131 [ 47.605617][ T1897] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 [ 47.606907][ T1897] Workqueue: usb_hub_wq hub_event [ 47.607453][ T1897] Call Trace: [ 47.607801][ T1897] dump_stack_lvl+0x8e/0xd1 [ 47.608295][T1897] print_address_description.constprop.0.cold+0xf/0x334 [ 47.609009][ T1897] ? strsep+0x1b2/0x1f0 [47.609434][ T1897] ? strsep+0x1b2/0x1f0 [ 47.609863][ T1897] kasan_report.cold+0x83/0xdf [ 47.610366][T1897] ? strsep+0x1b2/0x1f0 [ 47.610882][ T1897] strsep+0x1b2/0x1f0 [ 47.611300][ T1897] ? brcmf_fil_iovar_data_get+0x3a/0xf0 [ 47.611883][ T1897] brcmf_c_preinit_dcmds+0x995/0xc40 [ 47.612434][T1897] ? brcmf_c_set_joinpref_default+0x100/0x100 [ 47.613078][ T1897] ? rcu_read_lock_sched_held+0xa1/0xd0 [ 47.613662][ T1897] ? rcu_read_lock_bh_held+0xb0/0xb0 [ 47.614208][T1897] ? lock_acquire+0x19d/0x4e0 [ 47.614704][ T1897] ? find_held_lock+0x2d/0x110 [ 47.615236][ T1897] ? brcmf_usb_deq+0x1a7/0x260 [ 47.615741][ T1897] ? brcmf_usb_rx_fill_all+0x5a/0xf0 [ 47.616288][ T1897] brcmf_attach+0x246/0xd40 [ 47.616758][ T1897] ? wiphy_new_nm+0x1703/0x1dd0 [ 47.617280][ T1897] ? kmemdup+0x43/0x50 [ 47.617720][ T1897] brcmf_usb_probe+0x12de/0x1690 [ 47.618244][ T1897] ? brcmf_usbdev_qinit.constprop.0+0x470/0x470 [ 47.618901][ T1897] usb_probe_interface+0x2aa/0x760 [47.619429][ T1897] ? usb_probe_device+0x250/0x250 [ 47.619950][ T1897] really_probe+0x205/0xb70 [47.620435][ T1897] ? driver_allows_async_probing+0x130/0x130 [ 47.621048][ T1897]
    __driver_probe_device+0x311/0x4b0 [ 47.621595][ T1897] ? driver_allows_async_probing+0x130/0x130 [47.622209][ T1897] driver_probe_device+0x4e/0x150 [ 47.622739][ T1897] __device_attach_driver+0x1cc/0x2a0 [ 47.623287][ T1897] bus_for_each_drv+0x156/0x1d0 [ 47.623796][ T1897] ? bus_rescan_devices+0x30/0x30 [47.624309][ T1897] ? lockdep_hardirqs_on_prepare+0x273/0x3e0 [ 47.624907][ T1897] ? trace_hardirqs_on+0x46/0x160 [ 47.625437][ T1897] __device_attach+0x23f/0x3a0 [ 47.625924][ T1897] ? device_bind_driver+0xd0/0xd0 [ 47.626433][ T1897] ? kobject_uevent_env+0x287/0x14b0 [ 47.627057][ T1897] bus_probe_device+0x1da/0x290 [ 47.627557][ T1897] device_add+0xb7b/0x1eb0 [ 47.628027][ T1897] ? wait_for_completion+0x290/0x290 [ 47.628593][ T1897] ? __fw_devlink_link_to_suppliers+0x5a0/0x5a0 [47.629249][ T1897] usb_set_configuration+0xf59/0x16f0 [ 47.629829][ T1897] usb_generic_driver_probe+0x82/0xa0 [ 47.630385][ T1897] usb_probe_device+0xbb/0x250 [ 47.630927][ T1897] ? usb_suspend+0x590/0x590 [ 47.631397][ T1897] really_probe+0x205/0xb70 [ 47.631855][ T1897] ? driver_allows_async_probing+0x130/0x130 [ 47.632469][ T1897] __driver_probe_device+0x311/0x4b0 [47.633002][ ---truncated--- (CVE-2022-50258)

  - 已修复 Linux 内核中的下列漏洞：netlink: prevent potential spectre v1 gadgets Most netlink attributes are parsed and validated from __nla_validate_parse() or validate_nla() u16 type = nla_type(nla); if (type == 0 || type > maxtype) { /* error or continue */ } @type is then used as an array index and can be used as a Spectre v1 gadget. array_index_nospec() can be used to prevent leaking content of kernel memory to malicious users. This should take care of vast majority of netlink uses, but an audit is needed to take care of others where validation is not yet centralized in core netlink functions. (CVE-2023-53000)

  - 已修复 Linux 内核中的下列漏洞：scsi: mpi3mr: Bad drive in topology results kernel crash When the SAS Transport Layer support is enabled and a device exposed to the OS by the driver fails INQUIRY commands, the driver frees up the memory allocated for an internal HBA port data structure. However, in some places, the reference to the freed memory is not cleared. When the firmware sends the Device Info change event for the same device again, the freed memory is accessed and that leads to memory corruption and OS crash. (CVE-2023-53037)

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

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
361268	CentOS Linux 7 [TuxCare] 安全更新：bpftool / kernel / kernel-debug / kernel-debug-devel / kernel-devel / 等多个漏洞（CENTOS7：CLSA-2026：1780133416）	Nessus	CentOS Local Security Checks	2026/10/1	2026/10/2	high
362073	CentOS Linux 8 [TuxCare] 安全更新：bpftool / kernel / kernel-core / kernel-cross-headers / 等多个漏洞（CENTOS-STREAM8：CLSA-2026：1780132980）	Nessus	CentOS Local Security Checks	2026/10/1	2026/10/2	high
176754	Amazon Linux 2 内核 --advisory ALAS2KERNEL-5。15-2023-019 (ALASKERNEL-5.15-2023-019)	Nessus	Amazon Linux Local Security Checks	2023/6/6	2026/2/9	high
360928	CentOS Linux 8.5 [TuxCare] 安全更新：bpftool / kernel / kernel-core / kernel-cross-headers / 等多个漏洞（CENTOS8.5：CLSA-2026：1771077729）	Nessus	CentOS Local Security Checks	2026/10/1	2026/10/18	high
245822	Linux Distros 未修补的漏洞：CVE-2023-53075	Nessus	Misc.	2025/8/8	2026/9/30	high
200362	Amazon Linux 2 内核 --advisory ALAS2KERNEL-5。10-2024-059 (ALASKERNEL-5.10-2024-059)	Nessus	Amazon Linux Local Security Checks	2024/6/11	2026/2/9	high
240448	Amazon Linux 2：内核 (ALAS-2025-2892)	Nessus	Amazon Linux Local Security Checks	2025/6/25	2026/2/24	high
200361	Amazon Linux 2 内核 --advisory ALAS2KERNEL-5。4-2024-070 (ALASKERNEL-5.4-2024-070)	Nessus	Amazon Linux Local Security Checks	2024/6/11	2026/2/9	high
173854	Amazon Linux 2023：bpftool、kernel、kernel-devel (ALAS2023-2023-148)	Nessus	Amazon Linux Local Security Checks	2023/4/4	2026/2/24	high
361173	CentOS Linux 8.4 [TuxCare] 安全更新：bpftool / kernel / kernel-core / kernel-cross-headers / 等多个漏洞（CENTOS8.4：CLSA-2026：1771078945）	Nessus	CentOS Local Security Checks	2026/10/1	2026/10/1	high
241751	Amazon Linux 2：内核 (ALAS-2025-2909)	Nessus	Amazon Linux Local Security Checks	2025/7/10	2026/2/24	high
352030	AlmaLinux 9.2 [TuxCare] 安全更新：bpftool / kernel / kernel-abi-stablelists / kernel-core / 等多个漏洞（ALMALINUX9.2：CLSA-2025：1765463110）	Nessus	Alma Linux Local Security Checks	2026/9/30	2026/10/1	high

检测

插件搜索

high

high

high

high

high

high

high

high

high

high

high

high