Page 215 of 5377 results (0.010 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: RDMA/ucma: Protect mc during concurrent multicast leaves Partially revert the commit mentioned in the Fixes line to make sure that allocation and erasing multicast struct are locked. BUG: KASAN: use-after-free in ucma_cleanup_multicast drivers/infiniband/core/ucma.c:491 [inline] BUG: KASAN: use-after-free in ucma_destroy_private_ctx+0x914/0xb70 drivers/infiniband/core/ucma.c:579 Read of size 8 at addr ffff88801bb74b00 by task syz-executor.1/25529 CPU: 0 PID: 25529 Comm: syz-executor.1 Not tainted 5.16.0-rc7-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description.constprop.0.cold+0x8d/0x320 mm/kasan/report.c:247 __kasan_report mm/kasan/report.c:433 [inline] kasan_report.cold+0x83/0xdf mm/kasan/report.c:450 ucma_cleanup_multicast drivers/infiniband/core/ucma.c:491 [inline] ucma_destroy_private_ctx+0x914/0xb70 drivers/infiniband/core/ucma.c:579 ucma_destroy_id+0x1e6/0x280 drivers/infiniband/core/ucma.c:614 ucma_write+0x25c/0x350 drivers/infiniband/core/ucma.c:1732 vfs_write+0x28e/0xae0 fs/read_write.c:588 ksys_write+0x1ee/0x250 fs/read_write.c:643 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae Currently the xarray search can touch a concurrently freeing mc as the xa_for_each() is not surrounded by any lock. Rather than hold the lock for a full scan hold it only for the effected items, which is usually an empty list. • https://git.kernel.org/stable/c/95fe51096b7adf1d1e7315c49c75e2f75f162584 https://git.kernel.org/stable/c/75c610212b9f1756b9384911d3a2c347eee8031c https://git.kernel.org/stable/c/2923948ffe0835f7114e948b35bcc42bc9b3baa1 https://git.kernel.org/stable/c/ee2477e8ccd3d978eeac0dc5a981b286d9bb7b0a https://git.kernel.org/stable/c/36e8169ec973359f671f9ec7213547059cae972e •

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

In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix potential memory leak in intel_setup_irq_remapping() After commit e3beca48a45b ("irqdomain/treewide: Keep firmware node unconditionally allocated"). For tear down scenario, fn is only freed after fail to allocate ir_domain, though it also should be freed in case dmar_enable_qi returns error. Besides free fn, irq_domain and ir_msi_domain need to be removed as well if intel_setup_irq_remapping fails to enable queued invalidation. Improve the rewinding path by add out_free_ir_domain and out_free_fwnode lables per Baolu's suggestion. • https://git.kernel.org/stable/c/03992c88d71ba79d956f2ed54e370e630b8750f4 https://git.kernel.org/stable/c/c0c489e5430530a7021f4c889cd5931597e4b200 https://git.kernel.org/stable/c/36f7355545725c5e9400520ae33e6ee16cf78c0e https://git.kernel.org/stable/c/e3beca48a45b5e0e6e6a4e0124276b8248dcc9bb https://git.kernel.org/stable/c/b4198ecddb87cd955aa9e024dd656af5ceaf6196 https://git.kernel.org/stable/c/a0c685ba99961b1dd894b2e470e692a539770f6d https://git.kernel.org/stable/c/a31cb1f0fb6caf46ffe88c41252b6b7a4ee062d9 https://git.kernel.org/stable/c/5c43d46daa0d2928234dd2792ebebc35d •

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

In the Linux kernel, the following vulnerability has been resolved: spi: uniphier: fix reference count leak in uniphier_spi_probe() The issue happens in several error paths in uniphier_spi_probe(). When either dma_get_slave_caps() or devm_spi_register_master() returns an error code, the function forgets to decrease the refcount of both `dma_rx` and `dma_tx` objects, which may lead to refcount leaks. Fix it by decrementing the reference count of specific objects in those error paths. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: spi: uniphier: corrige la fuga del recuento de referencias en uniphier_spi_probe() El problema ocurre en varias rutas de error en uniphier_spi_probe(). Cuando dma_get_slave_caps() o devm_spi_register_master() devuelven un código de error, la función se olvida de disminuir el recuento de los objetos `dma_rx` y `dma_tx`, lo que puede provocar fugas de recuento. Corríjalo disminuyendo el recuento de referencias de objetos específicos en esas rutas de error. • https://git.kernel.org/stable/c/28d1dddc59f6b7fc085093e7c1e978b33f0caf4c https://git.kernel.org/stable/c/e895e067d73e154b1ebc84a124e00831e311d9b0 https://git.kernel.org/stable/c/dd00b4f8f768d81c3788a8ac88fdb3d745e55ea3 https://git.kernel.org/stable/c/447c3d4046d7b54052d07d8b27e15e6edea5662c https://git.kernel.org/stable/c/37c2c83ca4f1ef4b6908181ac98e18360af89b42 •

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

In the Linux kernel, the following vulnerability has been resolved: net: ieee802154: ca8210: Stop leaking skb's Upon error the ieee802154_xmit_complete() helper is not called. Only ieee802154_wake_queue() is called manually. We then leak the skb structure. Free the skb structure upon error before returning. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: ieee802154: ca8210: Detener la fuga de skb. En caso de error, no se llama al asistente ieee802154_xmit_complete(). • https://git.kernel.org/stable/c/ded845a781a578dfb0b5b2c138e5a067aa3b1242 https://git.kernel.org/stable/c/a1c277b0ed2a13e7de923b5f03bc23586eceb851 https://git.kernel.org/stable/c/d6a44feb2f28d71a7e725f72d09c97c81561cd9a https://git.kernel.org/stable/c/6f38d3a6ec11c2733b1c641a46a2a2ecec57be08 https://git.kernel.org/stable/c/78b3f20c17cbcb7645bfa63f2ca0e11b53c09d56 https://git.kernel.org/stable/c/94cd597e20ed4acedb8f15f029d92998b011cb1a https://git.kernel.org/stable/c/21feb6df3967541931242c427fe0958276af81cc https://git.kernel.org/stable/c/621b24b09eb61c63f262da0c9c5f0e933 •

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

In the Linux kernel, the following vulnerability has been resolved: net/smc: Forward wakeup to smc socket waitqueue after fallback When we replace TCP with SMC and a fallback occurs, there may be some socket waitqueue entries remaining in smc socket->wq, such as eppoll_entries inserted by userspace applications. After the fallback, data flows over TCP/IP and only clcsocket->wq will be woken up. Applications can't be notified by the entries which were inserted in smc socket->wq before fallback. So we need a mechanism to wake up smc socket->wq at the same time if some entries remaining in it. The current workaround is to transfer the entries from smc socket->wq to clcsock->wq during the fallback. But this may cause a crash like this: general protection fault, probably for non-canonical address 0xdead000000000100: 0000 [#1] PREEMPT SMP PTI CPU: 3 PID: 0 Comm: swapper/3 Kdump: loaded Tainted: G E 5.16.0+ #107 RIP: 0010:__wake_up_common+0x65/0x170 Call Trace: <IRQ> __wake_up_common_lock+0x7a/0xc0 sock_def_readable+0x3c/0x70 tcp_data_queue+0x4a7/0xc40 tcp_rcv_established+0x32f/0x660 ? sk_filter_trim_cap+0xcb/0x2e0 tcp_v4_do_rcv+0x10b/0x260 tcp_v4_rcv+0xd2a/0xde0 ip_protocol_deliver_rcu+0x3b/0x1d0 ip_local_deliver_finish+0x54/0x60 ip_local_deliver+0x6a/0x110 ? • https://git.kernel.org/stable/c/fb92e025baa73e99250b79ab64f4e088d2888993 https://git.kernel.org/stable/c/2153bd1e3d3dbf6a3403572084ef6ed31c53c5f0 https://git.kernel.org/stable/c/d6e981ec9491be5ec46d838b1151e7edefe607f5 https://git.kernel.org/stable/c/ff6eeb627898c179aac421af5d6515d3f50b84df https://git.kernel.org/stable/c/0ef6049f664941bc0f75828b3a61877635048b27 https://git.kernel.org/stable/c/504078fbe9dd570d685361b57784a6050bc40aaa https://git.kernel.org/stable/c/341adeec9adad0874f29a0a1af35638207352a39 •