Red Hat Linux Security Advisories & CVEs
12467 advisories tracked · Red Hat Security Data API · direct feeds checked every minute; rate-limited backstops use a safe source cadence
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 34 official vendor sources and 160+ reviewed platform categories.
Security advisories for your Red Hat release
Pick your distribution release to see every advisory issued for it and its severity mix. Fixes ship as errata — keep the system patched. This is the release's advisory history, not a per-package scan.
Official 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 advisories
Medium [CVE-2026-74362] fix ignored return value of generic_write_sync
In the Linux kernel, the following vulnerability has been resolved: ext2: fix ignored return value of generic_write_sync() Fix ext2_dio_write_iter() to propagate the error returned by generic_write_sync() instead of silently discarding it, which could cause write(2) to return success to userspace on O_SYNC/O_DSYNC files even when the sync failed. The correct pattern, already used in ext2_dax_write_iter() in the same file and in ext4, xfs, f2fs among others, is: if (ret > 0) ret = generic_write_sync(iocb, ret); Found by Linux Verification Center (linuxtesting.org) with SVACE. [JK: Reflect also filemap_write_and_wait() return value] When performing write operations on files opened with O_SYNC or O_DSYNC flags, the system call write(2) could incorrectly report success to a local user even if the data synchronization to disk failed. This could lead to data integrity issues, as applications might assume data is safely written when it is not. A low impact flaw was found in the Linux kernel's ext2 filesystem. The flaw is not network-reachable, does not involve memory corruption or privilege escalation, and requires local write access to an affected ext2 file. Although the assigned Red Hat CVSS 3.1 score is 5.5 (MODERATE), Red Hat assessed the overall impact of this error-handling defect as LOW.
Medium [CVE-2026-74380] Fix iommu_map_sgtable return value check
In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix iommu_map_sgtable() return value check Commit "iommu: return full error code from iommu_map_sg[_atomic]()" changed iommu_map_sgtable() to return an ssize_t and negative values in error cases, rather than a size_t and a zero. pin_job() also was incorrectly assigning to 'int', which could cause overflows into negative values. Update pin_job() to correctly check for errors from iommu_map_sgtable. An incorrect return value check in the `iommu_map_sgtable()` function, coupled with an improper integer assignment in `pin_job()`, could lead to negative value overflows. This vulnerability may result in data integrity issues or system instability within the GPU memory management subsystem. A low impact flaw was found in the Linux kernel host1x GPU driver, affecting the kernel and kernel-rt packages in Red Hat Enterprise Linux 9 and 10 as well as the kernel and kernel-ivos-qualcomm packages in Red Hat In-Vehicle OS 2. A local user with low privileges who can reach the host1x GPU job submission interface could trigger a job whose scatter-gather table fails to map; because the failure is treated as success, job setup can continue with an unmapped IOVA, leading to IOMMU faults or device job failure. Affected products named by the advisory: Red Hat Enterprise Linux 10; Red Hat package: kernel-rt.
Medium [CVE-2026-74414] Remove the duplicate attr inode dirty marking action
In the Linux kernel, the following vulnerability has been resolved: hfsplus: Remove the duplicate attr inode dirty marking action Syzbot reported a null-ptr-deref in [1]. If the attributes file is not loaded during system mount, a trigger occurs [1] when setxattr is executed in userspace. Remove the first mark attr inode dirty operation. [1] KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] Call Trace: hfsplus_setxattr+0x124/0x340 fs/hfsplus/xattr.c:555 hfsplus_trusted_setxattr+0x40/0x60 fs/hfsplus/xattr_trusted.c:30 __vfs_setxattr+0x43c/0x480 fs/xattr.c:218 __vfs_setxattr_noperm+0x12d/0x660 fs/xattr.c:252 vfs_setxattr+0x163/0x360 fs/xattr.c:339 do_setxattr fs/xattr.c:654 [inline] A flaw was found in the Linux kernel's HFS Plus (hfsplus) filesystem. Successful exploitation of this flaw could lead to a system crash, resulting in a Denial of Service (DoS). All Red Hat Enterprise Linux (kernel and kernel-rt) and Red Hat In-Vehicle OS (kernel and kernel-ivos-qualcomm) streams assessed for this flaw are not affected, because the vulnerable code is not present in the shipped Red Hat kernels, so no Red Hat product is exposed to this issue. 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-74276] use FIFO occupancy register to determine buffer size
In the Linux kernel, the following vulnerability has been resolved: spi: xilinx: use FIFO occupancy register to determine buffer size The method the driver uses to determine the size of the FIFO has a problem. What it currently does is this: It stops the SPI hardware and writes to the TX FIFO register until TX FIFO FULL asserts in the status register. But the hardware does not only have the FIFO, it also has a shift register which can hold a byte. This can be seen, when writing a byte to the FIFO (while the SPI hardware is stopped,) the TX FIFO EMPTY is still empty. So, if we have a FIFO size of 16 for example, the current method returns a 17. This is a problem, at least when using the driver in irq mode. The same size determined for the TX FIFO is also assumed for the RX FIFO. But it is empty in our case. So this check spins in a while loop forever locking the driver. This patch fixes the logic to determine the FIFO size. The driver incorrectly determines the size of its internal buffer, a First-In, First-Out (FIFO) queue. This miscalculation can lead to an overflow when the driver attempts to write more data than the FIFO can hold during a Serial Peripheral Interface (SPI) transaction. This causes the driver to lose data and enter an infinite loop, resulting in a denial of service (DoS) for the system.
Medium [CVE-2026-74406] Fix potential null-ptr-deref in vxlan_gro_prepare_receive
In the Linux kernel, the following vulnerability has been resolved: vxlan: Fix potential null-ptr-deref in vxlan_gro_prepare_receive(). udp_tunnel_sock_release() could set sk->sk_user_data to NULL while vxlan_gro_prepare_receive() is running. Let's check if rcu_dereference_sk_user_data() is NULL after skb_gro_remcsum_init(). A flaw was found in the Linux kernel's Virtual Extensible LAN (VXLAN) component. A race condition can occur where the `udp_tunnel_sock_release()` function sets a socket's user data to NULL while the `vxlan_gro_prepare_receive()` function is still actively using it. This could lead to a null pointer dereference, potentially causing a system crash or denial of service. No impact to confidentiality or integrity is expected, and successful exploitation depends on hitting a narrow timing window between socket release and packet reception. Red Hat Enterprise Linux 6, 7, and 8 are not affected because the vulnerable code is not present in those supported streams. The fix for the affected Red Hat Enterprise Linux 9, Red Hat Enterprise Linux 10, and Red Hat In-Vehicle OS 2 releases has been deferred and is planned to be addressed in a future update. Until a fix is delivered, the residual risk is limited to a potential kernel crash (denial of service) if the race condition is triggered. Affected products named by the advisory: Red Hat package: kernel-rt.
Medium [CVE-2026-74334] Fix locking when accessing mr->pd
In the Linux kernel, the following vulnerability has been resolved: RDMA/nldev: Fix locking when accessing mr->pd Sashiko points out that, due to rereg_mr, the PD is actually variable and all the touches in nldev are racy. Use mr->device instead of mr->pd->device. Getting the PD restrack ID is more tricky. To avoid disturbing all the happy paths, add an rdma_restrack_sync() operation which is sort of like flush_workqueue() or synchronize_irq(): after it returns, all the old nldev touches to the mr are gone and everything sees the new PD. This makes it safe to reach into the PD pointer. Improper locking during memory region re-registration (rereg_mr) can lead to a race condition when accessing protection domains (PD). This vulnerability could result in unpredictable system behavior or a denial of service due to concurrent, unsynchronized memory access. A race condition flaw rated Moderate severity was found in the RDMA/nldev component of the Linux kernel as shipped in Red Hat Enterprise Linux and Red Hat In-Vehicle OS. Exploitation requires a local user with access to the RDMA userspace verbs and netlink resource-dump interfaces, and successful triggering depends on precise timing of the race. 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 2 more.
Medium [CVE-2026-74321] fix invalid pointer dereference in __btrfs_run_delayed_refs
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix invalid pointer dereference in __btrfs_run_delayed_refs() In the beginning of the loop, we try to obtain a locked delayed ref head, if 'locked_ref' is currently NULL, by calling btrfs_select_ref_head(), which can return an error pointer. If the error pointer is -EAGAIN we do a continue and go back to the beginning of the loop, which will not try again to call btrfs_select_ref_head() since 'locked_ref' is no longer NULL but it's ERR_PTR(-EAGAIN), and then we do: spin_lock(&locked_ref->lock); against a ERR_PTR(-EAGAIN) value, generating an invalid pointer dereference. Fix this by ensuring that 'locked_ref' is set to NULL when btrfs_select_ref_head() returns ERR_PTR(-EAGAIN) and incrementing 'count' as well, to prevent infinite looping. We do this by doing a goto to the bottom of the loop that already sets 'locked_ref' to NULL and does a cond_resched(), with an increment to 'count' right before the goto. These measures were in place before the refactoring in commit 0110a4c43451 ("btrfs: refactor __btrfs_run_delayed_refs loop") but were unintentionally lost afterwards. A flaw was found in the btrfs file system component of the Linux kernel. This vulnerability occurs in the `__btrfs_run_delayed_refs()` function when an error condition is not properly handled, leading to an invalid pointer dereference.
Medium [CVE-2026-74426] fix NULL pointer dereference in afs_get_tree
In the Linux kernel, the following vulnerability has been resolved: afs: fix NULL pointer dereference in afs_get_tree() afs_alloc_sbi() uses kzalloc for memory allocation. And, if ctx->dyn_root is not null, as->cell and as->volume are null. In trace_afs_get_tree() they are dereferenced. KASAN error message: KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 2 PID: 18478 Comm: syz-executor.7 Not tainted 5.10.246-syzkaller #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:perf_trace_afs_get_tree+0x1d9/0x550 include/trace/events/afs.h:1365 Call Trace: trace_afs_get_tree include/trace/events/afs.h:1365 [inline] afs_get_tree+0x922/0x1350 fs/afs/super.c:599 vfs_get_tree+0x8e/0x300 fs/super.c:1572 do_new_mount fs/namespace.c:3011 [inline] path_mount+0x14a5/0x2220 fs/namespace.c:3341 do_mount fs/namespace.c:3354 [inline] __do_sys_mount fs/namespace.c:3562 [inline] __se_sys_mount fs/namespace.c:3539 [inline] __x64_sys_mount+0x283/0x300 fs/namespace.c:3539 do_syscall_64+0x33/0x50 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1 Found by Linux Verification Center (linuxtesting.org) with Syzkaller. A flaw was found in the Linux kernel's AFS (Andrew File System) component. Affected products named by the advisory: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 9; Red Hat package: kernel-rt.
Medium [CVE-2026-74318] fix deadlock cloning inline extent when using flushoncommit
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix deadlock cloning inline extent when using flushoncommit In commit b48c980b6a7e ("btrfs: fix deadlock between reflink and transaction commit when using flushoncommit") a deadlock was fixed between reflinks and transaction commits when the fs is mounted with the flushoncommit option. This happened when we had to copy an inline extent's data to the destination file. However the issue was fixed only for the case where the destination offset is 0, it missed the case when the offset is greater than zero. Syzbot reported this with the following trace: INFO: task kworker/u8:3:57 blocked for more than 143 seconds. Affected products named by the advisory: Red Hat Enterprise Linux 10; Red Hat package: kernel.
Medium [CVE-2026-74357] fix KASAN slab-out-of-bounds in amdgpu_coredump ring dump
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix KASAN slab-out-of-bounds in amdgpu_coredump ring dump The ring content dump in amdgpu_coredump() uses two separate loops over adev->rings[]: the first counts rings with unsignalled fences to size the allocation, and the second copies ring data into the allocated buffers. Both loops use the same condition to skip rings: atomic_read(&ring->fence_drv.last_seq) == ring->fence_drv.sync_seq Because last_seq is an atomic that is updated concurrently by the fence signalling path, additional rings may appear unsignalled in the second loop that were signalled during the first. When this happens, idx exceeds the allocated ring_count and the store to coredump->rings[idx] writes past the end of the kcalloc-ed buffer. This was found during IGT stressful test amd_queue_reset which triggers random GPU resets. The OVERSIZE subtest (CMD_STREAM_EXEC_INVALID_PACKET_LENGTH_OVERSIZE on GFX ring) provokes a ring timeout and subsequent coredump, which hits the race between the counting and copying loops. The failure is non-deterministic and depends on fence signalling timing during the reset. Affected products named by the advisory: Red Hat Enterprise Linux 6; Red Hat package: kernel.
Medium [CVE-2026-74382] prevent unbounded recursion in offload rollback
In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_bpf: prevent unbounded recursion in offload rollback Quan Sun reported [1] a stack overflow in cls_bpf_offload_cmd(). Reproducer on netdevsim: add a skip_sw cls_bpf filter, set the bpf_tc_accept debugfs knob to 0, then `tc filter replace`. The replace calls tc_setup_cb_replace() which fails. cls_bpf_offload_cmd() then swaps prog/oldprog and recursively calls itself to roll back. But bpf_tc_accept=0 makes the rollback fail too, which triggers yet another rollback frame with the same arguments, and so on until the stack is exhausted. bpf_tc_accept is just a convenient knob for the reproducer. Any driver whose tc_setup_cb_replace() fails twice in a row can hit the same loop, so this is not a netdevsim-only issue. Two ways to fix it: 1) Have the rollback call tc_setup_cb_add() on oldprog instead of re-entering cls_bpf_offload_cmd(). 2) Mark the rollback frame with a flag and skip a second-level rollback from inside it. Go with (2). It is the smaller change and keeps the original behaviour: the rollback still goes through tc_setup_cb_replace(), so the driver gets one real chance to restore its state. If that attempt also fails, we just return the original error instead of recursing. [1]: A flaw was found in the Linux kernel's `cls_bpf` component, which handles traffic control filtering.
Medium [CVE-2026-74399] terminate and bound the evm_xattrs read buffer
In the Linux kernel, the following vulnerability has been resolved: evm: terminate and bound the evm_xattrs read buffer evm_read_xattrs() allocates size + 1 bytes, fills them from the list of enabled xattrs, and then passes strlen(temp) to simple_read_from_buffer(). When no configured xattrs are enabled, the fill loop stores nothing and temp[0] remains uninitialized, so strlen() reads beyond initialized memory. Explicitly terminate the buffer after allocation, use snprintf() for each formatted line, and pass the accumulated length, without risk of truncation, to simple_read_from_buffer(). A flaw was found in the Linux kernel's Extended Verification Module (EVM). The `evm_read_xattrs()` function, when processing extended attributes, fails to properly initialize a buffer. This can lead to an out-of-bounds read when no extended attributes are configured, potentially allowing an attacker to cause a denial of service (DoS) or disclose sensitive information. Red Hat rates this flaw Moderate (CVSS 5.5, AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H); exploitation requires local access. Red Hat Enterprise Linux 8, 9, and 10 (kernel and kernel-rt) and Red Hat In-Vehicle OS 2 are affected. Affected products named by the advisory: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 9; Red Hat package: kernel-rt.
Medium [CVE-2026-74311] tear down old virtqueues before restore
In the Linux kernel, the following vulnerability has been resolved: virtio: rtc: tear down old virtqueues before restore virtio_device_restore() resets the device and restores the negotiated features before calling ->restore(). viortc_freeze() intentionally leaves the existing virtqueues in place so the alarm queue can still wake the system, but viortc_restore() immediately calls viortc_init_vqs() without first deleting those old queues. If virtqueue reinitialization fails on virtio-pci, the transport error path can run vp_del_vqs() against a newly allocated vp_dev->vqs array while vdev->vqs still contains the old virtqueues. vp_del_vqs() then looks up queue state through the new array and can dereference a NULL info pointer in vp_del_vq(), crashing the guest kernel during restore. This can also happen during a non-faulty reinitialization, when one of the vp_find_vqs_msix() attempts is unsuccessful before a later attempt would succeed. Delete the stale virtqueues before rebuilding them. If restore fails before virtio_device_ready(), reuse the remove path to stop the device. Once the device is ready, return errors directly instead of deleting the virtqueues again. During a system restore operation, the virtio real-time clock (RTC) component fails to properly manage virtual queues (virtqueues).
Medium [CVE-2026-74330] fix lockless traversals of ->s_children
In the Linux kernel, the following vulnerability has been resolved: configfs: fix lockless traversals of ->s_children Having the parent directory locked protects entries from removal by another thread, but it does *not* protect cursors from being moved around by lseek() - or freed, for that matter. This vulnerability arises from improper handling of directory traversals, where cursors can be unexpectedly moved or freed by another process even when the parent directory is locked. This lack of proper synchronization can lead to an inconsistent system state, potentially causing system instability or data corruption. A moderate impact flaw was found in the Linux kernel's configfs file system. When a configfs directory is read, the kernel traverses the ->s_children list of directory entries without adequate locking. A local user able to access and operate on a configfs mount could race these operations to corrupt kernel memory, resulting in a system crash or inconsistent system state, which is primarily a denial of service. 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 2 more.
Medium [CVE-2026-74320] Fix buffer errors in OF binding code
In the Linux kernel, the following vulnerability has been resolved: fbdev: sm501fb: Fix buffer errors in OF binding code The code that gets the frame buffer mode from OF has 'use after free', 'buffer overrun' and memory leaks. info->edid_data isn't free if the probe functions fail or if pd->def_mode is set. If both the CRT and PANEL are enabled info->edid_data is used after being freed and is freed twice. The string returned by of_get_property(np, "mode", &len) is just written over either the static "640x480-16@60" or the module parameter string without any regard for the length (which is most likely longer). Use kstrump() for the OF mode and free everything before freeing 'info. The code responsible for obtaining frame buffer mode information from Open Firmware (OF) binding contains multiple memory handling errors. These include use-after-free vulnerabilities, buffer overruns when writing mode strings without proper length checks, and memory leaks. These issues could lead to system instability or potentially allow a local attacker to impact system integrity. Red Hat rates the impact as Moderate (CVSS 3.1 score 5.5, AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H), with availability being the primary consequence.
Medium [CVE-2026-74261] avoid stale FIFO cells during resize
In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: avoid stale FIFO cells during resize snd_seq_fifo_resize() still needs to publish the replacement pool before it waits for FIFO users. A blocking snd_seq_read() holds f->use_lock while it sleeps, so concurrent senders must be able to queue to the new pool and wake that reader instead of failing against a closing old pool. However, snd_seq_fifo_event_in() duplicates an event before it takes f->lock, and snd_seq_read() can dequeue a cell and later call snd_seq_fifo_cell_putback() if copy_to_user() or snd_seq_expand_var_event() fails. If resize swaps f->pool and detaches oldhead in between, either path can relink an old-pool cell after the snapshot. That stale cell sits outside the drained oldhead list, keeps oldpool->counter elevated, and can leave snd_seq_pool_delete() waiting for the retired pool to drain. Keep the existing swap-before-wait ordering in snd_seq_fifo_resize(), but reject stale cells before any FIFO relink. Revalidate event-in cells under f->lock and retry them against the published replacement pool, and free stale putback cells instead of linking them back into the FIFO. The buggy scenario involves two paths, with each column showing the order within that path: resize path: relink path: 1. Allocate newpool. 1. Take f->use_lock. 2. Swap f->pool to newpool and 2.
Medium [CVE-2026-72434] make sure gc is properly stopped
In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: make sure gc is properly stopped Sashiko noticed that when destroying a set, cancel_delayed_work_sync() was called while gc calls queue_delayed_work() unconditionally which can lead not to properly shutting down the gc. This improper shutdown can lead to resource exhaustion, potentially resulting in a Denial of Service (DoS) condition. A flaw was found in the Linux kernel's netfilter ipset subsystem, rated by Red Hat Product Security as having Moderate impact. When an ipset that uses timeout-based garbage collection is destroyed, the garbage collection (gc) delayed work is not reliably stopped: cancel_delayed_work_sync() is called while the gc path can still unconditionally call queue_delayed_work() and re-queue itself, so a later gc run may operate on a set that has already been freed. A local attacker with the privileges required to manage ipsets (for example CAP_NET_ADMIN, which may be delegated to a container root or a network management service rather than full host root) could trigger this race by destroying a set, causing an RCU stall, kernel panic, or other system instability, resulting in a denial of service. Affected products named by the advisory: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 6; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9; and 1 more.
Medium [CVE-2026-72484] avoid double free on video register failure
In the Linux kernel, the following vulnerability has been resolved: staging: most: video: avoid double free on video register failure comp_register_videodev() allocates a video_device with video_device_alloc() and releases it if video_register_device() fails. This can double free the video_device when __video_register_device() reaches device_register() and that call fails: video_register_device() -> __video_register_device() -> device_register() fails -> put_device(&vdev->dev) -> v4l2_device_release() -> vdev->release(vdev) -> video_device_release(vdev) comp_register_videodev() -> video_device_release(mdev->vdev) Use video_device_release_empty() while registering the device so that registration failure paths do not free mdev->vdev through vdev->release(). comp_register_videodev() then releases mdev->vdev exactly once on failure. Restore video_device_release() after successful registration so the registered device keeps its normal lifetime handling. This issue was found by a static analysis tool I am developing. This vulnerability occurs when `comp_register_videodev()` attempts to release a `video_device` that might have already been freed during a failed device registration. A local attacker could exploit this double free vulnerability, potentially leading to memory corruption or a denial of service (DoS).
Medium [CVE-2026-72476] Fix possible use after free
In the Linux kernel, the following vulnerability has been resolved: dmaengine: Fix possible use after free In dma_release_channel(), check chan->device->privatecnt after call dma_chan_put(). However, dma_chan_put() call dma_device_put() which could release the last reference of the device if the DMA provider is already gone and hence free it. This flaw occurs in the `dma_release_channel()` function due to an incorrect order of operations, where a channel's reference count is decremented before verifying if the device is still in use. This can lead to a use-after-free vulnerability, potentially causing system instability or a denial of service. A moderate use-after-free flaw was found in the dmaengine subsystem of the Linux kernel as shipped in Red Hat Enterprise Linux and Red Hat In-Vehicle OS. A local user able to trigger the release of a DMA channel during provider teardown could exploit this use-after-free to crash the kernel, resulting in a denial of service; in the worst case, memory corruption from the use of the freed device object could have broader consequences. Red Hat has rated this flaw as having MODERATE impact (CVSS 5.5, AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H) because exploitation requires local access to the DMA channel release path and the primary practical consequence is a kernel panic.
Medium [CVE-2026-72341] Fix publication race for priv->channel_stats
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix publication race for priv->channel_stats[] mlx5e_channel_stats_alloc() publishes a new entry to priv->channel_stats[] and then increments priv->stats_nch as a publication token, but neither store carries any memory barrier: priv->channel_stats[ix] = kvzalloc_node(...); if (!priv->channel_stats[ix]) return -ENOMEM; priv->stats_nch++; Concurrent readers compute the loop bound from priv->stats_nch and then dereference priv->channel_stats[i] using plain accesses, e.g. for (i = 0; i stats_nch; i++) { struct mlx5e_channel_stats *cs = priv->channel_stats[i];... cs->rq.packets... } On weakly-ordered architectures (ARM, PowerPC, RISC-V) the writes to channel_stats[ix] and stats_nch may become visible to other CPUs out of program order. A reader can observe stats_nch == N while still seeing channel_stats[N-1] == NULL, leading to a NULL pointer dereference in the channel_stats loop. Affected products named by the advisory: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 6; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9; and 1 more.