Red Hat Linux Linux Kernel Vulnerabilities & Security Advisories
2127 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: 776 high, 1348 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
Medium [CVE-2026-68433] bound get_version reply decode to front len
In the Linux kernel, the following vulnerability has been resolved: libceph: bound get_version reply decode to front len handle_get_version_reply() uses msg->front_alloc_len as the decode boundary for MON_GET_VERSION_REPLY. That is the size of the reused reply buffer, not the number of bytes actually received. A truncated reply can therefore pass ceph_decode_need() and decode the second u64 from stale tail bytes left in the buffer by an earlier message, causing an uninitialized memory read. Use msg->front.iov_len as the receive-side decode boundary, matching other libceph reply handlers and limiting decoding to the bytes that were actually read from the wire. This vulnerability occurs because the system incorrectly processes replies, using an allocated buffer size rather than the actual received data length. A specially crafted, truncated reply can lead to the system reading uninitialized memory. This could result in the disclosure of sensitive information or cause system instability. This issue affects systems using the in-kernel Ceph client (libceph). MON_GET_VERSION_REPLY decoding used the allocated buffer size instead of received length, allowing stale tail bytes to be read on truncated replies from the monitor. Systems without Ceph are not affected. Red Hat severity: Moderate — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-125.
Medium [CVE-2026-68445] Prevent shader BO mappings from becoming writable
In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Prevent shader BO mappings from becoming writable vc4_gem_object_mmap() rejects a writable mapping of a validated shader BO, but leaves VM_MAYWRITE set. Userspace can map the BO read-only and then turn it writable with mprotect(). Validated shader BOs must stay read-only: the validator checks the instructions once and the GPU trusts them afterwards. A writable mapping lets userspace rewrite the code after validation, bypassing the validator. Clear VM_MAYWRITE on the read-only path so the mapping cannot be upgraded, as i915 already does for its read-only objects. This vulnerability allows a local user to bypass security validation for shader code. By manipulating memory permissions, an attacker could modify shader instructions after they have been deemed safe, potentially leading to unauthorized code execution. This issue affects Raspberry Pi and other systems using the vc4 DRM driver. Validated shader buffer objects reject writable mmap but leave VM_MAYWRITE set, allowing mprotect() to make shader code writable after GPU validation. Systems without vc4 hardware are not affected. Red Hat severity: Moderate — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-179.
Medium [CVE-2026-68434] Fix NULL function pointer dereference on DNV/ICX-D/SNR platforms
In the Linux kernel, the following vulnerability has been resolved: serial: 8250_mid: Fix NULL function pointer dereference on DNV/ICX-D/SNR platforms Commit b1b4efea05a5 ("serial: 8250_mid: Disable DMA for selected platforms") replaced the dnv_board setup and exit callbacks with PTR_IF(false,...), which evaluates to NULL. However, the three call sites in mid8250_probe() and mid8250_remove() unconditionally dereference these function pointers without NULL checks, causing a NULL pointer dereference (kernel oops) on any Denverton (DNV), Ice Lake Xeon D (ICX-D/CDF), or Snowridge (SNR) platform. This vulnerability occurs due to missing NULL checks before calling setup and exit callbacks, which can result in a NULL pointer dereference. A local attacker could exploit this flaw to cause a kernel oops, leading to a Denial of Service (DoS) on affected Denverton, Ice Lake Xeon D, or Snowridge platforms. Setup and exit callbacks were set to NULL but are dereferenced unconditionally during probe/remove, causing a kernel oops. Other platforms using 8250_mid are not affected. Red Hat severity: Low — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-476. Affected Red Hat products: Red Hat Enterprise Linux 8; Red Hat OpenShift Container Platform 4. Red Hat does not currently list a fixing RHSA for this CVE.
Medium [CVE-2026-68441] Handle TC_ACT_REDIRECT from qdisc filter chains
In the Linux kernel, the following vulnerability has been resolved: net/sched: Handle TC_ACT_REDIRECT from qdisc filter chains When a TC filter attached to a qdisc filter chain returns TC_ACT_REDIRECT (ex: via an eBPF program calling bpf_redirect() or an act_bpf action), the redirect was silently lost i.e no qdisc classify function handled TC_ACT_REDIRECT, so the packet fell through the switch and was enqueued normally instead of being redirected. This has been broken since bpf_redirect() was introduced for TC in commit 27b29f63058d ("bpf: add bpf_redirect() helper"). We got lucky for a long time because bpf_net_context was a per-CPU variable that was always available. commit 401cb7dae813 ("net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.") turned bpf_net_context into a task_struct member that is only set up by explicit callers. Without a caller setting it up, bpf_redirect() itself crashes with a NULL pointer dereference in bpf_net_ctx_get_ri(). However, even with bpf_net_context available, TC_ACT_REDIRECT from qdisc filter chains cannot be honored without adding skb_do_redirect() calls to every qdisc classify function, which would require changes across net/sched/. Isolate it to ebpf core where it belongs.
Medium [CVE-2026-68435] Fix address space mismatch in kexec command line lookup
In the Linux kernel, the following vulnerability has been resolved: LoongArch: Fix address space mismatch in kexec command line lookup When searching the loaded segments for the "kexec" command line marker, the kexec_load(2) path (file_mode == 0) passes the user-space segment buffer straight to strncmp() through a bogus (char __user *) cast. This dereferences a user pointer in kernel context, which is wrong and is flagged by sparse: arch/loongarch/kernel/machine_kexec.c:84:51: sparse: incorrect type in argument 2 (different address spaces) @@ expected char const * @@ got char [noderef] __user * Here copy the marker-sized prefix of each segment into a small on-stack buffer with copy_from_user() before comparing, and skip segments that fault. The subsequent copy_from_user() that stages the full command line into the safe area is left unchanged. A local attacker could exploit this by using the `kexec_load` system call, which incorrectly passes a user-space segment buffer to a kernel function without proper validation. This improper handling leads to dereferencing a user pointer in kernel context, potentially resulting in a denial of service or information disclosure. This issue affects LoongArch systems using kexec_load(). Systems not using LoongArch are not affected. Red Hat severity: Moderate — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-822.
Medium [CVE-2026-68444] Fix NULL dereference in ffa_partition_info_get
In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Fix NULL dereference in ffa_partition_info_get() ffa_partition_info_get() passes uuid_str directly to uuid_parse() without a NULL check. When a caller passes NULL, uuid_parse() -> __uuid_parse() -> uuid_is_valid() dereferences the pointer, causing a kernel panic: | Unable to handle kernel NULL pointer dereference at virtual address | 0000000000000040 | pc: uuid_parse+0x40/0xac | lr: ffa_partition_info_get+0x1c/0x94 [arm_ffa] Add a NULL guard before uuid_parse() so a NULL argument returns -ENODEV instead of crashing. Callers are expected to always supply a valid partition UUID, so NULL is not a supported input. A local attacker or malicious process could exploit this vulnerability by providing a NULL argument to the `ffa_partition_info_get()` function. This missing NULL check leads to a NULL pointer dereference, causing a kernel panic and resulting in a Denial of Service (DoS) for the affected system. This issue affects ARM systems using FF-A (Firmware Framework for Arm). ffa_partition_info_get() passes a NULL uuid_str to uuid_parse() without validation, causing kernel panic. Callers must pass valid UUID strings; systems without FF-A are not affected. Red Hat severity: Moderate — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-476.
Medium [CVE-2026-68437] Fit paired fragment job in the correct CCCB
In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fit paired fragment job in the correct CCCB For geometry jobs with a paired fragment job, at the moment, the DRM scheduler's prepare_job() callback: - checks for internal (driver) dependencies for the geometry job; - calls into pvr_queue_get_paired_frag_job_dep() to check for external dependencies for the fragment job (the two jobs are submitted together but the common scheduler code doesn't know about it, so this needs to be done at this point in time); - calls into the prepare_job() callback again, but for the fragment job, to check its internal dependencies as well, passing the fragment job's drm_sched_job and the geometry job's drm_sched_entity / pvr_queue. The problem with the last step is that pvr_queue_prepare_job() doesn't always take the mismatched fragment job and geometry queue into account, in particular when checking whether there is space for the fragment command to be submitted, so the code ends up checking for space in the geometry (i.e. wrong) CCCB. The rest of the nested prepare_job() callback happens to work fine at the moment as the other internal dependencies are not relevant for a paired fragment job. Affected products named by the advisory: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux for NVIDIA 26; Red Hat package: kernel.
Medium [CVE-2026-68443] (gigabyte_waterforce) Stop device IO before calling hid_hw_stop
In the Linux kernel, the following vulnerability has been resolved: hwmon: (gigabyte_waterforce) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after "io start" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop(). A race condition exists because `hid_hw_stop()` does not properly stop device I/O. This can occur during a driver probe failure after I/O has been initiated, leading to a Use-After-Free (UAF) vulnerability. An attacker could potentially exploit this to achieve arbitrary code execution or cause a denial of service. This issue affects Gigabyte Waterforce AIO coolers using the gigabyte_waterforce hwmon driver. hid_hw_stop() does not stop device I/O, so probe failure after io start can race with hid_input_report() causing use-after-free. Systems without this hardware are not affected. Red Hat severity: Moderate — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-825. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux for NVIDIA 26.
Medium [CVE-2026-68449] fix infinite loop in NCQ tag completion bit-scanning
In the Linux kernel, the following vulnerability has been resolved: ata: sata_dwc_460ex: fix infinite loop in NCQ tag completion bit-scanning The hand-rolled bit-scanning loop in the NCQ completion path has an infinite loop bug. When tag_mask has only high bits set (e.g. 0x80000000), the inner while loop left-shifts tag_mask until it overflows to 0. At that point!(0 & 1) is always true and 0 <<= 1 stays 0, causing an infinite loop in hardirq context with a spinlock held. Replace the open-coded bit-scanning with __ffs() which correctly finds the least significant set bit and is bounded by the width of the argument. This can lead to a system hang or crash, resulting in a Denial of Service (DoS). Red Hat severity: Moderate — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-835. Affected Red Hat products: Red Hat Enterprise Linux 7; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9; Red Hat OpenShift Container Platform 4. Red Hat does not currently list a fixing RHSA for this CVE. Affected products named by the advisory: Red Hat package: kernel-rt.
Medium [CVE-2026-68447] clamp v9 CRIU control stack checkpoint copy to BO size
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: clamp v9 CRIU control stack checkpoint copy to BO size CRIU checkpoint copies the MQD control stack using cp_hqd_cntl_stack_size from hardware without bounding it to the allocated BO region. If the HW field is larger than the queue's control stack allocation, memcpy reads past the BO into adjacent GTT memory and can leak kernel data to userspace. Store the page-aligned control stack BO size in mqd_manager and clamp checkpoint copies and reported checkpoint sizes to min(cp_hqd_cntl_stack_size, mm->ctl_stack_size). Apply the same bound for multi-XCC v9.4.3 checkpoint layout. (cherry picked from commit 6c2abd0ec09e86c6323010673766f76050e28aa3) The Checkpoint/Restore in Userspace (CRIU) checkpoint process, which saves and restores the state of a running application, incorrectly copies the Memory Queue Descriptor (MQD) control stack. This occurs because the copy operation does not properly limit the amount of data copied to the allocated buffer size. A local attacker could exploit this by causing the system to read beyond the intended memory region, potentially leading to the disclosure of sensitive kernel data to userspace. Red Hat severity: Moderate — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-125.
Medium [CVE-2026-68428] Fix use-after-free on vendor module reload
In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Fix use-after-free on vendor module reload mmu_destroy_caches() destroys pte_list_desc_cache and mmu_page_header_cache, but leaves both pointers unchanged. The pointers live in kvm.ko, and therefore survive when a vendor module is unloaded while kvm.ko remains loaded. If creation of pte_list_desc_cache fails during a subsequent vendor module load, its assignment sets pte_list_desc_cache to NULL and the error path calls mmu_destroy_caches(). mmu_page_header_cache still points to the cache destroyed during the preceding vendor module unload. Passing that stale pointer to kmem_cache_destroy() causes a slab use-after-free. Reproduce the issue on a v7.1.3 kernel with CONFIG_KASAN=y, CONFIG_KASAN_GENERIC=y, CONFIG_KVM=m, and CONFIG_KVM_INTEL=m. A one-shot test hook forces pte_list_desc_cache to NULL on the second invocation of kvm_mmu_vendor_module_init(): 1. Load kvm.ko and kvm-intel.ko, creating both caches. 2. Unload only kvm_intel, leaving kvm.ko loaded. 3. Reload kvm_intel and force initialization through the -ENOMEM path. KASAN reports: BUG: KASAN: slab-use-after-free in kvm_mmu_vendor_module_init+0x5b/0x170 [kvm]... kmem_cache_destroy+0x21/0x1d0 kvm_mmu_vendor_module_init+0x5b/0x170 [kvm]...
Medium [CVE-2026-68425] Drop unmatched RMPP responses before reassembly
In the Linux kernel, the following vulnerability has been resolved: IB/mad: Drop unmatched RMPP responses before reassembly Kernel-handled RMPP receive processing starts reassembly for active DATA responses before the response is matched to an outstanding send. The normal match happens later, after ib_process_rmpp_recv_wc() has either assembled a complete message or consumed the segment. That ordering lets an unsolicited response that routes to a kernel RMPP agent by the high TID bits allocate or extend RMPP receive state before the full TID and source address are checked against a real request. A reordered burst can therefore reach the receive-side insertion path even though the response would not match any send. The matcher already checks the full TID, management class and source address/GID against the agent wait, backlog and in-flight send lists. If there is no match, drop the response without creating RMPP state. This leaves the RMPP window behavior unchanged and only rejects responses that have no corresponding request. A flaw was found in the Linux kernel's InfiniBand (IB) Management Datagram (mad) component. A remote attacker could exploit this vulnerability by sending unsolicited Reliable Multicast Packet Protocol (RMPP) responses.
Medium [CVE-2026-68422] fix root leak if its reloc root is unexpected in merge_reloc_roots
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix root leak if its reloc root is unexpected in merge_reloc_roots() If we have an unexpected reloc_root for our root, we jump to the out label but never drop the reference we obtained for root, resulting in a leak. Add a missing btrfs_put_root() call. A flaw was found in the btrfs filesystem component of the Linux kernel. An unexpected relocation root in the `merge_reloc_roots()` function can lead to a resource leak. This occurs because a reference to the root is not properly released, potentially causing system instability or a denial of service due to resource exhaustion. This issue affects systems using the Btrfs file system during balance/relocation operations. If merge_reloc_roots() encounters an unexpected relocation root, it exits without releasing a reference on the root structure, leaking memory. Over time this can contribute to resource exhaustion on affected workloads. Red Hat severity: Low — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-772. Affected Red Hat products: Red Hat Enterprise Linux 10. Red Hat does not currently list a fixing RHSA for this CVE. Affected products named by the advisory: Red Hat package: kernel.
Medium [CVE-2026-68421] Don't warn on core-sched forced idle in put_prev_task_scx
In the Linux kernel, the following vulnerability has been resolved: sched_ext: Don't warn on core-sched forced idle in put_prev_task_scx() put_prev_task_scx() warns when a runnable task drops to a lower sched_class without SCX_OPS_ENQ_LAST, on the assumption that balance_one() would have kept it running. Core scheduling breaks that: a forced-idle SMT sibling reschedules through the core_pick fast path in pick_next_task(), which skips pick_task_scx() and thus balance_one(), so a runnable task can drop to idle with ENQ_LAST unset. Gate the warning on sched_cpu_cookie_match(): a cookie mismatch means core scheduling forced the idle, while a match (or core scheduling off) still catches a genuine missing-ENQ_LAST drop. The `put_prev_task_scx()` function incorrectly issues a warning when a runnable task transitions to an idle state due to core scheduling. This occurs because the core scheduling mechanism bypasses certain checks, leading to a misleading warning. This issue affects sched_ext (BPF scheduler). Requires CONFIG_SCHED_CLASS_EXT. Red Hat severity: Moderate — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-1288. Affected Red Hat products: Red Hat Enterprise Linux for NVIDIA 26. Affected products named by the advisory: Red Hat package: kernel.
Medium [CVE-2026-68418] Prevent user-triggered null deref on QP create
In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Prevent user-triggered null deref on QP create Previously, the user QP creation path would only attempt to populate iwqp->iwpbl if the user-provided req.user_wqe_bufs field was non-zero. The problem is that iwqp->iwpbl is unconditionally dereferenced later on in irdma_setup_virt_qp. The end result is that a user could send a zero user_wqe_bufs value and trigger a null ptr deref. Fix this by unconditionally calling irdma_get_pbl and bailing if it fails, similar to the CQ and SRQ paths. A local user could exploit this vulnerability by providing a zero value for `user_wqe_bufs` during the creation of a Queue Pair (QP). This action leads to a null pointer dereference, which can cause the system to crash, resulting in a Denial of Service (DoS). This issue affects systems using the Intel RDMA (irdma) driver. A local user creating a queue pair with user_wqe_bufs set to zero can trigger a NULL pointer dereference because iwpbl is not allocated but is later dereferenced unconditionally. Systems without irdma/RDMA userspace access are not affected. Red Hat severity: Low — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/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 Enterprise Linux for NVIDIA 26.
Medium [CVE-2026-68417] publish QP after initialization
In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: publish QP after initialization siw_create_qp() currently calls siw_qp_add() before the queues, CQ pointers, state, completion, and device list entry are ready. A QPN lookup can therefore reach a QP that is still being constructed. The `siw_create_qp()` function prematurely publishes a Queue Pair (QP) before its complete initialization. This allows a Queue Pair Number (QPN) lookup to access a QP that is still under construction, potentially leading to unexpected behavior or system instability. This issue affects RDMA siw (Soft-iWARP). QP published to lookup table before initialization completes. Systems not using siw RDMA are not affected. Red Hat severity: Moderate — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-908. Affected Red Hat products: 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.
Medium [CVE-2026-68413] memory leak in ipw2100_pci_init_one
In the Linux kernel, the following vulnerability has been resolved: wifi: ipw2100: fix potential memory leak in ipw2100_pci_init_one() The memory allocated in the ipw2100_alloc_device() function is not freed in some of the error paths in ipw2100_pci_init_one(). Fix that by converting the direct return into a goto to the error path return. The error path when pci_enable_device() fails cannot jump to fail, since at this point priv is not set, so perform error handling inline. A flaw was found in the ipw2100 wireless driver in the Linux kernel. This occurs because memory allocated by ipw2100_alloc_device() is not properly released in specific error scenarios, potentially allowing a local attacker to cause a denial of service due to resource exhaustion. Red Hat severity: Moderate — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-772. 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 does not currently list a fixing RHSA for this CVE. Affected products named by the advisory: Red Hat package: kernel-rt.
Medium [CVE-2026-68412] Fix an error handling path in cfg80211_wext_siwscan
In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: Fix an error handling path in cfg80211_wext_siwscan() If the test against IEEE80211_MAX_SSID_LEN fails, then 'creq' leaks. A flaw was found in the Linux kernel's Wi-Fi subsystem, specifically within the `cfg80211` component. This vulnerability, located in the `cfg80211_wext_siwscan()` function, can lead to a memory leak. A local attacker could exploit this by sending a crafted Wi-Fi scan request with an Extended Service Set Identifier (ESSID) exceeding the maximum allowed length. This improper handling of the oversized ESSID causes a `creq` object to not be properly freed, potentially leading to a denial of service. This issue affects cfg80211 wireless extensions scan requests. If SSID length validation fails in cfg80211_wext_siwscan(), the allocated creq structure leaks. Systems using only nl80211 (not wext) are not affected. Red Hat severity: Low — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-772. 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 6; Red Hat Enterprise Linux for NVIDIA 26.
Medium [CVE-2026-68407] free RNR data on MBSSID mismatch
In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: free RNR data on MBSSID mismatch nl80211_parse_beacon() rejects EMA RNR data when there are fewer RNR entries than MBSSID entries. The rejected RNR allocation has not been attached to the beacon data yet, so free it before returning the error. When processing beacon frames, the `nl80211_parse_beacon()` function may fail to properly free allocated RNR (Reduced Neighbor Report) data if there is a mismatch in the number of RNR and MBSSID (Multiple Basic Service Set Identifier) entries. This improper memory handling could lead to a memory leak, potentially allowing a remote attacker to cause a denial of service. This issue affects nl80211 beacon parsing with EMA MBSSID and RNR data. Systems not using nl80211 beacon parsing are not affected. Red Hat severity: Low — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/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.
Medium [CVE-2026-68406] validate PMSR FTM preamble range
In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: validate PMSR FTM preamble range PMSR FTM request parsing accepts preamble values outside the enumerated nl80211 preamble range. Reject out-of-range values before using them in the parser capability bit test using the policy. [drop unnecessary check] A flaw was found in the `cfg80211` component of the Linux kernel's Wi-Fi subsystem. An attacker could exploit this by providing malformed input, potentially leading to unexpected system behavior or resource exhaustion. This issue affects the cfg80211 Wi-Fi configuration layer. PMSR FTM request parsing accepted preamble values outside the nl80211 enumerated range, which could lead to out-of-bounds access in capability bit tests. Exploitation requires a local user able to issue nl80211 PMSR requests. Red Hat severity: Low — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-839. 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.