A security vulnerability has been detected in Telegram Desktop up to 6.7.5. This vulnerability affects the function RequestButton of the file Telegram/SourceFiles/boxes/url_auth_box.cpp of the component Bot API. The manipulation of the argument login_url leads to null pointer dereference. It is possible to initiate the attack remotely. The exploit has been disclosed publicly and may be used. There is ongoing doubt regarding the real existence of this vulnerability. Upgrading to version 6.7.6 is able to resolve this issue. Upgrading the affected component is recommended. The vendor provides this rationale for the dispute: "[T]he described scenario does not lead to any security issue or vulnerability, and only causes a one-time crash. In the outlined scenario, the targeted user must perform an active action, which doesn't produce any consequences after the app is relaunched."
A vulnerability was identified in YunaiV yudao-cloud up to 2026.01. This affects the function getDataBySQL of the file yudao-module-report-biz/src/main/java/io/github/ruoyi/report/service/impl/GoViewDataServiceImpl.java. Such manipulation leads to sql injection. It is possible to launch the attack remotely. The exploit is publicly available and might be used. The vendor explains: "[T]he SQL execution feature and existing report:go-view-data:get-by-sql functional permission remain. We are not adding a super-administrator restriction, default-off switch or independent-datasource enforcement in this batch. SQL access granted through that permission must be limited to trusted roles and appropriate database privileges; this item is not reported as patched."
CVE-2026-43201 is a vulnerability related to ARM processor error handling in Microsoft software version 3.0. The issue involves improper handling of allocated memory boundaries, potentially leading to memory access errors. No CVSS score or detailed impact information is provided.
A vulnerability identified as CVE-2026-31698 involves the Microsoft cryptographic component where an attempt is made to copy a PDH certificate to userspace even if the PSP command failed. The advisory references Microsoft's support lifecycle but provides no detailed technical or impact information.
This vulnerability involves the Microsoft cryptographic component (ccp) where the system attempts to copy a Certificate Signing Request (CSR) to userspace even if the Platform Security Processor (PSP) command has failed. The issue is identified in Microsoft product version 3.0. No CVSS score or detailed impact information is provided.
This vulnerability involves the Microsoft product version 3.0 where an issue occurs in the crypto component related to the ccp module. Specifically, the flaw is that the system attempts to copy an ID to userspace even if the PSP command has failed. The description does not provide further technical details or impact information.
CVE-2026-46179 is a vulnerability in Microsoft software version 3.0 that involves improper pointer operations on unconfigured streams. The issue relates to the handling of streams that have not been properly configured, potentially leading to unintended behavior. No CVSS score or detailed technical impact information is provided. There are no known exploits in the wild, and no patch or remediation details have been disclosed.
CVE-2026-46127 is a vulnerability in Microsoft software related to the RDMA/ocrdma component, where a NULL pointer dereference can occur on errors in the function ocrdma_copy_pd_uresp(). This issue may cause the software to crash or behave unexpectedly when handling certain error conditions.
CVE-2026-45912 is a vulnerability related to the ext4 filesystem implementation, specifically concerning caching behavior during extent splitting. The available information is limited and does not provide technical details beyond the title or describe exploitation methods or impacts. There is no CVSS score or detailed vendor advisory content available to clarify the severity or remediation status. No known exploits in the wild have been reported. The affected products include Microsoft and Azure Linux 3.0 versions. Patch status is not confirmed, and no official fix or mitigation guidance is provided.
CVE-2026-31767 is a medium-severity vulnerability in the Linux kernel's drm/i915/dsi driver. It involves improper horizontal timing adjustments for Display Stream Compression (DSC) in command mode, which could cause a division-by-zero error leading to a kernel crash. The issue was fixed by stopping these adjustments in command mode, aligning behavior with the Windows driver and hardware specifications.
CVE-2026-31775 is a medium severity vulnerability in the Linux kernel ALSA ctxfi driver. A recent refactoring caused the driver to incorrectly enumerate the SPDIF1 audio interface during DAIO initialization, which is only valid for a specific hardware model (hw20k1) but not for hw20k2. This mismatch leads to a kernel crash on hw20k2 devices. The issue was previously mitigated by a workaround commit, and now a proper fix has been implemented by skipping the SPDIF1 enumeration in the parser loop.
In the Linux kernel, the following vulnerability has been resolved: sched_ext: Fix stale direct dispatch state in ddsp_dsq_id @p->scx.ddsp_dsq_id can be left set (non-SCX_DSQ_INVALID) triggering a spurious warning in mark_direct_dispatch() when the next wakeup's ops.select_cpu() calls scx_bpf_dsq_insert(), such as: WARNING: kernel/sched/ext.c:1273 at scx_dsq_insert_commit+0xcd/0x140 The root cause is that ddsp_dsq_id was only cleared in dispatch_enqueue(), which is not reached in all paths that consume or cancel a direct dispatch verdict. Fix it by clearing it at the right places: - direct_dispatch(): cache the direct dispatch state in local variables and clear it before dispatch_enqueue() on the synchronous path. For the deferred path, the direct dispatch state must remain set until process_ddsp_deferred_locals() consumes them. - process_ddsp_deferred_locals(): cache the dispatch state in local variables and clear it before calling dispatch_to_local_dsq(), which may migrate the task to another rq. - do_enqueue_task(): clear the dispatch state on the enqueue path (local/global/bypass fallbacks), where the direct dispatch verdict is ignored. - dequeue_task_scx(): clear the dispatch state after dispatch_dequeue() to handle both the deferred dispatch cancellation and the holding_cpu race, covering all cases where a pending direct dispatch is cancelled. - scx_disable_task(): clear the direct dispatch state when transitioning a task out of the current scheduler. Waking tasks may have had the direct dispatch state set by the outgoing scheduler's ops.select_cpu() and then been queued on a wake_list via ttwu_queue_wakelist(), when SCX_OPS_ALLOW_QUEUED_WAKEUP is set. Such tasks are not on the runqueue and are not iterated by scx_bypass(), so their direct dispatch state won't be cleared. Without this clear, any subsequent SCX scheduler that tries to direct dispatch the task will trigger the WARN_ON_ONCE() in mark_direct_dispatch().
In the Linux kernel, the following vulnerability has been resolved: perf/x86: Fix potential bad container_of in intel_pmu_hw_config Auto counter reload may have a group of events with software events present within it. The software event PMU isn't the x86_hybrid_pmu and a container_of operation in intel_pmu_set_acr_caused_constr (via the hybrid helper) could cause out of bound memory reads. Avoid this by guarding the call to intel_pmu_set_acr_caused_constr with an is_x86_event check.
In the Linux kernel, the following vulnerability has been resolved: drm/xe/pxp: Clear restart flag in pxp_start after jumping back If we don't clear the flag we'll keep jumping back at the beginning of the function once we reach the end. (cherry picked from commit 0850ec7bb2459602351639dccf7a68a03c9d1ee0)
In the Linux kernel, the following vulnerability has been resolved: scsi: target: file: Use kzalloc_flex for aio_cmd The target_core_file doesn't initialize the aio_cmd->iocb for the ki_write_stream. When a write command fd_execute_rw_aio() is executed, we may get a bogus ki_write_stream value, causing unintended write failure status when checking iocb->ki_write_stream > max_write_streams in the block device. Let's just use kzalloc_flex when allocating the aio_cmd and let ki_write_stream=0 to fix this issue.
In the Linux kernel, the following vulnerability has been resolved: HID: multitouch: Check to ensure report responses match the request It is possible for a malicious (or clumsy) device to respond to a specific report's feature request using a completely different report ID. This can cause confusion in the HID core resulting in nasty side-effects such as OOB writes. Add a check to ensure that the report ID in the response, matches the one that was requested. If it doesn't, omit reporting the raw event and return early.
In the Linux kernel, the following vulnerability has been resolved: crypto: krb5enc - fix async decrypt skipping hash verification krb5enc_dispatch_decrypt() sets req->base.complete as the skcipher callback, which is the caller's own completion handler. When the skcipher completes asynchronously, this signals "done" to the caller without executing krb5enc_dispatch_decrypt_hash(), completely bypassing the integrity verification (hash check). Compare with the encrypt path which correctly uses krb5enc_encrypt_done as an intermediate callback to chain into the hash computation on async completion. Fix by adding krb5enc_decrypt_done as an intermediate callback that chains into krb5enc_dispatch_decrypt_hash() upon async skcipher completion, matching the encrypt path's callback pattern. Also fix EBUSY/EINPROGRESS handling throughout: remove krb5enc_request_complete() which incorrectly swallowed EINPROGRESS notifications that must be passed up to callers waiting on backlogged requests, and add missing EBUSY checks in krb5enc_encrypt_ahash_done for the dispatch_encrypt return value. Unset MAY_BACKLOG on the async completion path so the user won't see back-to-back EINPROGRESS notifications.