Red Hat Linux Security Advisories & CVEs
12983 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-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.
Medium [CVE-2026-72480] fix out-of-bounds channel lookup in event handling
In the Linux kernel, the following vulnerability has been resolved: iio: adc: xilinx-ams: fix out-of-bounds channel lookup in event handling ams_event_to_channel() may return a pointer past the end of dev->channels when no matching scan_index is found. This can lead to invalid memory access in ams_handle_event(). Add a bounds check in ams_event_to_channel() and return NULL when no channel is found. Also guard the caller to safely handle this case. A flaw was found in the Linux kernel's Industrial Input/Output (IIO) subsystem, specifically in the Xilinx Analog-to-Digital Converter (ADC) AMS driver. When handling events, the `ams_event_to_channel()` function could attempt to access memory outside of its allocated boundaries if a matching channel is not found. This out-of-bounds access can lead to system instability or a denial of service, making the system unresponsive. Red Hat rates this flaw as Moderate severity (CVSS 3.1 score 5.5, AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H) because exploitation requires a local actor on a system that uses the Xilinx AMS driver and the verified impact is limited to availability. The higher CVE.org score of 7.8 (Important) assumes high confidentiality and integrity impacts that the available evidence does not support.
Medium [CVE-2026-72357] Use proper mm_struct in __in_uprobe_trampoline
In the Linux kernel, the following vulnerability has been resolved: uprobes/x86: Use proper mm_struct in __in_uprobe_trampoline In the unregister path we use __in_uprobe_trampoline check with current->mm for the VMA lookup, which is wrong, because we are in the tracer context, not the traced process. Add mm_struct pointer argument to __in_uprobe_trampoline and changing related callers to pass proper mm_struct pointer. The `__in_uprobe_trampoline` function incorrectly uses the current process's memory management (`current->mm`) for Virtual Memory Area (VMA) lookups during the unregistration process. This improper memory management could lead to unexpected system behavior or stability issues. A MODERATE severity flaw was found in the Linux kernel uprobes subsystem on x86 systems. In the uprobe unregistration path, the __in_uprobe_trampoline() function used current->mm for the VMA lookup even though it runs in the tracer's context rather than in the context of the traced process. Exploiting this flaw requires local access with sufficient privileges to register and unregister uprobes on a traced process.
Medium [CVE-2026-72495] Avoid repeated requests to allocate WC pages
In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Avoid repeated requests to allocate WC pages Applications can request multiple WC pages for the same ucontext. As of now, only 1 WC page per ucontext is supported. Add a lock to avoid concurrent access and a check to fail repeated requests. Also, if the mmap entry insert fails for the WC, free the Doorbell page index mapped for the WC page. This could lead to concurrent access issues and potentially result in a denial of service due to resource exhaustion. A moderate-impact flaw was found in the Linux kernel's RDMA driver for Broadcom NetXtreme-E adapters (bnxt_re). This could cause inconsistent resource accounting and exhaustion of the driver's limited doorbell resources, resulting in a local denial of service. Red Hat rated this flaw Moderate (CVSS 5.5, AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H), significantly lower than the CVE.org critical rating (9.3), because exploitation requires local access to the RDMA device interface and the impact is limited to availability of RDMA resources, with no effect on confidentiality or integrity. Affected products named by the advisory: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 9; Red Hat package: kernel-rt.
Medium [CVE-2026-72345] LAG, Fix off-by-one in single-FDB error rollback
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: LAG, Fix off-by-one in single-FDB error rollback On failure at index i, the reverse cleanup loop in mlx5_lag_create_single_fdb() starts from i, so the failed index itself is rolled back. That can operate on uninitialized state or double-tear-down a rule the add_one path already self-rolled-back. Start the rollback from i - 1 so only successfully-installed entries are undone. A flaw was found in the Linux kernel's mlx5 LAG (Link Aggregation Group) driver. An off-by-one error in the `mlx5_lag_create_single_fdb()` function's error rollback mechanism can lead to operations on uninitialized memory or a double-free condition. This could result in system instability or a denial of service. An off-by-one error in the error rollback path of mlx5_lag_create_single_fdb() causes the reverse cleanup loop, entered when single-FDB rule creation fails, to start at the failed index itself instead of the last successfully installed entry. Red Hat rated this flaw Moderate severity (CVSS 5.5, AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H) because triggering the vulnerable error path requires local privileged access and mlx5 LAG configuration on systems using mlx5-based network adapters, and only availability is impacted.
Medium [CVE-2026-72453] Do not overwrite error code when finalizing cache after error
In the Linux kernel, the following vulnerability has been resolved: regcache: Do not overwrite error code when finalizing cache after error During regcache initialization, if an error occurs in the cache_ops->populate callback, and if cache operations include an exit callback, the error code from populate() is overwritten with the return value from exit(). This hides the error condition from the caller of regcache_init(), and can cause NULL pointer dereferences when the regcache is later accessed. This masks the original error, potentially causing the system to attempt operations on uninitialized memory. Such actions can result in NULL pointer dereferences, leading to system instability or a denial of service. A flaw was found in the Linux kernel's regcache (register map cache) mechanism. Triggering this flaw requires local access and depends on a specific regmap-based driver and cache configuration in which the populate callback fails; there is no impact on confidentiality or integrity. The vulnerable code, introduced when the ->populate() callback was added to regcache, is present only in Red Hat Enterprise Linux 9.9, Red Hat Enterprise Linux 10.3, and Red Hat In-Vehicle OS 2 streams (kernel and kernel-ivos-qualcomm components). Affected products named by the advisory: Red Hat package: kernel-rt.
Medium [CVE-2026-72475] Properly free struct axi_dmac_desc
In the Linux kernel, the following vulnerability has been resolved: dmaengine: dma-axi-dmac: Properly free struct axi_dmac_desc Use axi_dmac_free_desc() to free fully the descriptor at fail path when call axi_dmac_alloc_desc() in axi_dmac_prep_peripheral_dma_vec(). This vulnerability arises from the improper freeing of a data structure within the axi_dmac_prep_peripheral_dma_vec() function. This oversight could lead to memory corruption, potentially causing system instability or a denial of service. 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-1341. 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 as not affected.
Medium [CVE-2026-72384] Fix missing chained handler cleanup on remove
In the Linux kernel, the following vulnerability has been resolved: irqchip/ts4800: Fix missing chained handler cleanup on remove The driver installs a chained handler for the parent interrupt during probe using irq_set_chained_handler_and_data(), but the remove function does not clear this handler. This leaves a dangling handler that may be called when the parent interrupt fires after the driver has been removed, potentially accessing freed memory and causing a kernel crash. Additionally, the parent_irq obtained via irq_of_parse_and_map() is not stored, making it inaccessible in the remove function. Moreover, interrupt mappings created during probe are not properly disposed. Fix this by: - Saving parent_irq in probe - Clearing the chained handler with NULL in ts4800_ic_remove() - Disposing all IRQ mappings before domain removal to prevent resource leaks Such an event could lead to the system attempting to access freed memory, resulting in a kernel crash and 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-825. 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 as not affected.
Medium [CVE-2026-72348] mark malformed IPv6 extension headers for hotdrop
In the Linux kernel, the following vulnerability has been resolved: netfilter: ip6tables: mark malformed IPv6 extension headers for hotdrop The ah, hbh and rt matches check that the fixed extension header is present, then use the header length field to derive the advertised extension header length for matching. In all three cases, set hotdrop to true before returning false when the advertised extension header length exceeds the available skb data. Returning false treats the packet as a rule mismatch. Set hotdrop to true and drop malformed packets so they cannot bypass rules intended to drop packets with these IPv6 extension headers. A flaw was found in the Linux kernel's netfilter subsystem, specifically within ip6tables. A remote attacker could send specially crafted IPv6 packets with malformed extension headers. Due to improper length checks, these malformed packets might not be correctly identified and dropped by ip6tables rules. This could allow an attacker to bypass intended security filtering policies. When a malformed IPv6 packet advertises an extension-header length larger than the data actually available in the skb, the affected match functions can return `false` without setting `hotdrop`. 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 1 more.