CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2025-21650 – net: hns3: fixed hclge_fetch_pf_reg accesses bar space out of bounds issue
https://notcve.org/view.php?id=CVE-2025-21650
19 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: net: hns3: fixed hclge_fetch_pf_reg accesses bar space out of bounds issue The TQP BAR space is divided into two segments. TQPs 0-1023 and TQPs 1024-1279 are in different BAR space addresses. However, hclge_fetch_pf_reg does not distinguish the tqp space information when reading the tqp space information. When the number of TQPs is greater than 1024, access bar space overwriting occurs. The problem of different segments has been considered ... • https://git.kernel.org/stable/c/939ccd107ffcade20c9c7055a2e7ae0fd724fb72 •
CVSS: 5.7EPSS: 0%CPEs: 2EXPL: 0CVE-2025-21649 – net: hns3: fix kernel crash when 1588 is sent on HIP08 devices
https://notcve.org/view.php?id=CVE-2025-21649
19 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix kernel crash when 1588 is sent on HIP08 devices Currently, HIP08 devices does not register the ptp devices, so the hdev->ptp is NULL. But the tx process would still try to set hardware time stamp info with SKBTX_HW_TSTAMP flag and cause a kernel crash. [ 128.087798] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018 ... [ 128.280251] pc : hclge_ptp_set_tx_info+0x2c/0x140 [hclge] [ 128.286600]... • https://git.kernel.org/stable/c/0bf5eb788512187b744ef7f79de835e6cbe85b9c •
CVSS: 7.1EPSS: 0%CPEs: 6EXPL: 0CVE-2025-21648 – netfilter: conntrack: clamp maximum hashtable size to INT_MAX
https://notcve.org/view.php?id=CVE-2025-21648
19 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: netfilter: conntrack: clamp maximum hashtable size to INT_MAX Use INT_MAX as maximum size for the conntrack hashtable. Otherwise, it is possible to hit WARN_ON_ONCE in __kvmalloc_node_noprof() when resizing hashtable because __GFP_NOWARN is unset. See: 0708a0afe291 ("mm: Consider __GFP_NOWARN flag for oversized kvmalloc() calls") Note: hashtable resize is only possible from init_netns. In the Linux kernel, the following vulnerability has be... • https://git.kernel.org/stable/c/9cc1c73ad66610bffc80b691136ffc1e9a3b1a58 •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2025-21647 – sched: sch_cake: add bounds checks to host bulk flow fairness counts
https://notcve.org/view.php?id=CVE-2025-21647
19 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: sched: sch_cake: add bounds checks to host bulk flow fairness counts Even though we fixed a logic error in the commit cited below, syzbot still managed to trigger an underflow of the per-host bulk flow counters, leading to an out of bounds memory access. To avoid any such logic errors causing out of bounds memory accesses, this commit factors out all accesses to the per-host bulk flow counters to a series of helpers that perform bounds-chec... • https://git.kernel.org/stable/c/549e407569e08459d16122341d332cb508024094 •
CVSS: 7.8EPSS: 0%CPEs: 6EXPL: 0CVE-2025-21646 – afs: Fix the maximum cell name length
https://notcve.org/view.php?id=CVE-2025-21646
19 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: afs: Fix the maximum cell name length The kafs filesystem limits the maximum length of a cell to 256 bytes, but a problem occurs if someone actually does that: kafs tries to create a directory under /proc/net/afs/ with the name of the cell, but that fails with a warning: WARNING: CPU: 0 PID: 9 at fs/proc/generic.c:405 because procfs limits the maximum filename length to 255. However, the DNS limits the maximum lookup length and, by extensio... • https://git.kernel.org/stable/c/c3e9f888263bb4df11cbd623ceced02081cb2f9f •
CVSS: 6.3EPSS: 0%CPEs: 5EXPL: 0CVE-2025-21645 – platform/x86/amd/pmc: Only disable IRQ1 wakeup where i8042 actually enabled it
https://notcve.org/view.php?id=CVE-2025-21645
19 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: platform/x86/amd/pmc: Only disable IRQ1 wakeup where i8042 actually enabled it Wakeup for IRQ1 should be disabled only in cases where i8042 had actually enabled it, otherwise "wake_depth" for this IRQ will try to drop below zero and there will be an unpleasant WARN() logged: kernel: atkbd serio0: Disabling IRQ1 wakeup source to avoid platform firmware bug kernel: ------------[ cut here ]------------ kernel: Unbalanced IRQ 1 wake disable ker... • https://git.kernel.org/stable/c/8e60615e8932167057b363c11a7835da7f007106 •
CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 0CVE-2025-21643 – netfs: Fix kernel async DIO
https://notcve.org/view.php?id=CVE-2025-21643
19 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: netfs: Fix kernel async DIO Netfslib needs to be able to handle kernel-initiated asynchronous DIO that is supplied with a bio_vec[] array. Currently, because of the async flag, this gets passed to netfs_extract_user_iter() which throws a warning and fails because it only handles IOVEC and UBUF iterators. This can be triggered through a combination of cifs and a loopback blockdev with something like: mount //my/cifs/share /foo dd if=/dev/zer... • https://git.kernel.org/stable/c/153a9961b551101cd38e94e26cd92fbfd198b19b •
CVSS: 7.8EPSS: 0%CPEs: 4EXPL: 0CVE-2025-21642 – mptcp: sysctl: sched: avoid using current->nsproxy
https://notcve.org/view.php?id=CVE-2025-21642
19 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: mptcp: sysctl: sched: avoid using current->nsproxy Using the 'net' structure via 'current' is not recommended for different reasons. First, if the goal is to use it to read or write per-netns data, this is inconsistent with how the "generic" sysctl entries are doing: directly by only using pointers set to the table entry, e.g. table->data. Linked to that, the per-netns data should always be obtained from the table linked to the netns it had... • https://git.kernel.org/stable/c/daad878a509d69da1761106cb48c091dfe9d522d •
CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0CVE-2025-21640 – sctp: sysctl: cookie_hmac_alg: avoid using current->nsproxy
https://notcve.org/view.php?id=CVE-2025-21640
19 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: sctp: sysctl: cookie_hmac_alg: avoid using current->nsproxy As mentioned in a previous commit of this series, using the 'net' structure via 'current' is not recommended for different reasons: - Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns. - current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using... • https://git.kernel.org/stable/c/3c68198e75111a905ac2412be12bf7b29099729b •
CVSS: 6.4EPSS: 0%CPEs: 7EXPL: 0CVE-2025-21639 – sctp: sysctl: rto_min/max: avoid using current->nsproxy
https://notcve.org/view.php?id=CVE-2025-21639
19 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: sctp: sysctl: rto_min/max: avoid using current->nsproxy As mentioned in a previous commit of this series, using the 'net' structure via 'current' is not recommended for different reasons: - Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns. - current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acc... • https://git.kernel.org/stable/c/4f3fdf3bc59cafd14c3bc2c2369efad34c7aa8b5 •