Export limit exceeded: 403509 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (403509 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-80425 | 1 Ibm | 1 Datastage On Cloud Pak For Data | 2026-10-06 | 8.8 High |
| IBM DataStage on Cloud Pak for Data 5.4.0.0 could allow a remote authenticated attacker to execute arbitrary commands due to improper neutralization of special elements used in an OS command. | ||||
| CVE-2026-80423 | 1 Ibm | 1 Datastage On Cloud Pak For Data | 2026-10-06 | 8.8 High |
| IBM DataStage on Cloud Pak for Data 5.4.0.0 could allow a remote authenticated attacker to obtain sensitive information due to the exposure of namespace-wide secrets via accessible file mounts. | ||||
| CVE-2026-81208 | 1 Ibm | 1 Datastage On Cloud Pak For Data | 2026-10-06 | 7.7 High |
| IBM DataStage on Cloud Pak for Data 5.4.0.0 could allow an authenticated user to access sensitive information due to improper handling of encrypted credentials. An attacker could exploit this vulnerability to obtain credentials intended for other users or environments. | ||||
| CVE-2026-81536 | 1 Ibm | 1 Datastage On Cloud Pak For Data | 2026-10-06 | 7.7 High |
| IBM DataStage on Cloud Pak for Data 5.4.0.0 could allow a remote authenticated attacker to obtain sensitive information due to an XML external entity (XXE) injection. | ||||
| CVE-2026-81537 | 1 Ibm | 1 Datastage On Cloud Pak For Data | 2026-10-06 | 8.8 High |
| IBM DataStage on Cloud Pak for Data 5.4.0.0 could allow a remote authenticated attacker to execute arbitrary code due to OS command injection. | ||||
| CVE-2026-81539 | 1 Ibm | 1 Datastage On Cloud Pak For Data | 2026-10-06 | 8.8 High |
| IBM DataStage on Cloud Pak for Data 5.4.0.0 could allow a remote authenticated attacker to execute arbitrary code due to improper neutralization of special elements used in an OS command. | ||||
| CVE-2026-81545 | 1 Ibm | 1 Datastage On Cloud Pak For Data | 2026-10-06 | 8.8 High |
| IBM DataStage on Cloud Pak for Data 5.4.0.0 could allow a remote authenticated attacker to execute arbitrary commands due to improper neutralization of special elements used in an OS command. | ||||
| CVE-2026-81547 | 1 Ibm | 1 Datastage On Cloud Pak For Data | 2026-10-06 | 8.8 High |
| IBM DataStage on Cloud Pak for Data 5.4.0.0 could allow a remote authenticated attacker to execute arbitrary commands due to path traversal. | ||||
| CVE-2026-98182 | 1 Linux | 1 Linux Kernel | 2026-10-06 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: refuse to make a monitor active when it has no queue A monitor interface only gets a TXQ if it's created active, and one can't be added later. Setting the flag on a down interface is still allowed, so the driver is handed a monitor with no queue. ath9k dereferences it: BUG: kernel NULL pointer dereference, address: 0000000000000066 RIP: 0010:ath_tx_node_init+0x49/0x170 [ath9k] ath9k_add_interface+0x10c/0x140 [ath9k] drv_add_interface+0x54/0x250 [mac80211] ieee80211_do_open+0x32f/0x800 [mac80211] Reached with CAP_NET_ADMIN by "iw dev X set monitor active" followed by "ip link set X up". RTNL is held, so netlink operations block behind it. Refuse the flag when there is no queue to give. | ||||
| CVE-2026-98183 | 1 Linux | 1 Linux Kernel | 2026-10-06 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: avoid out-of-bounds read for empty PREQ elements ieee80211_mesh_preq_size_ok() derives the location of the PREQ bottom fields before checking whether the element contains even the fixed header. ieee80211_mesh_hwmp_preq_get_bottom() reads the flags byte to account for the optional Address Extension field. Consequently, an empty PREQ element causes a one-byte read beyond its declared payload. Move the helper call after both size checks, so the bottom fields are only accessed when they are present. | ||||
| CVE-2026-98187 | 1 Linux | 1 Linux Kernel | 2026-10-06 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: wifi: p54: require a full exp_if record in PDR_INTERFACE_LIST The PDR_INTERFACE_LIST loop only checks that the record start is within the entry before reading an entire struct exp_if from it. A truncated trailing record makes the if_id/variant reads cross the entry boundary into the heap beyond the EEPROM buffer (verified with a KASAN reproducer of the loop). The variant also feeds the synth front-end selection, so this is not only a leak. Advance only while a full record still fits in the entry. | ||||
| CVE-2026-98246 | 1 Linux | 1 Linux Kernel | 2026-10-06 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: Serialize local codec list cleanup hci_dev_close_sync() clears hdev->local_codecs after releasing hdev->lock. Codec list additions and both traversals in sco_sock_getsockopt() use that lock, but the close path does not. A close and BT_CODEC query can therefore interleave as follows: hci_dev_close_sync() sco_sock_getsockopt() hci_dev_lock() fetch codec entry hci_codec_list_clear() kfree(entry) read entry->id The reader then accesses an entry which the close path has freed. KASAN BUG: KASAN: slab-use-after-free in sco_sock_getsockopt+0xfa0/0xfe0 Read of size 1 at addr ffff8881001c3450 Call Trace: sco_sock_getsockopt+0xfa0/0xfe0 do_sock_getsockopt+0x537/0x7b0 __sys_getsockopt+0xf2/0x170 Allocated by task 92: hci_codec_list_add.isra.0+0x2c/0x440 hci_read_codec_capabilities+0x224/0x590 hci_read_supported_codecs+0x2c2/0x640 Freed by task 92: kfree+0x131/0x3c0 hci_codec_list_clear+0xd8/0x160 hci_dev_close_sync+0x92a/0xfa0 Take hdev->lock around the clear operation at its existing point in the close path. This makes the clear wait for active readers and prevents a new traversal until the list is empty without changing teardown ordering. | ||||
| CVE-2026-98328 | 1 Linux | 1 Linux Kernel | 2026-10-06 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: add HE 6 GHz capability in the scan elems len The HE 6 GHz Band Capability element is in the probe request for every band if 6 GHz is supported, so add the size to scan_ies_len. Otherwise, building probe request elements can fail, triggering the WARN_ON in __ieee80211_start_scan(). | ||||
| CVE-2026-70341 | 3 Apple, Linux, Microsoft | 5 Macos, Linux Kernel, Edge and 2 more | 2026-10-06 | 8.5 High |
| Use after free in Microsoft Edge (Chromium-based) allows an authorized attacker to execute code over a network. | ||||
| CVE-2026-98196 | 1 Linux | 1 Linux Kernel | 2026-10-06 | 7.0 High |
| 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. | ||||
| CVE-2026-98202 | 1 Linux | 1 Linux Kernel | 2026-10-06 | N/A |
| 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. | ||||
| CVE-2026-98205 | 1 Linux | 1 Linux Kernel | 2026-10-06 | N/A |
| 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. | ||||
| CVE-2026-98232 | 1 Linux | 1 Linux Kernel | 2026-10-06 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: scsi: core: Validate MODE SENSE lengths in scsi_cdl_enable() scsi_cdl_enable() uses length fields returned by MODE SENSE to locate the ATA feature mode page in a 64-byte stack buffer. A target can report a total length shorter than its mode header and block descriptors. The unsigned subtraction used for the MODE SELECT length can wrap, and the separately computed buf_data can point beyond buf. During automatic scan, enable is false, so the read-modify-write of buf_data[4] can clear the low two bits of a target-selected out-of-bounds stack byte. scsi_mode_select() can then copy up to 64 bytes from outside the buffer into the outgoing MODE SELECT payload, disclosing stack contents to the target. This is reachable while scanning a USB storage device that identifies as an ATA device and advertises CDL support. No filesystem mount or userspace access to the block device is required. On upstream commit cee9395acd80 ("Linux 7.3-rc1"), a build-specific, one-vCPU QEMU/Raw Gadget proof using QEMU-only multi-UDC allocator sampling executed a fixed proof command inside the guest and created a UID-0-owned marker during automatic enumeration, with KASLR and NX enabled. The issue was independently found during security research at Drivesec S.r.l. Cap the available length to the buffer size. Validate and consume the mode header and block descriptor lengths before using the page, and require the five bytes needed to access the CDL field. | ||||
| CVE-2026-98242 | 1 Linux | 1 Linux Kernel | 2026-10-06 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: dma-buf: Fix silent overflow for phys vec to sgt In case MMIO size is bigger than 4G and peer2peer DMA goes through host bridge, we trigger a code path that assigns the total linked IOVA (which is greater than 4G) to mapped_len. Previously, `mapped_len` was declared as 32-bit `unsigned int`. When accumulating `size_t` lengths, this leads to a silent wrap-around. This truncation causes truncated lengths to be passed to functions like `fill_sg_entry()`. Fix this by changing `mapped_len` to `size_t` (64-bit). While at it, fix similar potential overflow issues in `calc_sg_nents` by using `check_add_overflow()` for `nents` and using `unsigned int` for the loop iterator in `fill_sg_entry` to match. | ||||
| CVE-2026-98340 | 1 Linux | 1 Linux Kernel | 2026-10-06 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: only group hidden BSSes with beacon entries When a probe response for an unknown BSS comes in, __cfg80211_bss_update() looks for an existing entry with the same BSSID and a hidden (zero-length or NUL-filled) SSID, and if it finds one it groups them, using the beacon IEs from the existing entry. But that could find another entry without a beacon, if it was also from a probe response (with SSID), so there's a group without beacon elements. If a beacon with a hidden SSID for that BSSID arrives later, cfg80211_combine_bsses() goes looking for the probe response entries that belong to it - i.e. entries with the same BSSID and channel that have no beacon IEs - and finds those two. They are already grouped with each other, so it hits its WARN_ON_ONCE(bss->pub.hidden_beacon_bss) WARN_ON_ONCE(!list_empty(&bss->hidden_list)) which are there because an entry without beacon elements is not supposed to be part of a group yet. Only combine entries when a beacon was already received, ones that are kept separate will be combined when a beacon arrives. | ||||