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

    AMD 建议针对此问题使用软件缓解措施，该问题默认启用内核。Linux 内核将在 AMD 实例 (*5a*) 上使用通用的 retpoline 软件缓解措施，而不是专用的 AMD 缓解措施。此为默认操作，不需要管理员操作。(CVE-2021-26341)

    AMD 建议针对此问题使用软件缓解措施，该问题默认启用内核。Linux 内核将在 AMD 实例 (*5a*) 上使用通用的 retpoline 软件缓解措施，而不是专用的 AMD 缓解措施。此为默认操作，不需要管理员操作。(CVE-2021-26401)

    在 Linux 内核的控制组和命名空间子系统中发现存在无权限的文件处理程序写入缺陷，导致用户可以访问一些由 cgroups 控制并具有较高权限父进程的低权限进程。此缺陷实际会影响 cgroup2 和 cgroup1 版本的控制组。本地用户可利用此缺陷造成系统崩溃，或提升其在系统中的权限。(CVE-2021-4197)

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

    PCI：pciehp：修复电源故障时 IRQ 处理程序中的无限循环 (CVE-2021-47617)

    在某些 Intel(R) 处理器的上下文间不透明地共享分支预测器选择器可能允许授权用户实现信息披露。(CVE-2022-0001)

    在某些 Intel(r) 处理器的上下文中不透明地共享分支预测器可能允许授权用户通过本地访问实现信息披露。(CVE-2022-0002)

    在 Linux 内核用户使用 TIPC 协议功能发送带有恶意内容的数据包时发现了一个堆栈溢出缺陷，其中域成员节点的数量超过允许的 64 个。
    具有 TIPC 网络访问权限的本地用户可利用此缺陷导致系统奔溃或升级其权限。(CVE-2022-0435)

    现在，Amazon Linux 内核在所有基于 ARM 的 EC2 实例类型上默认启用针对此问题的软件缓解措施。(CVE-2022-23960)

    在 Linux 内核的基于 ASIX AX88179_178A 的 USB 2.0/3.0 千兆位以太网设备驱动程序中发现一个缺陷，该漏洞包含多个越界读取问题，并且可能造成越界写入。
    (CVE-2022-2964)

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

    tipc：改进对已接收域记录的大小验证 (CVE-2022-48711)

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

    iommu/vt-d：修复 intel_setup_irq_remapping() 中的潜在内存泄漏 (CVE-2022-48724)

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

    btrfs：修复配额禁用和 qgroup 重新扫描工作线程之间的死锁 (CVE-2022-48734)

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

    rtnetlink：确保刷新 __rtnl_newlink() 中的 master_dev/m_ops (CVE-2022-48742)

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

    net：amd-xgbe：修复 skb 数据长度下溢问题 (CVE-2022-48743)

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

    Drivers: hv: vmbus：修复 vmbus_add_channel_kobj 中的内存泄漏 (CVE-2022-48775)

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

    vsock：连接被信号中断时，从连接表中删除 vsock (CVE-2022-48786)

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

    nvme-rdma：修复传输 error_recovery 工作中可能存在的释放后使用 (CVE-2022-48788)

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

    nvme：修复加载期间重置控制器时可能存在的释放后使用 (CVE-2022-48790)

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

    perf：修复 perf_cgroup_switch() 中的列表损坏 (CVE-2022-48799)

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

    vt_ioctl：修复 vt_setactivate 中的 array_index_nospec(CVE-2022-48804)

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

    net：usb：ax88179_178a：修复 RX 修复中的越界访问 (CVE-2022-48805)

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

    net：修复取消克隆 skb dst 及其元数据时的内存泄漏 (CVE-2022-48809)

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

    ipmrip6mr在失败路径上调用 ip[6]mr_free_table() 之前获取 RTNL (CVE-2022-48810)

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

    scsi：qedf：修复在 TMF 期间收到 LOGO 时的引用计数问题 (CVE-2022-48823)

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

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

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

  - 已修复 Linux 内核中的下列漏洞：tracing: Restructure trace_clock_global() to never block It was reported that a fix to the ring buffer recursion detection would cause a hung machine when performing suspend / resume testing. The following backtrace was extracted from debugging that case: Call Trace: trace_clock_global+0x91/0xa0 __rb_reserve_next+0x237/0x460 ring_buffer_lock_reserve+0x12a/0x3f0 trace_buffer_lock_reserve+0x10/0x50 __trace_graph_return+0x1f/0x80 trace_graph_return+0xb7/0xf0 ? trace_clock_global+0x91/0xa0 ftrace_return_to_handler+0x8b/0xf0 ? pv_hash+0xa0/0xa0 return_to_handler+0x15/0x30 ? ftrace_graph_caller+0xa0/0xa0 ? trace_clock_global+0x91/0xa0 ? __rb_reserve_next+0x237/0x460 ? ring_buffer_lock_reserve+0x12a/0x3f0 ? trace_event_buffer_lock_reserve+0x3c/0x120 ? trace_event_buffer_reserve+0x6b/0xc0 ? trace_event_raw_event_device_pm_callback_start+0x125/0x2d0 ? dpm_run_callback+0x3b/0xc0 ? pm_ops_is_empty+0x50/0x50 ? platform_get_irq_byname_optional+0x90/0x90 ? trace_device_pm_callback_start+0x82/0xd0 ? dpm_run_callback+0x49/0xc0 With the following RIP: RIP:
    0010:native_queued_spin_lock_slowpath+0x69/0x200 Since the fix to the recursion detection would allow a single recursion to happen while tracing, this lead to the trace_clock_global() taking a spin lock and then trying to take it again: ring_buffer_lock_reserve() { trace_clock_global() { arch_spin_lock() {queued_spin_lock_slowpath() { /* lock taken */ (something else gets traced by function graph tracer) ring_buffer_lock_reserve() { trace_clock_global() { arch_spin_lock() { queued_spin_lock_slowpath() { /* DEAD LOCK! */ Tracing should *never* block, as it can lead to strange lockups like the above. Restructure the trace_clock_global() code to instead of simply taking a lock to update the recorded prev_time simply use it, as two events happening on two different CPUs that calls this at the same time, really doesn't matter which one goes first. Use a trylock to grab the lock for updating the prev_time, and if it fails, simply try again the next time. If it failed to be taken, that means something else is already updating it. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=212761 (CVE-2021-46939)

  - 已修复 Linux 内核中的下列漏洞：userfaultfd: fix a race between writeprotect and exit_mmap() A race is possible when a process exits, its VMAs are removed by exit_mmap() and at the same time userfaultfd_writeprotect() is called. The race was detected by KASAN on a development kernel, but it appears to be possible on vanilla kernels as well. Use mmget_not_zero() to prevent the race as done in other userfaultfd operations. (CVE-2021-47461)

  - 已修复 Linux 内核中的下列漏洞：net: amd-xgbe: Fix skb data length underflow There will be BUG_ON() triggered in include/linux/skbuff.h leading to intermittent kernel panic, when the skb length underflow is detected. Fix this by dropping the packet if such length underflows are seen because of inconsistencies in the hardware descriptors. (CVE-2022-48743)

  - 已修复 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 内核中的下列漏洞：nvme-tcp: fix possible use-after-free in transport error_recovery work While nvme_tcp_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-48789)

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

CentOS Linux 8.4 主机上存在安装的程序包，该程序包受到 TuxCare CENTOS8.4：CLSA-2024：1725872696公告中提及的多个漏洞的影响。

  - 已修复 Linux 内核中的下列漏洞：tracing: Restructure trace_clock_global() to never block It was reported that a fix to the ring buffer recursion detection would cause a hung machine when performing suspend / resume testing. The following backtrace was extracted from debugging that case: Call Trace: trace_clock_global+0x91/0xa0 __rb_reserve_next+0x237/0x460 ring_buffer_lock_reserve+0x12a/0x3f0 trace_buffer_lock_reserve+0x10/0x50 __trace_graph_return+0x1f/0x80 trace_graph_return+0xb7/0xf0 ? trace_clock_global+0x91/0xa0 ftrace_return_to_handler+0x8b/0xf0 ? pv_hash+0xa0/0xa0 return_to_handler+0x15/0x30 ? ftrace_graph_caller+0xa0/0xa0 ? trace_clock_global+0x91/0xa0 ? __rb_reserve_next+0x237/0x460 ? ring_buffer_lock_reserve+0x12a/0x3f0 ? trace_event_buffer_lock_reserve+0x3c/0x120 ? trace_event_buffer_reserve+0x6b/0xc0 ? trace_event_raw_event_device_pm_callback_start+0x125/0x2d0 ? dpm_run_callback+0x3b/0xc0 ? pm_ops_is_empty+0x50/0x50 ? platform_get_irq_byname_optional+0x90/0x90 ? trace_device_pm_callback_start+0x82/0xd0 ? dpm_run_callback+0x49/0xc0 With the following RIP: RIP:
    0010:native_queued_spin_lock_slowpath+0x69/0x200 Since the fix to the recursion detection would allow a single recursion to happen while tracing, this lead to the trace_clock_global() taking a spin lock and then trying to take it again: ring_buffer_lock_reserve() { trace_clock_global() { arch_spin_lock() {queued_spin_lock_slowpath() { /* lock taken */ (something else gets traced by function graph tracer) ring_buffer_lock_reserve() { trace_clock_global() { arch_spin_lock() { queued_spin_lock_slowpath() { /* DEAD LOCK! */ Tracing should *never* block, as it can lead to strange lockups like the above. Restructure the trace_clock_global() code to instead of simply taking a lock to update the recorded prev_time simply use it, as two events happening on two different CPUs that calls this at the same time, really doesn't matter which one goes first. Use a trylock to grab the lock for updating the prev_time, and if it fails, simply try again the next time. If it failed to be taken, that means something else is already updating it. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=212761 (CVE-2021-46939)

  - 已修复 Linux 内核中的下列漏洞：net: amd-xgbe: Fix skb data length underflow There will be BUG_ON() triggered in include/linux/skbuff.h leading to intermittent kernel panic, when the skb length underflow is detected. Fix this by dropping the packet if such length underflows are seen because of inconsistencies in the hardware descriptors. (CVE-2022-48743)

  - 已修复 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 内核中的下列漏洞：nvme-tcp: fix possible use-after-free in transport error_recovery work While nvme_tcp_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-48789)

  - 已修复 Linux 内核中的下列漏洞：nvme: fix a possible use-after-free in controller reset during load Unlike .queue_rq, in .submit_async_event drivers may not check the ctrl readiness for AER submission. This may lead to a use-after-free condition that was observed with nvme-tcp.
    The race condition may happen in the following scenario: 1. driver executes its reset_ctrl_work 2. -> nvme_stop_ctrl - flushes ctrl async_event_work 3. ctrl sends AEN which is received by the host, which in turn schedules AEN handling 4. teardown admin queue (which releases the queue socket) 5. AEN processed, submits another AER, calling the driver to submit 6. driver attempts to send the cmd ==> use-after-free In order to fix that, add ctrl state check to validate the ctrl is actually able to accept the AER submission. This addresses the above race in controller resets because the driver during teardown should:
    1. change ctrl state to RESETTING 2. flush async_event_work (as well as other async work elements) So after 1,2, any other AER command will find the ctrl state to be RESETTING and bail out without submitting the AER. (CVE-2022-48790)

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

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

  - nvme修复加载期间控制器重置中可能的释放后使用。与 .queue_rq 不同在 .submit_async_event 中驱动程序可能不检查 ctrl 对于 AER 提交的准备情况。这可能导致使用 nvme-tcp 时发现的释放后使用情况。在以下情况下可能会发生争用条件1. 驱动程序执行其 reset_ctrl_work 2. -> nvme_stop_ctrl - 刷新 ctrl async_event_work 3.
    ctrl 发送 AEN 主机接收主机反过来安排 AEN 处理 4. 拆卸管理队列可释放队列套接字5. 处理 AEN 后提交另一个 AER从而调用驱动程序来提交 6.
    驱动程序尝试发送 cmd ==> 释放后使用。修复此问题添加 ctrl 状态检查以验证 ctrl 是否确实能够接受 AER 提交。这解决了控制器重置中的上述争用因为驱动程序在拆卸期间应该: 1. 将 ctrl 状态更改为 RESETTING 2. 刷新 async_event_work以及其他异步工作元素因此在 1,2 之后任何其他 AER 命令都将找到 ctrl 状态被重置并且在未提交 AER 的情况下离开。 (CVE-2022-48790)

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

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

  - 已修复 Linux 内核中的下列漏洞：media: ngene: Fix out-of-bounds bug in ngene_command_config_free_buf() Fix an 11-year old bug in ngene_command_config_free_buf() while addressing the following warnings caught with -Warray-bounds: arch/alpha/include/asm/string.h:22:16: warning:
    '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds] arch/x86/include/asm/string_32.h:182:25:
    warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds] The problem is that the original code is trying to copy 6 bytes of data into a one-byte size member _config_ of the wrong structue FW_CONFIGURE_BUFFERS, in a single call to memcpy(). This causes a legitimate compiler warning because memcpy() overruns the length of &com.cmd.ConfigureBuffers.config. It seems that the right structure is FW_CONFIGURE_FREE_BUFFERS, instead, because it contains 6 more members apart from the header _hdr_. Also, the name of the function ngene_command_config_free_buf() suggests that the actual intention is to ConfigureFreeBuffers, instead of ConfigureBuffers (which takes place in the function ngene_command_config_buf(), above). Fix this by enclosing those 6 members of struct FW_CONFIGURE_FREE_BUFFERS into new struct config, and use &com.cmd.ConfigureFreeBuffers.config as the destination address, instead of &com.cmd.ConfigureBuffers.config, when calling memcpy(). This also helps with the ongoing efforts to globally enable -Warray-bounds and get us closer to being able to tighten the FORTIFY_SOURCE routines on memcpy(). (CVE-2021-47288)

  - 已修复 Linux 内核中的下列漏洞：nvme: fix a possible use-after-free in controller reset during load Unlike .queue_rq, in .submit_async_event drivers may not check the ctrl readiness for AER submission. This may lead to a use-after-free condition that was observed with nvme-tcp.
    The race condition may happen in the following scenario: 1. driver executes its reset_ctrl_work 2. -> nvme_stop_ctrl - flushes ctrl async_event_work 3. ctrl sends AEN which is received by the host, which in turn schedules AEN handling 4. teardown admin queue (which releases the queue socket) 5. AEN processed, submits another AER, calling the driver to submit 6. driver attempts to send the cmd ==> use-after-free In order to fix that, add ctrl state check to validate the ctrl is actually able to accept the AER submission. This addresses the above race in controller resets because the driver during teardown should:
    1. change ctrl state to RESETTING 2. flush async_event_work (as well as other async work elements) So after 1,2, any other AER command will find the ctrl state to be RESETTING and bail out without submitting the AER. (CVE-2022-48790)

  - 已修复 Linux 内核中的下列漏洞：scsi: pm8001: Fix use-after-free for aborted TMF sas_task Currently a use-after-free may occur if a TMF sas_task is aborted before we handle the IO completion in mpi_ssp_completion(). The abort occurs due to timeout. When the timeout occurs, the SAS_TASK_STATE_ABORTED flag is set and the sas_task is freed in pm8001_exec_internal_tmf_task(). However, if the I/O completion occurs later, the I/O completion still thinks that the sas_task is available. Fix this by clearing the ccb->task if the TMF times out - the I/O completion handler does nothing if this pointer is cleared. (CVE-2022-48791)

  - 已修复 Linux 内核中的下列漏洞：tracing: Free buffers when a used dynamic event is removed After 65536 dynamic events have been added and removed, the type field of the event then uses the first type number that is available (not currently used by other events). A type number is the identifier of the binary blobs in the tracing ring buffer (known as events) to map them to logic that can parse the binary blob. The issue is that if a dynamic event (like a kprobe event) is traced and is in the ring buffer, and then that event is removed (because it is dynamic, which means it can be created and destroyed), if another dynamic event is created that has the same number that new event's logic on parsing the binary blob will be used. To show how this can be an issue, the following can crash the kernel: # cd /sys/kernel/tracing # for i in `seq 65536`; do echo 'p:kprobes/foo do_sys_openat2 $arg1:u32' > kprobe_events # done For every iteration of the above, the writing to the kprobe_events will remove the old event and create a new one (with the same format) and increase the type number to the next available on until the type number reaches over 65535 which is the max number for the 16 bit type. After it reaches that number, the logic to allocate a new number simply looks for the next available number.
    When an dynamic event is removed, that number is then available to be reused by the next dynamic event created. That is, once the above reaches the max number, the number assigned to the event in that loop will remain the same. Now that means deleting one dynamic event and created another will reuse the previous events type number. This is where bad things can happen. After the above loop finishes, the kprobes/foo event which reads the do_sys_openat2 function call's first parameter as an integer. # echo 1 > kprobes/foo/enable # cat /etc/passwd > /dev/null # cat trace cat-2211 [005] .... 2007.849603: foo:
    (do_sys_openat2+0x0/0x130) arg1=4294967196 cat-2211 [005] .... 2007.849620: foo:
    (do_sys_openat2+0x0/0x130) arg1=4294967196 cat-2211 [005] .... 2007.849838: foo:
    (do_sys_openat2+0x0/0x130) arg1=4294967196 cat-2211 [005] .... 2007.849880: foo:
    (do_sys_openat2+0x0/0x130) arg1=4294967196 # echo 0 > kprobes/foo/enable Now if we delete the kprobe and create a new one that reads a string: # echo 'p:kprobes/foo do_sys_openat2 +0($arg2):string' > kprobe_events And now we can the trace: # cat trace sendmail-1942 [002] ..... 530.136320: foo:
    (do_sys_openat2+0x0/0x240) arg1= cat-2046 [004] ..... 530.930817: foo: (do_sys_openat2+0x0/0x240) arg1= cat-2046 [004] ..... 530.930961: foo: (do_sys_openat2+0x0/0x240) arg1= cat-2046 [004] ..... 530.934278: foo: (do_sys_openat2+0x0/0x240) arg1= cat-2046 [004] ..... 530.934563: foo: (do_sys_openat2+0x0/0x240) arg1= ---truncated--- (CVE-2022-49006)

  - 已修复 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)

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

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

    AMD 建议针对此问题使用软件缓解措施，该问题默认启用内核。Linux 内核将在 AMD 实例 (*5a*) 上使用通用的 retpoline 软件缓解措施，而不是专用的 AMD 缓解措施。此为默认操作，不需要管理员操作。(CVE-2021-26341)

    AMD 建议针对此问题使用软件缓解措施，该问题默认启用内核。Linux 内核将在 AMD 实例 (*5a*) 上使用通用的 retpoline 软件缓解措施，而不是专用的 AMD 缓解措施。此为默认操作，不需要管理员操作。(CVE-2021-26401)

    在 Linux 内核的控制组和命名空间子系统中发现存在无权限的文件处理程序写入缺陷，导致用户可以访问一些由 cgroups 控制并具有较高权限父进程的低权限进程。此缺陷实际会影响 cgroup2 和 cgroup1 版本的控制组。本地用户可利用此缺陷造成系统崩溃，或提升其在系统中的权限。(CVE-2021-4197)

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

    PCI：pciehp：修复电源故障时 IRQ 处理程序中的无限循环 (CVE-2021-47617)

    在某些 Intel(R) 处理器的上下文间不透明地共享分支预测器选择器可能允许授权用户实现信息披露。(CVE-2022-0001)

    在某些 Intel(r) 处理器的上下文中不透明地共享分支预测器可能允许授权用户通过本地访问实现信息披露。(CVE-2022-0002)

    在 Linux 内核用户使用 TIPC 协议功能发送带有恶意内容的数据包时发现了一个堆栈溢出缺陷，其中域成员节点的数量超过允许的 64 个。
    具有 TIPC 网络访问权限的本地用户可利用此缺陷导致系统奔溃或升级其权限。(CVE-2022-0435)

    在 Linux 内核的 copy_page_to_iter_pipe 和 push_pipe 函数中发现一个缺陷，其中新管道缓冲区结构的标记成员未经正确初始化，因此可能包含过时值。无权限本地用户可利用此缺陷在只读文件支持的页面缓存中写入页面，并由此升级其在系统上的权限。(CVE-2022-0847)

    在 Linux 内核中，发现 net/sched/cls_api.c 的 tc_new_tfilter 函数中存在释放后使用漏洞。本地非特权用户命名空间的可用性允许特权提升。
    (CVE-2022-1055)

    现在，Amazon Linux 内核在所有基于 ARM 的 EC2 实例类型上默认启用针对此问题的软件缓解措施。(CVE-2022-23960)

    在 Linux 内核的基于 ASIX AX88179_178A 的 USB 2.0/3.0 千兆位以太网设备驱动程序中发现一个缺陷，该漏洞包含多个越界读取问题，并且可能造成越界写入。
    (CVE-2022-2964)

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

    tipc：改进对已接收域记录的大小验证 (CVE-2022-48711)

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

    ext4：修复 ext4_fc_record_modified_inode() 中的错误处理（CVE-2022-48712）

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

    perf/x86/intel/pt：修复单一范围模式中停止过滤器时发生的崩溃 (CVE-2022-48713)

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

    bpf：针对 ringbuf 使用 VM_MAP（而不是 VM_ALLOC）(CVE-2022-48714)

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

    net: macsec：修复对 NETDEV_UNREGISTER 事件的卸载支持 (CVE-2022-48720)

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

    iommu/vt-d：修复 intel_setup_irq_remapping() 中的潜在内存泄漏 (CVE-2022-48724)

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

    RDMA/ucma：在并发多播离开期间保护 mc (CVE-2022-48726)

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

    IB/hfi1修复 AIP 早期初始化错误 (CVE-2022-48728)

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

    btrfs：修复配额禁用和 qgroup 重新扫描工作线程之间的死锁 (CVE-2022-48734)

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

    selinux：修复错误路径上的 cond_list 的双重释放 (CVE-2022-48740)

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

    rtnetlink：确保刷新 __rtnl_newlink() 中的 master_dev/m_ops (CVE-2022-48742)

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

    net：amd-xgbe：修复 skb 数据长度下溢问题 (CVE-2022-48743)

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

    net/mlx5：在 fw 重置停止轮询的流中使用 del_timer_sync (CVE-2022-48745)

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

    net/mlx5e：修复绑定 netevent 期间对错误设备的处理 (CVE-2022-48746)

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

    KVM：x86：切换 SMM 状态时强制保留嵌套的 virt (CVE-2022-48763)

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

    xprtrdma：修复 rpcrdma_ep_create 错误情况下的指针取消引用 (CVE-2022-48773)

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

    Drivers: hv: vmbus：修复 vmbus_add_channel_kobj 中的内存泄漏 (CVE-2022-48775)

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

    vsock：连接被信号中断时，从连接表中删除 vsock (CVE-2022-48786)

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

    nvme-rdma：修复传输 error_recovery 工作中可能存在的释放后使用 (CVE-2022-48788)

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

    nvme：修复加载期间重置控制器时可能存在的释放后使用 (CVE-2022-48790)

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

    iommu：修复探测期间潜在的释放后使用 (CVE-2022-48796)

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

    mm不尝试对具有其他用途的 COW 页面进行 NUMA 迁移 (CVE-2022-48797)

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

    perf：修复 perf_cgroup_switch() 中的列表损坏 (CVE-2022-48799)

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

    fs/proc：task_mmu.c：不读取迁移条目的 mapcount (CVE-2022-48802)

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

    vt_ioctl：修复 vt_setactivate 中的 array_index_nospec(CVE-2022-48804)

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

    net：usb：ax88179_178a：修复 RX 修复中的越界访问 (CVE-2022-48805)

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

    net：修复取消克隆 skb dst 及其元数据时的内存泄漏 (CVE-2022-48809)

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

    ipmrip6mr在失败路径上调用 ip[6]mr_free_table() 之前获取 RTNL (CVE-2022-48810)

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

    netdsalantiq_gswip不要将 devres 用于 mdiobusCVE-2022-48812

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

    net：dsa：felix：不将 devres 用于 mdiobus (CVE-2022-48813)

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

    net：dsa：bcm_sf2：不将 devres 用于 mdiobus (CVE-2022-48815)

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

    netdsaar9331注册 devres 下的 mdiobus (CVE-2022-48817)

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

    net：dsa：mv88e6xxx：不将 devres 用于 mdiobus (CVE-2022-48818)

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

    scsi：qedf：修复在 TMF 期间收到 LOGO 时的引用计数问题 (CVE-2022-48823)

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

    scsiqedf将 stag_work 添加到所有 vports (CVE-2022-48825)

    在 Linux 内核中发现内存管理子组件的 fs/proc/task_mmu.c 存在争用问题。
    具有用户权限的本地攻击者可利用此缺陷造成系统拒绝服务。(CVE-2023-1582)

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

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

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
161456	Amazon Linux 2 内核 --advisory ALAS2KERNEL-5。4-2022-023 (ALASKERNEL-5.4-2022-023)	Nessus	Amazon Linux Local Security Checks	2022/5/24	2026/2/26	high
366947	CentOS Linux 8.5 [TuxCare] 安全更新：bpftool / kernel / kernel-core / kernel-cross-headers / 等多个漏洞（CENTOS8.5：CLSA-2024：1725876080）	Nessus	CentOS Local Security Checks	2026/10/18	2026/10/18	high
366937	CentOS Linux 8.4 [TuxCare] 安全更新：bpftool / kernel / kernel-core / kernel-cross-headers / 等多个漏洞（CENTOS8.4：CLSA-2024：1725872696）	Nessus	CentOS Local Security Checks	2026/10/18	2026/10/18	high
225796	Linux Distros 未修补的漏洞：CVE-2022-48790	Nessus	Misc.	2025/3/5	2026/11/12	high
353232	CentOS Linux 7 [TuxCare] 安全更新：bpftool / kernel / kernel-debug / kernel-debug-devel / kernel-devel / 等多个漏洞（CENTOS7：CLSA-2026：1782148320）	Nessus	CentOS Local Security Checks	2026/9/30	2026/9/30	high
160425	Amazon Linux 2 内核 --advisory ALAS2KERNEL-5。10-2022-011 (ALASKERNEL-5.10-2022-011)	Nessus	Amazon Linux Local Security Checks	2022/5/2	2026/2/26	high

检测

插件搜索

high

high

high

high

high

high