CentOS Linux 8.5 [TuxCare] Security Update: bpftool / kernel / kernel-core / kernel-cross-headers / etc Multiple Vulnerabilities (CENTOS8.5:CLSA-2024:1725876080)

high Nessus Plugin ID 366947

Synopsis

The CentOS Linux host is missing one or more security updates.

Description

The CentOS Linux 8.5 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare CENTOS8.5:CLSA-2024:1725876080 advisory.

- In the Linux kernel, the following vulnerability has been resolved: 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)

- In the Linux kernel, the following vulnerability has been resolved: 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)

- In the Linux kernel, the following vulnerability has been resolved: 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)

- In the Linux kernel, the following vulnerability has been resolved: 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)

- In the Linux kernel, the following vulnerability has been resolved: 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)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

Solution

Update the affected packages based on the guidance in TuxCare advisory CENTOS8.5:CLSA-2024:1725876080.

Plugin Details

Severity: High

ID: 366947

File Name: tuxcare_centos_8.5_CLSA-2024-1725876080.nasl

Version: 1.1

Type: Local

Agent: unix

Family: CentOS Local Security Checks

Published: 10/18/2026

Updated: 10/18/2026

Supported Sensors: Continuous Assessment, Nessus Agent, Nessus

Risk Information

VPR

Risk Factor: High

Score: 7.6

Percentile: 98.48

Vendor

Vendor Severity: Important

CVSS v2

Risk Factor: Medium

Base Score: 6.8

Temporal Score: 5

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

CVSS Score Source: CVE-2024-42225

CVSS v3

Risk Factor: High

Base Score: 7.8

Temporal Score: 6.8

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

Temporal Vector: CVSS:3.0/E:U/RL:O/RC:C

CVSS Score Source: CVE-2024-41087

Vulnerability Information

Required KB Items: Host/OS/extended-third-party, Host/local_checks_enabled, Host/CentOS/release, Host/CentOS/rpm-list

Exploit Ease: No known exploits are available

Patch Publication Date: 9/9/2024

Vulnerability Publication Date: 7/16/2021

Reference Information

CVE: CVE-2021-46939, CVE-2021-47461, 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-40956, CVE-2024-41087, CVE-2024-41090, CVE-2024-41091, CVE-2024-42154, CVE-2024-42161, CVE-2024-42225, CVE-2024-42228

CLSA: 2024:1725876080

Detections

Analytics