Search Results (7548 CVEs found)

CVE Vendors Products Updated CVSS v3.1
CVE-2024-36922 2 Linux, Redhat 3 Linux Kernel, Enterprise Linux, Rhel Eus 2025-10-01 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: read txq->read_ptr under lock If we read txq->read_ptr without lock, we can read the same value twice, then obtain the lock, and reclaim from there to two different places, but crucially reclaim the same entry twice, resulting in the WARN_ONCE() a little later. Fix that by reading txq->read_ptr under lock.
CVE-2025-30232 1 Exim 1 Exim 2025-09-30 8.1 High
A use-after-free in Exim 4.96 through 4.98.1 could allow users (with command-line access) to escalate privileges.
CVE-2024-43864 1 Linux 1 Linux Kernel 2025-09-29 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix CT entry update leaks of modify header context The cited commit allocates a new modify header to replace the old one when updating CT entry. But if failed to allocate a new one, eg. exceed the max number firmware can support, modify header will be an error pointer that will trigger a panic when deallocating it. And the old modify header point is copied to old attr. When the old attr is freed, the old modify header is lost. Fix it by restoring the old attr to attr when failed to allocate a new modify header context. So when the CT entry is freed, the right modify header context will be freed. And the panic of accessing error pointer is also fixed.
CVE-2025-10994 1 Openbabel 1 Open Babel 2025-09-29 5.3 Medium
A weakness has been identified in Open Babel up to 3.1.1. This affects the function GAMESSOutputFormat::ReadMolecule of the file gamessformat.cpp. This manipulation causes use after free. It is possible to launch the attack on the local host. The exploit has been made available to the public and could be exploited.
CVE-2024-56699 1 Linux 1 Linux Kernel 2025-09-26 7.8 High
In the Linux kernel, the following vulnerability has been resolved: s390/pci: Fix potential double remove of hotplug slot In commit 6ee600bfbe0f ("s390/pci: remove hotplug slot when releasing the device") the zpci_exit_slot() was moved from zpci_device_reserved() to zpci_release_device() with the intention of keeping the hotplug slot around until the device is actually removed. Now zpci_release_device() is only called once all references are dropped. Since the zPCI subsystem only drops its reference once the device is in the reserved state it follows that zpci_release_device() must only deal with devices in the reserved state. Despite that it contains code to tear down from both configured and standby state. For the standby case this already includes the removal of the hotplug slot so would cause a double removal if a device was ever removed in either configured or standby state. Instead of causing a potential double removal in a case that should never happen explicitly WARN_ON() if a device in non-reserved state is released and get rid of the dead code cases.
CVE-2024-46736 1 Linux 1 Linux Kernel 2025-09-26 7.8 High
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix double put of @cfile in smb2_rename_path() If smb2_set_path_attr() is called with a valid @cfile and returned -EINVAL, we need to call cifs_get_writable_path() again as the reference of @cfile was already dropped by previous smb2_compound_op() call.
CVE-2025-5068 1 Google 1 Chrome 2025-09-26 8.8 High
Use after free in Blink in Google Chrome prior to 137.0.7151.68 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: Medium)
CVE-2023-41093 1 Silabs 1 Bluetooth Low Energy Software Development Kit 2025-09-25 3.1 Low
Use After Free vulnerability in Silicon Labs Bluetooth SDK on 32 bit, ARM may allow an attacker with precise timing capabilities to intercept a small number of packets intended for a recipient that has left the network.This issue affects Silabs Bluetooth SDK: through 8.0.0.
CVE-2024-41045 1 Linux 1 Linux Kernel 2025-09-25 7.8 High
In the Linux kernel, the following vulnerability has been resolved: bpf: Defer work in bpf_timer_cancel_and_free Currently, the same case as previous patch (two timer callbacks trying to cancel each other) can be invoked through bpf_map_update_elem as well, or more precisely, freeing map elements containing timers. Since this relies on hrtimer_cancel as well, it is prone to the same deadlock situation as the previous patch. It would be sufficient to use hrtimer_try_to_cancel to fix this problem, as the timer cannot be enqueued after async_cancel_and_free. Once async_cancel_and_free has been done, the timer must be reinitialized before it can be armed again. The callback running in parallel trying to arm the timer will fail, and freeing bpf_hrtimer without waiting is sufficient (given kfree_rcu), and bpf_timer_cb will return HRTIMER_NORESTART, preventing the timer from being rearmed again. However, there exists a UAF scenario where the callback arms the timer before entering this function, such that if cancellation fails (due to timer callback invoking this routine, or the target timer callback running concurrently). In such a case, if the timer expiration is significantly far in the future, the RCU grace period expiration happening before it will free the bpf_hrtimer state and along with it the struct hrtimer, that is enqueued. Hence, it is clear cancellation needs to occur after async_cancel_and_free, and yet it cannot be done inline due to deadlock issues. We thus modify bpf_timer_cancel_and_free to defer work to the global workqueue, adding a work_struct alongside rcu_head (both used at _different_ points of time, so can share space). Update existing code comments to reflect the new state of affairs.
CVE-2022-48821 1 Linux 1 Linux Kernel 2025-09-25 7.8 High
In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: avoid double fput() on failed usercopy If the copy back to userland fails for the FASTRPC_IOCTL_ALLOC_DMA_BUFF ioctl(), we shouldn't assume that 'buf->dmabuf' is still valid. In fact, dma_buf_fd() called fd_install() before, i.e. "consumed" one reference, leaving us with none. Calling dma_buf_put() will therefore put a reference we no longer own, leading to a valid file descritor table entry for an already released 'file' object which is a straight use-after-free. Simply avoid calling dma_buf_put() and rely on the process exit code to do the necessary cleanup, if needed, i.e. if the file descriptor is still valid.
CVE-2025-47327 1 Qualcomm 83 Aqt1000, Aqt1000 Firmware, Fastconnect 6200 and 80 more 2025-09-25 7.8 High
Memory corruption while encoding the image data.
CVE-2025-27037 1 Qualcomm 75 Fastconnect 6800, Fastconnect 6800 Firmware, Fastconnect 6900 and 72 more 2025-09-25 7.8 High
Memory corruption while processing config_dev IOCTL when camera kernel driver drops its reference to CPU buffers.
CVE-2025-27077 2 Qnx, Qualcomm 56 Qnx, Qam8255p, Qam8255p Firmware and 53 more 2025-09-25 7.8 High
Memory corruption while processing message in guest VM.
CVE-2025-47315 2 Qnx, Qualcomm 56 Qnx, Qam8255p, Qam8255p Firmware and 53 more 2025-09-25 7.8 High
Memory corruption while handling repeated memory unmap requests from guest VM.
CVE-2025-47316 1 Qualcomm 59 Aqt1000, Aqt1000 Firmware, Fastconnect 6200 and 56 more 2025-09-25 7.8 High
Memory corruption due to double free when multiple threads race to set the timestamp store.
CVE-2025-10500 4 Apple, Google, Linux and 1 more 4 Macos, Chrome, Linux Kernel and 1 more 2025-09-25 8.8 High
Use after free in Dawn in Google Chrome prior to 140.0.7339.185 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)
CVE-2025-10501 4 Apple, Google, Linux and 1 more 4 Macos, Chrome, Linux Kernel and 1 more 2025-09-25 8.8 High
Use after free in WebRTC in Google Chrome prior to 140.0.7339.185 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)
CVE-2021-47479 1 Linux 1 Linux Kernel 2025-09-24 7.0 High
In the Linux kernel, the following vulnerability has been resolved: staging: rtl8712: fix use-after-free in rtl8712_dl_fw Syzbot reported use-after-free in rtl8712_dl_fw(). The problem was in race condition between r871xu_dev_remove() ->ndo_open() callback. It's easy to see from crash log, that driver accesses released firmware in ->ndo_open() callback. It may happen, since driver was releasing firmware _before_ unregistering netdev. Fix it by moving unregister_netdev() before cleaning up resources. Call Trace: ... rtl871x_open_fw drivers/staging/rtl8712/hal_init.c:83 [inline] rtl8712_dl_fw+0xd95/0xe10 drivers/staging/rtl8712/hal_init.c:170 rtl8712_hal_init drivers/staging/rtl8712/hal_init.c:330 [inline] rtl871x_hal_init+0xae/0x180 drivers/staging/rtl8712/hal_init.c:394 netdev_open+0xe6/0x6c0 drivers/staging/rtl8712/os_intfs.c:380 __dev_open+0x2bc/0x4d0 net/core/dev.c:1484 Freed by task 1306: ... release_firmware+0x1b/0x30 drivers/base/firmware_loader/main.c:1053 r871xu_dev_remove+0xcc/0x2c0 drivers/staging/rtl8712/usb_intf.c:599 usb_unbind_interface+0x1d8/0x8d0 drivers/usb/core/driver.c:458
CVE-2025-10824 1 Axboe 1 Fio 2025-09-24 5.3 Medium
A vulnerability was determined in axboe fio up to 3.41. This impacts the function __parse_jobs_ini of the file init.c. Executing manipulation can lead to use after free. The attack needs to be launched locally. The exploit has been publicly disclosed and may be utilized.
CVE-2022-48801 1 Linux 1 Linux Kernel 2025-09-24 7.8 High
In the Linux kernel, the following vulnerability has been resolved: iio: buffer: Fix file related error handling in IIO_BUFFER_GET_FD_IOCTL If we fail to copy the just created file descriptor to userland, we try to clean up by putting back 'fd' and freeing 'ib'. The code uses put_unused_fd() for the former which is wrong, as the file descriptor was already published by fd_install() which gets called internally by anon_inode_getfd(). This makes the error handling code leaving a half cleaned up file descriptor table around and a partially destructed 'file' object, allowing userland to play use-after-free tricks on us, by abusing the still usable fd and making the code operate on a dangling 'file->private_data' pointer. Instead of leaving the kernel in a partially corrupted state, don't attempt to explicitly clean up and leave this to the process exit path that'll release any still valid fds, including the one created by the previous call to anon_inode_getfd(). Simply return -EFAULT to indicate the error.