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-72353] avoid stale runlist element dereference in fallocate
In the Linux kernel, the following vulnerability has been resolved: ntfs: avoid stale runlist element dereference in fallocate ntfs_attr_fallocate() allocates holes and delayed allocations inside initialized size by looking up the current runlist element under ni->runlist.lock. The returned struct runlist_element is only a borrowed pointer into ni->runlist.rl. A writer can replace and free that array after the read lock is dropped, so later reads of rl->lcn, rl->length and rl->vcn can touch freed memory. The buggy scenario involves two paths, with each column showing the order within that path: ntfs_attr_fallocate(): 1. Take ni->runlist.lock for read. 2. Get rl from ntfs_attr_find_vcn_nolock(). 3. 4. Enter ntfs_filemap_page_mkwrite(). Reach __ntfs_write_iomap_begin() and ntfs_attr_map_cluster(). Merge allocation state with ntfs_runlists_merge(). Reallocate ni->runlist.rl in ntfs_rl_realloc(), freeing the old array. Validation reproduced this kernel report: BUG: KASAN: slab-use-after-free in ntfs_attr_fallocate+0xbb8/0xd00 Call Trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630? ntfs_attr_fallocate+0xbb8/0xd00? srso_alias_return_thunk+0x5/0xfbef5? __virt_addr_valid+0x20d/0x410? ntfs_attr_fallocate+0xbb8/0xd00 kasan_report+0xe0/0x110? ntfs_attr_fallocate+0xbb8/0xd00 ntfs_attr_fallocate+0xbb8/0xd00? lock_acquire+0x2b8/0x2f0? __pfx_ntfs_attr_fallocate+0x10/0x10?
Medium [CVE-2026-72412] Fix handling of _PAGE_UNUSED pte bit
In the Linux kernel, the following vulnerability has been resolved: s390/mm: Fix handling of _PAGE_UNUSED pte bit The _PAGE_UNUSED softbit should not really be lying around. Its sole purpose is to signal to try_to_unmap_one() and try_to_migrate_one() that the page can be discarded instead of being moved / swapped. KVM has no way to know why a page is being unmapped, so it sets the bit on userspace ptes corresponding to unused guest pages every time they get unmapped. While set_ptes() checks and clears the bit, other paths that set new ptes did not. This led to used pages being thrown out as if they were unused, causing guest corruption. Fix the issue by clearing the _PAGE_UNUSED bit for present ptes in set_pte(), i.e. whenever a present pte is getting set. The check in set_ptes() is then redundant and can be removed. A flaw was found in the Linux kernel's memory management for s390 systems. An internal flag, intended to mark guest memory pages for discard after unmapping by the Kernel-based Virtual Machine (KVM), was not consistently cleared when those pages were subsequently reused. This improper handling could cause actively used guest memory to be prematurely discarded. The most significant consequence is data corruption within guest virtual machines. 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-911.
Medium [CVE-2026-72354] avoid stale runlist element dereference in MFT writeback
In the Linux kernel, the following vulnerability has been resolved: ntfs: avoid stale runlist element dereference in MFT writeback ntfs_write_mft_block() maps each $MFT record through the $MFT data runlist. For sub-folio clusters it looks up a struct runlist_element under ni->runlist.lock, drops the lock, and later uses rl->length and rl->vcn when choosing folio_sz. That pointer is only borrowed from ni->runlist.rl. Concurrent $MFT allocation extension can merge a replacement runlist under the same lock, and ntfs_rl_realloc() can free the old backing array. If that happens between the lookup and the later folio_sz decision, writeback can dereference freed runlist storage. The buggy scenario involves two paths, with each column showing the order within that path: MFT writeback path: $MFT allocation extension: 1. Look up rl under 1. 2. 3. Compute the remaining run length while ni->runlist.lock is still held, and use that scalar after unlock. This preserves the existing folio sizing decision without carrying a borrowed runlist_element across the lock boundary.
Medium [CVE-2026-72496] Proper rollback if the ioremap fails
In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Proper rollback if the ioremap fails bnxt_qplib_alloc_dpi returns success even if ioremap fails. Add the proper rollback when the ioremap fails and return -ENOMEM status. When the `bnxt_qplib_alloc_dpi` function attempts to map I/O memory (`ioremap`), it may not properly handle failures. This oversight could lead to system instability or a denial of service (DoS) condition, as the system might proceed with an invalid memory state. 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-252. Affected Red Hat products: Red Hat Enterprise Linux 10; 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-74263] check skb_clone in control TX
In the Linux kernel, the following vulnerability has been resolved: net: wwan: t7xx: check skb_clone in control TX t7xx_port_ctrl_tx() clones each skb fragment before passing it to the port transmit path. The clone is used immediately to set cloned->len, so an skb_clone() failure results in a NULL pointer dereference. If previous fragments were already queued, preserve the driver's existing partial-write behavior by returning the number of bytes submitted so far. A flaw was found in the Linux kernel's Wireless Wide Area Network (WWAN) t7xx driver. The `t7xx_port_ctrl_tx()` function, which handles control transmissions, fails to validate the return value of `skb_clone()`. An attacker with local access could exploit this by triggering a scenario where `skb_clone()` returns a NULL pointer, leading to a NULL pointer dereference. This vulnerability can cause a system crash, resulting in a Denial of Service (DoS). 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. 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-74257] Fix use-after-free in udp_bpf_recvmsg
In the Linux kernel, the following vulnerability has been resolved: sockmap: Fix use-after-free in udp_bpf_recvmsg() syzbot reported use-after-free of struct sk_msg in sk_msg_recvmsg(). [0] sk_msg_recvmsg() peeks sk_msg from psock->ingress_msg under a lock, but its processing is lockless. Thus, sk_msg_recvmsg() must be serialised by callers, otherwise multiple threads could touch the same sk_msg. For example, TCP uses lock_sock(), and AF_UNIX uses unix_sk(sk)->iolock. Initially, udp_bpf_recvmsg() had used lock_sock(), but the cited commit removed it. Let's serialise sk_msg_recvmsg() with lock_sock() in udp_bpf_recvmsg(). Affected products named by the advisory: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9; Red Hat package: kernel-rt.
Medium [CVE-2026-72498] Avoid displaying the kernel pointer
In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Avoid displaying the kernel pointer While dumping the info on MR using the rdma tool, we dump the mr_hwq which is a kernel pointer. There is no need to expose this value for end user. This vulnerability occurs when a user dumps information about a Memory Region (MR) using the `rdma` tool, inadvertently exposing a kernel pointer. The exposure of this pointer, `mr_hwq`, could provide an attacker with sensitive details about the system's memory layout. Such information might be used to facilitate more advanced attacks. 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-497. Affected Red Hat products: Red Hat Enterprise Linux 10; 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-74255] fix UAF in tipc_l2_send_msg
In the Linux kernel, the following vulnerability has been resolved: tipc: fix UAF in tipc_l2_send_msg() Syzbot reported a slab-use-after-free in ipvlan_hard_header() when called from tipc_l2_send_msg(). The root cause is that tipc_disable_l2_media() calls synchronize_net() while b->media_ptr is still valid. This allows concurrent RCU readers to obtain the device pointer after synchronize_net() has finished. The pointer is cleared later in bearer_disable(), but without any subsequent synchronization, allowing the device to be freed while still in use by readers. Fix this by clearing b->media_ptr in tipc_disable_l2_media() before calling synchronize_net(). This is safe to do now because the call order in bearer_disable() was reversed in 0d051bf93c06 ("tipc: make bearer packet filtering generic") to call tipc_node_delete_links() (which needs the pointer) before disable_media(). https: //lore.kernel.org/netdev/[email protected]/T/#u A flaw was found in the Linux kernel's Transparent Inter-Process Communication (TIPC) module. This use-after-free vulnerability occurs when the `tipc_disable_l2_media()` function calls `synchronize_net()` before properly invalidating a media pointer. This timing issue allows concurrent readers to access a memory region after it has been freed, which can lead to system instability or a denial of service.
Medium [CVE-2026-72497] Add a max slot check for SQ
In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Add a max slot check for SQ The variable WQE mode must be validated against the maximum slots supported by HW. Adding a max and min check and fail if user supplied value is more than the max supported and zero. This vulnerability arises from insufficient validation of the Work Queue Entry (WQE) mode, which dictates how tasks are managed, against the hardware's defined slot limits. A local attacker could exploit this by supplying an invalid WQE mode value, potentially causing unexpected system behavior or a denial of service (DoS). 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-805. Affected Red Hat products: Red Hat Enterprise Linux 10; 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-74260] add nf_dev_xmit_recursion* helpers and use them
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_dup_netdev: add nf_dev_xmit_recursion*() helpers and use them Update nft_dup and nft_fwd to use the nf_dev_xmit_recursion() helpers. This patch also disables BH when transmitting the skb to address a possible migration to different CPU leading to imbalanced decrementation of the recursion counters. This is modeled after Florian Westphal's dev_xmit_recursion*() API available since commit 97cdcf37b57e ("net: place xmit recursion in softnet data") according to its current state in the tree. A flaw was found in the Linux kernel's netfilter component, specifically within the nf_dup_netdev module. This vulnerability arises from an imbalanced decrementation of recursion counters when network packets are transmitted, particularly during a possible migration to a different CPU. This improper handling of recursion counters could lead to system instability or 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-821. 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-74265] initialize gdma queue id to INVALID_QUEUE_ID
In the Linux kernel, the following vulnerability has been resolved: net: mana: initialize gdma queue id to INVALID_QUEUE_ID mana_gd_create_mana_wq_cq() leaves queue->id as 0 (from kzalloc_obj()) until mana_create_wq_obj() assigns the firmware-returned id. If creation fails before that, cleanup calls mana_gd_destroy_cq() with id 0, NULLing gc->cq_table[0] and silently breaking whichever real CQ owns that slot. Initialize queue->id to INVALID_QUEUE_ID right after allocation, matching mana_gd_create_eq(). The existing (id >= max_num_cqs) guard then short-circuits cleanly. A flaw was found in the `mana` network driver of the Linux kernel. When creating a General DMA (GDMA) queue, the `queue->id` may not be properly initialized. If the queue creation fails before a valid ID is assigned, a subsequent cleanup operation can incorrectly use a zero ID, potentially corrupting the Completion Queue (CQ) table. This could lead to system instability or a denial of service. 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-908. 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-74264] fix refcount tracking races
In the Linux kernel, the following vulnerability has been resolved: net: watchdog: fix refcount tracking races Blamed commit converted the untracked dev_hold()/dev_put() calls in the watchdog code to use the tracked dev_hold_track()/dev_put_track() (which were later renamed/interfaced to netdev_hold() and netdev_put()). By introducing dev->watchdog_dev_tracker to store the reference tracking information without adding synchronization between netdev_watchdog_up() and dev_watchdog(), it enabled the race condition where this pointer could be overwritten or freed concurrently, leading to the list corruption crash syzbot reported: list_del corruption, ffff888114a18c00->next is NULL kernel BUG at lib/list_debug.c:52! Affected products named by the advisory: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 6; Red Hat Enterprise Linux 9; Red Hat package: kernel-rt.
Medium [CVE-2026-74416] fix memory leak in radeon_ring_restore on lock failure
In the Linux kernel, the following vulnerability has been resolved: drm/radeon: fix memory leak in radeon_ring_restore() on lock failure radeon_ring_restore() takes ownership of the data buffer allocated by radeon_ring_backup(). The caller (radeon_gpu_reset()) only frees it in the non-restore branch; in the restore branch it relies on radeon_ring_restore() to free it. If radeon_ring_lock() fails, the function returned early without calling kvfree(data), leaking the ring backup buffer on every GPU reset that fails at the lock stage. During repeated GPU resets this causes cumulative kernel memory exhaustion. Free data before returning the error. When a Graphics Processing Unit (GPU) reset operation fails to acquire a necessary lock, a memory buffer is not properly released. Repeated occurrences of this issue can lead to a gradual depletion of kernel memory. This memory exhaustion can ultimately result in a system crash or denial of service. A flaw was found in the Linux kernel's drm/radeon driver, with low security impact for Red Hat products. 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-74337] Fix NMI/tracepoint re-entry deadlock on lru locks
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix NMI/tracepoint re-entry deadlock on lru locks NMI and tracepoint BPF programs can re-enter the per-CPU or global LRU lock that bpf_lru_pop_free()/push_free() already hold on the same CPU, AA-deadlocking. Lockdep reports "inconsistent {INITIAL USE} -> {IN-NMI}" on &l->lock (syzbot c69a0a2c816716f1e0d5) and "possible recursive locking detected" on &loc_l->lock (syzbot 18b26edb69b2e19f3b33). Prior trylock and rqspinlock based fixes (see links) were nacked because compromised on reliability. This patch converts every LRU lock site to rqspinlock_t and adds a recovery path for some failure windows to avoid node leaks. Failure recovery: - *_pop_free top-level: return NULL; prealloc_lru_pop() already treats that as no-free-element (-ENOMEM). - Cross-CPU steal: skip the victim's locked loc_l, try next CPU. - Post-steal local lock fail: publish stolen node to lockless per-CPU free_llist; next pop on this CPU picks it up. - push_free fail: mark node pending_free=1. __local_list_flush(), __local_list_pop_pending() reclaim the node from pending_list. __bpf_lru_list_shrink_inactive() reclaims the node from inactive list. Nodes from active list are reclaimed by __bpf_lru_list_shrink() or after __bpf_lru_list_rotate_active() demotes it to the inactive.
Medium [CVE-2026-74258] Guard __get_user acesss with access_ok for uprobe_multi data
In the Linux kernel, the following vulnerability has been resolved: bpf: Guard __get_user acesss with access_ok for uprobe_multi data As reported by sashiko [1] we need to use access_ok to check the user space data bounds before we use __get-user to get it. [1] A flaw was found in the Linux kernel's BPF (Berkeley Packet Filter) subsystem. A missing bounds check when accessing user space data for `uprobe_multi` could allow a local attacker to read or write to memory outside of intended boundaries. This vulnerability can lead to information disclosure or potentially privilege escalation. When attaching a uprobe_multi (multi-uprobe) BPF link, the kernel read the user-supplied offset, reference-counter-offset, and cookie arrays with __get_user without first validating that the supplied user-space address ranges were valid, because the required access_ok bounds check was missing. Red Hat Product Security has rated this flaw Moderate (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 an already-privileged BPF tracing interface rather than a network-reachable path; this differs from the upstream CVE rating of Important (CVSS 7.8), which assumes broader confidentiality, integrity, and availability impact. Affected products named by the advisory: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 9; Red Hat package: kernel-rt.
Medium [CVE-2026-74360] Reject exclusive maps for bpf_map_elem iterators
In the Linux kernel, the following vulnerability has been resolved: bpf: Reject exclusive maps for bpf_map_elem iterators Exclusive maps (aka excl_prog_hash) are meant to be reachable only from the single program whose hash matches. This is enforced by check_map_prog_compatibility() when the map is referenced from a program such as signed BPF loaders. A bpf_map_elem iterator, however, binds its target map at attach time in bpf_iter_attach_map() instead of referencing it from the program, so the exclusivity check is never reached. On top of that, the iterator exposes the map value as a writable buffer. A flaw was found in the Linux kernel's Berkeley Packet Filter (BPF) subsystem. The `bpf_map_elem` iterator does not properly enforce exclusivity checks for certain maps, allowing it to bind to an exclusive map. A local attacker could leverage this to perform unauthorized modifications to data within these exclusive maps, potentially leading to privilege escalation or information disclosure. A local attacker with the ability to load BPF programs and attach BPF iterators could exploit this to make unauthorized modifications to data in exclusive maps, potentially disrupting the kernel components that rely on them (Red Hat CVSS 5.5, AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).
Medium [CVE-2026-74402] atmel-sha204a - fix blocking and non-blocking rng logic
In the Linux kernel, the following vulnerability has been resolved: crypto: atmel-sha204a - fix blocking and non-blocking rng logic The blocking and non-blocking paths were failing to provide valid entropy due to improper buffer management. Reading the buffer starting from byte 1, only fetch the 32 bytes of random data from the return message. Tested on an Atmel SHA204A device. Before (here for blocking), tests showed repeatedly reading reduced bytes. $ head -c 32 /dev/hwrng | hexdump -C 00000000 02 28 85 b3 47 40 f2 ee 00 00 00 00 00 00 00 00 |.(..G@..........| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000020 After, the result will be similar to the following: $ head -c 32 /dev/hwrng | hexdump -C 00000000 5a fc 3f 13 14 68 fe 06 68 0a bd 04 83 6e 09 69 |Z.?..h..h....n.i| 00000010 75 ff cf 87 10 84 3b c9 c1 df ae eb 45 53 4c c3 |u.....;.....ESL.| 00000020 A flaw was found in the Linux kernel's `atmel-sha204a` cryptographic hardware random number generator (HWRNG) driver. Consequently, cryptographic operations relying on this hardware random number generator may be weakened due to insufficient randomness. The issue is limited to kernels containing the atmel-sha204a driver used with the corresponding Atmel hardware.
Medium [CVE-2026-74376] reset read_slot when reusing r10bio for discard
In the Linux kernel, the following vulnerability has been resolved: md/raid10: reset read_slot when reusing r10bio for discard put_all_bios() always drops devs[i].bio, but it only drops devs[i].repl_bio when r10_bio->read_slot < 0. If discard reuses an r10bio that was previously used for a read, read_slot can still be non-negative, and discard cleanup can skip bio_put() on repl_bio. This vulnerability occurs when a specific internal data structure, used for disk operations, is reused for a discard operation without properly resetting a critical flag. This oversight can lead to improper release of system resources, potentially causing system instability or a denial of service (DoS). A flaw of low impact was found in the Linux kernel's md/raid10 driver in Red Hat Enterprise Linux 8, 9, and 10 and Red Hat In-Vehicle OS 2. Repeated discard operations on an md/raid10 array can therefore leak bios and associated memory, resulting in resource exhaustion and a local denial of service. Triggering the flaw requires local access to a system performing discard operations on an md/raid10 array; there is no impact on confidentiality or integrity and the flaw is not network-reachable. The vulnerable code is not present in Red Hat Enterprise Linux 7 Extended Lifecycle Support (kernel and kernel-rt), which is therefore not affected.
Medium [CVE-2026-74355] Fix RB-tree corruption in probe error path
In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix RB-tree corruption in probe error path The info->node RB-tree member is zero-initialized via kzalloc. If a device does not support ATS, the device_rbtree_insert() call is skipped. If a subsequent probe step fails, the error path jumps to device_rbtree_remove(), which misinterprets the zeroed node as a tree root and corrupts the device RB-tree. Fix this by explicitly initializing the RB-node as empty using RB_CLEAR_NODE() during initialization and guarding the removal with RB_EMPTY_NODE(). This misinterpretation leads to corruption of the device RB-tree, which can result in system instability or a denial of service. A moderate severity flaw was found in the Linux kernel's Intel VT-d IOMMU driver (iommu/vt-d). Red Hat rated this flaw Moderate (CVSS 3.1 score 5.5, AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H), which is lower than the upstream CVE.org Important rating of 8.2, because the issue is local, requires privileges, and primarily affects system availability rather than 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-74281] reject inverted service ranges from peer bindings
In the Linux kernel, the following vulnerability has been resolved: tipc: reject inverted service ranges from peer bindings tipc_update_nametbl() inserts a binding advertised by a peer node using the lower and upper service-range bounds taken directly from the wire, without checking that lower upper is inserted at the far end of the service-range rbtree (keyed on lower) where no lookup or withdrawal can ever match it (service_range_foreach_match() requires sr->lower upper. A flaw was found in the Linux kernel's Transparent Inter-Process Communication (TIPC) module. A remote attacker, acting as a peer node, could exploit this by sending specially crafted PUBLICATION messages with inverted service ranges. This oversight in validating service range bounds allows the attacker to cause unbounded memory leaks in the binding table, leading to a denial of service (DoS) for the affected system. Repeated malicious publications could therefore exhaust kernel memory and cause a denial of service. Red Hat Enterprise Linux 6 and 7 are not affected because the vulnerable code is not present in those kernels. For the affected Red Hat Enterprise Linux and Red Hat In-Vehicle OS kernel streams, the fix is currently deferred given the Moderate impact rating and the fact that exploitatio…