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-72430] fix nf_connlabels leak on two error paths
In the Linux kernel, the following vulnerability has been resolved: net/sched: act_ct: fix nf_connlabels leak on two error paths tcf_ct_fill_params() calls nf_connlabels_get() (setting put_labels) when TCA_CT_LABELS is present, but two later error sites use a bare return instead of "goto err", skipping the err: nf_connlabels_put() cleanup. They also precede the "p->put_labels = put_labels" assignment, so the tcf_ct_params_free() fallback does not release the count either. Each failed RTM_NEWACTION on these paths leaks one nf_connlabels Affected products named by the advisory: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 9; Red Hat package: kernel-rt.
Medium [CVE-2026-72277] Inject SEA if guest VNCR isn't normal memory
In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: nv: Inject SEA if guest VNCR isn't normal memory When constructing an L1 VNCR mapping, KVM unconditionally uses cacheable memory attributes, even if the underlying PFN isn't memory. This gets particularly hairy if the endpoint doesn't support cacheable memory attributes, potentially throwing an SError on writeback... While KVM does permit cacheable memory attributes on certain PFNMAP VMAs, kvm_translate_vncr() isn't currently grabbing the VMA. So do the simpler thing for now and just reject everything that isn't memory. A flaw was found in the Linux kernel's KVM (Kernel-based Virtual Machine) for ARM64 systems. When KVM constructs an L1 VNCR (Virtual Nested Control Register) mapping, it incorrectly applies cacheable memory attributes even when the underlying physical memory is not normal memory. This can lead to a system error (SError) during writeback operations, potentially causing system instability or a denial of service. Exploitation requires local access to a guest virtual machine capable of controlling nested virtualization state and its backing memory mappings; the issue is not network-reachable and affects availability only, with no impact on confidentiality or integrity. Affected products named by the advisory: Red Hat Enterprise Linux 10; Red Hat package: kernel.
Medium [CVE-2026-72116] fix stale rx/tx ops after device removal
In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix stale rx/tx ops after device removal RX: an RX_SETUP update(!) for an existing op skipped can_rx_register() unconditionally, even when a concurrent NETDEV_UNREGISTER had already torn down its registration (op->rx_reg_dev == NULL). This silently did not re-enable frame delivery for that updated filter. bcm_rx_setup() now re-registers in that case, while leaving rx_ops with ifindex = 0 (all CAN devices) which never carry a tracked rx_reg_dev registered as-is. TX: bcm_notify() only handled bo->rx_ops on NETDEV_UNREGISTER, leaving tx_ops with an active cyclic transmission re-arming its hrtimer indefinitely to execute bcm_tx_timeout_handler(). Cancelling the hrtimer prevents the runaway timer and any injection into a later reused ifindex, since nothing else calls bcm_can_tx() for the op until an explicit TX_SETUP update re-arms it. Unlike bcm_rx_unreg(), which clears the tracked rx_reg_dev for rx_ops, the ifindex is intentionally left unchanged for tx_ops. bcm_tx_setup() always rejects ifindex 0, so clearing it would strand the op: neither a later TX_SETUP (bcm_find_op()) nor TX_DELETE (bcm_delete_tx_op()) could ever find it again, since both require an exact ifindex match. A flaw was found in the Linux kernel's Broadcom Controller Area Network (CAN) bus driver.
Medium [CVE-2026-72472] use nfsi->rwsem to protect traversal of the file lock list
In the Linux kernel, the following vulnerability has been resolved: nfs: use nfsi->rwsem to protect traversal of the file lock list Lingfeng identified a bug and suggested two solutions, but both appear to have issues. Generally, we cannot release flc_lock while iterating over the file lock list to avoid use-after-free (UAF) problems with file locks. However, functions like nfs_delegation_claim_locks and nfs4_reclaim_locks cannot adhere to this rule because recover_lock or nfs4_lock_delegation_recall may take a long time. To resolve this, NFS switches to using nfsi->rwsem for the same protection, and nfs_reclaim_locks follows this approach. Although nfs_delegation_claim_locks uses so_delegreturn_mutex instead, this is inadequate since a single inode can have multiple nfs4_state instances. Therefore, the fix is to also use nfsi->rwsem in this case. Furthermore, after commit c69899a17ca4 ("NFSv4: Update of VFS byte range lock must be atomic with the stateid update"), the functions nfs4_locku_done and nfs4_lock_done also break this rule because they call locks_lock_inode_wait without holding nfsi->rwsem. Simply adding this protection could cause many deadlocks, so instead, the call to locks_lock_inode_wait is moved into _nfs4_proc_setlk.
Medium [CVE-2026-72483] Fix shift-out-of-bounds in max3421_hub_control
In the Linux kernel, the following vulnerability has been resolved: usb: host: max3421: Fix shift-out-of-bounds in max3421_hub_control() The `max3421_hub_control()` function handles USB hub class requests to the virtual root hub. In the `default` branches of both the `ClearPortFeature` and `SetPortFeature` switch statements, it modifies `max3421_hcd->port_status` by left shifting 1 by the request's `value` parameter. However, it does not validate whether this shift will exceed the width of `port_status`. So if a malicious userspace task with access to the root hub via /dev/bus/usb/.../001 issues a USBDEVFS_CONTROL ioctl with `wValue` greater than or equal to 32, the left shift operation invokes shift-out-of-bounds undefined behavior. This results in arbitrary bit corruption of `port_status`, including the normally-immutable change bits, which can bypass internal state checks and confuse the hub status. Fix this by rejecting requests whose `value` exceeds the shift width before performing the shift. This issue was found using a KLEE-based symbolic execution tool for kernel drivers that I'm currently developing. A moderate severity flaw was found in the Linux kernel MAX3421E USB host controller driver.
Medium [CVE-2026-72411] fix use-after-free of DSA ports in crc_err_work
In the Linux kernel, the following vulnerability has been resolved: net: dsa: mxl862xx: fix use-after-free of DSA ports in crc_err_work Upon an MDIO CRC error mxl862xx_crc_err_work_fn() walks the DSA ports and closes the CPU port conduits: dsa_switch_for_each_cpu_port(dp, priv->ds) dev_close(dp->conduit); mxl862xx_remove() unregisters the switch before cancelling this work: set_bit(MXL862XX_FLAG_WORK_STOPPED, &priv->flags); cancel_delayed_work_sync(&priv->stats_work); dsa_unregister_switch(ds); mxl862xx_host_shutdown(priv); dsa_unregister_switch() frees the dsa_port objects. If a CRC error schedules the work during teardown it can run after the ports have been freed and dereference freed memory. Guard the port walk with MXL862XX_FLAG_WORK_STOPPED, which is already set before dsa_unregister_switch(). DSA tears the ports down under rtnl_lock(), so checking the flag under rtnl_lock() means the work either runs before teardown and sees valid ports, or runs afterwards, observes the flag and skips the walk. This mirrors the host_flood_work handler, which skips torn-down ports under rtnl_lock(). A flaw was found in the Linux kernel's mxl862xx Digital Subscriber Line (DSA) driver. An issue during the driver's teardown process, specifically when handling MDIO CRC errors, can lead to a use-after-free vulnerability.
Medium [CVE-2026-72327] Reject invalid indirect BO handle in indirect CSD setup
In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Reject invalid indirect BO handle in indirect CSD setup v3d_get_cpu_indirect_csd_params() looks up the indirect buffer object from a userspace-supplied handle but never checks the result. A bogus or stale handle makes drm_gem_object_lookup() return NULL, which is then stored in info->indirect and only dereferenced later when the indirect CSD job runs, turning a userspace mistake into a NULL pointer dereference in the kernel. Bail out with -ENOENT as soon as the lookup fails, so the bad handle is rejected at submission time. This can lead to a system crash, resulting in a Denial of Service (DoS). A low impact flaw was found in the Linux kernel drm/v3d driver. There is no impact on confidentiality or integrity. All currently assessed Red Hat Enterprise Linux and Red Hat In-Vehicle OS kernel streams are not affected because the vulnerable code is not present in the shipped kernels. Although the CVSS:3.1 base score is 5.5 (moderate), the overall Red Hat impact is rated low because exploitation requires local access to the V3D DRM device and the consequence is limited to a system crash. Weakness: CWE-476.
Medium [CVE-2026-72032] HWS, fix matcher leak on resize target setup failure
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: HWS, fix matcher leak on resize target setup failure hws_bwc_matcher_move() allocates a replacement matcher before setting it as the resize target. If mlx5hws_matcher_resize_set_target() fails, the replacement matcher is not attached anywhere and is leaked. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1.1. An x86_64 allyesconfig build showed no new warnings. As we do not have a mlx5 HWS-capable device to test with, no runtime testing was able to be performed. This vulnerability occurs when the hws_bwc_matcher_move() function attempts to resize a matcher, and the mlx5hws_matcher_resize_set_target() operation fails. In such a scenario, a replacement matcher is allocated but not properly deallocated, leading to a memory leak. Over time, repeated occurrences of this flaw could potentially lead to a Denial of Service (DoS) due to resource exhaustion. 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. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 6; Red Hat Enterprise Linux 9.
Medium [CVE-2026-72486] fix UAF during device teardown
In the Linux kernel, the following vulnerability has been resolved: mailbox: mtk-adsp: fix UAF during device teardown When the SOF audio driver fails to initialize (e.g. firmware boot timeout), its devres unwind frees the snd_sof_dev object that the mailbox client (mtk-adsp-ipc) reaches via chan->cl->rx_callback. The mtk-adsp-mailbox shutdown clears the mailbox command registers but leaves the IRQ line unmasked, so a late interrupt can still queue a threaded handler after mbox_free_channel() had cleared chan->cl, and mbox_chan_received_data() would then trigger UAF: BUG: KASAN: slab-use-after-free in sof_ipc3_validate_fw_version sof_ipc3_validate_fw_version sof_ipc3_do_rx_work sof_ipc3_rx_msg mt8196_dsp_handle_request mtk_adsp_ipc_recv mbox_chan_received_data mtk_adsp_mbox_isr irq_thread_fn Freed by task...: kfree devres_release_all really_probe... (sof-audio-of-mt8196 probe failure) The crash was observed roughly three seconds after the failed probe. disable_irq() in shutdown and enable_irq() in startup. disable_irq() also waits for any in-flight interrupts, so by the time mbox_free_channel() proceeds to clear chan->cl no rx_callback can run. In addition, request the IRQ with IRQF_NO_AUTOEN so it stays masked between probe and the first client bind — otherwise an early interrupt can crash on chan->cl == NULL in mbox_chan_received_data().
Medium [CVE-2026-72056] clean up XDP TX queues when regular TX setup fails
In the Linux kernel, the following vulnerability has been resolved: net: ena: clean up XDP TX queues when regular TX setup fails create_queues_with_size_backoff() creates XDP TX queues before setting up the regular TX path. If the subsequent allocation or creation of regular TX queues fails, the error handling paths omit the teardown of the XDP TX queues, leading to a resource leak. Fix this by explicitly destroying the XDP TX queue subset at the two missing failure points. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc7. An x86_64 allyesconfig build showed no new warnings. As we do not have an ENA device to test with, no runtime testing was able to be performed. A flaw was found in the Linux kernel's Elastic Network Adapter (ENA) driver. During the setup of eXpress Data Path (XDP) transmit (TX) queues, if the subsequent setup of regular TX queues fails, the error handling mechanism does not properly clean up the XDP TX queues. This oversight can lead to a resource leak, potentially resulting in a Denial of Service (DoS) condition. 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-459.
Medium [CVE-2026-72155] Improve locking user experience
In the Linux kernel, the following vulnerability has been resolved: mtd: spi-nor: swp: Improve locking user experience In the case of the first block being locked (or the few first blocks), if the user want to fully unlock the device it has two possibilities: - either it asks to unlock the entire device, and this works; - or it asks to unlock just the block(s) that are currently locked, which fails. It fails because the conditions "can_be_top" and "can_be_bottom" are true. Indeed, in this case, we unlock everything, so the TB bit does not matter. However in the current implementation, use_top would be true (as this is the favourite option) and lock_len, which in practice should be reduced down to 0, is set to "nor->params->size - (ofs + len)" which is a positive number. This is wrong. An easy way is to simply add an extra condition. In the unlock() path, if we can achieve the same result from both sides, it means we unlock everything and lock_len must simply be 0. A comment is added to clarify that logic. When a user attempts to unlock specific blocks on a Serial Peripheral Interface (SPI) NOR flash device, particularly those at the beginning of the device, the operation may fail. This occurs due to an incorrect calculation of the `lock_len` parameter, which prevents the intended blocks from being unlocked.
Medium [CVE-2026-72014] reject data replies with an out-of-range payload size
In the Linux kernel, the following vulnerability has been resolved: drbd: reject data replies with an out-of-range payload size recv_dless_read() receives a P_DATA_REPLY from a peer into the bio of an outstanding read request. The peer-supplied payload length reaches it as the signed int data_size, and two peer-controlled inputs can make it negative. With a negotiated data-integrity-alg the digest length is subtracted first, so a reply whose payload is smaller than the digest underflows data_size. With no integrity algorithm (the default) data_size is assigned from the unsigned h95/h100 wire length and drbdd() never bounds it for a payload-carrying command, so a length above INT_MAX casts it negative; this path needs no non-default feature. The bio receive loop then computes expect = min_t(int, data_size, bv_len), which is negative, and drbd_recv_all_warn(mapped, expect) receives with a size_t of SIZE_MAX into the first mapped page. The sibling receive path read_in_block() is not affected: it uses an unsigned size and rejects it against DRBD_MAX_BIO_SIZE before receiving. Reject a data reply whose size is negative after the optional digest subtraction, covering both triggers. Impact: a malicious or man-in-the-middle DRBD peer copies attacker-chosen bytes past a bio page in the receiver, corrupting kernel memory.
Medium [CVE-2026-72163] fix NULL h_transaction deref in ocfs2_assure_trans_credits
In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix NULL h_transaction deref in ocfs2_assure_trans_credits [BUG] A direct write over unwritten extents can panic the kernel in ocfs2_assure_trans_credits() when the journal aborts during DIO completion. The crash is a general protection fault from a NULL pointer dereference. [CAUSE] ocfs2_dio_end_io_write() loops over a direct write's unwritten extents, marking each written under a single journal handle. If the journal aborts (for example after an I/O error) while the extent tree is being updated, the handle is left aborted with its transaction pointer cleared. The extent merge treats that failure as not critical and reports success, so the loop keeps using the handle. ocfs2_assure_trans_credits() reads the handle's remaining credits without first checking whether the handle is aborted, and that read dereferences the cleared transaction pointer. [FIX] A journal abort is recorded in the handle itself, so callers are expected to test the handle rather than rely on a returned error. Make ocfs2_assure_trans_credits() do that, as the other ocfs2 journal helpers already do, and return -EROFS when the handle is aborted. A local user with write access to an OCFS2 filesystem could trigger a kernel panic by performing a direct write over unwritten extents.
Medium [CVE-2026-72183] Fix LANDLOCK_SCOPE_SIGNAL bypass on the SIGIO path
In the Linux kernel, the following vulnerability has been resolved: landlock: Fix LANDLOCK_SCOPE_SIGNAL bypass on the SIGIO path LANDLOCK_SCOPE_SIGNAL must prevent a sandboxed process from signaling processes outside its Landlock domain. It can be bypassed through the asynchronous SIGIO delivery path. A sandboxed process that owns any file or socket can arm it with fcntl(fd, F_SETOWN, -pgid), fcntl(fd, F_SETSIG, SIGKILL) and O_ASYNC, so that an I/O event makes the kernel deliver the chosen signal to the whole process group. As the head of its process group's task list (the default position right after fork()) that group can also hold the non-sandboxed process that launched it, e.g. a supervisor or a security monitor. The sandbox can thus kill or signal the processes LANDLOCK_SCOPE_SIGNAL is meant to protect from it. The scope is enforced in hook_file_send_sigiotask() against the Landlock domain recorded at F_SETOWN time, not the live domain of the sender. control_current_fowner() decides whether to record that domain and skips recording it when the fowner target is in the caller's thread group, which is safe only for a single-task target (PIDTYPE_PID, PIDTYPE_TGID). Affected products named by the advisory: Red Hat Enterprise Linux 9; Red Hat package: kernel-rt.
Medium [CVE-2026-72303] Validate notification payload size
In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: ipc4-control: Validate notification payload size Validate MODULE_NOTIFICATION payload length before reading bytes/channel data in control update handling. An attacker could potentially exploit this by providing a malformed notification, which may lead to unexpected system behavior or a denial of service. A moderate out-of-bounds read vulnerability was found in the Linux kernel ASoC Sound Open Firmware (SOF) IPC4 control update handling. The MODULE_NOTIFICATION payload length is not validated before bytes/channel control data is read, so a malformed notification reaching the SOF IPC4 audio control path can cause the kernel to read past the end of the notification buffer, resulting in a kernel crash and 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) because exploitation requires local access on a system with affected SOF IPC4 audio support and the impact is limited to availability; this differs from the upstream CVEORG score of 7.8, which assumes high confidentiality and integrity impact that the evidence for this read-only flaw does not support. Affected products named by the advisory: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 9; Red Hat package: kernel-rt.
Medium [CVE-2026-72087] Fix memory leak in lpfc_sli4_driver_resource_setup
In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Fix memory leak in lpfc_sli4_driver_resource_setup() The memory allocated for mboxq using mempool_alloc() is not freed in some of the early exit error paths. Fix that by moving the mempool_free() call to an earlier point after last use. This memory leak can lead to resource exhaustion, potentially resulting in a denial of service (DoS) for the system. 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. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 6; 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-72029] bound device offsets in the MUX downlink decoder
In the Linux kernel, the following vulnerability has been resolved: net: wwan: iosm: bound device offsets in the MUX downlink decoder mux_dl_adb_decode() walks a chain of aggregated datagram tables using offsets and lengths taken from the modem. first_table_index, next_table_index, table_length, datagram_index and datagram_length are all device supplied le values. Only first_table_index was checked, and only for being non zero. The decoder then formed adth = block + adth_index and read the table header and the datagram entries with no bound against the received skb. A modem that reports an index or a length past the downlink buffer makes the decoder read out of bounds. The buffer is IPC_MEM_MAX_DL_MUX_LITE_BUF_SIZE and skb->len is at most that, so skb->len is the real limit, but none of these in band offsets were checked against it. The table chain is also followed with no forward progress check. The loop takes the next table from adth->next_table_index and stops only when that reaches zero. A modem can stage two tables that point at each other, so the loop never ends. It runs in softirq and clones the skb on every pass. Validate every device offset and length against skb->len before use. Each table header, on entry and after every next_table_index, must lie inside the skb. The header padding must not exceed the datagram length so the receive length does not wrap.
Medium [CVE-2026-72238] Validate console=uart8250 baud rate to fix early boot hang
In the Linux kernel, the following vulnerability has been resolved: x86/boot: Validate console=uart8250 baud rate to fix early boot hang When the baud rate is empty, 0, invalid, or overflows to 0 when stored as an int, the system will hang during early boot because of a division by zero in early_serial_init(). Fall back to DEFAULT_BAUD when the resulting baud rate is 0 to prevent an early system hang. This invalid input leads to a division-by-zero error in the `early_serial_init()` function, resulting in a Denial of Service (DoS). A MODERATE severity denial of service flaw was found in the Linux kernel x86 boot code. A local user able to control kernel boot parameters could use this flaw to cause a complete denial of service of the system at boot time; confidentiality and integrity are not affected. All Red Hat Enterprise Linux 6 through 10 (kernel and kernel-rt) and Red Hat In-Vehicle OS 2 (kernel and kernel-ivos-qualcomm) products in scope for this flaw are not affected because the vulnerable code is not present in the shipped kernels. 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-369.
Medium [CVE-2026-72037] Initialize eth_syslock spinlock before use
In the Linux kernel, the following vulnerability has been resolved: net: lan743x: Initialize eth_syslock spinlock before use lan743x_hardware_init() calls pci11x1x_strap_get_status() during the PCI11x1x probe sequence. That helper acquires the Ethernet subsystem hardware lock via lan743x_hs_syslock_acquire(), which relies on adapter->eth_syslock_spinlock to serialize access. The spinlock is currently initialized only after the strap status is read. With CONFIG_DEBUG_SPINLOCK enabled, taking the zeroed initialized spinlock can trip the spinlock debug check. Fix by initializing adapter->eth_syslock_spinlock before reading the strap status so the probe path never attempts to lock an uninitialized spinlock. A flaw was found in the Linux kernel's `lan743x` Ethernet driver. A system lock, or spinlock, is accessed during the driver's initialization sequence before it has been properly set up. This improper initialization can lead to a system crash if kernel debugging features are enabled, 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-908. 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-72024] remove interfaces with RCU list deletion
In the Linux kernel, the following vulnerability has been resolved: mac802154: remove interfaces with RCU list deletion Queue wake, stop, and disable paths walk local->interfaces under RCU. The bulk hardware teardown path removes entries with list_del(), so an asynchronous transmit completion can follow a poisoned list node in ieee802154_wake_queue(). Use list_del_rcu() as in the single-interface removal path. The following unregister_netdevice() waits for in-flight RCU readers before freeing the netdevice, so no separate grace-period wait is needed. When network interfaces are removed, the system incorrectly manages memory, which can cause a program to try and use memory that is no longer available or has been corrupted. This vulnerability could lead to system instability or a denial of service, making the affected system unresponsive. 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. 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.