Skip to content
VulniPulse

Red Hat Linux Security Advisories & CVEs

5847 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

Medium5.5Vendor: LowRed Hat

Medium [CVE-2026-74559] drain continuation descs after overflow in xsk_build_skb

In the Linux kernel, the following vulnerability has been resolved: xsk: drain continuation descs after overflow in xsk_build_skb() Fix generic xmit path multi-buffer logic when packets are either too big (count of descriptors exceed MAX_SKB_FRAGS) or an invalid descriptor is included in fragmented packet. Introduce xdp_sock::drain_cont and act upon this flag - when it is set, keep on consuming descriptors from AF_XDP Tx ring and put them directly onto Cq. Previously these descriptors were silently lost and could never be reached again. A flaw was found in the Linux kernel's AF_XDP (eXpress Data Path) networking component. This vulnerability, located in the `xsk_build_skb()` function, involves improper handling of network packet descriptors. When processing large or malformed multi-buffer packets, the system fails to properly drain continuation descriptors after an overflow, leading to their silent loss. An attacker could exploit this issue by sending specially crafted packets, resulting in a denial of service that impacts network communication. 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 9. Red Hat does not currently list a fixing RHSA for this CVE. Affected products named by the advisory: Red Hat package: kernel-rt.

CVE-2026-74559
Linux Kernel
Aug 15, 2026
Medium5.5Vendor: LowRed Hat

Medium [CVE-2026-74495] Fix leak in TX DMA error cleanup

In the Linux kernel, the following vulnerability has been resolved: igbvf: Fix leak in TX DMA error cleanup If an error is encountered while mapping TX buffers, the driver should unmap any buffers already mapped for that skb. Because count is incremented before each frag mapping, it will always match the correct number of unmappings needed when dma_error is reached. Decrementing count before the while loop in dma_error causes an off-by-one error. If any mapping was successful before an unsuccessful mapping, exactly one DMA mapping (the head) would leak. This bug was introduced by a 2010 fix for an endless loop in dma_error. All other affected drivers have already been fixed. An off-by-one error during the cleanup of transmit (TX) Direct Memory Access (DMA) buffer mappings can lead to a memory leak. If an error occurs while mapping TX buffers, one DMA mapping may not be properly unmapped, potentially impacting system stability or performance over time. 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 7; 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.

CVE-2026-74495
Linux Kernel
Aug 15, 2026
Medium5.5Red Hat

Medium [CVE-2026-74481] use system_freezable_wq to fix UAF during suspend

In the Linux kernel, the following vulnerability has been resolved: mm/page_reporting: use system_freezable_wq to fix UAF during suspend During PM freeze (e.g. S3 suspend or S4 hibernation), device drivers like virtio_balloon reset their underlying virtio devices and delete their virtqueues via vdev->config->del_vqs(). However, page reporting work (page_reporting_process) was scheduled on the global system_wq. Because system_wq lacks the WQ_FREEZABLE flag, the PM freezer skips it, leaving page_reporting_process active during suspend. If pages are freed into the buddy allocator while suspending (for example, when core MM invokes the balloon shrinker during S4 hibernation image saving), page reporting triggers virtballoon_free_page_report() on deleted virtqueues, resulting in a Use-After-Free / General Protection Fault: [ 196.795226] general protection fault, probably for non-canonical address 0xaa1436fe70dae6df: 0000 [#1] SMP NOPTI [ 196.825967] Workqueue: events page_reporting_process [ 196.831038] RIP: 0010:virtqueue_add_split+0x233/0x4c0 [virtio_ring] [ 196.927073] virtballoon_free_page_report+0x3a/0xe0 [virtio_balloon] [ 196.946943] page_reporting_process+0x370/0x4f0 Fix this by switching page reporting work to system_freezable_wq. This ensures that the PM freezer pauses page_reporting_process before device drivers destroy their reporting virtqueues.

CVE-2026-74481
Linux Kernel
Aug 15, 2026
Medium5.5Vendor: LowRed Hat

Medium [CVE-2026-74571] skip global block reserve accounting for rescue mounts

In the Linux kernel, the following vulnerability has been resolved: btrfs: skip global block reserve accounting for rescue mounts [BUG] Mounting with rescue=ibadroots after corrupting the block group tree root triggers a NULL pointer dereference: BUG: kernel NULL pointer dereference, address: 0000000000000100 RIP: 0010:btrfs_update_global_block_rsv+0x9d/0x1c0 [btrfs] Call Trace: fill_dummy_bgs+0xd4/0x120 [btrfs] open_ctree+0xc6e/0x1ca0 [btrfs] btrfs_get_tree+0x50d/0xa40 [btrfs] The same crash occurs with a corrupted raid stripe tree root, via btrfs_read_block_groups() instead of fill_dummy_bgs(). [CAUSE] With rescue=ibadroots, btrfs_read_roots() allows the mount to continue when either root cannot be read, leaving the corresponding root pointer NULL while its on-disk feature bit remains set. btrfs_update_global_block_rsv() then dereferences the missing root based on the feature bit alone. [FIX] Rescue mounts are fully read-only and cannot start transactions, so the global reserve is never consumed. Under btrfs_is_full_ro(), mark the reserve as full and return before performing the accounting. And since we need to check if the fs is mount fully RO, export fs_is_full_ro() as btrfs_is_full_ro(), and move it to fs.h. [ Squash the fs_is_full_ro() export commit into this one. ] This vulnerability can cause a system crash, resulting in a Denial of Service (DoS).

CVE-2026-74571
Linux Kernel
Aug 15, 2026
Medium5.5Red Hat

Medium [CVE-2026-74458] kvaser_usb_leaf_wait_cmd: validate received command extents

In the Linux kernel, the following vulnerability has been resolved: can: kvaser_usb_leaf: kvaser_usb_leaf_wait_cmd(): validate received command extents The wait and bulk receive paths walk variable-length commands from a USB buffer. A nonzero command shorter than CMD_HEADER_LEN can still be dispatched, and the wait path copies a matching command into a fixed caller-owned struct kvaser_cmd using the device-provided length. Reject nonzero commands that do not contain the fixed header or that extend beyond the current USB buffer item. In the wait path, also reject a matching command that exceeds the destination before copying it. This vulnerability occurs due to insufficient validation of received command lengths from a USB buffer. A malicious or malformed command shorter than the expected header length, or one that exceeds the destination buffer, can be processed. This could lead to a buffer overflow, potentially causing a denial of service or other 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-120. 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.

CVE-2026-74458
Linux Kernel
Aug 15, 2026
Medium5.5Red Hat

Medium [CVE-2026-74473] use pskb_network_may_pull in route_shortcircuit

In the Linux kernel, the following vulnerability has been resolved: vxlan: use pskb_network_may_pull() in route_shortcircuit() route_shortcircuit() currently calls pskb_may_pull(skb, sizeof(struct iphdr)) (or ipv6hdr), which checks if bytes are available starting from skb->data. However, in vxlan_xmit(), skb->data points to the MAC header, so skb_network_offset(skb) is ETH_HLEN (14 bytes). Using pskb_may_pull(skb, 20) only checks 20 bytes from skb->data (which is 14 bytes MAC header + 6 bytes of IP header), leaving the rest of the IP header potentially un-pulled in non-linear frags. Subsequent dereferences of ip_hdr(skb)->daddr can read beyond the pulled linear buffer length. Fix this by using pskb_network_may_pull(), which adds skb_network_offset(skb) to the length check to ensure the full network header is present in the linear buffer. A flaw was found in the Linux kernel's Virtual Extensible LAN (VXLAN) implementation. An incorrect buffer length check in the `route_shortcircuit()` function, specifically when using `pskb_may_pull()`, can lead to reading beyond the allocated buffer length. This occurs when processing IP headers in non-linear network packet fragments. This vulnerability could potentially allow an attacker to access sensitive information or cause a denial of service. 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).

CVE-2026-74473
Linux Kernel
Aug 15, 2026
Medium5.5Red Hat

Medium [CVE-2026-74512] fix potential use-after-free in audit_del_rule

In the Linux kernel, the following vulnerability has been resolved: audit: fix potential use-after-free in audit_del_rule() `audit_del_rule()` destroys `e->rule.exe` via `audit_remove_mark_rule()` before unlinking the rule from RCU-visible filter lists and waiting for a grace period. Concurrent readers in `audit_filter()` and `audit_filter_rules()` still dereference `e->rule.exe`, while the fsnotify mark can be freed on an independent lifetime path. This creates a use-after-free window during rule deletion. This ensures that all existing RCU readers have exited the critical section before any underlying resources are destroyed. During the deletion of audit rules, the `audit_del_rule()` function prematurely frees a resource while other kernel functions can still access it. This creates a use-after-free vulnerability, which a local attacker could potentially exploit to cause system instability, information disclosure, or potentially escalate privileges. 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 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.

CVE-2026-74512
Linux Kernel
Aug 15, 2026
Medium5.5Vendor: LowRed Hat

Medium [CVE-2026-74526] Fix potential deadlock in mpi3mr_fault_uevent_emit

In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Fix potential deadlock in mpi3mr_fault_uevent_emit mpi3mr_fault_uevent_emit() runs from the fault watchdog and reset paths where host I/O may already be blocked. GFP_KERNEL allocations here, both the local kzalloc_obj() and the ones inside kobject_uevent_env() itself, can trigger reclaim that waits on that blocked I/O and deadlock. Use memalloc_noio_save()/restore() to cover the whole call instead of just the local allocation. When the `mpi3mr_fault_uevent_emit()` function is called from fault watchdog or reset paths, memory allocation requests can trigger a reclaim process. This reclaim process may then wait on host I/O that is already blocked, leading to a system deadlock. This can result 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-833. 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.

CVE-2026-74526
Linux Kernel
Aug 15, 2026
Medium5.5Red Hat

Medium [CVE-2026-74482] unlock i_mmap_rwsem before releasing after-split folios

In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: unlock i_mmap_rwsem before releasing after-split folios __folio_split() keeps dereferencing the mapping after the split: shmem_uncharge(mapping->host) and remap_page() while the folios are still frozen/locked, and i_mmap_unlock_read(mapping) at the very end, after the after-split folios have been unlocked and freed. Nothing holds an inode reference across that. The split relies on @folio -- which the beyond-EOF drop loop never removes, as it starts at folio_next(folio) -- staying locked and in the page cache to hold off eviction. But the unlock loop unlocks @folio before i_mmap_unlock_read() runs. This is now a rule the split depends on, alongside keeping @folio frozen until the page cache is updated: no inode or mapping dereference once the after-split folios start being unlocked. A flaw was found in the Linux kernel's huge memory management (mm/huge_memory). A race condition exists in the `__folio_split()` function where the `i_mmap_rwsem` lock is released prematurely before all after-split folios are fully processed. This allows a concurrent operation to free the inode while subsequent memory management operations attempt to access it, leading to a use-after-free vulnerability. This can result in system instability or a denial of service.

CVE-2026-74482
Linux Kernel
Aug 15, 2026
Medium5.5Red Hat

Medium [CVE-2026-74521] use memcmp to compare ClientGUIDs

In the Linux kernel, the following vulnerability has been resolved: ksmbd: use memcmp() to compare ClientGUIDs ClientGUID is a fixed-size binary value and can contain embedded NUL bytes. strncmp() stops comparing at the first NUL byte, so different ClientGUID values can incorrectly be treated as equal. Use memcmp() in SMB3 multichannel session binding and FSCTL_VALIDATE_NEGOTIATE_INFO to compare all SMB2_CLIENT_GUID_SIZE bytes. A flaw was found in ksmbd, a Linux kernel module that provides an in-kernel Server Message Block (SMB) server. This vulnerability stems from a logic error in how ClientGUIDs, which are unique client identifiers, are compared. This could lead to misidentification of clients during SMB3 multichannel session binding and validation, potentially impacting session integrity. 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-1025. 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.

CVE-2026-74521
Unclassified
Aug 15, 2026
Medium5.5Vendor: LowRed Hat

Medium [CVE-2026-74514] Fix memory accounting for pinned/unpinned pages

In the Linux kernel, the following vulnerability has been resolved: KVM: s390: pci: Fix memory accounting for pinned/unpinned pages The account_mem() and unaccount_mem() functions call get_uid() which increments the reference count of struct user_struct on every invocation. But we don't decrement the count by calling free_uid(). It also accounted/unaccounted the pages against the current->mm. But its possible the unaccount_mem() can be called from a different process context than the one that originally pinned the pages. Let's fix this by storing the pinning process user_struct and mm_struct when accounting for pinned pages, and subsequently free these resources when the pages are unpinned. [borntraeger@linux.ibm.com: Fixed whitespace] A flaw was found in the KVM (Kernel-based Virtual Machine) s390 PCI component. Incorrect memory accounting in the `account_mem()` and `unaccount_mem()` functions, specifically related to the handling of pinned and unpinned pages, can lead to a resource leak. This occurs because the reference count for user structures is not properly decremented, and memory accounting might be performed in a different process context than the one that originally pinned the pages. This issue could potentially lead to resource exhaustion, resulting in a Denial of Service (DoS) for the system.

CVE-2026-74514
Linux Kernel
Aug 15, 2026
Medium5.5Red Hat

Medium [CVE-2026-74453] Zero the tile state data array before each BIN job

In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Zero the tile state data array before each BIN job The binner BO is a single 16MB buffer split into 512KB slots that are handed out to jobs at submission time and recycled as jobs complete, without ever being cleared. Each slot holds the job's Tile State Data Array (TSDA) at its start, followed by the tile allocation pool. While the tile allocation pool is only walked by the render thread through branches the binner generated during the current job, the TSDA is the PTB's own per-tile bookkeeping and is consumed by the hardware itself. Although the kernel sets the "Auto-initialise Tile State Data Array" flag in the tile binning mode configuration, the PTB demonstrably still acts on stale tile state left by the slot's previous user: the binner ends up creating invalid command streams with invalid primitive streams and branches, which can cause GPU hangs as observed in [1][2]. Zero the TSDA when the job's binning slot is configured. This clears 48 bytes per tile (~24KB for a 1080p frame) in the submission path, and guarantees the PTB never sees another job's tile state. The tile count is only checked for being non-zero today, so the 8-bit fields it comes from can describe a tile state array almost six times larger than the slot it has to live in.

CVE-2026-74453
Unclassified
Aug 15, 2026
Medium5.5Red Hat

Medium [CVE-2026-74450] fix pptable use-after-free

In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: fix pptable use-after-free amdgpu_dpm_get_pp_table() returns a pointer to a driver-owned power table after dropping adev->pm.mutex. The sysfs path then copies from that pointer. A concurrent pp_table write can replace and free the allocation during the copy, causing a use-after-free. Change the DPM interface to copy into caller-provided storage while the mutex is held. Keep the size-only query for attribute discovery without exposing the driver-owned pointer. (cherry picked from commit f6eed7acfd30099ef7baeb6ba45bb59daad80631) A flaw was found in the Linux kernel's AMD GPU power management component. This vulnerability, known as a use-after-free, occurs when the system attempts to access memory that has already been released. A local attacker could potentially exploit this flaw to cause a system crash (denial of service) or, in more severe scenarios, execute arbitrary code with elevated privileges. 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 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.

CVE-2026-74450
Linux Kernel
Aug 15, 2026
Medium5.5Red Hat

Medium [CVE-2026-74477] Fix NULL pointer dereference in hprobe_expire

In the Linux kernel, the following vulnerability has been resolved: uprobes: Fix NULL pointer dereference in hprobe_expire() Forking a task that has a pending uretprobe can oops the kernel with a NULL pointer dereference in the clone() path: BUG: kernel NULL pointer dereference, address: 0000000000000018 Oops: 0002 [#1] SMP NOPTI RIP: 0010:hprobe_expire CR2: 0000000000000018 Call Trace: uprobe_copy_process copy_process kernel_clone __x64_sys_clone do_syscall_64 entry_SYSCALL_64_after_hwframe This was found on real hosts on Meta fleet. I've got the impression that this is what is happening: CPU 1 CPU 2 (traced task) ----- ------------------- hit uprobe, prepare_uretprobe(): hprobe LEASED, refcount >= 1 uprobe_unregister() put_uprobe(): refcount -> 0 fork() -> dup_utask() hprobe_expire(hprobe, true) try_get_uprobe() -> NULL get_uprobe(NULL) <-- Oops Only take the extra reference when the uprobe is non-NULL; a NULL means it is gone and is the correct value to return. A local attacker could exploit a race condition by forking a task with a pending uretprobe while another CPU unregisters the uprobe. This could lead to a NULL pointer dereference in the hprobe_expire() function, causing a kernel oops and resulting in a system crash, effectively a denial of service. 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.

CVE-2026-74477
Unclassified
Aug 15, 2026
Medium5.5Vendor: LowRed Hat

Medium [CVE-2026-74536] fix leaking sk after socket release

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: fix leaking sk after socket release iso_sock_kill() tests!sock_flag(sk, SOCK_ZAPPED) || sk->sk_socket || sock_flag(sk, SOCK_DEAD) for early return, but this is always true since sock_orphan(sk) sets SOCK_DEAD, so the sk reference released by socket always leaks, iso_sock_destruct is never called. The socket reference also leaks when __iso_sock_close() does not set SOCK_ZAPPED, since iso_conn_del() does not call iso_sock_kill() after zapping. Fix by replacing SOCK_DEAD by BT_SK_KILLED flag that is not used for something else, and lock_sock to ensure iso_sock_kill() puts sk only after socket release only once. Release and iso_conn_del may run concurrently. Remove call to iso_sock_kill() from iso_sock_close(), as it's generally no-op there. This vulnerability occurs due to an issue in how socket references are managed after a socket is released, specifically within the `iso_sock_kill()` and `__iso_sock_close()` functions. This improper handling leads to a memory leak, which a local attacker could exploit to exhaust system resources and cause 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-911. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 9.

CVE-2026-74536
Linux Kernel
Aug 15, 2026
Medium5.5Red Hat

Medium [CVE-2026-74460] validate CPC message lengths

In the Linux kernel, the following vulnerability has been resolved: can: ems_usb: validate CPC message lengths ems_usb_read_bulk_callback() walks CPC messages packed in one USB receive buffer. Check that each declared message fits in the URB payload. Also require the type-specific payload to cover the fields used by the CAN, state, error and overrun handlers. This vulnerability occurs because the `ems_usb_read_bulk_callback()` function, which processes Controller Area Network (CAN) Protocol Converter (CPC) messages from a USB receive buffer, does not properly validate the lengths of these messages. An attacker could exploit this by sending specially crafted CPC messages, potentially leading to a denial of service due to a format error when processing the malformed data. 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-130. 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.

CVE-2026-74460
Linux Kernel
Aug 15, 2026
Medium5.5Red Hat

Medium [CVE-2026-74532] Validate length before parsing diagnostics TLV

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btintel: Validate length before parsing diagnostics TLV btintel_diagnostics() accesses tlv->val[0] without first validating that the diagnostics VSE is long enough to contain that field, so may cause reading data beyond the received frame. The `btintel_diagnostics()` function fails to validate the length of a diagnostics Vendor Specific Event (VSE) before accessing its data. This oversight allows an attacker to potentially read data beyond the intended memory boundary, which could lead to 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-125. 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.

CVE-2026-74532
Linux Kernel
Aug 15, 2026
Medium5.5Red Hat

Medium [CVE-2026-74497] Clamp frame size in implicit-feedback mode

In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Clamp frame size in implicit-feedback mode snd_usb_handle_sync_urb() scales received sync packet sizes by the sender's stride and stores the result directly in out_packet->packet_size[i]. If a connected USB device sends an oversized sync packet, this frame count can exceed ep->maxframesize. The un-clamped frame count then propagates to the playback endpoint queue, potentially driving packet transfers beyond the endpoint's hardware frame limits. Cap the calculated frame count against ep->maxframesize in snd_usb_handle_sync_urb() to prevent oversized packets from entering the playback queue. A flaw was found in the Linux kernel's ALSA (Advanced Linux Sound Architecture) USB audio subsystem. A connected USB device could send oversized synchronization packets, causing the system to process data beyond its hardware limits. This could lead to a denial of service (DoS) 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-787. 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.

CVE-2026-74497
Linux Kernel
Aug 15, 2026
Medium5.5Red Hat

Medium [CVE-2026-74505] Fix UAF at error handling during probe

In the Linux kernel, the following vulnerability has been resolved: ALSA: 6fire: Fix UAF at error handling during probe Although 6fire driver had a few fixes for dealing with the early error handling during the probe phase, it forgot a pending URB before freeing the resources, which may lead to a UAF. This patch addresses it by doing the almost same cleanup procedure like the normal disconnect phase at the error path. This oversight could lead to a Use-After-Free (UAF) vulnerability. A local attacker could potentially exploit this to cause a system crash (denial of service) or, in some scenarios, execute arbitrary code. 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 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.

CVE-2026-74505
Linux Kernel
Aug 15, 2026
Medium5.5Red Hat

Medium [CVE-2026-74461] Cancel hrtimer before clearing slave pointer

In the Linux kernel, the following vulnerability has been resolved: i2c: imx: Cancel hrtimer before clearing slave pointer In i2c_imx_unreg_slave(), the slave pointer is set to NULL after disabling interrupts. However, a pending interrupt might already have started the hrtimer (i2c_imx_slave_timeout) before the pointer was cleared. If the hrtimer fires after i2c_imx->slave is set to NULL, the timer callback i2c_imx_slave_finish_op() will call i2c_imx_slave_event() with a NULL slave pointer, which results in a use-after-free / NULL pointer dereference. Fix by canceling the hrtimer and waiting for it to complete after disabling interrupts, before clearing the slave pointer. A flaw was found in the Linux kernel, specifically within the i2c: imx driver. This vulnerability occurs due to a timing issue during device unregistration, where a critical pointer is cleared before a related timer is properly canceled. This can lead to a system crash, potentially allowing a local attacker to cause a denial of service. 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 does not currently list a fixing RHSA for this CVE. Affected products named by the advisory: Red Hat package: kernel-rt.

CVE-2026-74461
Linux Kernel
Aug 15, 2026

← All vendors