Search Results (14147 CVEs found)

CVE Vendors Products Updated CVSS v3.1
CVE-2025-23340 3 Linux, Microsoft, Nvidia 3 Linux Kernel, Windows, Cuda Toolkit 2025-10-06 3.3 Low
NVIDIA CUDA Toolkit for all platforms contains a vulnerability in the nvdisasm binary where a user may cause an out-of-bounds read by passing a malformed ELF file to nvdisasm. A successful exploit of this vulnerability may lead to a partial denial of service.
CVE-2025-23346 3 Linux, Microsoft, Nvidia 3 Linux Kernel, Windows, Cuda Toolkit 2025-10-06 3.3 Low
NVIDIA CUDA Toolkit contains a vulnerability in cuobjdump, where an unprivileged user can cause a NULL pointer dereference. A successful exploit of this vulnerability may lead to a limited denial of service.
CVE-2025-4598 5 Debian, Linux, Oracle and 2 more 8 Debian Linux, Linux Kernel, Linux and 5 more 2025-10-06 4.7 Medium
A vulnerability was found in systemd-coredump. This flaw allows an attacker to force a SUID process to crash and replace it with a non-SUID binary to access the original's privileged process coredump, allowing the attacker to read sensitive data, such as /etc/shadow content, loaded by the original process. A SUID binary or process has a special type of permission, which allows the process to run with the file owner's permissions, regardless of the user executing the binary. This allows the process to access more restricted data than unprivileged users or processes would be able to. An attacker can leverage this flaw by forcing a SUID process to crash and force the Linux kernel to recycle the process PID before systemd-coredump can analyze the /proc/pid/auxv file. If the attacker wins the race condition, they gain access to the original's SUID process coredump file. They can read sensitive content loaded into memory by the original binary, affecting data confidentiality.
CVE-2024-0137 2 Linux, Nvidia 4 Linux Kernel, Container Toolkit, Nvidia Container Toolkit and 1 more 2025-10-06 5.5 Medium
NVIDIA Container Toolkit contains an improper isolation vulnerability where a specially crafted container image could lead to untrusted code running in the host’s network namespace. This vulnerability is present only when the NVIDIA Container Toolkit is configured in a nondefault way. A successful exploit of this vulnerability may lead to denial of service and escalation of privileges.
CVE-2024-0136 2 Linux, Nvidia 4 Linux Kernel, Container Toolkit, Nvidia Container Toolkit and 1 more 2025-10-06 7.6 High
NVIDIA Container Toolkit contains an improper isolation vulnerability where a specially crafted container image could lead to untrusted code obtaining read and write access to host devices. This vulnerability is present only when the NVIDIA Container Toolkit is configured in a nondefault way. A successful exploit of this vulnerability may lead to code execution, denial of service, escalation of privileges, information disclosure, and data tampering.
CVE-2024-0135 2 Linux, Nvidia 4 Linux Kernel, Container Toolkit, Nvidia Container Toolkit and 1 more 2025-10-06 7.6 High
NVIDIA Container Toolkit contains an improper isolation vulnerability where a specially crafted container image could lead to modification of a host binary. A successful exploit of this vulnerability may lead to code execution, denial of service, escalation of privileges, information disclosure, and data tampering.
CVE-2025-39751 1 Linux 1 Linux Kernel 2025-10-06 7.0 High
This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE-2024-42130 1 Linux 1 Linux Kernel 2025-10-03 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: nfc/nci: Add the inconsistency check between the input data length and count write$nci(r0, &(0x7f0000000740)=ANY=[@ANYBLOB="610501"], 0xf) Syzbot constructed a write() call with a data length of 3 bytes but a count value of 15, which passed too little data to meet the basic requirements of the function nci_rf_intf_activated_ntf_packet(). Therefore, increasing the comparison between data length and count value to avoid problems caused by inconsistent data length and count.
CVE-2024-42260 1 Linux 1 Linux Kernel 2025-10-03 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Validate passed in drm syncobj handles in the performance extension If userspace provides an unknown or invalid handle anywhere in the handle array the rest of the driver will not handle that well. Fix it by checking handle was looked up successfully or otherwise fail the extension by jumping into the existing unwind. (cherry picked from commit a546b7e4d73c23838d7e4d2c92882b3ca902d213)
CVE-2024-42261 1 Linux 1 Linux Kernel 2025-10-03 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Validate passed in drm syncobj handles in the timestamp extension If userspace provides an unknown or invalid handle anywhere in the handle array the rest of the driver will not handle that well. Fix it by checking handle was looked up successfully or otherwise fail the extension by jumping into the existing unwind. (cherry picked from commit 8d1276d1b8f738c3afe1457d4dff5cc66fc848a3)
CVE-2024-42265 2 Linux, Redhat 3 Linux Kernel, Enterprise Linux, Rhel Eus 2025-10-03 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: protect the fetch of ->fd[fd] in do_dup2() from mispredictions both callers have verified that fd is not greater than ->max_fds; however, misprediction might end up with tofree = fdt->fd[fd]; being speculatively executed. That's wrong for the same reasons why it's wrong in close_fd()/file_close_fd_locked(); the same solution applies - array_index_nospec(fd, fdt->max_fds) could differ from fd only in case of speculative execution on mispredicted path.
CVE-2024-42267 1 Linux 1 Linux Kernel 2025-10-03 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: riscv/mm: Add handling for VM_FAULT_SIGSEGV in mm_fault_error() Handle VM_FAULT_SIGSEGV in the page fault path so that we correctly kill the process and we don't BUG() the kernel.
CVE-2024-38620 1 Linux 1 Linux Kernel 2025-10-03 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: HCI: Remove HCI_AMP support Since BT_HS has been remove HCI_AMP controllers no longer has any use so remove it along with the capability of creating AMP controllers. Since we no longer need to differentiate between AMP and Primary controllers, as only HCI_PRIMARY is left, this also remove hdev->dev_type altogether.
CVE-2024-38624 1 Linux 1 Linux Kernel 2025-10-03 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Use 64 bit variable to avoid 32 bit overflow For example, in the expression: vbo = 2 * vbo + skip
CVE-2024-38619 2 Linux, Redhat 2 Linux Kernel, Enterprise Linux 2025-10-03 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: usb-storage: alauda: Check whether the media is initialized The member "uzonesize" of struct alauda_info will remain 0 if alauda_init_media() fails, potentially causing divide errors in alauda_read_data() and alauda_write_lba(). - Add a member "media_initialized" to struct alauda_info. - Change a condition in alauda_check_media() to ensure the first initialization. - Add an error check for the return value of alauda_init_media().
CVE-2024-38618 2 Linux, Redhat 2 Linux Kernel, Enterprise Linux 2025-10-03 5.3 Medium
In the Linux kernel, the following vulnerability has been resolved: ALSA: timer: Set lower bound of start tick time Currently ALSA timer doesn't have the lower limit of the start tick time, and it allows a very small size, e.g. 1 tick with 1ns resolution for hrtimer. Such a situation may lead to an unexpected RCU stall, where the callback repeatedly queuing the expire update, as reported by fuzzer. This patch introduces a sanity check of the timer start tick time, so that the system returns an error when a too small start size is set. As of this patch, the lower limit is hard-coded to 100us, which is small enough but can still work somehow.
CVE-2024-38617 1 Linux 1 Linux Kernel 2025-10-03 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: kunit/fortify: Fix mismatched kvalloc()/vfree() usage The kv*() family of tests were accidentally freeing with vfree() instead of kvfree(). Use kvfree() instead.
CVE-2024-38615 2 Linux, Redhat 3 Linux Kernel, Enterprise Linux, Rhel Eus 2025-10-03 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: cpufreq: exit() callback is optional The exit() callback is optional and shouldn't be called without checking a valid pointer first. Also, we must clear freq_table pointer even if the exit() callback isn't present.
CVE-2024-38614 1 Linux 1 Linux Kernel 2025-10-03 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: openrisc: traps: Don't send signals to kernel mode threads OpenRISC exception handling sends signals to user processes on floating point exceptions and trap instructions (for debugging) among others. There is a bug where the trap handling logic may send signals to kernel threads, we should not send these signals to kernel threads, if that happens we treat it as an error. This patch adds conditions to die if the kernel receives these exceptions in kernel mode code.
CVE-2024-38611 1 Linux 1 Linux Kernel 2025-10-03 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: media: i2c: et8ek8: Don't strip remove function when driver is builtin Using __exit for the remove function results in the remove callback being discarded with CONFIG_VIDEO_ET8EK8=y. When such a device gets unbound (e.g. using sysfs or hotplug), the driver is just removed without the cleanup being performed. This results in resource leaks. Fix it by compiling in the remove callback unconditionally. This also fixes a W=1 modpost warning: WARNING: modpost: drivers/media/i2c/et8ek8/et8ek8: section mismatch in reference: et8ek8_i2c_driver+0x10 (section: .data) -> et8ek8_remove (section: .exit.text)