Page 168 of 4642 results (0.007 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: nvme-rdma: destroy cm id before destroy qp to avoid use after free We should always destroy cm_id before destroy qp to avoid to get cma event after qp was destroyed, which may lead to use after free. In RDMA connection establishment error flow, don't destroy qp in cm event handler.Just report cm_error to upper level, qp will be destroy in nvme_rdma_alloc_queue() after destroy cm id. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nvme-rdma: destruye cm id antes de destruir qp para evitar su use after free. Siempre debemos destruir cm_id antes de destruir qp para evitar que se produzca un evento cma después de que se destruya qp, lo que puede llevar a use after free. En el flujo de error de establecimiento de conexión RDMA, no destruya qp en el controlador de eventos cm. Simplemente informe cm_error al nivel superior, qp se destruirá en nvme_rdma_alloc_queue() después de destruir cm id. • https://git.kernel.org/stable/c/ecf0dc5a904830c926a64feffd8e01141f89822f https://git.kernel.org/stable/c/d268a182c56e8361e19fb781137411643312b994 https://git.kernel.org/stable/c/9817d763dbe15327b9b3ff4404fa6f27f927e744 https://access.redhat.com/security/cve/CVE-2021-47378 https://bugzilla.redhat.com/show_bug.cgi?id=2282362 • CWE-416: Use After Free •

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

In the Linux kernel, the following vulnerability has been resolved: bpf: Add oversize check before call kvcalloc() Commit 7661809d493b ("mm: don't allow oversized kvmalloc() calls") add the oversize check. When the allocation is larger than what kmalloc() supports, the following warning triggered: WARNING: CPU: 0 PID: 8408 at mm/util.c:597 kvmalloc_node+0x108/0x110 mm/util.c:597 Modules linked in: CPU: 0 PID: 8408 Comm: syz-executor221 Not tainted 5.14.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:kvmalloc_node+0x108/0x110 mm/util.c:597 Call Trace: kvmalloc include/linux/mm.h:806 [inline] kvmalloc_array include/linux/mm.h:824 [inline] kvcalloc include/linux/mm.h:829 [inline] check_btf_line kernel/bpf/verifier.c:9925 [inline] check_btf_info kernel/bpf/verifier.c:10049 [inline] bpf_check+0xd634/0x150d0 kernel/bpf/verifier.c:13759 bpf_prog_load kernel/bpf/syscall.c:2301 [inline] __sys_bpf+0x11181/0x126e0 kernel/bpf/syscall.c:4587 __do_sys_bpf kernel/bpf/syscall.c:4691 [inline] __se_sys_bpf kernel/bpf/syscall.c:4689 [inline] __x64_sys_bpf+0x78/0x90 kernel/bpf/syscall.c:4689 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Agregar verificación de tamaño excesivo antes de llamar a kvcalloc() Confirmación 7661809d493b ("mm: no permitir llamadas a kvmalloc() de gran tamaño") agregar la verificación de tamaño excesivo. Cuando la asignación es mayor que lo que admite kmalloc(), se activa la siguiente advertencia: ADVERTENCIA: CPU: 0 PID: 8408 en mm/util.c:597 kvmalloc_node+0x108/0x110 mm/util.c:597 Módulos vinculados en: CPU : 0 PID: 8408 Comm: syz-executor221 No contaminado 5.14.0-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:kvmalloc_node+0x108/0x110 mm/util .c:597 Seguimiento de llamadas: kvmalloc include/linux/mm.h:806 [en línea] kvmalloc_array include/linux/mm.h:824 [en línea] kvcalloc include/linux/mm.h:829 [en línea] check_btf_line kernel/bpf /verifier.c:9925 [en línea] check_btf_info kernel/bpf/verifier.c:10049 [en línea] bpf_check+0xd634/0x150d0 kernel/bpf/verifier.c:13759 bpf_prog_load kernel/bpf/syscall.c:2301 [en línea] __sys_bpf +0x11181/0x126e0 kernel/bpf/syscall.c:4587 __do_sys_bpf kernel/bpf/syscall.c:4691 [en línea] __se_sys_bpf kernel/bpf/syscall.c:4689 [en línea] __x64_sys_bpf+0x78/0x90 pf/syscall.c:4689 do_syscall_x64 arch/x86/entry/common.c:50 [en línea] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 Entry_SYSCALL_64_after_hwframe+0x44/0xae • https://git.kernel.org/stable/c/93937596e0652d50973f9dc944fea1694ac8cdfd https://git.kernel.org/stable/c/6345a0bee80139ea00a341c4202ebfd1534b5eb0 https://git.kernel.org/stable/c/b5fe7cdfee5901ce5513c30e554d51536e003bde https://git.kernel.org/stable/c/0e6491b559704da720f6da09dd0a52c4df44c514 •

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

In the Linux kernel, the following vulnerability has been resolved: blktrace: Fix uaf in blk_trace access after removing by sysfs There is an use-after-free problem triggered by following process: P1(sda) P2(sdb) echo 0 > /sys/block/sdb/trace/enable blk_trace_remove_queue synchronize_rcu blk_trace_free relay_close rcu_read_lock __blk_add_trace trace_note_tsk (Iterate running_trace_list) relay_close_buf relay_destroy_buf kfree(buf) trace_note(sdb's bt) relay_reserve buf->offset <- nullptr deference (use-after-free) !!! rcu_read_unlock [ 502.714379] BUG: kernel NULL pointer dereference, address: 0000000000000010 [ 502.715260] #PF: supervisor read access in kernel mode [ 502.715903] #PF: error_code(0x0000) - not-present page [ 502.716546] PGD 103984067 P4D 103984067 PUD 17592b067 PMD 0 [ 502.717252] Oops: 0000 [#1] SMP [ 502.720308] RIP: 0010:trace_note.isra.0+0x86/0x360 [ 502.732872] Call Trace: [ 502.733193] __blk_add_trace.cold+0x137/0x1a3 [ 502.733734] blk_add_trace_rq+0x7b/0xd0 [ 502.734207] blk_add_trace_rq_issue+0x54/0xa0 [ 502.734755] blk_mq_start_request+0xde/0x1b0 [ 502.735287] scsi_queue_rq+0x528/0x1140 ... [ 502.742704] sg_new_write.isra.0+0x16e/0x3e0 [ 502.747501] sg_ioctl+0x466/0x1100 Reproduce method: ioctl(/dev/sda, BLKTRACESETUP, blk_user_trace_setup[buf_size=127]) ioctl(/dev/sda, BLKTRACESTART) ioctl(/dev/sdb, BLKTRACESETUP, blk_user_trace_setup[buf_size=127]) ioctl(/dev/sdb, BLKTRACESTART) echo 0 > /sys/block/sdb/trace/enable & // Add delay(mdelay/msleep) before kernel enters blk_trace_free() ioctl$SG_IO(/dev/sda, SG_IO, ...) // Enters trace_note_tsk() after blk_trace_free() returned // Use mdelay in rcu region rather than msleep(which may schedule out) Remove blk_trace from running_list before calling blk_trace_free() by sysfs if blk_trace is at Blktrace_running state. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: blktrace: corrige uaf en el acceso a blk_trace después de eliminarlo mediante sysfs. Hay un problema de use after free desencadenado por el siguiente proceso: P1(sda) P2(sdb) echo 0 &gt; /sys /block/sdb/trace/enable blk_trace_remove_queue sincronizar_rcu blk_trace_free relé_cerrar rcu_read_lock __blk_add_trace trace_note_tsk (Iterar running_trace_list) relé_close_buf relé_destroy_buf kfree(buf) trace_note(sdb's bt) relé_reserve buf-&gt;offset &lt;- deferencia nullptr (uso-después) -gratis) !!! rcu_read_unlock [502.714379] ERROR: desreferencia del puntero NULL del kernel, dirección: 0000000000000010 [502.715260] #PF: acceso de lectura de supervisor en modo kernel [502.715903] #PF: error_code(0x0000) - página no presente [502.716546] PGD 103984067 P4D 103984067 PUD 17592b067 PMD 0 [ 502.717252] Vaya: 0000 [#1] SMP [ 502.720308] RIP: 0010:trace_note.isra.0+0x86/0x360 [ 502.732872] Seguimiento de llamadas: [ 502.733193] 0x1a3 [502.733734] blk_add_trace_rq+ 0x7b/0xd0 [ 502.734207] blk_add_trace_rq_issue+0x54/0xa0 [ 502.734755] blk_mq_start_request+0xde/0x1b0 [ 502.735287] scsi_queue_rq+0x528/0x1140 ... [ 502.7427 04] sg_new_write.isra.0+0x16e/0x3e0 [ 502.747501] sg_ioctl+0x466/0x1100 Método de reproducción: ioctl(/dev/sda, BLKTRACESETUP, blk_user_trace_setup[buf_size=127]) ioctl(/dev/sda, BLKTRACESTART) ioctl(/dev/sdb, BLKTRACESETUP, blk_user_trace_setup[buf_size=127]) ioctl(/dev/sdb , BLKTRACESTART) echo 0 &gt; /sys/block/sdb/trace/enable &amp; // Agrega retraso(mdelay/msleep) antes de que el kernel entre blk_trace_free() ioctl$SG_IO(/dev/sda, SG_IO, ...) // Entra trace_note_tsk() después de que blk_trace_free() regresara // Utilice mdelay en la región rcu en lugar de msleep (que puede programarse) Elimine blk_trace de running_list antes de llamar a blk_trace_free() mediante sysfs si blk_trace está en el estado Blktrace_running. • https://git.kernel.org/stable/c/c71a896154119f4ca9e89d6078f5f63ad60ef199 https://git.kernel.org/stable/c/488da313edf3abea7f7733efe011c96b23740ab5 https://git.kernel.org/stable/c/dacfd5e4d1142bfb3809aab3634a375f6f373269 https://git.kernel.org/stable/c/d56171d9360c0170c5c5f8f7e2362a2e999eca40 https://git.kernel.org/stable/c/677e362ba807f3aafe6f405c07e0b37244da5222 https://git.kernel.org/stable/c/ebb8d26d93c3ec3c7576c52a8373a2309423c069 https://git.kernel.org/stable/c/3815fe7371d2411ce164281cef40d9fc7b323dee https://git.kernel.org/stable/c/a5f8e86192612d0183047448d8bbe7918 •

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

In the Linux kernel, the following vulnerability has been resolved: dma-debug: prevent an error message from causing runtime problems For some drivers, that use the DMA API. This error message can be reached several millions of times per second, causing spam to the kernel's printk buffer and bringing the CPU usage up to 100% (so, it should be rate limited). However, since there is at least one driver that is in the mainline and suffers from the error condition, it is more useful to err_printk() here instead of just rate limiting the error message (in hopes that it will make it easier for other drivers that suffer from this issue to be spotted). En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: dma-debug: evita que un mensaje de error cause problemas de tiempo de ejecución Para algunos controladores, que utilizan la API DMA. Este mensaje de error puede aparecer varios millones de veces por segundo, provocando spam en el búfer printk del kernel y elevando el uso de la CPU hasta el 100% (por lo tanto, debería tener una velocidad limitada). • https://git.kernel.org/stable/c/de4afec2d2946c92c62a15ab341c70b287289e6a https://git.kernel.org/stable/c/510e1a724ab1bf38150be2c1acabb303f98d0047 •

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

In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v3-its: Fix potential VPE leak on error In its_vpe_irq_domain_alloc, when its_vpe_init() returns an error, there is an off-by-one in the number of VPEs to be freed. Fix it by simply passing the number of VPEs allocated, which is the index of the loop iterating over the VPEs. [maz: fixed commit message] En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: irqchip/gic-v3-its: soluciona una posible fuga de VPE en caso de error. En its_vpe_irq_domain_alloc, cuando its_vpe_init() devuelve un error, hay un error de uno en uno en el número de VPE. para ser liberado. Solucionelo simplemente pasando el número de VPE asignados, que es el índice del bucle que se itera sobre los VPE. [maz: mensaje de confirmación fijo] • https://git.kernel.org/stable/c/7d75bbb4bc1ad90386776459d37e4ddfe605671e https://git.kernel.org/stable/c/7d39992d45acd6f2d6b2f62389c55b61fb3d486b https://git.kernel.org/stable/c/5701e8bff314c155e7afdc467b1e0389d86853d0 https://git.kernel.org/stable/c/42d3711c23781045e7a5cd28536c774b9a66d20b https://git.kernel.org/stable/c/568662e37f927e3dc3e475f3ff7cf4ab7719c5e7 https://git.kernel.org/stable/c/e0c1c2e5da19685a20557a50f10c6aa4fa26aa84 https://git.kernel.org/stable/c/280bef512933b2dda01d681d8cbe499b98fc5bdd https://access.redhat.com/security/cve/CVE-2021-47373 • CWE-402: Transmission of Private Resources into a New Sphere ('Resource Leak') •