Red Hat Linux Linux Kernel Vulnerabilities & Security Advisories
2150 advisories tracked · Red Hat Security Data API · 1 listed in the CISA Known Exploited Vulnerabilities catalog
Every row below is a published Red Hat Linux advisory that VulniPulse classified as Linux Kernel, with the CVEs, affected and fixed releases and exploitation status the vendor stated. Severity mix: 782 high, 1365 medium, 1 low.
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 32 official vendor sources and 160+ reviewed platform categories.
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 Linux Kernel advisories
High [CVE-2026-53264] use RCU with deferred freeing for action lifecycle
In the Linux kernel, the following vulnerability has been resolved: net/sched: act_api: use RCU with deferred freeing for action lifecycle When NEWTFILTER and DELFILTER are run concurrently it is possible to create a race with an associated action. Let's illustrate with CPU0 running NEWTFILTER and CPU1 running DELFILTER: 0: mutex_lock() 0, mutex held 1: idr_remove(idr, index) tcfa_refcnt) 0, mutex held 1: idr_remove(idr, index) 1: mutex_unlock() 1: call_rcu(&p->tcfa_rcu, tcf_action_rcu_free) tcfa_refcnt) <-- fails, refcnt already 0 1: rcu_read_unlock() <-- release so freeing can run after grace period After CPU1 calls idr_remove(), the object is no longer reachable through the IDR. CPU0's subsequent idr_find() will return NULL, and even if it still held a stale pointer, the immediate kfree()… Affected products named by the advisory: Red Hat Enterprise Linux 10.0 Extended Update Support; Red Hat Enterprise Linux 9.2 Update Services for SAP Solutions; Red Hat Enterprise Linux 9.4 Update Services for SAP Solutions; Red Hat Enterprise Linux 9.6 Extended Update Support; and 2 more. Affected products named by the advisory: Red Hat Enterprise Linux 8; Red Hat package: kernel-rt.
High [CVE-2026-53270] clear the svc scheduler ptr early on edit
In the Linux kernel, the following vulnerability has been resolved: ipvs: clear the svc scheduler ptr early on edit ip_vs_edit_service() while unbinding the old scheduler clears the svc->scheduler ptr after the scheduler module initiates RCU callbacks. This can cause packets to use the old scheduler at the time when svc->sched_data is already freed after RCU grace period. Fix it by clearing the ptr early in ip_vs_unbind_scheduler(), before the done_service method schedules any RCU callbacks. Also, if the new scheduler fails to initialize when replacing the old scheduler, try to restore the old scheduler while still returning the error code. A flaw was found in the Linux kernel's IP Virtual Server (IPVS) component. During the `ip_vs_edit_service()` operation, the `svc->scheduler` pointer is cleared too late when unbinding an old scheduler. This improper handling allows packets to access previously freed scheduler data, leading to a use-after-free vulnerability. This can result in system instability or a denial of service. Red Hat severity: Moderate — CVSS 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/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.
High [CVE-2026-53276] Fix a use-after-free of the hci_conn pointer
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Fix a use-after-free of the hci_conn pointer In iso_sock_rebind_bc(), the bis pointer is cached, then the socket lock is dropped: bis = iso_pi(sk)->conn->hcon; /* Release the socket before lookups since that requires hci_dev_lock * which shall not be acquired while holding sock_lock for proper * ordering. */ release_sock(sk); hci_dev_lock(bis->hdev); During the unlocked window, could a concurrent close() destroy the connection and free the bis structure, causing hci_dev_lock(bis->hdev) to access memory after it is freed, fix this by using the hdev reference which was safely acquired via iso_conn_get_hdev(). A local attacker with the ability to perform Bluetooth ISO socket operations could exploit a use-after-free vulnerability during a socket rebind operation. This occurs due to a race condition where a connection object's memory can be freed while still being referenced, leading to a kernel crash and a local denial of service. In some scenarios, this could potentially lead to information disclosure or integrity impacts. Red Hat severity: Moderate — CVSS 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H). Weakness: CWE-367. Affected Red Hat products: Red Hat Enterprise Linux 10. Red Hat does not currently list a fixing RHSA for this CVE.
High [CVE-2026-52924] purge outqueue on stale COOKIE-ECHO handling
In the Linux kernel, the following vulnerability has been resolved: sctp: purge outqueue on stale COOKIE-ECHO handling sctp_stream_update() is only invoked when the association is moved into COOKIE_WAIT during association setup/reconfiguration. In this path, the outbound stream scheduler state (stream->out_curr) is expected to be clean, since no user data should have been transmitted yet unless the state machine has already partially progressed. However, a corner case exists in sctp_sf_do_5_2_6_stale(): when a Stale Cookie ERROR is received, the association is rolled back from COOKIE_ECHOED to COOKIE_WAIT. In this scenario, user data may already have been queued and even bundled with the COOKIE-ECHO chunk. During the rollback, sctp_stream_update() frees the old stream table and installs a new one, but it does not invalidate stream->out_curr. As a result, out_curr may still point to a freed sctp_stream_out entry from the previous stream state. Later, SCTP scheduler dequeue paths (FCFS, RR, PRIO, etc.) rely on stream->out_curr->ext, which can lead to use-after-free once the old stream state has been released via sctp_stream_free(). Affected products named by the advisory: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9; Red Hat package: kernel-rt.
High [CVE-2026-52950] fix UAF with retry loop
In the Linux kernel, the following vulnerability has been resolved: drm/xe/dma-buf: fix UAF with retry loop Retry doesn't work here, since bo will be freed on error, leading to UAF. However, now that we do the alloc & init before the attach, we can now combine this as one unit and have the init do the alloc for us. This should make the retry safe. Reported by Sashiko. v2: Fix up the error unwind (CI) (cherry picked from commit 479669418253e0f27f8cf5db01a731352ea592e7) This Use-After-Free (UAF) vulnerability occurs due to an issue in a retry loop, where a buffer object is prematurely freed on error. An attacker could potentially exploit this to cause memory corruption, leading to system instability or, in some cases, arbitrary code execution. Red Hat severity: Important — CVSS 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H). Weakness: CWE-825. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 9. Red Hat fixing advisory: RHSA-2026:42919, RHSA-2026:45192. Affected products named by the advisory: Red Hat package: kernel-rt.
High [CVE-2026-52951] handle empty bo and UAF races
In the Linux kernel, the following vulnerability has been resolved: drm/xe/dma-buf: handle empty bo and UAF races There look to be some nasty races here when triggering the invalidate_mappings hook: 1) We do xe_bo_alloc() followed by the attach, before the actual full bo init step in xe_dma_buf_init_obj(). However the bo is visible on the attachments list after the attach. This is bad since exporter driver, say amdgpu, can at any time call back into our invalidate_mappings hook, with an empty/bogus bo, leading to potential bugs/crashes. 2) Similar to 1) but here we get a UAF, when the invalidate_mappings hook is triggered. For example, we get as far as xe_bo_init_locked() but this fails in some way. To fix this, move the attach step until after we actually have a fully set up buffer object. Note that the bo is not published to userspace until later, so not sure what the comment "Don't publish the bo until we have a valid attachment", is referring to. We have at least two different customers reporting hitting a NULL ptr deref in evict_flags when importing something from amdgpu, followed by triggering the evict flow. Affected products named by the advisory: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 9; Red Hat package: kernel-rt.
High [CVE-2026-52952] Fix WARN_ON in __iommu_group_set_domain_nofail due to reset
In the Linux kernel, the following vulnerability has been resolved: iommu: Fix WARN_ON in __iommu_group_set_domain_nofail() due to reset In __iommu_group_set_domain_internal(), concurrent domain attachments are rejected when any device in the group is recovering. This is necessary to fence concurrent attachments to a multi-device group where devices might share the same RID due to PCI DMA alias quirks, but triggers the WARN_ON in __iommu_group_set_domain_nofail(). Other IOMMU_SET_DOMAIN_MUST_SUCCEED callers in detach/teardown paths, such as __iommu_group_set_core_domain and __iommu_release_dma_ownership, should not be rejected, as the domain would be freed anyway in these nofail paths while group->domain is still pointing to it. So pci_dev_reset_iommu_done() could trigger a UAF when re-attaching group->domain. Honor the IOMMU_SET_DOMAIN_MUST_SUCCEED flag, allowing the callers through the group->recovery_cnt fence, so as to update the group->domain pointer. Instead add a gdev->blocked check in the device iteration loop, to prevent any concurrent per-device detachment. A flaw was found in the Linux kernel's Input/Output Memory Management Unit (IOMMU) subsystem, which manages how devices access system memory. Affected products named by the advisory: Red Hat Enterprise Linux 10; Red Hat package: kernel.
High [CVE-2026-52972] af_alg - Cap AEAD AD length to 0x80000000
In the Linux kernel, the following vulnerability has been resolved: crypto: af_alg - Cap AEAD AD length to 0x80000000 In order to prevent arithmetic overflows when checking the TX buffer size, cap the associated data length to 0x80000000. A flaw was found in the Linux kernel's `af_alg` cryptography module. This vulnerability involves an arithmetic overflow when processing associated data lengths during the transmit buffer size check. A remote attacker could exploit this flaw by providing a specially crafted associated data length, potentially leading to a denial of service (DoS) due to system instability. Red Hat severity: Important — CVSS 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H). Weakness: CWE-190. 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.
High [CVE-2026-52973] Drop CLONE_THREAD requirement for private default hash alloc
In the Linux kernel, the following vulnerability has been resolved: futex: Drop CLONE_THREAD requirement for private default hash alloc Currently need_futex_hash_allocate_default() depends on strict pthread semantics, abusing CLONE_THREAD. This breaks the non-concurrency assumptions when doing the mm->futex_ref pcpu allocations, leading to bugs[0] when sharing the mm in other ways; ie: BUG: KASAN: slab-use-after-free in futex_hash_put... where the +1 bias can end up on a percpu counter that mm->futex_ref no longer points at. Loosen the check to cover any CLONE_VM clone, except vfork(). Excluding vfork keeps the existing paths untouched (no overhead), and we can't race in the first place: either the parent is suspended and the child runs alone, or mm->futex_ref is already allocated from an earlier CLONE_VM. The need_futex_hash_allocate_default() function incorrectly relies on CLONE_THREAD semantics, which can lead to non-concurrency issues when memory allocations (mm->futex_ref pcpu allocations) are shared across CLONE_VM clones, excluding vfork(). This can result in a use-after-free vulnerability in futex_hash_put, a form of memory corruption. Such vulnerabilities can potentially lead to system instability or other security impacts. This vulnerability was introduced in Red Hat Enterprise Linux 9.8 and 10.2; therefore, earlier versions of RHEL are unaffected.
High [CVE-2026-52976] Fix error cleanup in xe_exec_queue_create_ioctl
In the Linux kernel, the following vulnerability has been resolved: drm/xe: Fix error cleanup in xe_exec_queue_create_ioctl() Two error handling issues exist in xe_exec_queue_create_ioctl(): 1. When xe_hw_engine_group_add_exec_queue() fails, the error path jumps to put_exec_queue which skips xe_exec_queue_kill(). If the VM is in preempt fence mode, xe_vm_add_compute_exec_queue() has already added the queue to the VM's compute exec queue list. Skipping the kill leaves the queue on that list, leading to a dangling pointer after the queue is freed. 2. When xa_alloc() fails after xe_hw_engine_group_add_exec_queue() has succeeded, the error path does not call xe_hw_engine_group_del_exec_queue() to remove the queue from the hw engine group list. The queue is then freed while still linked into the hw engine group, causing a use-after-free. Affected products named by the advisory: Red Hat Enterprise Linux 10.0 Extended Update Support; Red Hat Enterprise Linux 9.6 Extended Update Support; Red Hat package: kernel-rt.
High [CVE-2026-52987] avoid double drm_exec_fini in userq validate
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: avoid double drm_exec_fini() in userq validate When new_addition is true, amdgpu_userq_vm_validate() calls drm_exec_fini(&exec) before iterating over the collected HMM ranges and calling amdgpu_ttm_tt_get_user_pages(). If amdgpu_ttm_tt_get_user_pages() fails in that path, the code jumps to unlock_all and calls drm_exec_fini(&exec) a second time on the same exec object. drm_exec_fini() is not idempotent: it frees exec->objects and may also drop exec->contended and finalize the ww acquire context. Route that error path directly to the range cleanup once exec has already been finalized. Issue found using a prototype static analysis tool and confirmed by code review. (cherry picked from commit 2802952e4a07306da6ebe813ff1acacc5691851a) A double free vulnerability exists in the `drm/amdgpu` component within the `userq validate` function. This issue arises because the `drm_exec_fini()` function is called twice on the same execution object, which is not designed to be idempotent. An attacker could potentially exploit this to cause a denial of service or lead to unpredictable system behavior. Red Hat severity: Important — CVSS 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H). Weakness: CWE-1341. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 9.
High [CVE-2026-52989] propagate nvmet_tcp_build_pdu_iovec errors to its callers
In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: propagate nvmet_tcp_build_pdu_iovec() errors to its callers Currently, when nvmet_tcp_build_pdu_iovec() detects an out-of-bounds PDU length or offset, it triggers nvmet_tcp_fatal_error(cmd->queue) and returns early. However, because the function returns void, the callers are entirely unaware that a fatal error has occurred and that the cmd->recv_msg.msg_iter was left uninitialized. Callers such as nvmet_tcp_handle_h2c_data_pdu() proceed to blindly overwrite the queue state with queue->rcv_state = NVMET_TCP_RECV_DATA Consequently, the socket receiving loop may attempt to read incoming network data into the uninitialized iterator. Fix this by shifting the error handling responsibility to the callers. This can lead to uninitialized memory being used by subsequent operations, such as reading incoming network data into an uninitialized iterator. A remote attacker could potentially exploit this memory corruption to cause a denial of service or achieve arbitrary code execution. Red Hat severity: Moderate — CVSS 7.1 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H). Weakness: CWE-390. 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.
High [CVE-2026-52991] fix race between file release and pressure write
In the Linux kernel, the following vulnerability has been resolved: sched/psi: fix race between file release and pressure write A potential race condition exists between pressure write and cgroup file release regarding the priv member of struct kernfs_open_file, which triggers the uaf reported in [1]. Consider the following scenario involving execution on two separate CPUs: CPU0CPU1 ======== vfs_rmdir() kernfs_iop_rmdir() cgroup_rmdir() cgroup_kn_lock_live() cgroup_destroy_locked() cgroup_addrm_files() cgroup_rm_file() kernfs_remove_by_name() kernfs_remove_by_name_ns() vfs_write()__kernfs_remove() new_sync_write()kernfs_drain() kernfs_fop_write_iter()kernfs_drain_open_files() cgroup_file_write()kernfs_release_file() pressure_write()cgroup_file_release() ctx = of->priv; kfree(ctx); of->priv = NULL; cgroup_kn_unlock() cgroup_kn_lock_live() cgroup_get(cgrp) cgroup_kn_unlock() if (ctx->psi.trigger) // here, trigger uaf for ctx, that is of->priv The cgroup_rmdir() is protected by the cgroup_mutex, it also safeguards the memory deallocation of of->priv performed within cgroup_file_release(). However, the operations involving of->priv executed within pressure_write() are not entirely covered by the protection of cgroup_mutex. Affected products named by the advisory: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9; Red Hat package: kernel-rt.
High [CVE-2026-52993] fix double-free in tipc_buf_append
In the Linux kernel, the following vulnerability has been resolved: tipc: fix double-free in tipc_buf_append() tipc_msg_validate() can potentially reallocate the skb it is validating, freeing the old one. In tipc_buf_append(), it was being called with a pointer to a local variable which was a copy of the caller's skb pointer. If the skb was reallocated and validation subsequently failed, the error handling path would free the original skb pointer, which had already been freed, leading to double-free. Fix this by checking if head now points to a newly allocated reassembled skb. If it does, reassign *headbuf for later freeing operations. A flaw was found in the Linux kernel's Transparent Inter-Process Communication (TIPC) module. This vulnerability, a double-free, occurs when the `tipc_buf_append()` function incorrectly handles memory after a socket buffer (skb) reallocation. An attacker could potentially exploit this to cause system instability or a denial of service. In some scenarios, this type of memory corruption could also lead to arbitrary code execution. Red Hat severity: Important — CVSS 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H). Weakness: CWE-763. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9. Red Hat fixing advisory: RHSA-2026:47017, RHSA-2026:45116, RHSA-2026:45115, RHSA-2026:49212.
High [CVE-2026-53000] use kfree_rcu to release ops
In the Linux kernel, the following vulnerability has been resolved: netfilter: nat: use kfree_rcu to release ops Florian Westphal says: "Historically this is not an issue, even for normal base hooks: the data path doesn't use the original nf_hook_ops that are used to register the callbacks. However, in v5.14 I added the ability to dump the active netfilter hooks from userspace. This code will peek back into the nf_hook_ops that are available at the tail of the pointer-array blob used by the datapath. The nat hooks are special, because they are called indirectly from the central nat dispatcher hook. They are currently invisible to the nfnl hook dump subsystem though. But once that changes the nat ops structures have to be deferred too." Update nf_nat_register_fn() to deal with partial exposition of the hooks from error path which can be also an issue for nfnetlink_hook. A flaw was found in the Linux kernel's netfilter component, specifically within the Network Address Translation (NAT) subsystem. This vulnerability involves improper memory management when releasing network filter operation structures. This could potentially allow an attacker to cause a system crash, leading to a Denial of Service (DoS), or to gain unauthorized access to sensitive information due to the partial exposure of internal hook data during error handling.
High [CVE-2026-53002] remove sprintf usage
In the Linux kernel, the following vulnerability has been resolved: netfilter: conntrack: remove sprintf usage Replace it with scnprintf, the buffer sizes are expected to be large enough to hold the result, no need for snprintf+overflow check. Increase buffer size in mangle_content_len() while at it. BUG: KASAN: stack-out-of-bounds in vsnprintf+0xea5/0x1270 Write of size 1 at addr [..] vsnprintf+0xea5/0x1270 sprintf+0xb1/0xe0 mangle_content_len+0x1ac/0x280 nf_nat_sdp_session+0x1cc/0x240 process_sdp+0x8f8/0xb80 process_invite_request+0x108/0x2b0 process_sip_msg+0x5da/0xf50 sip_help_tcp+0x45e/0x780 nf_confirm+0x34d/0x990 [..] This vulnerability arises from the use of `sprintf` and insufficient buffer sizing in the `mangle_content_len()` function, which can lead to a stack-out-of-bounds write. An attacker could potentially exploit this memory corruption issue to cause a denial of service or other unspecified impacts. A local attacker with low privileges could trigger a stack-out-of-bounds write by sending specially crafted SIP messages, potentially leading to a denial of service or privilege escalation. This vulnerability requires the system to process SIP traffic through netfilter. Red Hat severity: Important — CVSS 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H). Weakness: CWE-787.
High [CVE-2026-53006] fix possible UAF in icmpv6_rcv
In the Linux kernel, the following vulnerability has been resolved: ipv6: fix possible UAF in icmpv6_rcv() Caching saddr and daddr before pskb_pull() is problematic since skb->head can change. Remove these temporary variables: - We only access &ipv6_hdr(skb)->saddr and &ipv6_hdr(skb)->daddr when net_dbg_ratelimited() is called in the slow path. - Avoid potential future misuse after pskb_pull() call. A flaw was found in the Linux kernel's IPv6 (Internet Protocol version 6) implementation. This vulnerability, a Use-After-Free (UAF) error, occurs due to incorrect caching of network packet addresses before a memory operation. An attacker could potentially exploit this flaw to cause memory corruption, which may lead to a denial of service or, in some scenarios, arbitrary code execution. Red Hat severity: Important — CVSS 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/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 fixing advisory: RHSA-2026:47017, RHSA-2026:47010, RHSA-2026:47011, RHSA-2026:45192. Affected products named by the advisory: Red Hat package: kernel-rt.
High [CVE-2026-53009] fix double-free of tx_buf skb
In the Linux kernel, the following vulnerability has been resolved: ice: fix double-free of tx_buf skb If ice_tso() or ice_tx_csum() fail, the error path in ice_xmit_frame_ring() frees the skb, but the 'first' tx_buf still points to it and is marked as valid (ICE_TX_BUF_SKB). 'next_to_use' remains unchanged, so the potential problem will likely fix itself when the next packet is transmitted and the tx_buf gets overwritten. But if there is no next packet and the interface is brought down instead, ice_clean_tx_ring() -> ice_unmap_and_free_tx_buf() will find the tx_buf and free the skb for the second time. The fix is to reset the tx_buf type to ICE_TX_BUF_EMPTY in the error path, so that ice_unmap_and_free_tx_buf(). Move the initialization of 'first' up, to ensure it's already valid in case we hit the linearization error path. The bug was spotted by AI while I had it looking for something else. It also proposed an initial version of the patch. I reproduced the bug and tested the fix by adding code to inject failures, on a build with KASAN. I looked for similar bugs in related Intel drivers and did not find any. A flaw was found in the Linux kernel's ice network driver. An error in the driver's handling of network packet transmission, specifically when ice_tso() or ice_tx_csum() functions fail, can lead to a double-free of a network buffer (skb).
High [CVE-2026-53016] ccp - copy IV using skcipher ivsize
In the Linux kernel, the following vulnerability has been resolved: crypto: ccp - copy IV using skcipher ivsize AF_ALG rfc3686-ctr-aes-ccp requests pass an 8-byte IV to the driver. ccp_aes_complete() restores AES_BLOCK_SIZE bytes into the caller's IV buffer while RFC3686 skciphers expose an 8-byte IV, so the restore overruns the provided buffer. Use crypto_skcipher_ivsize() to copy only the algorithm's IV length. When processing AF_ALG rfc3686-ctr-aes-ccp requests, the ccp_aes_complete() function attempts to restore more data than the allocated buffer for the Initialization Vector (IV) can hold. This leads to a buffer overrun, which can result in memory corruption within the kernel. An out-of-bounds write exists in the AMD CCP AES completion path because ccp_aes_complete() restores AES_BLOCK_SIZE bytes into req iv even when the selected skcipher exposes a shorter IV. For the CVSS the PR:L is used because a local user or local process can reach AF_ALG crypto interfaces without needing full administrator privileges when the vulnerable CCP backed algorithm is available. The issue is not network reachable and requires local code execution on a system with the affected CCP crypto driver and algorithm available. Red Hat severity: Moderate — CVSS 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H). Weakness: CWE-805.
High [CVE-2026-53071] Add missing chan lock in l2cap_ecred_reconf_rsp
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: l2cap: Add missing chan lock in l2cap_ecred_reconf_rsp l2cap_ecred_reconf_rsp() calls l2cap_chan_del() without holding l2cap_chan_lock(). Every other l2cap_chan_del() caller in the file acquires the lock first. A remote BLE device can send a crafted L2CAP ECRED reconfiguration response to corrupt the channel list while another thread is iterating it. Add l2cap_chan_hold() and l2cap_chan_lock() before l2cap_chan_del(), and l2cap_chan_unlock() and l2cap_chan_put() after, matching the pattern used in l2cap_ecred_conn_rsp() and l2cap_conn_del(). A flaw was found in the Linux kernel's Bluetooth Logical Link Control and Adaptation Protocol (L2CAP) implementation. This can lead to the corruption of the channel list, potentially causing a Denial of Service (DoS) by making the system unstable or unresponsive. The vulnerability is due to a missing channel lock when a channel is deleted. The issue is adjacent network reachable rather than Internet reachable because Bluetooth radio proximity is required. Red Hat severity: Moderate — CVSS 7.5 (CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H). Weakness: CWE-416. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9. Affected products named by the advisory: Red Hat package: kernel-rt.