Page 196 of 6981 results (0.008 seconds)

CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0

15 Sep 2025 — In the Linux kernel, the following vulnerability has been resolved: md/raid5-cache: fix null-ptr-deref for r5l_flush_stripe_to_raid() r5l_flush_stripe_to_raid() will check if the list 'flushing_ios' is empty, and then submit 'flush_bio', however, r5l_log_flush_endio() is clearing the list first and then clear the bio, which will cause null-ptr-deref: T1: submit flush io raid5d handle_active_stripes r5l_flush_stripe_to_raid // list is empty // add 'io_end_ios' to the list bio_init submit_bio // io1 T2: io1 i... • https://git.kernel.org/stable/c/0dd00cba99c352dc9afd62979f350d808c215cb9 • CWE-366: Race Condition within a Thread CWE-476: NULL Pointer Dereference •

CVSS: 7.1EPSS: 0%CPEs: 3EXPL: 0

15 Sep 2025 — In the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Load L1's TSC multiplier based on L1 state, not L2 state When emulating nested VM-Exit, load L1's TSC multiplier if L1's desired ratio doesn't match the current ratio, not if the ratio L1 is using for L2 diverges from the default. Functionally, the end result is the same as KVM will run L2 with L1's multiplier if L2's multiplier is the default, i.e. checking that L1's multiplier is loaded is equivalent to checking if L2 has a non... • https://git.kernel.org/stable/c/5228eb96a4875f8cf5d61d486e3795ac14df8904 •

CVSS: 7.8EPSS: 0%CPEs: 4EXPL: 0

15 Sep 2025 — In the Linux kernel, the following vulnerability has been resolved: KVM: s390/diag: fix racy access of physical cpu number in diag 9c handler We do check for target CPU == -1, but this might change at the time we are going to use it. Hold the physical target CPU in a local variable to avoid out-of-bound accesses to the cpu arrays. In the Linux kernel, the following vulnerability has been resolved: KVM: s390/diag: fix racy access of physical cpu number in diag 9c handler We do check for target CPU == -1, but... • https://git.kernel.org/stable/c/87e28a15c42cc592009c32a8c20e5789059027c2 •

CVSS: 6.5EPSS: 0%CPEs: 16EXPL: 0

15 Sep 2025 — In the Linux kernel, the following vulnerability has been resolved: af_unix: Fix data-races around user->unix_inflight. user->unix_inflight is changed under spin_lock(unix_gc_lock), but too_many_unix_fds() reads it locklessly. Let's annotate the write/read accesses to user->unix_inflight. BUG: KCSAN: data-race in unix_attach_fds / unix_inflight write to 0xffffffff8546f2d0 of 8 bytes by task 44798 on cpu 1: unix_inflight+0x157/0x180 net/unix/scm.c:66 unix_attach_fds+0x147/0x1e0 net/unix/scm.c:123 unix_scm_to... • https://git.kernel.org/stable/c/712f4aad406bb1ed67f3f98d04c044191f0ff593 • CWE-366: Race Condition within a Thread •

CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0

15 Sep 2025 — In the Linux kernel, the following vulnerability has been resolved: PM: domains: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once. In the Linux kernel, the following vulnerability has been resolved: PM: domains: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the resu... • https://git.kernel.org/stable/c/718072ceb211833f3c71724f49d733d636067191 • CWE-772: Missing Release of Resource after Effective Lifetime •

CVSS: 8.4EPSS: 0%CPEs: 6EXPL: 0

15 Sep 2025 — In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: wraparound mbox producer index Driver is not handling the wraparound of the mbox producer index correctly. Currently the wraparound happens once u32 max is reached. Bit 31 of the producer index register is special and should be set only once for the first command. Because the producer index overflow setting bit31 after a long time, FW goes to initialization sequence and this causes FW hang. Fix is to wraparound the mbox produc... • https://git.kernel.org/stable/c/1ac5a404797523cedaf424a3aaa3cf8f9548dff8 •

CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0

15 Sep 2025 — In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: fix percpu counter block leak on error path when creating new netns Here is the stack where we allocate percpu counter block: +-< __alloc_percpu +-< xt_percpu_counter_alloc +-< find_check_entry # {arp,ip,ip6}_tables.c +-< translate_table And it can be leaked on this code path: +-> ip6t_register_table +-> translate_table # allocates percpu counter block +-> xt_register_table # fails there is no freeing of the counter blo... • https://git.kernel.org/stable/c/71ae0dff02d756e4d2ca710b79f2ff5390029a5f •

CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0

15 Sep 2025 — In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: hif_usb: clean up skbs if ath9k_hif_usb_rx_stream() fails Syzkaller detected a memory leak of skbs in ath9k_hif_usb_rx_stream(). While processing skbs in ath9k_hif_usb_rx_stream(), the already allocated skbs in skb_pool are not freed if ath9k_hif_usb_rx_stream() fails. If we have an incorrect pkt_len or pkt_tag, the input skb is considered invalid and dropped. All the associated packets already in skb_pool should be dropped and... • https://git.kernel.org/stable/c/44b23b488d44e56d467764ecb661830e5b02b308 •

CVSS: 5.5EPSS: 0%CPEs: 9EXPL: 0

15 Sep 2025 — In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix memory leak in ocfs2_stack_glue_init() ocfs2_table_header should be free in ocfs2_stack_glue_init() if ocfs2_sysfs_init() failed, otherwise kmemleak will report memleak. BUG: memory leak unreferenced object 0xffff88810eeb5800 (size 128): comm "modprobe", pid 4507, jiffies 4296182506 (age 55.888s) hex dump (first 32 bytes): c0 40 14 a0 ff ff ff ff 00 00 00 00 01 00 00 00 .@.............. 01 00 00 00 00 00 00 00 00 00 00 00 00 00 0... • https://git.kernel.org/stable/c/3878f110f71a0971ff7acc15dd6db711b6ef37c6 •

CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0

15 Sep 2025 — In the Linux kernel, the following vulnerability has been resolved: qlcnic: prevent ->dcb use-after-free on qlcnic_dcb_enable() failure adapter->dcb would get silently freed inside qlcnic_dcb_enable() in case qlcnic_dcb_attach() would return an error, which always happens under OOM conditions. This would lead to use-after-free because both of the existing callers invoke qlcnic_dcb_get_info() on the obtained pointer, which is potentially freed at that point. Propagate errors from qlcnic_dcb_enable(), and ins... • https://git.kernel.org/stable/c/3c44bba1d270cb1620b4fe76786d0968118cb86b •