Page 306 of 3327 results (0.013 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Ensure liveliness of nested VM-Enter fail tracepoint message Use the __string() machinery provided by the tracing subystem to make a copy of the string literals consumed by the "nested VM-Enter failed" tracepoint. A complete copy is necessary to ensure that the tracepoint can't outlive the data/memory it consumes and deference stale memory. Because the tracepoint itself is defined by kvm, if kvm-intel and/or kvm-amd are built as modules, the memory holding the string literals defined by the vendor modules will be freed when the module is unloaded, whereas the tracepoint and its data in the ring buffer will live until kvm is unloaded (or "indefinitely" if kvm is built-in). This bug has existed since the tracepoint was added, but was recently exposed by a new check in tracing to detect exactly this type of bug. fmt: '%s%s ' current_buffer: ' vmx_dirty_log_t-140127 [003] .... kvm_nested_vmenter_failed: ' WARNING: CPU: 3 PID: 140134 at kernel/trace/trace.c:3759 trace_check_vprintf+0x3be/0x3e0 CPU: 3 PID: 140134 Comm: less Not tainted 5.13.0-rc1-ce2e73ce600a-req #184 Hardware name: ASUS Q87M-E/Q87M-E, BIOS 1102 03/03/2014 RIP: 0010:trace_check_vprintf+0x3be/0x3e0 Code: <0f> 0b 44 8b 4c 24 1c e9 a9 fe ff ff c6 44 02 ff 00 49 8b 97 b0 20 RSP: 0018:ffffa895cc37bcb0 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffa895cc37bd08 RCX: 0000000000000027 RDX: 0000000000000027 RSI: 00000000ffffdfff RDI: ffff9766cfad74f8 RBP: ffffffffc0a041d4 R08: ffff9766cfad74f0 R09: ffffa895cc37bad8 R10: 0000000000000001 R11: 0000000000000001 R12: ffffffffc0a041d4 R13: ffffffffc0f4dba8 R14: 0000000000000000 R15: ffff976409f2c000 FS: 00007f92fa200740(0000) GS:ffff9766cfac0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000559bd11b0000 CR3: 000000019fbaa002 CR4: 00000000001726e0 Call Trace: trace_event_printf+0x5e/0x80 trace_raw_output_kvm_nested_vmenter_failed+0x3a/0x60 [kvm] print_trace_line+0x1dd/0x4e0 s_show+0x45/0x150 seq_read_iter+0x2d5/0x4c0 seq_read+0x106/0x150 vfs_read+0x98/0x180 ksys_read+0x5f/0xe0 do_syscall_64+0x40/0xb0 entry_SYSCALL_64_after_hwframe+0x44/0xae En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: x86: Garantizar la vivacidad de la VM anidada. Ingrese el mensaje de punto de seguimiento de falla. Utilice la maquinaria __string() proporcionada por el subsistema de seguimiento para hacer una copia de los literales de cadena consumidos por los puntos de seguimiento "nested VM-Enter failed". • https://git.kernel.org/stable/c/380e0055bc7e4a5c687436ba3ccebb4667836b95 https://git.kernel.org/stable/c/796d3bd4ac9316e70c181189318cd2bd98af34bc https://git.kernel.org/stable/c/d046f724bbd725a24007b7e52b2d675249870888 https://git.kernel.org/stable/c/9fb088ce13bc3c59a51260207b487db3e556f275 https://git.kernel.org/stable/c/f31500b0d437a2464ca5972d8f5439e156b74960 •

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

In the Linux kernel, the following vulnerability has been resolved: IB/mlx5: Fix initializing CQ fragments buffer The function init_cq_frag_buf() can be called to initialize the current CQ fragments buffer cq->buf, or the temporary cq->resize_buf that is filled during CQ resize operation. However, the offending commit started to use function get_cqe() for getting the CQEs, the issue with this change is that get_cqe() always returns CQEs from cq->buf, which leads us to initialize the wrong buffer, and in case of enlarging the CQ we try to access elements beyond the size of the current cq->buf and eventually hit a kernel panic. [exception RIP: init_cq_frag_buf+103] [ffff9f799ddcbcd8] mlx5_ib_resize_cq at ffffffffc0835d60 [mlx5_ib] [ffff9f799ddcbdb0] ib_resize_cq at ffffffffc05270df [ib_core] [ffff9f799ddcbdc0] llt_rdma_setup_qp at ffffffffc0a6a712 [llt] [ffff9f799ddcbe10] llt_rdma_cc_event_action at ffffffffc0a6b411 [llt] [ffff9f799ddcbe98] llt_rdma_client_conn_thread at ffffffffc0a6bb75 [llt] [ffff9f799ddcbec8] kthread at ffffffffa66c5da1 [ffff9f799ddcbf50] ret_from_fork_nospec_begin at ffffffffa6d95ddd Fix it by getting the needed CQE by calling mlx5_frag_buf_get_wqe() that takes the correct source buffer as a parameter. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: IB/mlx5: Corrección al inicializar el búfer de fragmentos CQ. Se puede llamar a la función init_cq_frag_buf() para inicializar el búfer de fragmentos CQ actual cq-&gt;buf, o el cq-&gt;resize_buf temporal que es rellenado durante la operación de cambio de tamaño de CQ. Sin embargo, la confirmación infractora comenzó a usar la función get_cqe() para obtener los CQE, el problema con este cambio es que get_cqe() siempre devuelve CQE desde cq-&gt;buf, lo que nos lleva a inicializar el búfer incorrecto y, en caso de ampliarlo, En el CQ intentamos acceder a elementos más allá del tamaño del cq-&gt;buf actual y finalmente entramos en pánico en el kernel. [excepción RIP: init_cq_frag_buf+103] [ffff9f799ddcbcd8] mlx5_ib_resize_cq en fffffffc0835d60 [mlx5_ib] [ffff9f799ddcbdb0] ib_resize_cq en fffffffc05270df [ib_core] [ffff9f799ddcbdc0] _rdma_setup_qp en ffffffffc0a6a712 [llt] [ffff9f799ddcbe10] llt_rdma_cc_event_action en ffffffffc0a6b411 [llt] [ffff9f799ddcbe98] llt_rdma_client_conn_thread en ffffffffc0a6bb75 [llt] [ffff9f799ddcbec8] kthread en ffffffffa66c5da1 [ffff9f799ddcbf50] ret_from_fork_nospec_begin en ffffffffa6d95ddd Arréglelo obteniendo el CQE necesario llamando a mlx5_frag_buf_get_wqe() que toma el búfer de origen correcto como parámetro. • https://git.kernel.org/stable/c/388ca8be00370db132464e27f745b8a0add19fcb https://git.kernel.org/stable/c/1ec2dcd680c71d0d36fa25638b327a468babd5c9 https://git.kernel.org/stable/c/e3ecd9c09fcc10cf6b2bc67e2990c397c40a8c26 https://git.kernel.org/stable/c/91f7fdc4cc10542ca1045c06aad23365f0d067e0 https://git.kernel.org/stable/c/3e670c54eda238cb8a1ea93538a79ae89285c1c4 https://git.kernel.org/stable/c/2ba0aa2feebda680ecfc3c552e867cf4d1b05a3a •

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

In the Linux kernel, the following vulnerability has been resolved: NFS: Fix a potential NULL dereference in nfs_get_client() None of the callers are expecting NULL returns from nfs_get_client() so this code will lead to an Oops. It's better to return an error pointer. I expect that this is dead code so hopefully no one is affected. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: NFS: corrija una posible desreferencia NULL en nfs_get_client() Ninguna de las personas que llaman espera retornos NULL de nfs_get_client(), por lo que este código generará un error ¡Oops! Es mejor devolver un puntero de error. • https://git.kernel.org/stable/c/31434f496abb9f3410b10f541462fe58613dd3ad https://git.kernel.org/stable/c/fab8bfdfb4aac9e4e8363666333adfdf21e89106 https://git.kernel.org/stable/c/a979e601000982a3ca693171a6d4dffc47f8ad00 https://git.kernel.org/stable/c/634f17ff1d59905eb3b4bbbc00805961d08beaee https://git.kernel.org/stable/c/4b380a7d84ef2ce3f4f5bec5d8706ed937ac6502 https://git.kernel.org/stable/c/0057ecef9f324007c0ba5fcca4ddd131178ce78b https://git.kernel.org/stable/c/279ad78a00f8b9c5ff24171a59297187a3bd44b7 https://git.kernel.org/stable/c/58ddf61f10b8f9b7b1341644bfee2f1c6 •

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

In the Linux kernel, the following vulnerability has been resolved: NFS: Fix use-after-free in nfs4_init_client() KASAN reports a use-after-free when attempting to mount two different exports through two different NICs that belong to the same server. Olga was able to hit this with kernels starting somewhere between 5.7 and 5.10, but I traced the patch that introduced the clear_bit() call to 4.13. So something must have changed in the refcounting of the clp pointer to make this call to nfs_put_client() the very last one. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: core: corrige el manejo de errores de scsi_host_alloc(). Después de que el dispositivo se inicializa mediante device_initialize(), o su nombre se establece mediante dev_set_name(), el dispositivo debe liberarse mediante put_device (). De lo contrario, se filtrará el nombre del dispositivo porque se asigna dinámicamente en dev_set_name(). • https://git.kernel.org/stable/c/8dcbec6d20eb881ba368d0aebc3a8a678aebb1da https://git.kernel.org/stable/c/c7eab9e2d7b4e983ce280276fb920af649955897 https://git.kernel.org/stable/c/42c10b0db064e45f5c5ae7019bbf2168ffab766c https://git.kernel.org/stable/c/3e3c7ebbfac152d08be75c92802a64a1f6471a15 https://git.kernel.org/stable/c/c3b6cf64dfe4ef96e7341508d50d6998da7062c7 https://git.kernel.org/stable/c/72651c6579a25317a90536181d311c663d0329ab https://git.kernel.org/stable/c/476bdb04c501fc64bf3b8464ffddefc8dbe01577 • CWE-416: Use After Free •

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

In the Linux kernel, the following vulnerability has been resolved: scsi: core: Fix error handling of scsi_host_alloc() After device is initialized via device_initialize(), or its name is set via dev_set_name(), the device has to be freed via put_device(). Otherwise device name will be leaked because it is allocated dynamically in dev_set_name(). Fix the leak by replacing kfree() with put_device(). Since scsi_host_dev_release() properly handles IDA and kthread removal, remove special-casing these from the error handling as well. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: core: corrige el manejo de errores de scsi_host_alloc(). Después de que el dispositivo se inicializa mediante device_initialize(), o su nombre se establece mediante dev_set_name(), el dispositivo debe liberarse mediante put_device (). • https://git.kernel.org/stable/c/8958181c1663e24a13434448e7d6b96b5d04900a https://git.kernel.org/stable/c/db08ce595dd64ea9859f7d088b51cbfc8e685c66 https://git.kernel.org/stable/c/2dc85045ae65b9302a1d2e2ddd7ce4c030153a6a https://git.kernel.org/stable/c/79296e292d67fa7b5fb8d8c27343683e823872c8 https://git.kernel.org/stable/c/7a696ce1d5d16a33a6cd6400bbcc0339b2460e11 https://git.kernel.org/stable/c/45d83db4728127944b237c0c8248987df9d478e7 https://git.kernel.org/stable/c/66a834d092930cf41d809c0e989b13cd6f9ca006 •