Page 25 of 7645 results (0.011 seconds)

CVSS: 6.6EPSS: 0%CPEs: 4EXPL: 0

07 Oct 2025 — In the Linux kernel, the following vulnerability has been resolved: netfilter: conntrack: fix wrong ct->timeout value (struct nf_conn)->timeout is an interval before the conntrack confirmed. After confirmed, it becomes a timestamp. It is observed that timeout of an unconfirmed conntrack: - Set by calling ctnetlink_change_timeout(). As a result, `nfct_time_stamp` was wrongly added to `ct->timeout` twice. - Get by calling ctnetlink_dump_timeout(). As a result, `nfct_time_stamp` was wrongly subtracted. • https://git.kernel.org/stable/c/a4b4766c3cebb4018167e06b863d8e95b7274757 • CWE-682: Incorrect Calculation •

CVSS: 7.1EPSS: 0%CPEs: 5EXPL: 0

07 Oct 2025 — In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-sysman: Fix reference leak If a duplicate attribute is found using kset_find_obj(), a reference to that attribute is returned. This means that we need to dispose it accordingly. Use kobject_put() to dispose the duplicate attribute in such a case. Compile-tested only. In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-sysman: Fix reference leak If a duplicate attribute is found using kse... • https://git.kernel.org/stable/c/e8a60aa7404bfef37705da5607c97737073ac38d •

CVSS: 7.1EPSS: 0%CPEs: 3EXPL: 0

07 Oct 2025 — In the Linux kernel, the following vulnerability has been resolved: fs: dlm: fix use after free in midcomms commit While working on processing dlm message in softirq context I experienced the following KASAN use-after-free warning: [ 151.760477] ================================================================== [ 151.761803] BUG: KASAN: use-after-free in dlm_midcomms_commit_mhandle+0x19d/0x4b0 [ 151.763414] Read of size 4 at addr ffff88811a980c60 by task lock_torture/1347 [ 151.765284] CPU: 7 PID: 1347 Comm... • https://git.kernel.org/stable/c/489d8e559c6596eb08e16447d9830bc39afbe54e •

CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 0

07 Oct 2025 — In the Linux kernel, the following vulnerability has been resolved: scsi: hisi_sas: Grab sas_dev lock when traversing the members of sas_dev.list When freeing slots in function slot_complete_v3_hw(), it is possible that sas_dev.list is being traversed elsewhere, and it may trigger a NULL pointer exception, such as follows: ==>cq thread ==>scsi_eh_6 ==>scsi_error_handler() ==>sas_eh_handle_sas_errors() ==>sas_scsi_find_task() ==>lldd_abort_task() ==>slot_complete_v3_hw() ==>hisi_sas_abort_task() ==>hisi_sas_... • https://git.kernel.org/stable/c/6e2a40b3a332ea84079983be21c944de8ddbc4f3 •

CVSS: 7.8EPSS: 0%CPEs: 5EXPL: 0

07 Oct 2025 — In the Linux kernel, the following vulnerability has been resolved: ext4: fix possible double unlock when moving a directory The SUSE Linux Enterprise 15 SP5 RT kernel was updated to fix various security issues. • https://git.kernel.org/stable/c/8dac5a63cf79707b547ea3d425fead5f4482198f • CWE-459: Incomplete Cleanup •

CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0

07 Oct 2025 — In the Linux kernel, the following vulnerability has been resolved: drm/i915/gvt: fix vgpu debugfs clean in remove Check carefully on root debugfs available when destroying vgpu, e.g in remove case drm minor's debugfs root might already be destroyed, which led to kernel oops like below. Console: switching to colour dummy device 80x25 i915 0000:00:02.0: MDEV: Unregistering intel_vgpu_mdev b1338b2d-a709-4c23-b766-cc436c36cdf0: Removing from iommu group 14 BUG: kernel NULL pointer dereference, address: 0000000... • https://git.kernel.org/stable/c/bc7b0be316aebac42eb9e8e54c984609555944da • CWE-476: NULL Pointer Dereference •

CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0

07 Oct 2025 — In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_fq: fix integer overflow of "credit" if sch_fq is configured with "initial quantum" having values greater than INT_MAX, the first assignment of "credit" does signed integer overflow to a very negative value. In this situation, the syzkaller script provided by Cristoph triggers the CPU soft-lockup warning even with few sockets. It's not an infinite loop, but "credit" wasn't probably meant to be minus 2Gb for each new flow. Cap... • https://git.kernel.org/stable/c/afe4fd062416b158a8a8538b23adc1930a9b88dc •

CVSS: 5.7EPSS: 0%CPEs: 8EXPL: 0

07 Oct 2025 — In the Linux kernel, the following vulnerability has been resolved: mm/swap: fix swap_info_struct race between swapoff and get_swap_pages() The si->lock must be held when deleting the si from the available list. Otherwise, another thread can re-add the si to the available list, which can lead to memory corruption. The only place we have found where this happens is in the swapoff path. This case can be described as below: core 0 core 1 swapoff del_from_avail_list(si) waiting try lock si->lock acquire swap_av... • https://git.kernel.org/stable/c/a2468cc9bfdff6139f59ca896671e5819ff5f94a • CWE-413: Improper Resource Locking •

CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0

07 Oct 2025 — In the Linux kernel, the following vulnerability has been resolved: gfs2: Fix possible data races in gfs2_show_options() Some fields such as gt_logd_secs of the struct gfs2_tune are accessed without holding the lock gt_spin in gfs2_show_options(): val = sdp->sd_tune.gt_logd_secs; if (val != 30) seq_printf(s, ",commit=%d", val); And thus can cause data races when gfs2_show_options() and other functions such as gfs2_reconfigure() are concurrently executed: spin_lock(>->gt_spin); gt->gt_logd_secs = newargs->... • https://git.kernel.org/stable/c/7e5bbeb7eb813bb2568e1d5d02587df943272e57 •

CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0

07 Oct 2025 — In the Linux kernel, the following vulnerability has been resolved: md: fix soft lockup in status_resync status_resync() will calculate 'curr_resync - recovery_active' to show user a progress bar like following: [============>........] resync = 61.4% 'curr_resync' and 'recovery_active' is updated in md_do_sync(), and status_resync() can read them concurrently, hence it's possible that 'curr_resync - recovery_active' can overflow to a huge number. In this case status_resync() will be stuck in the loop to pri... • https://git.kernel.org/stable/c/b4acb6c3ede88d6b7d33742a09e63cfce5e7fb69 •