Page 4 of 2800 results (0.010 seconds)

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

11 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: ipvs: fix UB due to uninitialized stack access in ip_vs_protocol_init() Under certain kernel configurations when building with Clang/LLVM, the compiler does not generate a return or jump as the terminator instruction for ip_vs_protocol_init(), triggering the following objtool warning during build time: vmlinux.o: warning: objtool: ip_vs_protocol_init() falls through to next function __initstub__kmod_ip_vs_rr__935_123_ip_vs_rr_init6() At run... • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 •

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

11 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: igb: Fix potential invalid memory access in igb_init_module() The pci_register_driver() can fail and when this happened, the dca_notifier needs to be unregistered, otherwise the dca_notifier can be called when igb fails to install, resulting to invalid memory access. In the Linux kernel, the following vulnerability has been resolved: igb: Fix potential invalid memory access in igb_init_module() The pci_register_driver() can fail and when th... • https://git.kernel.org/stable/c/bbd98fe48a43464b4a044bc4cbeefad284d6aa80 •

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

11 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: spi: mpc52xx: Add cancel_work_sync before module remove If we remove the module which will call mpc52xx_spi_remove it will free 'ms' through spi_unregister_controller. while the work ms->work will be used. The sequence of operations that may lead to a UAF bug. Fix it by ensuring that the work is canceled before proceeding with the cleanup in mpc52xx_spi_remove. In the Linux kernel, the following vulnerability has been resolved: spi: mpc52xx... • https://git.kernel.org/stable/c/ca632f556697d45d67ed5cada7cedf3ddfe0db4b •

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

11 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: btrfs: don't take dev_replace rwsem on task already holding it Running fstests btrfs/011 with MKFS_OPTIONS="-O rst" to force the usage of the RAID stripe-tree, we get the following splat from lockdep: BTRFS info (device sdd): dev_replace from /dev/sdd (devid 1) to /dev/sdb started ============================================ WARNING: possible recursive locking detected 6.11.0-rc3-btrfs-for-next #599 Not tainted -----------------------------... • https://git.kernel.org/stable/c/a5bc4e030f50fdbb1fbc69acc1e0c5f57c79d044 •

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

11 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: dlm: fix possible lkb_resource null dereference This patch fixes a possible null pointer dereference when this function is called from request_lock() as lkb->lkb_resource is not assigned yet, only after validate_lock_args() by calling attach_lkb(). Another issue is that a resource name could be a non printable bytearray and we cannot assume to be ASCII coded. The log functionality is probably never being hit when DLM is used in normal way a... • https://git.kernel.org/stable/c/6fbdc3980b70e9c1c86eccea7d5ee68108008fa7 •

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

11 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: bpf: Prevent tailcall infinite loop caused by freplace There is a potential infinite loop issue that can occur when using a combination of tail calls and freplace. In an upcoming selftest, the attach target for entry_freplace of tailcall_freplace.c is subprog_tc of tc_bpf2bpf.c, while the tail call in entry_freplace leads to entry_tc. This results in an infinite loop: entry_tc -> subprog_tc -> entry_freplace --tailcall-> entry_tc. The probl... • https://git.kernel.org/stable/c/987aa730bad3e1ef66d9f30182294daa78f6387d •

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

11 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: dma-debug: fix a possible deadlock on radix_lock radix_lock() shouldn't be held while holding dma_hash_entry[idx].lock otherwise, there's a possible deadlock scenario when dma debug API is called holding rq_lock(): CPU0 CPU1 CPU2 dma_free_attrs() check_unmap() add_dma_entry() __schedule() //out (A) rq_lock() get_hash_bucket() (A) dma_entry_hash check_sync() (A) radix_lock() (W) dma_entry_hash dma_entry_free() (W) radix_lock() // CPU2's one ... • https://git.kernel.org/stable/c/3ccce34a5c3f5c9541108a451657ade621524b32 •

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

11 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: pinmux: Use sequential access to access desc->pinmux data When two client of the same gpio call pinctrl_select_state() for the same functionality, we are seeing NULL pointer issue while accessing desc->mux_owner. Let's say two processes A, B executing in pin_request() for the same pin and process A updates the desc->mux_usecount but not yet updated the desc->mux_owner while process B see the desc->mux_usecount which got updated by A path an... • https://git.kernel.org/stable/c/2da32aed4a97ca1d70fb8b77926f72f30ce5fb4b •

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

11 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to shrink read extent node in batches We use rwlock to protect core structure data of extent tree during its shrink, however, if there is a huge number of extent nodes in extent tree, during shrink of extent tree, it may hold rwlock for a very long time, which may trigger kernel hang issue. This patch fixes to shrink read extent node in batches, so that, critical region of the rwlock can be shrunk to avoid its extreme long time ho... • https://git.kernel.org/stable/c/295b50e95e900da31ff237e46e04525fa799b2cf •

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

08 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: bpf: put bpf_link's program when link is safe to be deallocated In general, BPF link's underlying BPF program should be considered to be reachable through attach hook -> link -> prog chain, and, pessimistically, we have to assume that as long as link's memory is not safe to free, attach hook's code might hold a pointer to BPF program and use it. As such, it's not (generally) correct to put link's program early before waiting for RCU GPs to ... • https://git.kernel.org/stable/c/5fe23c57abadfd46a7a66e81f3536e4757252a0b •