Total
33957 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2025-38065 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2025-12-17 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: orangefs: Do not truncate file size 'len' is used to store the result of i_size_read(), so making 'len' a size_t results in truncation to 4GiB on 32-bit systems. | ||||
| CVE-2025-38063 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2025-12-17 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: dm: fix unconditional IO throttle caused by REQ_PREFLUSH When a bio with REQ_PREFLUSH is submitted to dm, __send_empty_flush() generates a flush_bio with REQ_OP_WRITE | REQ_PREFLUSH | REQ_SYNC, which causes the flush_bio to be throttled by wbt_wait(). An example from v5.4, similar problem also exists in upstream: crash> bt 2091206 PID: 2091206 TASK: ffff2050df92a300 CPU: 109 COMMAND: "kworker/u260:0" #0 [ffff800084a2f7f0] __switch_to at ffff80004008aeb8 #1 [ffff800084a2f820] __schedule at ffff800040bfa0c4 #2 [ffff800084a2f880] schedule at ffff800040bfa4b4 #3 [ffff800084a2f8a0] io_schedule at ffff800040bfa9c4 #4 [ffff800084a2f8c0] rq_qos_wait at ffff8000405925bc #5 [ffff800084a2f940] wbt_wait at ffff8000405bb3a0 #6 [ffff800084a2f9a0] __rq_qos_throttle at ffff800040592254 #7 [ffff800084a2f9c0] blk_mq_make_request at ffff80004057cf38 #8 [ffff800084a2fa60] generic_make_request at ffff800040570138 #9 [ffff800084a2fae0] submit_bio at ffff8000405703b4 #10 [ffff800084a2fb50] xlog_write_iclog at ffff800001280834 [xfs] #11 [ffff800084a2fbb0] xlog_sync at ffff800001280c3c [xfs] #12 [ffff800084a2fbf0] xlog_state_release_iclog at ffff800001280df4 [xfs] #13 [ffff800084a2fc10] xlog_write at ffff80000128203c [xfs] #14 [ffff800084a2fcd0] xlog_cil_push at ffff8000012846dc [xfs] #15 [ffff800084a2fda0] xlog_cil_push_work at ffff800001284a2c [xfs] #16 [ffff800084a2fdb0] process_one_work at ffff800040111d08 #17 [ffff800084a2fe00] worker_thread at ffff8000401121cc #18 [ffff800084a2fe70] kthread at ffff800040118de4 After commit 2def2845cc33 ("xfs: don't allow log IO to be throttled"), the metadata submitted by xlog_write_iclog() should not be throttled. But due to the existence of the dm layer, throttling flush_bio indirectly causes the metadata bio to be throttled. Fix this by conditionally adding REQ_IDLE to flush_bio.bi_opf, which makes wbt_should_throttle() return false to avoid wbt_wait(). | ||||
| CVE-2025-46287 | 1 Apple | 3 Macos, Macos Sequoia, Macos Sonoma | 2025-12-17 | 9.8 Critical |
| An inconsistent user interface issue was addressed with improved state management. This issue is fixed in macOS Sonoma 14.8.3, macOS Sequoia 15.7.3. An attacker may be able to spoof their FaceTime caller ID. | ||||
| CVE-2025-43519 | 1 Apple | 3 Macos, Macos Sequoia, Macos Sonoma | 2025-12-17 | 7.5 High |
| A permissions issue was addressed with additional restrictions. This issue is fixed in macOS Sonoma 14.8.3, macOS Sequoia 15.7.3. An app may be able to access sensitive user data. | ||||
| CVE-2025-43512 | 1 Apple | 3 Macos, Macos Sequoia, Macos Sonoma | 2025-12-17 | 7.8 High |
| A logic issue was addressed with improved checks. This issue is fixed in macOS Sonoma 14.8.3, macOS Sequoia 15.7.3. An app may be able to elevate privileges. | ||||
| CVE-2025-43416 | 1 Apple | 3 Macos, Macos Sequoia, Macos Sonoma | 2025-12-17 | 9.8 Critical |
| A logic issue was addressed with improved restrictions. This issue is fixed in macOS Sonoma 14.8.3, macOS Sequoia 15.7.3. An app may be able to access protected user data. | ||||
| CVE-2025-38074 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2025-12-17 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: vhost-scsi: protect vq->log_used with vq->mutex The vhost-scsi completion path may access vq->log_base when vq->log_used is already set to false. vhost-thread QEMU-thread vhost_scsi_complete_cmd_work() -> vhost_add_used() -> vhost_add_used_n() if (unlikely(vq->log_used)) QEMU disables vq->log_used via VHOST_SET_VRING_ADDR. mutex_lock(&vq->mutex); vq->log_used = false now! mutex_unlock(&vq->mutex); QEMU gfree(vq->log_base) log_used() -> log_write(vq->log_base) Assuming the VMM is QEMU. The vq->log_base is from QEMU userpace and can be reclaimed via gfree(). As a result, this causes invalid memory writes to QEMU userspace. The control queue path has the same issue. | ||||
| CVE-2025-38071 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2025-12-17 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: x86/mm: Check return value from memblock_phys_alloc_range() At least with CONFIG_PHYSICAL_START=0x100000, if there is < 4 MiB of contiguous free memory available at this point, the kernel will crash and burn because memblock_phys_alloc_range() returns 0 on failure, which leads memblock_phys_free() to throw the first 4 MiB of physical memory to the wolves. At a minimum it should fail gracefully with a meaningful diagnostic, but in fact everything seems to work fine without the weird reserve allocation. | ||||
| CVE-2025-38067 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2025-12-17 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: rseq: Fix segfault on registration when rseq_cs is non-zero The rseq_cs field is documented as being set to 0 by user-space prior to registration, however this is not currently enforced by the kernel. This can result in a segfault on return to user-space if the value stored in the rseq_cs field doesn't point to a valid struct rseq_cs. The correct solution to this would be to fail the rseq registration when the rseq_cs field is non-zero. However, some older versions of glibc will reuse the rseq area of previous threads without clearing the rseq_cs field and will also terminate the process if the rseq registration fails in a secondary thread. This wasn't caught in testing because in this case the leftover rseq_cs does point to a valid struct rseq_cs. What we can do is clear the rseq_cs field on registration when it's non-zero which will prevent segfaults on registration and won't break the glibc versions that reuse rseq areas on thread creation. | ||||
| CVE-2025-38120 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2025-12-17 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_set_pipapo_avx2: fix initial map fill If the first field doesn't cover the entire start map, then we must zero out the remainder, else we leak those bits into the next match round map. The early fix was incomplete and did only fix up the generic C implementation. A followup patch adds a test case to nft_concat_range.sh. | ||||
| CVE-2025-38044 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2025-12-17 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: media: cx231xx: set device_caps for 417 The video_device for the MPEG encoder did not set device_caps. Add this, otherwise the video device can't be registered (you get a WARN_ON instead). Not seen before since currently 417 support is disabled, but I found this while experimenting with it. | ||||
| CVE-2025-38119 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2025-12-17 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: scsi: core: ufs: Fix a hang in the error handler ufshcd_err_handling_prepare() calls ufshcd_rpm_get_sync(). The latter function can only succeed if UFSHCD_EH_IN_PROGRESS is not set because resuming involves submitting a SCSI command and ufshcd_queuecommand() returns SCSI_MLQUEUE_HOST_BUSY if UFSHCD_EH_IN_PROGRESS is set. Fix this hang by setting UFSHCD_EH_IN_PROGRESS after ufshcd_rpm_get_sync() has been called instead of before. Backtrace: __switch_to+0x174/0x338 __schedule+0x600/0x9e4 schedule+0x7c/0xe8 schedule_timeout+0xa4/0x1c8 io_schedule_timeout+0x48/0x70 wait_for_common_io+0xa8/0x160 //waiting on START_STOP wait_for_completion_io_timeout+0x10/0x20 blk_execute_rq+0xe4/0x1e4 scsi_execute_cmd+0x108/0x244 ufshcd_set_dev_pwr_mode+0xe8/0x250 __ufshcd_wl_resume+0x94/0x354 ufshcd_wl_runtime_resume+0x3c/0x174 scsi_runtime_resume+0x64/0xa4 rpm_resume+0x15c/0xa1c __pm_runtime_resume+0x4c/0x90 // Runtime resume ongoing ufshcd_err_handler+0x1a0/0xd08 process_one_work+0x174/0x808 worker_thread+0x15c/0x490 kthread+0xf4/0x1ec ret_from_fork+0x10/0x20 [ bvanassche: rewrote patch description ] | ||||
| CVE-2025-38090 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2025-12-17 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drivers/rapidio/rio_cm.c: prevent possible heap overwrite In riocm_cdev_ioctl(RIO_CM_CHAN_SEND) -> cm_chan_msg_send() -> riocm_ch_send() cm_chan_msg_send() checks that userspace didn't send too much data but riocm_ch_send() failed to check that userspace sent sufficient data. The result is that riocm_ch_send() can write to fields in the rio_ch_chan_hdr which were outside the bounds of the space which cm_chan_msg_send() allocated. Address this by teaching riocm_ch_send() to check that the entire rio_ch_chan_hdr was copied in from userspace. | ||||
| CVE-2025-38043 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2025-12-17 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Set dma_mask for ffa devices Set dma_mask for FFA devices, otherwise DMA allocation using the device pointer lead to following warning: WARNING: CPU: 1 PID: 1 at kernel/dma/mapping.c:597 dma_alloc_attrs+0xe0/0x124 | ||||
| CVE-2025-64673 | 1 Microsoft | 16 Windows 10 1809, Windows 10 21h2, Windows 10 21h2 and 13 more | 2025-12-17 | 7.8 High |
| Improper access control in Storvsp.sys Driver allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2025-64670 | 1 Microsoft | 14 Windows 10 21h2, Windows 10 21h2, Windows 10 22h2 and 11 more | 2025-12-17 | 6.5 Medium |
| Exposure of sensitive information to an unauthorized actor in Microsoft Graphics Component allows an authorized attacker to disclose information over a network. | ||||
| CVE-2025-62571 | 1 Microsoft | 23 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 20 more | 2025-12-17 | 7.8 High |
| Improper input validation in Windows Installer allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2025-48639 | 1 Google | 1 Android | 2025-12-17 | 7.3 High |
| In DefaultTransitionHandler.java, there is a possible way to unknowingly grant permissions to an app due to a tapjacking/overlay attack. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is needed for exploitation. | ||||
| CVE-2025-48633 | 1 Google | 1 Android | 2025-12-17 | 5.5 Medium |
| In hasAccountsOnAnyUser of DevicePolicyManagerService.java, there is a possible way to add a Device Owner after provisioning due to a logic error in the code. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. | ||||
| CVE-2025-48632 | 1 Google | 1 Android | 2025-12-17 | 7.8 High |
| In setDisplayName of AssociationRequest.java, there is a possible way to cause CDM associations to persist after the user has disassociated them due to improper input validation. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. | ||||