LiveActive security incident?Get immediate response
CVE archive

May 2026

Browse CVE records published in May 2026, with severity, affected products, CWE, KEV, and source-backed vulnerability context.

Showing 50 of 6029 matching CVEs · Page 16 of 121.

High · CVSS 7

CVE-2026-34331: Win32k Elevation of Privilege Vulnerability

Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Win32K - GRFX allows an authorized attacker to elevate privileges locally.

Published May 12, 2026 · Updated Aug 10, 2026

High · CVSS 7.8

CVE-2026-34330: Win32k Elevation of Privilege Vulnerability

Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Win32K - GRFX allows an authorized attacker to elevate privileges locally.

Published May 12, 2026 · Updated Aug 10, 2026

High · CVSS 7

CVE-2026-33839: Win32k Elevation of Privilege Vulnerability

Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Win32K - GRFX allows an authorized attacker to elevate privileges locally.

Published May 12, 2026 · Updated Aug 10, 2026

Critical · CVSS 9.1

CVE-2026-33117: Azure SDK for Java Security Feature Bypass Vulnerability

The Java Key Vault Keys library in the Azure SDK for Java contains an issue in the local cryptographic verification path where authentication tag comparison was implemented incorrectly. In affected applications that use the vulnerable local cryptography path, specially crafted encrypted input may bypass integrity verification checks. Operations delegated to the Key Vault service are not affected. The issue is addressed in version 4.10.6.

Published May 12, 2026 · Updated Aug 10, 2026

Critical · CVSS 9.3

CVE-2026-41090: Microsoft Copilot Tampering Vulnerability

Improper neutralization of special elements used in a command ('command injection') in Microsoft Copilot allows an unauthorized attacker to perform tampering over a network.

Published May 22, 2026 · Updated Aug 10, 2026

High · CVSS 7.5

CVE-2026-42561: Python-Multipart: Denial of Service via unbounded multipart part headers

Python-Multipart is a streaming multipart parser for Python. Prior to 0.0.27, python-multipart has a denial of service vulnerability in multipart part header parsing. When parsing multipart/form-data, MultipartParser previously had no limit on the number of part headers or the size of an individual part header. An attacker could send a request with either many repeated headers without terminating the header block or a single very large header value, causing excessive CPU work before request rejection or completion. This vulnerability is fixed in 0.0.27.

Published May 13, 2026 · Updated Aug 7, 2026

Medium · CVSS 6.1

CVE-2026-8496: A cross-site scripting (XSS) vulnerability in Alinto SOGo, version 5.12.7

A cross-site scripting (XSS) vulnerability exists in Alinto SOGo, version 5.12.7. A maliciously crafted ICS calendar invitation files allows arbitrary JavaScript execution within the authenticated SOGo webmail session. The issue occurs because SVG content embedded in the description field of an ICS file, with an onrepeat event handler, is insufficiently sanitized before being rendered in the webmail interface. A remote attacker can execute JavaScript in the victim's browser when the malicious calendar invite is viewed. Successful exploitation may allow mailbox access, email and contact theft, session hijacking, and other actions allowed by an authenticated user.

Published May 13, 2026 · Updated Aug 6, 2026

Medium · CVSS 5.3

CVE-2026-3609: XIGNCODE3 xhunter1.sys kernel driver contains a Privilege Escalation Vulnerability

Wellbia's XIGNCODE3 xhunter1.sys kernel driver, version 10.0.10011.16384 through 2023.12.7.78, privilege escalation vulnerability provides access to the IRP_MJ_WRITE command interface, which allows any user process to request a PROCESS_ALL_ACCESS. Note: KVE 2023-5589 (https://krcert.or.kr) was initially issued for version 10.0.10011.16384, but the vulnerability was not fully remediated and remains in version 2023.12.7.78.

Published May 11, 2026 · Updated Aug 5, 2026

High · CVSS 7.8

CVE-2026-46240: media: iris: Fix use-after-free in iris_release_internal_buffers()

In the Linux kernel, the following vulnerability has been resolved: media: iris: Fix use-after-free in iris_release_internal_buffers() The recent change in commit 1dabf00ee206 ("media: iris: gen1: Destroy internal buffers after FW releases") introduced a regression where session_release_buf() may free the buffer. The caller, iris_release_internal_buffers(), continued to access `buffer` after the call, leading to a potential use-after-free. Fix this by setting BUF_ATTR_PENDING_RELEASE before calling session_release_buf(), and reverting the flag if the call fails. This ensures no dereference occurs after potential freeing.

Published May 28, 2026 · Updated Aug 5, 2026

High · CVSS 8.8

CVE-2026-46238: batman-adv: stop caching unowned originator pointers in BAT IV

In the Linux kernel, the following vulnerability has been resolved: batman-adv: stop caching unowned originator pointers in BAT IV BAT IV keeps the last-hop neighbor address in each neigh_node, but some paths also cache an originator pointer derived from a temporary lookup. That pointer is not owned by the neigh_node and may no longer refer to a live originator entry after purge handling runs. Stop storing the auxiliary originator pointer in the BAT IV neighbor state. When BAT IV needs the neighbor originator data, resolve it from the stored neighbor address and drop the reference again after use. [sven: avoid bonding logic for outgoing OGM]

Published May 28, 2026 · Updated Aug 5, 2026

High · CVSS 8.1

CVE-2026-46232: HID: playstation: Clamp num_touch_reports

In the Linux kernel, the following vulnerability has been resolved: HID: playstation: Clamp num_touch_reports A device would never lie about the number of touch reports would it? If it does the loop in dualshock4_parse_report will read off the end of the touch_reports array, up to about 2 KiB for the maximum number of 256 loop iteraions. The data that is read is emitted via evdev if the DS4_TOUCH_POINT_INACTIVE bit happens to be set. Protect against this by clamping the num_touch_reports value provided by the device to the maximum size of the touch_reports array.

Published May 28, 2026 · Updated Aug 5, 2026

High · CVSS 7.1

CVE-2026-46218: drm/amdgpu: Add bounds checking to ib_{get,set}_value

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Add bounds checking to ib_{get,set}_value The uvd/vce/vcn code accesses the IB at predefined offsets without checking that the IB is large enough. Check the bounds here. The caller is responsible for making sure it can handle arbitrary return values. Also make the idx a uint32_t to prevent overflows causing the condition to fail.

Published May 28, 2026 · Updated Aug 5, 2026

High · CVSS 7.8

CVE-2026-46215: drm: Set old handle to NULL before prime swap in change_handle

In the Linux kernel, the following vulnerability has been resolved: drm: Set old handle to NULL before prime swap in change_handle There was a potential race condition in change_handle. The ioctl briefly had a single object with two idr entries; a concurrent gem_close could delete the object and remove one of the handles while leaving the other one dangling, which could subsequently be dereferenced for a use-after-free. To fix this, do the same dance that gem_close itself does. (f6cd7daecff5 drm: Release driver references to handle before making it available again) First idr_replace the old handle to NULL. Later, if the prime operations are successful, actually close it. create_tail required a similar dance to avoid a similar problem. (bd46cece51a3 drm/gem: Fix race in drm_gem_handle_create_tail()) It idr_allocs the new handle with NULL, then swaps in the correct object later to avoid races. We don't need to do that here, since the only operations that could race are drm_prime, and change_handle holds the prime lock for the entire duration. v2: cleanups of error paths

Published May 28, 2026 · Updated Aug 5, 2026

High · CVSS 8.8

CVE-2026-46212: batman-adv: bla: prevent use-after-free when deleting claims

In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: prevent use-after-free when deleting claims When batadv_bla_del_backbone_claims() removes all claims for a backbone, it does this by dropping the link entry in the hash list. This list entry itself was one of the references which need to be dropped at the same time via batadv_claim_put(). But the batadv_claim_put() must not be done before the last access to the claim object in this function. Otherwise the claim might be freed already by the batadv_claim_release() function before the list entry was dropped.

Published May 28, 2026 · Updated Aug 5, 2026

High · CVSS 7.8

CVE-2026-46208: batman-adv: stop tp_meter sessions during mesh teardown

In the Linux kernel, the following vulnerability has been resolved: batman-adv: stop tp_meter sessions during mesh teardown TP meter sessions remain linked on bat_priv->tp_list after the netlink request has already finished. When the mesh interface is removed, batadv_mesh_free() currently tears down the mesh without first draining these sessions. A running sender thread or a late incoming tp_meter packet can then keep processing against a mesh instance which is already shutting down. Synchronize tp_meter with the mesh lifetime by stopping all active sessions from batadv_mesh_free() and waiting for sender threads to exit before teardown continues.

Published May 28, 2026 · Updated Aug 5, 2026

High · CVSS 7.8

CVE-2026-46206: batman-adv: reject new tp_meter sessions during teardown

In the Linux kernel, the following vulnerability has been resolved: batman-adv: reject new tp_meter sessions during teardown Prevent tp_meter from starting new sender or receiver sessions after mesh_state has left BATADV_MESH_ACTIVE.

Published May 28, 2026 · Updated Aug 5, 2026

High · CVSS 7.8

CVE-2026-46205: staging: media: atomisp: Disallow all private IOCTLs

In the Linux kernel, the following vulnerability has been resolved: staging: media: atomisp: Disallow all private IOCTLs Disallow all private IOCTLs. These aren't quite as safe as one could assume of IOCTL handlers; disable them for now. Instead of removing the code, return in the beginning of the function if cmd is non-zero in order to keep static checkers happy.

Published May 28, 2026 · Updated Aug 5, 2026

High · CVSS 8.8

CVE-2026-46198: batman-adv: fix integer overflow on buff_pos

In the Linux kernel, the following vulnerability has been resolved: batman-adv: fix integer overflow on buff_pos Fixing an integer overflow present in batadv_iv_ogm_send_to_if. The size check is done using the int type in batadv_iv_ogm_aggr_packet whereas the buff_pos variable uses the s16 type. This could lead to an out-of-bound read.

Published May 28, 2026 · Updated Aug 5, 2026

High · CVSS 7.1

CVE-2026-46175: f2fs: fix fsck inconsistency caused by FGGC of node block

In the Linux kernel, the following vulnerability has been resolved: f2fs: fix fsck inconsistency caused by FGGC of node block During FGGC node block migration, fsck may incorrectly treat the migrated node block as fsync-written data. The reproduction scenario: root@vm:/mnt/f2fs# seq 1 2048 | xargs -n 1 ./test_sync // write inline inode and sync root@vm:/mnt/f2fs# rm -f 1 root@vm:/mnt/f2fs# sync root@vm:/mnt/f2fs# f2fs_io gc_range // move data block in sync mode and not write CP SPO, "fsck --dry-run" find inode has already checkpointed but still with DENT_BIT_SHIFT set The root cause is that GC does not clear the dentry mark and fsync mark during node block migration, leading fsck to misinterpret them as user-issued fsync writes. In BGGC mode, node block migration is handled by f2fs_sync_node_pages(), which guarantees the dentry and fsync marks are cleared before writing. This patch move the set/clear of the fsync|dentry marks into __write_node_folio to make the logic clearer, and ensures the fsync|dentry mark is cleared in FGGC.

Published May 28, 2026 · Updated Aug 5, 2026

High · CVSS 7

CVE-2026-46164: btrfs: fix double free in create_space_info_sub_group() error path

In the Linux kernel, the following vulnerability has been resolved: btrfs: fix double free in create_space_info_sub_group() error path When kobject_init_and_add() fails, the call chain is: create_space_info_sub_group() -> btrfs_sysfs_add_space_info_type() -> kobject_init_and_add() -> failure -> kobject_put(&sub_group->kobj) -> space_info_release() -> kfree(sub_group) Then control returns to create_space_info_sub_group(), where: btrfs_sysfs_add_space_info_type() returns error -> kfree(sub_group) Thus, sub_group is freed twice. Keep parent->sub_group[index] = NULL for the failure path, but after btrfs_sysfs_add_space_info_type() has called kobject_put(), let the kobject release callback handle the cleanup.

Published May 28, 2026 · Updated Aug 5, 2026

High · CVSS 7.8

CVE-2026-46157: ALSA: pcm: oss: Fix data race at accessing runtime.oss.trigger

In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: oss: Fix data race at accessing runtime.oss.trigger Currently the runtime.oss.trigger field may be accessed concurrently without protection, which may lead to the data race. And, in this case, it may lead to more severe problem because it's a bit field; as writing the data, it may overwrite other bit fields as well, which confuses the operation completely, as spotted by fuzzing. Fix it by covering runtime.oss.trigger bit fled also with the existing params_lock mutex in both snd_pcm_oss_get_trigger() and snd_pcm_oss_poll().

Published May 28, 2026 · Updated Aug 5, 2026

High · CVSS 7

CVE-2026-46154: sched_ext: Read scx_root under scx_cgroup_ops_rwsem in cgroup setters

In the Linux kernel, the following vulnerability has been resolved: sched_ext: Read scx_root under scx_cgroup_ops_rwsem in cgroup setters scx_group_set_{weight,idle,bandwidth}() cache scx_root before acquiring scx_cgroup_ops_rwsem, so the pointer can be stale by the time the op runs. If the loaded scheduler is disabled and freed (via RCU work) and another is enabled between the naked load and the rwsem acquire, the reader sees scx_cgroup_enabled=true (the new scheduler's) but dereferences the freed one - UAF on SCX_HAS_OP(sch, ...) / SCX_CALL_OP(sch, ...). scx_cgroup_enabled is toggled only under scx_cgroup_ops_rwsem write (scx_cgroup_{init,exit}), so reading scx_root inside the rwsem read section correlates @sch with the enabled snapshot.

Published May 28, 2026 · Updated Aug 5, 2026

High · CVSS 7.8

CVE-2026-46129: btrfs: fix double free in create_space_info() error path

In the Linux kernel, the following vulnerability has been resolved: btrfs: fix double free in create_space_info() error path When kobject_init_and_add() fails, the call chain is: create_space_info() -> btrfs_sysfs_add_space_info_type() -> kobject_init_and_add() -> failure -> kobject_put(&space_info->kobj) -> space_info_release() -> kfree(space_info) Then control returns to create_space_info(): btrfs_sysfs_add_space_info_type() returns error -> goto out_free -> kfree(space_info) This causes a double free. Keep the direct kfree(space_info) for the earlier failure path, but after btrfs_sysfs_add_space_info_type() has called kobject_put(), let the kobject release callback handle the cleanup.

Published May 28, 2026 · Updated Aug 5, 2026

High · CVSS 7.7

CVE-2026-46123: Bluetooth: virtio_bt: clamp rx length before skb_put

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: virtio_bt: clamp rx length before skb_put virtbt_rx_work() calls skb_put(skb, len) where len comes directly from virtqueue_get_buf() with no validation against the buffer we posted to the device. The RX skb is allocated in virtbt_add_inbuf() and exposed to virtio as exactly 1000 bytes via sg_init_one(). Checking len against skb_tailroom(skb) is not sufficient because alloc_skb() can leave more tailroom than the 1000 bytes actually handed to the device. A malicious or buggy backend can therefore report used.len between 1001 and skb_tailroom(skb), causing skb_put() to include uninitialized kernel heap bytes that were never written by the device. The same path also accepts len == 0, in which case skb_put(skb, 0) leaves the skb empty but virtbt_rx_handle() still reads the pkt_type byte from skb->data, consuming uninitialized memory. Define VIRTBT_RX_BUF_SIZE once and reuse it in alloc_skb() and sg_init_one(), and gate virtbt_rx_work() on that same constant so the bound checked matches the buffer actually exposed to the device. Reject used.len == 0 in the same gate so an empty completion can no longer reach virtbt_rx_handle(). Use bt_dev_err_ratelimited() because the length value comes from an untrusted backend that can otherwise flood the kernel log. Same class of bug as commit c04db81cd028 ("net/9p: Fix buffer overflow in USB transport layer"), which hardened the USB 9p transport against unchecked device-reported length.

Published May 28, 2026 · Updated Aug 5, 2026

High · CVSS 7.8

CVE-2026-46112: RDMA/hns: Fix unlocked call to hns_roce_qp_remove()

In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix unlocked call to hns_roce_qp_remove() Sashiko points out that hns_roce_qp_remove() requires the caller to hold locks. The error flow in hns_roce_create_qp_common() doesn't hold those locks for the error unwind so it risks corrupting memory. Grab the same locks the other two callers use.

Published May 28, 2026 · Updated Aug 5, 2026

High · CVSS 7.8

CVE-2026-46105: scsi: mpt3sas: Limit NVMe request size to 2 MiB

In the Linux kernel, the following vulnerability has been resolved: scsi: mpt3sas: Limit NVMe request size to 2 MiB The HBA firmware reports NVMe MDTS values based on the underlying drive capability. However, because the driver allocates a fixed 4K buffer for the PRP list, accommodating at most 512 entries, the driver supports a maximum I/O transfer size of 2 MiB. Limit max_hw_sectors to the smaller of the reported MDTS and the 2 MiB driver limit to prevent issuing oversized I/O that may lead to a kernel oops.

Published May 28, 2026 · Updated Aug 5, 2026

High · CVSS 7.8

CVE-2026-46100: fs: afs: revert mmap_prepare() change

In the Linux kernel, the following vulnerability has been resolved: fs: afs: revert mmap_prepare() change Partially reverts commit 9d5403b1036c ("fs: convert most other generic_file_*mmap() users to .mmap_prepare()"). This is because the .mmap invocation establishes a refcount, but .mmap_prepare is called at a point where a merge or an allocation failure might happen after the call, which would leak the refcount increment. Functionality is being added to permit the use of .mmap_prepare in this case, but in the interim, we need to fix this.

Published May 27, 2026 · Updated Aug 5, 2026

High · CVSS 7.8

CVE-2026-46093: mm/vmalloc: take vmap_purge_lock in shrinker

In the Linux kernel, the following vulnerability has been resolved: mm/vmalloc: take vmap_purge_lock in shrinker decay_va_pool_node() can be invoked concurrently from two paths: __purge_vmap_area_lazy() when pools are being purged, and the shrinker via vmap_node_shrink_scan(). However, decay_va_pool_node() is not safe to run concurrently, and the shrinker path currently lacks serialization, leading to races and possible leaks. Protect decay_va_pool_node() by taking vmap_purge_lock in the shrinker path to ensure serialization with purge users.

Published May 27, 2026 · Updated Aug 5, 2026

High · CVSS 7.5

CVE-2026-46085: rxrpc: Fix rxkad crypto unalignment handling

In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix rxkad crypto unalignment handling Fix handling of a packet with a misaligned crypto length. Also handle non-ENOMEM errors from decryption by aborting. Further, remove the WARN_ON_ONCE() so that it can't be remotely triggered (a trace line can still be emitted).

Published May 27, 2026 · Updated Aug 5, 2026

High · CVSS 7.8

CVE-2026-46081: crypto: acomp - fix wrong pointer stored by acomp_save_req()

In the Linux kernel, the following vulnerability has been resolved: crypto: acomp - fix wrong pointer stored by acomp_save_req() acomp_save_req() stores &req->chain in req->base.data. When acomp_reqchain_done() is invoked on asynchronous completion, it receives &req->chain as the data argument but casts it directly to struct acomp_req. Since data points to the chain member, all subsequent field accesses are at a wrong offset, resulting in memory corruption. The issue occurs when an asynchronous hardware implementation, such as the QAT driver, completes a request that uses the DMA virtual address interface (e.g. acomp_request_set_src_dma()). This combination causes crypto_acomp_compress() to enter the acomp_do_req_chain() path, which sets acomp_reqchain_done() as the completion callback via acomp_save_req(). With KASAN enabled, this manifests as a general protection fault in acomp_reqchain_done(): general protection fault, probably for non-canonical address 0xe000040000000000 KASAN: probably user-memory-access in range [0x0000400000000000-0x0000400000000007] RIP: 0010:acomp_reqchain_done+0x15b/0x4e0 Call Trace: <IRQ> qat_comp_alg_callback+0x5d/0xa0 [intel_qat] adf_ring_response_handler+0x376/0x8b0 [intel_qat] adf_response_handler+0x60/0x170 [intel_qat] tasklet_action_common+0x223/0x820 handle_softirqs+0x1ab/0x640 </IRQ> Fix this by storing the request itself in req->base.data instead of &req->chain, so that acomp_reqchain_done() receives the correct pointer. Simplify acomp_restore_req() accordingly to access req->chain directly.

Published May 27, 2026 · Updated Aug 5, 2026