Описание
Security update for the Linux Kernel (Live Patch 76 for SUSE Linux Enterprise 12 SP5)
This update for the SUSE Linux Enterprise Kernel 4.12.14-122.290 fixes various security issues
The following security issues were fixed:
- CVE-2025-54518: AMD-SN-7052: CPU OP Cache Corruption (bsc#1264096).
- CVE-2026-23243: RDMA/umad: Reject negative data_len in ib_umad_write (bsc#1259798).
- CVE-2026-46300: FragNesia attack: another xfrm/esp based local root exploit (bsc#1265224).
- CVE-2026-46333: ptrace: slightly saner 'get_dumpable()' logic (bsc#1265384).
Список пакетов
SUSE Linux Enterprise Live Patching 12 SP5
Ссылки
- Link for SUSE-SU-2026:2168-1
- E-Mail link for SUSE-SU-2026:2168-1
- SUSE Security Ratings
- SUSE Bug 1259798
- SUSE Bug 1264096
- SUSE Bug 1265224
- SUSE Bug 1265384
- SUSE CVE CVE-2025-54518 page
- SUSE CVE CVE-2026-23243 page
- SUSE CVE CVE-2026-46300 page
- SUSE CVE CVE-2026-46333 page
Описание
Improper isolation of shared resources within the CPU operation cache on Zen 2-based products could allow an attacker to corrupt instructions executed at a different privilege level, potentially resulting in privilege escalation.
Затронутые продукты
Ссылки
- CVE-2025-54518
- SUSE Bug 1264013
- SUSE Bug 1264066
- SUSE Bug 1264096
Описание
In the Linux kernel, the following vulnerability has been resolved: RDMA/umad: Reject negative data_len in ib_umad_write ib_umad_write computes data_len from user-controlled count and the MAD header sizes. With a mismatched user MAD header size and RMPP header length, data_len can become negative and reach ib_create_send_mad(). This can make the padding calculation exceed the segment size and trigger an out-of-bounds memset in alloc_send_rmpp_list(). Add an explicit check to reject negative data_len before creating the send buffer. KASAN splat: [ 211.363464] BUG: KASAN: slab-out-of-bounds in ib_create_send_mad+0xa01/0x11b0 [ 211.364077] Write of size 220 at addr ffff88800c3fa1f8 by task spray_thread/102 [ 211.365867] ib_create_send_mad+0xa01/0x11b0 [ 211.365887] ib_umad_write+0x853/0x1c80
Затронутые продукты
Ссылки
- CVE-2026-23243
- SUSE Bug 1259797
- SUSE Bug 1259798
Описание
In the Linux kernel, the following vulnerability has been resolved: net: skbuff: preserve shared-frag marker during coalescing skb_try_coalesce() can attach paged frags from @from to @to. If @from has SKBFL_SHARED_FRAG set, the resulting @to skb can contain the same externally-owned or page-cache-backed frags, but the shared-frag marker is currently lost. That breaks the invariant relied on by later in-place writers. In particular, ESP input checks skb_has_shared_frag() before deciding whether an uncloned nonlinear skb can skip skb_cow_data(). If TCP receive coalescing has moved shared frags into an unmarked skb, ESP can see skb_has_shared_frag() as false and decrypt in place over page-cache backed frags. Propagate SKBFL_SHARED_FRAG when skb_try_coalesce() transfers paged frags. The tailroom copy path does not need the marker because it copies bytes into @to's linear data rather than transferring frag descriptors.
Затронутые продукты
Ссылки
- CVE-2026-46300
- SUSE Bug 1265209
- SUSE Bug 1265226
- SUSE Bug 1265312
- SUSE Bug 1265383
- SUSE Bug 1265960
Описание
In the Linux kernel, the following vulnerability has been resolved: ptrace: slightly saner 'get_dumpable()' logic The 'dumpability' of a task is fundamentally about the memory image of the task - the concept comes from whether it can core dump or not - and makes no sense when you don't have an associated mm. And almost all users do in fact use it only for the case where the task has a mm pointer. But we have one odd special case: ptrace_may_access() uses 'dumpable' to check various other things entirely independently of the MM (typically explicitly using flags like PTRACE_MODE_READ_FSCREDS). Including for threads that no longer have a VM (and maybe never did, like most kernel threads). It's not what this flag was designed for, but it is what it is. The ptrace code does check that the uid/gid matches, so you do have to be uid-0 to see kernel thread details, but this means that the traditional "drop capabilities" model doesn't make any difference for this all. Make it all make a *bit* more sense by saying that if you don't have a MM pointer, we'll use a cached "last dumpability" flag if the thread ever had a MM (it will be zero for kernel threads since it is never set), and require a proper CAP_SYS_PTRACE capability to override.
Затронутые продукты
Ссылки
- CVE-2026-46333
- SUSE Bug 1265308
- SUSE Bug 1265384