Red Hat Linux Security Advisories & CVEs
5864 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-68387] add locking for raw flags bitfield
In the Linux kernel, the following vulnerability has been resolved: can: raw: add locking for raw flags bitfield With commit 890e5198a6e5 ("can: raw: use bitfields to store flags in struct raw_sock") the formerly separate integer values have been integrated into a single bitfield. This led to a read-modify-write operation when changing a flag in raw_setsockopt() which now needs a locking to prevent concurrent access. Instead of adding a lock/unlock hell in each of the flag manipulations this patch introduces a wrapper for a new raw_setsockopt_locked() function analogue to the isotp_setsockopt[_locked]() approach in net/can/isotp.c [mkl: use Closes tag instead of Link] A flaw was found in the Linux kernel's Controller Area Network (CAN) raw socket implementation. A local attacker could exploit a race condition in the `raw_setsockopt()` function. This occurs due to insufficient locking during read-modify-write operations on a shared bitfield when modifying socket flags. Successful exploitation could lead to data corruption or system instability, potentially resulting in a denial of service. This issue affects CAN raw sockets. Converting CAN_RAW flags to a bitfield introduced unsynchronized read-modify-write races when multiple threads set socket options concurrently. 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-414.
Medium [CVE-2026-68385] Fix csum_partial without vector facility
In the Linux kernel, the following vulnerability has been resolved: s390/checksum: Fix csum_partial() without vector facility Currently csum_partial() calls csum_copy() with copy=false and dst=NULL. On machines without the vector facility, csum_copy() falls back to cksm(dst,...), causing the checksum to be calculated from address zero instead of the source buffer. The VX implementation already checksums data loaded from src. Make the fallback do the same by passing src to cksm(). A flaw was found in the Linux kernel's s390 architecture checksumming mechanism. On systems without a vector facility, the csum_partial() function incorrectly calculates checksums. This occurs because the csum_copy() function, when called with specific parameters, falls back to calculating the checksum from memory address zero instead of the intended source buffer. This can lead to incorrect checksums, potentially affecting data integrity within the kernel. This issue affects s390 without vector facility. csum_partial() passes NULL dst to csum_copy fallback. s390 non-vector machines only. 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. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 9; Red Hat Enterprise Linux for NVIDIA 26. Affected products named by the advisory: Red Hat package: kernel-rt.
Medium [CVE-2026-68384] Fix VF CCS attach/detach race with in-flight BO moves
In the Linux kernel, the following vulnerability has been resolved: drm/xe/vf: Fix VF CCS attach/detach race with in-flight BO moves xe_bo_move() attaches VF CCS read/write batch buffers (BBs) to a BO after it transitions NULL/SYSTEM -> TT, and detaches them after it transitions TT -> SYSTEM. Both operations were done synchronously on the CPU immediately after building the move's copy/clear fence, without waiting for that fence to signal. This creates two races with VF migration: - Attach happens too late relative to the copy job it is meant to protect. If the copy job is submitted before the CCS BBs are attached, a VF migration event that pauses execution mid-copy can observe partially copied CCS metadata without the attach state needed to correctly save/restore it. - Detach happens too early relative to the copy job that moves data out of TT. The CCS BBs are torn down right after the copy fence is obtained, while the actual blit may still be in flight. A VF migration event that pauses execution mid-copy can then race the save/restore path against the still-running blit, and the CCS BBs it would need to make sense of the paused state have already been removed. Fix both races: - Move the attach call to before the copy/clear job is submitted, so the CCS BBs are already registered by the time the copy runs.
Medium [CVE-2026-68383] Keep scheduler timeline name alive
In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Keep scheduler timeline name alive The scheduler keeps a pointer to the timeline name, but q->name is freed with the exec queue while scheduler fences can still reference it. Store the name in struct xe_guc_exec_queue so it shares the scheduler's RCU-deferred lifetime. (cherry picked from commit 41075f0eb5dcbd3b065d15f15ef7bbe9315188e8) This creates a use-after-free vulnerability, where the system attempts to access memory that has already been released. Such an issue can lead to system instability and crashes, potentially resulting in a denial of service. This issue affects Intel Xe GuC scheduler. Systems without Intel Xe are not affected. 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 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-68382] Hold device ref until queue teardown completes
In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Hold device ref until queue teardown completes GuC exec queue destruction can run asynchronously. If the final device put happens from a destroy worker, drmm cleanup can end up draining the same workqueue and deadlock. Hold a drm_device reference for the queue lifetime and drop it after queue teardown completes. This keeps drmm cleanup from running while async destroy work is still pending. Move GuC destroy work to a module-lifetime Xe workqueue and flush it on PCI remove so hot-unbind/rebind still waits for pending destroy work. With queue-held device refs, guc_submit_sw_fini() cannot run with live GuC IDs. This vulnerability arises from a race condition during the asynchronous destruction of the Graphics micro-controller (GuC) execution queues. If the device reference is released prematurely, it can lead to a deadlock within the Direct Rendering Manager (DRM) cleanup process. This deadlock can cause the affected system or component to become unresponsive, resulting in a Denial of Service (DoS). This issue affects Intel Xe graphics with GuC submission. Systems without Intel Xe are not affected. 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-833.
Medium [CVE-2026-68378] fix NULL pointer dereference in dpll_msg_add_pin_ref_sync
In the Linux kernel, the following vulnerability has been resolved: dpll: fix NULL pointer dereference in dpll_msg_add_pin_ref_sync() When a dpll_pin is shared across multiple dpll_device instances and those devices are being unregistered (e.g. during driver module removal), a NULL pointer dereference can occur in dpll_msg_add_pin_ref_sync(). Affected products named by the advisory: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 9; Red Hat package: kernel-rt.
Medium [CVE-2026-68375] Handle partially initialized auxiliary devices
In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Handle partially initialized auxiliary devices bnxt_aux_devices_init() calls auxiliary_device_init() before all fields used by bnxt_aux_dev_release() are initialized. After auxiliary_device_init() succeeds, later errors must unwind with auxiliary_device_uninit(), which invokes the release callback. The release callback assumes that aux_priv->id, aux_priv->edev, edev->net and edev->ulp_tbl are all populated. If allocation fails after auxiliary_device_init(), the release path can otherwise dereference or clear partially initialized state. Allocate and attach the bnxt_en_dev and ULP table before calling auxiliary_device_init(), so the release callback only sees a fully initialized auxiliary private object. If auxiliary_device_init() itself fails, free those allocations directly because device_initialize() has not run and the release callback will not be invoked. This issue was found by a static analysis checker and confirmed by manual source review. A flaw was found in the Linux kernel's `bnxt_en` driver, which handles Broadcom NetXtreme-C/E network adapters. This could lead to system instability or a denial of service. Affected products named by the advisory: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 9; Red Hat Enterprise Linux for NVIDIA 26; Red Hat package: kernel-rt.
Medium [CVE-2026-68371] Do not put borrowed of_node in probe
In the Linux kernel, the following vulnerability has been resolved: usb: musb: omap2430: Do not put borrowed of_node in probe omap2430_probe() stores pdev->dev.of_node in a local np variable. This is a borrowed pointer and the probe function does not take a reference to it. The success and error paths nevertheless call of_node_put(np). This drops a reference that is owned by the platform device, and can leave pdev->dev.of_node with an unbalanced reference count. References taken for the child MUSB device are handled by the device core, and the ctrl-module phandle reference is still released separately. The `omap2430_probe()` function incorrectly decrements the reference count of a borrowed device node, leading to an unbalanced reference count. This issue could potentially result in a denial of service. This issue affects OMAP2430 MUSB USB controller. omap2430_probe() of_node_put on borrowed pointer underflows refcount. OMAP platforms only. 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. 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; Red Hat Enterprise Linux for NVIDIA 26; Red Hat OpenShift Container Platform 4 as not affected.
Medium [CVE-2026-68369] fix infinite loop in printer_read
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: printer: fix infinite loop in printer_read() printer_read() uses the same variable for the requested copy size and the number of bytes actually copied to user space. copy_to_user() returns the number of bytes not copied, so when it fails to copy anything, the computed copied length becomes zero. In that case len, buf, current_rx_bytes and current_rx_buf are left unchanged. If RX data is available and the user buffer remains unwritable, the read loop can repeat indefinitely. Track the copied length separately and return -EFAULT, or the number of bytes already copied, if an iteration makes no progress. An attacker, by providing specific input to the `printer_read()` function, could trigger an infinite loop. This vulnerability occurs when the `copy_to_user()` function fails to copy data, leading to a denial of service condition where the system becomes 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-835. Affected Red Hat products: Red Hat OpenShift Container Platform 4. Red Hat does not currently list a fixing RHSA for this CVE.
Medium [CVE-2026-68367] synchronize delayed set_alt with teardown
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_tcm: synchronize delayed set_alt with teardown The f_tcm set_alt() path defers endpoint setup to a work item and completes the delayed status response from process context. The delayed work uses f_tcm private state and may complete the setup request after disconnect or function teardown has already moved on. Cancel and drain the delayed set_alt work when the function is unbound or freed. For disable paths, which are reached under the composite device lock, use a small state machine and a non-sleeping cancellation path instead of cancel_work_sync(). If the work is already running, mark it cancelled and let the worker own the cleanup; otherwise tcm_disable() can cancel the queued work and clean up immediately. Also serialize the final delayed-status completion with the cancellation check while holding the composite device lock. This prevents a disconnect from clearing delayed_status while the worker is about to complete the control request. Affected product named by the advisory: Red Hat OpenShift Container Platform 4.
Medium [CVE-2026-68366] clamp SEND_RESPONSE length to the response buffer
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: clamp SEND_RESPONSE length to the response buffer uvc_send_response() builds the UVC control response from a user-supplied struct uvc_request_data: req->length = min_t(unsigned int, uvc->event_length, data->length);... memcpy(req->buf, data->data, req->length); req->length is clamped to uvc->event_length, which is taken from the host control request wLength (up to UVC_MAX_REQUEST_SIZE, 64), and to data->length, which comes from the UVCIOC_SEND_RESPONSE ioctl and is only checked for being negative. The source buffer data->data is only 60 bytes, so a response with uvc->event_length and data->length both greater than 60 makes memcpy() read past the end of data->data. The uvc_send_response() function, which constructs UVC control responses, fails to properly restrict the length of data copied into a response buffer. A remote attacker, by sending a specially crafted USB control request, could cause an out-of-bounds read. This could lead to information disclosure or a denial of service (DoS) on the affected system. Systems not using UVC gadget are not affected. 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-125. Affected Red Hat products: Red Hat OpenShift Container Platform 4. Red Hat does not currently list a fixing RHSA for this CVE.
Medium [CVE-2026-68364] Fix ISM dc_lock deadlock during suspend
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix ISM dc_lock deadlock during suspend [Why] System hang observed during suspend/resume while video is playing. amdgpu_dm_ism_disable() is called under dc_lock and waits for ISM delayed work via disable_delayed_work_sync(). The work handlers themselves take dc_lock, producing an ABBA deadlock when a worker is in flight at suspend time. [How] Split the disable path into two phases with opposite locking contracts: 1. amdgpu_dm_ism_disable() -- quiesces workers, must NOT hold dc_lock. 2. amdgpu_dm_ism_force_full_power() (new) -- drives the ISM FSM back to FULL_POWER_RUNNING, must hold dc_lock. This issue arises due to conflicting locking mechanisms within the display driver, where a function attempting to disable a component waits for delayed work that itself tries to acquire the same lock. This can lead to a system hang, resulting in a Denial of Service (DoS) for the affected system. Systems without AMD GPUs are not affected. 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-833. 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; Red Hat Enterprise Linux for NVIDIA 26; Red Hat OpenShift Container Platform 4.
Medium [CVE-2026-68362] fix NULL pointer dereference in ath11k_hal_srng_access_begin
In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix NULL pointer dereference in ath11k_hal_srng_access_begin In ATH11K_QMI_EVENT_FW_READY, ATH11K_FLAG_REGISTERED is set unconditionally even when ath11k_core_qmi_firmware_ready() fails. This leaves the driver in an inconsistent state where initialization is considered complete although the firmware ready handling did not finish successfully. During the subsequent SSR, the driver enters the restart path based on this incorrect state and dereferences uninitialized srng members, resulting in a NULL pointer dereference. Call trace: ath11k_hal_srng_access_begin+0xc/0x60 [ath11k] (P) ath11k_ce_cleanup_pipes+0x17c/0x180 [ath11k] ath11k_core_restart+0x40/0x168 [ath11k] Fix this by: - skipping firmware_ready if ATH11K_FLAG_REGISTERED is already set - setting ATH11K_FLAG_REGISTERED only when firmware_ready succeeds - setting ATH11K_FLAG_QMI_FAIL and aborting the FW_READY handling on error Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.2.0.c2-00204-QCAMSLSWPLZ-1 A flaw was found in the `ath11k` Wi-Fi driver for the Linux kernel. During the firmware ready process, the driver incorrectly sets a flag indicating successful initialization even when the process fails.
Medium [CVE-2026-68360] (corsair-cpro) Stop device IO before calling hid_hw_stop
In the Linux kernel, the following vulnerability has been resolved: hwmon: (corsair-cpro) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after "io start" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop(). A race condition can occur during the driver's initialization process if device input/output (IO) is started but then fails. This timing issue can lead to a use-after-free (UAF) vulnerability, where the system attempts to access memory that has already been released. This critical flaw could potentially allow a local attacker to execute arbitrary code or cause a system crash (denial of service). This issue affects Corsair Commander Pro (corsair-cpro hwmon). HID I/O not stopped before hid_hw_stop on probe failure can UAF. Systems without this hardware are not affected. 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.
Medium [CVE-2026-68358] (nzxt-kraken3) Stop device IO before calling hid_hw_stop
In the Linux kernel, the following vulnerability has been resolved: hwmon: (nzxt-kraken3) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after "io start" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop(). A race condition exists where the `hid_hw_stop()` function does not stop device input/output (IO). This can lead to a use-after-free (UAF) vulnerability if a device probe operation fails after IO has been initiated. This vulnerability could allow a local attacker to potentially cause a denial of service or escalate privileges. This issue affects NZXT Kraken3 AIO coolers (nzxt-kraken3 hwmon). HID I/O not stopped before hid_hw_stop on probe failure can UAF. Systems without this hardware are not affected. 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 for NVIDIA 26. Affected products named by the advisory: Red Hat package: kernel.
Medium [CVE-2026-68356] Prevent division by zero when clock frequency is zero
In the Linux kernel, the following vulnerability has been resolved: watchdog: airoha: Prevent division by zero when clock frequency is zero clk_get_rate() can return 0 when the clock provider is not properly configured or the clock is unmanaged. The driver uses wdt_freq as a divisor directly in airoha_wdt_probe() to compute max_timeout and in airoha_wdt_get_timeleft() to compute the remaining time, which results in a division by zero. Add a check for wdt_freq == 0 in probe and return -EINVAL with dev_err_probe() to prevent the division by zero and provide a diagnostic message. This vulnerability occurs when the clock frequency is zero, causing the driver to attempt a division by zero. This can lead to a system crash, resulting in a denial of service for the affected system. Airoha SoC platforms only. 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. 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; Red Hat Enterprise Linux for NVIDIA 26; Red Hat OpenShift Container Platform 4 as not affected.
Medium [CVE-2026-68354] Fix fragmented datagram reassembly
In the Linux kernel, the following vulnerability has been resolved: firewire: net: Fix fragmented datagram reassembly fwnet_frag_new() keeps a sorted list of received fragments for a partial datagram. When a new fragment is adjacent to an existing fragment, the code checks whether the new fragment also closes the gap to the next or previous list entry. Those neighbor lookups currently assume that the current fragment always has a real next or previous fragment. At a list edge, the next or previous entry is the list head, not a struct fwnet_fragment_info. The gap checks also compare against the old edge of the current fragment instead of the edge after adding the new fragment. As a result, a fragment that bridges two existing ranges may leave two adjacent ranges unmerged, so fwnet_pd_is_complete() can miss a complete datagram. Check for the list head before looking up the neighboring fragment, and compare the neighbor against the new fragment's far edge when deciding whether to merge all three ranges. This issue was found by a static analysis checker and confirmed by manual source review. A flaw was found in the FireWire (IEEE 1394) networking driver in the Linux kernel. The fragmented datagram reassembly logic in `fwnet_frag_new()` incorrectly handles list edges and merging of adjacent fragments.
Medium [CVE-2026-68353] fix OOB read from firmware num_msg in TX complete handler
In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB read from firmware num_msg in TX complete handler The firmware-controlled num_msg field (u8, 0-255) drives the loop in ath6kl_wmi_tx_complete_event_rx() without validation against the buffer length. This allows out-of-bounds reads of up to 1020 bytes past the WMI event buffer when the firmware sends an inflated num_msg. Add a check that the buffer is large enough to hold the fixed struct and the num_msg variable-length entries. The `ath6kl_wmi_tx_complete_event_rx()` function, responsible for handling Wi-Fi messages, does not properly validate the `num_msg` field provided by the firmware against the buffer length. This could result in information disclosure or potentially a denial of service. This issue affects Qualcomm ath6kl Wi-Fi. TX complete handler loops on firmware num_msg without buffer bounds check, allowing large OOB reads. Systems without ath6kl hardware are not affected. 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-125. Affected Red Hat products: Red Hat Enterprise Linux 7; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9; Red Hat OpenShift Container Platform 4. 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-68352] fix OOB read from firmware IE lengths in connect event
In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB read from firmware IE lengths in connect event The firmware-controlled beacon_ie_len, assoc_req_len, and assoc_resp_len fields in ath6kl_wmi_connect_event_rx() are not validated against the buffer length. Their sum (up to 765) can exceed the actual WMI event data, causing out-of-bounds reads during IE parsing and state corruption of wmi->is_wmm_enabled. Add a check that the total IE length fits within the buffer. The driver does not properly validate the lengths of firmware-controlled information elements (IEs) during a connect event. This vulnerability allows the sum of these lengths to exceed the allocated buffer, resulting in an out-of-bounds read. An attacker could exploit this to cause state corruption within the driver, potentially leading to a denial of service. This issue affects Qualcomm ath6kl Wi-Fi. Systems without ath6kl hardware are not affected. 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-805. Affected Red Hat products: Red Hat Enterprise Linux 7; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9; Red Hat OpenShift Container Platform 4. 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-68350] Linux kernel carl9170 Wi-Fi driver: Out-of-bounds read vulnerability
In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: fix OOB read from off-by-two in TX status handler The bounds check in carl9170_tx_process_status() uses `i > ((cmd->hdr.len / 2) + 1)` which is off by two, allowing 2 extra iterations past valid _tx_status entries when the firmware- controlled hdr.ext exceeds hdr.len/2. An out-of-bounds read vulnerability exists within the `carl9170_tx_process_status()` function. This issue is caused by an off-by-two error in a bounds check, allowing the system to read beyond the intended memory buffer when processing firmware-controlled data. This could potentially lead to information disclosure or system instability. Red Hat severity: Moderate — CVSS 6.1 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:H). Weakness: CWE-125. Affected Red Hat products: Red Hat Enterprise Linux 7; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9; Red Hat OpenShift Container Platform 4. Red Hat does not currently list a fixing RHSA for this CVE. Affected products named by the advisory: Red Hat package: kernel-rt.