Threats Tagged 'cve-2026-53385'
View all threats tagged with 'cve-2026-53385'. Filter and sort to focus on specific types of threats.
Stop chasing alerts. Route them.
Start free, then upgrade once to turn Radar into an automated delivery engine for your security stack.
Custom feeds / Automations: email, Slack, webhooks, SIEM/MISP / API access (baseline limits)
API access activates after upgrading in Console -> Billing.
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.
Filter Threats
Narrow down the results by type, severity, or affected countries
Threats Tagged 'cve-2026-53385'
Click on any threat for detailed analysis and mitigation recommendations
kernel-devel-7.1.4-1.1 on GA mediaCVE-2026-53366 0 These are all security issues fixed in the kernel-devel-7.1.4-1.1 package on the GA media of openSUSE Tumbleweed. Join the discussion | GCVE Database | 07/22/2026, 00:00:00 UTC Added: 07/17/2026, 10:15:02 UTC |
0 These are all security issues fixed in the kernel-devel-7.1.4-1.1 package on the GA media of openSUSE Tumbleweed. Join the discussion | GCVE Database | 07/22/2026, 00:00:00 UTC Added: 07/16/2026, 10:35:33 UTC |
A null pointer dereference vulnerability was identified and resolved in the Linux kernel's vc_screen component, specifically in the vcs_notifier() function during concurrent vcs_write operations. The issue arises from a race condition where the vc_data pointer may become NULL after re-acquiring a lock, but the code still calls vcs_scr_updated() with this NULL pointer, causing a null pointer dereference. This vulnerability can lead to a denial of service (system crash). Join the discussion | GCVE Database | 07/19/2026, 12:30:22 UTC Added: 07/19/2026, 19:38:21 UTC |
In the Linux kernel, the following vulnerability has been resolved: vc_screen: fix null-ptr-deref in vcs_notifier() during concurrent vcs_write A KASAN null-ptr-deref was observed in vcs_notifier(): BUG: KASAN: null-ptr-deref in vcs_notifier+0x98/0x130 Read of size 2 at addr qmp_cmd_name: qmp_capabilities, arguments: {} The issue is a race condition in vcs_write(). When the console_lock is temporarily dropped (to copy data from userspace), the vc_data pointer obtained from vcs_vc() may become stale. After re-acquiring the lock, vcs_vc() is called again to re-validate the pointer. If the vc has been deallocated in the meantime, vcs_vc() returns NULL, and the while loop breaks (with written > 0). However, after the loop, vcs_scr_updated(vc) is still called with the now-NULL vc pointer, leading to a null pointer dereference in the notifier chain (vcs_notifier dereferences param->vc). Fix this by adding a NULL check for vc before calling vcs_scr_updated(). Join the discussion | GCVE Database | 07/19/2026, 12:16:00 UTC Added: 07/21/2026, 20:03:03 UTC |
In the Linux kernel, the following vulnerability has been resolved: rxrpc: Also unshare DATA/RESPONSE packets when paged frags are present The DATA-packet handler in rxrpc_input_call_event() and the RESPONSE handler in rxrpc_verify_response() copy the skb to a linear one before calling into the security ops only when skb_cloned() is true. An skb that is not cloned but still carries externally-owned paged fragments (e.g. SKBFL_SHARED_FRAG set by splice() into a UDP socket via __ip_append_data, or a chained skb_has_frag_list()) falls through to the in-place decryption path, which binds the frag pages directly into the AEAD/skcipher SGL via skb_to_sgvec(). Extend the gate to also unshare when skb_has_frag_list() or skb_has_shared_frag() is true. This catches the splice-loopback vector and other externally-shared frag sources while preserving the zero-copy fast path for skbs whose frags are kernel-private (e.g. NIC page_pool RX, GRO). The OOM/trace handling already in place is reused. Join the discussion | GCVE Database | 05/11/2026, 08:16:00 UTC Added: 07/18/2026, 11:19:29 UTC |
Showing 1 to 5 of 5 results