Red Hat Linux Security Advisories & CVEs
12893 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-72454] Fix race in i3c_hci_addr_to_dev
In the Linux kernel, the following vulnerability has been resolved: i3c: mipi-i3c-hci: Fix race in i3c_hci_addr_to_dev() i3c_hci_addr_to_dev() walks bus->devs.i3c, which is protected by bus.lock (rwsem). However, it is invoked from the MIPI I3C HCI IRQ handler, which cannot take bus.lock. This allows concurrent device addition/removal in the I3C core to modify the list while it is being traversed, potentially leading to use-after-free or crashes. Remove the dependency on the bus device list and introduce a dedicated lookup table. Add an ibi_devs[] array indexed by DAT entry, maintained under hci->lock. Update the array when IBIs are enabled or disabled, so that it always reflects the set of devices allowed to generate IBIs. Also update when IBIs are freed, to cover the corner case when an IBI is freed without first being disabled (e.g. oldedev in i3c_master_add_i3c_dev_locked()). Move i3c_hci_addr_to_dev() into core.c, reimplement it using the new array, and add a lockdep assertion to enforce that hci->lock is held by callers. Demote a message in PIO and DMA IBI handling, from an error to a debug message, because there is a race window when the condition can arise normally. A flaw was found in the Linux kernel's MIPI I3C Host Controller Interface (HCI) driver. Affected products named by the advisory: Red Hat Enterprise Linux 10; Red Hat package: kernel.
Medium [CVE-2026-72025] Reject buffer reuse with different data length
In the Linux kernel, the following vulnerability has been resolved: s390/monwriter: Reject buffer reuse with different data length When data buffers are reused, e.g. for interval sample records, the first record determines the data length, and the size of the buffer for user copy. Current monwriter code does not check if the data length was changed for subsequent records, which also would never happen for valid user programs. However, a malicious user could change the data length, resulting in out of bounds user copy to the kernel buffer, and memory corruption. By default, the monwriter misc device is created with root-only permissions, so practical impact is typically low. Fix this by checking for changed data length and rejecting such records. This vulnerability allows a malicious local user with elevated privileges to cause memory corruption. By changing the data length during buffer reuse, the `monwriter` code fails to validate the new length, leading to an out-of-bounds write to the kernel buffer. While the `monwriter` device typically requires root permissions, successful exploitation could lead to system instability or further compromise. 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 9.
Medium [CVE-2026-72396] Prevent reading uninitialized stack
In the Linux kernel, the following vulnerability has been resolved: hwmon: adm1275: Prevent reading uninitialized stack While adding support for the ROHM BD127X0 hot-swap controllers, sashiko reported an error in device-name comparison, which can lead to reading uninitialized stack memory. Quoting Sashiko: This is a pre-existing issue, but I noticed that just before this block in adm1275_probe(), there might be an out-of-bounds stack read: ret = i2c_smbus_read_block_data(client, PMBUS_MFR_MODEL, block_buffer); if (ret name[0]; mid++) { if (!strncasecmp(mid->name, block_buffer, strlen(mid->name))) break; } Since i2c_smbus_read_block_data() reads up to 32 bytes into the uninitialized stack array block_buffer without appending a null terminator, strncasecmp() could read past the valid bytes returned in ret. For example, if the device returns a shorter string like "adm12", checking it against "adm1275" up to the length of "adm1275" will continue reading into uninitialized stack bounds. A flaw was found in the Linux kernel's hwmon subsystem, specifically in the adm1275 driver. This vulnerability allows a local attacker or a specially crafted device to trigger an out-of-bounds read during device name comparison. By providing a device name shorter than expected, uninitialized stack memory can be accessed, potentially leading to the disclosure of sensitive information.
Medium [CVE-2026-72305] avoid leaking information to userspace
In the Linux kernel, the following vulnerability has been resolved: VDUSE: avoid leaking information to userspace The bounceing is not necessarily page aligned, so current VDUSE can leak kernel information through mapping bounce pages to userspace. This vulnerability allows a local user to disclose sensitive kernel information. By mapping non-page-aligned bounce pages to userspace, an attacker can access kernel memory that should not be exposed, leading to an information disclosure. Red Hat severity: Moderate — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-908. Affected Red Hat products: Red Hat Enterprise Linux 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-72309] Fix leak in trace_remote_alloc_buffer error path
In the Linux kernel, the following vulnerability has been resolved: tracing/remotes: Fix leak in trace_remote_alloc_buffer() error path If page allocation fails in trace_remote_alloc_buffer(), desc->nr_cpus is not yet incremented for the current CPU. As a consequence, on error, half-allocated rb_desc will not be freed in trace_remote_free_buffer(). Due to an unincremented CPU counter, a partially allocated buffer descriptor (rb_desc) is not properly freed, leading to a memory leak. Over time, this memory leak could potentially lead to a Denial of Service (DoS) condition. A Moderate severity memory leak flaw was found in the Linux kernel tracing/remotes subsystem (kernel/trace/trace_remote.c). Red Hat scored this flaw as Moderate (CVSS 3.1: 5.5, AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). The vulnerable code was introduced in upstream Linux 7.1 and is not present in the kernels shipped by Red Hat: all Red Hat Enterprise Linux kernel and kernel-rt streams and all Red Hat In-Vehicle OS kernels are therefore not affected (vulnerable code not present), and no update is required for Red Hat products. Weakness: CWE-911.
Medium [CVE-2026-72470] resize log->one_page_buf when adopting on-disk page size
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: resize log->one_page_buf when adopting on-disk page size log_replay() allocates log->one_page_buf using the page size that was chosen from the host PAGE_SIZE: log->one_page_buf = kmalloc(log->page_size, GFP_NOFS); Later, when a restart area is found, the log page size recorded on disk is adopted: t32 = le32_to_cpu(log->rst_info.r_page->sys_page_size); if (log->page_size!= t32) { log->l_size = log->orig_file_size; log->page_size = norm_file_page(t32, &log->l_size, t32 == DefaultLogPageSize); } If the on-disk page size is larger than the size used for the initial allocation, log->page_size grows but one_page_buf is left at its original, smaller size. A subsequent unaligned read_log_page() then reads log->page_size bytes into the undersized scratch buffer: page_buf = page_off? log->one_page_buf: *buffer; err = ntfs_read_run_nb_ra(ni->mi.sbi, &ni->file.run, page_vbo, page_buf, log->page_size, NULL, &log->read_ahead); overflowing the allocation. This is reachable when mounting a dirty NTFS volume whose log was formatted with a page size larger than the buffer initially allocated on the mounting host (for example a 64K-log volume mounted on a host that allocated a 4K scratch buffer). On krealloc() failure the original buffer is left intact and freed by the existing error path.
Medium [CVE-2026-72011] Add missing array_index_nospec call to memtop_get_page_count
In the Linux kernel, the following vulnerability has been resolved: s390/diag: Add missing array_index_nospec() call to memtop_get_page_count() 'level' is user space controlled and used to read from an array. A local user could exploit a missing bounds check when handling a user-controlled 'level' variable, which is used to read from an array. This vulnerability could lead to information disclosure through speculative execution, potentially allowing an attacker to access sensitive data. A flaw of low impact was found in the Linux kernel's s390/diag310 memory topology handling (arch/s390/kernel/diag/diag310.c), used on the s390x (IBM zSystems) architecture. In memtop_get_page_count(), a user-space controlled 'level' value is used as an index into an array; although the value is architecturally bounds checked, the missing array_index_nospec() call allows speculative out-of-bounds reads. A local, unprivileged attacker could use this to establish a Spectre v1 style side channel and potentially disclose sensitive kernel memory contents. Red Hat rates the impact of this flaw as Low because it is not network reachable, requires the ability to run code locally, and provides only a limited and hard-to-exploit speculative disclosure primitive with no expected integrity or availability impact.
Medium [CVE-2026-72490] fix stainfo check in rtw_aes_decrypt
In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix stainfo check in rtw_aes_decrypt The null-pointer-guard was incorrect, returning _FAIL on valid pointer. Invert the guard, so it returns _FAIL on invalid pointer. An incorrect null-pointer guard in the `rtw_aes_decrypt` function could lead to the system misinterpreting memory addresses. This issue may result in a system crash, causing a Denial of Service (DoS). A moderate-impact flaw was found in the Linux kernel's rtl8723bs Wi-Fi driver, in the rtw_aes_decrypt function in drivers/staging/rtl8723bs/core/rtw_security.c. The null-pointer guard for the station-information pointer was inverted, returning a failure code for a valid pointer while continuing to process an invalid one. This could cause the system to misinterpret memory addresses and crash, resulting in a denial of service. Red Hat rates this flaw as Moderate severity with a CVSS 3.1 score of 5.5 (AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H), reflecting a local attack vector that requires privileges and impact limited to availability.
Medium [CVE-2026-72189] fail attrlist updates when the superblock is inactive
In the Linux kernel, the following vulnerability has been resolved: ntfs: fail attrlist updates when the superblock is inactive generic_shutdown_super() clears SB_ACTIVE before evicting cached inodes. If eviction selects the fake inode for a base inode's unnamed $ATTRIBUTE_LIST attribute, ntfs_evict_big_inode() drops the fake inode's reference on the base inode while the fake inode is still hashed and marked I_FREEING. That iput can synchronously write back the base inode. The writeback path may update mapping pairs and call ntfs_attrlist_update(), which unconditionally calls ntfs_attr_iget() for the same $ATTRIBUTE_LIST fake inode. VFS then finds the I_FREEING inode and waits for eviction to finish, but the current task is still inside that eviction path, causing a self-deadlock in find_inode(). Fix this by mirroring the teardown guard used by __ntfs_write_inode(): once SB_ACTIVE has been cleared, do not try to iget the attribute-list fake inode. Return -EIO so teardown aborts the update instead of waiting on the inode it is evicting. A flaw was found in the Linux kernel's NTFS file system. During the process of shutting down a file system, a specific internal condition can arise where the system attempts to update an attribute list while an associated inode is being evicted.
Medium [CVE-2026-72068] Use u64 multiplication in update_rlimit_cpu
In the Linux kernel, the following vulnerability has been resolved: posix-cpu-timers: Use u64 multiplication in update_rlimit_cpu() update_rlimit_cpu() converts the RLIMIT_CPU value to nanoseconds with u64 nsecs = rlim_new * NSEC_PER_SEC; On 32-bit kernels both rlim_new (unsigned long) and NSEC_PER_SEC (1000000000L) are 32-bit, so the multiplication is performed in unsigned long and truncated for rlim_new > 4 seconds before being widened to u64. The same file already casts to u64 for the matching computation in check_process_timers(): u64 softns = (u64)soft * NSEC_PER_SEC; As a result, the truncated value is installed into the CPUCLOCK_PROF expiry cache (nextevt), causing the process CPU timer to be programmed to fire prematurely for any RLIMIT_CPU soft limit >= 5 seconds. The actual SIGXCPU/SIGKILL decision in check_process_timers() already casts to u64 and is therefore correct, so limit enforcement is not broken; only the expiry-cache programming is wrong. Apply the same cast here so both paths convert rlim_cur identically. An integer truncation vulnerability occurs in the `update_rlimit_cpu()` function when converting the `RLIMIT_CPU` value to nanoseconds. While actual resource limit enforcement remains correct, this premature timer expiry could lead to a denial of service for affected processes.
Medium [CVE-2026-72296] require ETH_HLEN to be pullable in ife_decode
In the Linux kernel, the following vulnerability has been resolved: net: ife: require ETH_HLEN to be pullable in ife_decode() ife decode may return after making only the outer IFE header and metadata pullable. The caller then passes the decapsulated packet to eth_type_trans(), which expects the inner Ethernet header to be accessible from the linear data area. With a malformed IFE frame, the inner Ethernet header may still be shorter than ETH_HLEN in the linear area, which can lead to a crash in the original code. Fix this by extending the pull check in ife_decode() so that the inner Ethernet header is also guaranteed to be pullable before returning. A flaw was found in the Linux kernel's In-band Flow Engine (IFE) component. A remote attacker could send a specially crafted IFE frame with a malformed inner Ethernet header. This improper handling of the packet structure could lead to a system crash, resulting in a Denial of Service (DoS). Exploiting this flaw requires sending specially crafted IFE-encapsulated frames to a host where an IFE traffic-control action is configured, which in practice limits attacks to the network segment where IFE encapsulation is deployed. All Red Hat Enterprise Linux and Red Hat In-Vehicle OS kernel packages tracked for this flaw are not affected because the vulnerable code is not present in them.
Medium [CVE-2026-72458] fix NULL pointer dereference in unpack_pdb
In the Linux kernel, the following vulnerability has been resolved: apparmor: fix NULL pointer dereference in unpack_pdb pdb->dfa could be NULL if unpack_dfa fails, causing a NULL pointer dereference. A flaw was found in the Linux kernel's Apparmor security module. This vulnerability occurs in the `unpack_pdb` function, where it does not correctly handle a null pointer if a preceding operation, `unpack_dfa`, fails. This oversight can lead to a NULL pointer dereference, which typically results in a system crash and a Denial of Service (DoS) for the affected system. 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. 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-72373] Fix missing NULL pointer check in afs_break_some_callbacks
In the Linux kernel, the following vulnerability has been resolved: afs: Fix missing NULL pointer check in afs_break_some_callbacks() Fix afs_break_some_callbacks() to check to see if afs_lookup_volume_rcu() returned NULL (e.g. the specified volume is unknown). A flaw was found in the AFS (Andrew File System) component of the Linux kernel. A missing NULL pointer check in the `afs_break_some_callbacks()` function could allow a local attacker to trigger a kernel panic, leading to a denial of service. This occurs when the `afs_lookup_volume_rcu()` function returns a NULL value, indicating an unknown volume. Only system availability is affected; there is no impact on confidentiality or integrity. Red Hat Enterprise Linux 6, 7, and 8 are not affected because the vulnerable code is not present in those streams. Red Hat rates 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) reflecting a local attack vector requiring privileges, which differs from the upstream CVE record severity of 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H), where the network vector considers a malicious or compromised AFS server triggering the crash remotely on AFS client systems. Weakness: CWE-476. Red Hat does not currently list a fixing RHSA for this CVE. Affected products named by the advisory: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 9; Red Hat package: kernel-rt.
Medium [CVE-2026-72308] fix refcount leak in mlxsw_sp_port_lag_join
In the Linux kernel, the following vulnerability has been resolved: mlxsw: fix refcount leak in mlxsw_sp_port_lag_join() When mlxsw_sp_port_lag_index_get() fails, mlxsw_sp_port_lag_join() returns an error without releasing the lag reference obtained by the earlier mlxsw_sp_lag_get(). All other error paths in the function jump to the cleanup label that ends with mlxsw_sp_lag_put(), so this is a single missed release. Fix the leak by replacing the bare 'return err' with a goto to the existing error cleanup label, which will drop the reference safely. This vulnerability occurs when the `mlxsw_sp_port_lag_join()` function fails to properly release a network resource reference, leading to a reference count leak. Over time, this leak could exhaust system resources, potentially resulting in a denial of service (DoS) for affected systems. 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-911. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 6; Red Hat Enterprise Linux 7; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9. Will not fix / out of support: Red Hat Enterprise Linux 6. 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-72088] Fix DMA mapping leak on IOACCEL2 reset path
In the Linux kernel, the following vulnerability has been resolved: scsi: hpsa: Fix DMA mapping leak on IOACCEL2 reset path If phys_disk->in_reset is set, the function returns directly without undoing the resources acquired for the command. Add the missing error cleanup by unmapping the IOACCEL2 SG chain block when needed, unmapping the SCSI command, and dropping the outstanding IOACCEL command count before returning. When a physical disk is in a reset state, the driver fails to properly unmap Direct Memory Access (DMA) resources. This oversight can lead to a DMA mapping leak, potentially causing resource exhaustion over time. Red Hat severity: Moderate — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-772. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 6; Red Hat Enterprise Linux 9. Will not fix / out of support: Red Hat Enterprise Linux 6. 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-72445] clear opened when stream enable fails
In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: qcom: clear opened when stream enable fails On enable, subs->opened is set before the service_interval is validated; an invalid interval jumps to the response label without clearing it, so the substream is wedged at -EBUSY until a disable or disconnect. An attacker, by providing an invalid service interval during stream enablement, can cause the audio substream to become unresponsive. This can lead to a Denial of Service (DoS) for the affected audio device, requiring a disable or disconnect to restore functionality. 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-911. 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-72019] don't read an unset MAC header in macsec_encrypt
In the Linux kernel, the following vulnerability has been resolved: macsec: don't read an unset MAC header in macsec_encrypt() macsec_encrypt() reads the Ethernet header via eth_hdr(skb) (skb->head + skb->mac_header) to memmove() the 12 source/destination MAC bytes forward and make room for the SecTAG. On the AF_PACKET SOCK_RAW + PACKET_QDISC_BYPASS transmit path the skb reaches the macsec ndo_start_xmit() with the MAC header unset, so eth_hdr(skb) resolves to skb->head + (u16)~0 and the read is out of bounds: a 12-byte heap over-read that is also emitted on the wire as the frame's outer source/destination MAC. KASAN reports a slab-out-of-bounds read in macsec_start_xmit() on 6.0; on current mainline a CONFIG_DEBUG_NET build flags it as an unset mac header in skb_mac_header(). On the TX path the L2 header is at skb->data, so use skb_eth_hdr(), added by commit 96cc4b69581d ("macvlan: do not assume mac_header is set in macvlan_broadcast()") for exactly this purpose. When processing packets on the AF_PACKET SOCK_RAW + PACKET_QDISC_BYPASS transmit path, the `macsec_encrypt()` function attempts to read an unset Media Access Control (MAC) header. This leads to a 12-byte heap over-read, where sensitive data from memory beyond the intended buffer is accessed.
Medium [CVE-2026-68466] fail DMA transfer on completion timeout
In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: lpc32xx_slc: fail DMA transfer on completion timeout lpc32xx_xmit_dma() waits for the DMA completion callback but ignores wait_for_completion_timeout(). A timed out DMA transfer is therefore unmapped and reported as successful to the NAND read/write path. Return -ETIMEDOUT when the completion wait expires. Terminate the DMA channel before unmapping the scatterlist so the timed out transfer cannot continue to access the buffer after the error is returned. A flaw was found in the Linux kernel's `lpc32xx_slc` driver, which manages NAND flash memory. This vulnerability occurs because the driver fails to properly handle Direct Memory Access (DMA) transfer timeouts. When a DMA transfer times out, the driver incorrectly reports it as successful and unmaps the associated memory buffer without terminating the DMA channel. This can lead to the system attempting to access an unmapped memory region, potentially causing data corruption or system instability. 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-72059] destroy DMA pool on CLDMA late init failure
In the Linux kernel, the following vulnerability has been resolved: net: wwan: t7xx: destroy DMA pool on CLDMA late init failure t7xx_cldma_late_init() creates md_ctrl->gpd_dmapool before initializing the TX and RX rings. If any ring initialization fails, the error path frees the already initialized rings but leaves the DMA pool allocated. This issue occurs during the initialization of the Cellular Direct Memory Access (CLDMA) module. If the setup of the transmit or receive rings fails, a dedicated memory resource, known as a Direct Memory Access (DMA) pool, is not properly released. This oversight leads to a memory leak, which could potentially degrade system performance or stability over an extended period. Red Hat severity: Low — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-772. 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-72259] Release reserved memory on cleanup
In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: mt8192: Release reserved memory on cleanup The MT8192 AFE probe calls of_reserved_mem_device_init() and falls back to preallocated buffers when no reserved memory region is available. When the reserved memory assignment succeeds, however, the driver never releases it. Register a devm cleanup action after a successful reserved-memory assignment so the assignment is released on probe failure and driver unbind. A flaw was found in the Linux kernel's ASoC (Audio System on Chip) Mediatek MT8192 audio driver. This vulnerability occurs because the driver fails to release reserved memory after a successful assignment during the probe process. This oversight can lead to a memory leak, potentially causing system instability or a Denial of Service (DoS) due to resource exhaustion over extended operation. A local user with the privileges required to rebind or re-probe the audio device could repeat this cycle to progressively exhaust reserved memory, causing a denial of service through resource exhaustion over extended operation; there is no impact on confidentiality or integrity (Red Hat CVSS:3.1 score 5.5, AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Affected products named by the advisory: Red Hat Enterprise Linux 10; Red Hat package: kernel.