Page 163 of 4080 results (0.009 seconds)

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

08 Aug 2024 — In the Linux kernel, the following vulnerability has been resolved: io_uring: fix error pbuf checking Syz reports a problem, which boils down to NULL vs IS_ERR inconsistent error handling in io_alloc_pbuf_ring(). KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:__io_remove_buffers+0xac/0x700 io_uring/kbuf.c:341 Call Trace: io_put_bl io_uring/kbuf.c:378 [inline] io_destroy_buffers+0x14e/0x490 io_uring/kbuf.c:392 io_ring_ctx_free+0xa00/0x1070 io_uring/io_uring.c:2613 io_... • https://git.kernel.org/stable/c/87585b05757dc70545efb434669708d276125559 •

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

08 Aug 2024 — In the Linux kernel, the following vulnerability has been resolved: gpio: pca953x: fix pca953x_irq_bus_sync_unlock race Ensure that `i2c_lock' is held when setting interrupt latch and mask in pca953x_irq_bus_sync_unlock() in order to avoid races. The other (non-probe) call site pca953x_gpio_set_multiple() ensures the lock is held before calling pca953x_write_regs(). The problem occurred when a request raced against irq_bus_sync_unlock() approximately once per thousand reboots on an i.MX8MP based system. * N... • https://git.kernel.org/stable/c/58a5c93bd1a6e949267400080f07e57ffe05ec34 •

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

08 Aug 2024 — In the Linux kernel, the following vulnerability has been resolved: closures: Change BUG_ON() to WARN_ON() If a BUG_ON() can be hit in the wild, it shouldn't be a BUG_ON() For reference, this has popped up once in the CI, and we'll need more info to debug it: 03240 ------------[ cut here ]------------ 03240 kernel BUG at lib/closure.c:21! 03240 kernel BUG at lib/closure.c:21! 03240 Internal error: Oops - BUG: 00000000f2000800 [#1] SMP 03240 Modules linked in: 03240 CPU: 15 PID: 40534 Comm: kworker/u80:1 Not... • https://git.kernel.org/stable/c/c894a74756478bb7aec894bcc513add3d554c0cf •

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

08 Aug 2024 — In the Linux kernel, the following vulnerability has been resolved: mm: page_ref: remove folio_try_get_rcu() The below bug was reported on a non-SMP kernel: [ 275.267158][ T4335] ------------[ cut here ]------------ [ 275.267949][ T4335] kernel BUG at include/linux/page_ref.h:275! [ 275.268526][ T4335] invalid opcode: 0000 [#1] KASAN PTI [ 275.269001][ T4335] CPU: 0 PID: 4335 Comm: trinity-c3 Not tainted 6.7.0-rc4-00061-gefa7df3e3bb5 #1 [ 275.269787][ T4335] Hardware name: QEMU Standard PC (i440FX + PIIX, 1... • https://git.kernel.org/stable/c/57edfcfd3419b4799353d8cbd6ce49da075cfdbd •

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

07 Aug 2024 — In the Linux kernel, the following vulnerability has been resolved: cachefiles: add missing lock protection when polling Add missing lock protection in poll routine when iterating xarray, otherwise: Even with RCU read lock held, only the slot of the radix tree is ensured to be pinned there, while the data structure (e.g. struct cachefiles_req) stored in the slot has no such guarantee. The poll routine will iterate the radix tree and dereference cachefiles_req accordingly. Thus RCU read lock is not adequate ... • https://git.kernel.org/stable/c/b817e22b2e91257ace32a6768c3c003faeaa1c5c •

CVSS: 3.3EPSS: 0%CPEs: 2EXPL: 0

07 Aug 2024 — In the Linux kernel, the following vulnerability has been resolved: spi: don't unoptimize message in spi_async() Calling spi_maybe_unoptimize_message() in spi_async() is wrong because the message is likely to be in the queue and not transferred yet. This can corrupt the message while it is being used by the controller driver. spi_maybe_unoptimize_message() is already called in the correct place in spi_finalize_current_message() to balance the call to spi_maybe_optimize_message() in spi_async(). In the Linux... • https://git.kernel.org/stable/c/7b1d87af14d9ae902ed0c5dc5fabf4eea5abdf02 •

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

07 Aug 2024 — In the Linux kernel, the following vulnerability has been resolved: tty: serial: ma35d1: Add a NULL check for of_node The pdev->dev.of_node can be NULL if the "serial" node is absent. Add a NULL check to return an error in such cases. In the Linux kernel, the following vulnerability has been resolved: tty: serial: ma35d1: Add a NULL check for of_node The pdev->dev.of_node can be NULL if the "serial" node is absent. Add a NULL check to return an error in such cases. • https://git.kernel.org/stable/c/930cbf92db0184e327293d5e7089be0b08d46371 •

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

07 Aug 2024 — In the Linux kernel, the following vulnerability has been resolved: wireguard: allowedips: avoid unaligned 64-bit memory accesses On the parisc platform, the kernel issues kernel warnings because swap_endian() tries to load a 128-bit IPv6 address from an unaligned memory location: Kernel: unaligned access to 0x55f4688c in wg_allowedips_insert_v6+0x2c/0x80 [wireguard] (iir 0xf3010df) Kernel: unaligned access to 0x55f46884 in wg_allowedips_insert_v6+0x38/0x80 [wireguard] (iir 0xf2010dc) Avoid such unaligned m... • https://git.kernel.org/stable/c/e7096c131e5161fa3b8e52a650d7719d2857adfd •

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

07 Aug 2024 — In the Linux kernel, the following vulnerability has been resolved: net, sunrpc: Remap EPERM in case of connection failure in xs_tcp_setup_socket When using a BPF program on kernel_connect(), the call can return -EPERM. This causes xs_tcp_setup_socket() to loop forever, filling up the syslog and causing the kernel to potentially freeze up. Neil suggested: This will propagate -EPERM up into other layers which might not be ready to handle it. It might be safer to map EPERM to an error we would be more likely ... • https://git.kernel.org/stable/c/4fbac77d2d092b475dda9eea66da674369665427 • CWE-835: Loop with Unreachable Exit Condition ('Infinite Loop') •

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

07 Aug 2024 — In the Linux kernel, the following vulnerability has been resolved: Revert "sched/fair: Make sure to try to detach at least one movable task" This reverts commit b0defa7ae03ecf91b8bfd10ede430cff12fcbd06. b0defa7ae03ec changed the load balancing logic to ignore env.max_loop if all tasks examined to that point were pinned. The goal of the patch was to make it more likely to be able to detach a task buried in a long list of pinned tasks. However, this has the unfortunate side effect of creating an O(n) iterati... • https://git.kernel.org/stable/c/b0defa7ae03ecf91b8bfd10ede430cff12fcbd06 • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •