Red Hat Linux Security Advisories & CVEs
15893 advisories tracked · Red Hat Security Data API · direct feeds checked every minute; rate-limited sources checked less often
Get an email when Red Hat publishes the next one.
See Red Hat's last 90 days of advisories first. Then choose one product with live alerts free for life, or a free month of real-time alerts on everything with the severity, the fixed version and the vendor's link (card needed, then US$15/month; we email you before the first charge).
iPhone and Android apps · New on the App Store
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, so 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-63877] Convert to use a platform device
In the Linux kernel, the following vulnerability has been resolved: serial: dz: Convert to use a platform device Prevent a crash from happening as the first serial port is initialised: Console: switching to colour frame buffer device 160x64 tgafb: SFB+ detected, rev=0x02 fb0: Digital ZLX-E1 frame buffer device at 0x1e000000 DECstation DZ serial driver version 1.04 CPU 0 Unable to handle kernel paging request at virtual address 000000bc, epc == 8048b3a4, ra == 80470a78 Oops[#1]: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.19.0-dirty #35 NONE $ 0: 00000000 1000ac00 00000004 804707ac $ 4: 00000000 80e20850 80e20858 81000030 $ 8: 00000000 8072c81c 00000008 fefefeff $12: 6c616972 00000006 80c5917f 69726420 $16: 80e20800 00000000 808f8968 80e20800 $20: 00000000 807f5a90 808b0094 808d3bc8 $24: 00000018 80479030 $28: 80c2e000 80c2fd70 00000069 80470a78 Hi: 00000004 Lo: 00000000 epc: 8048b3a4 __dev_fwnode+0x0/0xc ra: 80470a78 serial_base_ctrl_add+0xa0/0x168 Status: 1000ac04IEp Cause: 30000008 (ExcCode 02) BadVA: 000000bc PrId: 00000220 (R3000) Modules linked in: Process swapper/0 (pid: 1, threadinfo=(ptrval), task=(ptrval), tls=00000000) Stack: 00400044 00400040 8046f4cc 00000000 808a6148 808a0000 808f8968 8086983c 808e0000 8046fc84 1000ac01 00000028 80e20700 802ba3f8 80e20700 80d34a94 80c1b900 80e20700 80e20700 80e20700 80e20700 80444650 00000000 00000000 00000000 807f5a90…
Medium [CVE-2026-63976] clear chan->ident on ECRED reconfiguration success
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: l2cap: clear chan->ident on ECRED reconfiguration success l2cap_ecred_reconf_rsp() returns early on success without clearing chan->ident. Every other L2CAP response handler (l2cap_ecred_conn_rsp, l2cap_le_connect_rsp, l2cap_config_rsp) clears chan->ident after a successful transaction to prevent the channel from matching subsequent responses with the recycled ident value. A remote attacker that completed a reconfiguration as the peer can replay a failure response with the stale ident, causing the kernel to match and destroy the already-established channel via l2cap_chan_del(chan, ECONNRESET). Clear chan->ident for all matching channels on success, and harden the failure path by using l2cap_chan_hold_unless_zero() consistent with other L2CAP handlers (l2cap_le_command_rej, __l2cap_get_chan_by_ident). A flaw was found in the Linux kernel's Bluetooth L2CAP (Logical Link Control and Adaptation Protocol) implementation. A remote attacker, acting as a peer, could exploit a vulnerability where the system fails to clear a channel identifier after a successful Enhanced Credit Based Mode (ECRED) reconfiguration. By replaying a failure response with this stale identifier, the attacker can force the kernel to terminate an active Bluetooth connection, leading to a Denial of Service (DoS).
Medium [CVE-2026-64000] fix potential OOB access in supervision frame handling
In the Linux kernel, the following vulnerability has been resolved: net: hsr: fix potential OOB access in supervision frame handling Ensure the entire TLV header is linearized before access by adding sizeof(struct hsr_sup_tlv) to the pskb_may_pull() calls. Without this, a truncated frame could cause an out-of-bounds access. A flaw was found in the Linux kernel's High-availability Seamless Redundancy (HSR) module. The issue arises because the system does not ensure the entire TLV (Type-Length-Value) header is properly processed before memory access. This could lead to system instability or denial of service. An out of bounds read can occur in the HSR supervision frame parser because the code may access the next TLV header before the full struct hsr_sup_tlv is present and linearized in the skb. A truncated or malformed HSR supervision frame from an adjacent Layer 2 network can reach this path and may cause a kernel crash or other availability impact. For the CVSS the PR:N because an attacker only needs adjacent network reachability to an exposed HSR interface and no local account on the target. The issue is not Internet routable in normal deployments because HSR is an Ethernet redundancy protocol used mainly in local industrial or availability focused networks. Impact is at least denial of service.
Medium [CVE-2026-63972] Skip redundant detach on already-detached port
In the Linux kernel, the following vulnerability has been resolved: net: mana: Skip redundant detach on already-detached port When mana_per_port_queue_reset_work_handler() runs after a previous detach succeeded but attach failed, the port is left in a detached state with apc->tx_qp and apc->rxqs already freed. Calling mana_detach() again unconditionally leads to NULL pointer dereferences during queue teardown. Add an early exit in mana_detach() when the port is already in detached state (!netif_device_present) for non-close callers, making it safe to call idempotently. This allows the queue reset handler and other recovery paths to simply retry mana_attach() without redundant teardown. A flaw was found in the Linux kernel's mana network driver. An issue arises when the driver attempts a redundant detach operation on an already-detached network port. This can cause a null pointer dereference, leading to a system crash and a Denial of Service (DoS). Red Hat severity: Moderate. 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.
Medium [CVE-2026-63989] Fix sleep in atomic context in netlink path
In the Linux kernel, the following vulnerability has been resolved: bridge: Fix sleep in atomic context in netlink path Since the introduction of the netlink configuration path for bridge ports in commit 25c71c75ac87 ("bridge: bridge port parameters over netlink"), br_setport() was always called with the bridge lock held around it. Back then this decision made sense: The bridge lock protects the STP state of the bridge and its ports and at that time the function only processed three STP related netlink attributes (cost, priority and state). Nowadays, br_setport() processes a lot more attributes and most of them do not need the bridge lock: * Bridge flags: Only require RTNL. Read locklessly by the data path. Annotations can be added in net-next. * FDB port flushing: Only requires the FDB lock. * Multicast attributes: Only require the multicast lock. * Group forward mask: Only requires RTNL. This is a problem as the bridge calls dev_set_promiscuity() when certain bridge port flags change and this function can sleep since the commit cited below, resulting in a splat such as [1]. Affected products named by the advisory: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 6; Red Hat package: kernel.
Medium [CVE-2026-64004] fix locking in.getsockopt
In the Linux kernel, the following vulnerability has been resolved: net/iucv: fix locking in.getsockopt Mirror iucv_sock_setsockopt() and wrap the whole switch in lock_sock()/release_sock(). The pre-existing SO_MSGLIMIT-only lock becomes redundant and is removed. Any AF_IUCV HIPER user can potentially crash the kernel by racing recvmsg() with getsockopt(SO_MSGSIZE): the SO_MSGSIZE arm dereferences iucv->hs_dev->mtu after iucv_sock_close() (called from the racing recvmsg()) has set hs_dev to NULL, producing a NULL pointer dereference oops. A flaw was found in the Linux kernel's AF_IUCV (Inter-User Communication Vehicle) networking module. A local user can exploit a race condition between message reception and socket option retrieval, specifically when calling getsockopt(SO_MSGSIZE). This can lead to a null pointer dereference, causing the kernel to crash and resulting in 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-476. 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.
Medium [CVE-2026-63935] fix division by zero in write_raw
In the Linux kernel, the following vulnerability has been resolved: iio: adc: nxp-sar-adc: fix division by zero in write_raw Add a validation check for the sampling frequency value before using it as a divisor. A user writing zero or a negative value to the sampling_frequency sysfs attribute triggers a division by zero in the kernel. Also prevent unsigned integer underflow when the computed cycle count is smaller than NXP_SAR_ADC_CONV_TIME, which would wrap the u32 inpsamp to a huge value. A flaw was found in the Linux kernel's NXP SAR Analog-to-Digital Converter (ADC) module. This vulnerability can lead to a denial of service (DoS) due to the kernel crashing. Additionally, an unsigned integer underflow can occur, potentially causing unexpected system behavior. 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. Affected Red Hat products: Red Hat Enterprise Linux 10. Red Hat does not currently list a fixing RHSA for this CVE. Affected products named by the advisory: Red Hat package: kernel.
Medium [CVE-2026-63999] fix indir_table and hkey leak on get_rxfh failure
In the Linux kernel, the following vulnerability has been resolved: ethtool: rss: fix indir_table and hkey leak on get_rxfh failure rss_prepare_get() allocates the indirection table and hash key buffer via rss_get_data_alloc(), then calls ops->get_rxfh() to populate them. If get_rxfh() fails, the function returns an error without freeing the allocation. A flaw was found in the Linux kernel's ethtool subsystem, specifically within the Receive Side Scaling (RSS) functionality. The rss_prepare_get() function fails to deallocate memory for the indirection table and hash key buffer if an internal operation (ops->get_rxfh()) does not complete successfully. This memory leak can be exploited by a local attacker, potentially leading to a Denial of Service (DoS) due to resource exhaustion 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 9. 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-63930] fix use-after-free in error path
In the Linux kernel, the following vulnerability has been resolved: iio: buffer: hw-consumer: fix use-after-free in error path In the err_put_buffers cleanup path of iio_hw_consumer_alloc(), the code was using list_for_each_entry() to iterate through buffers while calling iio_buffer_put() which can free the current buffer if refcount drops to 0. The list_for_each_entry() loop macro then evaluates buf->head.next to continue iteration, accessing the freed buffer. Fix this by using list_for_each_entry_safe(). During buffer cleanup, the code incorrectly uses `list_for_each_entry()` to iterate through buffers while simultaneously freeing them, which can lead to accessing memory that has already been released. This memory corruption could result in a denial of service or potentially lead to arbitrary code execution. Red Hat severity: Moderate. 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.
Medium [CVE-2026-63881] fix a vulnerability of integer overflow in kfd debugger
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix a vulnerability of integer overflow in kfd debugger get_queue_ids() computes array_size = num_queues * sizeof(uint32_t), which could overflow on 32-bit size_t build. using array_size() instead, it saturates to SIZE_MAX on overflow. (cherry picked from commit 2d57a0475f085c08b49312dfd8edcb461845f285) A flaw was found in the Linux kernel's AMD KFD (Kernel Fusion Driver) debugger component. The `get_queue_ids()` function, responsible for handling queue identifiers, contains an integer overflow vulnerability. This occurs when calculating the size of an array, where a malicious local user could provide a large number of queues, causing the size calculation to wrap around on 32-bit systems. This could lead to a heap buffer overflow, potentially resulting in a denial of service or, in certain scenarios, privilege escalation. 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. Affected products named by the advisory: Red Hat package: kernel-rt.
Medium [CVE-2026-63915] fix out-of-bounds read in HCP header parsing
In the Linux kernel, the following vulnerability has been resolved: nfc: hci: fix out-of-bounds read in HCP header parsing Both nfc_hci_recv_from_llc() and nci_hci_data_received_cb() read packet->header from skb->data at function entry without first checking that the buffer holds at least one byte. A malicious NFC peer can send a 0-byte HCP frame that passes through the SHDLC layer and reaches these functions, causing an out-of-bounds heap read of packet->header. The same 0-byte frame, if queued as a non-final fragment, also causes the reassembly loop to underflow msg_len to UINT_MAX, triggering skb_over_panic() when the reassembled skb is written. Fix this by adding a pskb_may_pull() check at the entry of each function before packet->header is first accessed. The existing pskb_may_pull() checks before the reassembled hcp_skb is cast to struct hcp_packet remain in place to guard the 2-byte HCP message header. A flaw was found in the Linux kernel's Near Field Communication (NFC) Host Controller Interface (HCI). A remote attacker, by sending a specially crafted 0-byte Host Controller Protocol (HCP) frame, could trigger an out-of-bounds read. This could lead to a system crash, resulting in a Denial of Service (DoS). Red Hat severity: Moderate. Weakness: CWE-125.
Medium [CVE-2026-63929] Fix DMA fence leak in iio_buffer_enqueue_dmabuf
In the Linux kernel, the following vulnerability has been resolved: iio: buffer: Fix DMA fence leak in iio_buffer_enqueue_dmabuf() iio_buffer_enqueue_dmabuf() allocates a struct iio_dma_fence (104 bytes, kmalloc-128) via kmalloc_obj()+dma_fence_init(), which sets the initial kref to 1. It then calls dma_resv_add_fence() which takes a second reference (kref=2), and stores a raw pointer in block->fence. On the success path the function returns without calling dma_fence_put() to release the initial reference, so every buffer enqueue permanently leaks one kmalloc-128 allocation. The iio_buffer_cleanup() work item only releases the temporary reference taken during completion signalling by iio_buffer_signal_dmabuf_done(); the initial reference from dma_fence_init() is never released. With four iio_rwdev instances at 240kHz and 512 samples per buffer, this produces ~1875 kmalloc-128 allocations per second matching the observed slab growth exactly. A test with ftrace confirmed that the dma_fence_destroy event was never triggered. Fix by calling dma_fence_put() after dma_resv_add_fence(), transferring ownership of the fence to the DMA reservation object. The DMA fence then gets properly discarded after being signalled. The `iio_buffer_enqueue_dmabuf()` function, responsible for managing Direct Memory Access (DMA) buffers, fails to properly release a memory reference.
Medium [CVE-2026-64019] fix dma mapping leak on data setup error
In the Linux kernel, the following vulnerability has been resolved: nvme-pci: fix dma mapping leak on data setup error We're leaking the initial DMA mapping during iteration if we fail to allocate the tracking descriptor for both PRP and SGL. Unmap the iterator directly; we can't use the existing unmap helper because it depends on the tracking descriptor being successfully allocated, so a new one for an in-use iterator is provided. The mappings were also leaking when the driver detects an invalid bio_vec when mapping PRPs, so fix that too. A flaw was found in the Linux kernel's NVMe (Non-Volatile Memory Express) PCI (Peripheral Component Interconnect) driver. This vulnerability occurs due to a leak in the Direct Memory Access (DMA) mapping during data setup operations. Specifically, the system fails to properly unmap DMA resources when there are errors in allocating tracking descriptors for Physical Region Pages (PRP) and Scatter-Gather Lists (SGL), or when an invalid bio_vec is detected during PRP mapping. This can lead to resource exhaustion over time. 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 10. Red Hat does not currently list a fixing RHSA for this CVE. Affected products named by the advisory: Red Hat package: kernel.
Medium [CVE-2026-63904] check URB actual_length for interrupt-IN notifications
In the Linux kernel, the following vulnerability has been resolved: usb: usbtmc: check URB actual_length for interrupt-IN notifications USBTMC devices can use an optional interrupt endpoint for notification messages. These typically contain two-byte headers indicating the payload format, but the driver does not check if these headers are present before accessing the data buffers. In cases where the URB actual_length is not enough to fit these headers, the driver will either cause an out-of-bounds read, or consume stale leftover data from a previous notification. Fix by checking if actual_data contains enough bytes for the headers, otherwise resubmit URB to the interrupt endpoint. A flaw was found in the Linux kernel's USB Test and Measurement Class (USBTMC) driver. This vulnerability occurs because the driver does not properly verify the size of incoming notification messages, specifically failing to ensure that required two-byte headers are present. An attacker could exploit this by sending malformed USBTMC messages, potentially leading to an out-of-bounds read. This could result in a system crash (Denial of Service) or the disclosure of sensitive information. This vulnerability is evaluated as Moderate because successful exploitation requires local access or the connection of a specialized, malformed USB device, limiting the attack scope primarily to a local system crash.
Medium [CVE-2026-64003] Run queues for all non-SDEV_DEL devices from scsi_run_host_queues
In the Linux kernel, the following vulnerability has been resolved: scsi: core: Run queues for all non-SDEV_DEL devices from scsi_run_host_queues While a SCSI host is in a recovery state, scsi_mq_requeue_cmd() will not set the requeue list for a requeued command to be kicked in the future. However, scsi_run_host_queues() uses shost_for_each_device() which uses scsi_device_get() and so will ignore devices in a partially removed state like SDEV_CANCEL. But these devices may also have requeued requests, leaving their requests stuck from not being kicked and causing the removal process of the device to hang. scsi_run_host_queues() needs to run against more devices than the macro shost_for_each_device() allows. Instead of using the too limiting scsi_device_get() state checks, only ignore devices in SDEV_DEL state or when unable to acquire a reference. A flaw was found in the Linux kernel's SCSI (Small Computer System Interface) core. During a SCSI host recovery, the `scsi_run_host_queues()` function may incorrectly ignore devices that are in a partially removed state. This oversight can cause pending requests for these devices to become stuck, leading to a hang in the device removal process. The primary consequence is a Denial of Service (DoS), as affected devices cannot be properly removed from the system.
Medium [CVE-2026-63963] validate VDO count in Discover Identity ACK handlers
In the Linux kernel, the following vulnerability has been resolved: usb: typec: tcpm: validate VDO count in Discover Identity ACK handlers Properly validate the count passed from a device when calling svdm_consume_identity() or svdm_consume_identity_sop_prime() as the device-controlled value could index off of the static arrays, which could leak data. A flaw was found in the Linux kernel's USB Type-C subsystem. A malicious or malformed USB Type-C device could send an invalid Vendor Defined Object (VDO) count during the Discover Identity Acknowledgement (ACK) process. This improper validation could allow the device to read beyond the intended memory boundaries, potentially leading to information disclosure from the kernel. This vulnerability is rated as Moderate severity for Red Hat Enterprise Linux because exploitation requires physical access to attach a specialized or compromised USB Type-C peripheral to the target host. In standard enterprise server environments, physical access controls significantly limit overall exposure. When an untrusted device negotiates power delivery identity parameters, out-of-bounds kernel memory reads can occur, exposing sensitive information without causing host disruption or granting unauthorized code execution. Weakness: CWE-125. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9.
Medium [CVE-2026-63973] Add NULL guards in teardown path to prevent panic on attach failure
In the Linux kernel, the following vulnerability has been resolved: net: mana: Add NULL guards in teardown path to prevent panic on attach failure When queue allocation fails partway through, the error cleanup frees and NULLs apc->tx_qp and apc->rxqs. Multiple teardown paths such as mana_remove(), mana_change_mtu() recovery, and internal error handling in mana_alloc_queues() can subsequently call into functions that dereference these pointers without NULL checks: - mana_chn_setxdp() dereferences apc->rxqs[0], causing a NULL pointer dereference panic (CR2: 0000000000000000 at mana_chn_setxdp+0x26). - mana_destroy_vport() iterates apc->rxqs without a NULL check. - mana_fence_rqs() iterates apc->rxqs without a NULL check. - mana_dealloc_queues() iterates apc->tx_qp without a NULL check. Add a NULL guard for apc->tx_qp in mana_dealloc_queues() to skip TX queue draining when TX queues were never allocated or already freed. A flaw was found in the Linux kernel's mana network driver. During certain error handling scenarios, specifically when network queue allocation fails, the driver attempts to access memory that has already been freed. This can lead to a NULL pointer dereference, causing the system to crash and 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.
Medium [CVE-2026-63997] avoid leaking a netdev ref on module flash errors
In the Linux kernel, the following vulnerability has been resolved: ethtool: module: avoid leaking a netdev ref on module flash errors module_flash_fw_schedule() is missing undo for setting the "in_progress" flag and taking the netdev reference. Delay taking these, the device can't disappear while we are holding rtnl_lock. This oversight can lead to a resource leak, preventing the device from being properly released while the `rtnl_lock` is held, potentially causing a denial of service. 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.
Medium [CVE-2026-64028] Avoid NULL return from hist_field_name on truncation
In the Linux kernel, the following vulnerability has been resolved: tracing: Avoid NULL return from hist_field_name() on truncation hist_field_name() returns "" everywhere except the fully-qualified VAR_REF/EXPR case, where snprintf() truncation returns NULL early and bypasses the bottom NULL->"" guard. Callers don't expect NULL: strcat(expr, hist_field_name(field, 0)) at trace_events_hist.c:1758 and the strcmp() in the sort-key match loop at:4804 both deref it. system and event_name are bounded by MAX_EVENT_NAME_LEN, but the field name on a VAR_REF is kstrdup'd from a histogram variable name parsed out of the trigger string and has no length cap, so a long enough var name in a fully qualified reference can reach the truncation path. Keep the length check but leave field_name as "" on overflow. The `hist_field_name()` function, responsible for handling field names, can return a NULL value if a long variable name in a fully-qualified reference causes `snprintf()` truncation. This unexpected NULL return can lead to a NULL pointer dereference when other functions attempt to use the returned value, potentially causing a system crash and 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.
Medium [CVE-2026-64016] fix durable reconnect error path file lifetime
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix durable reconnect error path file lifetime After a durable reconnect succeeds, ksmbd_reopen_durable_fd() republishes the same ksmbd_file into the session volatile-id table. If smb2_open() then takes a later error path, cleanup first calls ksmbd_fd_put(work, fp) and then unconditionally calls ksmbd_put_durable_fd(dh_info.fp). In this case fp and dh_info.fp are the same object. The first put drops the reconnect lookup reference, but the final durable put can run __ksmbd_close_fd(NULL, fp). Because the final close is not session-aware, it can free the file object without removing the volatile-id entry that was just published into the session table. Use the session-aware put for the final reconnect drop when the reconnect had already succeeded and the error path is cleaning up the republished file. Earlier reconnect failures, before fp is assigned to dh_info.fp, keep using the durable-only put path. A flaw was found in the Linux kernel's ksmbd component, which handles file sharing. When a durable network connection is re-established, an error in managing the lifetime of file objects can occur. This can lead to a situation where a file object is released from memory while still being referenced, creating a use-after-free vulnerability.
Free weekly CVE digest
Every Monday: the week's critical and high advisories for Red Hat or every vendor, new CISA KEV entries and upcoming end-of-life dates.