Описание
Important: kernel security, bug fix, and enhancement update
The kernel packages contain the Linux kernel, the core of any Linux operating system.
Security Fix(es):
-
kernel: xfrm: espintcp: do not reuse an in-progress partial send (CVE-2026-52935)
-
kernel: USB: serial: io_ti: fix heap overflow in get_manuf_info() (CVE-2026-53196)
-
kernel: sctp: keep chunk->transport in step with the list it is queued on (CVE-2026-74588)
-
kernel: sctp: validate cookie AUTH state before use (CVE-2026-74752)
-
kernel: smb: client: reject a tree connect response whose byte count is too small (CVE-2026-89631)
-
kernel: sctp: stop processing a packet once its association is deleted (CVE-2026-89479)
-
kernel: perf: Fix addr_filter_ranges lifetime (CVE-2026-93817)
-
kernel: netfilter: nfnetlink_log: wait for rcu grace period before freeing pernet state (CVE-2026-93288)
-
kernel: kernel: strparser: use-after-free via msg_timer_work rearm after strp_done() cancellation ()
-
kernel: netfilter: flowtable: hold reference on ct until flow is released (CVE-2026-98320)
Bug Fix(es) and Enhancement(s):
-
gfs2 filesystem withdrawal rework [Rocky Linux-8] (JIRA:Rocky Linux-129363)
-
Batch: z-stream xfrm - rhel-8.10.z (NST-Core-26W38) (JIRA:Rocky Linux-256684)
For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.
Затронутые продукты
Rocky Linux 8
Ссылки на источники
Исправления
- Red Hat - 2492098
- Red Hat - 2492750
- Red Hat - 2521384
- Red Hat - 2524422
- Red Hat - 2532089
- Red Hat - 2532290
- Red Hat - 2540391
- Red Hat - 2540500
- Red Hat - 2546494
Связанные уязвимости
In the Linux kernel, the following vulnerability has been resolved: xfrm: espintcp: do not reuse an in-progress partial send espintcp keeps a single in-flight transmit in ctx->partial. Before building a new sk_msg, espintcp_sendmsg() first tries to flush that state through espintcp_push_msgs(). For blocking callers, espintcp_push_msgs() may return success even when the previous partial send is still pending. espintcp_sendmsg() would then reinitialize emsg->skmsg and reuse ctx->partial while the old transfer still owns that state. Do not rebuild the send message when ctx->partial is still in progress. If espintcp_push_msgs() returns with emsg->len still set, fail the new send instead of overwriting the live partial state. This is a memory-safety fix: reusing the live partial-send state can leave a stale offset attached to a new sk_msg and lead to an out-of- bounds read in the send path. tcp_sendmsg_locked() already handles waiting for send buffer memory, so the fix here is just to pr...
In the Linux kernel, the following vulnerability has been resolved: xfrm: espintcp: do not reuse an in-progress partial send espintcp keeps a single in-flight transmit in ctx->partial. Before building a new sk_msg, espintcp_sendmsg() first tries to flush that state through espintcp_push_msgs(). For blocking callers, espintcp_push_msgs() may return success even when the previous partial send is still pending. espintcp_sendmsg() would then reinitialize emsg->skmsg and reuse ctx->partial while the old transfer still owns that state. Do not rebuild the send message when ctx->partial is still in progress. If espintcp_push_msgs() returns with emsg->len still set, fail the new send instead of overwriting the live partial state. This is a memory-safety fix: reusing the live partial-send state can leave a stale offset attached to a new sk_msg and lead to an out-of- bounds read in the send path. tcp_sendmsg_locked() already handles waiting for send buffer memory, so the fix here is just to pr...
In the Linux kernel, the following vulnerability has been resolved: xfrm: espintcp: do not reuse an in-progress partial send espintcp keeps a single in-flight transmit in ctx->partial. Before building a new sk_msg, espintcp_sendmsg() first tries to flush that state through espintcp_push_msgs(). For blocking callers, espintcp_push_msgs() may return success even when the previous partial send is still pending. espintcp_sendmsg() would then reinitialize emsg->skmsg and reuse ctx->partial while the old transfer still owns that state. Do not rebuild the send message when ctx->partial is still in progress. If espintcp_push_msgs() returns with emsg->len still set, fail the new send instead of overwriting the live partial state. This is a memory-safety fix: reusing the live partial-send state can leave a stale offset attached to a new sk_msg and lead to an out-of- bounds read in the send path. tcp_sendmsg_locked() already handles waiting for send buffer memory, so the fix here is just to
In the Linux kernel, the following vulnerability has been resolved: x ...