Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: dsa: corrige el pánico cuando el dispositivo maestro DSA se desvincula al apagar Rafael informa que en un sistema con conmutadores LX2160A y Marvell DSA, si se produce un reinicio mientras el DSA maestro (dpaa2-eth ) está activo, se puede ver el siguiente pánico: systemd-shutdown[1]: Rebooting. No se puede manejar la solicitud de paginación del kernel en la dirección virtual 00a0000800000041 [00a0000800000041] dirección entre los rangos de direcciones del usuario y del kernel Error interno: Ups: 96000004 [#1] CPU SMP PREEMPT: 6 PID: 1 Comm: systemd-shutdow No está contaminado 5.16.5-00042 -g8f5585009b24 #32 pc: dsa_slave_netdevice_event+0x130/0x3e4 lr: raw_notifier_call_chain+0x50/0x6c Rastreo de llamadas: dsa_slave_netdevice_event+0x130/0x3e4 raw_notifier_call_chain+0x50/0x6c call_netdevice_notifiers_info+ 0x54/0xa0 __dev_close_many+0x50/0x130 dev_close_many+0x84/0x120 unregister_netdevice_many+0x130/ 0x710 unregister_netdevice_queue+0x8c/0xd0 unregister_netdev+0x20/0x30 dpaa2_eth_remove+0x68/0x190 fsl_mc_driver_remove+0x20/0x5c __device_release_driver+0x21c/0x220 dispositivo_release_driver_internal+0xac/0x b0 device_links_unbind_consumers+0xd4/0x100 __device_release_driver+0x94/0x220 dispositivo_release_driver+0x28/0x40 bus_remove_device+0x118/ 0x124 dispositivo_del+0x174/0x420 fsl_mc_device_remove+0x24/0x40 __fsl_mc_device_remove+0xc/0x20 dispositivo_para_cada_niño+0x58/0xa0 dprc_remove+0x90/0xb0 fsl_mc_driver_remove+0x20/0x5c __ dispositivo_liberación_controlador+0x21c/0x220 dispositivo_liberación_controlador+0x28/0x40 bus_remove_device+0x118/0x124 dispositivo_del+0x174/ 0x420 fsl_mc_bus_remove+0x80/0x100 fsl_mc_bus_shutdown+0xc/0x1c platform_shutdown+0x20/0x30 dispositivo_shutdown+0x154/0x330 __do_sys_reboot+0x1cc/0x250 __arm64_sys_reboot+0x20/0x30 invoke_syscall.constprop.0+0x4c/0xe0 do_el0_svc+0x4c/0x150 el0_svc+0x24/0xb0 el0t_64_sync_handler+0xa8/0xb0 el0t_64_sync+0x178/0x17c Se puede ver en el seguimiento de la pila que el problema es que la cancelación del registro del maestro provoca un dev_close(), que se notifica como NETDEV_GOING_DOWN a dsa_slave_netdevice_event(). Pero dsa_switch_shutdown() ya se ejecutó, y esto anuló el registro de las interfaces esclavas DSA y, aún así, el controlador NETDEV_GOING_DOWN intenta llamar a dev_close_many() en esas interfaces esclavas, lo que genera el problema. El intento anterior de evitar NETDEV_GOING_DOWN en el maestro después de llamar a dsa_switch_shutdown() parece inadecuado. Anular el registro de las interfaces esclavas es innecesario e inútil. En cambio, después de que los esclavos hayan dejado de ser superiores al maestro DSA, ahora podemos restablecer a NULL el puntero maestro->dsa_ptr, lo que hará que DSA comience a ignorar todos los eventos notificadores futuros en el maestro.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: soluciona un memleak al desaclonar un skb dst y sus metadatos Al desaclonar un skb dst y sus metadatos asociados, se asigna un nuevo dst+metadatos que luego reemplaza al antiguo en el skb. Esto es útil para tener metadatos dst+ no compartidos adjuntos a un skb específico. El problema es que los metadatos dst+ no clonados se inicializan con un recuento de 1, que se incrementa a 2 antes de adjuntarlo al skb. Cuando tun_dst_unclone regresa, solo se hace referencia a los metadatos dst+ desde un único lugar (el skb) mientras su refcount es 2. Su refcount nunca bajará a 0 (cuando se consume el skb), lo que provoca una pérdida de memoria. Solucione este problema eliminando la llamada a dst_hold en tun_dst_unclone, ya que el recuento de metadatos dst+ ya es 1.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ipmr,ip6mr: adquiere RTNL antes de llamar a ip[6]mr_free_table() en la ruta de error. ip[6]mr_free_table() solo se puede llamar bajo el bloqueo RTNL. RTNL: error de aserción en net/core/dev.c (10367) ADVERTENCIA: CPU: 1 PID: 5890 en net/core/dev.c:10367 unregister_netdevice_many+0x1246/0x1850 net/core/dev.c:10367 Módulos vinculados en : CPU: 1 PID: 5890 Comm: syz-executor.2 No contaminado 5.16.0-syzkaller-11627-g422ee58dc0ef #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010: unregister_netdevice_many+0x1246/0x1850 net/core/dev.c:10367 Código: 0f 85 9b ee ff ff e8 69 07 4b fa ba 7f 28 00 00 48 c7 c6 00 90 ae 8a 48 c7 c7 40 90 ae 8a c6 05 reb1 51 06 01 e8 8c 90 d8 01 <0f> 0b e9 70 ee ff ff e8 3e 07 4b fa 4c 89 e7 e8 86 2a 59 fa e9 ee RSP: 0018:ffffc900046ff6e0 EFLAGS: 00010286 RAX: 000000000 RBX: 00000000000000000 RCX: 0000000000000000 RDX : ffff888050f51d00 RSI: ffffffff815fa008 RDI: fffff520008dfece RBP: 0000000000000000 R08: 00000000000000000 R09: 0000000000000000 R10: ffffffff815f3d 6e R11: 0000000000000000 R12: 00000000ffffff4 R13: dffffc0000000000 R14: ffffc900046ff750 R15: ffff88807b7dc000 FS: 00007f4ab736e700(0000) ff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fee0b4f8990 CR3: 000000001e7d2000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: mroute_clean_tables+0x244/0xb40 net/ipv6/ip6mr.c:1509 ip6mr_free_table net/ipv6/ip6mr.c:389 [en línea] ip6mr_rules_init net/ipv6/ip6mr.c:246 [en línea] ip6mr_net_init net/ipv6/ip6mr.c:1306 [en línea] ip6mr_net_init+ 0x3f0/0x4e0 net/ipv6/ip6mr.c:1298 ops_init+0xaf/0x470 net/core/net_namespace.c:140 setup_net+0x54f/0xbb0 net/core/net_namespace.c:331 copy_net_ns+0x318/0x760 net/core/net_namespace .c:475 create_new_namespaces+0x3f6/0xb20 kernel/nsproxy.c:110 copy_namespaces+0x391/0x450 kernel/nsproxy.c:178 copy_process+0x2e0c/0x7300 kernel/fork.c:2167 kernel_clone+0xe7/0xab0 kernel/fork.c :2555 __do_sys_clone+0xc8/0x110 kernel/fork.c:2672 do_syscall_x64 arch/x86/entry/common.c:50 [en línea] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 Entry_SYSCALL_64_after_hwframe+0x44/0 xae RIP: 0033:0x7f4ab89f9059 Código: No se puede acceder a los bytes del código de operación en RIP 0x7f4ab89f902f. RSP: 002b:00007f4ab736e118 EFLAGS: 00000206 ORIG_RAX: 0000000000000038 RAX: ffffffffffffffda RBX: 00007f4ab8b0bf60 RCX: 00007f4ab89f9059 RDX: 0020000280 RSI: 0000000020000270 RDI: 0000000040200000 RBP: 00007f4ab8a5308d R08: 0000000020000300 R09: 0000000020000300 R10: 200002c0 R11: 0000000000000206 R12: 0000000000000000 R13: 00007ffc3977cc1f R14: 00007f4ab736e300 R15: 0000000000022000

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ibmvnic: no liberar napi en __ibmvnic_open() Si __ibmvnic_open() encuentra un error como al configurar el estado del enlace, llama a release_resources() que libera las estructuras de napi innecesariamente. En su lugar, haga que __ibmvnic_open() solo limpie el trabajo que hizo hasta ahora (es decir, deshabilite napi e irqs) y deje el resto a las personas que llaman. Si el llamador de __ibmvnic_open() es ibmvnic_open(), debería liberar los recursos inmediatamente. Si la persona que llama es do_reset() o do_hard_reset(), liberará los recursos en el próximo reinicio. Esto corrige el siguiente fallo que se produjo al ejecutar el comando drmgr varias veces para agregar/eliminar una interfaz vnic: [102056] ibmvnic 30000003 env3: deshabilitar rx_scrq[6] irq [102056] ibmvnic 30000003 env3: deshabilitar rx_scrq[7] irq [102056] ibmvnic 30000003 env3: Se reabastecieron 8 grupos. El kernel intentó leer la página del usuario (10): ¿intento de explotación? (uid: 0) ERROR: Desreferencia del puntero NULL del kernel al leer en 0x00000010 Dirección de instrucción errónea: 0xc000000000a3c840 Ups: Acceso al kernel del área defectuosa, firma: 11 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries .. CPU: 9 PID: 102056 Comm: kworker/9:2 Kdump: cargado No contaminado 5.16.0-rc5-autotest-g6441998e2e37 #1 Cola de trabajo: events_long __ibmvnic_reset [ibmvnic] NIP: c000000000a3c840 LR: c0080000029b537. 8 CTR: c000000000a3c820 REGS: c0000000548e37e0 TRAMPA : 0300 No contaminado (5.16.0-rc5-autotest-g6441998e2e37) MSR: 8000000000009033 CR: 28248484 XER: 00000004 CFAR: c0080000029bdd24 DAR: 00000000010 DSISR: 40000000 IRQMASK: 0 GPR00: c0080000029b55d0 c0000000548e3a80 c0000000028f0200 0000000000000000 ... NIP [c000000000a3c840] napi_enable+0x20/0xc0 LR [c0080000029b 5378] __ibmvnic_open+0xf0/0x430 [ibmvnic] Seguimiento de llamadas: [c0000000548e3a80] [0000000000000006] 0x6 (no confiable) [c0000000548e3ab0] [c0080000029b55d0] __ibmvnic_open+0x348/0x430 [ibmvnic] [c0000000548e3b40] [c0080000029bcc28] __ibmvnic_reset+0x500/0xdf0 [ibmvnic] [c0000000548e3c60] [c000000000176228 ] proceso_one_work+0x288/0x570 [c0000000548e3d00] [c000000000176588] hilo_trabajador+0x78/0x660 [c0000000548e3da0] [c0000000001822f0] kthread+0x1c0/0x1d0 [c0000000548e3e10] [c00000000000cf64] ret_from_kernel_thread+0x5c/0x64 Volcado de instrucciones: 7d2948f8 792307e0 4e800020 60000000 3c4c01eb 9e0 f821ffd1 39430010 38a0fff6 e92d1100 f9210028 39200000 f9010020 60420000 e9210020 ---[ final de seguimiento 5f8033b08fd27706 ]---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: dsa: lantiq_gswip: no use devres para mdiobus Como se explica en los commits: 74b6d7d13307 ("net: dsa: realtek: registre el bus MDIO en devres") 5135e96a3dd2 (" net: dsa: no asigne el esclavo_mii_bus usando devres") mdiobus_free() entrará en pánico cuando se llame desde devm_mdiobus_free() <- devres_release_all() <- __device_release_driver(), y ese mdiobus no fue anulado previamente. El conmutador GSWIP es un dispositivo de plataforma, por lo que el conjunto inicial de restricciones que pensé que causaría esto (buses I2C o SPI que llaman ->eliminar activado ->apagar) no se aplican. Pero hay algo más que se aplica aquí. Si el maestro DSA está en un bus que llama ->remove from ->shutdown (como dpaa2-eth, que está en el bus fsl-mc), hay un enlace de dispositivo entre el conmutador y el maestro DSA, y device_links_unbind_consumers( ) desvinculará el controlador del conmutador GSWIP al apagar. Por lo tanto, se debe aplicar el mismo tratamiento a todos los controladores de conmutador DSA, que es: usar devres tanto para la asignación como para el registro de mdiobus, o no usar devres en absoluto. El controlador gswip tiene la estructura de código implementada para la eliminación ordenada de mdiobus, así que simplemente reemplace devm_mdiobus_alloc() con la variante que no es devres y agregue manual free cuando sea necesario, para garantizar que no permitamos que devres libere un bus aún registrado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: dsa: felix: don't use devres for mdiobus Como se explica en los commits: 74b6d7d13307 ("net: dsa: realtek: registre el bus MDIO en devres") 5135e96a3dd2 (" net: dsa: no asigne el esclavo_mii_bus usando devres") mdiobus_free() entrará en pánico cuando se llame desde devm_mdiobus_free() <- devres_release_all() <- __device_release_driver(), y ese mdiobus no fue anulado previamente. El conmutador Felix VSC9959 es un dispositivo PCI, por lo que el conjunto inicial de restricciones que pensé que causarían esto (buses I2C o SPI que llaman ->eliminar activado ->apagar) no se aplican. Pero hay algo más que se aplica aquí. Si el maestro DSA está en un bus que llama ->remove from ->shutdown (como dpaa2-eth, que está en el bus fsl-mc), hay un enlace de dispositivo entre el conmutador y el maestro DSA, y device_links_unbind_consumers( ) desvinculará el controlador del interruptor Felix al apagarlo. Por lo tanto, se debe aplicar el mismo tratamiento a todos los controladores de conmutador DSA, que es: usar devres tanto para la asignación como para el registro de mdiobus, o no usar devres en absoluto. El controlador Felix tiene la estructura de código implementada para la eliminación ordenada de mdiobus, así que simplemente reemplace devm_mdiobus_alloc_size() con la variante que no es devres y agregue manual free cuando sea necesario, para garantizar que no permitamos que devres libere un bus aún registrado.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: net: dsa: seville: registrar el mdiobus bajo devres Como se explica en commits: 74b6d7d13307 ("net: dsa: realtek: registrar el bus MDIO bajo devres") 5135e96a3dd2 ("net: dsa: no asigne el esclavo_mii_bus usando devres") mdiobus_free() entrará en pánico cuando se llame desde devm_mdiobus_free() <- devres_release_all() <- __device_release_driver(), y ese mdiobus no fue anulado previamente. El conmutador Sevilla VSC9959 es un dispositivo de plataforma, por lo que el conjunto inicial de restricciones que pensé que causarían esto (buses I2C o SPI que llaman ->eliminar encendido ->apagar) no se aplican. Pero hay algo más que se aplica aquí. Si el maestro DSA está en un bus que llama ->remove from ->shutdown (como dpaa2-eth, que está en el bus fsl-mc), hay un enlace de dispositivo entre el conmutador y el maestro DSA, y device_links_unbind_consumers( ) desvinculará el controlador del interruptor de Sevilla al apagarlo. Por lo tanto, se debe aplicar el mismo tratamiento a todos los controladores de conmutador DSA, que es: usar devres tanto para la asignación como para el registro de mdiobus, o no usar devres en absoluto. El controlador Sevilla tiene una estructura de código que podría acomodar las llamadas mdiobus_unregister y mdiobus_free, pero tiene una dependencia externa de mscc_miim_setup() de mdio-mscc-miim.c, que llama a devm_mdiobus_alloc_size() en su nombre. Entonces, en lugar de reestructurar eso y exportar un símbolo más mscc_miim_teardown(), trabajemos con devres y reemplacemos of_mdiobus_register con la variante devres. Cuando usamos all-devres, podemos asegurarnos de que devres no libere un bus aún registrado (ejecuta ambas devoluciones de llamada o ninguna).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: dsa: bcm_sf2: no use devres para mdiobus Como se explica en los commits: 74b6d7d13307 ("net: dsa: realtek: registre el bus MDIO en devres") 5135e96a3dd2 (" net: dsa: no asigne el esclavo_mii_bus usando devres") mdiobus_free() entrará en pánico cuando se llame desde devm_mdiobus_free() <- devres_release_all() <- __device_release_driver(), y ese mdiobus no fue anulado previamente. El Starfighter 2 es un dispositivo de plataforma, por lo que el conjunto inicial de restricciones que pensé que causarían esto (buses I2C o SPI que llaman ->eliminar activado ->apagar) no se aplican. Pero hay algo más que se aplica aquí. Si el maestro DSA está en un bus que llama ->remove from ->shutdown (como dpaa2-eth, que está en el bus fsl-mc), hay un enlace de dispositivo entre el conmutador y el maestro DSA, y device_links_unbind_consumers( ) desvinculará el controlador del conmutador bcm_sf2 al apagar. Por lo tanto, se debe aplicar el mismo tratamiento a todos los controladores de conmutador DSA, que es: usar devres tanto para la asignación como para el registro de mdiobus, o no usar devres en absoluto. El controlador bcm_sf2 tiene la estructura de código implementada para la eliminación ordenada de mdiobus, así que simplemente reemplace devm_mdiobus_alloc() con la variante que no es devres y agregue manual free cuando sea necesario, para garantizar que no permitamos que devres libere un bus aún registrado.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: SUNRPC: bloqueo contra ->cambio de calcetín durante la lectura de sysfs ->sock se puede establecer en NULL de forma asincrónica a menos que se mantenga ->recv_mutex. Por eso es importante mantener ese mutex. De lo contrario, una lectura de sysfs puede provocar un error. El commit 17f09d3f619a ("SUNRPC: compruebe si el xprt está conectado antes de manejar las lecturas sysfs") parece intentar solucionar este problema, pero solo reduce la ventana de ejecución.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: net: dsa: ar9331: registrar el mdiobus en devres Como se explica en commits: 74b6d7d13307 ("net: dsa: realtek: registrar el bus MDIO en devres") 5135e96a3dd2 ("net: dsa: no asigne el Slave_mii_bus usando devres") mdiobus_free() entrará en pánico cuando se llame desde devm_mdiobus_free() <- devres_release_all() <- __device_release_driver(), y ese mdiobus no fue anulado previamente. El ar9331 es un dispositivo MDIO, por lo que el conjunto inicial de restricciones que pensé que causarían esto (buses I2C o SPI que llaman ->eliminar en ->apagar) no se aplican. Pero hay algo más que se aplica aquí. Si el maestro DSA está en un bus que llama ->remove from ->shutdown (como dpaa2-eth, que está en el bus fsl-mc), hay un enlace de dispositivo entre el conmutador y el maestro DSA, y device_links_unbind_consumers( ) desvinculará el controlador del interruptor ar9331 al apagar. Por lo tanto, se debe aplicar el mismo tratamiento a todos los controladores de conmutador DSA, que es: usar devres tanto para la asignación como para el registro de mdiobus, o no usar devres en absoluto. El controlador ar9331 no tiene una estructura de código compleja para la eliminación de mdiobus, así que simplemente reemplace of_mdiobus_register con la variante devres para que sea todo devres y garantizar que no liberemos un bus aún registrado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: dsa: mv88e6xxx: no use devres para mdiobus Como se explica en los commits: 74b6d7d13307 ("net: dsa: realtek: registre el bus MDIO en devres") 5135e96a3dd2 (" net: dsa: no asigne el esclavo_mii_bus usando devres") mdiobus_free() entrará en pánico cuando se llame desde devm_mdiobus_free() <- devres_release_all() <- __device_release_driver(), y ese mdiobus no fue anulado previamente. El mv88e6xxx es un dispositivo MDIO, por lo que el conjunto inicial de restricciones que pensé que causaría esto (buses I2C o SPI que llaman ->eliminar en ->apagar) no se aplican. Pero hay algo más que se aplica aquí. Si el maestro DSA está en un bus que llama ->remove from ->shutdown (como dpaa2-eth, que está en el bus fsl-mc), hay un enlace de dispositivo entre el conmutador y el maestro DSA, y device_links_unbind_consumers( ) desvinculará el controlador del interruptor Marvell al apagarlo. systemd-shutdown[1]: Apagando. mv88e6085 0x0000000008b96000:00 sw_gl0: El enlace está inactivo fsl-mc dpbp.9: Eliminando del grupo iommu 7 fsl-mc dpbp.8: Eliminando del grupo iommu 7 ------------[ cortar aquí ]- ----------- ¡ERROR del kernel en drivers/net/phy/mdio_bus.c:677! Error interno: Ups - ERROR: 0 [#1] PREEMPT Módulos SMP vinculados en: CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 5.16.5-00040-gdc05f73788e5 #15 pc: mdiobus_free+0x44/0x50 lr: devm_mdiobus_free +0x10/0x20 Rastreo de llamadas: mdiobus_free+0x44/0x50 devm_mdiobus_free+0x10/0x20 devres_release_all+0xa0/0x100 __device_release_driver+0x190/0x220 device_release_driver_internal+0xac/0xb0 device_links_unbind_consumers+0xd4/0x 100 __device_release_driver+0x4c/0x220 dispositivo_release_driver_internal+0xac/0xb0 device_links_unbind_consumers+0xd4 /0x100 __device_release_driver+0x94/0x220 dispositivo_release_driver+0x28/0x40 bus_remove_device+0x118/0x124 device_del+0x174/0x420 fsl_mc_device_remove+0x24/0x40 __fsl_mc_device_remove+0xc/0x20 _for_each_child+0x58/0xa0 dprc_remove+0x90/0xb0 fsl_mc_driver_remove+0x20/0x5c __device_release_driver+0x21c /0x220 dispositivo_liberación_controlador+0x28/0x40 bus_remove_device+0x118/0x124 dispositivo_del+0x174/0x420 fsl_mc_bus_remove+0x80/0x100 fsl_mc_bus_shutdown+0xc/0x1c plataforma_apagado+0x20/0x30 54/0x330 kernel_power_off+0x34/0x6c __do_sys_reboot+0x15c/0x250 __arm64_sys_reboot+0x20 /0x30 invoke_syscall.constprop.0+0x4c/0xe0 do_el0_svc+0x4c/0x150 el0_svc+0x24/0xb0 el0t_64_sync_handler+0xa8/0xb0 el0t_64_sync+0x178/0x17c Por lo tanto, se debe aplicar el mismo tratamiento a todos los controladores de conmutador DSA, que es: usar devres tanto para la asignación como para el registro de mdiobus, o no utilice devres en absoluto. El controlador Marvell ya tiene una buena estructura para la eliminación de mdiobus, así que simplemente conecte mdiobus_free y elimine los devres.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tcp: cuidado del caso mixto splice()/sendmsg(MSG_ZEROCOPY) syzbot descubrió que mezclar llamadas sendpage() y sendmsg(MSG_ZEROCOPY) en el mismo socket TCP desencadenaría nuevamente el infame advertencia en inet_sock_destruct() WARN_ON(sk_forward_alloc_get(sk)); Si bien Talal tuvo en cuenta una combinación de datos copiados normales y uno MSG_ZEROCOPY en el mismo skb, la ruta sendpage() se olvidó. Queremos que el cobro se realice por sendpage(), porque las páginas podrían provenir de una tubería. Lo que falta es degradar el estado de copia cero pura para garantizar que sk_forward_alloc permanezca sincronizado. Agregue el asistente tcp_downgrade_zcopy_pure() para que podamos usarlo desde las dos personas que llaman.