Red Hat Linux Security Advisories & CVEs
13625 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-68227] fix devres lifetime
In the Linux kernel, the following vulnerability has been resolved: media: cx231xx: fix devres lifetime USB drivers bind to USB interfaces and any device managed resources should have their lifetime tied to the interface rather than parent USB device. This avoids issues like memory leaks when drivers are unbound without their devices being physically disconnected (e.g. on probe deferral or configuration changes). Fix the driver state lifetime so that it is released on driver unbind. This vulnerability arises from incorrect management of device-managed resources, where their lifetime is tied to the parent Universal Serial Bus (USB) device instead of the USB interface. This can lead to memory leaks when drivers are unbound without the associated devices being physically disconnected, potentially 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-772. 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-68139] Use sender devcom for MPV master-up
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Use sender devcom for MPV master-up After PCIe DPC recovery, mlx5 reloads the affected functions and replays multiport affiliation events. In the reported failure, the first relevant device error was: pcieport 0000:10:01.1: DPC: containment event pcieport 0000:10:01.1: PCIe Bus Error: severity=Uncorrected (Fatal) pcieport 0000:10:01.1: [ 5] SDES (First) mlx5 recovered the PCI functions and resumed 0000:11:00.1. During that resume, RDMA multiport binding replayed MLX5_DRIVER_EVENT_AFFILIATION_DONE and mlx5e sent MPV_DEVCOM_MASTER_UP. The host then panicked with: BUG: kernel NULL pointer dereference, address: 0000000000000010 RIP: mlx5_devcom_comp_set_ready+0x5/0x40 [mlx5_core] RDI: 0000000000000000 Call trace included: mlx5_devcom_comp_set_ready mlx5e_devcom_event_mpv mlx5_devcom_send_event mlx5_ib_bind_slave_port mlx5r_mp_probe mlx5_pci_resume MPV devcom registration publishes mlx5e private data to the component peer list before mlx5e_devcom_init_mpv() stores the returned component device in priv->devcom. A concurrent master-up event can therefore reach a peer whose private data is visible but whose priv->devcom backpointer is still NULL. MPV_DEVCOM_MASTER_UP already carries the sender/master mlx5e private data as event_data.
Medium [CVE-2026-68226] add ioremap return check and cleanup
In the Linux kernel, the following vulnerability has been resolved: media: cx23885: add ioremap return check and cleanup Add a check for the return value of pci_ioremap_bar() in cx23885_dev_setup(). If ioremap for BAR0 fails, release the already allocated PCI memory region, decrement the device count, and return -ENODEV. This prevents a potential null pointer dereference and ensures proper cleanup on memory mapping failure. A local attacker could potentially trigger a null pointer dereference by causing the `pci_ioremap_bar()` function to fail during memory mapping in `cx23885_dev_setup()`. This vulnerability could lead to 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. Affected Red Hat products: Red Hat Enterprise Linux 7; Red Hat Enterprise Linux 8. 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-68212] Fix a possible memory leak in saa7134_video_init1
In the Linux kernel, the following vulnerability has been resolved: media: saa7134: Fix a possible memory leak in saa7134_video_init1 In saa7134_video_init1(), the return value of the first saa7134_pgtable_alloc() is not checked. If it fails, the function continues as if successful, leaving the driver with an invalid page table. Additionally, if vb2_queue_init() for the VBI queue fails after the video queue page table has been allocated, the allocated memory is not freed before returning. The second saa7134_pgtable_alloc() also lacks a return value check. Errors occur during device probing before the device is fully registered, the normal cleanup path in saa7134_finidev() is not executed, leading to memory leaks and potential use of uninitialized DMA resources. On failure of any later step, free allocated page tables to avoid memory leaks. Ensure control handlers are also released on error to prevent further resource leakage. Found by code review. During device probing, the saa7134_video_init1() function does not properly check return values from memory allocation, leading to unreleased memory and invalid page tables. A local attacker could exploit this to cause 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-772. Affected Red Hat products: Red Hat Enterprise Linux 8.
Low [CVE-2026-18503] Denial of Service via super-linear regular expression work in csv.Sniffer.sniff
Attacker-controlled CSV samples can trigger super-linear regular-expression work during dialect sniffing and consume significant CPU when applications pass unbounded input to csv. Sniffer.sniff(). A flaw was found in the `csv. This excessive processing consumes significant CPU resources, potentially leading to a Denial of Service (DoS) for applications that process unbounded input using this function. Red Hat has evaluated this issue and determined it has a Low security impact. Most applications are not affected as they use csv.reader() or csv. DictReader() directly without invoking the sniffing functionality. Red Hat severity: Low — CVSS 2.8 (CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:L). Weakness: CWE-1333. Affected Red Hat products: Red Hat Hardened Images; Exploit Intelligence; 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 AI (RHEL AI) 3; Red Hat Enterprise Linux command line assistant; Red Hat OpenShift AI (RHOAI); Red Hat OpenShift Dev Spaces; Red Hat OpenShift Virtualization 4; Self-service automation portal 2. Red Hat fixing advisory: RHSA-2026:54534, RHSA-2026:54554, RHSA-2026:57010, RHSA-2026:57660, RHSA-2026:58420. Affected products named by the advisory: Red Hat package: python3.12; Red Hat package: python36; Red Hat package: python3.9.
Low [CVE-2026-66484] GNU cpio: Path Traversal allows creating hard links outside intended directory via malicious tar archives.
GNU cpio contains a Path Traversal vulnerability in its tar archive extraction functionality. When extracting a tar archive in copy-in mode with the --no-absolute-filenames option, the extracted file name is normalized but the tar hard-link target is passed to the link_to_name function without equivalent sanitization before calling link function. A tar archive provided by an attacker, containing a hard-link entry whose linkname is set to an absolute path outside the extraction directory, can cause cpio to create a hard link to an existing file outside the intended extraction directory, breaking the expected guarantee of --no-absolute-filenames and allowing archive-controlled linkage to external files. This issue has been fixed in commit e2b9cbdd3354d2b1569b7390d1bc15c1930559ad This vulnerability, known as Path Traversal, occurs during the extraction of tar archives in copy-in mode when the `--no-absolute-filenames` option is used. An attacker could provide a specially crafted tar archive that, when extracted with this option, creates hard links pointing to files outside the intended extraction directory, potentially leading to unauthorized file modifications. Red Hat severity: Low — CVSS 3.3 (CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N). Weakness: CWE-22.
Low [CVE-2026-71391] off-by-one error via a malicious font file
GNU Emacs for Android contains an off-by-one error in the gvar table parser in src/sfnt.c. The shared-coordinate index boundary check in sfnt_vary_simple_glyph() and sfnt_vary_compound_glyph() uses a strict greater-than comparison instead of greater-than-or-equal, allowing a crafted TrueType variable font to bypass the check and trigger a heap-based out-of-bounds read via memcpy. An attacker can deliver a malicious font file via email, EWW (Emacs Web Wowser), or documents with custom faces, causing Emacs to load it. This exposes heap memory contents which can be later used to defeat ASLR. This issue was fixed in commit 95ab9ef627b212d74d321c5bbb5b56a1be7b9fbe An off-by-one error can occur when a specially crafted font file is processed due to an improper bounds check. This can cause a heap-based buffer over-read, exposing heap memory contents. To exploit this flaw, a user needs to load a malicious font file or a document with custom faces, limiting its exposure. The only security impact of this issue is an information disclosure of heap memory contents. For these reasons, this vulnerability has been rated with a low severity. Red Hat severity: Low — CVSS 3.3 (CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N). Weakness: CWE-193.
Low [CVE-2026-19411] shim/dp.c library: NULL-pointer dereference in is_removable_media_path when DevicePathToStr returns NULL
shim/dp.c library: NULL-pointer dereference in is_removable_media_path() when DevicePathToStr() returns NULL. Red Hat rates this low (CVSS 3.9). Weakness: CWE-476. Affected products named by the advisory: Red Hat Enterprise Linux 7; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9.
Advisory [CVE-2026-68199] fix OOB access from firmware ADDBA window size
In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB access from firmware ADDBA window size aggr_recv_addba_req_evt() logs a debug message when the firmware-supplied win_sz is outside [AGGR_WIN_SZ_MIN, AGGR_WIN_SZ_MAX] but does not return. The out-of-range win_sz is then used in TID_WINDOW_SZ() to compute a kzalloc size and stored in rxtid->hold_q_sz, leading to zero-size or overflowed allocations and subsequent out-of-bounds access. Clean up any previously active aggregation session for the TID first, then return early when win_sz is out of the valid range, instead of proceeding with a broken allocation size. This vulnerability allows a local attacker to cause an out-of-bounds memory access. The flaw occurs when the firmware provides an invalid window size during an ADDBA (Add Block Ack) request, leading to incorrect memory allocation. This can result in a denial of service or potentially lead to further system compromise. Red Hat severity: not rated. Weakness: CWE-787. 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.
Advisory [CVE-2026-68151] only honour the first PT_INTERP
In the Linux kernel, the following vulnerability has been resolved: binfmt_elf_fdpic: only honour the first PT_INTERP The program header scan handles PT_INTERP from a switch nested in the scan loop, so its break leaves the switch and not the loop. A binary carrying more than one PT_INTERP runs the case again and overwrites both interpreter_name and interpreter. The previous name allocation leaks and so does the previous interpreter reference, along with the write denial open_exec() took on it. The denial is never released, so the file stays unwritable for as long as the system runs. An unprivileged caller reaches this with a crafted binary and repeats it at will. binfmt_elf stops at the first PT_INTERP. Do the same here. The flaw dates back to the driver's introduction in the pre-git history tree introduced in v2.6.11 by 91808d6ebe39 ("[PATCH] FRV: Add FDPIC ELF binary format driver"). This component, which handles FDPIC ELF binaries, does not correctly process multiple `PT_INTERP` program headers. An unprivileged local attacker can exploit this by crafting a malicious binary with more than one `PT_INTERP` header. Successful exploitation leads to a resource leak where a file remains unwritable indefinitely, causing a denial of service. Red Hat severity: not rated. Weakness: CWE-772.
Advisory [CVE-2026-68359] (nzxt-smart2) Stop device IO before calling hid_hw_stop
In the Linux kernel, the following vulnerability has been resolved: hwmon: (nzxt-smart2) 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 when the `hid_hw_stop()` function is called without first stopping device input/output (IO). This could allow a local attacker to potentially cause a system crash (denial of service) or achieve arbitrary code execution. Red Hat severity: not rated. 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.
Advisory [CVE-2026-68088] add length check to response query
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: function: rndis: add length check to response query Add variable representations for BufLength and BufOffset in rndis_query_response(), and perform a length check on them. This is identical to how rndis_set_response() handles these parameters. A flaw was found in the Linux kernel's RNDIS (Remote Network Driver Interface Specification) gadget function. A missing length check for `BufLength` and `BufOffset` parameters within the `rndis_query_response()` function could allow a malicious actor to provide specially crafted input. This could lead to memory corruption, potentially resulting in a denial of service. Red Hat severity: not rated. Weakness: CWE-805. 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.
Advisory [CVE-2026-68361] (corsair-psu) Stop device IO before calling hid_hw_stop
In the Linux kernel, the following vulnerability has been resolved: hwmon: (corsair-psu) Stop device IO before calling hid_hw_stop 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 corsairpsu_probe(). If the probe operation fails after "io start" has been initiated, this race condition will result in a uaf vulnerability [1]. A race condition exists where the `hid_hw_stop()` function fails to stop device input/output (I/O) operations before memory is deallocated. This can occur during the `corsairpsu_probe()` failure path, allowing the `hid_input_report()` function to access memory that has already been freed. This use-after-free vulnerability could allow a local attacker to cause a system crash (denial of service) or potentially execute arbitrary code. Red Hat severity: not rated. Weakness: CWE-763. 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.
Advisory [CVE-2026-68303] Fix null dereference in unbind
In the Linux kernel, the following vulnerability has been resolved: drm/vc4: hvs/v3d: Fix null dereference in unbind The hvs and v3d drivers use dev_get_drvdata(master) in their unbind functions. Since the vc4-drm gets removed before its dependent drivers (vc4_hvs/vc4_v3d) the vc4_hvs_unbind/vc4_v3d_unbind functions try to get drvdata of its master and fails with a null dereference error. Use the data pointer passed to the unbind functions directly instead of dev_get_drvdata(master). This avoids using potentially freed memory. When these drivers are being removed, they attempt to access memory that has already been freed. This occurs because they try to retrieve driver data from a master device that is no longer available, leading to a null pointer dereference. A local attacker could potentially exploit this vulnerability to cause system instability or a denial of service (DoS). Red Hat severity: not rated. 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.
Advisory [CVE-2026-68179] only unlock nsm_dev on post-lock error paths
In the Linux kernel, the following vulnerability has been resolved: misc: nsm: only unlock nsm_dev on post-lock error paths nsm_dev_ioctl() jumps to the common out label even when the initial copy_from_user() fails before nsm->lock has been taken. The error path then blindly unlocks a mutex that was never acquired. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the miscdevice ioctl entry and the pre-lock copy_from_user(&raw, argp, _IOC_SIZE(cmd)) failure path by issuing NSM_IOCTL_RAW with an invalid user pointer. Lockdep reported: WARNING: bad unlock balance detected! exploit/193 is trying to release lock (&global_nsm.lock) at: nsm_dev_ioctl+0x5f/0xcf [vuln_msv] but there are no more locks to release! no locks held by exploit/193. Return immediately on the pre-lock copy_from_user() failure and keep the common unlock label for the post-lock paths only. A flaw was found in the Linux kernel's Network Shared Memory (NSM) module. A local attacker can exploit an issue in the `nsm_dev_ioctl()` function where an incorrect mutex unlock operation is performed. This occurs when an initial data copy fails, leading to an attempt to unlock a mutex that was never acquired. Successful exploitation can result in a kernel panic, causing a denial of service (DoS). Red Hat severity: not rated. Weakness: CWE-832.
Advisory [CVE-2026-68124] handle zero-length frames to prevent rx buffer overflow
In the Linux kernel, the following vulnerability has been resolved: mctp: serial: handle zero-length frames to prevent rx buffer overflow The MCTP serial receive state machine reads a frame length byte in mctp_serial_push_header() case 2 and validates it upper-bound-only: if (c > MCTP_SERIAL_FRAME_MTU) { dev->rxstate = STATE_ERR; } else { dev->rxlen = c; dev->rxpos = 0; dev->rxstate = STATE_DATA;... } A length of zero passes this check, so rxlen is set to 0 and the state machine advances to STATE_DATA. In mctp_serial_push() STATE_DATA, the incoming byte is stored and rxpos incremented before the terminator is dev->rxbuf[dev->rxpos] = c; dev->rxpos++; dev->rxstate = STATE_DATA; if (dev->rxpos == dev->rxlen) { dev->rxpos = 0; dev->rxstate = STATE_TRAILER; } With rxlen == 0 the "rxpos == rxlen" terminator can never fire (rxpos is already 1 on the first data byte), so subsequent bytes are written past the end of the fixed 74-byte rxbuf, which is the last member of the netdev private area. Every following data byte is an attacker-controlled 1-byte out-of-bounds heap write, and the overflow continues until a frame (0x7e) or escape byte resets the parser -- effectively unbounded. Reaching this requires CAP_NET_ADMIN to attach the N_MCTP line discipline and bring the resulting mctpserialN netdev up, after which the bytes arrive via the tty receive path.
Advisory [CVE-2026-68213] Return queued buffers on start_streaming failure
In the Linux kernel, the following vulnerability has been resolved: media: rtl2832_sdr: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. rtl2832_sdr_start_streaming() had multiple error paths that hit this trap: two direct early returns (-ENODEV, -ERESTARTSYS), plus six `goto err` paths covering subdev s_power, tuner setup, ADC setup, stream-buffer allocation, urb allocation, and urb submission failures. None of them returned the queued buffers. The original function had no distinct success exit and fell straight through into the err label, which previously only did mutex_unlock and "return ret". Adding queued-buffer cleanup at err must therefore be paired with an explicit success return; otherwise every successful start would also drain the buffer queue and kill streaming. Add that success return, then add rtl2832_sdr_cleanup_queued_bufs() at the err label and before each early return.
Advisory [CVE-2026-68327] Only reset hardware after BAR mapping
In the Linux kernel, the following vulnerability has been resolved: wan: wanxl: Only reset hardware after BAR mapping wanxl_pci_init_one() stores the freshly allocated card in driver data before the PLX BAR is mapped. Several early probe failures then unwind through wanxl_pci_remove_one(), including failure to allocate the coherent status area or to restore the DMA mask. wanxl_pci_remove_one() unconditionally calls wanxl_reset(), and wanxl_reset() dereferences card->plx. On those early failures card->plx is still NULL, so the error path can dereference a NULL MMIO pointer. The remaining cleanup in wanxl_pci_remove_one() already checks whether later resources were allocated. This issue was found by a static analysis checker and confirmed by manual source review. During the initialization process, an error handling path in the `wanxl_pci_remove_one()` function can lead to a null pointer dereference. This occurs when the `wanxl_reset()` function attempts to access hardware resources before they are properly mapped, specifically the `card->plx` pointer, if an early probe failure happens. A local attacker could potentially trigger this condition, leading to a system crash and a Denial of Service (DoS). Red Hat severity: not rated. Weakness: CWE-476.
Advisory [CVE-2026-68203] fix cleanup bugs in vivid_init
In the Linux kernel, the following vulnerability has been resolved: media: vivid: fix cleanup bugs in vivid_init() When platform_device_register() fails in vivid_init(), the embedded struct device in vivid_pdev has already been initialized by device_initialize(), but the failure path jumps to free_output_strings without dropping the device reference for the current platform device: vivid_init() -> platform_device_register(&vivid_pdev) -> device_initialize(&vivid_pdev.dev) -> setup_pdev_dma_masks(&vivid_pdev) -> platform_device_add(&vivid_pdev) This leads to a reference leak when platform_device_register() fails. Fix this by calling platform_device_put() before jumping to the common cleanup path. Also, the unreg_driver label incorrectly calls platform_driver_register() instead of platform_driver_unregister(), which breaks cleanup when workqueue creation fails after successful driver registration. Fix that as well. The reference leak was identified by a static analysis tool I developed and confirmed by manual review. The incorrect cleanup call was found during code inspection. This vulnerability involves two cleanup bugs within the `vivid_init()` function. Firstly, a reference leak occurs if `platform_device_register()` fails, preventing the proper release of device resources.
Advisory [CVE-2026-68285] Fix memory leak in bpf_jit_free
In the Linux kernel, the following vulnerability has been resolved: LoongArch: BPF: Fix memory leak in bpf_jit_free() When bpf_int_jit_compile() is called for subprograms, it returns early during the first pass (!prog->is_func || extra_pass is false), keeping ctx->offset alive for the subsequent extra pass. If JIT compilation fails for a later subprogram, the BPF core aborts and calls bpf_jit_free() to clean up the first subprogram. However, bpf_jit_free() fails to free jit_data->ctx.offset, which causes a memory leak of the JIT context offsets array. So fix this by adding the missing kvfree(jit_data->ctx.offset) in bpf_jit_free(). A flaw was found in the Linux kernel's BPF (Berkeley Packet Filter) JIT (Just-In-Time) compiler for the LoongArch architecture. When JIT compilation fails for a subprogram, the bpf_jit_free() function does not properly release the memory allocated for the JIT context offsets array. This oversight leads to a memory leak, which could potentially impact system stability or performance over time. Red Hat severity: not rated. 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.