CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2024-26691 – KVM: arm64: Fix circular locking dependency
https://notcve.org/view.php?id=CVE-2024-26691
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: 0CVE-2024-26689 – ceph: prevent use-after-free in encode_cap_msg()
https://notcve.org/view.php?id=CVE-2024-26689
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: 7EXPL: 0CVE-2024-26688 – fs,hugetlb: fix NULL pointer dereference in hugetlbs_fill_super
https://notcve.org/view.php?id=CVE-2024-26688
03 Apr 2024 — In the Linux kernel, the following vulnerability has been resolved: fs,hugetlb: fix NULL pointer dereference in hugetlbs_fill_super When configuring a hugetlb filesystem via the fsconfig() syscall, there is a possible NULL dereference in hugetlbfs_fill_super() caused by assigning NULL to ctx->hstate in hugetlbfs_parse_param() when the requested pagesize is non valid. E.g: Taking the following steps: fd = fsopen("hugetlbfs", FSOPEN_CLOEXEC); fsconfig(fd, FSCONFIG_SET_STRING, "pagesize", "1024", 0); fsconfig(... • https://git.kernel.org/stable/c/32021982a324dce93b4ae00c06213bf45fb319c8 •
CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0CVE-2024-26687 – xen/events: close evtchn after mapping cleanup
https://notcve.org/view.php?id=CVE-2024-26687
03 Apr 2024 — In the Linux kernel, the following vulnerability has been resolved: xen/events: close evtchn after mapping cleanup shutdown_pirq and startup_pirq are not taking the irq_mapping_update_lock because they can't due to lock inversion. Both are called with the irq_desc->lock being taking. The lock order, however, is first irq_mapping_update_lock and then irq_desc->lock. This opens multiple races: - shutdown_pirq can be interrupted by a function that allocates an event channel: CPU0 CPU1 shutdown_pirq { xen_evtch... • https://git.kernel.org/stable/c/d46a78b05c0e37f76ddf4a7a67bf0b6c68bada55 •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2024-26686 – fs/proc: do_task_stat: use sig->stats_lock to gather the threads/children stats
https://notcve.org/view.php?id=CVE-2024-26686
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: 12EXPL: 0CVE-2024-26685 – nilfs2: fix potential bug in end_buffer_async_write
https://notcve.org/view.php?id=CVE-2024-26685
03 Apr 2024 — In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential bug in end_buffer_async_write According to a syzbot report, end_buffer_async_write(), which handles the completion of block device writes, may detect abnormal condition of the buffer async_write flag and cause a BUG_ON failure when using nilfs2. Nilfs2 itself does not use end_buffer_async_write(). But, the async_write flag is now used as a marker by commit 7f42ec394156 ("nilfs2: fix issue with race condition of competi... • https://git.kernel.org/stable/c/7f42ec3941560f0902fe3671e36f2c20ffd3af0a •
CVSS: 4.7EPSS: 0%CPEs: 4EXPL: 0CVE-2023-52639 – KVM: s390: vsie: fix race during shadow creation
https://notcve.org/view.php?id=CVE-2023-52639
03 Apr 2024 — In the Linux kernel, the following vulnerability has been resolved: KVM: s390: vsie: fix race during shadow creation Right now it is possible to see gmap->private being zero in kvm_s390_vsie_gmap_notifier resulting in a crash. This is due to the fact that we add gmap->private == kvm after creation: static int acquire_gmap_shadow(struct kvm_vcpu *vcpu, struct vsie_page *vsie_page) { [...] gmap = gmap_shadow(vcpu->arch.gmap, asce, edat); if (IS_ERR(gmap)) return PTR_ERR(gmap); gmap->private = vcpu->kvm; Let c... • https://git.kernel.org/stable/c/a3508fbe9dc6dd3bece0c7bf889cc085a011738c • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') •
CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2023-52638 – can: j1939: prevent deadlock by changing j1939_socks_lock to rwlock
https://notcve.org/view.php?id=CVE-2023-52638
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: 5.5EPSS: 0%CPEs: 7EXPL: 0CVE-2023-52637 – can: j1939: Fix UAF in j1939_sk_match_filter during setsockopt(SO_J1939_FILTER)
https://notcve.org/view.php?id=CVE-2023-52637
03 Apr 2024 — In the Linux kernel, the following vulnerability has been resolved: can: j1939: Fix UAF in j1939_sk_match_filter during setsockopt(SO_J1939_FILTER) Lock jsk->sk to prevent UAF when setsockopt(..., SO_J1939_FILTER, ...) modifies jsk->filters while receiving packets. Following trace was seen on affected system: ================================================================== BUG: KASAN: slab-use-after-free in j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939] Read of size 4 at addr ffff888012144014 by task j19... • https://git.kernel.org/stable/c/9d71dd0c70099914fcd063135da3c580865e924c • CWE-416: Use After Free •
CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0CVE-2024-26684 – net: stmmac: xgmac: fix handling of DPP safety error for DMA channels
https://notcve.org/view.php?id=CVE-2024-26684
02 Apr 2024 — In the Linux kernel, the following vulnerability has been resolved: net: stmmac: xgmac: fix handling of DPP safety error for DMA channels Commit 56e58d6c8a56 ("net: stmmac: Implement Safety Features in XGMAC core") checks and reports safety errors, but leaves the Data Path Parity Errors for each channel in DMA unhandled at all, lead to a storm of interrupt. Fix it by checking and clearing the DMA_DPP_Interrupt_Status register. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: stmmac: x... • https://git.kernel.org/stable/c/56e58d6c8a5640eb708e85866e9d243d0357ee54 •