| CVE-2026-97506 | In the Linux kernel, the following vulnerability has been resolved: crypto: ixp4xx - fix buffer chain unwind on allocation failure chainup_buffers() builds a linked list of buffer descriptors for a scatterlist. If dma_pool_alloc() fails while constructing the list, the current code sets buf to NULL and later dereferences it unconditionally at the end of the function: buf->next = NULL; buf->phys_next = 0; This can lead to a null-pointer dereference on allocation failure. If the failure happens after part of the descriptor chain has already been allocated and DMA-mapped, the partially constructed chain also needs to be released. Fix this by terminating the partially constructed chain on allocation failure and letting the callers unwind it via their existing cleanup paths. Also fix ablk_perform() to preserve the hook pointers before checking for failure, so partially built chains can be freed correctly. | medium | 2026-10-03 |
| CVE-2026-97505 | In the Linux kernel, the following vulnerability has been resolved: PCI/sysfs: Add CAP_SYS_ADMIN check to __resource_resize_store() Currently, the __resource_resize_store() allows writing to the resourceN_resize sysfs attribute to change a BAR's size without checking for capabilities, currently relying only on the file access check. Resizing a BAR modifies PCI device configuration and can disrupt active drivers. After the upcoming conversion to static attributes, it will also trigger resource file updates via sysfs_update_groups(). Add a CAP_SYS_ADMIN check to prevent unprivileged users from performing BAR resize operations. | high | 2026-09-28 |
| CVE-2026-97504 | In the Linux kernel, the following vulnerability has been resolved: watchdog: lenovo_se10_wdt: Fix use-after-free and resource leak risk Review by sashiko.dev highlighted potential use after free and resource leak instances. Set se10_pdev to null to prevent use after free Remove DMI call back and instead directly call se10_create_platform_device. Handle error cases appropriately | high | 2026-09-28 |
| CVE-2026-97503 | In the Linux kernel, the following vulnerability has been resolved: genirq/proc: Size interrupt directory names for 10-digit interrupt numbers /proc/irq/<n>/ directory names are built in `char name[10]` buffers with `sprintf(name, "%u", irq)`. Ten-digit IRQ numbers already need 11 bytes including the trailing NUL, and current sparse-IRQ configurations allow interrupt numbers in that range. Size the temporary name buffer for the current decimal form and switch to bounded formatting when creating or removing the proc entry. | medium | 2026-09-28 |
| CVE-2026-97502 | In the Linux kernel, the following vulnerability has been resolved: mmc: davinci: avoid NULL deref of host->data in IRQ handler mmc_davinci_irq() returns early only when both host->cmd and host->data are NULL: if (host->cmd == NULL && host->data == NULL) { ... return IRQ_NONE; } So we may legitimately reach the rest of the handler with host->data == NULL (and therefore data == NULL). The DATDNE branch already guards against this with an explicit "if (data != NULL)" check, but the subsequent TOUTRD ("read data timeout") and CRCWR/CRCRD ("data CRC error") branches dereference data unconditionally: if (qstatus & MMCST0_TOUTRD) { data->error = -ETIMEDOUT; <-- NULL deref ... davinci_abort_data(host, data); } if (qstatus & (MMCST0_CRCWR | MMCST0_CRCRD)) { data->error = -EILSEQ; <-- NULL deref ... } If either bit is set in qstatus while host->data is NULL, the kernel will crash inside the IRQ handler. smatch flags this: drivers/mmc/host/davinci_mmc.c:933 mmc_davinci_irq() error: we previously assumed 'data' could be null (see line 914) Gate both branches on a non-NULL data, matching the existing pattern used by the DATDNE branch. No functional change for callers where data is non-NULL, which is the only case in which these branches did meaningful work before this change. | medium | 2026-10-03 |
| CVE-2026-97501 | In the Linux kernel, the following vulnerability has been resolved: pinctrl: mediatek: paris: bypass pinctrl GPIO layer in set GPIO direction pinctrl_gpio_direction_input() / pinctrl_gpio_direction_output() take the pinctrl mutex. This causes a gpiochip operations to need to sleep. Worse yet, the .can_sleep field in the gpiochip is not set. This causes the shared GPIO proxy to trip over, as it uses gpiod_cansleep() to check whether it can use a spinlock or needs a mutex. In this case, it ends up taking a spinlock, then calls pinctrl_gpio_direction_output(), which takes a mutex. This causes a huge warning. While this class of Mediatek hardware does not have separate clear/set registers, the pinctrl context has a spinlock that is taken whenever a register read-modify-write is done. Also, once the GPIO function is selected / muxed in, further GPIO operations do not involve pinctrl operations or state. The GPIO direction and level values do not require toggling the pinmux or any other pin config options. Switch to directly calling mtk_pinmux_gpio_set_direction() in the GPIO set direction callbacks to avoid taking the pinctrl mutex. Drop the .gpio_set_direction field in mtk_pmxops to signal we are no longer using the pinctrl GPIO layer for setting the direction. | high | 2026-09-28 |
| CVE-2026-97500 | In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: phy: check length before parsing PHY status IE Hardware might report PHY status IE with unexpected length, and parser might access out of range. Check the length ahead. | medium | 2026-10-03 |
| CVE-2026-97499 | In the Linux kernel, the following vulnerability has been resolved: coresight: perf: Retrieve path and source from event data ETM perf callbacks currently use the per-CPU csdev_src pointer, which can race with updates during device registration and unregistration. The AUX setup already builds and stores the path in the event data. Use this path to retrieve the source instead of csdev_src to avoid the race. Export coresight_get_source() and add etm_event_get_ctxt_path() to retrieve the context's path and its source with READ_ONCE() / WRITE_ONCE() accessors. Give the comments to explain why this approach is safe when pause or resume callbacks preempt the disable callback (e.g. via NMI). | high | 2026-09-28 |
| CVE-2026-97498 | In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/userq: pin mqd and fw object bo to avoid eviction mqd and fw objects are queue core objects which should remain valid and never be unmapped and evicted for user queues to work properly. During eviction if these buffers are evicted the hw continue to use the invalid addresses and caused page faults and system hung. | high | 2026-09-28 |
| CVE-2026-97497 | In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Check bounds for allocate_sdma_queue restore_sdma_id allocate_sdma_queue has an option where the sdma queue id can be specified (used by CRIU). We weren't bounds-checking that value. Confirm it's less than the maximum number of queues. | high | 2026-10-03 |
| CVE-2026-97496 | In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix OOB memory exposure in get_wave_state() The get_wave_state() function for v9 trusts cp_hqd_cntl_stack_size and cp_hqd_cntl_stack_offset values read directly from the MQD, which are written by GPU microcode and fully attacker-controlled on the CRIU-restore path (via AMDKFD_IOC_RESTORE_PROCESS with H3). this leads to an unbounded copy_to_user() that can leak adjacent GTT/kernel memory. If offset > size, integer underflow produces a ~4 GiB read length, if size is set to 1 MiB against a 4 KiB allocation, we leak 1 MiB of adjacent kernel memory (other queues' MQDs, ring buffers, KASLR pointers). Fix by clamping both cp_hqd_cntl_stack_size to the actual allocated buffer size (q->ctl_stack_size) and cp_hqd_cntl_stack_offset to the clamped size before performing arithmetic and copy_to_user(). This ensures we never read beyond the allocated kernel BO regardless of attacker-supplied MQD field values. | high | 2026-10-03 |
| CVE-2026-97495 | In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Check bounds on allocate_doorbell allocated_doorbell has an option to set the doorbell id to a specific value (used by CRIU). This value was not bounds checked. Check to confirm it's less than KFD_MAX_NUM_OF_QUEUES_PER_PROCESS. | medium | 2026-10-03 |
| CVE-2026-97494 | In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: validate and share PSP fw_pri_buf copies via psp_copy_fw Change psp_copy_fw from void to int: return -ENODEV when drm_dev_enter fails, and -EINVAL when the image size is zero or larger than the 1 MiB PSP private buffer. Replace open-coded memset/memcpy into fw_pri_buf with psp_copy_fw. | high | 2026-09-28 |
| CVE-2026-97493 | In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Bound GPIO I2C table entry count from VBIOS Reject undersized tables and cap the derived entry count to AMDGPU_MAX_I2C_BUS so we do not overrun adev->i2c_bus[] or walk an absurd number of entries on corrupt size fields. | high | 2026-09-28 |
| CVE-2026-97492 | In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: don't call ieee80211_handle_reconfig_failure when not needed In case reconfiguration of NAN fails, we call ieee80211_handle_reconfig_failure, that marks all interfaces as not in the driver. Then, at the error path of the reconfig, cfg80211_shutdown_all_interfaces is called to destroy all the interfaces. If we have any other interface but the NAN one, for example a BSS station, then when its state (links, stations) will be removed, we won't tell the driver about this, because we will think that the interfaces are not in the driver, and then drivers might remain with dangling pointers to objects like stations and links (at least for iwlwifi this is the case). ieee80211_handle_reconfig_failure is meant to be called after we cleaned up the state in the driver, there is no reason to call it for NAN reconfiguration failure. Fix the code to just warn in such a case, as we do in other error paths in reconfig where it is too complicated to rewind. | medium | 2026-10-03 |
| CVE-2026-97491 | In the Linux kernel, the following vulnerability has been resolved: net/rds: Don't sleep inside rds_ib_conn_path_shutdown New rds rdma self tests exposed a hang when tearing down the ib network configs. This is caused by the shutdown worker thread sleeping on the wait_event call, which blocks other work items in the queue. Fix this by changing wait_event to wait_event timeout, and looping until the wait check succeeds. | medium | 2026-10-03 |
| CVE-2026-97490 | In the Linux kernel, the following vulnerability has been resolved: affs: handle set_blocksize failures affs uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting we will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call. | medium | 2026-10-03 |
| CVE-2026-97489 | In the Linux kernel, the following vulnerability has been resolved: bfs: handle set_blocksize failures bfs uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call. | medium | 2026-10-03 |
| CVE-2026-97488 | In the Linux kernel, the following vulnerability has been resolved: qnx4: handle set_blocksize failures qnx4 uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call. | medium | 2026-10-03 |
| CVE-2026-97487 | In the Linux kernel, the following vulnerability has been resolved: jfs: handle set_blocksize failures jfs uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting we will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call. | medium | 2026-10-03 |
| CVE-2026-97486 | In the Linux kernel, the following vulnerability has been resolved: hpfs: handle set_blocksize failures hpfs uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call. | medium | 2026-10-03 |
| CVE-2026-97485 | In the Linux kernel, the following vulnerability has been resolved: omfs: handle set_blocksize failures omfs uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting we will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call. | medium | 2026-10-03 |
| CVE-2026-97484 | In the Linux kernel, the following vulnerability has been resolved: usbip: vhci_hcd: fix NULL deref in status_show_vhci platform_get_drvdata() can return NULL if a VHCI host controller's probe failed (e.g. due to USB bus number exhaustion). status_show_vhci() checked for a NULL pdev but not for a NULL hcd returned by platform_get_drvdata(). Passing NULL to hcd_to_vhci_hcd() does not return NULL - it returns a pointer offset of 0x260, causing a NULL pointer dereference when that value is subsequently dereferenced. Add a NULL check on hcd before calling hcd_to_vhci_hcd(). Move status_show_not_ready() above status_show_vhci() to make it callable from the new error path without a forward declaration. | medium | 2026-10-03 |
| CVE-2026-97483 | In the Linux kernel, the following vulnerability has been resolved: usb: core: hcd: fix possible deadlock in rh control transfers >From within the SCSI error handler memory allocations must not trigger IO. Handling errors in UAS and the storage driver may involve resetting a device. The thread doing the reset itself relies on VM magic. However, that is insufficient, as resetting a device involves resuming it. Resumption as well as resetting involves conrol transfers to the parent of the device to be reset. That may be a root hub. Hence usbcore must heed the flags passed to usb_submit_urb() processing control transfers to root hubs. The problem exist since the storage driver has been merged. | high | 2026-10-03 |
| CVE-2026-97482 | In the Linux kernel, the following vulnerability has been resolved: usb: gadget: goku_udc: avoid NULL deref of dev->driver in INT_USBRESET log goku_irq() handles a number of bus events under a single ep0 path. It already guards the gadget driver suspend/resume callbacks against a NULL ->driver: if (dev->gadget.speed != USB_SPEED_UNKNOWN && dev->driver && dev->driver->resume) { spin_unlock(&dev->lock); dev->driver->resume(&dev->gadget); ... } but the very next branch unconditionally dereferences dev->driver when an INT_USBRESET arrives: if (stat & INT_USBRESET) { ACK(INT_USBRESET); INFO(dev, "USB reset done, gadget %s\n", dev->driver->driver.name); } If the controller raises INT_USBRESET before any gadget driver has been bound (or after one has been unbound), dev->driver is NULL and the printk dereferences NULL. smatch flags the inconsistency: drivers/usb/gadget/udc/goku_udc.c:1618 goku_irq() error: we previously assumed 'dev->driver' could be null (see line 1607) Fall back to a placeholder when the gadget driver is not bound. No functional change while a gadget driver is bound. | medium | 2026-10-03 |
| CVE-2026-97481 | In the Linux kernel, the following vulnerability has been resolved: serial: 8250: fix possible ISR soft lockup There are rare cases in which the host gets stuck in the ISR because it is flooded with messages during the startup phase. The reason for the soft lockup in the ISR is the missing FIFO error IRQ (FIFOE) handling. Not handling it and reporting IRQ_HANDLED triggers the IRQ immediately again. Fix this by adding a check for the FIFOE status and clearing the FIFO if no data is ready (DR). This behavior was observed on an AM62L device which uses the OMAP 8250 driver. Fix it for all 8250 drivers, since the OMAP driver's special IRQ setup handling may trigger this behavior more frequently, but it is not ensured that other 8250 drivers aren't affected. | medium | 2026-10-03 |
| CVE-2026-97480 | In the Linux kernel, the following vulnerability has been resolved: tty: serial: 8250: protect against NULL uart->port.dev in register serial8250_register_8250_port() conditionally copies uart->port.dev from up->port.dev only when up->port.dev is non-NULL: if (up->port.dev) { uart->port.dev = up->port.dev; ... } So if both the existing uart slot and up have a NULL ->dev, uart->port.dev remains NULL. The very next ACPI companion check then dereferences it unconditionally: if (!has_acpi_companion(uart->port.dev)) { has_acpi_companion() reads dev->fwnode without a NULL guard (include/linux/acpi.h), so this NULL-derefs the kernel for the remaining no-dev case rather than just skipping the mctrl_gpio_init() initialisation as intended. smatch flags the inconsistency: drivers/tty/serial/8250/8250_core.c:767 serial8250_register_8250_port() error: 'uart->port.dev' could be null (see line 719) Guard the call with a NULL check so register continues to work for callers that legitimately have no parent device (legacy non-OF/non-ACPI registrations). No functional change for callers that pass a non-NULL ->dev. | medium | 2026-09-28 |
| CVE-2026-97479 | In the Linux kernel, the following vulnerability has been resolved: driver core: Avoid warning when removing a device while its supplier is unbinding During driver removal, the following warning can appear: WARNING: CPU: 1 PID: 139 at drivers/base/core.c:1497 __device_links_no_driver+0xcc/0xfc ... Call trace: __device_links_no_driver+0xcc/0xfc (P) device_links_driver_cleanup+0xa8/0xf0 device_release_driver_internal+0x208/0x23c device_links_unbind_consumers+0xe0/0x108 device_release_driver_internal+0xec/0x23c device_links_unbind_consumers+0xe0/0x108 device_release_driver_internal+0xec/0x23c device_links_unbind_consumers+0xe0/0x108 device_release_driver_internal+0xec/0x23c driver_detach+0xa0/0x12c bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 pci_unregister_driver+0x20/0x9c lan966x_pci_driver_exit+0x18/0xa90 [lan966x_pci] This warning is triggered when a consumer is removed because the links status of its supplier is not DL_DEV_DRIVER_BOUND and the link flag DL_FLAG_SYNC_STATE_ONLY is not set. The topology in terms of consumers/suppliers used was the following (consumer ---> supplier): i2c -----------> OIC ----> PCI device | ^ | | +---> pinctrl ---+ When the PCI device is removed, the OIC (interrupt controller) has to be removed. In order to remove the OIC, pinctrl and i2c need to be removed and to remove pinctrl, i2c need to be removed. The removal order is: 1) i2c 2) pinctrl 3) OIC 4) PCI device In details, the removal sequence is the following (with 0000:01:00.0 the PCI device): driver_detach: call device_release_driver_internal(0000:01:00.0)... device_links_busy(0000:01:00.0): links->status = DL_DEV_UNBINDING device_links_unbind_consumers(0000:01:00.0): 0000:01:00.0--oic link->status = DL_STATE_SUPPLIER_UNBIND call device_release_driver_internal(oic)... device_links_busy(oic): links->status = DL_DEV_UNBINDING device_links_unbind_consumers(oic): oic--pinctrl link->status = DL_STATE_SUPPLIER_UNBIND call device_release_driver_internal(pinctrl)... device_links_busy(pinctrl): links->status = DL_DEV_UNBINDING device_links_unbind_consumers(pinctrl): pinctrl--i2c link->status = DL_STATE_SUPPLIER_UNBIND call device_release_driver_internal(i2c)... device_links_busy(i2c): links->status = DL_DEV_UNBINDING __device_links_no_driver(i2c)... pinctrl--i2c link->status is DL_STATE_SUPPLIER_UNBIND oic--i2c link->status is DL_STATE_ACTIVE oic--i2c link->supplier->links.status is DL_DEV_UNBINDING The warning is triggered by the i2c removal because the OIC (supplier) links status is not DL_DEV_DRIVER_BOUND. Its links status is indeed set to DL_DEV_UNBINDING. It is perfectly legit to have the links status set to DL_DEV_UNBINDING in that case. Indeed we had started to unbind the OIC which triggered the consumer unbinding and didn't finish yet when the i2c is unbound. Avoid the warning when the supplier links status is set to DL_DEV_UNBINDING and thus support this removal sequence without any warnings. | medium | 2026-09-28 |
| CVE-2026-97478 | In the Linux kernel, the following vulnerability has been resolved: virt: acrn: Fix irqfd use-after-free during eventfd shutdown acrn_irqfd_deassign() and the eventfd EPOLLHUP wakeup can race and free the same struct hsm_irqfd: CPU0 CPU1 ---- ---- eventfd_release() wake_up_poll(EPOLLHUP) hsm_irqfd_wakeup() queue_work(&irqfd->shutdown) acrn_irqfd_deassign() hsm_irqfd_shutdown() list_del_init() eventfd_ctx_remove_wait_queue() eventfd_ctx_put() kfree(irqfd) hsm_irqfd_shutdown_work() container_of(work, ..., shutdown) irqfd->vm <-- use-after-free The deassign path freed the irqfd while a shutdown work item was already queued by EPOLLHUP (or vice versa), so the work item could resurrect a dangling pointer through container_of(). Switch to the lifetime model used by KVM irqfds: - Deassign/deinit only deactivate the irqfd: remove it from vm->irqfds under irqfds_lock and queue the cleanup work. - hsm_irqfd_shutdown_work() becomes the sole owner that unhooks the eventfd waitqueue entry, drops the eventfd reference and frees the irqfd. - A new HSM_IRQFD_FLAG_SHUTDOWN bit guarded by test_and_set_bit() ensures the cleanup work is queued at most once, no matter how many of {EPOLLHUP, deassign, deinit} fire concurrently. This is safe to call from the waitqueue callback, which runs with wqh->lock held and IRQs disabled and therefore cannot take irqfds_lock. - acrn_irqfd_deassign() flushes vm->irqfd_wq before returning so the eventfd is fully detached on return. acrn_irqfd_deinit() deactivates every irqfd, flushes the workqueue and only then destroys it, so no path can queue_work() onto a torn-down workqueue. - acrn_irqfd_assign() now installs the eventfd waitqueue entry and publishes the irqfd to vm->irqfds under irqfds_lock, so the irqfd is never visible to deassign/deinit before its waitqueue entry is in place, and any EPOLLHUP that fires in the assign window queues cleanup work that blocks on irqfds_lock until publication is done. | high | 2026-09-28 |
| CVE-2026-97477 | In the Linux kernel, the following vulnerability has been resolved: RDMA/counter: Fix num_counters leak on bind_qp failure in alloc_and_bind() When __rdma_counter_bind_qp() fails in alloc_and_bind(), the error path jumps to err_mode which frees the counter without decrementing port_counter->num_counters. The only place that decrements is rdma_counter_free(), which is unreachable since the counter was never successfully bound. This leak accumulates across repeated failures, permanently preventing the port from switching to AUTO mode (-EBUSY in __counter_set_mode()) and blocking the MANUAL→NONE auto-revert in rdma_counter_free(). When the mode was NONE before the call, the MANUAL mode set by __counter_set_mode() also leaks since the revert logic is never reached. Add an err_bind label between the num_counters increment and the existing err_mode label. It decrements num_counters and mirrors the MANUAL→NONE revert from rdma_counter_free(), ensuring the port state is fully restored on bind failure. | medium | 2026-09-28 |
| CVE-2026-97476 | In the Linux kernel, the following vulnerability has been resolved: rds: filter RDS_INFO_* getsockopt by caller's netns The RDS_INFO_* family of getsockopt(2) options reads several file-scope global lists that are not per-netns: rds_sock_info / rds6_sock_info, rds_sock_inc_info / rds6_sock_inc_info -> rds_sock_list rds_tcp_tc_info / rds6_tcp_tc_info -> rds_tcp_tc_list rds_conn_info / rds6_conn_info, rds_conn_message_info_cmn (for the *_SEND_MESSAGES and *_RETRANS_MESSAGES variants), rds_for_each_conn_info (for RDS_INFO_IB_CONNECTIONS) -> rds_conn_hash[] The handlers do not filter by the caller's network namespace. rds_info_getsockopt() has no netns or capable() check, and rds_create() has no capable() check, so AF_RDS is reachable from an unprivileged user namespace. As a result, an unprivileged caller in a fresh user_ns plus netns can read the bound address and sock inode of every RDS socket on the host, the peer address of incoming messages on every RDS socket on the host, the peer address and TCP sequence numbers of every rds-tcp connection on the host, and the peer address and RDS sequence numbers of every RDS connection on the host. The rds-tcp transport is reachable from a non-initial netns (see rds_set_transport()), so a one-shot init_net gate at rds_info_getsockopt() would deny legitimate per-netns visibility to rds-tcp callers. Instead, filter at each handler by comparing the netns of the caller's socket to the netns of the list entry, or to rds_conn_net(conn) for connection paths. Only copy entries whose netns matches the caller. Counters (RDS_INFO_COUNTERS) are aggregate statistics and remain global. Reproducer (KASAN VM, rds and rds_tcp loaded): an AF_RDS socket binds 127.0.0.1:4242 in init_net as root. A child process enters a fresh user_ns plus netns and opens AF_RDS there, then calls getsockopt(SOL_RDS, RDS_INFO_SOCKETS). Before this change, the child sees the init_net socket. After this change, the child sees zero entries. Drop the rds_sock_count, rds_tcp_tc_count, and rds6_tcp_tc_count globals. v2 used them for the size precheck and lens->nr; v3 replaced the precheck with a per-ns count from a first pass over the list, so the globals have no remaining readers. The matching increments and decrements in rds_create()/rds_destroy_sock() and rds_tcp_set_callbacks()/rds_tcp_restore_callbacks() go away with them. Reported by the kernel test robot under clang W=1. | high | 2026-10-03 |
| CVE-2026-97475 | In the Linux kernel, the following vulnerability has been resolved: thermal/drivers/tegra/soctherma: Switch to devm cooling device registration Use devm_thermal_of_cooling_device_register() to simplify resource management and avoid manual cleanup in error paths. As a side effect this change has the benefit of solving an existing issue. Before, the function tegra_soctherm_remove() only called debugfs_remove_recursive() and never called thermal_cooling_device_unregister() for any of the cooling devices registered here. After the driver removal, the thermal framework's cdev list would still hold references to thermal_cooling_device objects whose devdata pointer (ts) pointed to memory already freed by the platform device's devm cleanup. With this change, the cooling device is unregistered when the driver is removed, thus fixing the issue above. | medium | 2026-10-03 |
| CVE-2026-97474 | In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mld: purge async notifications upon nic error This fixes a kernel panic in reconfig failure: 1. we have a BSS connection 2. we have a NAN connection 3. FW error occurs 4. reconfig restores the BSS connection 5. however, restoring the NAN connection fails due to a FW error. 6. erroneously, ieee80211_handle_reconfig_failure is called and marks all interfaces as not-in-driver (will be fixed in a different patch). 7. mac80211 frees the links of the BSS connection but doesn't tell the driver about that, as it thinks that this vif is not in the driver. 8. in ieee80211_stop_device, *ALL* wiphy works are getting flushed (erroneously?) 9. Therefore, async_handlers_wk is being executed, processing the statistics notification that was received after we restored the BSS connection. 10. the notification handler dereferences fw_id_to_bss_conf[id], which is now a dangling pointer, as mac80211 already freed this link in (7). 11. On the first access to one of the links fields, we panic. While this can and should be fixed by removing the call to ieee80211_handle_reconfig_failure in (6), it is also not a good idea to carry and maybe handle notifications from a dead FW. We do purge the notifications when we stop the FW, but in reconfig failure we stop the FW too late, after the notifications are processed. In addition, async_handlers_wk can always be scheduled before the reconfig work. Purge the notifications immediately when transport notifies about a nic error. | high | 2026-09-28 |
| CVE-2026-97473 | In the Linux kernel, the following vulnerability has been resolved: powercap: intel_rapl: Fix memory leak in rapl_add_package_cpuslocked() When topology_physical_package_id()/topology_logical_die_id() returns a negative value, rapl_add_package_cpuslocked() returns ERR_PTR(-EINVAL) directly without freeing the rapl_package structure that was just allocated by kzalloc_obj(), leaking memory on every failed package addition. Use the existing err_free_package label so that the allocation is released on the error path. | medium | 2026-09-28 |
| CVE-2026-97472 | In the Linux kernel, the following vulnerability has been resolved: ipv6: addrconf: fix temp address generation after prefix deprecation When a router temporarily deprecates an IPv6 prefix (either by sending a Router Advertisement with Preferred Lifetime = 0 or by letting the lifetime expire) and later restores it, the kernel permanently loses its ability to generate temporary privacy addresses (RFC 8981) for that prefix. This happens because the address worker attempts to generate a replacement temporary address when the current one nears expiration. As the base prefix is deprecated already, the generation fails after marking the temporary address as already having spawned a replacement (ifp->regen_count++). When the router eventually restores the prefix, the temporary address becomes active again. However, once it naturally expires, the address worker sees this temporary address already tried to generate one and skips the regeneration. Fix the issue by resetting the regen_count check of the latest temp address generated for the prefix updated by the incoming RA. | medium | 2026-10-03 |
| CVE-2026-97456 | In the Linux kernel, the following vulnerability has been resolved: ACPICA: Fix condition check in acpi_ps_parse_loop() Fix condition check for AML_ELSE_OP in acpi_ps_parse_loop() to prevent out-of-bounds access. | high | 2026-10-03 |
| CVE-2026-97455 | In the Linux kernel, the following vulnerability has been resolved: ACPICA: Fix use-after-free in acpi_ds_terminate_control_method() Fix use-after-free issue in acpi_ds_terminate_control_method() by clearing references to method locals and arguments. | high | 2026-10-03 |
| CVE-2026-97454 | In the Linux kernel, the following vulnerability has been resolved: ACPICA: add boundary checks in acpi_ps_get_next_field() Add boundary checks in acpi_ps_get_next_field() to prevent out-of-bounds access. | high | 2026-10-03 |
| CVE-2026-97453 | In the Linux kernel, the following vulnerability has been resolved: ACPICA: validate byte_count in acpi_ps_get_next_package_length() Validate package length reading in acpi_ps_get_next_package_length(). | high | 2026-10-03 |
| CVE-2026-97452 | In the Linux kernel, the following vulnerability has been resolved: ACPICA: Prevent adding invalid references Prevent adding references for local, argument, and debug objects in acpi_ut_copy_simple_object(). | high | 2026-10-03 |
| CVE-2026-97451 | In the Linux kernel, the following vulnerability has been resolved: ACPICA: Fix integer overflow in acpi_ex_opcode_3A_1T_1R() (mid_op) Add overflow check for Index + Length to prevent integer overflow when calculating the truncation length. This prevents negative size parameter being passed to memcpy(). | high | 2026-10-03 |
| CVE-2026-97450 | In the Linux kernel, the following vulnerability has been resolved: ACPICA: validate handler object type in two places ACPICA: validate handler object type in acpi_ev_has_default_handler() and acpi_ev_find_region_handler(). | high | 2026-10-03 |
| CVE-2026-97449 | In the Linux kernel, the following vulnerability has been resolved: ACPICA: Add package limit checks in parser functions Add package limit checks in parser functions to prevent out-of-bounds access. | high | 2026-10-03 |
| CVE-2026-97448 | In the Linux kernel, the following vulnerability has been resolved: ACPICA: Add validation for node in acpi_ns_build_normalized_path() Add validation for node in acpi_ns_build_normalized_path() to prevent use-after-free vulnerabilities. | high | 2026-10-03 |
| CVE-2026-97447 | In the Linux kernel, the following vulnerability has been resolved: ACPICA: Enhance OEM ID and Table ID validation in acpi_ex_load_table_op() Enhance OEM ID and Table ID validation in acpi_ex_load_table_op() to prevent buffer overflows. | high | 2026-09-25 |
| CVE-2026-97446 | In the Linux kernel, the following vulnerability has been resolved: ACPICA: Fix NULL pointer dereference in acpi_ns_custom_package() acpi_ns_custom_package() unconditionally dereferences the first element of the package to read the _BIX version number, without checking for NULL: if ((*Elements)->Common.Type != ACPI_TYPE_INTEGER) When firmware returns a _BIX package whose first element is an unresolvable reference, ACPICA evaluates that entry to NULL. acpi_ns_remove_null_elements() does not strip NULL entries for ACPI_PTYPE_CUSTOM packages (fixed-position format would break if elements were shifted), so acpi_ns_custom_package() sees the NULL and causes a crash. Add a NULL check for the first element (version field) before dereferencing it. The caller then receives AE_AML_OPERAND_TYPE instead of crashing. | medium | 2026-10-03 |
| CVE-2026-97445 | In the Linux kernel, the following vulnerability has been resolved: ACPICA: Enhance buffer validation in acpi_ut_walk_aml_resources() Enhance buffer validation in acpi_ut_walk_aml_resources() to prevent buffer overflows. | high | 2026-10-03 |
| CVE-2026-97444 | In the Linux kernel, the following vulnerability has been resolved: ACPICA: add boundary checks in two places Add boundary checks in acpi_ps_get_next_namestring() and acpi_ps_peek_opcode() to prevent out-of-bounds access. | high | 2026-10-03 |
| CVE-2026-97443 | In the Linux kernel, the following vulnerability has been resolved: perf/ftrace: Fix WARNING in __unregister_ftrace_function perf_ftrace_function_unregister() unconditionally calls unregister_ftrace_function() without checking whether the ftrace_ops was ever successfully registered. This triggers a WARN_ON in __unregister_ftrace_function() when the ops doesn't have FTRACE_OPS_FL_ENABLED set. This can happen during perf_event_alloc() error cleanup when perf_trace_destroy() is called via __free_event() on an event whose ftrace_ops registration failed or was already torn down by perf_try_init_event()'s err_destroy path. The call path is: perf_event_alloc() error cleanup -> __free_event() -> event->destroy() [tp_perf_event_destroy] -> perf_trace_destroy() -> perf_trace_event_close() -> TRACE_REG_PERF_CLOSE -> perf_ftrace_function_unregister() -> unregister_ftrace_function() -> __unregister_ftrace_function() -> WARN_ON(!(ops->flags & FTRACE_OPS_FL_ENABLED)) Fix this by checking FTRACE_OPS_FL_ENABLED before attempting to unregister. If the ops is not enabled, just free the filter and return success. | high | 2026-09-25 |
| CVE-2026-97442 | In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix invalid data access in ath11k_dp_rx_h_undecap_nwifi In certain cases, hardware might provide packets with a length greater than the maximum native Wi-Fi header length. This can lead to accessing and modifying fields in the header within the ath11k_dp_rx_h_undecap_nwifi() function for the DP_RX_DECAP_TYPE_NATIVE_WIFI decap type and potentially result in invalid data access and memory corruption. Kernel stack is corrupted in: ath11k_dp_rx_h_undecap+0x6b0/0x6b0 [ath11k] Call trace: ath11k_dp_rx_h_mpdu+0x0/0x2e8 [ath11k] ath11k_dp_rx_h_mpdu+0x1e0/0x2e8 [ath11k] ath11k_dp_rx_wbm_err+0x1e0/0x450 [ath11k] ath11k_dp_rx_process_wbm_err+0x2fc/0x460 [ath11k] ath11k_dp_service_srng+0x2e0/0x348 [ath11k] Add a sanity check before processing the SKB to prevent invalid data access in the undecap native Wi-Fi function for the DP_RX_DECAP_TYPE_NATIVE_WIFI decap type. This adapted from the discussion/patch of the ath12k driver [1]. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-04685-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1 | high | 2026-10-03 |
