Page 545 of 4090 results (0.079 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: openvswitch: fix stack OOB read while fragmenting IPv4 packets running openvswitch on kernels built with KASAN, it's possible to see the following splat while testing fragmentation of IPv4 packets: BUG: KASAN: stack-out-of-bounds in ip_do_fragment+0x1b03/0x1f60 Read of size 1 at addr ffff888112fc713c by task handler2/1367 CPU: 0 PID: 1367 Comm: handler2 Not tainted 5.12.0-rc6+ #418 Hardware name: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab 04/01/2014 Call Trace: dump_stack+0x92/0xc1 print_address_description.constprop.7+0x1a/0x150 kasan_report.cold.13+0x7f/0x111 ip_do_fragment+0x1b03/0x1f60 ovs_fragment+0x5bf/0x840 [openvswitch] do_execute_actions+0x1bd5/0x2400 [openvswitch] ovs_execute_actions+0xc8/0x3d0 [openvswitch] ovs_packet_cmd_execute+0xa39/0x1150 [openvswitch] genl_family_rcv_msg_doit.isra.15+0x227/0x2d0 genl_rcv_msg+0x287/0x490 netlink_rcv_skb+0x120/0x380 genl_rcv+0x24/0x40 netlink_unicast+0x439/0x630 netlink_sendmsg+0x719/0xbf0 sock_sendmsg+0xe2/0x110 ____sys_sendmsg+0x5ba/0x890 ___sys_sendmsg+0xe9/0x160 __sys_sendmsg+0xd3/0x170 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f957079db07 Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 eb ec ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 24 ed ff ff 48 RSP: 002b:00007f956ce35a50 EFLAGS: 00000293 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000000000000019 RCX: 00007f957079db07 RDX: 0000000000000000 RSI: 00007f956ce35ae0 RDI: 0000000000000019 RBP: 00007f956ce35ae0 R08: 0000000000000000 R09: 00007f9558006730 R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 R13: 00007f956ce37308 R14: 00007f956ce35f80 R15: 00007f956ce35ae0 The buggy address belongs to the page: page:00000000af2a1d93 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x112fc7 flags: 0x17ffffc0000000() raw: 0017ffffc0000000 0000000000000000 dead000000000122 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected addr ffff888112fc713c is located in stack of task handler2/1367 at offset 180 in frame: ovs_fragment+0x0/0x840 [openvswitch] this frame has 2 objects: [32, 144) 'ovs_dst' [192, 424) 'ovs_rt' Memory state around the buggy address: ffff888112fc7000: f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888112fc7080: 00 f1 f1 f1 f1 00 00 00 00 00 00 00 00 00 00 00 >ffff888112fc7100: 00 00 00 f2 f2 f2 f2 f2 f2 00 00 00 00 00 00 00 ^ ffff888112fc7180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888112fc7200: 00 00 00 00 00 00 f2 f2 f2 00 00 00 00 00 00 00 for IPv4 packets, ovs_fragment() uses a temporary struct dst_entry. Then, in the following call graph: ip_do_fragment() ip_skb_dst_mtu() ip_dst_mtu_maybe_forward() ip_mtu_locked() the pointer to struct dst_entry is used as pointer to struct rtable: this turns the access to struct members like rt_mtu_locked into an OOB read in the stack. Fix this changing the temporary variable used for IPv4 packets in ovs_fragment(), similarly to what is done for IPv6 few lines below. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: openvswitch: corrige la lectura OOB de la pila al fragmentar paquetes IPv4 al ejecutar openvswitch en kernels creados con KASAN, es posible ver el siguiente símbolo al probar la fragmentación de paquetes IPv4: ERROR: KASAN: stack- fuera de los límites en ip_do_fragment+0x1b03/0x1f60 Lectura de tamaño 1 en la dirección ffff888112fc713c por task handler2/1367 CPU: 0 PID: 1367 Comm: handler2 Not tainted 5.12.0-rc6+ #418 Nombre de hardware: Red Hat KVM, BIOS 1.11 .1-4.module+el8.1.0+4066+0f1aadab 01/04/2014 Seguimiento de llamadas: dump_stack+0x92/0xc1 print_address_description.constprop.7+0x1a/0x150 kasan_report.cold.13+0x7f/0x111 ip_do_fragment+0x1b03/0x1f60 ovs_fragment+0x5bf/0x840 [openvswitch] do_execute_actions+0x1bd5/0x2400 [openvswitch] ovs_execute_actions+0xc8/0x3d0 [openvswitch] ovs_packet_cmd_execute+0xa39/0x1150 [openvswitch] genl_family_rcv_msg_do it.isra.15+0x227/0x2d0 genl_rcv_msg+0x287/0x490 netlink_rcv_skb+0x120/ 0x380 genl_rcv+0x24/0x40 netlink_unicast+0x439/0x630 netlink_sendmsg+0x719/0xbf0 sock_sendmsg+0xe2/0x110 ____sys_sendmsg+0x5ba/0x890 ___sys_sendmsg+0xe9/0x160 __sy s_sendmsg+0xd3/0x170 do_syscall_64+0x33/0x40 Entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033: 0x7f957079db07 Código: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 eb ec ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 &lt;48&gt; 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 24 ed ff ff 48 RSP: 002b:00007f956ce35a50 EFLAGS: 00000293 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RB X: 0000000000000019 RCX: 00007f957079db07 RDX: 0000000000000000 RSI: 00007f956ce35ae0 RDI: 0000000000000019 RBP: 00007f956ce35ae0 R08: 00000000000000000 R09: 00007f9558006730 R10: 0000000000000000 R11: 00000000000000293 R12: 0000000000000000 R13: 00007f956ce37308 R14: 00007f956ce35f80 R15: 00007f956ce35ae0 La dirección del error pertenece a la página: página:00000000af2a1d93 refcount:0 mapcount:0 mapeo:00000000000000000 index:0x0 pfn: 0x112fc7 banderas: 0x17ffffc0000000() sin formato: 0017ffffc0000000 0000000000000000 muerto000000000122 00000000000000000 sin formato: 0000000000000000 000000000000 0000 00000000ffffffff 0000000000000000 página volcada porque: kasan: mal acceso detectado addr ffff888112fc713c está ubicado en la pila del controlador de tareas 2/1367 en el desplazamiento 180 en el framework: ovs_fragment+0x0/0x840 [ openvswitch] este framework tiene 2 objetos: [32, 144) 'ovs_dst' [192, 424) 'ovs_rt' Estado de la memoria alrededor de la dirección del error: ffff888112fc7000: f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff88811 2fc7080 : 00 f1 f1 f1 f1 00 00 00 00 00 00 00 00 00 00 00 &gt;ffff888112fc7100: 00 00 00 f2 f2 f2 f2 f2 f2 00 00 00 00 00 00 00 ^ ffff888112fc7180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888112fc7200: 00 00 00 00 00 00 f2 f2 f2 00 00 00 00 00 00 00 para paquetes IPv4, ovs_fragment() utiliza una estructura temporal dst_entry. Luego, en el siguiente gráfico de llamadas: ip_do_fragment() ip_skb_dst_mtu() ip_dst_mtu_maybe_forward() ip_mtu_locked() el puntero a struct dst_entry se usa como puntero a struct rtable: esto convierte el acceso a miembros de estructura como rt_mtu_locked en una lectura OOB en la pila. • https://git.kernel.org/stable/c/119bbaa6795a4f4aed46994cc7d9ab01989c87e3 https://git.kernel.org/stable/c/d543907a4730400f5c5b684c57cb5bbbfd6136ab https://git.kernel.org/stable/c/8387fbac8e18e26a60559adc63e0b7067303b0a4 https://git.kernel.org/stable/c/d52e5a7e7ca49457dd31fc8b42fb7c0d58a31221 https://git.kernel.org/stable/c/df9ece1148e2ec242871623dedb004f7a1387125 https://git.kernel.org/stable/c/b1d7280f9ba1bfdbc3af5bdb82e51f014854f26f https://git.kernel.org/stable/c/23e17ec1a5eb53fe39cc34fa5592686d5acd0dac https://git.kernel.org/stable/c/5a52fa8ad45b5a593ed416adf32653863 •

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

In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_frag: fix stack OOB read while fragmenting IPv4 packets when 'act_mirred' tries to fragment IPv4 packets that had been previously re-assembled using 'act_ct', splats like the following can be observed on kernels built with KASAN: BUG: KASAN: stack-out-of-bounds in ip_do_fragment+0x1b03/0x1f60 Read of size 1 at addr ffff888147009574 by task ping/947 CPU: 0 PID: 947 Comm: ping Not tainted 5.12.0-rc6+ #418 Hardware name: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab 04/01/2014 Call Trace: <IRQ> dump_stack+0x92/0xc1 print_address_description.constprop.7+0x1a/0x150 kasan_report.cold.13+0x7f/0x111 ip_do_fragment+0x1b03/0x1f60 sch_fragment+0x4bf/0xe40 tcf_mirred_act+0xc3d/0x11a0 [act_mirred] tcf_action_exec+0x104/0x3e0 fl_classify+0x49a/0x5e0 [cls_flower] tcf_classify_ingress+0x18a/0x820 __netif_receive_skb_core+0xae7/0x3340 __netif_receive_skb_one_core+0xb6/0x1b0 process_backlog+0x1ef/0x6c0 __napi_poll+0xaa/0x500 net_rx_action+0x702/0xac0 __do_softirq+0x1e4/0x97f do_softirq+0x71/0x90 </IRQ> __local_bh_enable_ip+0xdb/0xf0 ip_finish_output2+0x760/0x2120 ip_do_fragment+0x15a5/0x1f60 __ip_finish_output+0x4c2/0xea0 ip_output+0x1ca/0x4d0 ip_send_skb+0x37/0xa0 raw_sendmsg+0x1c4b/0x2d00 sock_sendmsg+0xdb/0x110 __sys_sendto+0x1d7/0x2b0 __x64_sys_sendto+0xdd/0x1b0 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f82e13853eb Code: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 f3 0f 1e fa 48 8d 05 75 42 2c 00 41 89 ca 8b 00 85 c0 75 14 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 75 c3 0f 1f 40 00 41 57 4d 89 c7 41 56 41 89 RSP: 002b:00007ffe01fad888 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00005571aac13700 RCX: 00007f82e13853eb RDX: 0000000000002330 RSI: 00005571aac13700 RDI: 0000000000000003 RBP: 0000000000002330 R08: 00005571aac10500 R09: 0000000000000010 R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffe01faefb0 R13: 00007ffe01fad890 R14: 00007ffe01fad980 R15: 00005571aac0f0a0 The buggy address belongs to the page: page:000000001dff2e03 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x147009 flags: 0x17ffffc0001000(reserved) raw: 0017ffffc0001000 ffffea00051c0248 ffffea00051c0248 0000000000000000 raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888147009400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888147009480: f1 f1 f1 f1 04 f2 f2 f2 f2 f2 f2 f2 00 00 00 00 >ffff888147009500: 00 00 00 00 00 00 00 00 00 00 f2 f2 f2 f2 f2 f2 ^ ffff888147009580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888147009600: 00 00 00 00 00 00 00 00 00 00 00 00 00 f2 f2 f2 for IPv4 packets, sch_fragment() uses a temporary struct dst_entry. Then, in the following call graph: ip_do_fragment() ip_skb_dst_mtu() ip_dst_mtu_maybe_forward() ip_mtu_locked() the pointer to struct dst_entry is used as pointer to struct rtable: this turns the access to struct members like rt_mtu_locked into an OOB read in the stack. Fix this changing the temporary variable used for IPv4 packets in sch_fragment(), similarly to what is done for IPv6 few lines below. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/sched: sch_frag: corrige la lectura OOB de la pila al fragmentar paquetes IPv4 cuando 'act_mirred' intenta fragmentar paquetes IPv4 que se habían reensamblado previamente usando 'act_ct', símbolos como el Se puede observar lo siguiente en los núcleos creados con KASAN: ERROR: KASAN: pila fuera de los límites en ip_do_fragment+0x1b03/0x1f60 Lectura de tamaño 1 en la dirección ffff888147009574 mediante tarea ping/947 CPU: 0 PID: 947 Comm: ping no contaminado 5.12.0-rc6+ #418 Nombre de hardware: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab 01/04/2014 Seguimiento de llamadas: dump_stack+0x92/0xc1 print_address_description.constprop. 7+0x1a/0x150 kasan_report.cold.13+0x7f/0x111 ip_do_fragment+0x1b03/0x1f60 sch_fragment+0x4bf/0xe40 tcf_mirred_act+0xc3d/0x11a0 [act_mirred] tcf_action_exec+0x104/0x3e0 fl_classify+0 x49a/0x5e0 [cls_flower] tcf_classify_ingress+0x18a/0x820 __netif_receive_skb_core+0xae7/0x3340 __netif_receive_skb_one_core+0xb6/0x1b0 Process_backlog+0x1ef/0x6c0 __napi_poll+0xaa/0x500 net_rx_action+0x702/0xac0 __do_softirq+0x1e4/0x97f do_softirq +0x71/0x90 __local_bh_enable_ip+0xdb/0xf0 ip_finish_output2+0x760/0x2120 ip_do_fragment +0x15a5/0x1f60 __ip_finish_output+0x4c2/0xea0 ip_output+0x1ca/0x4d0 ip_send_skb+0x37/0xa0 raw_sendmsg+0x1c4b/0x2d00 sock_sendmsg+0xdb/0x110 __sys_sendto+0x1d7/0x 2b0 __x64_sys_sendto+0xdd/0x1b0 do_syscall_64+0x33/0x40 Entry_SYSCALL_64_after_hwframe+0x44/0xae RIP : 0033:0x7f82e13853eb Código: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 f3 0f 1e fa 48 8d 05 75 42 2c 00 41 89 ca 8b 00 85 c0 75 14 b8 2c 00 00 00 0f 05 &lt;48 &gt; 3d 00 f0 ff ff 77 75 c3 0f 1f 40 00 41 57 4d 89 c7 41 56 41 89 RSP: 002b:00007ffe01fad888 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffff ffffffffffda RBX: 00005571aac13700 RCX: 00007f82e13853eb RDX: 0000000000002330 RSI: 00005571aac13700 RDI: 0000000000000003 RBP: 0000000000002330 R08: 00005571aac10500 R09: 0000000000000010 R10: 00000000000000000 R11: 0000000000000246 R12: 00007ffe01faefb0 R13: 00007ffe01fad890 R14: 00007ffe01fad980 R15: 00005571aac0f0a0 La dirección del error pertenece a la página: página:000000001dff2e03 refcount:1 mapcount:0 mapeo:0000000000000000 índice: 0x0 pfn:0x147009 banderas: 0x17ffffc0001000(reservado) raw: 0017ffffc0001000 ffffea00051c0248 ffffea00051c0248 0000000000000000 raw: 0000000000000000 0000 000000000000 00000001ffffffff 00000000000000000 página volcada porque: kasan: se detectó mal acceso Estado de la memoria alrededor de la dirección con errores: ffff888147009400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888147009480: f1 f1 f1 f1 04 f2 f2 f2 f2 f2 f2 f2 00 00 00 00 &gt;ffff888147009500: 00 00 00 00 00 00 00 00 00 00 f2 f2 f2 f 2 f2 f2^ffff888147009580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888147009600: 00 00 00 00 00 00 00 00 00 00 00 00 00 f2 f2 f2 para paquetes IPv4, sch_fragment() utiliza una estructura temporal dst_entry. Luego, en el siguiente gráfico de llamadas: ip_do_fragment() ip_skb_dst_mtu() ip_dst_mtu_maybe_forward() ip_mtu_locked() el puntero a struct dst_entry se usa como puntero a struct rtable: esto convierte el acceso a miembros de estructura como rt_mtu_locked en una lectura OOB en la pila. • https://git.kernel.org/stable/c/c129412f74e99b609f0a8e95fc3915af1fd40f34 https://git.kernel.org/stable/c/018bb8da5b5888e19585f9b802f036afe643fcef https://git.kernel.org/stable/c/8e6dfb7beeb6489ac1365b8a71052e737f5da76e https://git.kernel.org/stable/c/31fe34a0118e0acc958c802e830ad5d37ef6b1d3 • CWE-125: Out-of-bounds Read •

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

In the Linux kernel, the following vulnerability has been resolved: ACPI: GTDT: Don't corrupt interrupt mappings on watchdow probe failure When failing the driver probe because of invalid firmware properties, the GTDT driver unmaps the interrupt that it mapped earlier. However, it never checks whether the mapping of the interrupt actially succeeded. Even more, should the firmware report an illegal interrupt number that overlaps with the GIC SGI range, this can result in an IPI being unmapped, and subsequent fireworks (as reported by Dann Frazier). Rework the driver to have a slightly saner behaviour and actually check whether the interrupt has been mapped before unmapping things. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ACPI: GTDT: no corrompe las asignaciones de interrupciones en caso de falla de la sonda de vigilancia. Cuando falla la sonda del controlador debido a propiedades de firmware no válidas, el controlador GTDT desasigna la interrupción que asignó anteriormente. Sin embargo, nunca comprueba si el mapeo de la interrupción realmente tuvo éxito. • https://git.kernel.org/stable/c/ca9ae5ec4ef0ed13833b03297ab319676965492c https://git.kernel.org/stable/c/c3385a9122f8db15b453e07bfc88117fce7f3724 https://git.kernel.org/stable/c/7b2162db1498c71962a4bb2f776fa4e76d4d305b https://git.kernel.org/stable/c/504632a3577a049dd9bb7aabae5b4476f9c586b4 https://git.kernel.org/stable/c/e0f2d86481eaa83df33b0793f75212919db7a19d https://git.kernel.org/stable/c/42e69521ee1fa5abf21f478d147d06bbfe6bf6a8 https://git.kernel.org/stable/c/596e079c362ac17ed02aa1b99fdc444d62072a01 https://git.kernel.org/stable/c/1ecd5b129252249b9bc03d7645a7bda51 •

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

In the Linux kernel, the following vulnerability has been resolved: NFS: fs_context: validate UDP retrans to prevent shift out-of-bounds Fix shift out-of-bounds in xprt_calc_majortimeo(). This is caused by a garbage timeout (retrans) mount option being passed to nfs mount, in this case from syzkaller. If the protocol is XPRT_TRANSPORT_UDP, then 'retrans' is a shift value for a 64-bit long integer, so 'retrans' cannot be >= 64. If it is >= 64, fail the mount and return an error. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: NFS: fs_context: valida las retransmisiones UDP para evitar cambios fuera de los límites. Corrige cambios fuera de los límites en xprt_calc_majortimeo(). Esto se debe a que se pasa una opción de montaje de tiempo de espera de basura (retransmisión) al montaje nfs, en este caso desde syzkaller. • https://git.kernel.org/stable/c/9954bf92c0cddd50a2a470be302e1c1ffdf21d42 https://git.kernel.org/stable/c/96fa26b74cdcf9f5c98996bf36bec9fb5b19ffe2 https://git.kernel.org/stable/c/2f3380121d49e829fb73ba86240c181bc32ad897 https://git.kernel.org/stable/c/3d0163821c035040a46d816a42c0780f0f0a30a8 https://git.kernel.org/stable/c/c09f11ef35955785f92369e25819bf0629df2e59 • CWE-125: Out-of-bounds Read •

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

In the Linux kernel, the following vulnerability has been resolved: tpm: efi: Use local variable for calculating final log size When tpm_read_log_efi is called multiple times, which happens when one loads and unloads a TPM2 driver multiple times, then the global variable efi_tpm_final_log_size will at some point become a negative number due to the subtraction of final_events_preboot_size occurring each time. Use a local variable to avoid this integer underflow. The following issue is now resolved: Mar 8 15:35:12 hibinst kernel: Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Mar 8 15:35:12 hibinst kernel: Workqueue: tpm-vtpm vtpm_proxy_work [tpm_vtpm_proxy] Mar 8 15:35:12 hibinst kernel: RIP: 0010:__memcpy+0x12/0x20 Mar 8 15:35:12 hibinst kernel: Code: 00 b8 01 00 00 00 85 d2 74 0a c7 05 44 7b ef 00 0f 00 00 00 c3 cc cc cc 66 66 90 66 90 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 <f3> 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 f3 a4 Mar 8 15:35:12 hibinst kernel: RSP: 0018:ffff9ac4c0fcfde0 EFLAGS: 00010206 Mar 8 15:35:12 hibinst kernel: RAX: ffff88f878cefed5 RBX: ffff88f878ce9000 RCX: 1ffffffffffffe0f Mar 8 15:35:12 hibinst kernel: RDX: 0000000000000003 RSI: ffff9ac4c003bff9 RDI: ffff88f878cf0e4d Mar 8 15:35:12 hibinst kernel: RBP: ffff9ac4c003b000 R08: 0000000000001000 R09: 000000007e9d6073 Mar 8 15:35:12 hibinst kernel: R10: ffff9ac4c003b000 R11: ffff88f879ad3500 R12: 0000000000000ed5 Mar 8 15:35:12 hibinst kernel: R13: ffff88f878ce9760 R14: 0000000000000002 R15: ffff88f77de7f018 Mar 8 15:35:12 hibinst kernel: FS: 0000000000000000(0000) GS:ffff88f87bd00000(0000) knlGS:0000000000000000 Mar 8 15:35:12 hibinst kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Mar 8 15:35:12 hibinst kernel: CR2: ffff9ac4c003c000 CR3: 00000001785a6004 CR4: 0000000000060ee0 Mar 8 15:35:12 hibinst kernel: Call Trace: Mar 8 15:35:12 hibinst kernel: tpm_read_log_efi+0x152/0x1a7 Mar 8 15:35:12 hibinst kernel: tpm_bios_log_setup+0xc8/0x1c0 Mar 8 15:35:12 hibinst kernel: tpm_chip_register+0x8f/0x260 Mar 8 15:35:12 hibinst kernel: vtpm_proxy_work+0x16/0x60 [tpm_vtpm_proxy] Mar 8 15:35:12 hibinst kernel: process_one_work+0x1b4/0x370 Mar 8 15:35:12 hibinst kernel: worker_thread+0x53/0x3e0 Mar 8 15:35:12 hibinst kernel: ? process_one_work+0x370/0x370 En el kernel de Linux, se resolvió la siguiente vulnerabilidad: tpm: efi: use la variable local para calcular el tamaño del registro final Cuando se llama a tpm_read_log_efi varias veces, lo que sucede cuando uno carga y descarga un controlador TPM2 varias veces, entonces la variable global efi_tpm_final_log_size en algún momento se convierte en un número negativo debido a la resta de final_events_preboot_size que ocurre cada vez. Utilice una variable local para evitar este desbordamiento de enteros. El siguiente problema ahora está resuelto: 8 de marzo 15:35:12 kernel hibinst: Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS 0.0.0 06/02/2015 8 de marzo 15:35:12 kernel hibinst: Cola de trabajo: tpm-vtpm vtpm_proxy_work [tpm_vtpm_proxy] 8 de marzo 15:35:12 kernel de hibinst: RIP: 0010:__memcpy+0x12/0x20 8 de marzo 15:35:12 kernel de hibinst: Código: 00 b8 01 00 00 00 85 d2 74 0a c7 05 44 7b ef 00 0f 00 00 00 c3 cc cc cc 66 66 90 66 90 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 f3 a4 8 de marzo 15:35:12 kernel de hibinst: RSP: 0018:ffff9ac4c0fcfde0 EFLAGS: 00010206 8 de marzo 15:35:12 kernel de hibinst: RAX: ffff88f878cefed5 RBX: ffff88f878ce9000 RCX: 1ff ffffffffffe0f 8 de marzo 15:35:12 kernel de hibinst: RDX: 0000000000000003 RSI: ffff9ac4c003bff9 RDI: ffff88f878cf0e4d 8 de marzo 15:35:12 kernel de hibinst: RBP: ffff9ac4c003b000 R08: 0000000000001000 R09: 000 000007e9d6073 8 de marzo 15:35:12 kernel hibinst: R10: ffff9ac4c003b000 R11: ffff88f879ad3500 R12: 0000000000000ed5 8 de marzo 15:35:12 kernel de hibinst: R13: ffff88f878ce9760 R14: 0000000000000002 R15: ffff88f77de7f018 8 de marzo 15:35:12 kernel de hibinst: FS: 0000000000000000(0000) GS:ffff8 8f87bd00000(0000) knlGS:0000000000000000 8 de marzo a las 15:35: 12 kernel de hibinst: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 8 de marzo 15:35:12 kernel de hibinst: CR2: ffff9ac4c003c000 CR3: 00000001785a6004 CR4: 0000000000060ee0 8 de marzo 15:35:12 kernel de hibinst: Seguimiento de llamadas: 8 de marzo 15:35:12 Hibinst Kernel: tpm_read_log_efi+0x152/0x1a7 mar 8 15:35:12 hibinst kernel: tpm_bios_log_setup+0xc8/0x1c0 mar 8 15:35:12 hibinst kernel: tpm_chip_register kernel de hibinst: vtpm_proxy_work+0x16/0x60 [tpm_vtpm_proxy] 8 de marzo 15:35:12 kernel de hibinst: Process_one_work+0x1b4/0x370 8 de marzo 15:35:12 kernel de hibinst: work_thread+0x53/0x3e0 8 de marzo 15:35:12 kernel de hibinst : ? • https://git.kernel.org/stable/c/166a2809d65b282272c474835ec22c882a39ca1b https://git.kernel.org/stable/c/2f12258b5224cfaa808c54fd29345f3c1cbfca76 https://git.kernel.org/stable/c/60a01ecc9f68067e4314a0b55148e39e5d58a51b https://git.kernel.org/stable/c/3818b753277f5ca0c170bf5b98e0a5a225542fcb https://git.kernel.org/stable/c/ac07c557ca12ec9276c0375517bac7ae5be4e50c https://git.kernel.org/stable/c/48cff270b037022e37835d93361646205ca25101 • CWE-191: Integer Underflow (Wrap or Wraparound) •