CVSS: 7.1EPSS: 0%CPEs: 5EXPL: 0CVE-2023-53592 – gpio: sifive: Fix refcount leak in sifive_gpio_probe
https://notcve.org/view.php?id=CVE-2023-53592
04 Oct 2025 — In the Linux kernel, the following vulnerability has been resolved: gpio: sifive: Fix refcount leak in sifive_gpio_probe of_irq_find_parent() returns a node pointer with refcount incremented, We should use of_node_put() on it when not needed anymore. Add missing of_node_put() to avoid refcount leak. In the Linux kernel, the following vulnerability has been resolved: gpio: sifive: Fix refcount leak in sifive_gpio_probe of_irq_find_parent() returns a node pointer with refcount incremented, We should use of_no... • https://git.kernel.org/stable/c/96868dce644d002383f6d5eb575a6ce3c8779f39 •
CVSS: 7.1EPSS: 0%CPEs: 6EXPL: 0CVE-2023-53591 – net/mlx5e: Fix deadlock in tc route query code
https://notcve.org/view.php?id=CVE-2023-53591
04 Oct 2025 — In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix deadlock in tc route query code Cited commit causes ABBA deadlock[0] when peer flows are created while holding the devcom rw semaphore. Due to peer flows offload implementation the lock is taken much higher up the call chain and there is no obvious way to easily fix the deadlock. Instead, since tc route query code needs the peer eswitch structure only to perform a lookup in xarray and doesn't perform any sleeping operations w... • https://git.kernel.org/stable/c/f9d196bd632b8b79261ec3366c30ec3923ea9a02 •
CVSS: 7.8EPSS: 0%CPEs: 7EXPL: 0CVE-2023-53590 – sctp: add a refcnt in sctp_stream_priorities to avoid a nested loop
https://notcve.org/view.php?id=CVE-2023-53590
04 Oct 2025 — In the Linux kernel, the following vulnerability has been resolved: sctp: add a refcnt in sctp_stream_priorities to avoid a nested loop With this refcnt added in sctp_stream_priorities, we don't need to traverse all streams to check if the prio is used by other streams when freeing one stream's prio in sctp_sched_prio_free_sid(). This can avoid a nested loop (up to 65535 * 65535), which may cause a stuck as Ying reported: watchdog: BUG: soft lockup - CPU#23 stuck for 26s! [ksoftirqd/23:136] Call Trace:
CVSS: 7.8EPSS: 0%CPEs: 6EXPL: 0CVE-2023-53589 – wifi: iwlwifi: mvm: don't trust firmware n_channels
https://notcve.org/view.php?id=CVE-2023-53589
04 Oct 2025 — In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: don't trust firmware n_channels If the firmware sends us a corrupted MCC response with n_channels much larger than the command response can be, we might copy far too much (uninitialized) memory and even crash if the n_channels is large enough to make it run out of the one page allocated for the FW response. Fix that by checking the lengths. Doing a < comparison would be sufficient, but the firmware should be doing it cor... • https://git.kernel.org/stable/c/dcaf9f5ecb6f395152609bdc40660d9b593dca63 •
CVSS: 7.2EPSS: 0%CPEs: 3EXPL: 0CVE-2023-53588 – wifi: mac80211: check for station first in client probe
https://notcve.org/view.php?id=CVE-2023-53588
04 Oct 2025 — In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: check for station first in client probe When probing a client, first check if we have it, and then check for the channel context, otherwise you can trigger the warning there easily by probing when the AP isn't even started yet. Since a client existing means the AP is also operating, we can then keep the warning. Also simplify the moved code a bit. In the Linux kernel, the following vulnerability has been resolved: wifi: mac8... • https://git.kernel.org/stable/c/55de908ab292c03f1eb280f51170ddb9c6b57e31 •
CVSS: 5.5EPSS: 0%CPEs: 9EXPL: 0CVE-2023-53587 – ring-buffer: Sync IRQ works before buffer destruction
https://notcve.org/view.php?id=CVE-2023-53587
04 Oct 2025 — In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Sync IRQ works before buffer destruction If something was written to the buffer just before destruction, it may be possible (maybe not in a real system, but it did happen in ARCH=um with time-travel) to destroy the ringbuffer before the IRQ work ran, leading this KASAN report (or a crash without KASAN): BUG: KASAN: slab-use-after-free in irq_work_run_list+0x11a/0x13a Read of size 8 at addr 000000006d640a48 by task swapper/0 CPU... • https://git.kernel.org/stable/c/15693458c4bc0693fd63a50d60f35b628fcf4e29 •
CVSS: 7.1EPSS: 0%CPEs: 6EXPL: 0CVE-2023-53586 – scsi: target: Fix multiple LUN_RESET handling
https://notcve.org/view.php?id=CVE-2023-53586
04 Oct 2025 — In the Linux kernel, the following vulnerability has been resolved: scsi: target: Fix multiple LUN_RESET handling This fixes a bug where an initiator thinks a LUN_RESET has cleaned up running commands when it hasn't. The bug was added in commit 51ec502a3266 ("target: Delete tmr from list before processing"). The problem occurs when: 1. We have N I/O cmds running in the target layer spread over 2 sessions. 2. The initiator sends a LUN_RESET for each session. 3. session1's LUN_RESET loops over all the running... • https://git.kernel.org/stable/c/51ec502a32665fed66c7f03799ede4023b212536 • CWE-821: Incorrect Synchronization •
CVSS: 7.1EPSS: 0%CPEs: 6EXPL: 0CVE-2023-53585 – bpf: reject unhashed sockets in bpf_sk_assign
https://notcve.org/view.php?id=CVE-2023-53585
04 Oct 2025 — In the Linux kernel, the following vulnerability has been resolved: bpf: reject unhashed sockets in bpf_sk_assign The semantics for bpf_sk_assign are as follows: sk = some_lookup_func() bpf_sk_assign(skb, sk) bpf_sk_release(sk) That is, the sk is not consumed by bpf_sk_assign. The function therefore needs to make sure that sk lives long enough to be consumed from __inet_lookup_skb. The path through the stack for a TCPv4 packet is roughly: netif_receive_skb_core: takes RCU read lock __netif_receive_skb_core:... • https://git.kernel.org/stable/c/cf7fbe660f2dbd738ab58aea8e9b0ca6ad232449 • CWE-911: Improper Update of Reference Count •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2023-53584 – ubifs: ubifs_releasepage: Remove ubifs_assert(0) to valid this process
https://notcve.org/view.php?id=CVE-2023-53584
04 Oct 2025 — In the Linux kernel, the following vulnerability has been resolved: ubifs: ubifs_releasepage: Remove ubifs_assert(0) to valid this process There are two states for ubifs writing pages: 1. Dirty, Private 2. Not Dirty, Not Private The normal process cannot go to ubifs_releasepage() which means there exists pages being private but not dirty. Reproducer[1] shows that it could occur (which maybe related to [2]) with following process: PA PB PC lock(page)[PA] ubifs_write_end attach_page_private // set Private __s... • https://git.kernel.org/stable/c/1e51764a3c2ac05a23a22b2a95ddee4d9bffb16d •
CVSS: 5.6EPSS: 0%CPEs: 3EXPL: 0CVE-2023-53583 – perf: RISC-V: Remove PERF_HES_STOPPED flag checking in riscv_pmu_start()
https://notcve.org/view.php?id=CVE-2023-53583
04 Oct 2025 — In the Linux kernel, the following vulnerability has been resolved: perf: RISC-V: Remove PERF_HES_STOPPED flag checking in riscv_pmu_start() Since commit 096b52fd2bb4 ("perf: RISC-V: throttle perf events") the perf_sample_event_took() function was added to report time spent in overflow interrupts. If the interrupt takes too long, the perf framework will lower the sysctl_perf_event_sample_rate and max_samples_per_tick. When hwc->interrupts is larger than max_samples_per_tick, the hwc->interrupts will be set ... • https://git.kernel.org/stable/c/096b52fd2bb4996fd68d22b3b7ad21a1296db9d3 •