{ "query": { "page": "45" }, "count": 20, "total": 47466, "page": 45, "limit": 20, "updated": { "cves": "2026-10-07T12:47:36.253Z", "kev": "2026-10-07T12:46:35.984Z", "epss": "2026-10-07T12:59:36.323Z", "breaches": "2026-10-07T12:47:35.891Z", "posts": "2026-10-07T12:47:36.253Z" }, "links": { "web": "https://spydr.io/threats?page=45", "next": "https://spydr.io/threats.json?page=46" }, "warnings": [], "results": [ { "id": "CVE-2026-98211", "url": "https://spydr.io/cve/CVE-2026-98211", "published": "2026-10-06T09:18:07.497Z", "modified": "2026-10-06T09:18:07.497Z", "score": null, "severity": null, "cvss_version": null, "vector": null, "score_source": null, "epss": 0.00209, "epss_percentile": 0.10067, "exploited": false, "kev": null, "ssvc_exploitation": null, "vendors": [ "Linux" ], "products": [ "Linux" ], "cwes": [], "description": "In the Linux kernel, the following vulnerability has been resolved: mmc: mmci: Fix use-after-free in busy-timeout work ux500_busy_complete() can queue ux500_busy_timeout_work for an R1b command, but mmci_remove() never cancels it. The work can subsequently dereference the devm-allocated mmci_host after it has been released. Mask the controller interrupts and disable the delayed work during removal. This drains any queued instance and stops an IRQ handler that is still in progress from queueing the work again once it has been disabled. This issue was found by an in-house static analysis tool." }, { "id": "CVE-2026-98210", "url": "https://spydr.io/cve/CVE-2026-98210", "published": "2026-10-06T09:18:07.333Z", "modified": "2026-10-06T09:18:07.333Z", "score": null, "severity": null, "cvss_version": null, "vector": null, "score_source": null, "epss": 0.00184, "epss_percentile": 0.07305, "exploited": false, "kev": null, "ssvc_exploitation": null, "vendors": [ "Linux" ], "products": [ "Linux" ], "cwes": [], "description": "In the Linux kernel, the following vulnerability has been resolved: mmc: mxcmmc: cancel data work and watchdog on remove mxcmci_remove() frees the host through the devm tail, but neither it nor mmc_remove_host() drains the driver's own asynchronous state. host->watchdog, a 10 s timer armed on the DMA path in mxcmci_setup_data(), is deleted only by the DMA- and IRQ-complete paths, which the remove path does not explicitly drain; it can therefore fire after the host is freed and dereference it in mxcmci_watchdog(). host->datawork, armed from the IRQ handler on the PIO path, is not cancelled by the remove path either. Free the devm-registered IRQ, then cancel datawork and delete the watchdog in mxcmci_remove(), before dma_release_channel(). Freeing the IRQ first keeps a trailing handler from re-arming datawork between the cancel and the host free. Both callbacks are non-self-rearming. This issue was found by an in-house static analysis tool." }, { "id": "CVE-2026-98209", "url": "https://spydr.io/cve/CVE-2026-98209", "published": "2026-10-06T09:18:07.173Z", "modified": "2026-10-06T09:18:07.173Z", "score": null, "severity": null, "cvss_version": null, "vector": null, "score_source": null, "epss": 0.0022, "epss_percentile": 0.11352, "exploited": false, "kev": null, "ssvc_exploitation": null, "vendors": [ "Linux" ], "products": [ "Linux" ], "cwes": [], "description": "In the Linux kernel, the following vulnerability has been resolved: mmc: sdhci-of-aspeed: Remove children before releasing SDC resources Probe failure and removal leave SDHCI child devices registered after the parent clock and managed resources are released. Unregister the OF children in reverse order before disabling the parent clock on both paths. Use of_platform_device_destroy() because manual child creation does not set the flag required by of_platform_depopulate(). This issue was identified during our ongoing static-analysis research while reviewing kernel code." }, { "id": "CVE-2026-98208", "url": "https://spydr.io/cve/CVE-2026-98208", "published": "2026-10-06T09:18:07.017Z", "modified": "2026-10-06T09:18:07.017Z", "score": null, "severity": null, "cvss_version": null, "vector": null, "score_source": null, "epss": 0.00184, "epss_percentile": 0.07306, "exploited": false, "kev": null, "ssvc_exploitation": null, "vendors": [ "Linux" ], "products": [ "Linux" ], "cwes": [], "description": "In the Linux kernel, the following vulnerability has been resolved: mmc: sdio_uart: fix xmit_fifo leak when the port table is full sdio_uart_add_port() allocates the transmit fifo before claiming a slot in sdio_uart_table[]. When all UART_NR slots are taken, it returns -EBUSY with the fifo still allocated, but the probe error path only kfree()s the port, leaking the transmit fifo. Free the fifo in the failure path of sdio_uart_add_port() itself so the function retains nothing on error." }, { "id": "CVE-2026-98207", "url": "https://spydr.io/cve/CVE-2026-98207", "published": "2026-10-06T09:18:06.843Z", "modified": "2026-10-06T09:18:06.843Z", "score": null, "severity": null, "cvss_version": null, "vector": null, "score_source": null, "epss": 0.00184, "epss_percentile": 0.07303, "exploited": false, "kev": null, "ssvc_exploitation": null, "vendors": [ "Linux" ], "products": [ "Linux" ], "cwes": [], "description": "In the Linux kernel, the following vulnerability has been resolved: mmc: spi: reset bytes_xfered before retrying CRC failures mmc_spi_data_do() updates data->bytes_xfered after each block has been transferred successfully. If a later block in the same data request fails with a CRC error, data->bytes_xfered may therefore contain the number of bytes completed before the failing block. mmc_spi_request() has a private recovery path for such CRC failures. It sends STOP_TRANSMISSION, clears data->error and jumps back to crc_recover to issue the same command and data request again. However, it does not clear data->bytes_xfered before the retry. If the retry succeeds, the request is completed with the bytes from the failed attempt still included in data->bytes_xfered. For a multi-block request this can make the completed request report more bytes than were transferred by the successful retry, and can even exceed the request size when most blocks completed before the CRC error. This is most likely to be observed on MMC-over-SPI systems where long multi-block transfers occasionally hit a data CRC error but the mmc_spi-internal retry succeeds. The data itself is retried, but the completion accounting is not. Clear data->bytes_xfered together with data->error before repeating the request so the final completion reports only the bytes transferred by the successful attempt." }, { "id": "CVE-2026-98206", "url": "https://spydr.io/cve/CVE-2026-98206", "published": "2026-10-06T09:18:06.710Z", "modified": "2026-10-06T09:18:06.710Z", "score": null, "severity": null, "cvss_version": null, "vector": null, "score_source": null, "epss": 0.00175, "epss_percentile": 0.06385, "exploited": false, "kev": null, "ssvc_exploitation": null, "vendors": [ "Linux" ], "products": [ "Linux" ], "cwes": [], "description": "In the Linux kernel, the following vulnerability has been resolved: Input: cyttsp5 - clamp the HID report size before memcpy The size field comes from the device and is used as the memcpy() length into response_buf, which is CY_MAX_INPUT bytes." }, { "id": "CVE-2026-98205", "url": "https://spydr.io/cve/CVE-2026-98205", "published": "2026-10-06T09:18:06.547Z", "modified": "2026-10-06T09:18:06.547Z", "score": null, "severity": null, "cvss_version": null, "vector": null, "score_source": null, "epss": 0.00184, "epss_percentile": 0.07303, "exploited": false, "kev": null, "ssvc_exploitation": null, "vendors": [ "Linux" ], "products": [ "Linux" ], "cwes": [], "description": "In the Linux kernel, the following vulnerability has been resolved: Input: evdev - zero absinfo before partial copy in EVIOCSABS The EVIOCSABS handler copies at most the user supplied ioctl size into an uninitialized on-stack struct input_absinfo: if (copy_from_user(&abs, p, min_t(size_t, size, sizeof(struct input_absinfo)))) The size comes from _IOC_SIZE() of the ioctl command and is therefore fully controlled by userspace. A short size leaves the trailing part of the structure holding whatever was on the kernel stack, and the whole structure is then stored into the device: dev->absinfo[t] = abs; EVIOCGABS hands that back to userspace, disclosing the stale stack bytes. Only the resolution field is currently cleared, which covers the legacy struct layout but not an arbitrarily short size. Zero the structure before the copy so any part not supplied by the caller reads back as zero. The existing resolution fixup is kept, since it also handles a size that partially overlaps that field." }, { "id": "CVE-2026-98204", "url": "https://spydr.io/cve/CVE-2026-98204", "published": "2026-10-06T09:18:06.383Z", "modified": "2026-10-06T09:18:06.383Z", "score": null, "severity": null, "cvss_version": null, "vector": null, "score_source": null, "epss": 0.00184, "epss_percentile": 0.07304, "exploited": false, "kev": null, "ssvc_exploitation": null, "vendors": [ "Linux" ], "products": [ "Linux" ], "cwes": [], "description": "In the Linux kernel, the following vulnerability has been resolved: Input: rmi_smbus - fix out-of-bounds read in rmi_smb_write_block() When chunking writes into SMBus blocks in rmi_smb_write_block(), the loop calculates block_len using the original total length (len) instead of the remaining length (cur_len). If len is greater than 32 bytes (SMB_MAX_COUNT), block_len remains 32 for every iteration, even on the final partial chunk where fewer than 32 bytes remain. This causes smb_block_write() to read 32 bytes from the advanced data buffer pointer, reading past the end of the input buffer. Fix this by calculating block_len using cur_len and advancing the buffer and address pointers by block_len." }, { "id": "CVE-2026-98203", "url": "https://spydr.io/cve/CVE-2026-98203", "published": "2026-10-06T09:18:06.230Z", "modified": "2026-10-06T09:18:06.230Z", "score": null, "severity": null, "cvss_version": null, "vector": null, "score_source": null, "epss": 0.00184, "epss_percentile": 0.07304, "exploited": false, "kev": null, "ssvc_exploitation": null, "vendors": [ "Linux" ], "products": [ "Linux" ], "cwes": [], "description": "In the Linux kernel, the following vulnerability has been resolved: Input: soc_button_array - check btns_desc->package.count Check that btns_desc->package.count is not 0 before accessing btns_desc->package.elements[0]." }, { "id": "CVE-2026-98202", "url": "https://spydr.io/cve/CVE-2026-98202", "published": "2026-10-06T09:18:06.067Z", "modified": "2026-10-06T09:18:06.067Z", "score": null, "severity": null, "cvss_version": null, "vector": null, "score_source": null, "epss": 0.00184, "epss_percentile": 0.07302, "exploited": false, "kev": null, "ssvc_exploitation": null, "vendors": [ "Linux" ], "products": [ "Linux" ], "cwes": [], "description": "In the Linux kernel, the following vulnerability has been resolved: Input: synaptics-rmi4 - fix GPF in suspend and resume when unbound Transport drivers (such as rmi_i2c and rmi_spi) invoke rmi_driver_suspend() and rmi_driver_resume() on their child rmi_dev device during system power management events. However, transport drivers are fully registered and operational even if the physical RMI driver failed to bind or probe the rmi_dev device. When rmi_driver_suspend() or rmi_driver_resume() is called on an unbound rmi_dev, dev_get_drvdata() returns NULL. Calling rmi_disable_irq() or rmi_enable_irq() without driver data attached causes a NULL pointer dereference and General Protection Fault when attempting to lock data->enabled_mutex. Fix this by checking if driver data is attached to rmi_dev in rmi_driver_suspend() and rmi_driver_resume(), exiting early if no driver data is present." }, { "id": "CVE-2026-98201", "url": "https://spydr.io/cve/CVE-2026-98201", "published": "2026-10-06T09:18:05.900Z", "modified": "2026-10-06T09:18:05.900Z", "score": null, "severity": null, "cvss_version": null, "vector": null, "score_source": null, "epss": 0.00184, "epss_percentile": 0.07302, "exploited": false, "kev": null, "ssvc_exploitation": null, "vendors": [ "Linux" ], "products": [ "Linux" ], "cwes": [], "description": "In the Linux kernel, the following vulnerability has been resolved: Input: zero ff_effect before compat copy in input_ff_effect_from_user In the compat path input_ff_effect_from_user() aliases the caller's native struct ff_effect with the smaller struct ff_effect_compat and copies only the compat sized prefix: compat_effect = (struct ff_effect_compat *)effect; if (copy_from_user(compat_effect, buffer, sizeof(struct ff_effect_compat))) The tail of the native structure is never written. Callers pass an uninitialized on-stack object, for example evdev_do_ioctl() for EVIOCSFF, so those bytes keep their previous stack contents. input_ff_upload() then stores the full native structure in ff->effects[id], from where a uinput based force feedback daemon can read it back via UI_BEGIN_FF_UPLOAD, disclosing kernel stack memory to userspace. Zero the effect before the compat copy." }, { "id": "CVE-2026-98200", "url": "https://spydr.io/cve/CVE-2026-98200", "published": "2026-10-06T09:18:05.747Z", "modified": "2026-10-06T09:18:05.747Z", "score": null, "severity": null, "cvss_version": null, "vector": null, "score_source": null, "epss": 0.00175, "epss_percentile": 0.06383, "exploited": false, "kev": null, "ssvc_exploitation": null, "vendors": [ "Linux" ], "products": [ "Linux" ], "cwes": [], "description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (hp-wmi-sensors) Fix use-after-free in fungible_show() nsensor->current_state is dynamically replaced as the sensor's state changes. update_numeric_sensor_from_wobj() does this by freeing the old string and installing a new one: if (strcmp(trimmed, nsensor->current_state)) { new_string = hp_wmi_strdup(dev, trimmed); if (new_string) { devm_kfree(dev, nsensor->current_state); nsensor->current_state = new_string; } } This function is only ever called from hp_wmi_update_info() while state->lock is held, so the free-and-replace itself is properly serialized against concurrent updates. fungible_show(), however, reads the same pointer after the lock has already been dropped: err = hp_wmi_update_info(state, info); if (err) return err; switch (prop) { ... case HP_WMI_PROPERTY_CURRENT_STATE: seq_printf(seqf, \"%s\\n\", nsensor->current_state); break; hp_wmi_update_info() takes state->lock internally and releases it before returning, so by the time fungible_show() dereferences nsensor->current_state in seq_printf(), no lock is held. Two processes reading a sensor's current_state debugfs entry at overlapping times (or one reading it while another read of the same sensor triggers a refresh) can race: one thread's seq_printf() can be part-way through printing the string at the moment another thread's call into update_numeric_sensor_from_wobj() frees it with devm_kfree() and installs a new pointer, causing a use-after-free read. Take state->lock around the read in fungible_show() as well, so it can never run concurrently with the free-and-replace in update_numeric_sensor_from_wobj()." }, { "id": "CVE-2026-98199", "url": "https://spydr.io/cve/CVE-2026-98199", "published": "2026-10-06T09:18:05.597Z", "modified": "2026-10-06T09:18:05.597Z", "score": null, "severity": null, "cvss_version": null, "vector": null, "score_source": null, "epss": 0.00215, "epss_percentile": 0.10799, "exploited": false, "kev": null, "ssvc_exploitation": null, "vendors": [ "Linux" ], "products": [ "Linux" ], "cwes": [], "description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (pmbus/core) increase number of phases and add new mask Increase the number of phases to 16 as a new upcoming device supports such a number. While at it, add a new mask for controlling the source of the output voltage. Note (groeck): This patch was meant to prepare for support of MAX20826 and compatible devices, which support more than 10 phases per page. However, Sashiko reports that the mp2975 driver already supports up to 14 phases, and the mp2856 driver supports up to 12 phases. This already has the potential for out-of-bounds writes when probing the affected chips, making this patch a bug fix." }, { "id": "CVE-2026-98198", "url": "https://spydr.io/cve/CVE-2026-98198", "published": "2026-10-06T09:18:05.440Z", "modified": "2026-10-06T09:18:05.440Z", "score": null, "severity": null, "cvss_version": null, "vector": null, "score_source": null, "epss": 0.00175, "epss_percentile": 0.06381, "exploited": false, "kev": null, "ssvc_exploitation": null, "vendors": [ "Linux" ], "products": [ "Linux" ], "cwes": [], "description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (pwm-fan) Stop RPM timer before freeing tach data sample_timer() rearms the RPM timer and accesses the devm-managed ctx->tachs and ctx->pulses_per_revolution arrays. The cleanup action which stops the timer is registered before those arrays are allocated. Since devres releases entries in reverse order, driver detach can free the arrays before pwm_fan_cleanup() shuts down the timer. A timer expiry in that window accesses the freed tach data. With a KASAN kernel, a test-only kprobe delayed entry to pwm_fan_cleanup() while normal sysfs unbind ran. Each of three runs reported three four-byte reads and two four-byte writes in sample_timer() after its backing devm allocations had been freed. The helper did not invoke the timer callback, cleanup actions or free functions. With the fix, three matching unbind runs completed without KASAN, BUG, WARNING, Oops or panic. Instrumentation confirmed that timer retirement completed before the first timer backing allocation was released. Split timer retirement from the power cleanup and register its devres action after the timer backing data and IRQ actions are installed. This preserves the early power rollback action while ensuring the timer is retired before its backing data is released. Use timer_shutdown_sync() because the callback can rearm itself." }, { "id": "CVE-2026-98197", "url": "https://spydr.io/cve/CVE-2026-98197", "published": "2026-10-06T09:18:05.273Z", "modified": "2026-10-07T07:17:04.490Z", "score": 7, "severity": "high", "cvss_version": "3.1", "vector": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H", "score_source": "CNA", "epss": 0.0022, "epss_percentile": 0.11355, "exploited": false, "kev": null, "ssvc_exploitation": null, "vendors": [ "Linux" ], "products": [ "Linux" ], "cwes": [], "description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (w83791d) remove fan/pwm 4-5 sysfs group on remove When the fan/pwm 4-5 pins are not used as GPIO, w83791d_probe() creates the w83791d_group_fanpwm45 sysfs group on the I2C client device. The probe error path removes this group when a later initialization step fails, but the normal remove path only removes w83791d_group. As a result, the optional fan/pwm 4-5 sysfs files can remain after the driver is unbound. The callbacks associated with these files access the driver data, which is devm allocated and released after driver unbind. Leaving the sysfs files behind can therefore result in accesses to stale driver data. Remove w83791d_group_fanpwm45 during normal teardown as well. This issue was found by manual code inspection." }, { "id": "CVE-2026-98196", "url": "https://spydr.io/cve/CVE-2026-98196", "published": "2026-10-06T09:18:05.113Z", "modified": "2026-10-06T09:18:05.113Z", "score": null, "severity": null, "cvss_version": null, "vector": null, "score_source": null, "epss": 0.00184, "epss_percentile": 0.07301, "exploited": false, "kev": null, "ssvc_exploitation": null, "vendors": [ "Linux" ], "products": [ "Linux" ], "cwes": [], "description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmsmac: fix UAF in brcms_free_timer() brcms_free_timer() calls brcms_del_timer() which uses the non-synchronous cancel_delayed_work() to cancel the timer's underlying delayed work. If the work callback (_brcms_timer) is already running, cancel_delayed_work() returns false without waiting, and brcms_free_timer() proceeds to kfree(t) while the callback still accesses t through container_of(). Add an explicit cancel_delayed_work_sync() after brcms_del_timer() to guarantee that any in-flight callback has completed before the timer structure is freed." }, { "id": "CVE-2026-98195", "url": "https://spydr.io/cve/CVE-2026-98195", "published": "2026-10-06T09:18:04.953Z", "modified": "2026-10-06T09:18:04.953Z", "score": null, "severity": null, "cvss_version": null, "vector": null, "score_source": null, "epss": 0.00184, "epss_percentile": 0.07301, "exploited": false, "kev": null, "ssvc_exploitation": null, "vendors": [ "Linux" ], "products": [ "Linux" ], "cwes": [], "description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlegacy: fix broadcast stations deallocation On the error path of __il4965_up(), il_dealloc_bcast_stations() clears only IL_STA_UCODE_ACTIVE, leaving IL_STA_BCAST set. This causes the same broadcast stations to be deallocated again by __il4965_down(). This can occur when RF_KILL is toggled during driver startup. To fix clear the entire 'used' field, since we will not do any other operations on the station." }, { "id": "CVE-2026-98194", "url": "https://spydr.io/cve/CVE-2026-98194", "published": "2026-10-06T09:18:04.800Z", "modified": "2026-10-06T09:18:04.800Z", "score": null, "severity": null, "cvss_version": null, "vector": null, "score_source": null, "epss": 0.00184, "epss_percentile": 0.07301, "exploited": false, "kev": null, "ssvc_exploitation": null, "vendors": [ "Linux" ], "products": [ "Linux" ], "cwes": [], "description": "In the Linux kernel, the following vulnerability has been resolved: wifi: libertas_tf: fix UAF in lbtf_free_adapter() lbtf_free_adapter() calls lbtf_free_cmd_buffer() to free the command buffers before calling timer_delete_sync() to wait for the command timer callback. If the timer callback (command_timer_fn) is already running when lbtf_free_cmd_buffer() frees the command array, the callback dereferences priv->cur_cmd->cmdbuf which points to freed memory. Swap the order so that timer_delete_sync() runs first, ensuring any in-flight callback has completed before the command buffers are freed." }, { "id": "CVE-2026-98193", "url": "https://spydr.io/cve/CVE-2026-98193", "published": "2026-10-06T09:18:04.670Z", "modified": "2026-10-06T09:18:04.670Z", "score": null, "severity": null, "cvss_version": null, "vector": null, "score_source": null, "epss": 0.00175, "epss_percentile": 0.06382, "exploited": false, "kev": null, "ssvc_exploitation": null, "vendors": [ "Linux" ], "products": [ "Linux" ], "cwes": [], "description": "In the Linux kernel, the following vulnerability has been resolved: wifi: libipw: reject TKIP frames without a full MIC libipw_michael_mic_verify() assumes that an skb contains an eight-byte Michael MIC. A short TKIP frame makes the unsigned payload length wrap, causing michael_mic() to read past the skb. Check that the MIC is present before verifying it, and use the existing MICHAEL_MIC_LEN constant for all MIC lengths in the verifier." }, { "id": "CVE-2026-98192", "url": "https://spydr.io/cve/CVE-2026-98192", "published": "2026-10-06T09:18:04.537Z", "modified": "2026-10-06T09:18:04.537Z", "score": null, "severity": null, "cvss_version": null, "vector": null, "score_source": null, "epss": 0.00175, "epss_percentile": 0.06382, "exploited": false, "kev": null, "ssvc_exploitation": null, "vendors": [ "Linux" ], "products": [ "Linux" ], "cwes": [], "description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wcn36xx: Fix potential use-after-free in TX ack timer teardown wcn36xx_dxe_deinit() tears down the TX ack timer with timer_delete(), which only dequeues the timer and does not wait for a callback that is already executing; the preceding free_irq() calls synchronize the interrupt handlers only. The callback, wcn36xx_dxe_tx_timer(), can therefore be running past the teardown and use the wcn freed along with the ieee80211_hw in wcn36xx_remove(): it takes wcn->dxe_lock, reads wcn->tx_ack_skb and passes wcn->hw to ieee80211_tx_status_irqsafe(). Fix this by using timer_shutdown_sync(), which waits for a running callback and also prevents the timer from being rearmed again. The timer is set up again by wcn36xx_dxe_init() on the next start, so the start/stop cycle is unaffected. This issue was found by an in-house static analysis tool." } ], "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." } ] }