Detections
Analytics

CentOS Linux 8.4 [TuxCare] Security Update: bpftool / kernel / kernel-core / kernel-cross-headers / etc Multiple Vulnerabilities (CENTOS8.4:CLSA-2026:1792749577)

high Nessus Plugin ID 371225

Language:

Synopsis

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

Description

The CentOS Linux 8.4 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare CENTOS8.4:CLSA-2026:1792749577 advisory.

 - In the Linux kernel, the following vulnerability has been resolved: cifs: fix session state check in reconnect to avoid use-after-free issue Don't collect exiting session in smb2_reconnect_server(), because it will be released soon. Note that the exiting session will stay in server->smb_ses_list until it complete the cifs_free_ipc() and logoff() and then delete itself from the list. (CVE-2023-53794)

 - In the Linux kernel, the following vulnerability has been resolved: net: skbuff: propagate shared-frag marker through frag-transfer helpers Two frag-transfer helpers (__pskb_copy_fclone() and skb_shift()) fail to propagate the SKBFL_SHARED_FRAG bit in skb_shinfo()->flags when moving frags from source to destination. __pskb_copy_fclone() defers the rest of the shinfo metadata to skb_copy_header() after copying frag descriptors, but that helper only carries over gso_{size,segs, type} and never touches skb_shinfo()->flags; skb_shift() moves frag descriptors directly and leaves flags untouched. As a result, the destination skb keeps a reference to the same externally-owned or page-cache-backed pages while reporting skb_has_shared_frag() as false. The mismatch is harmful in any in-place writer that uses skb_has_shared_frag() to decide whether shared pages must be detoured through skb_cow_data(). ESP input is one such writer (esp4.c, esp6.c), and a single nft 'dup to <local>' rule -- or any other nf_dup_ipv4() / xt_TEE caller -- is enough to land a pskb_copy()'d skb in esp_input() with the marker stripped, letting an unprivileged user write into the page cache of a root-owned read-only file via authencesn-ESN stray writes. Set SKBFL_SHARED_FRAG on the destination whenever frag descriptors were actually moved from the source. skb_copy() and skb_copy_expand() share skb_copy_header() too but linearize all paged data into freshly allocated head storage and emerge with nr_frags == 0, so skb_has_shared_frag() returns false on its own; they need no change. The same omission exists in skb_gro_receive() and skb_gro_receive_list().
 The former moves the incoming skb's frag descriptors into the accumulator's last sub-skb via two paths (a direct frag-move loop and the head_frag + memcpy path); the latter chains the incoming skb whole onto p's frag_list. Downstream skb_segment() reads only skb_shinfo(p)->flags, and skb_segment_list() reuses each sub-skb's shinfo as the nskb -- both p and lp must carry the marker. The same omission also exists in tcp_clone_payload(), which builds an MTU probe skb by moving frag descriptors from skbs on sk_write_queue into a freshly allocated nskb. The helper falls into the same family and warrants the same fix for consistency; no TCP TX-side in-place writer is currently known to reach a user page through this gap, but a future consumer depending on the marker would regress silently. The same omission exists in skb_segment(): the per-iteration flag merge takes only head_skb's flag, and the inner switch that rebinds frag_skb to list_skb on head_skb-frags exhaustion does not fold the new frag_skb's flag into nskb. Fold frag_skb's flag at both sites so segments drawing frags from frag_list members carry the marker.
 (CVE-2026-43503)

 - In the Linux kernel, the following vulnerability has been resolved: RDMA/uverbs: Validate wqe_size before using it in ib_uverbs_post_send ib_uverbs_post_send() uses cmd.wqe_size from userspace without any validation before passing it to kmalloc() and using the allocated buffer as struct ib_uverbs_send_wr. If a user provides a small wqe_size value (e.g., 1), kmalloc() will succeed, but subsequent accesses to user_wr->opcode, user_wr->num_sge, and other fields will read beyond the allocated buffer, resulting in an out-of-bounds read from kernel heap memory. This could potentially leak sensitive kernel information to userspace. Additionally, providing an excessively large wqe_size can trigger a WARNING in the memory allocation path, as reported by syzkaller. This is inconsistent with ib_uverbs_unmarshall_recv() which properly validates that wqe_size >= sizeof(struct ib_uverbs_recv_wr) before proceeding. Add the same validation for ib_uverbs_post_send() to ensure wqe_size is at least sizeof(struct ib_uverbs_send_wr).
 (CVE-2026-45856)

 - In the Linux kernel, the following vulnerability has been resolved: crypto: authencesn - reject short ahash digests during instance creation authencesn requires either a zero authsize or an authsize of at least 4 bytes because the ESN encrypt/decrypt paths always move 4 bytes of high-order sequence number data at the end of the authenticated data. While crypto_authenc_esn_setauthsize() already rejects explicit non- zero authsizes in the range 1..3, crypto_authenc_esn_create() still copied auth->digestsize into inst->alg.maxauthsize without validating it. The AEAD core then initialized the tfm's default authsize from that value. As a result, selecting an ahash with digest size 1..3, such as cbcmac(cipher_null), exposed authencesn instances whose default authsize was invalid even though setauthsize() would have rejected the same value. AF_ALG could then trigger the ESN tail handling with a too-short tag and hit an out-of-bounds access. Reject authencesn instances whose ahash digest size is in the invalid non-zero range 1..3 so that no tfm can inherit an unsupported default authsize. (CVE-2026-46033)

 - In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Validate pad and ICRC before payload_size() in rxe_rcv rxe_rcv() currently checks only that the incoming packet is at least header_size(pkt) bytes long before payload_size() is used. However, payload_size() subtracts both the attacker-controlled BTH pad field and RXE_ICRC_SIZE from pkt->paylen: payload_size = pkt->paylen - offset[RXE_PAYLOAD] - bth_pad(pkt) - RXE_ICRC_SIZE This means a short packet can still make payload_size() underflow even if it includes enough bytes for the fixed headers. Simply requiring header_size(pkt) + RXE_ICRC_SIZE is not sufficient either, because a packet with a forged non-zero BTH pad can still leave payload_size() negative and pass an underflowed value to later receive-path users. Fix this by validating pkt->paylen against the full minimum length required by payload_size(): header_size(pkt) + bth_pad(pkt) + RXE_ICRC_SIZE. (CVE-2026-46043)

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.4:CLSA-2026:1792749577.

See Also

https://cve.tuxcare.com/els/releases/CLSA-2026:1792749577

http://www.nessus.org/u?8c8e68ea

Plugin Details

Severity: High

ID: 371225

File Name: tuxcare_centos_8.4_CLSA-2026-1792749577.nasl

Version: 1.1

Type: Local

Agent: unix

Published: 10/23/2026

Updated: 10/23/2026

Supported Sensors: Nessus Agent, Continuous Assessment, Tenable Cloud Security, Tenable Self-Hosted Container Security, Nessus

Risk Information

VPR

Risk Factor: Critical

Score: 9.2

Percentile: 99.77

Vendor

Vendor Severity: Critical

CVSS v2

Risk Factor: Medium

Base Score: 6.8

Temporal Score: 5.6

Vector: CVSS2#AV:L/AC:L/Au:S/C:C/I:C/A:C

CVSS Score Source: CVE-2026-64362

CVSS v3

Risk Factor: High

Base Score: 7.8

Temporal Score: 7.2

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:F/RL:O/RC:C

Vulnerability Information

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

Exploit Available: true

Exploit Ease: Exploits are available

Patch Publication Date: 10/23/2026

Vulnerability Publication Date: 9/7/2023

Reference Information

CVE: CVE-2023-53794, CVE-2026-43503, CVE-2026-45856, CVE-2026-46033, CVE-2026-46043, CVE-2026-46056, CVE-2026-46069, CVE-2026-46149, CVE-2026-46181, CVE-2026-46189, CVE-2026-46331, CVE-2026-52920, CVE-2026-52956, CVE-2026-52957, CVE-2026-53004, CVE-2026-53006, CVE-2026-53009, CVE-2026-53016, CVE-2026-53053, CVE-2026-53072, CVE-2026-53075, CVE-2026-53078, CVE-2026-53129, CVE-2026-53149, CVE-2026-53195, CVE-2026-53228, CVE-2026-53239, CVE-2026-53268, CVE-2026-53392, CVE-2026-63800, CVE-2026-63962, CVE-2026-63994, CVE-2026-64002, CVE-2026-64276, CVE-2026-64362, CVE-2026-64471, CVE-2026-64483, CVE-2026-72157, CVE-2026-72383, CVE-2026-72413, CVE-2026-72476, CVE-2026-74282, CVE-2026-74283, CVE-2026-74359, CVE-2026-74408, CVE-2026-74444, CVE-2026-74469, CVE-2026-74480, CVE-2026-74498, CVE-2026-74505, CVE-2026-74540, CVE-2026-74550, CVE-2026-74581, CVE-2026-80622, CVE-2026-80681, CVE-2026-80714, CVE-2026-89448, CVE-2026-89481, CVE-2026-89548, CVE-2026-89553, CVE-2026-89559, CVE-2026-89575, CVE-2026-89637, CVE-2026-89699, CVE-2026-89892, CVE-2026-89893, CVE-2026-89932, CVE-2026-89965, CVE-2026-89972, CVE-2026-90011, CVE-2026-90033, CVE-2026-90057, CVE-2026-90116, CVE-2026-90329, CVE-2026-93104, CVE-2026-93117, CVE-2026-93163, CVE-2026-93175, CVE-2026-93817, CVE-2026-93826, CVE-2026-97408, CVE-2026-97448, CVE-2026-97509, CVE-2026-97531, CVE-2026-97539, CVE-2026-97564, CVE-2026-97940, CVE-2026-97949, CVE-2026-98077, CVE-2026-98096, CVE-2026-98130, CVE-2026-98196, CVE-2026-98217, CVE-2026-98222, CVE-2026-98320, CVE-2026-98342, CVE-2026-98343

CLSA: 2026:1792749577