Page 86 of 3156 results (0.008 seconds)

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

03 Apr 2024 — In the Linux kernel, the following vulnerability has been resolved: nouveau: offload fence uevents work to workqueue This should break the deadlock between the fctx lock and the irq lock. This offloads the processing off the work from the irq into a workqueue. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nuevo: descargar valla uevents work to workqueue Esto debería romper el punto muerto entre el bloqueo fctx y el bloqueo irq. Esto descarga el procesamiento del trabajo del irq a una co... • https://git.kernel.org/stable/c/cc0037fa592d56e4abb9c7d1c52c4d2dc25cd906 • CWE-833: Deadlock •

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

03 Apr 2024 — In the Linux kernel, the following vulnerability has been resolved: parisc: Fix random data corruption from exception handler The current exception handler implementation, which assists when accessing user space memory, may exhibit random data corruption if the compiler decides to use a different register than the specified register %r29 (defined in ASM_EXCEPTIONTABLE_REG) for the error code. If the compiler choose another register, the fault handler will nevertheless store -EFAULT into %r29 and thus trash ... • https://git.kernel.org/stable/c/23027309b099ffc4efca5477009a11dccbdae592 •

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

03 Apr 2024 — In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix MST Null Ptr for RV The change try to fix below error specific to RV platform: BUG: kernel NULL pointer dereference, address: 0000000000000008 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 4 PID: 917 Comm: sway Not tainted 6.3.9-arch1-1 #1 124dc55df4f5272ccb409f39ef4872fc2b3376a2 Hardware name: LENOVO 20NKS01Y00/20NKS01Y00, BIOS R12ET61W(1.31 ) 07/28/2022 RIP: 0010:drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_disp... • https://git.kernel.org/stable/c/01d992088dce3945f70f49f34b0b911c5213c238 • CWE-476: NULL Pointer Dereference •

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

03 Apr 2024 — In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix data corruption in dsync block recovery for small block sizes The helper function nilfs_recovery_copy_block() of nilfs_recovery_dsync_blocks(), which recovers data from logs created by data sync writes during a mount after an unclean shutdown, incorrectly calculates the on-page offset when copying repair data to the file's page cache. In environments where the block size is smaller than the page size, this flaw can cause data co... • https://git.kernel.org/stable/c/5278c3eb6bf5896417572b52adb6be9d26e92f65 •

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

03 Apr 2024 — In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Fix circular locking dependency The rule inside kvm enforces that the vcpu->mutex is taken *inside* kvm->lock. The rule is violated by the pkvm_create_hyp_vm() which acquires the kvm->lock while already holding the vcpu->mutex lock from kvm_vcpu_ioctl(). Avoid the circular locking dependency altogether by protecting the hyp vm handle with the config_lock, much like we already do for other forms of VM-scoped data. En el kernel de... • https://git.kernel.org/stable/c/3d16cebf01127f459dcfeb79ed77bd68b124c228 • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •

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

03 Apr 2024 — In the Linux kernel, the following vulnerability has been resolved: ceph: prevent use-after-free in encode_cap_msg() In fs/ceph/caps.c, in encode_cap_msg(), "use after free" error was caught by KASAN at this line - 'ceph_buffer_get(arg->xattr_buf);'. This implies before the refcount could be increment here, it was freed. In same file, in "handle_cap_grant()" refcount is decremented by this line - 'ceph_buffer_put(ci->i_xattrs.blob);'. It appears that a race occurred and resource was freed by the latter line... • https://git.kernel.org/stable/c/8180d0c27b93a6eb60da1b08ea079e3926328214 •

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

03 Apr 2024 — In the Linux kernel, the following vulnerability has been resolved: fs/proc: do_task_stat: use sig->stats_lock to gather the threads/children stats lock_task_sighand() can trigger a hard lockup. If NR_CPUS threads call do_task_stat() at the same time and the process has NR_THREADS, it will spin with irqs disabled O(NR_CPUS * NR_THREADS) time. Change do_task_stat() to use sig->stats_lock to gather the statistics outside of ->siglock protected section, in the likely case this code will run lockless. En el ker... • https://git.kernel.org/stable/c/cf4b8c39b9a0bd81c47afc7ef62914a62dd5ec4d • CWE-413: Improper Resource Locking •

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

03 Apr 2024 — In the Linux kernel, the following vulnerability has been resolved: can: j1939: prevent deadlock by changing j1939_socks_lock to rwlock The following 3 locks would race against each other, causing the deadlock situation in the Syzbot bug report: - j1939_socks_lock - active_session_list_lock - sk_session_queue_lock A reasonable fix is to change j1939_socks_lock to an rwlock, since in the rare situations where a write lock is required for the linked list that j1939_socks_lock is protecting, the code does not ... • https://git.kernel.org/stable/c/03358aba991668d3bb2c65b3c82aa32c36851170 • CWE-833: Deadlock •

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

02 Apr 2024 — In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix variable 'mca_funcs' dereferenced before NULL check in 'amdgpu_mca_smu_get_mca_entry()' Fixes the below: drivers/gpu/drm/amd/amdgpu/amdgpu_mca.c:377 amdgpu_mca_smu_get_mca_entry() warn: variable dereferenced before check 'mca_funcs' (see line 368) 357 int amdgpu_mca_smu_get_mca_entry(struct amdgpu_device *adev, enum amdgpu_mca_error_type type, 358 int idx, struct mca_bank_entry *entry) 359 { 360 const struct amdgpu_mca_smu_f... • https://git.kernel.org/stable/c/7b5d58c07024516c0e81b95e98f37710cf402c53 • CWE-476: NULL Pointer Dereference •

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

02 Apr 2024 — In the Linux kernel, the following vulnerability has been resolved: blk-mq: fix IO hang from sbitmap wakeup race In blk_mq_mark_tag_wait(), __add_wait_queue() may be re-ordered with the following blk_mq_get_driver_tag() in case of getting driver tag failure. Then in __sbitmap_queue_wake_up(), waitqueue_active() may not observe the added waiter in blk_mq_mark_tag_wait() and wake up nothing, meantime blk_mq_mark_tag_wait() can't get driver tag successfully. This issue can be reproduced by running the followin... • https://git.kernel.org/stable/c/9525b38180e2753f0daa1a522b7767a2aa969676 • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') •