kernel-4.18.0-553.141.2.el8_10

The kernel packages contain the Linux kernel, the core of any Linux operating
system.

Security Fix(es):
* kernel: tcp: fix potential race in tcp_v6_syn_recv_sock() (CVE-2026-43198)
* kernel: netfilter: nfnetlink_cthelper: fix OOB read in
nfnl_cthelper_dump_table() (CVE-2026-43450)
* kernel: sctp: revalidate list cursor after sctp_sendmsg_to_asoc() in
SCTP_SENDALL (CVE-2026-46227)
* kernel: drm/gem: Fix inconsistent plane dimension calculation in
drm_gem_fb_init_with_funcs() (CVE-2026-46209)
* kernel: procfs: fix missing RCU protection when reading real_parent in
do_task_stat() (CVE-2026-46259)
* kernel: Arm Processors: Privilege escalation or information disclosure via
writes to higher exception level resources (CVE-2025-10263)
* kernel: fs/smb/client: fix out-of-bounds read in 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-A710, Cortex-A78, A78AE & A78C, Cortex-A77, Cortex-A76 &
A76A may allow writes to resources owned by a higher exception level.
CVE-2026-43198
In the Linux kernel, the following vulnerability has been resolved: 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.