CVE-2025-40191 - drm/amdkfd: Fix kfd process ref leaking when userptr unmapping
CVE ID : CVE-2025-40191
Published : Nov. 12, 2025, 10:15 p.m. | 42 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix kfd process ref leaking when userptr unmapping kfd_lookup_process_by_pid hold the kfd process reference to ensure it doesn't get destroyed while sending the segfault event to user space. Calling kfd_lookup_process_by_pid as function parameter leaks the kfd process refcount and miss the NULL pointer check if app process is already destroyed.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID : CVE-2025-40191
Published : Nov. 12, 2025, 10:15 p.m. | 42 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix kfd process ref leaking when userptr unmapping kfd_lookup_process_by_pid hold the kfd process reference to ensure it doesn't get destroyed while sending the segfault event to user space. Calling kfd_lookup_process_by_pid as function parameter leaks the kfd process refcount and miss the NULL pointer check if app process is already destroyed.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2025-40192 - Revert "ipmi: fix msg stack when IPMI is disconnected"
CVE ID : CVE-2025-40192
Published : Nov. 12, 2025, 10:15 p.m. | 42 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: Revert "ipmi: fix msg stack when IPMI is disconnected" This reverts commit c608966f3f9c2dca596967501d00753282b395fc. This patch has a subtle bug that can cause the IPMI driver to go into an infinite loop if the BMC misbehaves in a certain way. Apparently certain BMCs do misbehave this way because several reports have come in recently about this.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID : CVE-2025-40192
Published : Nov. 12, 2025, 10:15 p.m. | 42 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: Revert "ipmi: fix msg stack when IPMI is disconnected" This reverts commit c608966f3f9c2dca596967501d00753282b395fc. This patch has a subtle bug that can cause the IPMI driver to go into an infinite loop if the BMC misbehaves in a certain way. Apparently certain BMCs do misbehave this way because several reports have come in recently about this.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2025-40193 - xtensa: simdisk: add input size check in proc_write_simdisk
CVE ID : CVE-2025-40193
Published : Nov. 12, 2025, 10:15 p.m. | 42 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: xtensa: simdisk: add input size check in proc_write_simdisk A malicious user could pass an arbitrarily bad value to memdup_user_nul(), potentially causing kernel crash. This follows the same pattern as commit ee76746387f6 ("netdevsim: prevent bad user input in nsim_dev_health_break_write()")
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID : CVE-2025-40193
Published : Nov. 12, 2025, 10:15 p.m. | 42 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: xtensa: simdisk: add input size check in proc_write_simdisk A malicious user could pass an arbitrarily bad value to memdup_user_nul(), potentially causing kernel crash. This follows the same pattern as commit ee76746387f6 ("netdevsim: prevent bad user input in nsim_dev_health_break_write()")
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2025-40194 - cpufreq: intel_pstate: Fix object lifecycle issue in update_qos_request()
CVE ID : CVE-2025-40194
Published : Nov. 12, 2025, 10:15 p.m. | 42 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: cpufreq: intel_pstate: Fix object lifecycle issue in update_qos_request() The cpufreq_cpu_put() call in update_qos_request() takes place too early because the latter subsequently calls freq_qos_update_request() that indirectly accesses the policy object in question through the QoS request object passed to it. Fortunately, update_qos_request() is called under intel_pstate_driver_lock, so this issue does not matter for changing the intel_pstate operation mode, but it theoretically can cause a crash to occur on CPU device hot removal (which currently can only happen in virt, but it is formally supported nevertheless). Address this issue by modifying update_qos_request() to drop the reference to the policy later.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID : CVE-2025-40194
Published : Nov. 12, 2025, 10:15 p.m. | 42 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: cpufreq: intel_pstate: Fix object lifecycle issue in update_qos_request() The cpufreq_cpu_put() call in update_qos_request() takes place too early because the latter subsequently calls freq_qos_update_request() that indirectly accesses the policy object in question through the QoS request object passed to it. Fortunately, update_qos_request() is called under intel_pstate_driver_lock, so this issue does not matter for changing the intel_pstate operation mode, but it theoretically can cause a crash to occur on CPU device hot removal (which currently can only happen in virt, but it is formally supported nevertheless). Address this issue by modifying update_qos_request() to drop the reference to the policy later.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2025-40195 - mount: handle NULL values in mnt_ns_release()
CVE ID : CVE-2025-40195
Published : Nov. 12, 2025, 10:15 p.m. | 42 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: mount: handle NULL values in mnt_ns_release() When calling in listmount() mnt_ns_release() may be passed a NULL pointer. Handle that case gracefully.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID : CVE-2025-40195
Published : Nov. 12, 2025, 10:15 p.m. | 42 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: mount: handle NULL values in mnt_ns_release() When calling in listmount() mnt_ns_release() may be passed a NULL pointer. Handle that case gracefully.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2025-40196 - fs: quota: create dedicated workqueue for quota_release_work
CVE ID : CVE-2025-40196
Published : Nov. 12, 2025, 10:15 p.m. | 42 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: fs: quota: create dedicated workqueue for quota_release_work There is a kernel panic due to WARN_ONCE when panic_on_warn is set. This issue occurs when writeback is triggered due to sync call for an opened file(ie, writeback reason is WB_REASON_SYNC). When f2fs balance is needed at sync path, flush for quota_release_work is triggered. By default quota_release_work is queued to "events_unbound" queue which does not have WQ_MEM_RECLAIM flag. During f2fs balance "writeback" workqueue tries to flush quota_release_work causing kernel panic due to MEM_RECLAIM flag mismatch errors. This patch creates dedicated workqueue with WQ_MEM_RECLAIM flag for work quota_release_work. ------------[ cut here ]------------ WARNING: CPU: 4 PID: 14867 at kernel/workqueue.c:3721 check_flush_dependency+0x13c/0x148 Call trace: check_flush_dependency+0x13c/0x148 __flush_work+0xd0/0x398 flush_delayed_work+0x44/0x5c dquot_writeback_dquots+0x54/0x318 f2fs_do_quota_sync+0xb8/0x1a8 f2fs_write_checkpoint+0x3cc/0x99c f2fs_gc+0x190/0x750 f2fs_balance_fs+0x110/0x168 f2fs_write_single_data_page+0x474/0x7dc f2fs_write_data_pages+0x7d0/0xd0c do_writepages+0xe0/0x2f4 __writeback_single_inode+0x44/0x4ac writeback_sb_inodes+0x30c/0x538 wb_writeback+0xf4/0x440 wb_workfn+0x128/0x5d4 process_scheduled_works+0x1c4/0x45c worker_thread+0x32c/0x3e8 kthread+0x11c/0x1b0 ret_from_fork+0x10/0x20 Kernel panic - not syncing: kernel: panic_on_warn set ...
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID : CVE-2025-40196
Published : Nov. 12, 2025, 10:15 p.m. | 42 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: fs: quota: create dedicated workqueue for quota_release_work There is a kernel panic due to WARN_ONCE when panic_on_warn is set. This issue occurs when writeback is triggered due to sync call for an opened file(ie, writeback reason is WB_REASON_SYNC). When f2fs balance is needed at sync path, flush for quota_release_work is triggered. By default quota_release_work is queued to "events_unbound" queue which does not have WQ_MEM_RECLAIM flag. During f2fs balance "writeback" workqueue tries to flush quota_release_work causing kernel panic due to MEM_RECLAIM flag mismatch errors. This patch creates dedicated workqueue with WQ_MEM_RECLAIM flag for work quota_release_work. ------------[ cut here ]------------ WARNING: CPU: 4 PID: 14867 at kernel/workqueue.c:3721 check_flush_dependency+0x13c/0x148 Call trace: check_flush_dependency+0x13c/0x148 __flush_work+0xd0/0x398 flush_delayed_work+0x44/0x5c dquot_writeback_dquots+0x54/0x318 f2fs_do_quota_sync+0xb8/0x1a8 f2fs_write_checkpoint+0x3cc/0x99c f2fs_gc+0x190/0x750 f2fs_balance_fs+0x110/0x168 f2fs_write_single_data_page+0x474/0x7dc f2fs_write_data_pages+0x7d0/0xd0c do_writepages+0xe0/0x2f4 __writeback_single_inode+0x44/0x4ac writeback_sb_inodes+0x30c/0x538 wb_writeback+0xf4/0x440 wb_workfn+0x128/0x5d4 process_scheduled_works+0x1c4/0x45c worker_thread+0x32c/0x3e8 kthread+0x11c/0x1b0 ret_from_fork+0x10/0x20 Kernel panic - not syncing: kernel: panic_on_warn set ...
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2025-40197 - media: mc: Clear minor number before put device
CVE ID : CVE-2025-40197
Published : Nov. 12, 2025, 10:15 p.m. | 42 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: media: mc: Clear minor number before put device The device minor should not be cleared after the device is released.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID : CVE-2025-40197
Published : Nov. 12, 2025, 10:15 p.m. | 42 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: media: mc: Clear minor number before put device The device minor should not be cleared after the device is released.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2025-40198 - ext4: avoid potential buffer over-read in parse_apply_sb_mount_options()
CVE ID : CVE-2025-40198
Published : Nov. 12, 2025, 10:15 p.m. | 42 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: ext4: avoid potential buffer over-read in parse_apply_sb_mount_options() Unlike other strings in the ext4 superblock, we rely on tune2fs to make sure s_mount_opts is NUL terminated. Harden parse_apply_sb_mount_options() by treating s_mount_opts as a potential __nonstring.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID : CVE-2025-40198
Published : Nov. 12, 2025, 10:15 p.m. | 42 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: ext4: avoid potential buffer over-read in parse_apply_sb_mount_options() Unlike other strings in the ext4 superblock, we rely on tune2fs to make sure s_mount_opts is NUL terminated. Harden parse_apply_sb_mount_options() by treating s_mount_opts as a potential __nonstring.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2025-40199 - page_pool: Fix PP_MAGIC_MASK to avoid crashing on some 32-bit arches
CVE ID : CVE-2025-40199
Published : Nov. 12, 2025, 10:15 p.m. | 42 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: page_pool: Fix PP_MAGIC_MASK to avoid crashing on some 32-bit arches Helge reported that the introduction of PP_MAGIC_MASK let to crashes on boot on his 32-bit parisc machine. The cause of this is the mask is set too wide, so the page_pool_page_is_pp() incurs false positives which crashes the machine. Just disabling the check in page_pool_is_pp() will lead to the page_pool code itself malfunctioning; so instead of doing this, this patch changes the define for PP_DMA_INDEX_BITS to avoid mistaking arbitrary kernel pointers for page_pool-tagged pages. The fix relies on the kernel pointers that alias with the pp_magic field always being above PAGE_OFFSET. With this assumption, we can use the lowest bit of the value of PAGE_OFFSET as the upper bound of the PP_DMA_INDEX_MASK, which should avoid the false positives. Because we cannot rely on PAGE_OFFSET always being a compile-time constant, nor on it always being >0, we fall back to disabling the dma_index storage when there are not enough bits available. This leaves us in the situation we were in before the patch in the Fixes tag, but only on a subset of architecture configurations. This seems to be the best we can do until the transition to page types in complete for page_pool pages. v2: - Make sure there's at least 8 bits available and that the PAGE_OFFSET bit calculation doesn't wrap
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID : CVE-2025-40199
Published : Nov. 12, 2025, 10:15 p.m. | 42 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: page_pool: Fix PP_MAGIC_MASK to avoid crashing on some 32-bit arches Helge reported that the introduction of PP_MAGIC_MASK let to crashes on boot on his 32-bit parisc machine. The cause of this is the mask is set too wide, so the page_pool_page_is_pp() incurs false positives which crashes the machine. Just disabling the check in page_pool_is_pp() will lead to the page_pool code itself malfunctioning; so instead of doing this, this patch changes the define for PP_DMA_INDEX_BITS to avoid mistaking arbitrary kernel pointers for page_pool-tagged pages. The fix relies on the kernel pointers that alias with the pp_magic field always being above PAGE_OFFSET. With this assumption, we can use the lowest bit of the value of PAGE_OFFSET as the upper bound of the PP_DMA_INDEX_MASK, which should avoid the false positives. Because we cannot rely on PAGE_OFFSET always being a compile-time constant, nor on it always being >0, we fall back to disabling the dma_index storage when there are not enough bits available. This leaves us in the situation we were in before the patch in the Fixes tag, but only on a subset of architecture configurations. This seems to be the best we can do until the transition to page types in complete for page_pool pages. v2: - Make sure there's at least 8 bits available and that the PAGE_OFFSET bit calculation doesn't wrap
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2025-40200 - Squashfs: reject negative file sizes in squashfs_read_inode()
CVE ID : CVE-2025-40200
Published : Nov. 12, 2025, 10:15 p.m. | 42 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: Squashfs: reject negative file sizes in squashfs_read_inode() Syskaller reports a "WARNING in ovl_copy_up_file" in overlayfs. This warning is ultimately caused because the underlying Squashfs file system returns a file with a negative file size. This commit checks for a negative file size and returns EINVAL. [phillip@squashfs.org.uk: only need to check 64 bit quantity]
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID : CVE-2025-40200
Published : Nov. 12, 2025, 10:15 p.m. | 42 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: Squashfs: reject negative file sizes in squashfs_read_inode() Syskaller reports a "WARNING in ovl_copy_up_file" in overlayfs. This warning is ultimately caused because the underlying Squashfs file system returns a file with a negative file size. This commit checks for a negative file size and returns EINVAL. [phillip@squashfs.org.uk: only need to check 64 bit quantity]
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2025-40201 - kernel/sys.c: fix the racy usage of task_lock(tsk->group_leader) in sys_prlimit64() paths
CVE ID : CVE-2025-40201
Published : Nov. 12, 2025, 10:15 p.m. | 42 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: kernel/sys.c: fix the racy usage of task_lock(tsk->group_leader) in sys_prlimit64() paths The usage of task_lock(tsk->group_leader) in sys_prlimit64()->do_prlimit() path is very broken. sys_prlimit64() does get_task_struct(tsk) but this only protects task_struct itself. If tsk != current and tsk is not a leader, this process can exit/exec and task_lock(tsk->group_leader) may use the already freed task_struct. Another problem is that sys_prlimit64() can race with mt-exec which changes ->group_leader. In this case do_prlimit() may take the wrong lock, or (worse) ->group_leader may change between task_lock() and task_unlock(). Change sys_prlimit64() to take tasklist_lock when necessary. This is not nice, but I don't see a better fix for -stable.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID : CVE-2025-40201
Published : Nov. 12, 2025, 10:15 p.m. | 42 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: kernel/sys.c: fix the racy usage of task_lock(tsk->group_leader) in sys_prlimit64() paths The usage of task_lock(tsk->group_leader) in sys_prlimit64()->do_prlimit() path is very broken. sys_prlimit64() does get_task_struct(tsk) but this only protects task_struct itself. If tsk != current and tsk is not a leader, this process can exit/exec and task_lock(tsk->group_leader) may use the already freed task_struct. Another problem is that sys_prlimit64() can race with mt-exec which changes ->group_leader. In this case do_prlimit() may take the wrong lock, or (worse) ->group_leader may change between task_lock() and task_unlock(). Change sys_prlimit64() to take tasklist_lock when necessary. This is not nice, but I don't see a better fix for -stable.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2025-40202 - ipmi: Rework user message limit handling
CVE ID : CVE-2025-40202
Published : Nov. 12, 2025, 10:15 p.m. | 42 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: ipmi: Rework user message limit handling The limit on the number of user messages had a number of issues, improper counting in some cases and a use after free. Restructure how this is all done to handle more in the receive message allocation routine, so all refcouting and user message limit counts are done in that routine. It's a lot cleaner and safer.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID : CVE-2025-40202
Published : Nov. 12, 2025, 10:15 p.m. | 42 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: ipmi: Rework user message limit handling The limit on the number of user messages had a number of issues, improper counting in some cases and a use after free. Restructure how this is all done to handle more in the receive message allocation routine, so all refcouting and user message limit counts are done in that routine. It's a lot cleaner and safer.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2025-40203 - listmount: don't call path_put() under namespace semaphore
CVE ID : CVE-2025-40203
Published : Nov. 12, 2025, 10:15 p.m. | 42 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: listmount: don't call path_put() under namespace semaphore Massage listmount() and make sure we don't call path_put() under the namespace semaphore. If we put the last reference we're fscked.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID : CVE-2025-40203
Published : Nov. 12, 2025, 10:15 p.m. | 42 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: listmount: don't call path_put() under namespace semaphore Massage listmount() and make sure we don't call path_put() under the namespace semaphore. If we put the last reference we're fscked.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2025-40204 - sctp: Fix MAC comparison to be constant-time
CVE ID : CVE-2025-40204
Published : Nov. 12, 2025, 10:15 p.m. | 42 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: sctp: Fix MAC comparison to be constant-time To prevent timing attacks, MACs need to be compared in constant time. Use the appropriate helper function for this.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID : CVE-2025-40204
Published : Nov. 12, 2025, 10:15 p.m. | 42 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: sctp: Fix MAC comparison to be constant-time To prevent timing attacks, MACs need to be compared in constant time. Use the appropriate helper function for this.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2025-40205 - btrfs: avoid potential out-of-bounds in btrfs_encode_fh()
CVE ID : CVE-2025-40205
Published : Nov. 12, 2025, 10:15 p.m. | 42 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: btrfs: avoid potential out-of-bounds in btrfs_encode_fh() The function btrfs_encode_fh() does not properly account for the three cases it handles. Before writing to the file handle (fh), the function only returns to the user BTRFS_FID_SIZE_NON_CONNECTABLE (5 dwords, 20 bytes) or BTRFS_FID_SIZE_CONNECTABLE (8 dwords, 32 bytes). However, when a parent exists and the root ID of the parent and the inode are different, the function writes BTRFS_FID_SIZE_CONNECTABLE_ROOT (10 dwords, 40 bytes). If *max_len is not large enough, this write goes out of bounds because BTRFS_FID_SIZE_CONNECTABLE_ROOT is greater than BTRFS_FID_SIZE_CONNECTABLE originally returned. This results in an 8-byte out-of-bounds write at fid->parent_root_objectid = parent_root_id. A previous attempt to fix this issue was made but was lost. https://lore.kernel.org/all/4CADAEEC020000780001B32C@vpn.id2.novell.com/ Although this issue does not seem to be easily triggerable, it is a potential memory corruption bug that should be fixed. This patch resolves the issue by ensuring the function returns the appropriate size for all three cases and validates that *max_len is large enough before writing any data.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID : CVE-2025-40205
Published : Nov. 12, 2025, 10:15 p.m. | 42 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: btrfs: avoid potential out-of-bounds in btrfs_encode_fh() The function btrfs_encode_fh() does not properly account for the three cases it handles. Before writing to the file handle (fh), the function only returns to the user BTRFS_FID_SIZE_NON_CONNECTABLE (5 dwords, 20 bytes) or BTRFS_FID_SIZE_CONNECTABLE (8 dwords, 32 bytes). However, when a parent exists and the root ID of the parent and the inode are different, the function writes BTRFS_FID_SIZE_CONNECTABLE_ROOT (10 dwords, 40 bytes). If *max_len is not large enough, this write goes out of bounds because BTRFS_FID_SIZE_CONNECTABLE_ROOT is greater than BTRFS_FID_SIZE_CONNECTABLE originally returned. This results in an 8-byte out-of-bounds write at fid->parent_root_objectid = parent_root_id. A previous attempt to fix this issue was made but was lost. https://lore.kernel.org/all/4CADAEEC020000780001B32C@vpn.id2.novell.com/ Although this issue does not seem to be easily triggerable, it is a potential memory corruption bug that should be fixed. This patch resolves the issue by ensuring the function returns the appropriate size for all three cases and validates that *max_len is large enough before writing any data.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2025-40206 - netfilter: nft_objref: validate objref and objrefmap expressions
CVE ID : CVE-2025-40206
Published : Nov. 12, 2025, 10:15 p.m. | 42 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_objref: validate objref and objrefmap expressions Referencing a synproxy stateful object from OUTPUT hook causes kernel crash due to infinite recursive calls: BUG: TASK stack guard page was hit at 000000008bda5b8c (stack is 000000003ab1c4a5..00000000494d8b12) [...] Call Trace: __find_rr_leaf+0x99/0x230 fib6_table_lookup+0x13b/0x2d0 ip6_pol_route+0xa4/0x400 fib6_rule_lookup+0x156/0x240 ip6_route_output_flags+0xc6/0x150 __nf_ip6_route+0x23/0x50 synproxy_send_tcp_ipv6+0x106/0x200 synproxy_send_client_synack_ipv6+0x1aa/0x1f0 nft_synproxy_do_eval+0x263/0x310 nft_do_chain+0x5a8/0x5f0 [nf_tables nft_do_chain_inet+0x98/0x110 nf_hook_slow+0x43/0xc0 __ip6_local_out+0xf0/0x170 ip6_local_out+0x17/0x70 synproxy_send_tcp_ipv6+0x1a2/0x200 synproxy_send_client_synack_ipv6+0x1aa/0x1f0 [...] Implement objref and objrefmap expression validate functions. Currently, only NFT_OBJECT_SYNPROXY object type requires validation. This will also handle a jump to a chain using a synproxy object from the OUTPUT hook. Now when trying to reference a synproxy object in the OUTPUT hook, nft will produce the following error: synproxy_crash.nft: Error: Could not process rule: Operation not supported synproxy name mysynproxy ^^^^^^^^^^^^^^^^^^^^^^^^
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID : CVE-2025-40206
Published : Nov. 12, 2025, 10:15 p.m. | 42 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_objref: validate objref and objrefmap expressions Referencing a synproxy stateful object from OUTPUT hook causes kernel crash due to infinite recursive calls: BUG: TASK stack guard page was hit at 000000008bda5b8c (stack is 000000003ab1c4a5..00000000494d8b12) [...] Call Trace: __find_rr_leaf+0x99/0x230 fib6_table_lookup+0x13b/0x2d0 ip6_pol_route+0xa4/0x400 fib6_rule_lookup+0x156/0x240 ip6_route_output_flags+0xc6/0x150 __nf_ip6_route+0x23/0x50 synproxy_send_tcp_ipv6+0x106/0x200 synproxy_send_client_synack_ipv6+0x1aa/0x1f0 nft_synproxy_do_eval+0x263/0x310 nft_do_chain+0x5a8/0x5f0 [nf_tables nft_do_chain_inet+0x98/0x110 nf_hook_slow+0x43/0xc0 __ip6_local_out+0xf0/0x170 ip6_local_out+0x17/0x70 synproxy_send_tcp_ipv6+0x1a2/0x200 synproxy_send_client_synack_ipv6+0x1aa/0x1f0 [...] Implement objref and objrefmap expression validate functions. Currently, only NFT_OBJECT_SYNPROXY object type requires validation. This will also handle a jump to a chain using a synproxy object from the OUTPUT hook. Now when trying to reference a synproxy object in the OUTPUT hook, nft will produce the following error: synproxy_crash.nft: Error: Could not process rule: Operation not supported synproxy name mysynproxy ^^^^^^^^^^^^^^^^^^^^^^^^
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2025-40207 - media: v4l2-subdev: Fix alloc failure check in v4l2_subdev_call_state_try()
CVE ID : CVE-2025-40207
Published : Nov. 12, 2025, 10:15 p.m. | 42 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: media: v4l2-subdev: Fix alloc failure check in v4l2_subdev_call_state_try() v4l2_subdev_call_state_try() macro allocates a subdev state with __v4l2_subdev_state_alloc(), but does not check the returned value. If __v4l2_subdev_state_alloc fails, it returns an ERR_PTR, and that would cause v4l2_subdev_call_state_try() to crash. Add proper error handling to v4l2_subdev_call_state_try().
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID : CVE-2025-40207
Published : Nov. 12, 2025, 10:15 p.m. | 42 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: media: v4l2-subdev: Fix alloc failure check in v4l2_subdev_call_state_try() v4l2_subdev_call_state_try() macro allocates a subdev state with __v4l2_subdev_state_alloc(), but does not check the returned value. If __v4l2_subdev_state_alloc fails, it returns an ERR_PTR, and that would cause v4l2_subdev_call_state_try() to crash. Add proper error handling to v4l2_subdev_call_state_try().
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2025-40208 - media: iris: fix module removal if firmware download failed
CVE ID : CVE-2025-40208
Published : Nov. 12, 2025, 10:15 p.m. | 42 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: media: iris: fix module removal if firmware download failed Fix remove if firmware failed to load: qcom-iris aa00000.video-codec: Direct firmware load for qcom/vpu/vpu33_p4.mbn failed with error -2 qcom-iris aa00000.video-codec: firmware download failed qcom-iris aa00000.video-codec: core init failed then: $ echo aa00000.video-codec > /sys/bus/platform/drivers/qcom-iris/unbind Triggers: genpd genpd:1:aa00000.video-codec: Runtime PM usage count underflow! ------------[ cut here ]------------ video_cc_mvs0_clk already disabled WARNING: drivers/clk/clk.c:1206 at clk_core_disable+0xa4/0xac, CPU#1: sh/542 pc : clk_core_disable+0xa4/0xac lr : clk_core_disable+0xa4/0xac Call trace: clk_core_disable+0xa4/0xac (P) clk_disable+0x30/0x4c iris_disable_unprepare_clock+0x20/0x48 [qcom_iris] iris_vpu_power_off_hw+0x48/0x58 [qcom_iris] iris_vpu33_power_off_hardware+0x44/0x230 [qcom_iris] iris_vpu_power_off+0x34/0x84 [qcom_iris] iris_core_deinit+0x44/0xc8 [qcom_iris] iris_remove+0x20/0x48 [qcom_iris] platform_remove+0x20/0x30 device_remove+0x4c/0x80 ---[ end trace 0000000000000000 ]--- ------------[ cut here ]------------ video_cc_mvs0_clk already unprepared WARNING: drivers/clk/clk.c:1065 at clk_core_unprepare+0xf0/0x110, CPU#2: sh/542 pc : clk_core_unprepare+0xf0/0x110 lr : clk_core_unprepare+0xf0/0x110 Call trace: clk_core_unprepare+0xf0/0x110 (P) clk_unprepare+0x2c/0x44 iris_disable_unprepare_clock+0x28/0x48 [qcom_iris] iris_vpu_power_off_hw+0x48/0x58 [qcom_iris] iris_vpu33_power_off_hardware+0x44/0x230 [qcom_iris] iris_vpu_power_off+0x34/0x84 [qcom_iris] iris_core_deinit+0x44/0xc8 [qcom_iris] iris_remove+0x20/0x48 [qcom_iris] platform_remove+0x20/0x30 device_remove+0x4c/0x80 ---[ end trace 0000000000000000 ]--- genpd genpd:0:aa00000.video-codec: Runtime PM usage count underflow! ------------[ cut here ]------------ gcc_video_axi0_clk already disabled WARNING: drivers/clk/clk.c:1206 at clk_core_disable+0xa4/0xac, CPU#4: sh/542 pc : clk_core_disable+0xa4/0xac lr : clk_core_disable+0xa4/0xac Call trace: clk_core_disable+0xa4/0xac (P) clk_disable+0x30/0x4c iris_disable_unprepare_clock+0x20/0x48 [qcom_iris] iris_vpu33_power_off_controller+0x17c/0x428 [qcom_iris] iris_vpu_power_off+0x48/0x84 [qcom_iris] iris_core_deinit+0x44/0xc8 [qcom_iris] iris_remove+0x20/0x48 [qcom_iris] platform_remove+0x20/0x30 device_remove+0x4c/0x80 ------------[ cut here ]------------ gcc_video_axi0_clk already unprepared WARNING: drivers/clk/clk.c:1065 at clk_core_unprepare+0xf0/0x110, CPU#4: sh/542 pc : clk_core_unprepare+0xf0/0x110 lr : clk_core_unprepare+0xf0/0x110 Call trace: clk_core_unprepare+0xf0/0x110 (P) clk_unprepare+0x2c/0x44 iris_disable_unprepare_clock+0x28/0x48 [qcom_iris] iris_vpu33_power_off_controller+0x17c/0x428 [qcom_iris] iris_vpu_power_off+0x48/0x84 [qcom_iris] iris_core_deinit+0x44/0xc8 [qcom_iris] iris_remove+0x20/0x48 [qcom_iris] platform_remove+0x20/0x30 device_remove+0x4c/0x80 ---[ end trace 0000000000000000 ]--- Skip deinit if initialization never succeeded.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID : CVE-2025-40208
Published : Nov. 12, 2025, 10:15 p.m. | 42 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: media: iris: fix module removal if firmware download failed Fix remove if firmware failed to load: qcom-iris aa00000.video-codec: Direct firmware load for qcom/vpu/vpu33_p4.mbn failed with error -2 qcom-iris aa00000.video-codec: firmware download failed qcom-iris aa00000.video-codec: core init failed then: $ echo aa00000.video-codec > /sys/bus/platform/drivers/qcom-iris/unbind Triggers: genpd genpd:1:aa00000.video-codec: Runtime PM usage count underflow! ------------[ cut here ]------------ video_cc_mvs0_clk already disabled WARNING: drivers/clk/clk.c:1206 at clk_core_disable+0xa4/0xac, CPU#1: sh/542 pc : clk_core_disable+0xa4/0xac lr : clk_core_disable+0xa4/0xac Call trace: clk_core_disable+0xa4/0xac (P) clk_disable+0x30/0x4c iris_disable_unprepare_clock+0x20/0x48 [qcom_iris] iris_vpu_power_off_hw+0x48/0x58 [qcom_iris] iris_vpu33_power_off_hardware+0x44/0x230 [qcom_iris] iris_vpu_power_off+0x34/0x84 [qcom_iris] iris_core_deinit+0x44/0xc8 [qcom_iris] iris_remove+0x20/0x48 [qcom_iris] platform_remove+0x20/0x30 device_remove+0x4c/0x80 ---[ end trace 0000000000000000 ]--- ------------[ cut here ]------------ video_cc_mvs0_clk already unprepared WARNING: drivers/clk/clk.c:1065 at clk_core_unprepare+0xf0/0x110, CPU#2: sh/542 pc : clk_core_unprepare+0xf0/0x110 lr : clk_core_unprepare+0xf0/0x110 Call trace: clk_core_unprepare+0xf0/0x110 (P) clk_unprepare+0x2c/0x44 iris_disable_unprepare_clock+0x28/0x48 [qcom_iris] iris_vpu_power_off_hw+0x48/0x58 [qcom_iris] iris_vpu33_power_off_hardware+0x44/0x230 [qcom_iris] iris_vpu_power_off+0x34/0x84 [qcom_iris] iris_core_deinit+0x44/0xc8 [qcom_iris] iris_remove+0x20/0x48 [qcom_iris] platform_remove+0x20/0x30 device_remove+0x4c/0x80 ---[ end trace 0000000000000000 ]--- genpd genpd:0:aa00000.video-codec: Runtime PM usage count underflow! ------------[ cut here ]------------ gcc_video_axi0_clk already disabled WARNING: drivers/clk/clk.c:1206 at clk_core_disable+0xa4/0xac, CPU#4: sh/542 pc : clk_core_disable+0xa4/0xac lr : clk_core_disable+0xa4/0xac Call trace: clk_core_disable+0xa4/0xac (P) clk_disable+0x30/0x4c iris_disable_unprepare_clock+0x20/0x48 [qcom_iris] iris_vpu33_power_off_controller+0x17c/0x428 [qcom_iris] iris_vpu_power_off+0x48/0x84 [qcom_iris] iris_core_deinit+0x44/0xc8 [qcom_iris] iris_remove+0x20/0x48 [qcom_iris] platform_remove+0x20/0x30 device_remove+0x4c/0x80 ------------[ cut here ]------------ gcc_video_axi0_clk already unprepared WARNING: drivers/clk/clk.c:1065 at clk_core_unprepare+0xf0/0x110, CPU#4: sh/542 pc : clk_core_unprepare+0xf0/0x110 lr : clk_core_unprepare+0xf0/0x110 Call trace: clk_core_unprepare+0xf0/0x110 (P) clk_unprepare+0x2c/0x44 iris_disable_unprepare_clock+0x28/0x48 [qcom_iris] iris_vpu33_power_off_controller+0x17c/0x428 [qcom_iris] iris_vpu_power_off+0x48/0x84 [qcom_iris] iris_core_deinit+0x44/0xc8 [qcom_iris] iris_remove+0x20/0x48 [qcom_iris] platform_remove+0x20/0x30 device_remove+0x4c/0x80 ---[ end trace 0000000000000000 ]--- Skip deinit if initialization never succeeded.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2025-63645 - pH7Software pH7-Social-Dating-CMS Stored XSS
CVE ID : CVE-2025-63645
Published : Nov. 12, 2025, 10:15 p.m. | 42 minutes ago
Description : A stored cross-site scripting (XSS) vulnerability exists in pH7Software pH7-Social-Dating-CMS 17.9.1 in the application's message system. Unsanitized message content submitted by one user is persisted by the server and later rendered in another user's Inbox view without appropriate context-aware encoding. As a result, attacker-controlled content executes in the recipient's browser context when the Inbox message is viewed.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID : CVE-2025-63645
Published : Nov. 12, 2025, 10:15 p.m. | 42 minutes ago
Description : A stored cross-site scripting (XSS) vulnerability exists in pH7Software pH7-Social-Dating-CMS 17.9.1 in the application's message system. Unsanitized message content submitted by one user is persisted by the server and later rendered in another user's Inbox view without appropriate context-aware encoding. As a result, attacker-controlled content executes in the recipient's browser context when the Inbox message is viewed.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2025-64345 - Wasmtime provides unsound API access to a WebAssembly shared linear memory
CVE ID : CVE-2025-64345
Published : Nov. 12, 2025, 10:15 p.m. | 42 minutes ago
Description : Wasmtime is a runtime for WebAssembly. Prior to version 38.0.4, 37.0.3, 36.0.3, and 24.0.5, Wasmtime's Rust embedder API contains an unsound interaction where a WebAssembly shared linear memory could be viewed as a type which provides safe access to the host (Rust) to the contents of the linear memory. This is not sound for shared linear memories, which could be modified in parallel, and this could lead to a data race in the host. Patch releases have been issued for all supported versions of Wasmtime, notably: 24.0.5, 36.0.3, 37.0.3, and 38.0.4. These releases reject creation of shared memories via `Memory::new` and shared memories are now excluded from core dumps. As a workaround, eembeddings affected by this issue should use `SharedMemory::new` instead of `Memory::new` to create shared memories. Affected embeddings should also disable core dumps if they are unable to upgrade. Note that core dumps are disabled by default but the wasm threads proposal (and shared memory) is enabled by default.
Severity: 1.8 | LOW
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID : CVE-2025-64345
Published : Nov. 12, 2025, 10:15 p.m. | 42 minutes ago
Description : Wasmtime is a runtime for WebAssembly. Prior to version 38.0.4, 37.0.3, 36.0.3, and 24.0.5, Wasmtime's Rust embedder API contains an unsound interaction where a WebAssembly shared linear memory could be viewed as a type which provides safe access to the host (Rust) to the contents of the linear memory. This is not sound for shared linear memories, which could be modified in parallel, and this could lead to a data race in the host. Patch releases have been issued for all supported versions of Wasmtime, notably: 24.0.5, 36.0.3, 37.0.3, and 38.0.4. These releases reject creation of shared memories via `Memory::new` and shared memories are now excluded from core dumps. As a workaround, eembeddings affected by this issue should use `SharedMemory::new` instead of `Memory::new` to create shared memories. Affected embeddings should also disable core dumps if they are unable to upgrade. Note that core dumps are disabled by default but the wasm threads proposal (and shared memory) is enabled by default.
Severity: 1.8 | LOW
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2025-64429 - DuckDB Encryption Crypto implementation is vulnerable
CVE ID : CVE-2025-64429
Published : Nov. 12, 2025, 10:15 p.m. | 42 minutes ago
Description : DuckDB is a SQL database management system. DuckDB implemented block-based encryption of DB on the filesystem starting with DuckDB 1.4.0. There are a few issues related to this implementation. The DuckDB can fall back to an insecure random number generator (pcg32) to generate cryptographic keys or IVs. When clearing keys from memory, the compiler may remove the memset() and leave sensitive data on the heap. By modifying the database header, an attacker could downgrade the encryption mode from GCM to CTR to bypass integrity checks. There may be a failure to check return value on call to OpenSSL `rand_bytes()`. An attacker could use public IVs to compromise the internal state of RNG and determine the randomly generated key used to encrypt temporary files, get access to cryptographic keys if they have access to process memory (e.g. through memory leak),circumvent GCM integrity checks, and/or influence the OpenSSL random number generator and DuckDB would not be able to detect a failure of the generator. Version 1.4.2 has disabled the insecure random number generator by no longer using the fallback to write to or create databases. Instead, DuckDB will now attempt to install and load the OpenSSL implementation in the `httpfs` extension. DuckDB now uses secure MbedTLS primitive to clear memory as recommended and requires explicit specification of ciphers without integrity checks like CTR on `ATTACH`. Additionally, DuckDB now checks the return code.
Severity: 6.9 | MEDIUM
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID : CVE-2025-64429
Published : Nov. 12, 2025, 10:15 p.m. | 42 minutes ago
Description : DuckDB is a SQL database management system. DuckDB implemented block-based encryption of DB on the filesystem starting with DuckDB 1.4.0. There are a few issues related to this implementation. The DuckDB can fall back to an insecure random number generator (pcg32) to generate cryptographic keys or IVs. When clearing keys from memory, the compiler may remove the memset() and leave sensitive data on the heap. By modifying the database header, an attacker could downgrade the encryption mode from GCM to CTR to bypass integrity checks. There may be a failure to check return value on call to OpenSSL `rand_bytes()`. An attacker could use public IVs to compromise the internal state of RNG and determine the randomly generated key used to encrypt temporary files, get access to cryptographic keys if they have access to process memory (e.g. through memory leak),circumvent GCM integrity checks, and/or influence the OpenSSL random number generator and DuckDB would not be able to detect a failure of the generator. Version 1.4.2 has disabled the insecure random number generator by no longer using the fallback to write to or create databases. Instead, DuckDB will now attempt to install and load the OpenSSL implementation in the `httpfs` extension. DuckDB now uses secure MbedTLS primitive to clear memory as recommended and requires explicit specification of ciphers without integrity checks like CTR on `ATTACH`. Additionally, DuckDB now checks the return code.
Severity: 6.9 | MEDIUM
Visit the link for more details, such as CVSS details, affected products, timeline, and more...