Export limit exceeded: 395620 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (395620 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2025-1350 | 1 Ibm | 1 Controller | 2026-09-19 | 5.3 Medium |
| IBM Controller 11.0.0 through 11.0.1 FP7, and 11.1.0 through 11.1.3 FP1 could allow a remote attacker to obtain sensitive information when a detailed technical error message is returned in the browser. This information could be used in further attacks against the system. | ||||
| CVE-2024-56344 | 1 Ibm | 1 Cognos Analytics | 2026-09-19 | 5.9 Medium |
| IBM Cognos Analytics 12.0.4 through 12.0.4 FP2, and 12.1.0 through 12.1.3 FP1 could allow a remote attacker to obtain sensitive information, caused by the failure to properly enable HTTP Strict Transport Security. An attacker could exploit this vulnerability to obtain sensitive information using man in the middle techniques. | ||||
| CVE-2026-82560 | 2026-09-19 | N/A | ||
| Pod::Text versions before 6.1.1 for Perl allow CPU and memory exhaustion formatting a POD document whose =over nesting drives the margin to the output width. Each =over adds its indent to the margin, which wrap() subtracts from the output width to get the space available for text. When that space reaches zero, the line-splitting substitution matches the empty string, and the loop consumes no input while appending the margin padding on every pass. Formatting an attacker-supplied POD document never returns, and the output grows until memory is exhausted. | ||||
| CVE-2026-90242 | 1 Linux | 1 Linux Kernel | 2026-09-19 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix iopf_refcount leak on RID domain replacement intel_iommu_attach_device() enables IOPF for the new domain but never disables it for the old one. device_block_translation(), called at the start of the function, tears down translation but does not touch any IOPF state; blocking_domain_attach_dev() has to call iopf_for_domain_remove() explicitly before invoking it for exactly this reason. identity_domain_attach_dev() has the same problem. Its comment claims that no PRI handling is needed because the device has been put in the blocking state, but the blocking state and the IOPF reference count are independent of each other. As a result, replacing a domain that has an iopf_handler with another domain at RID level leaks a reference in info->iopf_refcount. The count never drops back to zero, so iopf_queue_remove_device() is never called and iommu_disable_pci_pri() triggers its WARN_ON(info->iopf_refcount) when the device is released. The PASID paths already handle this correctly by way of iopf_for_domain_replace(); convert the two RID paths to do the same. Using the replace helper rather than a bare remove keeps the enable before the disable, so the reference count does not transiently reach zero and evict the device from the IOPF queue. | ||||
| CVE-2026-90244 | 1 Linux | 1 Linux Kernel | 2026-09-19 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: iommu/dma: Restore locking around msi_page_list Unlike a group's default domain, which is always freshly allocated and privately owned (iommu_group_alloc_default_domain()), VFIO type1's legacy container merges any newly attached group into an existing domain whenever their iommu_ops and cache-coherency enforcement match. iommu_dma_get_msi_page() only asserts the caller's own group mutex is held (iommu_group_mutex_assert()). On an IOMMU that publishes IOMMU_RESV_SW_MSI, e.g. ARM SMMU, a VM with two such devices assigned through the legacy container can have their guest drivers probe and allocate MSIs in parallel; each host-side VFIO_DEVICE_SET_IRQS lands on a different device fd and group mutex, but both devices' domains are the same merged domain, so both can enter iommu_dma_get_msi_page() concurrently and corrupt msi_page_list. commit 288683c92b1a ("iommu: Make iommu_dma_prepare_msi() into a generic operation") dropped the prior msi_prepare_lock on the reasoning that "each iommu_domain is unique to a group," which holds for default domains but not this VFIO type1 case. Restore the static lock, since it's only guarding a corner case and will likely never be contended. iommufd avoids the equivalent problem by having its own callers (iommufd_sw_map_msi()) take a ctx-wide sw_msi_lock before ever reaching the shared list. VFIO type1 can't mirror that since it dispatches to iommu_dma_sw_msi() which is outside VFIO's jurisdiction. | ||||
| CVE-2026-90245 | 1 Linux | 1 Linux Kernel | 2026-09-19 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: fbdev: kyro: Validate overlay viewport coordinates The overlay viewport end coordinates are computed from the viewport origin and dimensions using 32-bit unsigned arithmetic. Large input values can cause these calculations to wrap around before the resulting coordinates are passed to SetOverlayViewPort(). SetOverlayViewPort() packs the viewport coordinates into 16-bit register fields. The X coordinates are additionally adjusted by +2 and +1 before being written. Validate the coordinate calculations for 32-bit wraparound and ensure that the adjusted coordinates fit within their 16-bit register fields before calling SetOverlayViewPort(). Found by Linux Verification Center (linuxtesting.org) with SVACE. | ||||
| CVE-2026-90248 | 1 Linux | 1 Linux Kernel | 2026-09-19 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_api: fix teardown of an adopted proto on insert-race loss In tc_new_tfilter() the create branch sets tp_created = 1 before calling tcf_chain_tp_insert_unique(). When the caller loses the race (another request inserted a proto at the same chain/prio first), insert_unique() destroys the caller's own tp_new and returns the winner's proto with an extra reference. tp_created was never cleared, so the loser's errout path treated the winner's live proto as its own and called tcf_chain_tp_delete_empty() on it, silently unlinking an active classifier that the winning request already advertised via RTM_NEWTFILTER. Track the outcome of the insert step in a single tri-state variable so each errout path reacts correctly: - TP_NOT_CREATED: no proto created; pursue the old path. - TP_CREATED: proto inserted successfully; same code path as before. - TP_NOT_OWNED: New - lost the insert race; tp is another request's proto (chain ref already released by tp_new's destroy) Both errout reactions are single expressions derived from the state. This fix is motivated by the Sashiko's automated review of Patch (net/sched: cls_api: Always acquire rtnl_lock when destroying locked classifiers) [1][2]. The review identified the silent-unlink behaviour of an adopted proto's teardown when a request loses the tcf_chain_tp_insert_unique() race. [1] https://sashiko.dev/#/patchset/20260801125632.360365-1-jhs%40mojatatu.com [2] https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260801125632.360365-1-jhs%40mojatatu.com | ||||
| CVE-2026-90249 | 1 Linux | 1 Linux Kernel | 2026-09-19 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: iio: light: gp2ap002: Fix unbalanced runtime PM on repeated event writes The IIO core does not filter duplicate writes to the event enable attribute, so writing the same value twice invokes write_event_config() twice. Enabling twice leaks a runtime PM reference, preventing the device from ever suspending again; disabling twice underflows the usage count and triggers a "Runtime PM usage count underflow" warning. Bail out early when the requested state matches the current state. While at it, switch to pm_runtime_resume_and_get() so a failed resume is propagated to userspace instead of silently marking the event enabled. | ||||
| CVE-2026-90268 | 1 Linux | 1 Linux Kernel | 2026-09-19 | 8.1 High |
| In the Linux kernel, the following vulnerability has been resolved: scsi: sd: Fix error handling in sd_probe() after large pool creation failure After device_add(&sdkp->disk_dev) succeeds, sd_large_pool_create() failure must unregister disk_dev and let scsi_disk_release() free sdkp. Going through out_free_index kfree()s an already registered device and leaks the sysfs entry. | ||||
| CVE-2026-90305 | 1 Linux | 1 Linux Kernel | 2026-09-19 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: ARM: 9483/1: select HAVE_POSIX_CPU_TIMERS_TASK_WORK Commit c6e61c06d606 ("ARM: 9463/1: Allow to enable RT") enabled PREEMPT_RT on ARM but did not select HAVE_POSIX_CPU_TIMERS_TASK_WORK. This leaves CONFIG_POSIX_CPU_TIMERS_TASK_WORK disabled, so CPU timers expire in hard IRQ context. On PREEMPT_RT this makes run_posix_cpu_timers() take the sleeping sighand->siglock: BUG: sleeping function called from invalid context at spinlock_rt.c:48 rt_spin_lock from lock_task_sighand lock_task_sighand from run_posix_cpu_timers run_posix_cpu_timers from update_process_times ARM handles TIF_NOTIFY_RESUME on all return-to-user paths, including v7-M. ARM32 KVM host support was removed by commit 541ad0150ca4 ("arm: Remove 32bit KVM host support"), so the select need not be conditional on KVM. Select it to defer POSIX CPU timer expiry to task context. Reproduced with setrlimit(RLIMIT_CPU, ...) and a busy loop. The same path is used by setitimer(ITIMER_PROF or ITIMER_VIRTUAL) and POSIX CPU timers created with timer_create(). | ||||
| CVE-2026-90307 | 1 Linux | 1 Linux Kernel | 2026-09-19 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: RDMA/srp: fix heap information leak on a truncated SRP_CRED_REQ srp_recv_done() passes wc->byte_len to srp_process_rsp(). It passes nothing to srp_process_cred_req() and srp_process_aer_req(), which read fixed-size fields from the receive buffer without checking that those fields were received. The buffer size is max_ti_iu_len, which comes from the login response and is not validated. A target that advertises 8 and then sends an 8-byte SRP_CRED_REQ makes the initiator read req->tag from beyond the end of the buffer. req->tag is copied into the SRP_CRED_RSP and sent back, so those bytes reach the target. SRP_AER_REQ behaves the same way and also reads req->lun. The leak is 8 bytes per response. max_ti_iu_len also decides which slab cache the buffer comes from. With 8 the buffer is a kmalloc-8 object and the read is entirely outside it: BUG: KASAN: slab-out-of-bounds in srp_recv_done+0x172b/0x1aa0 Read of size 8 at addr ffff888104714da8 by task kworker/u8:3/50 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 8-byte region [ffff888104714da0, ffff888104714da8) Without KASAN the returned bytes are whatever is next in the slab. One run returned ".strtab". rsp->data[3] in srp_process_rsp() has the same problem: only resp_data_len is checked before it is read. Drop a request that is shorter than the structure being parsed, and check byte_len before the tsk_mgmt read. | ||||
| CVE-2026-90317 | 1 Linux | 1 Linux Kernel | 2026-09-19 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Invalidate RCU pointers after final spin unlock In a sleepable BPF program, a spin lock can provide the only RCU protection for a kptr. The final bpf_spin_unlock() ends that protection, but the verifier leaves the pointer valid. Another CPU can then free the object before the pointer is used. A capability-limited runtime PoC triggered a task_struct use-after-free in __bpf_get_task_stack(). Record whether the program is in an RCU-protected context before releasing the lock. Invalidate RCU-protected pointers only when the unlock leaves the final such context. This preserves valid pointers in non-sleepable programs and inside an explicit RCU read-side section. | ||||
| CVE-2026-90320 | 1 Linux | 1 Linux Kernel | 2026-09-19 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate external xattr entries when reading metadata ocfs2_validate_xattr_block() checks the xattr block header before the block reaches higher-level xattr users, but it does not verify that a non-indexed block's xh_count and entry offsets fit inside the block. Indexed buckets likewise reach list/get consumers after ECC without an entry-bounds check. Use the flat xattr entry validator for non-indexed external xattr blocks, and use a bucket-specific validator for indexed buckets at metadata read time. The bucket validator keeps the entry array bounded by the first bucket block while checking name/value offsets against the bucket block they target. Reject corrupted external xattr metadata before listxattr() or getxattr() can walk out-of-range entry arrays or name/value offsets. Validation reproduced this kernel report: BUG: KASAN: use-after-free in ocfs2_xattr_list_entries+0xd7/0x190 Read of size 1 at addr ffff88810a654007 by task ocfs2_xattr_lis/630 Call Trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 kasan_report+0xe0/0x110 ocfs2_xattr_list_entries+0xd7/0x190 ocfs2_listxattr+0x3f6/0x610 listxattr+0x90/0xe0 path_listxattrat+0xed/0x220 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f | ||||
| CVE-2026-90323 | 1 Linux | 1 Linux Kernel | 2026-09-19 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: ublk: validate auto buf reg before taking uring_cmd With UBLK_F_AUTO_BUF_REG, invalid sqe->addr can fail after ublk_fill_io_cmd() has set UBLK_IO_FLAG_ACTIVE. The uring_cmd is completed while the tag stays active, which can hang teardown. Split validation from buffer apply so the check has no side effects, then take the uring_cmd and store the already-validated buffer. Apply the same order in FETCH so io->buf is not written before __ublk_fetch() state checks. | ||||
| CVE-2026-76757 | 1 Drupal | 1 Gammu Sms Daemon | 2026-09-19 | 5.9 Medium |
| Vulnerability in Drupal Gammu SMS Daemon. This issue affects Gammu SMS Daemon versions: *.*. | ||||
| CVE-2026-90266 | 1 Linux | 1 Linux Kernel | 2026-09-19 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: btrfs: zoned: don't force read-only on transient -EAGAIN from reloc merge On a zoned FS, btrfs_delayed_refs_rsv_refill() returns -EAGAIN whenever the over-committed metadata plus the zone_unusable bytes exceeds the usable size in a metadata block-group to avoid heavy over-commit of metadata and early ENOSPC in one transaction. If this happens while doing reclaim, the transaction is getting aborted. Treat -EAGAIN as a soft, retryable condition in case of block-group reclaim. | ||||
| CVE-2026-90273 | 1 Linux | 1 Linux Kernel | 2026-09-19 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: coresight: etm4x: missing cscfg_csdev_disable_active_config() in perf enable In the perf enable path, there are missing cases where cscfg_csdev_disable_active_config() is not called: - Branch broadcast is selected but not supported by the hardware - etm4_enable_hw() fails This can lead to a leak of config_desc->active_cnt. Fix this by properly calling cscfg_csdev_disable_active_config() in these error paths. | ||||
| CVE-2026-90276 | 1 Linux | 1 Linux Kernel | 2026-09-19 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: md/md-llbitmap: stop daemon timer rearm on destroy llbitmap_destroy() deletes pending_timer before flushing md_llbitmap_io_wq. However, daemon_work can still be queued or running after the timer has been deleted, and the daemon path can arm pending_timer again when it finds dirty chunks that are not ready to flush yet. If that happens during teardown, pending_timer can remain armed after llbitmap is freed and later dereference freed memory. Add a BITMAP_SHUTDOWN bit to llbitmap->flags, set it before deleting the timer, and make the timer and daemon paths stop queueing or rearming work once teardown starts. Cancel daemon_work before flushing the shared workqueue so no already queued daemon instance can race with the free. Use timer_shutdown_sync() so a daemon instance that passed the shutdown check before teardown cannot rearm the timer afterward. BITMAP_SHUTDOWN is a runtime-only state. Mask it out when reading and updating the llbitmap superblock so the shutdown state is never loaded from disk or persisted to disk. | ||||
| CVE-2026-90329 | 1 Linux | 1 Linux Kernel | 2026-09-19 | 8.8 High |
| In the Linux kernel, the following vulnerability has been resolved: HID: synchronize input before cleaning up a failed probe hid_device_io_start() allows reports to run concurrently with probe. If the probe subsequently fails, __hid_device_probe() releases driver resources and clears hdev->driver without first excluding those report callbacks. For example, a report may enter hidraw_report_event() while the failure path frees the associated hidraw object, leading to a use-after-free when the report takes the object's list lock. Stop input before performing failed-probe cleanup. This reacquires driver_input_lock and waits for any report callback already in progress. | ||||
| CVE-2026-90335 | 1 Linux | 1 Linux Kernel | 2026-09-19 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: tty: skip cdev_del() when no cdev is registered TTY device registration can fail before a cdev is allocated. Serial core keeps the port so setserial can still use it, and later removal passes the NULL cdev slot to cdev_del(), causing a NULL-pointer dereference. Only delete the cdev when the slot is not NULL. | ||||