Page 236 of 7139 results (0.022 seconds)

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

30 May 2024 — In the Linux kernel, the following vulnerability has been resolved: blk-iocost: do not WARN if iocg was already offlined In iocg_pay_debt(), warn is triggered if 'active_list' is empty, which is intended to confirm iocg is active when it has debt. However, warn can be triggered during a blkcg or disk removal, if iocg_waitq_timer_fn() is run at that time: WARNING: CPU: 0 PID: 2344971 at block/blk-iocost.c:1402 iocg_pay_debt+0x14c/0x190 Call trace: iocg_pay_debt+0x14c/0x190 iocg_kick_waitq+0x438/0x... • https://git.kernel.org/stable/c/7caa47151ab2e644dd221f741ec7578d9532c9a3 •

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

30 May 2024 — In the Linux kernel, the following vulnerability has been resolved: SUNRPC: add a missing rpc_stat for TCP TLS Commit 1548036ef120 ("nfs: make the rpc_stat per net namespace") added functionality to specify rpc_stats function but missed adding it to the TCP TLS functionality. As the result, mounting with xprtsec=tls lead to the following kernel oops. [ 128.984192] Unable to handle kernel NULL pointer dereference at virtual address 000000000000001c [ 128.985058] Mem abort info: [ 128.985372] ESR = 0x... • https://git.kernel.org/stable/c/19f51adc778fb84c2eb07eb71800fb0d9f0ff13a •

CVSS: -EPSS: 0%CPEs: 5EXPL: 0

30 May 2024 — In the Linux kernel, the following vulnerability has been resolved: ARM: 9381/1: kasan: clear stale stack poison We found below OOB crash: [ 33.452494] ================================================================== [ 33.453513] BUG: KASAN: stack-out-of-bounds in refresh_cpu_vm_stats.constprop.0+0xcc/0x2ec [ 33.454660] Write of size 164 at addr c1d03d30 by task swapper/0/0 [ 33.455515] [ 33.455767] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O 6.1.25-mainline #1 [ 33.456880] H... • https://git.kernel.org/stable/c/5615f69bc2097452ecc954f5264d784e158d6801 •

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

30 May 2024 — In the Linux kernel, the following vulnerability has been resolved: tcp: defer shutdown(SEND_SHUTDOWN) for TCP_SYN_RECV sockets TCP_SYN_RECV state is really special, it is only used by cross-syn connections, mostly used by fuzzers. In the following crash [1], syzbot managed to trigger a divide by zero in tcp_rcv_space_adjust() A socket makes the following state transitions, without ever calling tcp_init_transfer(), meaning tcp_init_buffer_space() is also not called. TCP_CLOSE connect() ... • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 • CWE-369: Divide By Zero •

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

30 May 2024 — In the Linux kernel, the following vulnerability has been resolved: tcp: Use refcount_inc_not_zero() in tcp_twsk_unique(). Anderson Nascimento reported a use-after-free splat in tcp_twsk_unique() with nice analysis. Since commit ec94c2696f0b ("tcp/dccp: avoid one atomic operation for timewait hashdance"), inet_twsk_hashdance() sets TIME-WAIT socket's sk_refcnt after putting it into ehash and releasing the bucket lock. Thus, there is a small race window where other threads could try to reuse the port dur... • https://git.kernel.org/stable/c/ec94c2696f0bcd5ae92a553244e4ac30d2171a2d • CWE-416: Use After Free •

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

30 May 2024 — In the Linux kernel, the following vulnerability has been resolved: ipv6: Fix potential uninit-value access in __ip6_make_skb() As it was done in commit fc1092f51567 ("ipv4: Fix uninit-value access in __ip_make_skb()") for IPv4, check FLOWI_FLAG_KNOWN_NH on fl6->flowi6_flags instead of testing HDRINCL on the socket to avoid a race condition which causes uninit-value access. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ipv6: corrige el posible acceso a valores uninit en __ip6_make_skb() ... • https://git.kernel.org/stable/c/ea30388baebcce37fd594d425a65037ca35e59e8 • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') •

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

30 May 2024 — In the Linux kernel, the following vulnerability has been resolved: ipv6: fib6_rules: avoid possible NULL dereference in fib6_rule_action() syzbot is able to trigger the following crash [1], caused by unsafe ip6_dst_idev() use. Indeed ip6_dst_idev() can return NULL, and must always be checked. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 0 PID: 31648 ... • https://git.kernel.org/stable/c/5e5f3f0f801321078c897a5de0b4b4304f234da0 • CWE-476: NULL Pointer Dereference •

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

30 May 2024 — In the Linux kernel, the following vulnerability has been resolved: ipv6: prevent NULL dereference in ip6_output() According to syzbot, there is a chance that ip6_dst_idev() returns NULL in ip6_output(). Most places in IPv6 stack deal with a NULL idev just fine, but not here. syzbot reported: general protection fault, probably for non-canonical address 0xdffffc00000000bc: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x00000000000005e0-0x00000000000005e7] CPU: 0 PID: 9775 Comm: syz-exe... • https://git.kernel.org/stable/c/778d80be52699596bf70e0eb0761cf5e1e46088d • CWE-476: NULL Pointer Dereference •

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

30 May 2024 — In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix kernel crash when devlink reload during initialization The devlink reload process will access the hardware resources, but the register operation is done before the hardware is initialized. So, processing the devlink reload during initialization may lead to kernel crash. This patch fixes this by registering the devlink after hardware initialization. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: hns... • https://git.kernel.org/stable/c/cd6242991d2e3990c828a7c2215d2d3321f1da39 •

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

30 May 2024 — In the Linux kernel, the following vulnerability has been resolved: gpiolib: cdev: Fix use after free in lineinfo_changed_notify The use-after-free issue occurs as follows: when the GPIO chip device file is being closed by invoking gpio_chrdev_release(), watched_lines is freed by bitmap_free(), but the unregistration of lineinfo_changed_nb notifier chain failed due to waiting write rwsem. Additionally, one of the GPIO chip's lines is also in the release process and holds the notifier chain's read rwsem. C... • https://git.kernel.org/stable/c/51c1064e82e77b39a49889287ca50709303e2f26 • CWE-416: Use After Free •