Red Hat Linux Linux Kernel Vulnerabilities & Security Advisories
2148 advisories tracked · Red Hat Security Data API · 1 listed in the CISA Known Exploited Vulnerabilities catalog
Every row below is a published Red Hat Linux advisory that VulniPulse classified as Linux Kernel, with the CVEs, affected and fixed releases and exploitation status the vendor stated. Severity mix: 781 high, 1364 medium, 1 low.
Android app · Google Play
Monitor Red Hat CVEs from your phone.
Choose a whole vendor or a precise platform, then receive matching security advisories by phone notification, email, or both. Coverage follows 32 official vendor sources and 160+ reviewed platform categories.
Source
Red Hat Security Data API
Red Hat Enterprise Linux errata (RHSA) via the official Red Hat Security Data API — CVE severity, CVSS and affected packages. A credential-free official source.
Latest Red Hat Linux Kernel advisories
High [CVE-2026-68320] fix auth_chunk_list capacity check in sctp_auth_ep_add_chunkid
In the Linux kernel, the following vulnerability has been resolved: sctp: fix auth_chunk_list capacity check in sctp_auth_ep_add_chunkid sctp_auth_ep_add_chunkid() uses SCTP_NUM_CHUNK_TYPES (20) as the capacity limit for ep->auth_chunk_list, allowing it to hold up to 20 chunk entries (param_hdr.length up to 24). However, the copy destination asoc->c.auth_chunks in struct sctp_cookie is only SCTP_AUTH_MAX_CHUNKS (16) entries (20 bytes). When more than 16 chunks are added, sctp_association_init() memcpy overflows the destination by up to 4 bytes. Fix by using SCTP_AUTH_MAX_CHUNKS as the capacity limit, matching the destination capacity. A flaw was found in the Linux kernel's Stream Control Transmission Protocol (SCTP) implementation. This vulnerability occurs because the `sctp_auth_ep_add_chunkid` function allows more data to be written than the allocated buffer can hold during the initialization of an SCTP association. A remote attacker could potentially exploit this buffer overflow to cause memory corruption, leading to a denial of service or other unpredictable system behavior. Red Hat severity: Moderate — CVSS 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H). Weakness: CWE-120. Affected products named by the advisory: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 6; Red Hat Enterprise Linux 7; Red Hat Enterprise Linux 8; and 3 more.
High [CVE-2026-68299] fix BUG_ON in vmxnet3_get_hdr_len for Geneve packets
In the Linux kernel, the following vulnerability has been resolved: vmxnet3: fix BUG_ON in vmxnet3_get_hdr_len() for Geneve packets vmxnet3_get_hdr_len() assumes gdesc->rcd.v4/v6/tcp always describe the outer header, but for a Geneve-encapsulated packet the device can set them based on the inner header instead, signalled by the VMXNET3_RCD_HDR_INNER_SHIFT bit in the completion descriptor. Since the function never skips the outer encapsulation, this mismatch triggers: - BUG_ON(hdr.ipv4->protocol!= IPPROTO_TCP), because the outer protocol is UDP (Geneve), not TCP. - BUG_ON(hdr.eth->h_proto!=...), when the tunnel's outer and inner IP versions differ (e.g. outer IPv6/inner IPv4 or vice versa). Check VMXNET3_RCD_HDR_INNER_SHIFT up front and bail out, since the function cannot locate the inner header it would need to parse. Also convert the remaining BUG_ON()s in this function to return 0 defensively. A flaw was found in the `vmxnet3` virtual network device driver within the Linux kernel. When processing Geneve-encapsulated packets, the `vmxnet3_get_hdr_len()` function can incorrectly interpret header information, leading to a mismatch between expected and actual packet protocols or IP versions. This can trigger a `BUG_ON` condition, resulting in a kernel panic and a system crash, effectively causing a Denial of Service (DoS).
High [CVE-2026-68294] restrict socket creation to the initial network namespace
In the Linux kernel, the following vulnerability has been resolved: net: qrtr: restrict socket creation to the initial network namespace QRTR keeps its entire port and node state in module-global variables that are not partitioned per network namespace: qrtr_local_nid is a single global node id (always 1) and qrtr_ports is a single global xarray. qrtr_port_lookup() and qrtr_local_enqueue() operate on that global state with no network-namespace check, and qrtr_create() places no restriction on the namespace a socket is created in. As a result an unprivileged process that creates an AF_QIPCRTR socket in a separate network namespace, e.g. via unshare(CLONE_NEWUSER | CLONE_NEWNET), can send QRTR datagrams - including control-plane messages such as QRTR_TYPE_NEW_SERVER - to QRTR sockets owned by another namespace, and vice versa. The receiving socket sees such a message as coming from node id 1, indistinguishable from a legitimate local client, breaking the isolation that network namespaces are expected to provide. QRTR is a transport to global hardware endpoints (the modem and other remote processors) and has no per-namespace semantics; its in-kernel name service already creates its socket in init_net only. Confine the socket family to the initial network namespace, as other non-namespace-aware socket families do (see llc_ui_create() and the ieee802154 socket code).
High [CVE-2026-68289] fix integer overflow in tipc_recvmsg and tipc_recvstream
In the Linux kernel, the following vulnerability has been resolved: tipc: fix integer overflow in tipc_recvmsg() and tipc_recvstream() In tipc_recvmsg(), the copy length is computed as: copy = min_t(int, dlen - offset, buflen); buflen is size_t but min_t(int,...) casts it to int. When buflen exceeds INT_MAX (e.g. 0xFFFFFFFF via io_uring provided buffers), it wraps negative, wins the comparison, and the negative copy length propagates to simple_copy_to_iter() where int-to-size_t promotion makes it SIZE_MAX, triggering a WARN_ON. tipc_recvstream() has the same pattern. Kernel panic - not syncing: kernel: panic_on_warn set... RIP: 0010:simple_copy_to_iter+0x9e/0xd0 (net/core/datagram.c:521) Call Trace: __skb_datagram_iter+0x123/0x8b0 (net/core/datagram.c:402) skb_copy_datagram_iter+0x77/0x1a0 (net/core/datagram.c:534) tipc_recvmsg+0x3d7/0xe80 (net/tipc/socket.c:1934) io_recvmsg+0x47e/0xda0 Fix by changing min_t(int,...) to min_t(size_t,...) in both functions. The result is always <= (dlen - offset), which is bounded by TIPC maximum message size (0x1ffff bytes), so the implicit narrowing on assignment to int copy is always safe. An integer overflow vulnerability exists within the Transparent Inter-Process Communication (TIPC) subsystem, specifically in the `tipc_recvmsg()` and `tipc_recvstream()` functions.
High [CVE-2026-68278] fix buffer overflows in sideband chunk accumulation
In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix buffer overflows in sideband chunk accumulation drm_dp_sideband_append_payload() has three related bugs when processing device-provided sideband reply data: 1. Zero-length curchunk_len underflow: msg_len is a 6-bit field taken directly from the DP sideband header. If a device sends msg_len=0, curchunk_len is set to zero. The condition (curchunk_idx >= curchunk_len) is immediately true, and curchunk_len-1 wraps to 255 (u8 underflow). drm_dp_msg_data_crc4() reads 255 bytes from chunk[48], then memcpy() writes 255 bytes into msg[], both far out of bounds. 2. chunk[48] overflow: curchunk_len can reach 63 (6-bit field). chunk[] is only 48 bytes. Multi-iteration payload assembly appends 16-byte blocks until curchunk_idx reaches curchunk_len, writing up to 15 bytes past the end of chunk[] into msg[]. 3. msg[256] overflow: each chunk contributes (curchunk_len-1) bytes to msg[]. No check ensures curlen + (curchunk_len-1) stays within msg[256], so the memcpy can spill into adjacent struct fields. All three are reachable from any DP MST device that can forge sideband reply messages on a physical connection. A flaw was found in the Linux kernel's DisplayPort (DP) Multi-Stream Transport (MST) subsystem.
High [CVE-2026-68276] fix cleaner shader IB buffer overflow
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx: fix cleaner shader IB buffer overflow The cleaner shader sysfs path allocates a 16-dword (64 byte) IB but incorrectly fills (align_mask + 1) dwords. On GFX rings align_mask is 0xff, so the loop wrote 256 dwords into a 64-byte buffer, causing a kernel page fault. The IB only needs to be a minimal NOP shell to schedule the job; the cleaner shader itself is emitted on the ring via emit_cleaner_shader(). Fill 16 dwords to match the allocation. v2: Use ib_size_dw variable (Lijo) (cherry picked from commit bf21af331ebf72d0935fd70c73192414a422c03a) This occurs because the system incorrectly writes 256 double words (dwords) into a buffer allocated for only 16 dwords (64 bytes). Successful exploitation leads to a kernel page fault, causing a denial of service (DoS) on the system. Red Hat severity: Moderate — CVSS 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H). Weakness: CWE-787. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 9; Red Hat Enterprise Linux for NVIDIA 26. Red Hat lists Red Hat Enterprise Linux 6; Red Hat Enterprise Linux 7; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9; Red Hat OpenShift Container Platform 4 as not affected. Red Hat does not currently list a fixing RHSA for this CVE.
High [CVE-2026-68274] Fix buffer overflow in steered register list allocation
In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Fix buffer overflow in steered register list allocation The size calculation for the steered register extarray uses only the geometry DSS mask (g_dss_mask) to determine the number of entries to allocate: total = bitmap_weight(gt->fuse_topo.g_dss_mask,...) * steer_reg_num; However, the filling loop uses for_each_dss_steering(), which iterates over for_each_dss(), defined as the union of g_dss_mask and c_dss_mask (geometry + compute DSS). On platforms with compute-only DSS bits, the loop writes past the allocated buffer, corrupting adjacent slab objects. This manifests as list_del corruption and SLUB redzone overwrites during drm_managed_release on device unbind, since the overflow corrupts the drmres list_head of neighboring allocations. Fix by computing the allocation size using the union of both DSS masks, matching the iteration pattern of for_each_dss_steering(). -- v2: - use bitmap_weighted_or() (Zhanjun) (cherry picked from commit 0a78a44f4901aa6c9263e66be7fce02282f1109f) This memory corruption can result in system instability and a denial of service. Red Hat severity: Moderate — CVSS 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H). Weakness: CWE-787. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 9.
High [CVE-2026-68263] Linux kernel: drm/imagination use-after-free vulnerability
In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fix double call to drm_sched_entity_fini() Call sequence of double call: pvr_context_destroy pvr_context_kill_queues pvr_queue_kill drm_sched_entity_destroy drm_sched_entity_fini // here pvr_context_put kref_put(..., pvr_context_release) pvr_context_destroy_queues pvr_queue_destroy drm_sched_entity_fini // here Call to drm_sched_entity_destroy() from pvr_context_kill_queues() calls drm_sched_entity_flush() + drm_sched_entity_fini(). drm_sched_entity_flush() ensures all pending jobs are completed and drm_sched_entity_fini() ensures no further submission is allowed as per expectation from pvr_context_kill_queues(). Double call to drm_sched_entity_fini() is misuse of the API so keep call only in pvr_context_create() failure path. Affected products named by the advisory: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux for NVIDIA 26; Red Hat package: kernel.
High [CVE-2026-68257] fix 32-bit overflow in CWSR total size calculation
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix 32-bit overflow in CWSR total size calculation total_cwsr_size was computed in 32-bit before being used as a BO/SVM allocation size. With large ctx_save_restore_area_size and debug_memory_size multiplied by the XCC count, the product can wrap, yielding an undersized CWSR save area that firmware later overruns. Promote total_cwsr_size to u64 and use check_add_overflow()/ check_mul_overflow() in both kfd_queue_acquire_buffers() and kfd_queue_release_buffers(). (cherry picked from commit 319f7e13423ae3f486b9aea82f9ad2d6af0ee608) When processing large input values, this calculation can result in an undersized memory region, which can then be overrun by firmware. This could lead to system instability or a denial of service. Red Hat severity: Moderate — CVSS 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H). Weakness: CWE-787. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 6; Red Hat Enterprise Linux 7; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9; Red Hat Enterprise Linux for NVIDIA 26; Red Hat OpenShift Container Platform 4. Will not fix / out of support: Red Hat Enterprise Linux 8. Red Hat does not currently list a fixing RHSA for this CVE. Affected products named by the advisory: Red Hat package: kernel-rt.
High [CVE-2026-68253] check streams bounds before overflow
In the Linux kernel, the following vulnerability has been resolved: drm/i915/hdcp: check streams[] bounds before overflow The data->streams[] overflow check is done after the buffer overflow has already happened. Side note, emitting a warning splat with a backtrace might be overkill here, but prefer not changing the behaviour other than not doing the overrun. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 9284ab3b6e776c315883ac2611283d263c9460fd) A flaw was found in the Linux kernel's `drm/i915/hdcp` component, which handles display-related operations. This vulnerability arises because a check for buffer overflow is performed after the overflow has already occurred during a write operation. This improper handling of memory boundaries can lead to memory corruption, potentially allowing a local attacker to cause system instability or a denial of service. Red Hat severity: Moderate — CVSS 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H). Weakness: CWE-787. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9. Red Hat does not currently list a fixing RHSA for this CVE. Affected products named by the advisory: Red Hat package: kernel-rt.
High [CVE-2026-68202] close a re-opened queue timer in the destructor
In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: close a re-opened queue timer in the destructor queue_delete() closes the queue timer, then frees it. snd_seq_timer_close() clears q->timer->timeri. snd_use_lock_sync() then drains borrowers, and snd_seq_timer_delete() frees q->timer. A borrower can re-open the timer inside that window. A SET_QUEUE_CLIENT that took a queueptr() use_lock reference before the queue was unlinked runs snd_seq_timer_open() after the close. Open refuses re-open only while timeri is set, and the close just cleared it, so it re-opens timeri. snd_seq_timer_delete() does not close that instance. Its snd_seq_timer_stop() is a no-op, because running was cleared first. So it frees q->timer with the instance still live. The queue is freed next. A non-owner START on the unlocked queue arms it. Reachable by an unprivileged user with access to /dev/snd/seq. No CAP and no queue ownership required. Close any lingering instance in the destructor. There, ->timeri can no longer change: the queue is unlinked and all use_lock borrowers have drained, so no snd_seq_queue_use() can re-open it. Close it before clearing q->timer. snd_timer_close() waits for any in-flight snd_seq_timer_interrupt() to finish, and that callback still reads q->timer (via snd_seq_check_queue()), so q->timer must stay valid until it drains.
High [CVE-2026-68200] Linux kernel: ALSA timer use-after-free vulnerability allows privilege escalation
In the Linux kernel, the following vulnerability has been resolved: ALSA: timer: don't re-enter an instance callback that is still running The userspace-driven timer (utimer) TRIGGER ioctl calls snd_timer_interrupt() directly with no serialization, so two threads triggering the same utimer can run snd_timer_interrupt() on one snd_timer concurrently. snd_timer_process_callbacks() drops timer->lock around each instance callback and marks the in-flight callback with the single SNDRV_TIMER_IFLG_CALLBACK bit; snd_timer_close_locked() waits on that bit to drain an in-flight callback before freeing the instance. The bit cannot represent two concurrent callbacks: when a second interrupt re-queues an instance whose callback is still running, both run at once, the first to finish clears the bit, and the close-path drain then frees the instance (and its callback_data) while the other callback is still live - a use-after-free reachable by any user able to open /dev/snd/timer, both via a user timer instance and via a sequencer queue timer bound to the utimer. snd_timer_interrupt() sets IFLG_CALLBACK before dropping timer->lock, so a concurrent interrupt already observes it under the lock. Skip re-queuing an instance (and its slaves) to the ack/sack list while its callback is in flight; the accumulated pticks are delivered on the next tick, so no event is lost.
High [CVE-2026-68188] Linux kernel Bluetooth RFCOMM: Denial of Service via use-after-free in set_termios
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: Fix session UAF in set_termios rfcomm_tty_set_termios() tests dlc->session without rfcomm_mutex and later passes the pointer to rfcomm_send_rpn(). The latter dereferences both session->initiator and session->sock. Meanwhile, krfcommd can unlink the DLC and free the session while holding rfcomm_mutex. Have the TTY path use the helper and drop its unlocked session check. This keeps the session valid through both the frame construction and socket send. A race condition in the `rfcomm_tty_set_termios()` function allows a session to be freed while it is still actively in use. This use-after-free (UAF) vulnerability can be exploited by a local attacker. Successful exploitation leads to a system crash, resulting in a Denial of Service (DoS). Red Hat severity: Moderate — CVSS 7.1 (CVSS:3.1/AV:A/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H). Weakness: CWE-364. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 6; Red Hat Enterprise Linux 7; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9. Will not fix / out of support: Red Hat Enterprise Linux 8. Red Hat does not currently list a fixing RHSA for this CVE. Affected products named by the advisory: Red Hat package: kernel-rt.
High [CVE-2026-68171] Ensure saved x0 is kept in-sync with tracer updates
A flaw was found in the Linux kernel's arm64 syscall handling. A local attacker with the ability to trace processes (using ptrace) could manipulate syscall arguments after security checks (like seccomp, or secure computing mode) have been performed. This occurs because the kernel's internal record of the first syscall argument (x0) is not updated when a tracer modifies the actual register, leading to security mechanisms observing outdated information. This could potentially allow a bypass of security policies or lead to incorrect auditing. Red Hat severity: Important — CVSS 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H). Weakness: CWE-807. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9; Red Hat OpenShift Container Platform 4. Will not fix / out of support: Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9. Red Hat does not currently list a fixing RHSA for this CVE. Affected products named by the advisory: Red Hat package: kernel-rt.
High [CVE-2026-68166] Linux kernel: Arbitrary code execution via userfaultfd shadow stack manipulation
In the Linux kernel, the following vulnerability has been resolved: userfaultfd: prevent registration of special VMAs Vova Tokarev says: userfaultfd allows registration on shadow stack VMAs. With userfaultfd access, you can register on the shadow stack, discard a page... and inject a page with chosen return addresses via UFFDIO_COPY. Update vma_can_userfault() to reject VM_SHADOW_STACK. While on it, also reject VM_SPECIAL so that if a driver would implement vm_uffd_ops, it wouldn't be possible to register special VMAs with userfaultfd. Since VM_SPECIAL includes VM_DONTEXPAND which is set but hugetlb, exclude hugetlb VMAs from the check for VM_SPECIAL. A local attacker with userfaultfd access could register on shadow stack Virtual Memory Areas (VMAs). By discarding a page and injecting a page with chosen return addresses, an attacker could achieve arbitrary code execution. This vulnerability arises from the improper handling of special VMAs, including shadow stacks, allowing for manipulation of memory regions. Red Hat severity: Important — CVSS 7.3 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:H). Weakness: CWE-94. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 9. Red Hat fixing advisory: RHSA-2026:61887, RHSA-2026:63129. Affected products named by the advisory: Red Hat package: kernel.
High [CVE-2026-68162] avoid auth_enable sysctl UAF during netns teardown
In the Linux kernel, the following vulnerability has been resolved: sctp: avoid auth_enable sysctl UAF during netns teardown proc_sctp_do_auth() updates the SCTP control socket after changing net.sctp.auth_enable. The handler gets the per-net SCTP state from ctl->data, so an already opened sysctl file can still target a network namespace while that namespace is being torn down. SCTP previously registered its per-net sysctls from sctp_defaults_init(), while the control socket is created later from sctp_ctrlsock_init(). This exposed a window during initialization where auth_enable was writable before net->sctp.ctl_sock existed, and a teardown window where auth_enable stayed writable after inet_ctl_sock_destroy() had released the control socket. Move the per-net SCTP sysctl registration into sctp_ctrlsock_init() after sctp_ctl_sock_init() succeeds, and unregister the sysctl table before destroying the control socket in sctp_ctrlsock_exit(). If sysctl registration fails after the control socket was created, destroy the control socket in the same init path. Make sctp_sysctl_net_unregister() tolerate a missing header and clear the saved pointer so init-error and exit paths can safely share the unregister helper. A flaw was found in the Stream Control Transmission Protocol (SCTP) implementation within the Linux kernel.
High [CVE-2026-68161] close UDP tunnel sockets during netns teardown
In the Linux kernel, the following vulnerability has been resolved: sctp: close UDP tunnel sockets during netns teardown proc_sctp_do_udp_port() starts per-net SCTP UDP tunneling sockets when net.sctp.udp_port is set, and stops/restarts them when the sysctl value changes. The netns exit path does not stop these sockets, so a namespace can be torn down while its SCTP UDP tunnel sockets are still installed. This prevents new sysctl writes from racing in while the sockets are being released, and closes the sockets before the control socket is destroyed. A flaw was found in the Linux kernel's SCTP (Stream Control Transmission Protocol) implementation. This oversight can lead to a resource leak, potentially resulting in a denial of service (DoS) condition due to resource exhaustion or unexpected behavior during subsequent system calls. Red Hat severity: Moderate — CVSS 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H). Weakness: CWE-772. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9. Red Hat does not currently list a fixing RHSA for this CVE. Affected products named by the advisory: Red Hat package: kernel-rt.
High [CVE-2026-68160] fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps
In the Linux kernel, the following vulnerability has been resolved: ceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps() ceph_handle_caps() reads snap_trace_len from the wire-format ceph_mds_caps header and uses it unconditionally to build a fake end pointer (snaptrace + snaptrace_len) that is later handed to ceph_update_snap_trace() in the CEPH_CAP_OP_IMPORT case: snaptrace = h + 1; snaptrace_len = le32_to_cpu(h->snap_trace_len); p = snaptrace + snaptrace_len;... case CEPH_CAP_OP_IMPORT: if (snaptrace_len) {... if (ceph_update_snap_trace(mdsc, snaptrace, snaptrace + snaptrace_len, false, &realm)) {... } ceph_update_snap_trace() then decodes a struct ceph_mds_snap_realm from snaptrace using ceph_decode_need(&p, e, sizeof(*ri), bad) with the attacker-supplied fake end e == snaptrace + snaptrace_len. With snaptrace_len == 0xFFFFFFFF the bound check is trivially satisfied, ri = p reads sizeof(struct ceph_mds_snap_realm) past the legitimate msg->front buffer, and ri->num_snaps / ri->num_prior_parent_snaps then drive further out-of-bounds reads of the encoded snap arrays. Affected products named by the advisory: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 7; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9; and 2 more.
High [CVE-2026-68159] Linux kernel: libceph stack out-of-bounds write via crafted OSDMap
In the Linux kernel, the following vulnerability has been resolved: libceph: bound pg_{temp,upmap,upmap_items} length to CEPH_PG_MAX_SIZE __decode_pg_temp() decodes an user-controlled length but only rejects values large enough to overflow the allocation; it does not bound it to CEPH_PG_MAX_SIZE. The helper backs both pg_temp and pg_upmap decoding, and apply_upmap()/get_temp_osds() later copy the decoded list into the fixed-size on-stack array struct ceph_osds.osds[CEPH_PG_MAX_SIZE]. A monitor that sends an OSDMap with a pg_temp/pg_upmap entry longer than 32 thus causes a stack out-of-bounds write. An OSD set for a single PG can never exceed CEPH_PG_MAX_SIZE, so reject longer entries at decode time. The bound is well below the old overflow threshold, so it also covers the allocation-size overflow the previous check guarded against. Affected products named by the advisory: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 7; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9; and 3 more.
High [CVE-2026-68157] Linux kernel: libceph null pointer dereference leads to denial of service
In the Linux kernel, the following vulnerability has been resolved: libceph: guard missing CRUSH type name lookup Localized read selection can walk a parent bucket whose name exists in the CRUSH map while its type has no matching entry in type_names. get_immediate_parent() then dereferences a NULL type_cn and passes an invalid pointer into strcmp(), causing a null-ptr-deref. Skip such malformed parent buckets unless both the bucket name and type name metadata are present. This keeps malformed hierarchy data from crashing locality lookup and safely falls back to "not local". [ idryomov: add WARN_ON_ONCE ] This issue can lead to a system crash, resulting in a Denial of Service (DoS). Red Hat severity: Moderate — CVSS 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H). Weakness: CWE-476. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9. Red Hat does not currently list a fixing RHSA for this CVE. Affected products named by the advisory: Red Hat package: kernel-rt.