偵測

CentOS Linux 8.4 [TuxCare] 安全性更新：bpftool / kernel / kernel-core / kernel-cross-headers / etc 多個弱點 （CENTOS8.4：CLSA-2024：1725872696）

high Nessus Plugin ID 366937

語言:

概要

CentOS Linux 主機缺少一個或多個安全性更新。

說明

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 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

解決方案

根據 TuxCare 公告 CENTOS8.4：CLSA-2024：1725872696 中的指引更新受影響的套件。

另請參閱

https://cve.tuxcare.com/els/releases/CLSA-2024:1725872696

http://www.nessus.org/u?a50ba67b

Plugin 詳細資訊

嚴重性: High

ID: 366937

檔案名稱: tuxcare_centos_8.4_CLSA-2024-1725872696.nasl

版本: 1.1

類型: Local

代理程式: unix

已發布: 2026/10/18

已更新: 2026/10/18

支援的感應器: Nessus Agent, Continuous Assessment, Tenable Cloud Security, Tenable Self-Hosted Container Security, Nessus

風險資訊

VPR

風險因素: High

分數: 7.6

百分位數: 98.48

Vendor

Vendor Severity: Important

CVSS v2

風險因素: Medium

基本分數: 6.8

時間性分數: 5

媒介: CVSS2#AV:A/AC:H/Au:N/C:C/I:C/A:C

CVSS 評分資料來源: CVE-2024-42225

CVSS v3

風險因素: High

基本分數: 7.8

時間性分數: 6.8

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

時間媒介: CVSS:3.0/E:U/RL:O/RC:C

CVSS 評分資料來源: CVE-2024-41087

弱點資訊

必要的 KB 項目: Host/local_checks_enabled, Host/CentOS/release, Host/CentOS/rpm-list, Host/OS/extended-third-party

可輕鬆利用: No known exploits are available

修補程式發佈日期: 2024/9/9

弱點發布日期: 2021/7/16

參考資訊

CVE: CVE-2021-46939, CVE-2022-48743, CVE-2022-48757, CVE-2022-48788, CVE-2022-48789, CVE-2022-48790, CVE-2022-48796, CVE-2023-51779, CVE-2023-52340, CVE-2023-52486, CVE-2023-52530, CVE-2023-52619, CVE-2023-52622, CVE-2023-52623, CVE-2023-52707, CVE-2023-52811, CVE-2024-21803, CVE-2024-25739, CVE-2024-25742, CVE-2024-26614, CVE-2024-26668, CVE-2024-26669, CVE-2024-26698, CVE-2024-26704, CVE-2024-26733, CVE-2024-26772, CVE-2024-26773, CVE-2024-26925, CVE-2024-27397, CVE-2024-36883, CVE-2024-36940, CVE-2024-36960, CVE-2024-36978, CVE-2024-38552, CVE-2024-38570, CVE-2024-39471, CVE-2024-41087, CVE-2024-41090, CVE-2024-41091, CVE-2024-42154, CVE-2024-42161, CVE-2024-42225, CVE-2024-42228

CLSA: 2024:1725872696