high CVSS 8.8

CVE-2025-39862·Kernel vulnerability

In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: fix list corruption after hardware restart Since stations are recreated from scratch, all lists that wcids are added to must be cleared before calling ieee80211_restart_hw. Set wcid->sta = 0 for each wcid entry in order to ensure that they are not added again before they are ready.

Severity
high
Software
Kernel
Fixed in
6.16.6
Published
2025-09-19

Affected versions

From: 6.2

Until: 6.16.6

Fixed in: 6.16.6

How to fix this CVE

Update your Linux kernel to version 6.16.6 or later to patch a critical list corruption vulnerability in the MediaTek MT7915 WiFi driver that occurs during hardware restart operations. This vulnerability can cause kernel memory corruption and system instability when wireless devices are reinitialized. Apply the kernel update immediately and schedule a reboot to activate the patched version.

sudo dnf update kernel kernel-devel

Defensia detects this vulnerability

How to check if you are affected

  1. Step 1: Check your installed kernel version with 'uname -r' and compare against the vulnerable range (6.2 to 6.16.5)
  2. Step 2: Verify if MT7915 WiFi driver is loaded by running 'lsmod | grep mt7915' or check 'ethtool -i <interface>' for driver details
  3. Step 3: Search kernel logs for hardware restart events and list corruption indicators with 'dmesg | grep -E "mt7915|wcid|list_corruption|restart"'
  4. Step 4: After patching, confirm the new kernel version with 'uname -r' and verify it shows 6.16.6 or later

FAQ

What is CVE-2025-39862?

This vulnerability affects the MediaTek MT7915 WiFi driver in the Linux kernel, where station list structures become corrupted when the wireless hardware undergoes a restart cycle. The driver fails to properly clear internal station lists before reinitializing, causing stale memory references that can lead to kernel crashes or memory corruption.

Is CVE-2025-39862 being actively exploited?

No, there is no evidence of active exploitation in the wild, and no public exploits are available. However, the high CVSS score (8.8) reflects the severity of potential local impacts.

What versions of Kernel are affected by CVE-2025-39862?

Linux kernel versions 6.2 through 6.16.5 are vulnerable. Systems running kernel 6.16.6 or later, or versions before 6.2, are not affected.

How do I check if my server is vulnerable to CVE-2025-39862?

Run 'uname -r' to get your kernel version; if it falls between 6.2 and 6.16.5 and you have an MT7915 wireless device (check with 'lsmod | grep mt7915'), your system is vulnerable.

Does Defensia detect CVE-2025-39862?

Yes — Defensia's CVE advisory scanner compares installed package versions against the NVD database. If Linux kernel is installed on a monitored server, CVE-2025-39862 will appear in your dashboard with remediation steps.

Related Kernel CVEs

CVE-2026-100075CVSS 9.8In the Linux kernel, the following vulnerability has been resolved: RDMA/srpt: Fix srpt_alloc_rw_ctxs() unwind counters When srpt_alloc_rw_ctxs() fails partway through a multi-buffer indirect descriptor, the unwind path destroys RDMA contexts but leaves stale n_rw_ctx and n_rdma values (and a dangling rw_ctxs pointer). Later sq_wr_avail accounting in srpt_queue_response() or srpt_write_pending() can then subtract the wrong number of send queue credits. Reset the counters and clear rw_ctxs after freeing the heap allocation before returning an error.
CVE-2026-64439CVSS 9.8In the Linux kernel, the following vulnerability has been resolved: crypto: krb5 - filter out async aead implementations at alloc krb5_aead_encrypt(), krb5_aead_decrypt() in rfc3961_simplified.c and rfc8009_encrypt(), rfc8009_decrypt() in rfc8009_aes2.c set a NULL completion callback and treat any negative return from crypto_aead_{encrypt,decrypt}() as terminal, falling through to kfree_sensitive(buffer). When the encrypt_name resolves to an async AEAD instance the request returns -EINPROGRESS, the buffer is freed while the backend's worker still holds a pointer, and the worker dereferences the freed slab on completion. KASAN report under UML+SLUB with a synthetic async aead backend bound to krb5->encrypt_name: BUG: KASAN: slab-use-after-free in t5_stub_complete+0x7d/0xc7 The helpers were written synchronously, so filter the async instances out at allocation time instead of plumbing crypto_wait_req() through every call site. Reachable via net/rxrpc/rxgk.c, fs/afs/cm_security.c and net/ceph/crypto.c on systems with an async AEAD provider bound to the krb5 enctype name.
CVE-2026-64055CVSS 9.8In the Linux kernel, the following vulnerability has been resolved: net: ethernet: cortina: Carry over frag counter The gmac_rx() NAPI poll function assembles packets in an SKB from a ring buffer. If the ring buffer gets completely emptied during a poll cycle, we exit gmac_rx(), but the packet is not yet completely assembled in the SKB, yet the fragment counter frag_nr is reset to zero on the next invocation. Solve this by making the RX fragment counter a part of the port struct, and carry it over between invocations. Reset the fragment counter only right after calling napi_gro_frags(), on error (after calling napi_free_frags()) or if stopping the port. Reset it in some place where not strictly necessary just to emphasize what is going on. This was found by Sashiko during normal patch review.
CVE-2026-64061CVSS 9.8In the Linux kernel, the following vulnerability has been resolved: netfs: Fix early put of sink folio in netfs_read_gaps() Fix netfs_read_gaps() to release the sink page it uses after waiting for the request to complete. The way the sink page is used is that an ITER_BVEC-class iterator is created that has the gaps from the target folio at either end, but has the sink page tiled over the middle so that a single read op can fill in both gaps. The bug was found by KASAN detecting a UAF on the generic/075 xfstest in the cifsd kernel thread that handles reception of data from the TCP socket: BUG: KASAN: use-after-free in _copy_to_iter+0x48a/0xa20 Write of size 885 at addr ffff888107f92000 by task cifsd/1285 CPU: 2 UID: 0 PID: 1285 Comm: cifsd Not tainted 7.0.0 #6 PREEMPT(lazy) Call Trace: dump_stack_lvl+0x5d/0x80 print_report+0x17f/0x4f1 kasan_report+0x100/0x1e0 kasan_check_range+0x10f/0x1e0 __asan_memcpy+0x3c/0x60 _copy_to_iter+0x48a/0xa20 __skb_datagram_iter+0x2c9/0x430 skb_copy_datagram_iter+0x6e/0x160 tcp_recvmsg_locked+0xce0/0x1130 tcp_recvmsg+0xeb/0x300 inet_recvmsg+0xcf/0x3a0 sock_recvmsg+0xea/0x100 cifs_readv_from_socket+0x3a6/0x4d0 [cifs] cifs_read_iter_from_socket+0xdd/0x130 [cifs] cifs_readv_receive+0xaad/0xb10 [cifs] cifs_demultiplex_thread+0x1148/0x1740 [cifs] kthread+0x1cf/0x210
CVE-2026-64056CVSS 9.8In the Linux kernel, the following vulnerability has been resolved: net: ethernet: cortina: Make RX SKB per-port The SKB used to assemble packets from fragments in gmac_rx() is static local, but the Gemini has two ethernet ports, meaning there can be races between the ports on a bad day if a device is using both. Make the RX SKB a per-port variable and carry it over between invocations in the port struct instead. Zero the pointer once we call napi_gro_frags(), on error (after calling napi_free_frags()) or if the port is stopped. Zero it in some place where not strictly necessary just to emphasize what is going on. This was found by Sashiko during normal patch review.

References

Track CVEs across your fleet automatically

Defensia scans your Linux servers and tells you exactly which ones are running vulnerable versions — including CVE-2025-39862. Free for 1 server.

Get started free