Page 3 of 5927 results (0.008 seconds)

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

10 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: net: atm: add lec_mutex syzbot found its way in net/atm/lec.c, and found an error path in lecd_attach() could leave a dangling pointer in dev_lec[]. Add a mutex to protect dev_lecp[] uses from lecd_attach(), lec_vcc_attach() and lec_mcast_attach(). Following patch will use this mutex for /proc/net/atm/lec. BUG: KASAN: slab-use-after-free in lecd_attach net/atm/lec.c:751 [inline] BUG: KASAN: slab-use-after-free in lane_ioctl+0x2224/0x23e0 ne... • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 •

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

10 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: smb: Log an error when close_all_cached_dirs fails Under low-memory conditions, close_all_cached_dirs() can't move the dentries to a separate list to dput() them once the locks are dropped. This will result in a "Dentry still in use" error, so add an error message that makes it clear this is what happened: [ 495.281119] CIFS: VFS: \\otters.example.com\share Out of memory while dropping dentries [ 495.281595] ------------[ cut here ]--------... • https://git.kernel.org/stable/c/b8ced2b9a23a1a2c1e0ed8d0d02512e51bdf38da •

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

10 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: arm64/ptrace: Fix stack-out-of-bounds read in regs_get_kernel_stack_nth() KASAN reports a stack-out-of-bounds read in regs_get_kernel_stack_nth(). Call Trace: [ 97.283505] BUG: KASAN: stack-out-of-bounds in regs_get_kernel_stack_nth+0xa8/0xc8 [ 97.284677] Read of size 8 at addr ffff800089277c10 by task 1.sh/2550 [ 97.285732] [ 97.286067] CPU: 7 PID: 2550 Comm: 1.sh Not tainted 6.6.0+ #11 [ 97.287032] Hardware name: linux,dummy-virt (DT) [ 9... • https://git.kernel.org/stable/c/0a8ea52c3eb157dd65e224fc95b7c9c99fcba9f7 •

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

10 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: drm/amd/pp: Fix potential NULL pointer dereference in atomctrl_initialize_mc_reg_table The function atomctrl_initialize_mc_reg_table() and atomctrl_initialize_mc_reg_table_v2_2() does not check the return value of smu_atom_get_data_table(). If smu_atom_get_data_table() fails to retrieve vram_info, it returns NULL which is later dereferenced. In the Linux kernel, the following vulnerability has been resolved: drm/amd/pp: Fix potential NULL p... • https://git.kernel.org/stable/c/b3892e2bb519fe18225d0628f0dd255761f16502 •

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

10 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: bus: fsl-mc: fix double-free on mc_dev The blamed commit tried to simplify how the deallocations are done but, in the process, introduced a double-free on the mc_dev variable. In case the MC device is a DPRC, a new mc_bus is allocated and the mc_dev variable is just a reference to one of its fields. In this circumstance, on the error path only the mc_bus should be freed. This commit introduces back the following checkpatch warning which is ... • https://git.kernel.org/stable/c/a042fbed02904493ae6df26ec836045f5a7d3ce2 •

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

10 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: fbdev: core: fbcvt: avoid division by 0 in fb_cvt_hperiod() In fb_find_mode_cvt(), iff mode->refresh somehow happens to be 0x80000000, cvt.f_refresh will become 0 when multiplying it by 2 due to overflow. It's then passed to fb_cvt_hperiod(), where it's used as a divider -- division by 0 will result in kernel oops. Add a sanity check for cvt.f_refresh to avoid such overflow... Found by Linux Verification Center (linuxtesting.org) with the S... • https://git.kernel.org/stable/c/96fe6a2109db29cd15b90a093c16e6cb4b19371a •

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

10 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: iavf: get rid of the crit lock Get rid of the crit lock. That frees us from the error prone logic of try_locks. Thanks to netdev_lock() by Jakub it is now easy, and in most cases we were protected by it already - replace crit lock by netdev lock when it was not the case. Lockdep reports that we should cancel the work under crit_lock [splat1], and that was the scheme we have mostly followed since [1] by Slawomir. But when that is done we sti... • https://git.kernel.org/stable/c/d1639a17319ba78a018280cd2df6577a7e5d9fab •

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

10 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: seg6: Fix validation of nexthop addresses The kernel currently validates that the length of the provided nexthop address does not exceed the specified length. This can lead to the kernel reading uninitialized memory if user space provided a shorter length than the specified one. Fix by validating that the provided length exactly matches the specified one. In the Linux kernel, the following vulnerability has been resolved: seg6: Fix validati... • https://git.kernel.org/stable/c/d1df6fd8a1d22d37cffa0075ab8ad423ce656777 •

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

10 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: ptp: remove ptp->n_vclocks check logic in ptp_vclock_in_use() There is no disagreement that we should check both ptp->is_virtual_clock and ptp->n_vclocks to check if the ptp virtual clock is in use. However, when we acquire ptp->n_vclocks_mux to read ptp->n_vclocks in ptp_vclock_in_use(), we observe a recursive lock in the call trace starting from n_vclocks_store(). ============================================ WARNING: possible recursive lo... • https://git.kernel.org/stable/c/73f37068d540eba5f93ba3a0019bf479d35ebd76 •

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

10 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix NULL pointer deference on eir_get_service_data The len parameter is considered optional so it can be NULL so it cannot be used for skipping to next entry of EIR_SERVICE_DATA. In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix NULL pointer deference on eir_get_service_data The len parameter is considered optional so it can be NULL so it cannot be used for skipping to next entry of EIR_SERVICE_DA... • https://git.kernel.org/stable/c/8f9ae5b3ae80f168a6224529e3787f4fb27f299a •