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 •
CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 0CVE-2024-26683 – wifi: cfg80211: detect stuck ECSA element in probe resp
https://notcve.org/view.php?id=CVE-2024-26683
02 Apr 2024 — In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: detect stuck ECSA element in probe resp We recently added some validation that we don't try to connect to an AP that is currently in a channel switch process, since that might want the channel to be quiet or we might not be able to connect in time to hear the switching in a beacon. This was in commit c09c4f31998b ("wifi: mac80211: don't connect to an AP while it's in a CSA process"). However, we promptly got a report that th... • https://git.kernel.org/stable/c/c09c4f31998bac6d73508e38812518aceb069b68 •
CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 0CVE-2024-26682 – wifi: mac80211: improve CSA/ECSA connection refusal
https://notcve.org/view.php?id=CVE-2024-26682
02 Apr 2024 — In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: improve CSA/ECSA connection refusal As mentioned in the previous commit, we pretty quickly found that some APs have ECSA elements stuck in their probe response, so using that to not attempt to connect while CSA is happening we never connect to such an AP. Improve this situation by checking more carefully and ignoring the ECSA if cfg80211 has previously detected the ECSA element being stuck in the probe response. Additionally... • https://git.kernel.org/stable/c/c09c4f31998bac6d73508e38812518aceb069b68 •