{ "query": { "page": "83" }, "count": 20, "total": 48201, "page": 83, "limit": 20, "updated": { "cves": "2026-10-09T04:50:45.813Z", "kev": "2026-10-09T04:50:45.547Z", "epss": "2026-10-09T01:01:36.165Z", "breaches": "2026-10-09T00:49:35.859Z", "posts": "2026-10-09T04:50:45.812Z" }, "links": { "web": "https://spydr.io/threats?page=83", "next": "https://spydr.io/threats.json?page=84" }, "coverage": { "cves_published_since": "2026-06-11", "days": 120, "also": "every CVE in CISA KEV" }, "unscored_hidden": 0, "warnings": [], "results": [ { "id": "CVE-2026-98182", "url": "https://spydr.io/cve/CVE-2026-98182", "published": "2026-10-06T09:18:02.967Z", "modified": "2026-10-06T09:18:02.967Z", "score": null, "severity": null, "cvss_version": null, "vector": null, "score_source": null, "epss": 0.00175, "epss_percentile": 0.06415, "exploited": false, "kev": null, "ssvc_exploitation": null, "vendors": [ "Linux" ], "products": [ "Linux" ], "cwes": [], "description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: refuse to make a monitor active when it has no queue A monitor interface only gets a TXQ if it's created active, and one can't be added later. Setting the flag on a down interface is still allowed, so the driver is handed a monitor with no queue. ath9k dereferences it: BUG: kernel NULL pointer dereference, address: 0000000000000066 RIP: 0010:ath_tx_node_init+0x49/0x170 [ath9k] ath9k_add_interface+0x10c/0x140 [ath9k] drv_add_interface+0x54/0x250 [mac80211] ieee80211_do_open+0x32f/0x800 [mac80211] Reached with CAP_NET_ADMIN by \"iw dev X set monitor active\" followed by \"ip link set X up\". RTNL is held, so netlink operations block behind it. Refuse the flag when there is no queue to give." }, { "id": "CVE-2026-98181", "url": "https://spydr.io/cve/CVE-2026-98181", "published": "2026-10-06T09:18:02.807Z", "modified": "2026-10-06T09:18:02.807Z", "score": null, "severity": null, "cvss_version": null, "vector": null, "score_source": null, "epss": 0.00172, "epss_percentile": 0.0605, "exploited": false, "kev": null, "ssvc_exploitation": null, "vendors": [ "Linux" ], "products": [ "Linux" ], "cwes": [], "description": "In the Linux kernel, the following vulnerability has been resolved: drm/gud: fix out-of-bounds write in gud_plane_atomic_check() The plane property loop uses req->properties[num_properties + i] as write index while simultaneously incrementing `num_properties` inside the loop. At iteration i, num_properties has also incremented by i, so the write is done at `initial_num_properties + 2*i`, skipping every other index and advancing by 2 per iteration. With just 2 connector and 32 plane properties the last write happens at index 64, one slot past the end of the 64-slot (indices 0–63) allocation. A USB device can trigger OOB by advertising the maximum number of properties. Fix by dropping the redundant `+ i`; num_properties is already the correct running index, as gud_connector_fill_properties() fills the preceding slots." }, { "id": "CVE-2026-98180", "url": "https://spydr.io/cve/CVE-2026-98180", "published": "2026-10-06T09:18:01.617Z", "modified": "2026-10-07T07:17:04.363Z", "score": 7.1, "severity": "high", "cvss_version": "3.1", "vector": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H", "score_source": "CNA", "epss": 0.0012, "epss_percentile": 0.01672, "exploited": false, "kev": null, "ssvc_exploitation": null, "vendors": [ "Linux" ], "products": [ "Linux" ], "cwes": [], "description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm: RCU-free the scheduler-containing ring and VM objects Both struct msm_ringbuffer and struct msm_gem_vm embed a struct drm_gpu_scheduler. msm_ringbuffer_destroy() and the VM free callback msm_gem_vm_free() call drm_sched_fini() on the embedded scheduler and then free the containing object with plain kfree(). drm_sched_fence_get_timeline_name() returns fence->sched->name, and the scheduler fence keeps a .release callback so it is not ops-detached on signalling. A finished fence exported to userspace (the submit out-fence, or a VM_BIND fence, via sync_file / drm_syncobj) keeps pointing at the embedded scheduler after the ring/VM is freed, so a later get_timeline_name() -- reachable unprivileged through SYNC_IOC_FILE_INFO -- dereferences freed slab memory (KASAN slab-use-after-free read). Per the dma-fence lifetime contract the exporter must keep the data backing a signalled fence alive for an RCU grace period. Free the scheduler-containing objects with kfree_rcu() instead of kfree(). Patchwork: https://patchwork.freedesktop.org/patch/750234/" }, { "id": "CVE-2026-98179", "url": "https://spydr.io/cve/CVE-2026-98179", "published": "2026-10-06T09:18:00.123Z", "modified": "2026-10-06T09:18:00.123Z", "score": null, "severity": null, "cvss_version": null, "vector": null, "score_source": null, "epss": 0.00175, "epss_percentile": 0.06416, "exploited": false, "kev": null, "ssvc_exploitation": null, "vendors": [ "Linux" ], "products": [ "Linux" ], "cwes": [], "description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix rmmio iounmap skipped on device removal amdgpu_pci_remove() calls drm_dev_unplug() before fini_sw(), so drm_dev_enter() is already false there and the iounmap() guarded by it is skipped. This .remove path runs on both hot-unplug and plain rmmod, so the register BAR ioremap mapping leaks one instance per unload. Unmap rmmio unconditionally (guard only on non-NULL) and drop the now unused idx. (cherry picked from commit dd6f86a97260e5207d3329ad03aa89fdad61b1e6)" }, { "id": "CVE-2026-98178", "url": "https://spydr.io/cve/CVE-2026-98178", "published": "2026-10-06T09:17:59.930Z", "modified": "2026-10-06T09:17:59.930Z", "score": null, "severity": null, "cvss_version": null, "vector": null, "score_source": null, "epss": 0.00155, "epss_percentile": 0.04102, "exploited": false, "kev": null, "ssvc_exploitation": null, "vendors": [ "Linux" ], "products": [ "Linux" ], "cwes": [], "description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Skip KFD mapping clear before initialization amdgpu_amdkfd_clear_kfd_mapping() assumes that a non-NULL kfd_dev has a fully populated node array. This is not true when KFD device initialization fails after probe. For example, kgd2kfd_device_init() sets num_nodes before checking PCIe atomics support. On Polaris systems without the required atomics, it returns before allocating nodes[0], but the kfd_dev remains attached to the amdgpu device. A later GPU reset then dereferences nodes[0]->id. Require the authoritative KFD initialization flag before walking the node array, matching the existing KFD reset and teardown paths. (cherry picked from commit 4ac1835823c47903fbb278bbf474773c46f59edc)" }, { "id": "CVE-2026-98177", "url": "https://spydr.io/cve/CVE-2026-98177", "published": "2026-10-06T09:17:59.787Z", "modified": "2026-10-07T07:17:04.270Z", "score": null, "severity": null, "cvss_version": null, "vector": null, "score_source": null, "epss": 0.00155, "epss_percentile": 0.04101, "exploited": false, "kev": null, "ssvc_exploitation": null, "vendors": [ "Linux" ], "products": [ "Linux" ], "cwes": [], "description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Avoid integer underflow in EOP ring size calculation. The low 6 bits of cp_hqd_eop_control store the base-2 logarithm of the EOP ring size. This was calculated as order_base_2(q->eop_ring_buffer_size / 4) - 1 But order_base_2 can in theory return 0, so this could underflow (although in practice the ring buffer size cannot be less than 4096). Change this to order_base_2(q->eop_ring_buffer_size / 8) using properties of logarithms. Also add to the above comment to make the mathematics more clear. (cherry picked from commit f0f43fcf8b2b3a924cad9444340921c96ed5f634)" }, { "id": "CVE-2026-98176", "url": "https://spydr.io/cve/CVE-2026-98176", "published": "2026-10-06T09:17:59.653Z", "modified": "2026-10-07T07:17:04.167Z", "score": null, "severity": null, "cvss_version": null, "vector": null, "score_source": null, "epss": 0.00162, "epss_percentile": 0.04872, "exploited": false, "kev": null, "ssvc_exploitation": null, "vendors": [ "Linux" ], "products": [ "Linux" ], "cwes": [], "description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Avoid integer underflow with ffs in EOP ring size calc The low 6 bits of cp_hqd_eop_control store the base-2 logarithm of the EOP ring size. This was calculated as ffs(q->eop_ring_buffer_size / sizeof(unsigned int)) - 1 - 1 But ffs can in theory return 1 or 0, so this could underflow (although in practice the ring buffer size cannot be less than 4096). Change this to ffs(q->eop_ring_buffer_size / sizeof(unsigned int) / 4) using properties of logarithms. (cherry picked from commit 4f18c56630383c14bfc6b2d65f88f2f895d2121a)" }, { "id": "CVE-2026-98175", "url": "https://spydr.io/cve/CVE-2026-98175", "published": "2026-10-06T09:17:59.477Z", "modified": "2026-10-07T07:17:04.003Z", "score": 7.5, "severity": "high", "cvss_version": "3.1", "vector": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H", "score_source": "CNA", "epss": 0.00325, "epss_percentile": 0.23577, "exploited": false, "kev": null, "ssvc_exploitation": null, "vendors": [ "Linux" ], "products": [ "Linux" ], "cwes": [], "description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: cancel reconnect work in clean_demultiplex_info() clean_demultiplex_info() cancels server->echo delayed work but not server->reconnect, which can cause a use-after-free when the demultiplex thread exits while a reconnect work is still queued: cifs_demultiplex_thread() cifs_readv_from_socket() cifs_reconnect() __cifs_reconnect() cifs_queue_server_reconn() mod_delayed_work(cifsiod_wq, &server->reconnect, 0) clean_demultiplex_info() cancel_delayed_work_sync(&server->echo) // echo canceled // reconnect NOT canceled kfree_sensitive(server) // server freed ...later, on cifsiod_wq: smb2_reconnect_server() server->srv_count // UAF read of freed server Fix this by canceling server->reconnect delayed work in clean_demultiplex_info() before the server is freed, the same way cifs_put_tcp_session() already does." }, { "id": "CVE-2026-98174", "url": "https://spydr.io/cve/CVE-2026-98174", "published": "2026-10-06T09:17:59.220Z", "modified": "2026-10-07T07:17:03.870Z", "score": 7.5, "severity": "high", "cvss_version": "3.1", "vector": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H", "score_source": "CNA", "epss": 0.00365, "epss_percentile": 0.28299, "exploited": false, "kev": null, "ssvc_exploitation": null, "vendors": [ "Linux" ], "products": [ "Linux" ], "cwes": [], "description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix rlist race and missing initialization TCP_Server_Info.rlist is allocated via kzalloc which zeros both ->next and ->prev to NULL instead of pointing to itself, making list_empty() always return false and list_add() dereference a NULL ->prev pointer. Also, cifs_signal_cifsd_for_reconnect() can be called concurrently from multiple cifsd threads, allowing the same server's rlist node to be added twice into the local list, corrupting it." }, { "id": "CVE-2026-98173", "url": "https://spydr.io/cve/CVE-2026-98173", "published": "2026-10-06T09:17:59.060Z", "modified": "2026-10-07T07:17:03.737Z", "score": 7.5, "severity": "high", "cvss_version": "3.1", "vector": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H", "score_source": "CNA", "epss": 0.00325, "epss_percentile": 0.23577, "exploited": false, "kev": null, "ssvc_exploitation": null, "vendors": [ "Linux" ], "products": [ "Linux" ], "cwes": [], "description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix use-after-free of iface in cifs_try_adding_channels() cifs_try_adding_channels() iterates ses->iface_list with list_for_each_entry_safe_from(), which captures the next entry (niface) under iface_lock. The loop body then drops iface_lock for the whole duration of cifs_ses_add_channel(). A concurrent interface refresh (SMB3_request_interfaces() -> parse_server_interfaces()) marks all ifaces inactive and removes and frees any that are not re-advertised via list_del() + kref_put(), where release_iface() is a bare kfree(). Since niface typically has no channel holding a reference, the list reference is its last and it can be freed inside the unlocked window. On continue, the iterator advance step then dereferences niface->iface_head.next, and the loop body reads iface->rdma_capable/is_active, both on freed memory. Fix this by never keeping an unreferenced list pointer across the unlocked window. Each channel attempt now re-scans the list from the head under iface_lock, takes a kref on the selected candidate, and passes only that referenced candidate to cifs_ses_add_channel(). weight_fulfilled still tracks selection progress, so restarting the scan preserves the original weighted distribution and the weight_fulfilled-before-kref_put ordering on the failure path. Add a per-pass attempts cap so a flapping interface refresh cannot keep the inner loop spinning within a single tries increment." }, { "id": "CVE-2026-98172", "url": "https://spydr.io/cve/CVE-2026-98172", "published": "2026-10-06T09:17:58.920Z", "modified": "2026-10-06T09:17:58.920Z", "score": null, "severity": null, "cvss_version": null, "vector": null, "score_source": null, "epss": 0.00172, "epss_percentile": 0.0605, "exploited": false, "kev": null, "ssvc_exploitation": null, "vendors": [ "Linux" ], "products": [ "Linux" ], "cwes": [], "description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix smbd_connection leak on cifs_get_tcp_session() error When an RDMA connection is successfully established via smbd_get_connection() but cifs_get_tcp_session() later fails (e.g. kthread_create() returns an error), the error path frees tcp_ses without first destroying the smbd_connection. Fix this by calling smbd_destroy() in the out_err cleanup path before kfree(tcp_ses). smbd_destroy() safely handles the case where smbd_conn is NULL, so it can be called unconditionally." }, { "id": "CVE-2026-98171", "url": "https://spydr.io/cve/CVE-2026-98171", "published": "2026-10-06T09:17:58.773Z", "modified": "2026-10-07T07:17:03.600Z", "score": 8.8, "severity": "high", "cvss_version": "3.1", "vector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H", "score_source": "CNA", "epss": 0.00506, "epss_percentile": 0.41303, "exploited": false, "kev": null, "ssvc_exploitation": null, "vendors": [ "Linux" ], "products": [ "Linux" ], "cwes": [], "description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix next_buffer UAF and NextCommand bounds in compound PDUs Fix several related bounds checking and pointer lifecycle issues in receive_encrypted_standard()'s handling of compound encrypted frames: - Clear next_buffer after assigning it to server->bigbuf. A stale next_buffer pointer can lead to a use-after-free on subsequent error paths. - Update pdu_length to the decrypted plaintext size (buf_size). Using the pre-decryption length allows NextCommand to point into stale ciphertext residue. - Reject next_cmd values smaller than MID_HEADER_SIZE(server). - Fix an integer overflow in the upper bound check by verifying pdu_length - next_cmd < MID_HEADER_SIZE(server), ensuring the trailing slice is large enough for a header." }, { "id": "CVE-2026-98170", "url": "https://spydr.io/cve/CVE-2026-98170", "published": "2026-10-06T09:17:58.640Z", "modified": "2026-10-06T09:17:58.640Z", "score": null, "severity": null, "cvss_version": null, "vector": null, "score_source": null, "epss": 0.002, "epss_percentile": 0.09011, "exploited": false, "kev": null, "ssvc_exploitation": null, "vendors": [ "Linux" ], "products": [ "Linux" ], "cwes": [], "description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix OOB struct field reads in move_smb2_ea_to_cifs() In move_smb2_ea_to_cifs(), the while (src_size > 0) loop condition is insufficient. It allows iteration to continue even if the remaining src_size is too small to contain a complete smb2_ea_info structure. Consequently, reads of ea_name_length and ea_value_length can occur out-of-bounds. Fix this by ensuring src_size >= sizeof(*src) before attempting to read any structure fields. Additionally, reject any next_entry_offset that is smaller than sizeof(*src) or that would advance the pointer beyond the available buffer. Note that for calls where the server returns a malformed EA list, the error returned to userspace changes from -ENODATA (getxattr) or -ERANGE (listxattr) to -EIO. This correctly signals a server protocol error rather than misleadingly indicating \"attribute not present\" or \"output buffer too small\"." }, { "id": "CVE-2026-98169", "url": "https://spydr.io/cve/CVE-2026-98169", "published": "2026-10-06T09:17:58.480Z", "modified": "2026-10-07T07:17:03.450Z", "score": 7.1, "severity": "high", "cvss_version": "3.1", "vector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:H", "score_source": "CNA", "epss": 0.00432, "epss_percentile": 0.35534, "exploited": false, "kev": null, "ssvc_exploitation": null, "vendors": [ "Linux" ], "products": [ "Linux" ], "cwes": [], "description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential OOB read in smb3_enum_snapshots() If snapshot_array_size is smaller than GMT_TOKEN_SIZE, smb3_enum_snapshots() sets ret_data_len to sizeof(struct smb_snapshot_array) without verifying the actual length of the server's reply. Because SMB2_ioctl() places no lower bound on the server-supplied OutputCount and allocates retbuf to exactly that length, a short reply results in ret_data_len exceeding the size of retbuf. The subsequent copy_to_user() then reads past the end of retbuf, leaking adjacent slab memory to userspace. The subsequent clamp check is ineffective as it only reduces ret_data_len. Fix this by rejecting replies shorter than sizeof(struct smb_snapshot_array) with -EIO. Note that the bound is set to the 12-byte struct size rather than the 16-byte MIN_SNAPSHOT_ARRAY_SIZE defined in MS-SMB2 3.3.5.15.1, because 12 bytes is exactly what copy_to_user() attempts to read." }, { "id": "CVE-2026-98168", "url": "https://spydr.io/cve/CVE-2026-98168", "published": "2026-10-06T09:17:58.333Z", "modified": "2026-10-06T09:17:58.333Z", "score": null, "severity": null, "cvss_version": null, "vector": null, "score_source": null, "epss": 0.002, "epss_percentile": 0.09011, "exploited": false, "kev": null, "ssvc_exploitation": null, "vendors": [ "Linux" ], "products": [ "Linux" ], "cwes": [], "description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix reparse buffer bounds in cifs_query_reparse_point() In cifs_query_reparse_point(), the start >= end check before casting to struct reparse_data_buffer * only ensures the start pointer is within the response. It fails to verify that there is enough space remaining for the fixed 8-byte header of the structure. If a server provides a DataOffset that leaves less than 8 bytes remaining, the check passes, but subsequent reads of ReparseTag and ReparseDataLength will occur out-of-bounds. Fix this by ensuring the remaining space is at least the size of the reparse_data_buffer structure before accessing its fields." }, { "id": "CVE-2026-98167", "url": "https://spydr.io/cve/CVE-2026-98167", "published": "2026-10-06T09:17:58.177Z", "modified": "2026-10-06T09:17:58.177Z", "score": null, "severity": null, "cvss_version": null, "vector": null, "score_source": null, "epss": 0.00216, "epss_percentile": 0.11001, "exploited": false, "kev": null, "ssvc_exploitation": null, "vendors": [ "Linux" ], "products": [ "Linux" ], "cwes": [], "description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix server->total_read for compound encrypted PDUs In receive_encrypted_standard(), server->total_read is left at the full decrypted frame size when walking sub-PDUs of a compound encrypted frame. As a result, cifs_handle_standard() passes this full size to smb2_check_message(), causing the PDU length guards to incorrectly validate the entire compound frame instead of the current sub-PDU. This allows truncated non-last sub-PDUs to bypass length validation, leading to out-of-bounds reads in smb2_get_data_area_len(). Fix this by setting server->total_read to the true length of the current sub-PDU: next_cmd for non-last sub-PDUs, and the remaining pdu_length for the last one." }, { "id": "CVE-2026-98166", "url": "https://spydr.io/cve/CVE-2026-98166", "published": "2026-10-06T09:17:58.033Z", "modified": "2026-10-07T07:17:03.320Z", "score": 7.8, "severity": "high", "cvss_version": "3.1", "vector": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "score_source": "CNA", "epss": 0.00154, "epss_percentile": 0.03951, "exploited": false, "kev": null, "ssvc_exploitation": null, "vendors": [ "Linux" ], "products": [ "Linux" ], "cwes": [], "description": "In the Linux kernel, the following vulnerability has been resolved: drm/ttm: fix swapped-out resources never leaving their bulk_move range ttm_tt_swapout() returns the number of pages swapped out on success and a negative error code on failure; for a populated ttm it never returns zero. Commit b2ed01e7ad3d (\"drm/ttm: Fix ttm_bo_swapout() infinite LRU walk on swapout failure\") moved the bulk_move bookkeeping in ttm_bo_swapout_cb() under \"if (!ret)\", so the ttm_resource_del_bulk_move_unevictable() / ttm_resource_move_to_lru_tail() pair is now skipped on every successful swapout. The equivalent change for the shrinker in commit 1d59f36e95f7 (\"drm/ttm: Fix ttm_bo_shrink() infinite LRU walk on backup failure\") tests \"lret > 0\", which is what was intended here as well. Before b2ed01e7ad3d the resource was taken off the bulk_move before the swapout; since then a swapped-out resource stays inside its BO's bulk_move range (and on the manager LRU) although it is unevictable. When it is later freed or the BO leaves the bulk_move (ttm_resource_free(), ttm_bo_set_bulk_move() via amdgpu_vm_bo_del()), ttm_resource_del_bulk_move() skips it because of its !ttm_resource_unevictable() guard, so a range endpoint in pos->first / pos->last is left pointing at freed memory. The next ttm_lru_bulk_move_tail() or ttm_resource_add_bulk_move() on that cursor is a use-after-free, seen as the resv WARN in ttm_lru_bulk_move_add(), \"list_del corruption\" in ttm_resource_move_to_lru_tail() or a NULL dereference in ttm_resource_manager_next() -- minutes to hours after a hibernation, or at process exit / reboot following one. Samuel Ainsworth's analysis of drm/amd issue 5387 (see Link) identified the dangling cursor; the missing removal at swapout time is the reason it dangles. Testing the condition for success restores the removal. On an AMD Phoenix APU (ASUS UM3406GA, gfx1103) running suspend-then-hibernate on a 7.0.y stable kernel carrying the backport (Ubuntu 7.0.0-31) the bug crashed 5 of 18 hibernation cycles; a function profile of one hibernation showed 336 ttm_tt_swapout() calls and zero ttm_resource_del_bulk_move_unevictable() calls. With this change the removal happens for every swapped-out resource and 12 further cycles were clean." }, { "id": "CVE-2026-98165", "url": "https://spydr.io/cve/CVE-2026-98165", "published": "2026-10-06T09:17:57.887Z", "modified": "2026-10-06T09:17:57.887Z", "score": null, "severity": null, "cvss_version": null, "vector": null, "score_source": null, "epss": 0.00155, "epss_percentile": 0.04101, "exploited": false, "kev": null, "ssvc_exploitation": null, "vendors": [ "Linux" ], "products": [ "Linux" ], "cwes": [], "description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: restrict BAR0 fallback read to SR-IOV VFs only The BAR0 fallback read path was introduced as a workaround for SR-IOV VFs where the VRAM aperture is not available during early init. Restrict this workaround to only SR-IOV VFs where it's needed. (cherry picked from commit d8a0affd207c813bd063fa2c27786f449eaf92b8)" }, { "id": "CVE-2026-97308", "url": "https://spydr.io/cve/CVE-2026-97308", "published": "2026-10-06T09:17:57.740Z", "modified": "2026-10-06T15:04:52.637Z", "score": 4.8, "severity": "medium", "cvss_version": "3.1", "vector": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N", "score_source": "patchstack.com", "epss": 0.00193, "epss_percentile": 0.08161, "exploited": false, "kev": null, "ssvc_exploitation": "none", "vendors": [ "WebFactory" ], "products": [ "WebFactory Login Lockdown" ], "cwes": [ "CWE-290" ], "description": "Unauthenticated Bypass Vulnerability in Login Lockdown <= 2.17 versions." }, { "id": "CVE-2026-95594", "url": "https://spydr.io/cve/CVE-2026-95594", "published": "2026-10-06T09:17:57.577Z", "modified": "2026-10-06T15:04:25.990Z", "score": 8.1, "severity": "high", "cvss_version": "3.1", "vector": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H", "score_source": "patchstack.com", "epss": 0.00236, "epss_percentile": 0.13425, "exploited": false, "kev": null, "ssvc_exploitation": "none", "vendors": [ "Cozy Vision Technologies Pvt. Ltd." ], "products": [ "Cozy Vision Technologies Pvt. Ltd. SMS Alert Order Notifications" ], "cwes": [ "CWE-266" ], "description": "Unauthenticated Privilege Escalation in SMS Alert Order Notifications <= 4.0.0 versions." } ], "attribution": [ { "source": "NVD", "url": "https://nvd.nist.gov", "notice": "This product uses data from the NVD API but is not endorsed or certified by the NVD." }, { "source": "CISA KEV", "url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog", "notice": "Known exploited vulnerabilities from the CISA KEV catalog." }, { "source": "FIRST EPSS", "url": "https://www.first.org/epss", "notice": "Exploit prediction scores from FIRST EPSS." } ] }