CVE-2026-64025
CriticalCVSS 9.8Exploitation Probability (EPSS)
Low risk36th percentile - higher than 36% of all known CVEs
Summary
In the Linux kernel, a vulnerability in the BPF skmsg mechanism was found where sk_psock_verdict_data_ready() does not check for a TLS RX context, causing a race condition with ktls reception. This can lead to a use-after-free condition during data processing.
Risk Assessment
An attacker could exploit this vulnerability to gain unauthorized access to kernel memory, potentially leading to privilege escalation or sensitive data leakage.
Recommendation
Immediately update the Linux kernel to a version containing the fix (commit adding a TLS RX guard in sk_psock_verdict_data_ready()).
Other vulnerabilities in Linux kernel
See all- CVE-2026-90046High
In the Linux kernel, free_pages_nolock() uses spin_trylock() in NMI context on uniprocessor (UP) systems, which is unsafe. The bug affects the page freeing path and can crash the kernel. It is likely exploitable by local attackers for privilege escalation.
- CVE-2026-90045High
In the Linux kernel USB gadget ffs driver, the io_data structure stores a pointer to the submitting task's mm_struct but does not hold a reference while async requests are pending. This can cause a use-after-free if the task exits before completion handling finishes. The fix takes a reference with mmgrab() when queuing and releases it with mmdrop() on completion.
- CVE-2026-90044High
In the Linux kernel USB gadget f_fs driver, a use-after-free exists in the AIO error path. When ffs_epfile_io() fails with an error other than -EIOCBQUEUED, the io_data structure is freed, but the kiocb cancel function remains armed and points to the freed pointer. A concurrent cancel (e.g., sys_io_cancel()) can cause a use-after-free. The fix safely disarms the cancellation via kiocb->ki_complete() and returns -EIOCBQUEUED.
- CVE-2026-90043High
In the Linux kernel zram module, the slot lock bit is set in the wrong position on 64-bit big-endian systems. Instead of landing in the flags field, it lands in ac_time, so with ZRAM_TRACK_ENTRY_ACTIME enabled, storing the access time wipes out the held lock bit and lets another CPU take the same slot lock. An access time value with that bit set can make the slot appear locked forever. The fix shifts the lock bit into the flags half on big-endian 64-bit.
- CVE-2026-90041High
In the Linux kernel, the HID sony driver fails to remove a controller from the device list when HID core input device registration fails. The devres-managed sony_sc is freed while its list node remains linked, leading to use-after-free when the next matching controller is handled.
- CVE-2026-90039Unknown
In the Linux kernel, NFSD admin state-revocation handlers (unlock_filesystem, NFSD_CMD_UNLOCK_FILESYSTEM, NFSD_CMD_UNLOCK_EXPORT) only check nn->nfsd_serv, which is set before nn->conf_id_hashtbl is allocated. This leads to a NULL dereference when the server has not yet started.
- CVE-2026-90035Unknown
In the Linux kernel, get_estimated_bw() in the drm/amd/display driver divides by bw_granularity, which is zeroed and only populated after DP_TUNNELING_BW_ALLOC_CAP_CHANGED is handled. If a USB4/DPIA device reports an estimated-bandwidth change before a capability change, the DPCD interrupt handler triggers a division by zero.
- CVE-2026-90034Unknown
In the Linux kernel, the usb image mdc800 driver uses kmalloc() for irq_urb_buffer and download_urb_buffer in usb_mdc800_init(). If a shorter message is received in mdc800_usb_irq() or mdc800_usb_download_notify(), stack data may leak.
- CVE-2026-90033Unknown
In the Linux kernel, snd_usbmidi_us122l_output() in ALSA usb-audio picks a count of 2 for anything slower than high speed without relating it to ep->max_transfer. With a device declaring a one-byte bulk endpoint, the memset computes 1 - 2 in int and wraps to SIZE_MAX, causing an out-of-bounds write.
- CVE-2026-90024Unknown
A null-pointer dereference vulnerability exists in the Linux kernel's USB gadget MIDI 2.0 function, specifically in f_midi2_free_ep_reqs(). When configuring a MIDI 2.0 gadget via configfs with block direction set to SNDRV_UMP_DIR_INPUT, the midi1_ep_out endpoint is not initialized, leaving usb_ep->card as NULL. When the host later sets the alternate setting, f_midi2_free_ep_reqs() is called for the uninitialized endpoint, causing a kernel crash.
Original NVD description (English source)
In the Linux kernel, the following vulnerability has been resolved: bpf, skmsg: fix verdict sk_data_ready racing with ktls rx sk_psock_strp_data_ready() already checks tls_sw_has_ctx_rx() and defers to psock->saved_data_ready when a TLS RX context is present, avoiding a conflict with the TLS strparser's ownership of the receive queue (commit e91de6afa81c, "bpf: Fix running sk_skb program types with ktls"). sk_psock_verdict_data_ready() has no equivalent guard. When a socket is inserted into a sockmap (BPF_SK_SKB_VERDICT) before TLS RX is configured, tls_sw_strparser_arm() saves sk_psock_verdict_data_ready as rx_ctx->saved_data_ready. On data arrival: tls_data_ready -> tls_strp_data_ready -> tls_rx_msg_ready -> saved_data_ready() = sk_psock_verdict_data_ready() -> tcp_read_skb() drains sk_receive_queue via __skb_unlink() without calling tcp_eat_skb(), so copied_seq is not advanced. tls_strp_msg_load() then finds tcp_inq() >= full_len (stale), calls tcp_recv_skb() on the now-empty queue, hits WARN_ON_ONCE(!first), and returns with rx_ctx->strp.anchor.frag_list pointing at a psock-owned (potentially freed) skb. tls_decrypt_sg() subsequently walks that frag_list: use-after-free. Apply the same fix as sk_psock_strp_data_ready(): if a TLS RX context is present, call psock->saved_data_ready (sock_def_readable) to wake recv() waiters and return immediately, leaving the receive queue untouched. TLS retains sole ownership of the queue and decrypts the record normally through tls_sw_recvmsg().