CentOS Linux 8.4 [TuxCare] 安全性更新：bpftool / kernel / kernel-core / kernel-cross-headers / etc 多個弱點 （CENTOS8.4：CLSA-2026：1792749577）
high Nessus Plugin ID 371225
語言:
概要
CentOS Linux 主機缺少一個或多個安全性更新。說明
CentOS Linux 8.4 主機已安裝的套件會受到 TuxCare CENTOS8.4：CLSA-2026：1792749577 公告中提及的多個弱點影響。- 已解決 Linux 核心中的下列弱點：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)
- 已解決 Linux 核心中的下列弱點：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)
- 已解決 Linux 核心中的下列弱點：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)
- 已解決 Linux 核心中的下列弱點：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)
- 已解決 Linux 核心中的下列弱點：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)
請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。
解決方案
根據 TuxCare 公告 CENTOS8.4：CLSA-2026：1792749577 中的指引更新受影響的套件。另請參閱
Plugin 詳細資訊
嚴重性: High
ID: 371225
檔案名稱: tuxcare_centos_8.4_CLSA-2026-1792749577.nasl
版本: 1.1
類型: Local
代理程式: unix
已發布: 2026/10/23
已更新: 2026/10/23
支援的感應器: Nessus Agent, Continuous Assessment, Tenable Cloud Security, Tenable Self-Hosted Container Security, Nessus
風險資訊
VPR
風險因素: Critical
分數: 9.2
百分位數: 99.77
Vendor
Vendor Severity: Critical
CVSS v2
風險因素: Medium
基本分數: 6.8
時間性分數: 5.6
媒介: CVSS2#AV:L/AC:L/Au:S/C:C/I:C/A:C
CVSS 評分資料來源: CVE-2026-64362
CVSS v3
風險因素: High
基本分數: 7.8
時間性分數: 7.2
媒介: CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
時間媒介: CVSS:3.0/E:F/RL:O/RC:C
弱點資訊
必要的 KB 項目: Host/local_checks_enabled, Host/CentOS/release, Host/CentOS/rpm-list, Host/OS/extended-third-party
可被惡意程式利用: true
可輕鬆利用: Exploits are available
修補程式發佈日期: 2026/10/23
弱點發布日期: 2023/9/7
參考資訊
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