Complete feed
Recently updated
Advisories the vendor has revised
Android app · Google Play
Take your CVE monitoring with you.
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.
High [CVE-2026-50540] Arbitrary code execution via manipulated configuration path
Kata Containers is an open source project focusing on a standard implementation of lightweight Virtual Machines (VMs) that perform like containers. Prior to version 4.0.0, kata-runtime is vulnerable to host code execution via an unvalidated configuration path annotation. The runtime accepts an arbitrary io.katacontainers.config_path pod annotation and loads the referenced host TOML file without restriction. As a result, a pod user who can place a file at a host-visible path can supply a configuration that selects an attacker-controlled hypervisor or virtio-fs daemon binary, executing code as root on the host. This issue is fixed in version 4.0.0. A flaw was found in Kata Containers, affecting both its Rust and Go runtimes. An authenticated pod user can exploit this by setting the `io.katacontainers.config_path` annotation to an arbitrary configuration file on the host. This allows the attacker to control privileged runtime settings, leading to the execution of malicious binaries as root on the host system. The primary consequence is arbitrary code execution with elevated privileges. This is an Important flaw in Kata Containers that allows an authenticated pod user to achieve arbitrary code execution as root on the host. Affected products named by the advisory: Confidential Compute Attestation; Red Hat OpenShift Container Platform 4.
High [CVE-2026-64191] Reject I2C block transfers with invalid length
In the Linux kernel, the following vulnerability has been resolved: i2c: stub: Reject I2C block transfers with invalid length The I2C_SMBUS_I2C_BLOCK_DATA case in stub_xfer() uses data->block[0] as the transfer length. The existing check only clamps it to avoid overrunning the chip->words[256] register array, but does not validate it against I2C_SMBUS_BLOCK_MAX (32), which is the limit of the union i2c_smbus_data.block buffer (34 bytes total). The driver is a development/test tool (CONFIG_I2C_STUB=m, not built by default) that must be loaded with a chip_addr= parameter. Affected products named by the advisory: Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9; Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 7; and 1 more.
High [CVE-2026-64192] Reject BPF_MAP_TYPE_INODE_STORAGE creation if BPF LSM is uninitialized
In the Linux kernel, the following vulnerability has been resolved: bpf: Reject BPF_MAP_TYPE_INODE_STORAGE creation if BPF LSM is uninitialized When CONFIG_BPF_LSM=y is set, BPF inode storage maps (BPF_MAP_TYPE_INODE_STORAGE) are compiled into the kernel. However, if the BPF LSM is not explicitly enabled at boot time (e.g. omitted from the "lsm=" boot parameter), lsm_prepare() is never executed for the BPF LSM. Consequently, the BPF inode security blob offset (bpf_lsm_blob_sizes.lbs_inode) is never initialized and remains at its default compiled size of 8 bytes instead of being updated to a valid offset past the reserved struct rcu_head (typically 16 bytes or more). When a privileged user creates and updates a BPF_MAP_TYPE_INODE_STORAGE map, bpf_inode() evaluates inode->i_security + 8. This erroneously aliases the struct rcu_head.func callback pointer at the beginning of the inode->i_security blob. During subsequent map element cleanup or inode destruction, writing NULL to owner_storage clears the queued RCU callback pointer. When rcu_do_batch() later executes the queued callback, it attempts an instruction fetch at address 0x0, triggering an immediate kernel panic. Fix this by introducing a global bpf_lsm_initialized boolean flag marked with __ro_after_init. Set this flag to true inside bpf_lsm_init() when the LSM framework successfully registers the BPF LSM.
High [CVE-2026-64189] fix race between dump and ip_set_list resize
In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: fix race between dump and ip_set_list resize The release path of ip_set_dump_do() and ip_set_dump_done() read inst->ip_set_list via ip_set_ref_netlink(), a plain rcu_dereference_raw() of the array pointer. These run from netlink_recvmsg() without the nfnl mutex and without an RCU read-side critical section. A concurrent ip_set_create() can grow the array: it publishes the new array, calls synchronize_net() and then kvfree()s the old one. Since the dump paths read the array outside any RCU reader, synchronize_net() does not wait for them and the old array can be freed while they still index into it, causing a use-after-free. The dumped set itself stays pinned via set->ref_netlink, so only the array load needs protecting. Take rcu_read_lock() around it, matching ip_set_get_byname() and __ip_set_put_byindex(). BUG: KASAN: slab-use-after-free in ip_set_dump_do (net/netfilter/ipset/ip_set_core.c:1697) Read of size 8 at addr ffff88800b5c4018 by task exploit/150 Call Trace:... kasan_report (mm/kasan/report.c:595) ip_set_dump_do (net/netfilter/ipset/ip_set_core.c:1697) netlink_dump (net/netlink/af_netlink.c:2325) netlink_recvmsg (net/netlink/af_netlink.c:1976) sock_recvmsg (net/socket.c:1159) __sys_recvfrom (net/socket.c:2315)...
Medium [CVE-2026-15788] Information Disclosure via Improper Handling of NTFS Directory Junctions
BuildKit's cache mount source= selector on Windows Container on Windows (WCOW) workers does not detect NTFS directory junctions placed inside the cache root. A build authored by an untrusted user on a WCOW-configured BuildKit daemon can read arbitrary host files reachable to the BuildKit daemon process. A flaw was found in BuildKit. An untrusted user, when authoring a build on a Windows Container on Windows (WCOW) configured BuildKit daemon, can exploit a vulnerability in the cache mount source selector. Red Hat severity: Moderate — CVSS 6.3 (CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N). Weakness: CWE-22. Affected Red Hat products: Red Hat Hardened Images. Red Hat fixing advisory: RHSA-2026:43122, RHSA-2026:44152, RHSA-2026:46988, RHSA-2026:51065.
Medium [CVE-2026-64194] Net::DNS: Net::DNS: Denial of Service via crafted DNS compression pointers
Net::DNS versions through 1.55 for Perl allow Denial of Service via deep DNS compression pointer chains. Net::DNS::DomainName::decode follows RFC 1035 compression pointers by recursing into itself with no depth limit. It is possible to construct a name which saturates the call stack (at least with larger TCP responses), leading to a potential Denial of Service. The guard `$link new(\$wire)` i.e. any point where the library decodes a DNS message from the network. A remote attacker can exploit this vulnerability by sending a specially crafted DNS packet with deep compression pointer chains. This can cause excessive recursion in the `Net::DNS::DomainName::decode` function, leading to stack exhaustion and a Denial of Service (DoS) for any application processing untrusted DNS data. Contrary to the CVE description, this issue does not easily trigger an application crash via stack memory exhaustion, as the Perl interpreter h… Affected products named by the advisory: Red Hat Enterprise Linux 7; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9.
Medium [CVE-2026-26199] Denial of Service via buffer underflow in H5Iget_name
HDF5 is a high-performance library and a file format specification that implements the HDF5 data model. If `H5Iget_name` is invoked on a group id with `0` for the size parameter, it will underflow when trying to place a null terminator in the buffer. This can occur if `H5Iget_name` is invoked in a way where `size` can be forced to zero, and there is important data before the `name` buffer. A flaw was found in HDF5, a library used for managing large datasets. This vulnerability occurs when a specific function, H5Iget_name, is called with an invalid size parameter, leading to a buffer underflow. An attacker could exploit this by providing specially crafted input, potentially causing the application to crash or become unavailable, resulting in a denial of service (DoS). This Moderate vulnerability in HDF5 involves a buffer underflow in the `H5Iget_name` function, which can lead to a denial of service. Exploitation requires an attacker to provide specially crafted input that forces the `size` parameter to zero, a condition not commonly encountered in default Red Hat configurations, thus limiting the attack's practicality. Red Hat severity: Moderate — CVSS 5.3 (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:N/A:H). Weakness: CWE-124. Affected Red Hat products: Red Hat AI Inference Server; Red Hat Enterprise Linux AI (RHEL AI) 3; Red Hat OpenShift AI (RHOAI).
Medium [CVE-2026-26197] Out-of-bounds read due to corrupted file can lead to denial of service
HDF5 is a high-performance library and a file format specification that implements the HDF5 data model. If a file is corrupted such that an array datatype's size, the number of elements, and the element size are not in agreement it can trigger an out of bounds read. The array datatype stores the full size of the datatype (`dt->shared->size`) separately from the number of elements (`dt->shared->u.array.nelem`) and the element size (`dt->shared->parent->shared->size`). If any one of these are corrupted so that they don't align with the others (element size * nelem = full size), it can lead to an out of bounds read. Depending on what is corrupted, it can alter the type of out of bounds read triggered. The vulnerability is present only in files that have been maliciously altered, as its generally not possible to independently alter the full size of the datatype, the element count and the element size. As such, this is only present if a malicious actor is altering files, and won't appear in regular usage. A remote attacker can exploit this vulnerability by providing a maliciously altered HDF5 file. This can lead to a denial of service (DoS) by causing the application to crash or become unresponsive. This Moderate flaw in HDF5 is due to an out-of-bounds read when processing a maliciously crafted HDF5 file with inconsistent array datatype metadata.
Medium [CVE-2026-16277] stack buffer overflow in rpcinfo rpcbaddrlist
A stack-based buffer overflow was found in rpcbind's rpcinfo utility. When querying a remote rpcbind service with `rpcinfo -l`, address information returned by the server is copied into a fixed-size buffer without sufficient bounds checking. A malicious or compromised rpcbind server could use this flaw to crash the rpcinfo client, resulting in a denial of service. The highest threat from this vulnerability is to system availability. We rate the flaw as Moderate because exploitation requires a user or administrator to actively run `rpcinfo -l` against a malicious or compromised rpcbind endpoint (UI:R) — it cannot be triggered without that action. The demonstrated impact is limited to a crash of the `rpcinfo` client process; confidentiality and integrity are not affected, and no reliable code execution has been established. Red Hat severity: Moderate — CVSS 6.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H). Weakness: CWE-121. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9; Red Hat OpenShift Container Platform 4. Red Hat does not currently list a fixing RHSA for this CVE. Affected products named by the advisory: Red Hat package: rpcbind.
Medium [CVE-2026-15588] GDBusServer pre-authentication DoS via unbounded SASL line buffering
A denial-of-service and resource exhaustion vulnerability exists within the `GDBus` component of GLib. The `gdbusauth` authentication mechanism fails to enforce proper length limitations on data lines read from a client. An unauthenticated local or remote attacker can exploit this lack of input validation by sending excessively long streams of data, causing the application to consume massive amounts of system memory and CPU, potentially leading to a crash or system hang. A local or remote unauthenticated attacker could send an engineered stream of data without line length limitations during the authentication process (`gdbusauth`), leading to excessive memory allocation and CPU consumption. This resource exhaustion can result in a denial-of-service (DoS) condition, causing applications or services dependent on GLib to become unstable or crash. Red Hat severity: Moderate — CVSS 5.3 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L). Weakness: CWE-770. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 9; Red Hat Hardened Images; Red Hat Update Infrastructure 5; Red Hat Enterprise Linux 6; Red Hat Enterprise Linux 7; Red Hat Enterprise Linux 8; Red Hat OpenShift Container Platform 4. Red Hat fixing advisory: RHSA-2026:57015, RHSA-2026:55440, RHSA-2026:39985, RHSA-2026:40485, RHSA-2026:42329, RHSA-2026:58981.
Medium [CVE-2026-16254] Denial of service via out-of-bounds slice in claircore's apk installed-database parser
A flaw was found in claircore's apk package scanner. Malformed package-database data in a container layer can cause an out-of-bounds access that panics the scanner. If that panic is not recovered, the Clair indexer process can crash, leading to a denial of service. Red Hat Quay deployments, Clair typically runs as multiple OpenShift pods (default >=2, auto-restart). An unrecovered indexer panic terminates one Clair pod; remaining replicas and kubelet restart limit impact to a temporary interruption of vulnerability indexing, not a lasting Quay registry outage. Therefore Availability is Low (A:L). Red Hat severity: Moderate — CVSS 4.3 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L). Weakness: CWE-125. Affected Red Hat products: Red Hat Advanced Cluster Security 4; Red Hat Quay 3. Red Hat does not currently list a fixing RHSA for this CVE.
Medium [CVE-2026-15813] memory corruption and out-of-bounds access via malformed network packet defragmentation
A vulnerability was found in the network packet de-fragmentation engine of kronosnet (Version affected <= 1.34). The internal reassembly code does not properly validate sequence numbers of incoming payload fragments. An attacker can exploit this lack of verification by transmitting malformed packets with corrupted sequence parameters. Under specific conditions, this forces the packet processing layer to parse data outside the designated bounds of the internal memory structures, causing an out-of-bounds memory access or heap corruption. This behavior can result in sudden application crashes or system instability. Red Hat Product Security rates this vulnerability's impact as Low. While memory corruption and out-of-bounds access conditions are technically severe flaw types (typically rated Moderate or Important), the deployment requirements drastically reduce the real-world threat vector. The flaw can only be reached if kronosnet is running completely unencrypted traffic (a setting unsupported for production) and the attacker is capable of spoofing a trusted IP address already authorized within the cluster infrastructure to pass initial Access Control Lists (ACLs). Affected products named by the advisory: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9; Red Hat OpenShift Container Platform 4; and 1 more.
Medium [CVE-2026-64206] cancel pending_rx_work before taking conn->lock
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: cancel pending_rx_work before taking conn->lock l2cap_conn_del() takes conn->lock and then calls cancel_work_sync() for pending_rx_work. process_pending_rx() takes the same mutex, so teardown can deadlock against the worker it is flushing. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the l2cap_conn_ready() -> queue_work(..., &conn->pending_rx_work) submit path, the l2cap_conn_del() -> cancel_work_sync(&conn->pending_rx_work) teardown path, and the process_pending_rx() -> mutex_lock(&conn->lock) worker edge. Lockdep WARNING: possible circular locking dependency detected process_pending_rx+0x21/0x2a [vuln_msv] l2cap_conn_del.constprop.0+0x3f/0x4e [vuln_msv] *** DEADLOCK *** Cancel pending_rx_work before taking conn->lock, matching the existing lock-before-drain ordering used for the two delayed works in the same teardown path. The pending_rx queue is still purged after the work has been cancelled and conn->lock has been acquired. A flaw was found in the Linux kernel's Bluetooth Logical Link Control and Adaptation Protocol (L2CAP) subsystem. A local attacker could trigger a deadlock during connection teardown due to a circular locking dependency between `l2cap_conn_del()` and `process_pending_rx()` functions.
Medium [CVE-2026-64190] fix NULL pointer dereference in team_xmit during mode change
In the Linux kernel, the following vulnerability has been resolved: net: team: fix NULL pointer dereference in team_xmit during mode change __team_change_mode() clears team->ops with memset() before restoring safe dummy handlers via team_adjust_ops(). A concurrent team_xmit() running under RCU on another CPU can read team->ops.transmit during this window and call a NULL function pointer, crashing the kernel. The race requires a mode change (CAP_NET_ADMIN) concurrent with transmit on the team device. BUG: kernel NULL pointer dereference, address: 0000000000000000 Oops: 0010 [#1] SMP KASAN NOPTI RIP: 0010:0x0 Call Trace: team_xmit (drivers/net/team/team_core.c:1853) dev_hard_start_xmit (net/core/dev.c:3904) __dev_queue_xmit (net/core/dev.c:4871) packet_sendmsg (net/packet/af_packet.c:3109) __sys_sendto (net/socket.c:2265) The original code assumed that no ports means no traffic, so mode changes could freely memset()/memcpy() the ops. AF_PACKET with forced carrier breaks that assumption. Prevent the race instead of making it safe: replace memset()/memcpy() with per-field updates that never touch transmit or receive. Those two handlers are managed solely by team_adjust_ops(), which already installs dummies when tx_en_port_count == 0 (always true during mode change since no ports are present).
Medium [CVE-2026-64187] fail recovery on a committed log item with no regions
In the Linux kernel, the following vulnerability has been resolved: xfs: fail recovery on a committed log item with no regions If the first op of a transaction is a bare transaction header (len == sizeof(struct xfs_trans_header)), xlog_recover_add_to_trans() adds an item but no region, leaving it on r_itemq with ri_cnt == 0 and ri_buf == NULL. The header can be split across op records, so later ops may still add regions; the item is only invalid if the transaction commits with none. The runtime commit path never emits such a transaction, so this only happens on a crafted log. It came from an AI-assisted code audit of the recovery parser. xlog_recover_reorder_trans() calls ITEM_TYPE() on the item, which reads *(unsigned short *)item->ri_buf[0].iov_base and faults on the NULL ri_buf. Reject it there, before the commit handlers that also read ri_buf[0]. Affected products named by the advisory: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 6; Red Hat Enterprise Linux 7; Red Hat Enterprise Linux 8; and 2 more.
Medium [CVE-2026-64205] fix hardware state machine corruption in error path
In the Linux kernel, the following vulnerability has been resolved: i2c: i801: fix hardware state machine corruption in error path A severe livelock and subsequent Hung Task panic were observed in the i2c-i801 driver during concurrent Fuzzing. The crash is caused by an unconditional hardware register cleanup in the error handling path of i801_access(). When i801_check_pre() fails (e.g., returning -EBUSY because the SMBus controller is actively used by BIOS/ACPI), the kernel does not actually acquire the hardware ownership. However, the code jumps to the 'out' label and executes: iowrite8(SMBHSTSTS_INUSE_STS | STATUS_FLAGS, SMBHSTSTS(priv)); This forcefully clears the INUSE_STS lock and resets the hardware status flags without owning the controller. Doing so interrupts ongoing BIOS/ACPI transactions and totally corrupts the SMBus hardware state machine. Consequently, all subsequent i801_access() calls fail at the pre-check stage, triggering an endless stream of "SMBus is busy, can't use it!" error logs. Over a slow serial console, this printk flood monopolizes the CPU (Console Livelock), starving other processes trying to acquire the mmap_lock down_read semaphore, ultimately triggering the hung task watchdog. Fix this by moving the 'out' label below the hardware register cleanup.
Advisory [CVE-2026-64188] fix endpoint use-after-free in rmnet_dellink
In the Linux kernel, the following vulnerability has been resolved: net: qualcomm: rmnet: fix endpoint use-after-free in rmnet_dellink() rmnet_dellink() removes the endpoint from the hash table with hlist_del_init_rcu() and then immediately frees it with kfree(). However, RCU readers on the receive path (rmnet_rx_handler -> __rmnet_map_ingress_handler) may still hold a reference to the endpoint and dereference ep->egress_dev after the memory has been freed. The endpoint is a kmalloc-32 object, and the stale read at offset 8 corresponds to the egress_dev pointer. BUG: unable to handle page fault for address: ffffffffde942eef Oops: 0002 [#1] SMP NOPTI CPU: 1 UID: 0 PID: 137 Comm: poc_write Not tainted 7.0.0+ #4 PREEMPTLAZY RIP: 0010:rmnet_vnd_rx_fixup (rmnet_vnd.c:27) Call Trace: __rmnet_map_ingress_handler (rmnet_handlers.c:48 rmnet_handlers.c:101) rmnet_rx_handler (rmnet_handlers.c:129 rmnet_handlers.c:235) __netif_receive_skb_core.constprop.0 (net/core/dev.c:6096) __netif_receive_skb_one_core (net/core/dev.c:6208) netif_receive_skb (net/core/dev.c:6467) tun_get_user (drivers/net/tun.c:1955) tun_chr_write_iter (drivers/net/tun.c:2003) vfs_write (fs/read_write.c:688) ksys_write (fs/read_write.c:740) Add an rcu_head field to struct rmnet_endpoint and replace kfree() with kfree_rcu() so the endpoint memory remains valid through the RCU grace period.
Advisory [CVE-2026-64207] fix GSO backlog accounting
In the Linux kernel, the following vulnerability has been resolved: net/sched: dualpi2: fix GSO backlog accounting When DualPI2 splits a GSO skb into N segments, it propagates N additional packets to its parent before returning NET_XMIT_SUCCESS. The parent then accounts for the original skb once more, leaving its qlen one larger than the number of packets actually queued. With QFQ as the parent, after all real packets are dequeued, QFQ still has a non-zero qlen while its in-service aggregate has no active classes. qfq_choose_next_agg() returns NULL and qfq_dequeue() passes the result to qfq_peek_skb(), causing a NULL pointer dereference. Follow the same pattern used by tbf_segment() and taprio: count only successfully queued segments, propagate the difference between the original skb and those segments, and return NET_XMIT_SUCCESS whenever at least one segment was queued. A flaw was found in the Linux kernel's DualPI2 (Dual-rate PI2) queue discipline. This vulnerability arises from incorrect accounting of Generic Segmentation Offload (GSO) backlog, where the parent queue (such as QFQ - Hierarchical Fair Queueing) miscalculates the number of queued packets. This miscalculation can lead to a NULL pointer dereference when the system attempts to dequeue packets from an inactive class, resulting in a system crash and a Denial of Service (DoS) condition.
High [CVE-2026-12484] Arbitrary code execution via unsafe deserialization of PyTorch data
A vulnerability in keras-team/keras version 3.15.0 allows unsafe deserialization of attacker-controlled PyTorch pickle data through the public `keras.layers. TorchModuleWrapper.from_config` method. This method invokes `torch.load(..., weights_only=False)` without requiring an explicit unsafe opt-in, such as a `safe_mode=False` parameter. When called outside a `SafeModeScope(True)` context, the absence of an ambient safe mode state permits unsafe deserialization by default. This issue can lead to arbitrary code execution if untrusted Keras layer configurations are processed using this method. The vulnerability arises because the method does not enforce safe deserialization practices unless explicitly guarded by Keras safe mode. This occurs because the method does not enforce safe deserialization practices by default, potentially allowing malicious code to run on the system. This Important vulnerability affects Red Hat OpenShift AI components utilizing Keras for model processing. This risk is present when users process external or unverified model configurations within their OpenShift AI deployments. Red Hat severity: Important — CVSS 7.8 (CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H). Weakness: CWE-502. Affected Red Hat products: Red Hat OpenShift AI (RHOAI). Red Hat does not currently list a fixing RHSA for this CVE.
High [CVE-2026-64098] use uninterruptible resv lock for plane updates
In the Linux kernel, the following vulnerability has been resolved: drm/virtio: use uninterruptible resv lock for plane updates virtio_gpu_cursor_plane_update() and virtio_gpu_resource_flush() lock the framebuffer BO's dma_resv via virtio_gpu_array_lock_resv() and ignore its return value. The function can fail with -EINTR from dma_resv_lock_interruptible() (signal during lock wait) or with -ENOMEM from dma_resv_reserve_fences() (fence slot allocation), leaving the resv lock not held. The queue path then walks the object array and calls dma_resv_add_fence(), which requires the lock held; with lockdep enabled this trips dma_resv_assert_held(): WARNING: drivers/dma-buf/dma-resv.c:296 at dma_resv_add_fence+0x71e/0x840 Call Trace: virtio_gpu_array_add_fence virtio_gpu_queue_ctrl_sgs virtio_gpu_queue_fenced_ctrl_buffer virtio_gpu_cursor_plane_update drm_atomic_helper_commit_planes drm_atomic_helper_commit_tail commit_tail drm_atomic_helper_commit drm_atomic_commit drm_atomic_helper_update_plane __setplane_atomic drm_mode_cursor_universal drm_mode_cursor_common drm_mode_cursor_ioctl drm_ioctl __x64_sys_ioctl Beyond the WARN, mutating the dma_resv fence list without the lock races with concurrent readers/writers and can corrupt the list. Affected products named by the advisory: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 9; Red Hat package: kernel-rt.