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 7 主機已安裝的套件會受到 TuxCare CENTOS7：CLSA-2026：1782148320 公告中提及的多個弱點影響。

  - 已解決 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 Gigabit 乙太網路裝置驅動程式中發現一個缺陷。此弱點包含多個超出邊界讀取問題，並可能造成超出邊界寫入。
    (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 核心中，下列弱點已解決：

    驅動程式hvvmbus修正 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不嘗試 NUMA 移轉有其他用途的 COW 頁面 (CVE-2022-48797)

    在 Linux 核心中，下列弱點已解決：

    perf：修正 perf_cgroup_switch() 中的清單損毀 (CVE-2022-48799)

    在 Linux 核心中，下列弱點已解決：

    fs/proctask_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 核心中，下列弱點已解決：

    ipmr、ip6mr在失敗路徑上呼叫 ip[6]mr_free_table() 前先取得 RTNL (CVE-2022-48810)

    在 Linux 核心中，下列弱點已解決：

    netdsalantiq_gswip不針對 mdiobus 使用 devres (CVE-2022-48812)

    在 Linux 核心中，下列弱點已解決：

    net：dsa：felix：不要針對 mdiobus 使用 devres (CVE-2022-48813)

    在 Linux 核心中，下列弱點已解決：

    net：dsa：bcm_sf2：不要針對 mdiobus 使用 devres (CVE-2022-48815)

    在 Linux 核心中，下列弱點已解決：

    netdsaar9331在 devres 下註冊 mdiobus (CVE-2022-48817)

    在 Linux 核心中，下列弱點已解決：

    net：dsa：mv88e6xxx：不要針對 mdiobus 使用 devres (CVE-2022-48818)

    在 Linux 核心中，下列弱點已解決：

    scsi：qedf：修正 TMF 期間收到 LOGO 時的 refcount 問題 (CVE-2022-48823)

    在 Linux 核心中，下列弱點已解決：

    scsiqedf將 stag_work 新增至所有 vport (CVE-2022-48825)

    在 Linux 核心中發現記憶體管理子元件 fs/proc/task_mmu.c 存在爭用問題。
    具有使用者特權的本機攻擊者可藉由此問題造成拒絕服務。(CVE-2023-1582)

Tenable 已直接從所測試產品的安全公告擷取前置描述區塊。

請注意，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 中驅動程式可能不會檢查 AER 提交的 ctrl 就緒情況。這可能會導致使用 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 狀態為 RESETTING 且在不提交 AER 的情況下結束。 (CVE-2022-48790)

請注意，Nessus 依賴供應商報告的套件存在。

遠端主機上安裝的核心版本早於 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 Gigabit 乙太網路裝置驅動程式中發現一個缺陷。此弱點包含多個超出邊界讀取問題，並可能造成超出邊界寫入。
    (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 核心中，下列弱點已解決：

    驅動程式hvvmbus修正 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 核心中，下列弱點已解決：

    ipmr、ip6mr在失敗路徑上呼叫 ip[6]mr_free_table() 前先取得 RTNL (CVE-2022-48810)

    在 Linux 核心中，下列弱點已解決：

    scsi：qedf：修正 TMF 期間收到 LOGO 時的 refcount 問題 (CVE-2022-48823)

Tenable 已直接從所測試產品的安全公告擷取前置描述區塊。

請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

ID	名稱	產品	系列	已發布	已更新	嚴重性
366947	CentOS Linux 8.5 [TuxCare] 安全性更新：bpftool / kernel / kernel-core / kernel-cross-headers / etc 多個弱點（CENTOS8.5：CLSA-2024：1725876080）	Nessus	CentOS Local Security Checks	2026/10/18	2026/10/18	high
353232	CentOS Linux 7 [TuxCare] 安全性更新：bpftool / kernel / kernel-debug / kernel-debug-devel / kernel-devel / etc 多個漏洞（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
366937	CentOS Linux 8.4 [TuxCare] 安全性更新：bpftool / kernel / kernel-core / kernel-cross-headers / etc 多個弱點（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/7/17	high
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

偵測

搜尋 Plugin

high

high

high

high

high

high