Page 366 of 3802 results (0.007 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: powerpc/64s: Fix unrecoverable MCE calling async handler from NMI The machine check handler is not considered NMI on 64s. The early handler is the true NMI handler, and then it schedules the machine_check_exception handler to run when interrupts are enabled. This works fine except the case of an unrecoverable MCE, where the true NMI is taken when MSR[RI] is clear, it can not recover, so it calls machine_check_exception directly so something might be done about it. Calling an async handler from NMI context can result in irq state and other things getting corrupted. This can also trigger the BUG at arch/powerpc/include/asm/interrupt.h:168 BUG_ON(!arch_irq_disabled_regs(regs) && !(regs->msr & MSR_EE)); Fix this by making an _async version of the handler which is called in the normal case, and a NMI version that is called for unrecoverable interrupts. • https://git.kernel.org/stable/c/2b43dd7653cca47d297756980846ebbfe8887fa1 https://git.kernel.org/stable/c/d7a8e38999fbd6910516e44cb43f9f4317e54f73 https://git.kernel.org/stable/c/f08fb25bc66986b0952724530a640d9970fa52c1 https://access.redhat.com/security/cve/CVE-2021-47429 https://bugzilla.redhat.com/show_bug.cgi?id=2282302 • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •

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

In the Linux kernel, the following vulnerability has been resolved: powerpc/64s: fix program check interrupt emergency stack path Emergency stack path was jumping into a 3: label inside the __GEN_COMMON_BODY macro for the normal path after it had finished, rather than jumping over it. By a small miracle this is the correct place to build up a new interrupt frame with the existing stack pointer, so things basically worked okay with an added weird looking 700 trap frame on top (which had the wrong ->nip so it didn't decode bug messages either). Fix this by avoiding using numeric labels when jumping over non-trivial macros. Before: LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA PowerNV Modules linked in: CPU: 0 PID: 88 Comm: sh Not tainted 5.15.0-rc2-00034-ge057cdade6e5 #2637 NIP: 7265677368657265 LR: c00000000006c0c8 CTR: c0000000000097f0 REGS: c0000000fffb3a50 TRAP: 0700 Not tainted MSR: 9000000000021031 <SF,HV,ME,IR,DR,LE> CR: 00000700 XER: 20040000 CFAR: c0000000000098b0 IRQMASK: 0 GPR00: c00000000006c964 c0000000fffb3cf0 c000000001513800 0000000000000000 GPR04: 0000000048ab0778 0000000042000000 0000000000000000 0000000000001299 GPR08: 000001e447c718ec 0000000022424282 0000000000002710 c00000000006bee8 GPR12: 9000000000009033 c0000000016b0000 00000000000000b0 0000000000000001 GPR16: 0000000000000000 0000000000000002 0000000000000000 0000000000000ff8 GPR20: 0000000000001fff 0000000000000007 0000000000000080 00007fff89d90158 GPR24: 0000000002000000 0000000002000000 0000000000000255 0000000000000300 GPR28: c000000001270000 0000000042000000 0000000048ab0778 c000000080647e80 NIP [7265677368657265] 0x7265677368657265 LR [c00000000006c0c8] ___do_page_fault+0x3f8/0xb10 Call Trace: [c0000000fffb3cf0] [c00000000000bdac] soft_nmi_common+0x13c/0x1d0 (unreliable) --- interrupt: 700 at decrementer_common_virt+0xb8/0x230 NIP: c0000000000098b8 LR: c00000000006c0c8 CTR: c0000000000097f0 REGS: c0000000fffb3d60 TRAP: 0700 Not tainted MSR: 9000000000021031 <SF,HV,ME,IR,DR,LE> CR: 22424282 XER: 20040000 CFAR: c0000000000098b0 IRQMASK: 0 GPR00: c00000000006c964 0000000000002400 c000000001513800 0000000000000000 GPR04: 0000000048ab0778 0000000042000000 0000000000000000 0000000000001299 GPR08: 000001e447c718ec 0000000022424282 0000000000002710 c00000000006bee8 GPR12: 9000000000009033 c0000000016b0000 00000000000000b0 0000000000000001 GPR16: 0000000000000000 0000000000000002 0000000000000000 0000000000000ff8 GPR20: 0000000000001fff 0000000000000007 0000000000000080 00007fff89d90158 GPR24: 0000000002000000 0000000002000000 0000000000000255 0000000000000300 GPR28: c000000001270000 0000000042000000 0000000048ab0778 c000000080647e80 NIP [c0000000000098b8] decrementer_common_virt+0xb8/0x230 LR [c00000000006c0c8] ___do_page_fault+0x3f8/0xb10 --- interrupt: 700 Instruction dump: XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX ---[ end trace 6d28218e0cc3c949 ]--- After: ------------[ cut here ]------------ kernel BUG at arch/powerpc/kernel/exceptions-64s.S:491! Oops: Exception in kernel mode, sig: 5 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA PowerNV Modules linked in: CPU: 0 PID: 88 Comm: login Not tainted 5.15.0-rc2-00034-ge057cdade6e5-dirty #2638 NIP: c0000000000098b8 LR: c00000000006bf04 CTR: c0000000000097f0 REGS: c0000000fffb3d60 TRAP: 0700 Not tainted MSR: 9000000000021031 <SF,HV,ME,IR,DR,LE> CR: 24482227 XER: 00040000 CFAR: c0000000000098b0 IRQMASK: 0 GPR00: c00000000006bf04 0000000000002400 c000000001513800 c000000001271868 GPR04: 00000000100f0d29 0000000042000000 0000000000000007 0000000000000009 GPR08: 00000000100f0d29 0000000024482227 0000000000002710 c000000000181b3c GPR12: 9000000000009033 c0000000016b0000 00000000100f0d29 c000000005b22f00 GPR16: 00000000ffff0000 0000000000000001 0000000000000009 00000000100eed90 GPR20: 00000000100eed90 00000 ---truncated--- En el kernel de Linux, se resolvió la siguiente vulnerabilidad: powerpc/64s: programa de reparación, verificación, interrupción, ruta de pila de emergencia. La ruta de pila de emergencia saltaba a una etiqueta 3: dentro de la macro __GEN_COMMON_BODY para la ruta normal después de haber terminado, en lugar de saltar por encima. él. Por un pequeño milagro, este es el lugar correcto para construir un nuevo marco de interrupción con el puntero de pila existente, por lo que las cosas básicamente funcionaron bien con un marco de trampa 700 de aspecto extraño agregado en la parte superior (que tenía el -&gt;nip incorrecto, por lo que no decodificar mensajes de error tampoco). • https://git.kernel.org/stable/c/0a882e28468f48ab3d9a36dde0a5723ea29ed1ed https://git.kernel.org/stable/c/411b38fe68ba20a8bbe724b0939762c3f16e16ca https://git.kernel.org/stable/c/c835b3d1d6362b4a4ebb192da7e7fd27a0a45d01 https://git.kernel.org/stable/c/3e607dc4df180b72a38e75030cb0f94d12808712 https://access.redhat.com/security/cve/CVE-2021-47428 https://bugzilla.redhat.com/show_bug.cgi?id=2282304 • CWE-20: Improper Input Validation •

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

In the Linux kernel, the following vulnerability has been resolved: scsi: iscsi: Fix iscsi_task use after free Commit d39df158518c ("scsi: iscsi: Have abort handler get ref to conn") added iscsi_get_conn()/iscsi_put_conn() calls during abort handling but then also changed the handling of the case where we detect an already completed task where we now end up doing a goto to the common put/cleanup code. This results in a iscsi_task use after free, because the common cleanup code will do a put on the iscsi_task. This reverts the goto and moves the iscsi_get_conn() to after we've checked if the iscsi_task is valid. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: iscsi: corrige el uso after free de iscsi_task. Confirmación d39df158518c ("scsi: iscsi: Have abort handler get ref to conn") se agregaron llamadas iscsi_get_conn()/iscsi_put_conn() durante el manejo de abortos pero luego también cambió el manejo del caso en el que detectamos una tarea ya completada y ahora terminamos haciendo un acceso al código común de put/cleanup. Esto da como resultado un uso de iscsi_task después de la liberación, porque el código de limpieza común colocará iscsi_task. • https://git.kernel.org/stable/c/d39df158518ccc3bf24ee18082b5e100c8f014aa https://git.kernel.org/stable/c/1642f51ac0d4f2b55d5748094c49ff8f7191b93c https://git.kernel.org/stable/c/258aad75c62146453d03028a44f2f1590d58e1f6 •

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

In the Linux kernel, the following vulnerability has been resolved: bpf, s390: Fix potential memory leak about jit_data Make sure to free jit_data through kfree() in the error path. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bpf, s390: solucione una posible pérdida de memoria sobre jit_data. Asegúrese de liberar jit_data mediante kfree() en la ruta de error. • https://git.kernel.org/stable/c/1c8f9b91c456f5b47a377a0c8c5d4130fc39433a https://git.kernel.org/stable/c/a326f9c01cfbee4450ae49ce618ae6cbc0f76842 https://git.kernel.org/stable/c/29fdb11ca88d3c490a3d56f0dc77eb9444d086be https://git.kernel.org/stable/c/d590a410e472417a22336c7c37685bfb38e801f2 https://git.kernel.org/stable/c/686cb8b9f6b46787f035afe8fbd132a74e6b1bdd •

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

In the Linux kernel, the following vulnerability has been resolved: i2c: acpi: fix resource leak in reconfiguration device addition acpi_i2c_find_adapter_by_handle() calls bus_find_device() which takes a reference on the adapter which is never released which will result in a reference count leak and render the adapter unremovable. Make sure to put the adapter after creating the client in the same manner that we do for OF. [wsa: fixed title] En el kernel de Linux, se resolvió la siguiente vulnerabilidad: i2c: acpi: corrige la fuga de recursos en la reconfiguración del dispositivo añdido acpi_i2c_find_adapter_by_handle() llama a bus_find_device() que toma una referencia en el adaptador que nunca se libera, lo que resultará en una fuga de recuento de referencias y haga que el adaptador no sea extraíble. Asegúrese de colocar el adaptador después de crear el cliente de la misma manera que lo hacemos para OF. [wsa: título fijo] • https://git.kernel.org/stable/c/525e6fabeae286848592363bda13bc34b59bb5ac https://git.kernel.org/stable/c/b8090a84d7758b929d348bafbd86bb7a10c5fb63 https://git.kernel.org/stable/c/3d9d458a8aaafa47268ea4f1b4114a9f12927989 https://git.kernel.org/stable/c/60bacf259e8c2eb2324f3e13275200baaee9494b https://git.kernel.org/stable/c/f86de018fd7a24ee07372d55ffa7824f0c674a95 https://git.kernel.org/stable/c/90f1077c9184ec2ae9989e4642f211263f301694 https://git.kernel.org/stable/c/6558b646ce1c2a872fe1c2c7cb116f05a2c1950f •