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/7e1cda5cf07f848e6b50b4e5e7761ffbce905a3d •
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 •
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 •
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: 9.6EPSS: 0%CPEs: 7EXPL: 0CVE-2023-53582 – wifi: brcmfmac: ensure CLM version is null-terminated to prevent stack-out-of-bounds
https://notcve.org/view.php?id=CVE-2023-53582
04 Oct 2025 — In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: ensure CLM version is null-terminated to prevent stack-out-of-bounds Fix a stack-out-of-bounds read in brcmfmac that occurs when 'buf' that is not null-terminated is passed as an argument of strreplace() in brcmf_c_preinit_dcmds(). This buffer is filled with a CLM version string by memcpy() in brcmf_fil_iovar_data_get(). Ensure buf is null-terminated. Found by a modified version of syzkaller. [ 33.004414][ T1896] brcmfmac: b... • https://git.kernel.org/stable/c/3b173b4ad9c001a555f44adc7836d6fe3afbe9ec • CWE-125: Out-of-bounds Read •
CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2023-53581 – net/mlx5e: Check for NOT_READY flag state after locking
https://notcve.org/view.php?id=CVE-2023-53581
04 Oct 2025 — In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Check for NOT_READY flag state after locking Currently the check for NOT_READY flag is performed before obtaining the necessary lock. This opens a possibility for race condition when the flow is concurrently removed from unready_flows list by the workqueue task, which causes a double-removal from the list and a crash[0]. Fix the issue by moving the flag check inside the section protected by uplink_priv->unready_flows_lock mutex. ... • https://git.kernel.org/stable/c/ad86755b18d5edf1956f6d25c844f27289216877 •
CVSS: 7.1EPSS: 0%CPEs: 8EXPL: 0CVE-2022-50505 – iommu/amd: Fix pci device refcount leak in ppr_notifier()
https://notcve.org/view.php?id=CVE-2022-50505
04 Oct 2025 — In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix pci device refcount leak in ppr_notifier() As comment of pci_get_domain_bus_and_slot() says, it returns a pci device with refcount increment, when finish using it, the caller must decrement the reference count by calling pci_dev_put(). So call it before returning from ppr_notifier() to avoid refcount leak. In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix pci device refcount leak in ppr_notifi... • https://git.kernel.org/stable/c/daae2d25a4779b272a66ddd01f5810bcee822b9e •