Red Hat Linux Linux Kernel Vulnerabilities & Security Advisories
2144 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: 779 high, 1362 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-68328] Check resource mutex allocation
In the Linux kernel, the following vulnerability has been resolved: nfp: Check resource mutex allocation nfp_cpp_resource_find() allocates a CPP mutex handle for the matching resource-table entry and then reports success. nfp_resource_try_acquire() immediately passes that handle to nfp_cpp_mutex_trylock(). However, nfp_cpp_mutex_alloc() returns NULL on failure. Do the same for the resource mutex and fail the lookup before publishing the rest of the resource handle. This issue was found by a static analysis checker and confirmed by manual source review. However, the `nfp_cpp_resource_find()` function might still report success, leading to a subsequent attempt to dereference the NULL pointer by `nfp_resource_try_acquire()`. This can allow a local attacker to cause a system crash, resulting in a denial of service. This issue affects systems using Netronome NFP network adapters. When CPP mutex allocation fails during resource lookup, the driver still reports success and later dereferences a NULL mutex pointer. Systems without NFP hardware 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 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-68324] Fix out-of-bounds memset in dmar_latency_disable
In the Linux kernel, the following vulnerability has been resolved: iommu/intel: Fix out-of-bounds memset in dmar_latency_disable() dmar_latency_disable() intends to zero out only the single latency_statistic entry for the given type, but the memset size was computed as sizeof(*lstat) * DMAR_LATENCY_NUM, which clears the entire array starting from &lstat[type]. When type > 0, this writes beyond the end of the allocated array, corrupting adjacent memory. A flaw was found in the Intel IOMMU (Input/Output Memory Management Unit) driver within the Linux kernel. The `dmar_latency_disable()` function incorrectly calculates the size for a memory clear operation, leading to an out-of-bounds write. A local attacker could exploit this vulnerability to corrupt adjacent memory, potentially leading to system instability or a denial of service. This issue affects Intel IOMMU latency statistics. dmar_latency_disable() memset size clears beyond the target entry, writing adjacent array elements. Systems without Intel VT-d DMAR latency support 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-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.
Medium [CVE-2026-68322] Fix inet6_addr_lst NULL dereference when IPv6 is disabled
In the Linux kernel, the following vulnerability has been resolved: rds: Fix inet6_addr_lst NULL dereference when IPv6 is disabled When booting with the 'ipv6.disable=1' parameter, inet6_addr_lst is never initialized because inet6_init() exits before addrconf_init() is called to initialize it. Affected products named by the advisory: Red Hat Enterprise Linux 9; Red Hat OpenShift Container Platform 4; Red Hat package: kernel.
Medium [CVE-2026-68321] fix FDIR filter leak on remove
In the Linux kernel, the following vulnerability has been resolved: net: txgbe: fix FDIR filter leak on remove Perfect FDIR filters can be added while the interface is down and are kept on the software list for later restore. unregister_netdev() only calls ndo_stop when the device is up, so txgbe_fdir_filter_exit() in txgbe_close() is skipped in that case and the filters are leaked on driver remove. Free the filter list from txgbe_remove() as well. A resource leak vulnerability exists in the txgbe network driver. This flaw occurs because Flow Director (FDIR) filters are not properly freed when the network interface is removed while it is in a down state. This can lead to a gradual consumption of system resources, potentially resulting in a Denial of Service (DoS) over time. This issue affects Wangxun txgbe NICs. Systems without txgbe 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-772. Affected Red Hat products: Red Hat Enterprise Linux for NVIDIA 26. Red Hat lists 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 OpenShift Container Platform 4 as not affected. 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-68319] fix deadlock between reset thread and remove
In the Linux kernel, the following vulnerability has been resolved: pds_core: fix deadlock between reset thread and remove pci_reset_function() acquires device_lock before performing the reset. pdsc_remove() is called by the PCI core with device_lock already held. If pdsc_pci_reset_thread() is running when pdsc_remove() is called, destroy_workqueue() will block waiting for the work to complete, while the work is blocked waiting for device_lock - deadlock. Use pci_try_reset_function() which uses pci_dev_trylock() internally. This acquires both the device lock and the PCI config access lock without blocking - if either lock is contended, it returns -EAGAIN immediately. This avoids the deadlock while also ensuring proper config space access serialization during the reset. The pci_dev_get/put calls are also removed as they were unnecessary - the driver-owned workqueue is destroyed in pdsc_remove(), guaranteeing the work completes before remove returns. The PCI core holds its reference to pci_dev throughout the entire unbind sequence. This vulnerability involves a deadlock condition that can occur when the `pci_reset_function()` and `pdsc_remove()` functions are called concurrently. This can cause the system to become unresponsive, leading to a denial of service. This issue affects AMD Pensando (pds_core) devices. Systems without pds_core hardware are not affected.
Medium [CVE-2026-68318] fix use-after-free on workqueue during remove
In the Linux kernel, the following vulnerability has been resolved: pds_core: fix use-after-free on workqueue during remove In pdsc_remove(), the workqueue is destroyed before pdsc_teardown() is called. This ordering allows two paths to queue work on the destroyed workqueue: 1. If pdsc_teardown() -> pdsc_devcmd_reset() times out, the error path in pdsc_devcmd_locked() queues health_work. 2. A NotifyQ event can trigger the ISR and queue work before free_irq() is called in pdsc_teardown(). Fix by moving destroy_workqueue() after pdsc_teardown() so the workqueue outlives every queuer; destroy_workqueue() then flushes any work still pending. Draining the queued work also requires ordering the teardown so the resources that work touches are freed last: - In pdsc_qcq_free(), after freeing the interrupt, cancel_work_sync() the queue's work and only then clear qcq->intx, so pdsc_process_adminq()'s read of qcq->intx for interrupt-credit return cannot race with the clear. - Free adminqcq before notifyqcq: the shared adminq ISR is released when adminqcq is freed, and the adminq work accesses notifyqcq, so both must be stopped before notifyqcq is freed. This timing issue allows for work to be queued on an already destroyed workqueue, which can lead to system instability or potentially other impacts.
Medium [CVE-2026-68309] fix possible NULL-pointer deref in mt76_connac_mcu_uni_bss_he_tlv
In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: connac: fix possible NULL-pointer deref in mt76_connac_mcu_uni_bss_he_tlv() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it. This vulnerability occurs because the `mt76_connac_get_he_phy_cap` routine can return a NULL value, which is then dereferenced without proper validation. This can lead to a NULL-pointer dereference, potentially causing a system crash and resulting in a Denial of Service (DoS). This issue affects MediaTek mt76 connac Wi-Fi drivers broadly. mt76_connac_mcu_uni_bss_he_tlv() does not guard NULL from mt76_connac_get_he_phy_cap(). Systems without affected MediaTek Wi-Fi 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. 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-68307] fix crash in reset link replay
In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: fix crash in reset link replay During reset recovery, mt7925_vif_connect_iter() replays firmware state for links tracked in mvif->valid_links. After MLO link changes or MCU timeout recovery, the driver bitmap can temporarily contain a link whose mac80211 bss_conf has already gone away. This can pass a NULL bss_conf to mt76_connac_mcu_uni_add_dev(), matching the crash where x1, the second argument, is NULL: pc: mt76_connac_mcu_uni_add_dev+0x8c/0x1f8 [mt76_connac_lib] lr: mt7925_vif_connect_iter+0x9c/0x168 [mt7925_common] x2: ffffff80a77f6018 x1: 0000000000000000 x0: ffffff8099402080 Call trace: mt76_connac_mcu_uni_add_dev+0x8c/0x1f8 [mt76_connac_lib] mt7925_vif_connect_iter+0x9c/0x168 [mt7925_common] mt7925_mac_reset_work+0x264/0x2f8 [mt7925_common] Skip missing bss_conf entries before replaying the link. Non-MLO AP/STA reset replay is unchanged because the helper still returns &vif->bss_conf for the legacy link. A flaw was found in the MediaTek mt7925 Wi-Fi driver within the Linux kernel. During a reset recovery process, the driver can attempt to access a network configuration that no longer exists. This can lead to a null pointer dereference, causing the system to crash and resulting in a Denial of Service (DoS). This issue affects MediaTek mt7925 Wi-Fi with MLO.
Medium [CVE-2026-68305] Add drm_dev guards when detaching CCS read/write buffers
In the Linux kernel, the following vulnerability has been resolved: drm/xe/vf: Add drm_dev guards when detaching CCS read/write buffers CCS read/write buffers are freed during BO destruction. In some cases, BOs may be destroyed after the device is unbound but while the DRM structure remains valid, leading to NULL pointer dereferences when accessing device resources. Affected products named by the advisory: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 9; Red Hat package: kernel.
Medium [CVE-2026-68304] fix 802.1X-SHA256 call trace warning
In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix 802.1X-SHA256 call trace warning Based on wpa_auth as 1x_256 mode, need to set up "use_fwsup" with BRCMF_PROFILE_FWSUP_1X. Affected products named by the advisory: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9; Red Hat OpenShift Container Platform 4; and 1 more.
Medium [CVE-2026-68296] fix lltx regression for GRE tunnels with SEQ/CSUM
In the Linux kernel, the following vulnerability has been resolved: net: gre: fix lltx regression for GRE tunnels with SEQ/CSUM Before commit 00d066a4d4ed ("netdev_features: convert NETIF_F_LLTX to dev->lltx"), NETIF_F_LLTX was set unconditionally in both __gre_tunnel_init() and ip6gre_tnl_init_features() alongside GRE_FEATURES: dev->features |= GRE_FEATURES | NETIF_F_LLTX; When that commit converted NETIF_F_LLTX to the dev->lltx flag, it placed 'dev->lltx = true' after the SEQ/CSUM early returns instead of before them. This causes GRE/GRETAP/ip6gre tunnels with SEQ or CSUM+encap to lose lockless TX, reintroducing _xmit_lock acquisition around their ndo_start_xmit. Since GRE xmit re-enters the stack via ip_tunnel_xmit(), holding _xmit_lock risks ABBA deadlock with the underlay device. CPU0 CPU1 ---- ---- lock(&qdisc_xmit_lock_key#6); lock(&qdisc_xmit_lock_key#3); lock(&qdisc_xmit_lock_key#6); lock(&qdisc_xmit_lock_key#3); Fix by moving dev->lltx = true before the early returns in both functions, restoring the original unconditional behavior. A flaw was found in the Linux kernel's Generic Routing Encapsulation (GRE) tunnel implementation. An issue with how lockless transmission was handled for GRE tunnels with Sequence Number (SEQ) or Checksum (CSUM) features could lead to a deadlock.
Medium [CVE-2026-68295] Zero-extend signed ALU32 div/mod results
In the Linux kernel, the following vulnerability has been resolved: LoongArch: BPF: Zero-extend signed ALU32 div/mod results ALU32 operations write a 32-bit result and leave the upper 32 bits of the BPF register zero. The LoongArch JIT sign-extends the result of signed ALU32 BPF_DIV and BPF_MOD (off=1), so a negative 32-bit quotient or remainder leaves bits 63:32 set in JITted code while the verifier and interpreter model those bits as zero. Keep sign-extension on the operands, which signed divide needs, and zero-extend the ALU32 result after the divide or modulo instruction, matching the unsigned ALU32 div/mod paths and every other ALU32 operation in this JIT. The LoongArch Just-In-Time (JIT) compiler for the Berkeley Packet Filter (BPF) subsystem incorrectly sign-extends the results of signed 32-bit division and modulo operations. This behavior causes the upper bits of BPF registers to be set, which differs from the expected zero-extension model used by the BPF verifier and interpreter. Such an inconsistency could lead to unexpected program behavior or incorrect data processing within BPF programs. Signed ALU32 div/mod results are sign-extended instead of zero-extended, diverging from verifier semantics. 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-681.
Medium [CVE-2026-68291] Linux kernel: idpf driver null pointer dereference leads to Denial of Service
In the Linux kernel, the following vulnerability has been resolved: idpf: fix max_vport related crash on allocation error during init Set adapter->max_vports only after successful allocation of vports, netdevs and vport_config buffers. Affected products named by the advisory: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9; Red Hat Enterprise Linux for NVIDIA 26; and 1 more.
Medium [CVE-2026-68287] fix size calculations for 64-bit attributes
In the Linux kernel, the following vulnerability has been resolved: drop_monitor: fix size calculations for 64-bit attributes net_dm_packet_report_fill() and net_dm_hw_packet_report_fill() use nla_put_u64_64bit() to append 64-bit attributes (NET_DM_ATTR_PC and NET_DM_ATTR_TIMESTAMP). On 32-bit architectures without CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS, nla_put_u64_64bit() may append a 4-byte NET_DM_ATTR_PAD attribute for 64-bit alignment. However, net_dm_packet_report_size() and net_dm_hw_packet_report_size() used nla_total_size(sizeof(u64)) instead of nla_total_size_64bit(sizeof(u64)), budgeting 12 bytes instead of up to 16 bytes. This under-estimation of SKB size can lead to an skb_over_panic() when __nla_reserve() or skb_put() is subsequently called. Fix this by using nla_total_size_64bit(sizeof(u64)) in both size calculations. Incorrect size calculations for 64-bit attributes on 32-bit architectures without efficient unaligned access support can lead to an under-estimation of internal buffer (SKB) size. This under-estimation may cause a kernel panic, resulting in a Denial of Service (DoS) for the affected system. This issue affects drop_monitor on 32-bit architectures. Incorrect nla_put_u64_64bit size calculations can corrupt netlink messages. 64-bit systems 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).
Medium [CVE-2026-68286] perform u64_stats updates under IRQ-disabled section
In the Linux kernel, the following vulnerability has been resolved: drop_monitor: perform u64_stats updates under IRQ-disabled section In net_dm_packet_trace_kfree_skb_hit() and net_dm_hw_trap_packet_probe(), u64_stats_update_begin() / u64_stats_inc() / u64_stats_update_end() were called after spin_unlock_irqrestore(&...drop_queue.lock, flags), when local IRQs had already been re-enabled. Tracepoint probes can execute in IRQ or softirq context. On 32-bit architectures, u64_stats_update_begin() disables preemption but not interrupts, relying on seqcount writes. If a nested interrupt occurs on the same CPU during the 64-bit stats update, the reentrant seqcount update can corrupt the seqcount state or stats value. Fix this by performing the 64-bit per-CPU stats update before releasing drop_queue.lock via spin_unlock_irqrestore(), ensuring local interrupts remain disabled during the u64_stats update. On 32-bit architectures, a race condition can occur during the update of 64-bit statistics. If a nested interrupt happens on the same CPU while these statistics are being updated, it can lead to the corruption of internal sequence counters or the statistical values themselves. This data corruption could potentially impact system stability or lead to inaccurate monitoring information.
Medium [CVE-2026-68284] Linux kernel: bpf/sockmap use-after-free vulnerability leading to denial of service
In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix cork use-after-free in tcp_bpf_sendmsg() tcp_bpf_sendmsg() keeps msg_tx across sk_stream_wait_memory(), which drops and reacquires the socket lock. Its error path tries to decide whether msg_tx names the local temporary message by comparing it with the current value of psock->cork. This comparison is unsafe when two threads send on the same socket: Thread A Thread B msg_tx = psock->cork sk_msg_alloc() fails sk_stream_wait_memory() releases the socket lock acquires the socket lock completes the cork psock->cork = NULL frees the cork reacquires the socket lock msg_tx!= psock->cork sk_msg_free(msg_tx) The stale cork is therefore mistaken for the local temporary message and freed again. KASAN reported: BUG: KASAN: slab-use-after-free in sk_msg_free+0x49/0x50 Read of size 4 at addr ffff88810c908800 by task poc/90 Call Trace: sk_msg_free+0x49/0x50 tcp_bpf_sendmsg+0x14f5/0x1cc0 __sys_sendto+0x32c/0x3a0 __x64_sys_sendto+0xdb/0x1b0 Allocated by task 89: __kasan_kmalloc+0x8f/0xa0 tcp_bpf_sendmsg+0x16b3/0x1cc0 Freed by task 91: __kasan_slab_free+0x43/0x70 kfree+0x131/0x3c0 tcp_bpf_sendmsg+0xec3/0x1cc0 msg_tx can only name the stack-local tmp or the shared cork. Check for tmp directly so a changed psock->cork cannot turn a shared message into an apparent local one.
Medium [CVE-2026-68281] Count paired job fence as dependency in prepare_job
In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Count paired job fence as dependency in prepare_job() The DRM scheduler's prepare_job() callback counts the remaining non-signaled native dependencies for a job, preventing job submission until those (plus job data and fence update) can fit in the job queue's CCCB. This means checking which dependencies can be waited upon in the firmware, i.e. whether they are backed by a UFO object, i.e. whether their drm_sched_fence::parent has been assigned to a pvr_queue_fence::base fence. That happens when the job owning the fence is submitted to the firmware. Paired geometry and fragment jobs are submitted at the same time, which means the dependency between them can't be checked this way before submission. Update job_count_remaining_native_deps() to take into account the dependency between paired jobs. This fixes cases where prepare_job() underestimated the space left in an almost full fragment CCCB, wrongly unblocking run_job(), which then returned early without writing the full sequence of commands to the CCCB. Affected products named by the advisory: Red Hat Enterprise Linux for NVIDIA 26; Red Hat package: kernel.
Medium [CVE-2026-68279] fix OOB reads in remote DPCD/I2C sideband reply parsers
In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix OOB reads in remote DPCD/I2C sideband reply parsers drm_dp_sideband_parse_remote_dpcd_read() reads num_bytes from the raw message and then unconditionally does: memcpy(bytes, &raw->msg[idx], num_bytes); without checking that idx + num_bytes curlen. raw->msg[] is 256 bytes; if a malicious or misbehaving MST hub sets num_bytes larger than the remaining payload, the memcpy reads past the received data into whatever follows in raw->msg[]. drm_dp_sideband_parse_remote_i2c_read_ack() has the same flaw (noted with a /* TODO check */ comment since the code was introduced). Fix both functions by using a single combined check (idx + num_bytes > curlen) before each memcpy. Since num_bytes is u8, it is always >= 0, so this strictly subsumes the simpler idx > curlen form and no separate step is needed. [added missing fixes tag] A flaw was found in the Linux kernel's DisplayPort (DP) Multi-Stream Transport (MST) subsystem. A malicious or misbehaving MST hub could send a specially crafted sideband message that causes an out-of-bounds read in the `drm_dp_sideband_parse_remote_dpcd_read()` and `drm_dp_sideband_parse_remote_i2c_read_ack()` functions. This vulnerability allows the system to read past the intended data, potentially leading to information disclosure or system instability.
Medium [CVE-2026-68275] check amdgpu_vm_bo_find result in GET_MAPPING_INFO
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: check amdgpu_vm_bo_find() result in GET_MAPPING_INFO The AMDGPU_GEM_OP_GET_MAPPING_INFO path of amdgpu_gem_op_ioctl() looks up the bo_va for the buffer object in the caller's VM via amdgpu_vm_bo_find(), but uses the returned pointer without checking it. amdgpu_vm_bo_find() returns NULL when the BO has no bo_va in that VM, which is the normal case for a BO that has never been mapped. The result is fed straight into amdgpu_vm_bo_va_for_each_valid_mapping(), which expands to list_for_each_entry(mapping, &(bo_va)->valids, list) and dereferences bo_va, causing a NULL pointer dereference. This is reachable by any process able to issue the ioctl (render group) simply by requesting mapping info for an unmapped BO. Return -ENOENT when no bo_va is found, jumping to out_exec so the drm_exec context and GEM object reference are released. (cherry picked from commit 528b19377affc1cc7362a70a254c1dda793595f9) A local attacker, with the ability to issue ioctl commands to the render group, could trigger a null pointer dereference by requesting mapping information for an unmapped buffer object. This could lead to a system crash, resulting in a denial of service. This issue affects AMDGPU GEM ioctl. Systems without AMD GPUs are not affected.
Medium [CVE-2026-68272] validate CP_GFX_SHADOW chunk size in CS pass1
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: validate CP_GFX_SHADOW chunk size in CS pass1 Add a minimum-length check for the AMDGPU_CHUNK_ID_CP_GFX_SHADOW chunk in amdgpu_cs_pass1(), matching the gate already present for the IB, FENCE and BO_HANDLES chunk types. The CP_GFX_SHADOW case previously shared a bare break with the dependency and syncobj chunk types, which do not dereference a fixed-size struct. When userspace submits this chunk with length_dw == 0, vmemdup_array_user() is called with size 0 and returns ZERO_SIZE_PTR, which passes the IS_ERR() check. amdgpu_cs_p2_shadow() then dereferences chunk->kdata as a struct drm_amdgpu_cs_chunk_cp_gfx_shadow (reading shadow->flags), faulting on the ZERO_SIZE_PTR and causing a NULL-pointer dereference. This is reachable by an unprivileged process in the render group. Reject undersized chunks with -EINVAL during pass1 so the bad submission is rejected before pass2 ever dereferences the data. (cherry picked from commit 7f61b2eef7415eccdb40850aca0de94211948657) An unprivileged local attacker can exploit this vulnerability by submitting a specially crafted command with a zero-length chunk size for `CP_GFX_SHADOW`. This leads to improper memory access within the kernel, causing a system crash and a denial of service (DoS). This issue affects AMDGPU command submission.