MiracleLinux 8：kernel-4.18.0-553.141.2.el8_10 （AXSA：2026-1311：50）
high Nessus 插件 ID 328693
语言：
简介
远程 MiracleLinux 主机缺少一个或多个安全更新。描述
远程 MiracleLinux 8 主机上存在安装的程序包，该程序包受到 AXSA：2026-1311：50 公告中提及的多个漏洞的影响。* kernel： tcp：修复 tcp_v6_syn_recv_sock（） 中潜在的争用（CVE-2026-43198）
* kernel： netfilter： nfnetlink_cthelper：修复 nfnl_cthelper_dump_table（） （CVE-2026-43450） 中的 OOB 读取
* kernel： sctp：重新验证 SCTP_SENDALL （CVE-2026-46227） 中 sctp_sendmsg_to_asoc（） 之后的列表光标
* kernel： drm/gem：修复 drm_gem_fb_init_with_funcs（）中不一致的平面尺寸计算（CVE-2026-46209）
* kernel： procfs：修复在 do_task_stat（）中读取real_parent时缺少的 RCU 保护（CVE-2026-46259）
* 内核：Arm 处理器：通过写入更高异常级别的资源进行权限升级或信息泄露（CVE-2025-10263）
* kernel： fs/smb/client：修复 cifs_sanitize_prepath 中的越界读取 （CVE-2026-43112） CVE-2025-10263 Arm C1-Ultra、C1-Premium、Neoverse V3 & V3AE、Neoverse V2、Neoverse V1、Neoverse-N2、Neoverse-N1、Cortex-X925、Cortex-X4、Cortex-X3、Cortex-X2、Cortex-X1 & X1C、Cortex-、Cortex-A710、Cortex-A78、A78AE &; A78C、Cortex-A77、Cortex-A76 &; A76A 可能允许写入更高异常级别拥有的资源。
CVE-2026-43198 在 Linux 内核中，以下漏洞已得到解决： tcp: fix potential race in tcp_v6_syn_recv_sock() Code in tcp_v6_syn_recv_sock() after the call to tcp_v4_syn_recv_sock() is done too late. After tcp_v4_syn_recv_sock(), the child socket is already visible from TCP ehash table and other cpus might use it. Since newinet->pinet6 is still pointing to the listener ipv6_pinfo bad things can happen as syzbot found. Move the problematic code in tcp_v6_mapped_child_init() and call this new helper from tcp_v4_syn_recv_sock() before the ehash insertion. This allows the removal of one tcp_sync_mss(), since tcp_v4_syn_recv_sock() will call it with the correct context.
CVE-2026-43450 In the Linux kernel, the following vulnerability has been resolved: netfilter:
nfnetlink_cthelper: fix OOB read in nfnl_cthelper_dump_table() nfnl_cthelper_dump_table() has a 'goto restart' that jumps to a label inside the for loop body. When the last helper saved in cb->args[1] is deleted between dump rounds, every entry fails the (cur != last) check, so cb->args[1] is never cleared. The for loop finishes with cb->args[0] == nf_ct_helper_hsize, and the 'goto restart' jumps back into the loop body bypassing the bounds check, causing an 8-byte out-of-bounds read on nf_ct_helper_hash[nf_ct_helper_hsize]. The 'goto restart' block was meant to re-traverse the current bucket when last is no longer found, but it was placed after the for loop instead of inside it. Move the block into the for loop body so that the restart only occurs while cb->args[0] is still within bounds. BUG: KASAN: slab-out-of-bounds in nfnl_cthelper_dump_table+0x9f/0x1b0 Read of size 8 at addr ffff888104ca3000 by task poc_cthelper/131 Call Trace: nfnl_cthelper_dump_table+0x9f/0x1b0 netlink_dump+0x333/0x880 netlink_recvmsg+0x3e2/0x4b0 sock_recvmsg+0xde/0xf0
__sys_recvfrom+0x150/0x200 __x64_sys_recvfrom+0x76/0x90 do_syscall_64+0xc3/0x6e0 Allocated by task 1: __kvmalloc_node_noprof+0x21b/0x700 nf_ct_alloc_hashtable+0x65/0xd0 nf_conntrack_helper_init+0x21/0x60 nf_conntrack_init_start+0x18d/0x300 nf_conntrack_standalone_init+0x12/0xc0 CVE-2026-46209 In the Linux kernel, the following vulnerability has been resolved: drm/gem: Fix inconsistent plane dimension calculation in drm_gem_fb_init_with_funcs() drm_gem_fb_init_with_funcs() computes sub-sampled plane dimensions using plain integer division: unsigned int width = mode_cmd->width / (i ? info->hsub : 1);
unsigned int height = mode_cmd->height / (i ? info->vsub : 1); However, the ioctl-level framebuffer_check() in drm_framebuffer.c uses drm_format_info_plane_width/height() which round up dimensions via DIV_ROUND_UP(). This inconsistency corrupts the subsequent GEM object size check for certain pixel format and dimension combinations. For example, with NV12 (vsub=2) and a 1-pixel-tall framebuffer the GEM size validation path sees height=0 instead of height=1. The expression (height - 1) then wraps to UINT_MAX as an unsigned int, causing min_size to overflow and wrap back to a small value.
A tiny GEM object therefore passes the size guard, yet when the GPU accesses the chroma plane it will read or write memory beyond the object's bounds. Fix by replacing the open-coded divisions with drm_format_info_plane_width() and drm_format_info_plane_height(), which use DIV_ROUND_UP() and match the calculation already used in framebuffer_check().
CVE-2026-46227 In the Linux kernel, the following vulnerability has been resolved: sctp:
revalidate list cursor after sctp_sendmsg_to_asoc() in SCTP_SENDALL The SCTP_SENDALL path in sctp_sendmsg() iterates ep->asocs with list_for_each_entry_safe(), which caches the next entry in @tmp before the loop body runs. The body calls sctp_sendmsg_to_asoc(), which may drop the socket lock inside sctp_wait_for_sndbuf(). While the lock is dropped, another thread can SCTP_SOCKOPT_PEELOFF the association cached in @tmp, migrating it to a new endpoint via sctp_sock_migrate() (list_del_init() + list_add_tail() to newep->asocs), and optionally close the new socket which frees the association via kfree_rcu(). The cached @tmp can also be freed by a network ABORT for that association, processed in softirq while the lock is dropped.
sctp_wait_for_sndbuf() revalidates @asoc (the current entry) on re-lock via the sk != asoc->base.sk and asoc->base.dead checks, but nothing revalidates @tmp. After a successful return, the iterator advances to the stale @tmp, yielding either a use-after-free (if the peeled socket was closed) or a list-walk onto the new endpoint's list head (type confusion of &newep->asocs as a struct sctp_association *). Both are reachable from CapEff=0; the type-confusion path gives controlled indirect call via the outqueue.sched->init_sid pointer. Fix by re-deriving @tmp from @asoc after sctp_sendmsg_to_asoc() returns. @asoc is known to still be on ep->asocs at that point: the only callers that list_del an association from ep->asocs are sctp_association_free() (which sets asoc->base.dead) and sctp_assoc_migrate() (which changes asoc->base.sk), and sctp_wait_for_sndbuf() checks both under the lock before any successful return; a tripped check propagates as err < 0 and the loop bails before the re-derive. The SCTP_ABORT path in sctp_sendmsg_check_sflags() returns 0 and the loop hits 'continue' before sctp_sendmsg_to_asoc() is ever called, so the @tmp cached by list_for_each_entry_safe() still covers the lock-held free that ba59fb027307 (sctp: walk the list of asoc safely) was added for.
CVE-2026-46259 In the Linux kernel, the following vulnerability has been resolved: procfs: fix missing RCU protection when reading real_parent in do_task_stat() When reading /proc/[pid]/stat, do_task_stat() accesses task->real_parent without proper RCU protection, which leads to: cpu 0 cpu 1 ----- ----- do_task_stat var = task->real_parent release_task call_rcu(delayed_put_task_struct) task_tgid_nr_ns(var) rcu_read_lock <--- Too late to protect task->real_parent! task_pid_ptr <--- UAF! rcu_read_unlock This patch uses task_ppid_nr_ns() instead of task_tgid_nr_ns() to add proper RCU protection for accessing task->real_parent.
CVE-2026-43112 In the Linux kernel, the following vulnerability has been resolved:
fs/smb/client: fix out-of-bounds read in cifs_sanitize_prepath When cifs_sanitize_prepath is called with an empty string or a string containing only delimiters (e.g., /), the current logic attempts to check *(cursor2 - 1) before cursor2 has advanced. This results in an out-of-bounds read. This patch adds an early exit check after stripping prepended delimiters. If no path content remains, the function returns NULL. The bug was identified via manual audit and verified using a standalone test case compiled with AddressSanitizer, which triggered a SEGV on affected inputs.
Tenable 已直接从 MiracleLinux 安全公告中提取上述描述块。
请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。
解决方案
更新受影响的程序包。另见
插件详情
严重性: High
ID: 328693
文件名: miracle_linux_AXSA-2026-1311.nasl
版本: 1.1
类型: Local
发布时间: 2026/7/21
最近更新时间: 2026/7/21
支持的传感器: Nessus Agent, Nessus
风险信息
VPR
风险因素: High
分数: 7.5
百分位: 98.46
Vendor
Vendor Severity: High
CVSS v2
风险因素: Medium
基本分数: 6.2
时间分数: 4.6
矢量: CVSS2#AV:L/AC:L/Au:S/C:C/I:N/A:C
CVSS 分数来源: CVE-2026-43450
CVSS v3
风险因素: High
基本分数: 7.1
时间分数: 6.2
矢量: CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
时间矢量: CVSS:3.0/E:U/RL:O/RC:C
漏洞信息
CPE: cpe:/o:miracle:linux:8, p-cpe:/a:miracle:linux:bpftool, p-cpe:/a:miracle:linux:kernel-abi-stablelists, p-cpe:/a:miracle:linux:kernel-core, p-cpe:/a:miracle:linux:kernel-cross-headers, p-cpe:/a:miracle:linux:kernel-debug-core, p-cpe:/a:miracle:linux:kernel-debug-devel, p-cpe:/a:miracle:linux:kernel-debug-modules-extra, p-cpe:/a:miracle:linux:kernel-debug-modules, p-cpe:/a:miracle:linux:kernel-debug, p-cpe:/a:miracle:linux:kernel-devel, p-cpe:/a:miracle:linux:kernel-headers, p-cpe:/a:miracle:linux:kernel-modules-extra, p-cpe:/a:miracle:linux:kernel-modules, p-cpe:/a:miracle:linux:kernel-tools-libs-devel, p-cpe:/a:miracle:linux:kernel-tools-libs, p-cpe:/a:miracle:linux:kernel-tools, p-cpe:/a:miracle:linux:kernel, p-cpe:/a:miracle:linux:perf, p-cpe:/a:miracle:linux:python3-perf
必需的 KB 项: Host/local_checks_enabled, Host/cpu, Host/MiracleLinux/release, Host/MiracleLinux/rpm-list
易利用性: No known exploits are available
补丁发布日期: 2026/7/21
漏洞发布日期: 2026/3/27
参考资料信息
CVE: CVE-2025-10263, CVE-2026-43112, CVE-2026-43198, CVE-2026-43450, CVE-2026-46209, CVE-2026-46227, CVE-2026-46259