CVSS: 7.2EPSS: 0%CPEs: 11EXPL: 0CVE-2025-39860 – Bluetooth: Fix use-after-free in l2cap_sock_cleanup_listen()
https://notcve.org/view.php?id=CVE-2025-39860
19 Sep 2025 — In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix use-after-free in l2cap_sock_cleanup_listen() syzbot reported the splat below without a repro. In the splat, a single thread calling bt_accept_dequeue() freed sk and touched it after that. The root cause would be the racy l2cap_sock_cleanup_listen() call added by the cited commit. bt_accept_dequeue() is called under lock_sock() except for l2cap_sock_release(). Two threads could see the same socket during the list iteration in... • https://git.kernel.org/stable/c/a2da00d1ea1abfb04f846638e210b5b5166e3c9c •
CVSS: 7.8EPSS: 0%CPEs: 2EXPL: 0CVE-2025-39859 – ptp: ocp: fix use-after-free bugs causing by ptp_ocp_watchdog
https://notcve.org/view.php?id=CVE-2025-39859
19 Sep 2025 — In the Linux kernel, the following vulnerability has been resolved: ptp: ocp: fix use-after-free bugs causing by ptp_ocp_watchdog The ptp_ocp_detach() only shuts down the watchdog timer if it is pending. However, if the timer handler is already running, the timer_delete_sync() is not called. This leads to race conditions where the devlink that contains the ptp_ocp is deallocated while the timer handler is still accessing it, resulting in use-after-free bugs. The following details one of the race scenarios. ... • https://git.kernel.org/stable/c/773bda96492153e11d21eb63ac814669b51fc701 • CWE-416: Use After Free •
CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2025-39857 – net/smc: fix one NULL pointer dereference in smc_ib_is_sg_need_sync()
https://notcve.org/view.php?id=CVE-2025-39857
19 Sep 2025 — In the Linux kernel, the following vulnerability has been resolved: net/smc: fix one NULL pointer dereference in smc_ib_is_sg_need_sync() BUG: kernel NULL pointer dereference, address: 00000000000002ec PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP PTI CPU: 28 UID: 0 PID: 343 Comm: kworker/28:1 Kdump: loaded Tainted: G OE 6.17.0-rc2+ #9 NONE Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 Workqueue: smc_hs_wq smc_listen_work [smc] RIP: 0010:sm... • https://git.kernel.org/stable/c/0ef69e788411cba2af017db731a9fc62d255e9ac •
CVSS: 7.8EPSS: 0%CPEs: 3EXPL: 0CVE-2025-39854 – ice: fix NULL access of tx->in_use in ice_ll_ts_intr
https://notcve.org/view.php?id=CVE-2025-39854
19 Sep 2025 — In the Linux kernel, the following vulnerability has been resolved: ice: fix NULL access of tx->in_use in ice_ll_ts_intr Recent versions of the E810 firmware have support for an extra interrupt to handle report of the "low latency" Tx timestamps coming from the specialized low latency firmware interface. Instead of polling the registers, software can wait until the low latency interrupt is fired. This logic makes use of the Tx timestamp tracking structure, ice_ptp_tx, as it uses the same "ready" bitmap to t... • https://git.kernel.org/stable/c/82e71b226e0ef770d7bc143701c8b4960b4eb3d5 • CWE-416: Use After Free •
CVSS: 5.6EPSS: 0%CPEs: 8EXPL: 0CVE-2025-39853 – i40e: Fix potential invalid access when MAC list is empty
https://notcve.org/view.php?id=CVE-2025-39853
19 Sep 2025 — In the Linux kernel, the following vulnerability has been resolved: i40e: Fix potential invalid access when MAC list is empty list_first_entry() never returns NULL - if the list is empty, it still returns a pointer to an invalid object, leading to potential invalid memory access when dereferenced. Fix this by using list_first_entry_or_null instead of list_first_entry. In the Linux kernel, the following vulnerability has been resolved: i40e: Fix potential invalid access when MAC list is empty list_first_entr... • https://git.kernel.org/stable/c/e3219ce6a775468368fb270fae3eb82a6787b436 •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2025-39852 – net/tcp: Fix socket memory leak in TCP-AO failure handling for IPv6
https://notcve.org/view.php?id=CVE-2025-39852
19 Sep 2025 — In the Linux kernel, the following vulnerability has been resolved: net/tcp: Fix socket memory leak in TCP-AO failure handling for IPv6 When tcp_ao_copy_all_matching() fails in tcp_v6_syn_recv_sock() it just exits the function. This ends up causing a memory-leak: unreferenced object 0xffff0000281a8200 (size 2496): comm "softirq", pid 0, jiffies 4295174684 hex dump (first 32 bytes): 7f 00 00 06 7f 00 00 06 00 00 00 00 cb a8 88 13 ................ 0a 00 03 61 00 00 00 00 00 00 00 00 00 00 00 00 ...a............. • https://git.kernel.org/stable/c/06b22ef29591f625ef877ae00d82192938e29e60 • CWE-401: Missing Release of Memory after Effective Lifetime •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2025-39851 – vxlan: Fix NPD when refreshing an FDB entry with a nexthop object
https://notcve.org/view.php?id=CVE-2025-39851
19 Sep 2025 — In the Linux kernel, the following vulnerability has been resolved: vxlan: Fix NPD when refreshing an FDB entry with a nexthop object VXLAN FDB entries can point to either a remote destination or an FDB nexthop group. The latter is usually used in EVPN deployments where learning is disabled. However, when learning is enabled, an incoming packet might try to refresh an FDB entry that points to an FDB nexthop group and therefore does not have a remote. Such packets should be dropped, but they are only dropped... • https://git.kernel.org/stable/c/1274e1cc42264d4e629841e4f182795cb0becfd2 • CWE-476: NULL Pointer Dereference •
CVSS: 6.6EPSS: 0%CPEs: 3EXPL: 0CVE-2025-39850 – vxlan: Fix NPD in {arp,neigh}_reduce() when using nexthop objects
https://notcve.org/view.php?id=CVE-2025-39850
19 Sep 2025 — In the Linux kernel, the following vulnerability has been resolved: vxlan: Fix NPD in {arp,neigh}_reduce() when using nexthop objects When the "proxy" option is enabled on a VXLAN device, the device will suppress ARP requests and IPv6 Neighbor Solicitation messages if it is able to reply on behalf of the remote host. That is, if a matching and valid neighbor entry is configured on the VXLAN device whose MAC address is not behind the "any" remote (0.0.0.0 / ::). The code currently assumes that the FDB entry ... • https://git.kernel.org/stable/c/1274e1cc42264d4e629841e4f182795cb0becfd2 • CWE-476: NULL Pointer Dereference •
CVSS: 7.8EPSS: 0%CPEs: 6EXPL: 0CVE-2025-39849 – wifi: cfg80211: sme: cap SSID length in __cfg80211_connect_result()
https://notcve.org/view.php?id=CVE-2025-39849
19 Sep 2025 — In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: sme: cap SSID length in __cfg80211_connect_result() If the ssid->datalen is more than IEEE80211_MAX_SSID_LEN (32) it would lead to memory corruption so add some bounds checking. In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: sme: cap SSID length in __cfg80211_connect_result() If the ssid->datalen is more than IEEE80211_MAX_SSID_LEN (32) it would lead to memory corruption so add some bound... • https://git.kernel.org/stable/c/dd43f8f90206054e7da7593de0a334fb2cd0ea88 • CWE-787: Out-of-bounds Write •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2025-39848 – ax25: properly unshare skbs in ax25_kiss_rcv()
https://notcve.org/view.php?id=CVE-2025-39848
19 Sep 2025 — In the Linux kernel, the following vulnerability has been resolved: ax25: properly unshare skbs in ax25_kiss_rcv() Bernard Pidoux reported a regression apparently caused by commit c353e8983e0d ("net: introduce per netns packet chains"). skb->dev becomes NULL and we crash in __netif_receive_skb_core(). Before above commit, different kind of bugs or corruptions could happen without a major crash. But the root cause is that ax25_kiss_rcv() can queue/mangle input skb without checking if this skb is shared or no... • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 •