Red Hat Linux Security Advisories & CVEs
12445 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-72011] Add missing array_index_nospec call to memtop_get_page_count
In the Linux kernel, the following vulnerability has been resolved: s390/diag: Add missing array_index_nospec() call to memtop_get_page_count() 'level' is user space controlled and used to read from an array. A local user could exploit a missing bounds check when handling a user-controlled 'level' variable, which is used to read from an array. This vulnerability could lead to information disclosure through speculative execution, potentially allowing an attacker to access sensitive data. A flaw of low impact was found in the Linux kernel's s390/diag310 memory topology handling (arch/s390/kernel/diag/diag310.c), used on the s390x (IBM zSystems) architecture. In memtop_get_page_count(), a user-space controlled 'level' value is used as an index into an array; although the value is architecturally bounds checked, the missing array_index_nospec() call allows speculative out-of-bounds reads. A local, unprivileged attacker could use this to establish a Spectre v1 style side channel and potentially disclose sensitive kernel memory contents. Red Hat rates the impact of this flaw as Low because it is not network reachable, requires the ability to run code locally, and provides only a limited and hard-to-exploit speculative disclosure primitive with no expected integrity or availability impact.
Medium [CVE-2026-72490] fix stainfo check in rtw_aes_decrypt
In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix stainfo check in rtw_aes_decrypt The null-pointer-guard was incorrect, returning _FAIL on valid pointer. Invert the guard, so it returns _FAIL on invalid pointer. An incorrect null-pointer guard in the `rtw_aes_decrypt` function could lead to the system misinterpreting memory addresses. This issue may result in a system crash, causing a Denial of Service (DoS). A moderate-impact flaw was found in the Linux kernel's rtl8723bs Wi-Fi driver, in the rtw_aes_decrypt function in drivers/staging/rtl8723bs/core/rtw_security.c. The null-pointer guard for the station-information pointer was inverted, returning a failure code for a valid pointer while continuing to process an invalid one. This could cause the system to misinterpret memory addresses and crash, resulting in a denial of service. Red Hat rates this flaw as Moderate severity with a CVSS 3.1 score of 5.5 (AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H), reflecting a local attack vector that requires privileges and impact limited to availability.
Medium [CVE-2026-72189] fail attrlist updates when the superblock is inactive
In the Linux kernel, the following vulnerability has been resolved: ntfs: fail attrlist updates when the superblock is inactive generic_shutdown_super() clears SB_ACTIVE before evicting cached inodes. If eviction selects the fake inode for a base inode's unnamed $ATTRIBUTE_LIST attribute, ntfs_evict_big_inode() drops the fake inode's reference on the base inode while the fake inode is still hashed and marked I_FREEING. That iput can synchronously write back the base inode. The writeback path may update mapping pairs and call ntfs_attrlist_update(), which unconditionally calls ntfs_attr_iget() for the same $ATTRIBUTE_LIST fake inode. VFS then finds the I_FREEING inode and waits for eviction to finish, but the current task is still inside that eviction path, causing a self-deadlock in find_inode(). Fix this by mirroring the teardown guard used by __ntfs_write_inode(): once SB_ACTIVE has been cleared, do not try to iget the attribute-list fake inode. Return -EIO so teardown aborts the update instead of waiting on the inode it is evicting. A flaw was found in the Linux kernel's NTFS file system. During the process of shutting down a file system, a specific internal condition can arise where the system attempts to update an attribute list while an associated inode is being evicted.
Medium [CVE-2026-72068] Use u64 multiplication in update_rlimit_cpu
In the Linux kernel, the following vulnerability has been resolved: posix-cpu-timers: Use u64 multiplication in update_rlimit_cpu() update_rlimit_cpu() converts the RLIMIT_CPU value to nanoseconds with u64 nsecs = rlim_new * NSEC_PER_SEC; On 32-bit kernels both rlim_new (unsigned long) and NSEC_PER_SEC (1000000000L) are 32-bit, so the multiplication is performed in unsigned long and truncated for rlim_new > 4 seconds before being widened to u64. The same file already casts to u64 for the matching computation in check_process_timers(): u64 softns = (u64)soft * NSEC_PER_SEC; As a result, the truncated value is installed into the CPUCLOCK_PROF expiry cache (nextevt), causing the process CPU timer to be programmed to fire prematurely for any RLIMIT_CPU soft limit >= 5 seconds. The actual SIGXCPU/SIGKILL decision in check_process_timers() already casts to u64 and is therefore correct, so limit enforcement is not broken; only the expiry-cache programming is wrong. Apply the same cast here so both paths convert rlim_cur identically. An integer truncation vulnerability occurs in the `update_rlimit_cpu()` function when converting the `RLIMIT_CPU` value to nanoseconds. While actual resource limit enforcement remains correct, this premature timer expiry could lead to a denial of service for affected processes.
Medium [CVE-2026-72296] require ETH_HLEN to be pullable in ife_decode
In the Linux kernel, the following vulnerability has been resolved: net: ife: require ETH_HLEN to be pullable in ife_decode() ife decode may return after making only the outer IFE header and metadata pullable. The caller then passes the decapsulated packet to eth_type_trans(), which expects the inner Ethernet header to be accessible from the linear data area. With a malformed IFE frame, the inner Ethernet header may still be shorter than ETH_HLEN in the linear area, which can lead to a crash in the original code. Fix this by extending the pull check in ife_decode() so that the inner Ethernet header is also guaranteed to be pullable before returning. A flaw was found in the Linux kernel's In-band Flow Engine (IFE) component. A remote attacker could send a specially crafted IFE frame with a malformed inner Ethernet header. This improper handling of the packet structure could lead to a system crash, resulting in a Denial of Service (DoS). Exploiting this flaw requires sending specially crafted IFE-encapsulated frames to a host where an IFE traffic-control action is configured, which in practice limits attacks to the network segment where IFE encapsulation is deployed. All Red Hat Enterprise Linux and Red Hat In-Vehicle OS kernel packages tracked for this flaw are not affected because the vulnerable code is not present in them.
Medium [CVE-2026-72458] fix NULL pointer dereference in unpack_pdb
In the Linux kernel, the following vulnerability has been resolved: apparmor: fix NULL pointer dereference in unpack_pdb pdb->dfa could be NULL if unpack_dfa fails, causing a NULL pointer dereference. A flaw was found in the Linux kernel's Apparmor security module. This vulnerability occurs in the `unpack_pdb` function, where it does not correctly handle a null pointer if a preceding operation, `unpack_dfa`, fails. This oversight can lead to a NULL pointer dereference, which typically results in a system crash and a Denial of Service (DoS) for the affected system. 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. 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-72373] Fix missing NULL pointer check in afs_break_some_callbacks
In the Linux kernel, the following vulnerability has been resolved: afs: Fix missing NULL pointer check in afs_break_some_callbacks() Fix afs_break_some_callbacks() to check to see if afs_lookup_volume_rcu() returned NULL (e.g. the specified volume is unknown). A flaw was found in the AFS (Andrew File System) component of the Linux kernel. A missing NULL pointer check in the `afs_break_some_callbacks()` function could allow a local attacker to trigger a kernel panic, leading to a denial of service. This occurs when the `afs_lookup_volume_rcu()` function returns a NULL value, indicating an unknown volume. Only system availability is affected; there is no impact on confidentiality or integrity. Red Hat Enterprise Linux 6, 7, and 8 are not affected because the vulnerable code is not present in those streams. Red Hat rates this flaw Moderate (CVSS 3.1 score 5.5, AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H) reflecting a local attack vector requiring privileges, which differs from the upstream CVE record severity of 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H), where the network vector considers a malicious or compromised AFS server triggering the crash remotely on AFS client systems. Weakness: CWE-476. Red Hat does not currently list a fixing RHSA for this CVE. Affected products named by the advisory: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 9; Red Hat package: kernel-rt.
Medium [CVE-2026-72308] fix refcount leak in mlxsw_sp_port_lag_join
In the Linux kernel, the following vulnerability has been resolved: mlxsw: fix refcount leak in mlxsw_sp_port_lag_join() When mlxsw_sp_port_lag_index_get() fails, mlxsw_sp_port_lag_join() returns an error without releasing the lag reference obtained by the earlier mlxsw_sp_lag_get(). All other error paths in the function jump to the cleanup label that ends with mlxsw_sp_lag_put(), so this is a single missed release. Fix the leak by replacing the bare 'return err' with a goto to the existing error cleanup label, which will drop the reference safely. This vulnerability occurs when the `mlxsw_sp_port_lag_join()` function fails to properly release a network resource reference, leading to a reference count leak. Over time, this leak could exhaust system resources, potentially resulting in a denial of service (DoS) for affected systems. 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 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-72088] Fix DMA mapping leak on IOACCEL2 reset path
In the Linux kernel, the following vulnerability has been resolved: scsi: hpsa: Fix DMA mapping leak on IOACCEL2 reset path If phys_disk->in_reset is set, the function returns directly without undoing the resources acquired for the command. Add the missing error cleanup by unmapping the IOACCEL2 SG chain block when needed, unmapping the SCSI command, and dropping the outstanding IOACCEL command count before returning. When a physical disk is in a reset state, the driver fails to properly unmap Direct Memory Access (DMA) resources. This oversight can lead to a DMA mapping leak, potentially causing 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 Enterprise Linux 6; 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-72445] clear opened when stream enable fails
In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: qcom: clear opened when stream enable fails On enable, subs->opened is set before the service_interval is validated; an invalid interval jumps to the response label without clearing it, so the substream is wedged at -EBUSY until a disable or disconnect. An attacker, by providing an invalid service interval during stream enablement, can cause the audio substream to become unresponsive. This can lead to a Denial of Service (DoS) for the affected audio device, requiring a disable or disconnect to restore functionality. 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 does not currently list a fixing RHSA for this CVE. Affected products named by the advisory: Red Hat package: kernel.
Medium [CVE-2026-72019] don't read an unset MAC header in macsec_encrypt
In the Linux kernel, the following vulnerability has been resolved: macsec: don't read an unset MAC header in macsec_encrypt() macsec_encrypt() reads the Ethernet header via eth_hdr(skb) (skb->head + skb->mac_header) to memmove() the 12 source/destination MAC bytes forward and make room for the SecTAG. On the AF_PACKET SOCK_RAW + PACKET_QDISC_BYPASS transmit path the skb reaches the macsec ndo_start_xmit() with the MAC header unset, so eth_hdr(skb) resolves to skb->head + (u16)~0 and the read is out of bounds: a 12-byte heap over-read that is also emitted on the wire as the frame's outer source/destination MAC. KASAN reports a slab-out-of-bounds read in macsec_start_xmit() on 6.0; on current mainline a CONFIG_DEBUG_NET build flags it as an unset mac header in skb_mac_header(). On the TX path the L2 header is at skb->data, so use skb_eth_hdr(), added by commit 96cc4b69581d ("macvlan: do not assume mac_header is set in macvlan_broadcast()") for exactly this purpose. When processing packets on the AF_PACKET SOCK_RAW + PACKET_QDISC_BYPASS transmit path, the `macsec_encrypt()` function attempts to read an unset Media Access Control (MAC) header. This leads to a 12-byte heap over-read, where sensitive data from memory beyond the intended buffer is accessed.
Medium [CVE-2026-68466] fail DMA transfer on completion timeout
In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: lpc32xx_slc: fail DMA transfer on completion timeout lpc32xx_xmit_dma() waits for the DMA completion callback but ignores wait_for_completion_timeout(). A timed out DMA transfer is therefore unmapped and reported as successful to the NAND read/write path. Return -ETIMEDOUT when the completion wait expires. Terminate the DMA channel before unmapping the scatterlist so the timed out transfer cannot continue to access the buffer after the error is returned. A flaw was found in the Linux kernel's `lpc32xx_slc` driver, which manages NAND flash memory. This vulnerability occurs because the driver fails to properly handle Direct Memory Access (DMA) transfer timeouts. When a DMA transfer times out, the driver incorrectly reports it as successful and unmaps the associated memory buffer without terminating the DMA channel. This can lead to the system attempting to access an unmapped memory region, potentially causing data corruption 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-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-72059] destroy DMA pool on CLDMA late init failure
In the Linux kernel, the following vulnerability has been resolved: net: wwan: t7xx: destroy DMA pool on CLDMA late init failure t7xx_cldma_late_init() creates md_ctrl->gpd_dmapool before initializing the TX and RX rings. If any ring initialization fails, the error path frees the already initialized rings but leaves the DMA pool allocated. This issue occurs during the initialization of the Cellular Direct Memory Access (CLDMA) module. If the setup of the transmit or receive rings fails, a dedicated memory resource, known as a Direct Memory Access (DMA) pool, is not properly released. This oversight leads to a memory leak, which could potentially degrade system performance or stability over an extended period. 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. 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-72259] Release reserved memory on cleanup
In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: mt8192: Release reserved memory on cleanup The MT8192 AFE probe calls of_reserved_mem_device_init() and falls back to preallocated buffers when no reserved memory region is available. When the reserved memory assignment succeeds, however, the driver never releases it. Register a devm cleanup action after a successful reserved-memory assignment so the assignment is released on probe failure and driver unbind. A flaw was found in the Linux kernel's ASoC (Audio System on Chip) Mediatek MT8192 audio driver. This vulnerability occurs because the driver fails to release reserved memory after a successful assignment during the probe process. This oversight can lead to a memory leak, potentially causing system instability or a Denial of Service (DoS) due to resource exhaustion over extended operation. A local user with the privileges required to rebind or re-probe the audio device could repeat this cycle to progressively exhaust reserved memory, causing a denial of service through resource exhaustion over extended operation; there is no impact on confidentiality or integrity (Red Hat CVSS:3.1 score 5.5, AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Affected products named by the advisory: Red Hat Enterprise Linux 10; Red Hat package: kernel.
Medium [CVE-2026-72430] fix nf_connlabels leak on two error paths
In the Linux kernel, the following vulnerability has been resolved: net/sched: act_ct: fix nf_connlabels leak on two error paths tcf_ct_fill_params() calls nf_connlabels_get() (setting put_labels) when TCA_CT_LABELS is present, but two later error sites use a bare return instead of "goto err", skipping the err: nf_connlabels_put() cleanup. They also precede the "p->put_labels = put_labels" assignment, so the tcf_ct_params_free() fallback does not release the count either. Each failed RTM_NEWACTION on these paths leaks one nf_connlabels Affected products named by the advisory: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 9; Red Hat package: kernel-rt.
Medium [CVE-2026-72277] Inject SEA if guest VNCR isn't normal memory
In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: nv: Inject SEA if guest VNCR isn't normal memory When constructing an L1 VNCR mapping, KVM unconditionally uses cacheable memory attributes, even if the underlying PFN isn't memory. This gets particularly hairy if the endpoint doesn't support cacheable memory attributes, potentially throwing an SError on writeback... While KVM does permit cacheable memory attributes on certain PFNMAP VMAs, kvm_translate_vncr() isn't currently grabbing the VMA. So do the simpler thing for now and just reject everything that isn't memory. A flaw was found in the Linux kernel's KVM (Kernel-based Virtual Machine) for ARM64 systems. When KVM constructs an L1 VNCR (Virtual Nested Control Register) mapping, it incorrectly applies cacheable memory attributes even when the underlying physical memory is not normal memory. This can lead to a system error (SError) during writeback operations, potentially causing system instability or a denial of service. Exploitation requires local access to a guest virtual machine capable of controlling nested virtualization state and its backing memory mappings; the issue is not network-reachable and affects availability only, with no impact on confidentiality or integrity. Affected products named by the advisory: Red Hat Enterprise Linux 10; Red Hat package: kernel.
Medium [CVE-2026-72116] fix stale rx/tx ops after device removal
In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix stale rx/tx ops after device removal RX: an RX_SETUP update(!) for an existing op skipped can_rx_register() unconditionally, even when a concurrent NETDEV_UNREGISTER had already torn down its registration (op->rx_reg_dev == NULL). This silently did not re-enable frame delivery for that updated filter. bcm_rx_setup() now re-registers in that case, while leaving rx_ops with ifindex = 0 (all CAN devices) which never carry a tracked rx_reg_dev registered as-is. TX: bcm_notify() only handled bo->rx_ops on NETDEV_UNREGISTER, leaving tx_ops with an active cyclic transmission re-arming its hrtimer indefinitely to execute bcm_tx_timeout_handler(). Cancelling the hrtimer prevents the runaway timer and any injection into a later reused ifindex, since nothing else calls bcm_can_tx() for the op until an explicit TX_SETUP update re-arms it. Unlike bcm_rx_unreg(), which clears the tracked rx_reg_dev for rx_ops, the ifindex is intentionally left unchanged for tx_ops. bcm_tx_setup() always rejects ifindex 0, so clearing it would strand the op: neither a later TX_SETUP (bcm_find_op()) nor TX_DELETE (bcm_delete_tx_op()) could ever find it again, since both require an exact ifindex match. A flaw was found in the Linux kernel's Broadcom Controller Area Network (CAN) bus driver.
Medium [CVE-2026-72472] use nfsi->rwsem to protect traversal of the file lock list
In the Linux kernel, the following vulnerability has been resolved: nfs: use nfsi->rwsem to protect traversal of the file lock list Lingfeng identified a bug and suggested two solutions, but both appear to have issues. Generally, we cannot release flc_lock while iterating over the file lock list to avoid use-after-free (UAF) problems with file locks. However, functions like nfs_delegation_claim_locks and nfs4_reclaim_locks cannot adhere to this rule because recover_lock or nfs4_lock_delegation_recall may take a long time. To resolve this, NFS switches to using nfsi->rwsem for the same protection, and nfs_reclaim_locks follows this approach. Although nfs_delegation_claim_locks uses so_delegreturn_mutex instead, this is inadequate since a single inode can have multiple nfs4_state instances. Therefore, the fix is to also use nfsi->rwsem in this case. Furthermore, after commit c69899a17ca4 ("NFSv4: Update of VFS byte range lock must be atomic with the stateid update"), the functions nfs4_locku_done and nfs4_lock_done also break this rule because they call locks_lock_inode_wait without holding nfsi->rwsem. Simply adding this protection could cause many deadlocks, so instead, the call to locks_lock_inode_wait is moved into _nfs4_proc_setlk.
Medium [CVE-2026-72483] Fix shift-out-of-bounds in max3421_hub_control
In the Linux kernel, the following vulnerability has been resolved: usb: host: max3421: Fix shift-out-of-bounds in max3421_hub_control() The `max3421_hub_control()` function handles USB hub class requests to the virtual root hub. In the `default` branches of both the `ClearPortFeature` and `SetPortFeature` switch statements, it modifies `max3421_hcd->port_status` by left shifting 1 by the request's `value` parameter. However, it does not validate whether this shift will exceed the width of `port_status`. So if a malicious userspace task with access to the root hub via /dev/bus/usb/.../001 issues a USBDEVFS_CONTROL ioctl with `wValue` greater than or equal to 32, the left shift operation invokes shift-out-of-bounds undefined behavior. This results in arbitrary bit corruption of `port_status`, including the normally-immutable change bits, which can bypass internal state checks and confuse the hub status. Fix this by rejecting requests whose `value` exceeds the shift width before performing the shift. This issue was found using a KLEE-based symbolic execution tool for kernel drivers that I'm currently developing. A moderate severity flaw was found in the Linux kernel MAX3421E USB host controller driver.
Medium [CVE-2026-72411] fix use-after-free of DSA ports in crc_err_work
In the Linux kernel, the following vulnerability has been resolved: net: dsa: mxl862xx: fix use-after-free of DSA ports in crc_err_work Upon an MDIO CRC error mxl862xx_crc_err_work_fn() walks the DSA ports and closes the CPU port conduits: dsa_switch_for_each_cpu_port(dp, priv->ds) dev_close(dp->conduit); mxl862xx_remove() unregisters the switch before cancelling this work: set_bit(MXL862XX_FLAG_WORK_STOPPED, &priv->flags); cancel_delayed_work_sync(&priv->stats_work); dsa_unregister_switch(ds); mxl862xx_host_shutdown(priv); dsa_unregister_switch() frees the dsa_port objects. If a CRC error schedules the work during teardown it can run after the ports have been freed and dereference freed memory. Guard the port walk with MXL862XX_FLAG_WORK_STOPPED, which is already set before dsa_unregister_switch(). DSA tears the ports down under rtnl_lock(), so checking the flag under rtnl_lock() means the work either runs before teardown and sees valid ports, or runs afterwards, observes the flag and skips the walk. This mirrors the host_flood_work handler, which skips torn-down ports under rtnl_lock(). A flaw was found in the Linux kernel's mxl862xx Digital Subscriber Line (DSA) driver. An issue during the driver's teardown process, specifically when handling MDIO CRC errors, can lead to a use-after-free vulnerability.