CentOS Linux 7 [TuxCare] 安全性更新：bpftool / kernel / kernel-debug / kernel-debug-devel / kernel-devel / etc 多個弱點 （CENTOS7：CLSA-2026：1791730242）
high Nessus Plugin ID 366515
語言:
概要
CentOS Linux 主機缺少一個或多個安全性更新。說明
CentOS Linux 7 主機已安裝的套件會受到 TuxCare CENTOS7：CLSA-2026：1791730242 公告中提及的多個弱點影響。- Linux 核心的 netfilter: nf_tables 元件中有一個釋放後使用弱點，可遭惡意利用來提升本機權限。nf_tables netlink 控制平面交易和 nft_set 元素記憶體回收之間存在爭用情形，可能會使參照計數器反向溢位，進而造成釋放後使用弱點。建議升級過去的 Commit 3e91b0ebd994635df2346353322ac51ce84ce6d8。(CVE-2023-4244)
- 已解決 Linux 核心中的下列弱點：crypto: af_alg - Disallow concurrent writes in af_alg_sendmsg Issuing two writes to the same af_alg socket is bogus as the data will be interleaved in an unpredictable fashion. Furthermore, concurrent writes may create inconsistencies in the internal socket state. Disallow this by adding a new ctx->write field that indiciates exclusive ownership for writing. (CVE-2025-39964)
- 已解決 Linux 核心中的下列弱點：net: atm: fix crash due to unvalidated vcc pointer in sigd_send() Reproducer available at [1]. The ATM send path (sendmsg -> vcc_sendmsg -> sigd_send) reads the vcc pointer from msg->vcc and uses it directly without any validation. This pointer comes from userspace via sendmsg() and can be arbitrarily forged: int fd = socket(AF_ATMSVC, SOCK_DGRAM, 0); ioctl(fd, ATMSIGD_CTRL); // become ATM signaling daemon struct msghdr msg = { .msg_iov = &iov, ... };
*(unsigned long *)(buf + 4) = 0xdeadbeef; // fake vcc pointer sendmsg(fd, &msg, 0); // kernel dereferences 0xdeadbeef In normal operation, the kernel sends the vcc pointer to the signaling daemon via sigd_enq() when processing operations like connect(), bind(), or listen(). The daemon is expected to return the same pointer when responding. However, a malicious daemon can send arbitrary pointer values. Fix this by introducing find_get_vcc() which validates the pointer by searching through vcc_hash (similar to how sigd_close() iterates over all VCCs), and acquires a reference via sock_hold() if found. Since struct atm_vcc embeds struct sock as its first member, they share the same lifetime. Therefore using sock_hold/sock_put is sufficient to keep the vcc alive while it is being used. Note that there may be a race with sigd_close() which could mark the vcc with various flags (e.g., ATM_VF_RELEASED) after find_get_vcc() returns. However, sock_hold() guarantees the memory remains valid, so this race only affects the logical state, not memory safety. [1]:
https://gist.github.com/mrpre/1ba5949c45529c511152e2f4c755b0f3 (CVE-2026-31411)
- 已解決 Linux 核心中的下列弱點：ipc: limit next_id allocation to the valid ID range The checkpoint/restore sysctl path can request the next SysV IPC id through ids->next_id.
ipc_idr_alloc() currently forwards that request to idr_alloc() with an open-ended upper bound. If the valid tail of the SysV IPC id space is full, the allocation can spill beyond ipc_mni. The returned SysV IPC id still uses the normal index encoding, so later lookup and removal can target the wrong slot. This leaves the real IDR entry behind and breaks the IDR state for the object. The bug is in ipc_idr_alloc() in the checkpoint/restore path. 1. ids->next_id is passed to: idr_alloc(&ids->ipcs_idr, new, ipcid_to_idx(next_id), 0, ...) 2. The zero upper bound makes the allocation effectively open-ended. Once the valid SysV IPC tail is occupied, idr_alloc() can spill past ipc_mni and allocate an entry beyond the valid IPC id range. 3. The new object id is still encoded with the narrower SysV IPC index width: new->id = (new->seq << ipcmni_seq_shift()) + idx 4. Later removal goes through ipc_rmid(), which uses:
ipcid_to_idx(ipcp->id) That truncates the real IDR index. An object actually stored at a high index can then be removed as if it lived at a low in-range index. 5. For shared memory, shm_destroy() frees the current object anyway, but the real high IDR slot is left behind as a dangling pointer. 6. A subsequent walk of /proc/sysvipc/shm reaches the stale IDR entry and dereferences freed memory. Prevent this by bounding the requested allocation to ipc_mni so the checkpoint/restore path fails once the valid range is exhausted. (CVE-2026-52923)
- 已解決 Linux 核心中的下列弱點：dm log: fix out-of-bounds write due to region_count overflow The local variable region_count in create_log_context() is declared as unsigned int (32-bit), but dm_sector_div_up() returns sector_t (64-bit). When a device-mapper target has a sufficiently large ti->len with a small region_size, the division result can exceed UINT_MAX. The truncated value is then used to calculate bitset_size, causing clean_bits, sync_bits, and recovering_bits to be allocated far smaller than needed for the actual number of regions. Subsequent log operations (log_set_bit, log_clear_bit, log_test_bit) use region indices derived from the full untruncated region space, causing out-of-bounds writes to kernel heap memory allocated by vmalloc. This can be reproduced by creating a mirror target whose region_count overflows 32 bits: dmsetup create bigzero --table '0 8589934594 zero' dmsetup create mymirror --table '0 8589934594 mirror \ core 2 2 nosync 2 /dev/mapper/bigzero 0 \ /dev/mapper/bigzero 0' The status output confirms the truncation (sync_count=1 instead of 4294967297, because 0x100000001 was truncated to 1): $ dmsetup status mymirror 0 8589934594 mirror 2 254:1 254:1 1/4294967297 ... This leads to a kernel crash in core_in_sync: BUG: scheduling while atomic: (udev-worker)/9150/0x00000000 RIP: 0010:core_in_sync+0x14/0x30 [dm_log] CR2: 0000000000000008 Fixing recursive fault but reboot is needed! Fix by widening the local region_count to sector_t and adding an explicit overflow check before the value is assigned to lc->region_count. (CVE-2026-53059)
請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。
解決方案
根據 TuxCare 公告 CENTOS7：CLSA-2026：1791730242 中的指引更新受影響的套件。另請參閱
Plugin 詳細資訊
嚴重性: High
ID: 366515
檔案名稱: tuxcare_centos_7_CLSA-2026-1791730242.nasl
版本: 1.1
類型: Local
代理程式: unix
已發布: 2026/10/16
已更新: 2026/10/16
支援的感應器: Nessus Agent, Continuous Assessment, Tenable Cloud Security, Tenable Self-Hosted Container Security, Nessus
風險資訊
VPR
風險因素: Critical
分數: 9.3
百分位數: 99.82
Vendor
Vendor Severity: Important
CVSS v2
風險因素: High
基本分數: 7.2
時間性分數: 6
媒介: CVSS2#AV:L/AC:L/Au:N/C:C/I:C/A:C
CVSS 評分資料來源: CVE-2026-53196
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
CVSS 評分資料來源: CVE-2026-64343
弱點資訊
必要的 KB 項目: Host/local_checks_enabled, Host/CentOS/release, Host/CentOS/rpm-list, Host/OS/extended-third-party
可被惡意程式利用: true
可輕鬆利用: Exploits are available
修補程式發佈日期: 2026/10/11
弱點發布日期: 2023/9/6
CISA 已知遭惡意利用弱點到期日: 2026/9/21
參考資訊
CVE: CVE-2023-4244, CVE-2025-39964, CVE-2026-31411, CVE-2026-31688, CVE-2026-52923, CVE-2026-53059, CVE-2026-53195, CVE-2026-53196, CVE-2026-53266, CVE-2026-64191, CVE-2026-64340, CVE-2026-64343, CVE-2026-64372, CVE-2026-64375, CVE-2026-68106, CVE-2026-68111, CVE-2026-68175, CVE-2026-68218, CVE-2026-68234, CVE-2026-68299, CVE-2026-68425, CVE-2026-72005, CVE-2026-72019, CVE-2026-72020, CVE-2026-72036, CVE-2026-72039, CVE-2026-72083, CVE-2026-72106, CVE-2026-74720, CVE-2026-80844, CVE-2026-81000
CLSA: 2026:1791730242