{
  "query": {
    "page": "33"
  },
  "count": 20,
  "total": 47348,
  "page": 33,
  "limit": 20,
  "updated": {
    "cves": "2026-10-07T00:46:23.556Z",
    "kev": "2026-10-07T01:46:10.380Z",
    "epss": "2026-10-07T00:58:23.423Z",
    "breaches": "2026-10-07T00:46:23.055Z",
    "posts": "2026-10-07T01:47:10.349Z"
  },
  "links": {
    "web": "https://spydr.io/threats?page=33",
    "next": "https://spydr.io/threats.json?page=34"
  },
  "warnings": [],
  "results": [
    {
      "id": "CVE-2026-98333",
      "url": "https://spydr.io/cve/CVE-2026-98333",
      "published": "2026-10-06T09:18:25.780Z",
      "modified": "2026-10-06T09:18:25.780Z",
      "score": null,
      "severity": null,
      "cvss_version": null,
      "vector": null,
      "score_source": null,
      "epss": 0.00162,
      "epss_percentile": 0.04844,
      "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: reset the LED state when ifup fails When the first interface comes up, the radio LED is turned on. This can start the TPT trigger timer, which continues running. But if bringing up the interface fails then the timer keeps running and won't be stopped by anything, eventually it can be freed: ODEBUG: free active (active state 0) object: ffff888127e12130 object type: timer_list hint: tpt_trig_timer+0x0/0x300 net/mac80211/led.c:145 WARNING: CPU: 0 PID: 5923 at lib/debugobjects.c:612 debug_print_object+0x1a2/0x2b0 debug_check_no_obj_freed+0x4b7/0x600 lib/debugobjects.c:1129 kfree+0x436/0x670 mm/slub.c:6818 ieee80211_led_exit+0x162/0x1c0 net/mac80211/led.c:210 ieee80211_unregister_hw+0x27e/0x3a0 net/mac80211/main.c:1706 rt2x00lib_remove_dev+0x55b/0x670 Undo the LED state in the error path."
    },
    {
      "id": "CVE-2026-98332",
      "url": "https://spydr.io/cve/CVE-2026-98332",
      "published": "2026-10-06T09:18:25.657Z",
      "modified": "2026-10-06T09:18:25.657Z",
      "score": null,
      "severity": null,
      "cvss_version": null,
      "vector": null,
      "score_source": null,
      "epss": 0.00162,
      "epss_percentile": 0.04843,
      "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: only operate on TDLS peers in the TDLS code ieee80211_tdls_oper() can operate on the AP station, which then yields various warnings when the AP station is removed then or at a later point in time after being confused for a TDLS peer. Always check that the station is a TDLS peer."
    },
    {
      "id": "CVE-2026-98331",
      "url": "https://spydr.io/cve/CVE-2026-98331",
      "published": "2026-10-06T09:18:25.517Z",
      "modified": "2026-10-06T09:18:25.517Z",
      "score": null,
      "severity": null,
      "cvss_version": null,
      "vector": null,
      "score_source": null,
      "epss": 0.0018,
      "epss_percentile": 0.06922,
      "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: unlist vifs when their netdev is unregistered mac80211 only removes vifs from the local->interfaces list when an interface is removed via ieee80211_if_remove(), before it unregisters the netdev. However, it's possible for a netdev to be unregistered without going through that: When the netns that holds the wiphy is destroyed, the wiphy is supposed to move to the init_ns, but that can run into allocation failures. Then, mac80211 has an interface listed that doesn't exist, and will eventually hit BUG: failure at net/wireless/core.h:141/wiphy_to_rdev()! ... _cfg80211_unregister_wdev+0x24/0x36a [cfg80211] cfg80211_unregister_wdev+0x15/0x1d [cfg80211] ieee80211_remove_interfaces+0x1ff/0x257 [mac80211] ieee80211_unregister_hw+0x73/0x1d1 [mac80211] mac80211_hwsim_del_radio+0x114/0x166 [mac80211_hwsim] Remove the interface from the list in ->ndo_uninit if it's still around to avoid this."
    },
    {
      "id": "CVE-2026-98330",
      "url": "https://spydr.io/cve/CVE-2026-98330",
      "published": "2026-10-06T09:18:25.387Z",
      "modified": "2026-10-06T09:18:25.387Z",
      "score": null,
      "severity": null,
      "cvss_version": null,
      "vector": null,
      "score_source": null,
      "epss": 0.00173,
      "epss_percentile": 0.06152,
      "exploited": false,
      "kev": null,
      "ssvc_exploitation": null,
      "vendors": [
        "Linux"
      ],
      "products": [
        "Linux"
      ],
      "cwes": [],
      "description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: get the wiphy out of a dying network namespace When a network namespace is destroyed, cfg80211_pernet_exit() moves any wiphy back to the initial namespace, and just warns if that fails. But moving an interface can fail (due to allocation failures), and then the wiphy is left behind with a garbage netns pointer: Kernel mode fault at addr 0x30 genlmsg_multicast_netns.constprop.0+0x46/0xcf [cfg80211] nl80211_notify_wiphy+0xcd/0xe8 [cfg80211] wiphy_unregister+0x169/0x3fc [cfg80211] Note that commit debac3a20dec (\"net: Remove conflicting altnames for dying netns in __dev_change_net_namespace().\") fixed another path that could reach it without allocation failures. Remove interfaces that cannot be moved instead of failing the switch, so that the wiphy always ends up in the initial namespace. In this case the netdev core will unregister the interfaces anyway."
    },
    {
      "id": "CVE-2026-98329",
      "url": "https://spydr.io/cve/CVE-2026-98329",
      "published": "2026-10-06T09:18:25.250Z",
      "modified": "2026-10-06T09:18:25.250Z",
      "score": null,
      "severity": null,
      "cvss_version": null,
      "vector": null,
      "score_source": null,
      "epss": 0.00175,
      "epss_percentile": 0.06387,
      "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: don't allow injecting frames wider than the chanctx Frames injected on a monitor interface can carry a radiotap field requesting a bandwidth, which mac80211 passes down to the driver regardless of the the actual operational bandwidth. If the bandwidth requested is too wide, that triggers a warning in hwsim: WARN_ON(hwsim_get_chanwidth(bw) > hwsim_get_chanwidth(confbw)) Drop such frames entirely instead since they cannot be sent."
    },
    {
      "id": "CVE-2026-98328",
      "url": "https://spydr.io/cve/CVE-2026-98328",
      "published": "2026-10-06T09:18:25.110Z",
      "modified": "2026-10-06T09:18:25.110Z",
      "score": null,
      "severity": null,
      "cvss_version": null,
      "vector": null,
      "score_source": null,
      "epss": 0.0018,
      "epss_percentile": 0.06918,
      "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: add HE 6 GHz capability in the scan elems len The HE 6 GHz Band Capability element is in the probe request for every band if 6 GHz is supported, so add the size to scan_ies_len. Otherwise, building probe request elements can fail, triggering the WARN_ON in __ieee80211_start_scan()."
    },
    {
      "id": "CVE-2026-98327",
      "url": "https://spydr.io/cve/CVE-2026-98327",
      "published": "2026-10-06T09:18:24.980Z",
      "modified": "2026-10-06T09:18:24.980Z",
      "score": null,
      "severity": null,
      "cvss_version": null,
      "vector": null,
      "score_source": null,
      "epss": 0.00175,
      "epss_percentile": 0.06387,
      "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: mesh: reset the CSA state when leaving ifmsh->csa is allocated in ieee80211_mesh_csa_beacon() and only freed in ieee80211_mesh_finish_csa(), i.e. when the channel switch completes. Leaving the mesh while a switch is still pending therefore leaks it. Additionally, ifmsh->csa_role and ifmsh->chsw_ttl have their state leak in this case, so things can get mixed up in addition to the memory leak. Refactor the reset and call it in ieee80211_stop_mesh() to fix it all."
    },
    {
      "id": "CVE-2026-98326",
      "url": "https://spydr.io/cve/CVE-2026-98326",
      "published": "2026-10-06T09:18:24.840Z",
      "modified": "2026-10-06T09:18:24.840Z",
      "score": null,
      "severity": null,
      "cvss_version": null,
      "vector": null,
      "score_source": null,
      "epss": 0.0018,
      "epss_percentile": 0.06922,
      "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: mesh: release the channel if start fails ieee80211_join_mesh() acquires a channel context and then calls ieee80211_start_mesh(), which can fail. In that case, the chanctx isn't released then interface removal will attempt to unassign it after it's removed from the driver, hitting: wlan0: Failed check-sdata-in-driver check, flags: 0x0 WARNING: net/mac80211/driver-ops.c:366 at drv_unassign_vif_chanctx ieee80211_assign_link_chanctx __ieee80211_link_release_channel ieee80211_link_release_channel ieee80211_teardown_sdata unregister_netdevice_many_notify _cfg80211_unregister_wdev ieee80211_remove_interfaces ieee80211_unregister_hw mac80211_hwsim_del_radio hwsim_exit_net Correctly release the channel on start failures."
    },
    {
      "id": "CVE-2026-98325",
      "url": "https://spydr.io/cve/CVE-2026-98325",
      "published": "2026-10-06T09:18:24.693Z",
      "modified": "2026-10-06T09:18:24.693Z",
      "score": null,
      "severity": null,
      "cvss_version": null,
      "vector": null,
      "score_source": null,
      "epss": 0.0018,
      "epss_percentile": 0.06921,
      "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: set up the TX info early to fix failure paths The previous commit 2c51457d930f (\"wifi: mac80211: free ack status frame on TX header build failure\") cleaned up the leak, but still left the code a bit messy and the failed SKB didn't get reported to userspace. Fix this up by initialising skb->cb[] earlier, which allows using ieee80211_free_txskb() and therefore reports it for the failure in ieee80211_build_hdr(), and unifies the ieee80211_skb_resize() failure path with it."
    },
    {
      "id": "CVE-2026-98324",
      "url": "https://spydr.io/cve/CVE-2026-98324",
      "published": "2026-10-06T09:18:24.573Z",
      "modified": "2026-10-06T09:18:24.573Z",
      "score": null,
      "severity": null,
      "cvss_version": null,
      "vector": null,
      "score_source": null,
      "epss": 0.00162,
      "epss_percentile": 0.04846,
      "exploited": false,
      "kev": null,
      "ssvc_exploitation": null,
      "vendors": [
        "Linux"
      ],
      "products": [
        "Linux"
      ],
      "cwes": [],
      "description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: pxa: fix double counting of the hw descriptors pxad_alloc_desc() was converted from kzalloc(struct_size(sw_desc, hw_desc, nb_hw_desc), GFP_NOWAIT) to kzalloc_flex(), which sets the __counted_by() counter sw_desc->nb_desc itself - but only where the compiler has __builtin_counted_by_ref(), so from gcc 15.1 or clang 22.1 on. The loop below it still increments nb_desc, which makes it come out doubled there and correct elsewhere. nb_desc is what pxad_free_desc() iterates over and what set_updater_desc() indexes from, so set it explicitly and drop the increment. The error path has to lower it to the number of descriptors allocated so far, otherwise pxad_free_desc() would free entries that were never allocated."
    },
    {
      "id": "CVE-2026-98323",
      "url": "https://spydr.io/cve/CVE-2026-98323",
      "published": "2026-10-06T09:18:24.403Z",
      "modified": "2026-10-06T09:18:24.403Z",
      "score": null,
      "severity": null,
      "cvss_version": null,
      "vector": null,
      "score_source": null,
      "epss": 0.00184,
      "epss_percentile": 0.07298,
      "exploited": false,
      "kev": null,
      "ssvc_exploitation": null,
      "vendors": [
        "Linux"
      ],
      "products": [
        "Linux"
      ],
      "cwes": [],
      "description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Bound fragmented header copies by the remaining length siw_get_hdr() can receive an extended DDP/RDMAP header across more than one TCP callback. The first callback may receive most of the header, while the next one still limits the copy to hdrlen - MIN_DDP_HDR instead of the number of missing bytes. This makes the destination move past the end of the header and overwrite the receive state, including fpdu_part_rcvd. A later callback can then use a negative fpdu_part_rcvd value as a copy offset, which creates an OOB write. Use the number of header bytes already received when calculating the next copy length."
    },
    {
      "id": "CVE-2026-98322",
      "url": "https://spydr.io/cve/CVE-2026-98322",
      "published": "2026-10-06T09:18:24.243Z",
      "modified": "2026-10-06T09:18:24.243Z",
      "score": null,
      "severity": null,
      "cvss_version": null,
      "vector": null,
      "score_source": null,
      "epss": 0.0022,
      "epss_percentile": 0.11344,
      "exploited": false,
      "kev": null,
      "ssvc_exploitation": null,
      "vendors": [
        "Linux"
      ],
      "products": [
        "Linux"
      ],
      "cwes": [],
      "description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_nat: fully initialise new_addr in netmap setup nft_nat_setup_netmap() builds the mapped address in an on-stack union nf_inet_addr. For an IPv4 mapping it writes only the 4-byte .ip member and the loop runs a single 32-bit iteration, but it then copies the whole 16-byte union into range->min_addr and range->max_addr, so the upper 12 bytes reach nf_nat_setup_info() uninitialised. KMSAN reports an uninit-value in nf_nat_setup_info() reached from nft_nat_eval(). The IPv6 path fills all 16 bytes and is not affected. Zero-initialise new_addr."
    },
    {
      "id": "CVE-2026-98321",
      "url": "https://spydr.io/cve/CVE-2026-98321",
      "published": "2026-10-06T09:18:24.117Z",
      "modified": "2026-10-06T09:18:24.117Z",
      "score": null,
      "severity": null,
      "cvss_version": null,
      "vector": null,
      "score_source": null,
      "epss": 0.00173,
      "epss_percentile": 0.06151,
      "exploited": false,
      "kev": null,
      "ssvc_exploitation": null,
      "vendors": [
        "Linux"
      ],
      "products": [
        "Linux"
      ],
      "cwes": [],
      "description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_nat: unregister and release hooks on error If nf_hook_entries_insert_raw() fails, the NAT hooks get never released, resulting in a memleak. Postpone setting nat_proto_net->nat_hook_ops when the hooks are registered to simplify the error path to decide whether the nat hooks need unwinding."
    },
    {
      "id": "CVE-2026-98320",
      "url": "https://spydr.io/cve/CVE-2026-98320",
      "published": "2026-10-06T09:18:23.957Z",
      "modified": "2026-10-06T09:18:23.957Z",
      "score": null,
      "severity": null,
      "cvss_version": null,
      "vector": null,
      "score_source": null,
      "epss": 0.0022,
      "epss_percentile": 0.11344,
      "exploited": false,
      "kev": null,
      "ssvc_exploitation": null,
      "vendors": [
        "Linux"
      ],
      "products": [
        "Linux"
      ],
      "cwes": [],
      "description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: hold reference on ct until flow is released nf_ct_put() releases the ct->ext area inmediately, the rcu typesafe semantics also allow to refer to the wrong conntrack from the flowtable datapath. Hold reference on ct until flow is released after rcu grace period. Add rcu_barrier() on module exit path, to ensure pending flow entries are release before module goes away."
    },
    {
      "id": "CVE-2026-98319",
      "url": "https://spydr.io/cve/CVE-2026-98319",
      "published": "2026-10-06T09:18:23.800Z",
      "modified": "2026-10-06T09:18:23.800Z",
      "score": null,
      "severity": null,
      "cvss_version": null,
      "vector": null,
      "score_source": null,
      "epss": 0.0022,
      "epss_percentile": 0.11344,
      "exploited": false,
      "kev": null,
      "ssvc_exploitation": null,
      "vendors": [
        "Linux"
      ],
      "products": [
        "Linux"
      ],
      "cwes": [],
      "description": "In the Linux kernel, the following vulnerability has been resolved: drm: Fix drm_pending_vblank_event leak in error path for out_fence_ptr When an out_fence_ptr is provided but DRM_MODE_PAGE_FLIP_EVENT is not set, a drm_pending_vblank_event will be allocated. If later, there is an allocation failure or another failure at setup_out_fence(), that event will not have base.fence set and it will not be released at complete_signaling(). Release the event and set crtc_state->event to NULL just like in the DRM_MODE_PAGE_FLIP_EVENT case when there is a failure at drm_event_reserve_init(). That is, prepare_signaling() releases the event and there is nothing to be done at complete_signaling(). Use drm_event_cancel_free() as that will also undo drm_event_reserve_init() in case it has been called."
    },
    {
      "id": "CVE-2026-98318",
      "url": "https://spydr.io/cve/CVE-2026-98318",
      "published": "2026-10-06T09:18:23.670Z",
      "modified": "2026-10-06T09:18:23.670Z",
      "score": null,
      "severity": null,
      "cvss_version": null,
      "vector": null,
      "score_source": null,
      "epss": 0.00162,
      "epss_percentile": 0.04846,
      "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: validate absolute native symlink targets before NT fixups With symlinkroot unset, an absolute target is copied without conversion to an NT drive path. Later code still assumes an NT prefix is present when modifying the target and calculating the print name length. For \"/ab\", this causes two failures: sym[5] and path[5] are written past their allocations, and plen -= 2 * poff subtracts an assumed 8-byte prefix from a 6-byte UTF-16 target, wrapping u16 plen to 65534. That underflow causes another overflow: memcpy() copies 65534 bytes into a 24-byte buffer. A user with write access to a mounted share can trigger these bugs with default settings. Validate the NT drive prefix, including an ASCII drive letter, before accessing fixed offsets or subtracting the prefix length."
    },
    {
      "id": "CVE-2026-98317",
      "url": "https://spydr.io/cve/CVE-2026-98317",
      "published": "2026-10-06T09:18:23.530Z",
      "modified": "2026-10-06T09:18:23.530Z",
      "score": null,
      "severity": null,
      "cvss_version": null,
      "vector": null,
      "score_source": null,
      "epss": 0.00184,
      "epss_percentile": 0.07257,
      "exploited": false,
      "kev": null,
      "ssvc_exploitation": null,
      "vendors": [
        "Linux"
      ],
      "products": [
        "Linux"
      ],
      "cwes": [],
      "description": "In the Linux kernel, the following vulnerability has been resolved: neighbour: Enforce min/max to NDTPA_INTERVAL_PROBE_TIME_MS. NDTPA_INTERVAL_PROBE_TIME_MS sets .type and .min but misses .validation_type, so no validation is applied: # ynl --family rt-neigh --do setneightbl \\ --json '{\"name\": \"arp_cache\", \"parms\": {\"interval-probe-time-ms\": 0}}' # ynl --family rt-neigh --dump getneightbl --output-json | \\ jq '.[] | select(.name == \"arp_cache\" and has(\"config\")) | .parms[\"interval-probe-time-ms\"]' 0 Moreover, nla_get_msecs() uses msecs_to_jiffies(), and u64 is silently cast to u32, so a larger value can bypass the min check: e.g. 4294967296 == 0x100000000 # ynl --family rt-neigh --do setneightbl \\ --json '{\"name\": \"arp_cache\", \"parms\": {\"interval-probe-time-ms\": 4294967296}}' # ynl --family rt-neigh --dump getneightbl --output-json | \\ jq '.[] | select(.name == \"arp_cache\" and has(\"config\")) | .parms[\"interval-probe-time-ms\"]' 0 msecs_to_jiffies() returns MAX_JIFFY_OFFSET if the value is larger than INT_MAX. Also, INT_MAX ms overflows int NEIGH_VAR() when HZ > 1000 (Alpha, MIPS), and passing a negative integer to queue_delayed_work(unsigned long delay) causes sign extension, which wraps around the expiry time to the past, resulting in it being handled as 0 delay in the timer wheel. Let's use NLA_POLICY_FULL_RANGE() and limit the max to 1 day. The same max check is applied to sysctl as well. Note that this controls the probe interval for NTF_MANAGED entries, so the max of 1 day is unlikely to break any deployments."
    },
    {
      "id": "CVE-2026-98316",
      "url": "https://spydr.io/cve/CVE-2026-98316",
      "published": "2026-10-06T09:18:23.363Z",
      "modified": "2026-10-06T09:18:23.363Z",
      "score": null,
      "severity": null,
      "cvss_version": null,
      "vector": null,
      "score_source": null,
      "epss": 0.0018,
      "epss_percentile": 0.06919,
      "exploited": false,
      "kev": null,
      "ssvc_exploitation": null,
      "vendors": [
        "Linux"
      ],
      "products": [
        "Linux"
      ],
      "cwes": [],
      "description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: bcd2000: Fix race between rawmidi and disconnect Although we tried to fix the potential UAF issues at USB disconnect on bcd2000 driver, there is still an overlooked case -- namely, when a rawmidi trigger callback has been already running at USB disconnect handling, the in-flight function (e.g. bcd2000_midi_send()) could still access the URB, because the previous URB NULL-check & clearance was considered only for the URB complete callbacks, but not about the parallel rawmidi operations. For addressing the race, this patch introduced a new spinlock that covers each rawmidi operation as well as the rawmidi handling in the complete callback. The URB is cleared with the lock, so it guarantees that the pending rawmidi task already finished or a NULL check is effective."
    },
    {
      "id": "CVE-2026-98315",
      "url": "https://spydr.io/cve/CVE-2026-98315",
      "published": "2026-10-06T09:18:23.200Z",
      "modified": "2026-10-06T09:18:23.200Z",
      "score": null,
      "severity": null,
      "cvss_version": null,
      "vector": null,
      "score_source": null,
      "epss": 0.00162,
      "epss_percentile": 0.04842,
      "exploited": false,
      "kev": null,
      "ssvc_exploitation": null,
      "vendors": [
        "Linux"
      ],
      "products": [
        "Linux"
      ],
      "cwes": [],
      "description": "In the Linux kernel, the following vulnerability has been resolved: ntfs: protect runlist updates with the runlist lock ntfs_non_resident_attr_shrink() calls runlist helpers that require the runlist write lock, but did not hold it while freeing clusters and truncating the runlist. Serialize those operations and the resident conversion with the runlist lock. ntfs_attr_map_cluster() can merge a newly allocated run before updating mapping pairs. If the update fails, free the clusters and restore both the in-memory runlist and on-disk mapping pairs from a saved runlist. Mark the volume in error if either rollback step fails."
    },
    {
      "id": "CVE-2026-98314",
      "url": "https://spydr.io/cve/CVE-2026-98314",
      "published": "2026-10-06T09:18:23.033Z",
      "modified": "2026-10-06T09:18:23.033Z",
      "score": null,
      "severity": null,
      "cvss_version": null,
      "vector": null,
      "score_source": null,
      "epss": 0.00184,
      "epss_percentile": 0.07297,
      "exploited": false,
      "kev": null,
      "ssvc_exploitation": null,
      "vendors": [
        "Linux"
      ],
      "products": [
        "Linux"
      ],
      "cwes": [],
      "description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: set timer->private_data before registering the PCM timer snd_pcm_timer_init() calls snd_device_register() to link the new struct snd_timer into the global timer list while it still carries hw.c_resolution = snd_pcm_timer_resolution (and hw.start/hw.stop), and only afterwards sets timer->private_data = substream. Once the timer is on the list under register_mutex, a concurrent reader can already reach it through the same mutex and invoke these callbacks. /proc/asound/timers does this via c_resolution(), and snd_timer_open()+snd_timer_start() reach start()/stop() the same way. All three dereference timer->private_data, which for this brief window is NULL, giving a NULL-pointer dereference: substream = timer->private_data; return substream->runtime ? ... // substream is NULL Move the private_data/private_free assignment before snd_device_register() so the timer is never visible on the list without its private_data set. On the snd_device_register() failure path, private_free() (snd_pcm_timer_free()) can now run, but it only does substream->timer = NULL, which is already NULL at that point since substream->timer is set to the new timer just once, after a successful registration -- so the failure path stays safe."
    }
  ],
  "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."
    }
  ]
}
