VulniPulse uses Google Ads measurement to understand visits from advertisements and campaign performance. It runs cookie-free until you choose — accepting enables cookies for more accurate attribution. Rejecting keeps it cookie-free and never limits the site.
See exactly what is measuredComplete feed
1184 advisories across 32 monitored vendors.
In the Linux kernel, the following vulnerability has been resolved: net/smc: avoid NULL deref of conn->lnk in smc_msg_event tracepoint The smc_msg_event tracepoint class, shared by smc_tx_sendmsg and smc_rx_recvmsg, unconditionally dereferences smc->conn.lnk: __string(name, smc->conn.lnk->ibname) conn->lnk is only set for SMC-R; for SMC-D it is NULL. Other code on these paths already handles this (e.g. !conn->lnk in SMC_STAT_RMB_TX_SIZE_SMALL()). With the tracepoint enabled, the first sendmsg()/recvmsg() on an SMC-D socket crashes: Oops: general protection fault, probably for non-canonical address KASAN: null-ptr-deref in range [...] RIP: 0010:strlen+0x1e/0xa0 Call Trace: trace_event_raw_event_smc_msg_event (net/smc/smc_tracepoint.h:44) smc_rx_recvmsg (net/smc/smc_rx.c:515) smc_recvmsg (net/smc/af_smc.c:2859) __sys_recvfrom (net/socket.c:2315) __x64_sys_recvfrom (net/socket.c:2326) do_syscall_64 The faulting address 0x3e0 is offsetof(struct smc_link, ibname), confirming the NULL ->lnk deref. Enabling the tracepoint requires root, but the trigger itself is unprivileged: socket(AF_SMC, ...) has no capability check, and SMC-D negotiation needs no admin step on s390 or on x86 with the loopback ISM device loaded. Log an empty device name for SMC-D instead of dereferencing NULL.
In the Linux kernel, the following vulnerability has been resolved: net/rds: fix NULL deref in rds_ib_send_cqe_handler() on masked atomic completion rds_ib_xmit_atomic() always programs a masked atomic opcode (IB_WR_MASKED_ATOMIC_CMP_AND_SWP or IB_WR_MASKED_ATOMIC_FETCH_AND_ADD) for every RDS atomic cmsg. But the completion-side switch in rds_ib_send_unmap_op() only handles the non-masked opcodes, so a masked atomic completion falls through to default and returns rm == NULL while send->s_op is left set. rds_ib_send_cqe_handler() then dereferences the NULL rm via rm->m_final_op, oopsing in softirq context. An unprivileged AF_RDS sendmsg() of an atomic cmsg over an active RDS/IB connection triggers it; on hardware that natively accepts masked atomics (mlx4, mlx5) no extra setup is needed. RDS/IB: rds_ib_send_unmap_op: unexpected opcode 0xd in WR!
In the Linux kernel, the following vulnerability has been resolved: tap: fix stack info leak in tap_ioctl() SIOCGIFHWADDR In the SIOCGIFHWADDR path, tap_ioctl() copies 16 bytes of an uninitialised on-stack struct sockaddr_storage to userspace via ifr_hwaddr, but netif_get_mac_address() only writes sa_family and dev->addr_len (6 for Ethernet) bytes, leaving sa_data[6..13] uninitialised. Those 8 trailing bytes leak kernel stack contents; SIOCGIFHWADDR on a macvtap chardev returns kernel .text and direct-map pointers, defeating KASLR. Initialise ss at declaration. This vulnerability allows an attacker to potentially disclose sensitive kernel stack memory contents to userspace. The flaw occurs in the `tap_ioctl()` function when handling the `SIOCGIFHWADDR` command, where uninitialized portions of a stack-allocated structure are copied to userspace. This information leak could be used to bypass Kernel Address Space Layout Randomization (KASLR), making it easier for attackers to exploit other vulnerabilities. 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-909. 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.
In the Linux kernel, the following vulnerability has been resolved: sctp: stream: fully roll back denied add-stream state When ADD_OUT_STREAMS is denied, SCTP only shrinks the queued chunks and then lowers outcnt. That leaves removed stream metadata behind, so a later re-add can reuse a stale ext and hit a null-pointer dereference in the scheduler get path. Fix the rollback by tearing down the removed stream state the same way other stream resizes do. Unschedule the current scheduler state, drop the removed stream ext state with sctp_stream_outq_migrate(), and then reschedule the remaining streams. This keeps scheduler-private RR/FC/PRIO lists consistent while fully rolling back denied outgoing stream additions. A flaw was found in the Linux kernel's Stream Control Transmission Protocol (SCTP) stream handling. When an attempt to add outgoing streams is denied, the system fails to fully roll back the associated state. This incomplete rollback can leave behind stale stream metadata, which a subsequent stream re-addition can then reuse. This can lead to a null-pointer dereference, potentially causing a system 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-825. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9.
In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: stop hash:* range iteration at end The following hash set variants: hash:ip,mark hash:ip,port hash:ip,port,ip hash:ip,port,net iterate IPv4 ranges with a 32-bit iterator. The iterator must stop once the last address in the requested range has been processed. Advancing it once more can move the traversal state past the end of the request, so a later retry may continue from an unintended position. Handle the iterator increment explicitly at the end of the loop and stop once the upper bound has been processed. This keeps the existing retry behaviour intact for valid ranges while preventing traversal from continuing past the original boundary. This can cause the iteration to advance beyond the intended boundary, potentially leading to a later retry continuing from an unintended position. This issue could result in incorrect processing of network rules or unexpected system behavior. 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-193. 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.
In the Linux kernel, the following vulnerability has been resolved: ipc/shm: serialize orphan cleanup with shm_nattch updates shm_destroy_orphaned() walks the shm idr under shm_ids(ns).rwsem, but that does not serialize all fields tested by shm_may_destroy(). In particular, shm_nattch is updated while holding shm_perm.lock, and attach paths can do that without holding the rwsem. Do not decide that an orphaned segment is unused before taking the object lock. Move the shm_may_destroy() check under shm_perm.lock, matching the other destroy paths, and unlock the segment when it no longer qualifies for removal. A flaw was found in the Linux kernel's inter-process communication (IPC) shared memory (shm) component. A synchronization issue exists where orphaned shared memory segments might be incorrectly destroyed while still in use due to a lack of serialization between cleanup and attachment updates. This could lead to system instability or a denial of service. Red Hat severity: Moderate — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-367. 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.
In the Linux kernel, the following vulnerability has been resolved: crypto: jitterentropy - replace long-held spinlock with mutex jent_kcapi_random() serializes the shared jitterentropy state, but it currently holds a spinlock across the jent_read_entropy() call. That path performs expensive jitter collection and SHA3 conditioning, so parallel readers can trigger stalls as contending waiters spin for the same lock. To prevent non-preemptible lock hold, replace rng->jent_lock with a mutex so contended readers sleep instead of spinning on a shared lock held across expensive entropy generation. A flaw was found in the Linux kernel's `jitterentropy` cryptographic module. A long-held spinlock during entropy collection could cause parallel readers to stall. This issue allows a local attacker to trigger a Denial of Service (DoS) by causing contention for the shared lock, making the system unresponsive. 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-821. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 7; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9. Red Hat does not currently list a fixing RHSA for this CVE.
In the Linux kernel, the following vulnerability has been resolved: netfilter: ip6t_hbh: reject oversized option lists struct ip6t_opts stores at most IP6T_OPTS_OPTSNR option descriptors, but hbh_mt6_check() does not reject larger optsnr values supplied from userspace. Validate optsnr in the rule setup path so only match data that fits the fixed-size opts array can be installed. This follows the existing xtables pattern of rejecting invalid user-provided counts in checkentry() and keeps the packet matching path unchanged. `struct ip6t_opts` has a fixed `opts[IP6T_OPTS_OPTSNR]` array, where `IP6T_OPTS_OPTSNR` is 16, then off-by-one array access is possible: [ 137.924693][ T8692] UBSAN: array-index-out-of-bounds in ../net/ipv6/netfilter/ip6t_hbh.c:110:29 [ 137.926167][ T8692] index 16 is out of range for type '__u16 [16]' A flaw was found in the Linux kernel's netfilter subsystem, specifically within the ip6t_hbh module responsible for handling IPv6 Hop-by-Hop (HBH) options. This vulnerability allows a local attacker to provide an oversized list of HBH options from userspace, leading to an out-of-bounds write. This can result in memory corruption and potentially cause a system crash, leading to a denial of service. Red Hat severity: Moderate — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-787.
In the Linux kernel, the following vulnerability has been resolved: netfilter: ebtables: fix OOB read in compat_mtw_from_user Luxiao Xu says: The function compat_mtw_from_user() converts ebtables extensions from 32-bit user structures to kernel native structures. However, it lacks proper validation of the user-supplied match_size/target_size. When certain extensions are processed, the kernel-side translation logic may perform memory accesses based on the extension's expected size. If the user provides a size smaller than what the extension requires, it results in an out-of-bounds read as reported by KASAN. This fix introduces a check to ensure match_size is at least as large as the extension's required compatsize. This covers matches, watchers, and targets, while maintaining compatibility with standard targets. AFAIU this is relevant for matches that need to go though match->compat_from_user() call. Those that use plain memcpy with the user-provided size are ok because the caller checks that size vs the start of the next rule entry offset (which itself is checked vs. total size copied from userspace). The ->compat_from_user() callbacks assume they can read compatsize bytes, so they need this extra check. Based on an earlier patch from Luxiao Xu.
A flaw was found in KubeVirt's virt-handler domain notify server. The gRPC handlers for HandleDomainEvent and HandleK8SEvent derive the VMI identity (namespace/name) solely from the request body without validating it against the connection's origin. Each virt-launcher pod connects through a per-VMI pipe socket, but no identity tag is propagated from the pipe path to the server handlers. This allows a compromised virt-launcher process to send forged domain lifecycle events for any other VMI scheduled on the same node, causing virt-handler to erroneously update that VMI's state and disrupt its lifecycle management. Red Hat has assessed this issue as Moderate impact for OpenShift Virtualization. In a default deployment, a user with namespace edit permissions can exec into their own virt-launcher pod and exploit the unvalidated VMI identity in the notify server to disrupt co-located VMs belonging to other tenants. The attack is limited to denial of service (forced shutdown/restart of targeted VMs) and does not provide data access or code execution. Exploitation requires: (1) shell access inside a virt-launcher pod on the target node, (2) knowledge of the victim VMI's namespace and name, and (3) the victim VM to be scheduled on the same node.
In the Linux kernel, the following vulnerability has been resolved: md: fix array_state=clear sysfs deadlock When "clear" is written to array_state, md_attr_store() breaks sysfs active protection so the array can delete itself from its own sysfs store method. However, md_attr_store() currently drops the mddev reference before calling sysfs_unbreak_active_protection(). Once do_md_stop(..., 0) has made the mddev eligible for delayed deletion, the temporary kobject reference taken by sysfs_break_active_protection() can become the last kobject reference protecting the md kobject. That allows sysfs_unbreak_active_protection() to drop the last kobject reference from the current sysfs writer context. kobject teardown then recurses into kernfs removal while the current sysfs node is still being unwound, and lockdep reports recursive locking on kn->active with kernfs_drain() in the call chain. Reproducer on an existing level: 1. Create an md0 linear array and activate it: mknod /dev/md0 b 9 0 echo none > /sys/block/md0/md/metadata_version echo linear > /sys/block/md0/md/level echo 1 > /sys/block/md0/md/raid_disks echo "$(cat /sys/class/block/sdb/dev)" > /sys/block/md0/md/new_dev echo "$(($(cat /sys/class/block/sdb/size) / 2))" > \ /sys/block/md0/md/dev-sdb/size echo 0 > /sys/block/md0/md/dev-sdb/slot echo active > /sys/block/md0/md/array_state 2.
In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Bound MIDI 2.0 endpoint descriptor scans The USB MIDI 2.0 endpoint parser has the same descriptor walking pattern as the legacy MIDI parser. It validates bLength against bNumGrpTrmBlock before reading baAssoGrpTrmBlkID[], but not against the remaining bytes in the endpoint-extra scan. A malformed device can therefore make later baAssoGrpTrmBlkID[] reads consume bytes past the walked descriptor. Reject zero-length and overlong descriptors while walking endpoint extras. The USB MIDI 2.0 endpoint parser, responsible for handling audio device descriptors, failed to properly validate the length of these descriptors. This vulnerability could allow a local attacker, by connecting a specially crafted malformed USB MIDI 2.0 device, to cause an out-of-bounds read. Such an issue can lead to memory corruption, potentially resulting in information disclosure or a system crash (denial of service). Red Hat severity: Moderate — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-1284. 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.
In the Linux kernel, the following vulnerability has been resolved: ceph: put folios not suitable for writeback The batch holds references to the folios (see `filemap_get_folios`, `folio_batch_release`), so we need to `folio_put` the folios we remove. Tested on v6.18. This vulnerability occurs due to improper handling of memory pages, known as folios, that are not suitable for writeback. When certain folios are removed, their references are not properly released, leading to a resource leak. A local attacker could potentially exploit this to cause resource exhaustion, 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-911. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 7; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9. Red Hat does not currently list a fixing RHSA for this CVE.
In the Linux kernel, the following vulnerability has been resolved: quota: Fix race of dquot_scan_active() with quota deactivation dquot_scan_active() can race with quota deactivation in quota_release_workfn() like: CPU0 (quota_release_workfn) CPU1 (dquot_scan_active) ============================== ============================== spin_lock(&dq_list_lock); list_replace_init( &releasing_dquots, &rls_head); /* dquot X on rls_head, dq_count == 0, DQ_ACTIVE_B still set */ spin_unlock(&dq_list_lock); synchronize_srcu(&dquot_srcu); spin_lock(&dq_list_lock); list_for_each_entry(dquot, &inuse_list, dq_inuse) { /* finds dquot X */ dquot_active(X) -> true atomic_inc(&X->dq_count); } spin_unlock(&dq_list_lock); spin_lock(&dq_list_lock); dquot = list_first_entry(&rls_head); WARN_ON_ONCE(atomic_read(&dquot->dq_count)); The problem is not only a cosmetic one as under memory pressure the caller of dquot_scan_active() can end up working on freed dquot. Fix the problem by making sure the dquot is removed from releasing list when we acquire a reference to it. A race condition exists between the dquot_scan_active() function and quota deactivation within quota_release_workfn(). This vulnerability could allow a local attacker to cause memory corruption by manipulating quota operations, potentially leading to system instability or a denial of service (DoS).
In the Linux kernel, the following vulnerability has been resolved: s390/ap: use generic driver_override infrastructure When the AP masks are updated via apmask_store() or aqmask_store(), ap_bus_revise_bindings() is called after ap_attr_mutex has been released. This calls __ap_revise_reserved(), which accesses the driver_override field without holding any lock, racing against a concurrent driver_override_store() that may free the old string, resulting in a potential UAF. Fix this by using the driver-core driver_override infrastructure, which protects all accesses with an internal spinlock. Note that unlike most other buses, the AP bus does not check driver_override in its match() callback; the override is checked in ap_device_probe() and __ap_revise_reserved() instead. Also note that we do not enable the driver_override feature of struct bus_type, as AP - in contrast to most other buses - passes "" to sysfs_emit() when the driver_override pointer is NULL. Thus, printing "\n" instead of "(null)\n". Additionally, AP has a custom counter that is modified in the corresponding custom driver_override_store(). A race condition occurs when AP masks are updated, leading to `__ap_revise_reserved()` accessing the `driver_override` field without proper locking. This can result in a Use-After-Free (UAF) vulnerability, where memory is accessed after it has been freed.
In the Linux kernel, the following vulnerability has been resolved: drm/ttm: Fix ttm_bo_swapout() infinite LRU walk on swapout failure When ttm_tt_swapout() fails, the current code calls ttm_resource_add_bulk_move() followed by ttm_resource_move_to_lru_tail() to restore the resource's bulk_move membership. However, ttm_resource_move_to_lru_tail() places the resource at the tail of the LRU list which, relative to the walk cursor's hitch node (placed immediately after the resource when it was yielded), puts the resource *in front of the* the hitch. The next list_for_each_entry_continue() from the hitch finds the same resource again, causing an infinite loop. Fix by deferring del_bulk_move to the success path only. On the success path, TTM_TT_FLAG_SWAPPED has just been set by ttm_tt_swapout() but the resource is still tracked in the bulk_move range, so ttm_resource_del_bulk_move()'s !ttm_resource_unevictable() guard would incorrectly skip the removal. Introduce ttm_resource_del_bulk_move_unevictable() which bypasses that guard. A flaw was found in the Linux kernel's TTM (Trusted Memory Manager) component. When the ttm_tt_swapout() function fails, a resource is incorrectly added to the Least Recently Used (LRU) list. This misplacement can lead to an infinite loop during subsequent list processing, causing the system to become unresponsive.
In the Linux kernel, the following vulnerability has been resolved: erofs: unify lcn as u64 for 32-bit platforms As sashiko reported [1], `lcn` was typed as `unsigned long` (or `unsigned int` sometimes), which is only 32 bits wide on 32-bit platforms, which causes `(lcn << lclusterbits)` to be truncated at 4 GiB. In order to consolidate the logic, just use `u64` consistently around the codebase. [1] https://sashiko.dev/r/20260420034612.1899973-1-hsiangkao%40linux.alibaba.com On 32-bit platforms, the `lcn` variable, used for logical cluster numbers, was defined as a 32-bit integer. This could lead to truncation when calculating offsets larger than 4 Gigabytes (GiB), potentially causing incorrect data handling within the filesystem. 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-190. Affected Red Hat products: Red Hat Enterprise Linux 10. Red Hat does not currently list a fixing RHSA for this CVE.
In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: Fix memory leak after mt76_connac_mcu_alloc_sta_req() mt76_connac_mcu_alloc_sta_req() allocates an skb which is expected to be freed eventually by mt76_mcu_skb_send_msg(). However, currently if an intermediate function fails before sending, the allocated skb is leaked. Specifically, mt76_connac_mcu_sta_wed_update() and mt76_connac_mcu_sta_key_tlv() may fail, leading to an immediate memory leak in the error path. Fix this by explicitly freeing the skb in these error paths. Commit 7c0f63fe37a5 ("wifi: mt76: mt7996: fix memory leak on mt7996_mcu_sta_key_tlv error") made a similar change. Compile tested only. Issue found using a prototype static analysis tool and code review. This vulnerability, a memory leak, occurs when the mt76_connac_mcu_alloc_sta_req() function allocates a socket buffer (skb) that is not properly freed if subsequent operations, such as mt76_connac_mcu_sta_wed_update() or mt76_connac_mcu_sta_key_tlv(), fail. This can lead to a gradual consumption of system memory, potentially impacting system stability and performance over time. Red Hat severity: Low — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-772. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9.
In the Linux kernel, the following vulnerability has been resolved: ice: fix potential NULL pointer deref in error path of ice_set_ringparam() ice_set_ringparam nullifies tstamp_ring of temporary tx_rings, without clearing ICE_TX_RING_FLAGS_TXTIME bit. When ICE_TX_RING_FLAGS_TXTIME is set and the subsequent ice_setup_tx_ring() call fails, a NULL pointer dereference could happen in the unwinding sequence: ice_clean_tx_ring() -> ice_is_txtime_cfg() == true (ICE_TX_RING_FLAGS_TXTIME is set) -> ice_free_tx_tstamp_ring() -> ice_free_tstamp_ring() -> tstamp_ring->desc (NULL deref) Clear ICE_TX_RING_FLAGS_TXTIME bit to avoid the potential issue. Note that this potential issue is found by manual code review. Compile test only since unfortunately I don't have E830 devices. This vulnerability occurs due to a potential NULL pointer dereference in the `ice_set_ringparam()` function. When `tstamp_ring` of temporary `tx_rings` is nullified without clearing the `ICE_TX_RING_FLAGS_TXTIME` bit, and a subsequent `ice_setup_tx_ring()` call fails, it can lead to a system crash. This issue could allow a local attacker to cause a Denial of Service (DoS). Red Hat severity: Low — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-476. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 9. Red Hat does not currently list a fixing RHSA for this CVE.
In the Linux kernel, the following vulnerability has been resolved: drm: Replace old pointer to new idr Commit 5e28b7b94408 introduced a logical error by failing to replace the newly generated IDR pointer to old id's pointer at the correct location within the "change handle" logic; this resulted in the issue reported by syzbot [1]. Specifically, the new IDR object pointer is intended to replace the original id's pointer during the normal execution flow. Additionally, an unnecessary conditional check for the ret exit path has been removed. [1] !RB_EMPTY_ROOT(&prime_fpriv->dmabufs) WARNING: drivers/gpu/drm/drm_prime.c:224 at drm_prime_destroy_file_private+0x48/0x60 drivers/gpu/drm/drm_prime.c:224, CPU#0: syz.0.17/5833 Call Trace: drm_file_free.part.0+0x7e6/0xcc0 drivers/gpu/drm/drm_file.c:269 drm_file_free drivers/gpu/drm/drm_file.c:237 [inline] drm_close_helper.isra.0+0x186/0x200 drivers/gpu/drm/drm_file.c:290 drm_release+0x1ab/0x360 drivers/gpu/drm/drm_file.c:438 A flaw was found in the Linux kernel's Direct Rendering Manager (DRM) subsystem. A logical error in the 'change handle' logic, specifically related to the replacement of IDR (ID allocator) pointers, could lead to a kernel warning or system panic. This issue could allow a local attacker to trigger a system crash, resulting in a denial of service.