Export limit exceeded: 390142 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (390142 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-89458 | 1 Linux | 1 Linux Kernel | 2026-09-11 | 4.7 Medium |
| In the Linux kernel, the following vulnerability has been resolved: s390/dasd: Do not complete a failed ESE read as successful dasd_int_handler() completes an NRF read of an unallocated ESE track by calling ese_read() and unconditionally marking the request DASD_CQR_SUCCESS. dasd_eckd_ese_read() can return an error before it has zeroed the destination buffer: a failed sense-data parse or a current track outside the requested range both return early, leaving the destination pages untouched. The request is still completed successfully, so the block layer is handed stale / uninitialized memory instead of zeros. Check the ese_read() return value and fail the request through the normal error path instead of forcing DASD_CQR_SUCCESS. | ||||
| CVE-2026-89457 | 1 Linux | 1 Linux Kernel | 2026-09-11 | 4.7 Medium |
| In the Linux kernel, the following vulnerability has been resolved: s390/dasd: Guard sysfs discipline callbacks against unallocated private data Several sysfs show/store handlers call a discipline callback that dereferences device->private, either directly or through the DASD_DEFINE_ATTR() macro. During dasd_generic_set_online() the discipline is assigned before check_device() allocates device->private, so an unprivileged read of one of these world-readable attributes in that window dereferences a NULL pointer and panics. Guard the dereference inside each callback that actually touches device->private. | ||||
| CVE-2026-89455 | 1 Linux | 1 Linux Kernel | 2026-09-11 | 4.1 Medium |
| In the Linux kernel, the following vulnerability has been resolved: PCI: plda: Fix use-after-free of event IRQs during teardown plda_pcie_irq_domain_deinit() removes pcie->event_domain via irq_domain_remove(), but the per-event IRQs mapped from that domain are requested with devm_request_irq() in plda_init_interrupts(). The actual free_irq() for a devm-managed IRQ is deferred by devres until after the calling probe()/remove() function returns. This means irq_domain_remove() can free the domain's internal data before the deferred free_irq() for IRQs still mapped into it has run. When devres later processes that deferred cleanup, it can end up dereferencing the already-freed domain. Free each event IRQ explicitly with devm_free_irq() before removing the domain. This triggers the free immediately and removes the IRQ from the devres tracking list, so devres will not attempt to free it a second time later. Also dispose of the event, INTx, and MSI IRQ mappings with irq_dispose_mapping() before their owning domains are removed. Finally, guard the calls to irq_set_chained_handler_and_data() for pcie->irq, pcie->msi_irq, and pcie->intx_irq so they only run when those fields hold a valid (>0) IRQ number. This is a pre-existing issue, flagged by automated review during work on an earlier, unrelated patch to this driver. Build-tested and boot-tested on StarFive VisionFive v1.2A board | ||||
| CVE-2026-89454 | 1 Linux | 1 Linux Kernel | 2026-09-11 | 4.4 Medium |
| In the Linux kernel, the following vulnerability has been resolved: PCI: plda: Fix IRQ domain leaks in the error paths of plda_init_interrupts() plda_init_interrupts() initializes IRQ domains and creates IRQ mapping but does not unwind them when later step fails. If platform_get_irq() or either irq_create_mapping() fails in plda_init_interrupts(), the domains are never deinitialized. If irq_create_mapping() fails, port->intx_irq stays initialized. Hence, remove the IRQ domains in the error path by calling plda_pcie_irq_domain_deinit(). Since plda_pcie_irq_domain_deinit() now disposes of the intx_irq and msi_irq mappings itself before removing their domains, the msi_irq mapping failure path can go directly to err_irq_domain_deinit instead of disposing of port->intx_irq separately first. This issue was found by automated review of sashiko-bot [mani: commit log] | ||||
| CVE-2026-89449 | 1 Linux | 1 Linux Kernel | 2026-09-11 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: iommu: Fix dev_iommu memory leak when device_add fails in iommu_mock_device_add iommu_mock_device_add() first calls iommu_fwspec_init(), which on success allocates both dev->iommu (via dev_iommu_get()) and dev->iommu->fwspec. If the subsequent device_add(dev) call fails, the error path only calls iommu_fwspec_free(dev), which frees fwspec but leaves dev->iommu still allocated. This triggers the following kmemleak report when fuzzing with Syzkaller: BUG: memory leak unreferenced object 0xffff888011e0a200 (size 192): comm "syz.1.1695", pid 24885, jiffies 4295222527 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 ad 4e ad de .............N.. ff ff ff ff 00 00 00 00 ff ff ff ff ff ff ff ff ................ backtrace (crc 25df5bb3): kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline] slab_post_alloc_hook mm/slub.c:4575 [inline] slab_alloc_node mm/slub.c:4899 [inline] __kmalloc_cache_noprof+0x47a/0x710 mm/slub.c:5415 kmalloc_noprof include/linux/slab.h:950 [inline] kzalloc_noprof include/linux/slab.h:1188 [inline] dev_iommu_get+0x10c/0x1a0 drivers/iommu/iommu.c:408 iommu_fwspec_init+0x288/0x4d0 drivers/iommu/iommu.c:3087 iommu_mock_device_add+0x46/0xb0 drivers/iommu/iommu.c:385 mock_dev_create drivers/iommu/iommufd/selftest.c:1025 [inline] iommufd_test_mock_domain drivers/iommu/iommufd/selftest.c:1066 [inline] iommufd_test+0x2f8a/0x6190 drivers/iommu/iommufd/selftest.c:2072 iommufd_fops_ioctl+0x367/0x540 drivers/iommu/iommufd/main.c:533 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x116/0x800 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fix this by calling dev_iommu_free(dev) instead of iommu_fwspec_free(dev) in the device_add() failure path. dev_iommu_free() frees both fwspec and the outer dev_iommu struct and clears dev->iommu. | ||||
| CVE-2026-89445 | 1 Linux | 1 Linux Kernel | 2026-09-11 | 4.1 Medium |
| In the Linux kernel, the following vulnerability has been resolved: iommufd: Fix UAF in selftest IOPF reporting IOMMUFD selftest TRIGGER_IOPF borrows an attach handle from group->pasid_array without synchronizing against PASID detach, then a concurrent iommu_report_device_fault() can dereference that borrowed handle's domain pointer after the detach erases the handle and frees the backing struct iommufd_attach_handle. TRIGGER_IOPF then dereferences the freed handle, causing a UAF. Fix by adding a iopf_rwsem in mock_dev to follow the expected design of a real driver. Hold its read side across the whole iommu_report_device_fault() call, and its write side around every path that attaches, detaches, or replaces a device domain. This can block new reports and drains in-flight reports before an old attach handle or the IOPF fault parameter can be removed. Also take the write side while registering a mock device, since it can invoke the mock driver's default-domain attach callback. | ||||
| CVE-2026-89444 | 1 Linux | 1 Linux Kernel | 2026-09-11 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-wmi-sysman: Don't hex dump attribute security buffer set_attribute() populates the security area of the BIOS attribute request buffer with the current admin password via populate_security_buffer(), then dumps the whole request buffer with print_hex_dump_bytes(). This can expose the plaintext admin password in the kernel log. The same issue was fixed for the password attribute path by commit d1a196e0a6dc ("platform/x86: dell-wmi-sysman: Don't hex dump plaintext password data"). Remove the remaining dump from the BIOS attribute path. | ||||
| CVE-2026-89440 | 1 Linux | 1 Linux Kernel | 2026-09-11 | 5.8 Medium |
| In the Linux kernel, the following vulnerability has been resolved: mmc: via-sdmmc: stop card-detect handling on probe failure request_irq() registers the SD card-detect interrupt and the probe enables it before mmc_add_host() runs. If mmc_add_host() fails, the error path only unmaps the registers and returns: the interrupt stays registered, so the handler keeps running against the host once it is freed. via_sdc_isr() dereferences sdhost and its MMIO base and schedules carddet_work, which via_sdc_card_detect() also runs against freed memory through its container_of() dereference. Add a probe-error path that disables and frees the interrupt and cancels carddet_work before unmapping. carddet_work can re-enable the device interrupt via via_reset_pcictrl(), which restores PCIINTCTRL, so mask it again after cancelling the work. This issue was found by an in-house static analysis tool and confirmed by manual code review. | ||||
| CVE-2026-89438 | 1 Linux | 1 Linux Kernel | 2026-09-11 | 4.7 Medium |
| In the Linux kernel, the following vulnerability has been resolved: platform/x86: ISST: Validate logical CPU id and clos id Validate max CLOS ID and logical CPU ID for core power feature. Reject any clos level or logical CPU number greater than the supported maximum. These are used to calculate MMIO offset. | ||||
| CVE-2026-81016 | 1 Linux | 1 Linux Kernel | 2026-09-11 | 4.1 Medium |
| In the Linux kernel, the following vulnerability has been resolved: platform/x86/amd/pmc: Propagate SMU errors and validate S2D address amd_stb_s2d_init() discards the return value of several S2D SMU commands. When the SMU refuses a command (e.g. "SMU cmd failed. err: 0xff") the failure is only noticed indirectly - if at all - and reported as -EIO, masking the real error. More seriously, the S2D_PHYS_ADDR_LOW/HIGH return values are ignored, so on failure phys_addr_low/hi are left uninitialised and the assembled address is passed straight to devm_ioremap(). When the SMU leaves them at zero this maps physical address 0 and trips the ioremap-on-RAM warning: amd_pmc AMDI000B:00: SMU cmd failed. err: 0xff ioremap on RAM at 0x0000000000000000 - 0x0000000000ffffff WARNING: CPU: 13 PID: 4592 at arch/x86/mm/ioremap.c:... Check the return value of each SMU command and propagate it, and reject a zero physical address before calling devm_ioremap(). | ||||
| CVE-2026-81013 | 1 Linux | 1 Linux Kernel | 2026-09-11 | 4.7 Medium |
| In the Linux kernel, the following vulnerability has been resolved: platform/x86: hp-bioscfg: fix heap OOB read on empty password write validate_password_input() computes length = strlen(buf) and then checks buf[length - 1] to strip a trailing newline, without checking that length is nonzero first. Writing an empty string (a bare '\n') to current_password or new_password gives length == 0, and buf[length - 1] reads buf[-1], one byte before the heap allocation holding the copied input. KASAN confirms this directly: BUG: KASAN: slab-out-of-bounds in store_password_instance.constprop.0+0x223/0x2a0 [hp_bioscfg] Read of size 1 at addr ffff88811bd8da9f by task sh/13740 ... store_password_instance.constprop.0+0x223/0x2a0 [hp_bioscfg] current_password_store+0x14/0x20 [hp_bioscfg] ... The buggy address is located 23 bytes to the right of allocated 8-byte region [ffff88811bd8da80, ffff88811bd8da88) Reproduced identically via new_password_store. Execution continues past the bad read (the garbage byte only affects whether "length" is decremented by one), so the write completes and returns success; this is a pure information read past the buffer, not a crash, but it is still an out-of-bounds access KASAN correctly flags. Fix by only checking buf[length - 1] when length is nonzero. | ||||
| CVE-2026-81012 | 1 Linux | 1 Linux Kernel | 2026-09-11 | 5.1 Medium |
| In the Linux kernel, the following vulnerability has been resolved: platform/x86: hp-bioscfg: fix off-by-one write in hp_get_string_from_buffer() hp_get_string_from_buffer() clamps the converted string length against the destination buffer size with "size > dst_size", so when the converted length is exactly equal to dst_size, conv_dst_size is left at dst_size and the unconditional NUL terminator write dst[conv_dst_size] = 0; lands one byte past the destination buffer. This is the same shape of bug as the previously fixed off-by-one in hp_convert_hexstr_to_str(): the buffer is sized correctly for the content, but the terminator write is never checked against that size. Fix by changing the comparison to ">=" so conv_dst_size is always left with room for the terminator. All fixed-size destinations that reach this function (path[512], current_value[512], current_password/current_value[64], and the per-entry buffers in encodings[][512] and prerequisites[][512]) are affected. | ||||
| CVE-2026-81009 | 1 Linux | 1 Linux Kernel | 2026-09-11 | 4.7 Medium |
| In the Linux kernel, the following vulnerability has been resolved: io_uring/query: cap user size passed to copy_struct_to_user io_handle_query_entry() clamps hdr.size for the inbound copy_from_user() but keeps the original user value as usize. copy_struct_to_user() uses that usize and, when it is larger than the kernel result, clear_user()s the trailing bytes. As hdr.size is a __u32, a query can request nearly 4 GiB of zeroing, including on the error path where res_size stays 0. The interface is reachable without a ring via IORING_REGISTER_QUERY. Reject sizes larger than PAGE_SIZE, as recommended for copy_struct_* interfaces. | ||||
| CVE-2026-81006 | 1 Linux | 1 Linux Kernel | 2026-09-11 | 4.7 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ipmi: Remove all sysfs files on registration failure ipmi_add_smi() creates the nr_users and nr_msgs files before trying to create the maintenance_mode file. If that last creation fails, the error path removes only nr_users before dropping the final reference to the interface. Remove nr_msgs as well so no sysfs attribute embedded in the freed interface remains registered. | ||||
| CVE-2026-81004 | 1 Linux | 1 Linux Kernel | 2026-09-11 | 4.4 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ipmi:msghandler: Cancel work cleanly on an error If an error occurs during startup of an IPMI interface, it may have scheduled work to run. The work needs to be canceled before the interface can be freed. | ||||
| CVE-2026-81001 | 1 Linux | 1 Linux Kernel | 2026-09-11 | 4.7 Medium |
| In the Linux kernel, the following vulnerability has been resolved: slip: fix use-after-free in sl_sync() slip_devs[] stores bare net_device pointers and takes no reference on them. sl_sync() and sl_alloc() walk that table from slip_open() under rtnl_lock(), while an entry is dropped by sl_free_netdev(), which sl_setup() installs as dev->priv_destructor. priv_destructor is called from netdev_run_todo(), which deliberately runs with the RTNL semaphore released so that it can sleep while waiting for the device refcount to drop: /* Snapshot list, allow later requests */ list_replace_init(&net_todo_list, &list); __rtnl_unlock(); ... if (dev->priv_destructor) dev->priv_destructor(dev); /* slip_devs[i] = NULL */ if (dev->needs_free_netdev) free_netdev(dev); ... /* Free network device */ kobject_put(&dev->dev.kobj); So rtnl_lock() does not serialise slip_open() against the teardown at all. sl_sync() can load slip_devs[i] while the entry is still published and dereference it after netdev_run_todo() has run the destructor and released the device: CPU0 (slip_open) CPU1 (slip_close) unregister_netdev() rtnl_unlock() netdev_run_todo() __rtnl_unlock() rtnl_lock() sl_sync() dev = slip_devs[i] priv_destructor(dev) slip_devs[i] = NULL kobject_put(&dev->dev.kobj) /* dev is freed */ sl = netdev_priv(dev) if (sl->tty || sl->leased) /* use-after-free */ BUG: KASAN: use-after-free in sl_sync drivers/net/slip/slip.c:730 [inline] BUG: KASAN: use-after-free in slip_open+0xef4/0x1210 drivers/net/slip/slip.c:806 Read of size 1 at addr ffff8880712dac71 by task syz-executor.2/6506 CPU: 2 PID: 6506 Comm: syz-executor.2 Not tainted 6.1.134-syzkaller-00260-g0c8fc3469765 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 Call Trace: sl_sync drivers/net/slip/slip.c:730 [inline] slip_open+0xef4/0x1210 drivers/net/slip/slip.c:806 tty_ldisc_open+0xa2/0x120 drivers/tty/tty_ldisc.c:433 tty_set_ldisc+0x324/0x720 drivers/tty/tty_ldisc.c:564 tiocsetd drivers/tty/tty_io.c:2428 [inline] tty_ioctl+0x5f0/0x1530 drivers/tty/tty_io.c:2712 Allocated by task 6502: alloc_netdev_mqs+0x98/0xfe0 net/core/dev.c:10719 sl_alloc drivers/net/slip/slip.c:756 [inline] slip_open+0x36d/0x1210 drivers/net/slip/slip.c:817 tty_ldisc_open+0xa2/0x120 drivers/tty/tty_ldisc.c:433 tty_set_ldisc+0x324/0x720 drivers/tty/tty_ldisc.c:564 Freed by task 6497: device_release+0xa2/0x240 drivers/base/core.c:2507 kobject_put+0x179/0x280 lib/kobject.c:729 netdev_run_todo+0x6c8/0xef0 net/core/dev.c:10509 slip_close+0x166/0x1c0 drivers/net/slip/slip.c:906 tty_ldisc_close+0x113/0x1a0 drivers/tty/tty_ldisc.c:456 tty_ldisc_kill+0x94/0x160 drivers/tty/tty_ldisc.c:614 tty_ldisc_release+0xe3/0x2b0 drivers/tty/tty_ldisc.c:782 tty_release+0xbcc/0xe70 drivers/tty/tty_io.c:1860 Commit e58c19124189 ("slip: Fix use-after-free Read in slip_open") fixed a different source of stale entries - a device left in slip_devs[] after slip_open() freed it on the registration error path - and does not address this race, which is why the report survives it. Drop the entry from ndo_uninit instead. unregister_netdevice() calls ndo_uninit under RTNL, before the device is queued to netdev_run_todo(), so an entry that sl_sync() can still see while holding RTNL belongs to a device that cannot be freed until RTNL is dropped. sl_free_netdev() stays only for the slip_open() error path, where register_netdevice() may have failed before ndo_init and ndo_uninit is then not called either. Both running for the same device is harmless: the ---truncated--- | ||||
| CVE-2026-81000 | 1 Linux | 1 Linux Kernel | 2026-09-11 | 6.4 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net: tun: bound receive headroom tun_get_user() uses tun->align both as skb headroom and when choosing how much packet data to keep linear. OVS can propagate an oversized headroom request from another port to TUN or TAP. When align is larger than the usable space in a one-page skb head, SKB_MAX_HEAD(align) underflows and the result becomes negative when stored in good_linear. That value later wraps when assigned to the size_t linear variable, and tun_alloc_skb() can place skb->data outside the allocated head. Bound the headroom stored by TUN to the one-page skb-head budget and the largest non-sentinel 16-bit skb header offset. Leave one linear byte for raw TUN and a complete Ethernet header for TAP, including NET_IP_ALIGN. Also pull the raw-TUN protocol byte and the TAP Ethernet header before accessing them, so these checks remain safe for nonlinear skbs supplied by other allocation paths. | ||||
| CVE-2026-80998 | 1 Linux | 1 Linux Kernel | 2026-09-11 | 5.9 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net: bnxt: ring the doorbell when SW USO exits early When a burst of packets is handed down to the driver, the driver defers the doorbell to the end by setting txr->kick_pending = 1. The normal TX path handles this, but the SW USO path can miss it if it returns early. If bnxt_sw_udp_gso_xmit runs but returns early with NETDEV_TX_BUSY and txr->kick_pending was previously set to 1, then the TX queue can stall because the driver wrote some BDs but never wrote the doorbell. The device won't know to do the TX which would generate the completion that would wake the queue back up. Simplify bnxt_sw_udp_gso_xmit to set txr->kick_pending in its success case and check the flag on return. The added check after bnxt_sw_udp_gso_xmit returns ensures that any pending doorbells are written handling both successful USO and any early returns, which prevents the TX queue stall mentioned above. This TX queue stall was observed on a production system with a netdev TX watchdog informing about the queue stall. | ||||
| CVE-2026-80997 | 1 Linux | 1 Linux Kernel | 2026-09-11 | 4.7 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net: ipa: fix stalled modem TX queue after runtime resume ipa_start_xmit() unconditionally stops the TX queue before calling pm_runtime_get(), relying on the wake scheduled by runtime resume (ipa_modem_wake_queue_work()) to restart it once power is ACTIVE. But that work is queued from within the runtime resume callback, before the device's power state reaches RPM_ACTIVE, so it can run while the device is still RPM_RESUMING. The wake is then consumed too early: the transmit it restarts stops the queue again, pm_runtime_get() returns -EINPROGRESS without arranging any future wake (deferred_resume exists only for RPM_SUSPENDING), and after the resume completes nothing is left to wake the queue. Transmit stalls permanently: packets pile up in the qdisc behind the stopped queue, the device runtime-suspends, and since the netdev registers no ndo_tx_timeout the watchdog never fires. Observed on SM7635 (Fairphone 6) as the cellular data path going permanently deaf within hours, RX included, since nothing resumes the suspended endpoints. Close the window by making the wake work wait for the resume to complete (pm_runtime_get_sync()) before waking the queue. Every queue stop is then guaranteed a later wake that happens while power is ACTIVE; a transmit racing a new suspend/resume cycle re-schedules the work. If the device could not be resumed, wake the queue anyway so pending packets are dropped by the transmit path rather than stranded. The STARTED power flag used to narrow this window: a wake running before the transmit path's stop suppressed that stop, but only once, as the flag was cleared by the first stop it absorbed. Removing the flag made a single transmit during an in-flight resume sufficient to strand the queue, which is the form observed. With an accelerated reproducer (autosuspend delay shortened to 5 ms, ~20 packets/s of TX), an unpatched kernel stalled three times in 230 s / 4380 packets; with this patch the same test ran 3601 s / 70298 packets without a stall. | ||||
| CVE-2026-80996 | 1 Linux | 1 Linux Kernel | 2026-09-11 | 4.4 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net: l2tp: do not propagate multicast notification errors The tunnel create, tunnel modify, session create, and session modify netlink handlers send multicast notifications through helpers that can fail while allocating or encoding a message, or while multicasting it. For tunnel and session create/modify, a notification is sent after the live operation has completed. Returning a best-effort notification error as the command result can therefore report failure for an operation that already committed and can cause callers to retry and accumulate live objects. Keep sending notifications for listener visibility, but do not propagate their best-effort status as the command result. This also keeps the tunnel modify command consistent with the other notification-only paths. | ||||