CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2021-47024 – vsock/virtio: free queued packets when closing socket
https://notcve.org/view.php?id=CVE-2021-47024
In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: free queued packets when closing socket As reported by syzbot [1], there is a memory leak while closing the socket. We partially solved this issue with commit ac03046ece2b ("vsock/virtio: free packets during the socket release"), but we forgot to drain the RX queue when the socket is definitely closed by the scheduled work. To avoid future issues, let's use the new virtio_transport_remove_sock() to drain the RX queue before removing the socket from the af_vsock lists calling vsock_remove_sock(). [1] https://syzkaller.appspot.com/bug?extid=24452624fc4c571eedd9 En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: vsock/virtio: paquetes libres en cola al cerrar el socket Según lo informado por syzbot [1], hay una pérdida de memoria al cerrar el socket. Resolvimos parcialmente este problema con el compromiso ac03046ece2b ("vsock/virtio: paquetes libres durante el lanzamiento del socket"), pero nos olvidamos de vaciar la cola RX cuando el trabajo programado cierra definitivamente el socket. Para evitar problemas futuros, usemos el nuevo virtio_transport_remove_sock() para drenar la cola RX antes de eliminar el socket de las listas af_vsock llamando a vsock_remove_sock(). [1] https://syzkaller.appspot.com/bug? • https://git.kernel.org/stable/c/ac03046ece2b158ebd204dfc4896fd9f39f0e6c8 https://git.kernel.org/stable/c/4ea082cd3c400cd5bb36a7beb7e441bf3e29350d https://git.kernel.org/stable/c/4e539fa2dec4db3405e47002f2878aa4a99eb68b https://git.kernel.org/stable/c/4af8a327aeba102aaa9b78f3451f725bc590b237 https://git.kernel.org/stable/c/51adb8ebe8c1d80528fc2ea863cfea9d32d2c52b https://git.kernel.org/stable/c/7d29c9ad0ed525c1b10e29cfca4fb1eece1e93fb https://git.kernel.org/stable/c/b605673b523fe33abeafb2136759bcbc9c1e6ebf https://git.kernel.org/stable/c/27691665145e74a45034a9dccf1150cf1 •
CVSS: 8.2EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47023 – net: marvell: prestera: fix port event handling on init
https://notcve.org/view.php?id=CVE-2021-47023
In the Linux kernel, the following vulnerability has been resolved: net: marvell: prestera: fix port event handling on init For some reason there might be a crash during ports creation if port events are handling at the same time because fw may send initial port event with down state. The crash points to cancel_delayed_work() which is called when port went is down. Currently I did not find out the real cause of the issue, so fixed it by cancel port stats work only if previous port's state was up & runnig. The following is the crash which can be triggered: [ 28.311104] Unable to handle kernel paging request at virtual address 000071775f776600 [ 28.319097] Mem abort info: [ 28.321914] ESR = 0x96000004 [ 28.324996] EC = 0x25: DABT (current EL), IL = 32 bits [ 28.330350] SET = 0, FnV = 0 [ 28.333430] EA = 0, S1PTW = 0 [ 28.336597] Data abort info: [ 28.339499] ISV = 0, ISS = 0x00000004 [ 28.343362] CM = 0, WnR = 0 [ 28.346354] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000100bf7000 [ 28.352842] [000071775f776600] pgd=0000000000000000, p4d=0000000000000000 [ 28.359695] Internal error: Oops: 96000004 [#1] PREEMPT SMP [ 28.365310] Modules linked in: prestera_pci(+) prestera uio_pdrv_genirq [ 28.372005] CPU: 0 PID: 1291 Comm: kworker/0:1H Not tainted 5.11.0-rc4 #1 [ 28.378846] Hardware name: DNI AmazonGo1 A7040 board (DT) [ 28.384283] Workqueue: prestera_fw_wq prestera_fw_evt_work_fn [prestera_pci] [ 28.391413] pstate: 60000085 (nZCv daIf -PAN -UAO -TCO BTYPE=--) [ 28.397468] pc : get_work_pool+0x48/0x60 [ 28.401442] lr : try_to_grab_pending+0x6c/0x1b0 [ 28.406018] sp : ffff80001391bc60 [ 28.409358] x29: ffff80001391bc60 x28: 0000000000000000 [ 28.414725] x27: ffff000104fc8b40 x26: ffff80001127de88 [ 28.420089] x25: 0000000000000000 x24: ffff000106119760 [ 28.425452] x23: ffff00010775dd60 x22: ffff00010567e000 [ 28.430814] x21: 0000000000000000 x20: ffff80001391bcb0 [ 28.436175] x19: ffff00010775deb8 x18: 00000000000000c0 [ 28.441537] x17: 0000000000000000 x16: 000000008d9b0e88 [ 28.446898] x15: 0000000000000001 x14: 00000000000002ba [ 28.452261] x13: 80a3002c00000002 x12: 00000000000005f4 [ 28.457622] x11: 0000000000000030 x10: 000000000000000c [ 28.462985] x9 : 000000000000000c x8 : 0000000000000030 [ 28.468346] x7 : ffff800014400000 x6 : ffff000106119758 [ 28.473708] x5 : 0000000000000003 x4 : ffff00010775dc60 [ 28.479068] x3 : 0000000000000000 x2 : 0000000000000060 [ 28.484429] x1 : 000071775f776600 x0 : ffff00010775deb8 [ 28.489791] Call trace: [ 28.492259] get_work_pool+0x48/0x60 [ 28.495874] cancel_delayed_work+0x38/0xb0 [ 28.500011] prestera_port_handle_event+0x90/0xa0 [prestera] [ 28.505743] prestera_evt_recv+0x98/0xe0 [prestera] [ 28.510683] prestera_fw_evt_work_fn+0x180/0x228 [prestera_pci] [ 28.516660] process_one_work+0x1e8/0x360 [ 28.520710] worker_thread+0x44/0x480 [ 28.524412] kthread+0x154/0x160 [ 28.527670] ret_from_fork+0x10/0x38 [ 28.531290] Code: a8c17bfd d50323bf d65f03c0 9278dc21 (f9400020) [ 28.537429] ---[ end trace 5eced933df3a080b ]--- En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: marvell: prestera: corrige el manejo de eventos del puerto en init Por alguna razón, puede haber una falla durante la creación de puertos si los eventos del puerto se manejan al mismo tiempo porque fw puede enviar el puerto inicial evento con estado inactivo. El bloqueo apunta a cancel_delayed_work(), que se llama cuando el puerto está inactivo. Actualmente no descubrí la causa real del problema, así que lo solucioné cancelando las estadísticas del puerto solo si el estado del puerto anterior estaba activo y funcionando. El siguiente es el fallo que se puede desencadenar: [28.311104] No se puede manejar la solicitud de paginación del kernel en la dirección virtual 000071775f776600 [28.319097] Información de cancelación de memoria: [28.321914] ESR = 0x96000004 [28.324996] EC = 0x25: DABT (EL actual), IL = 32 bits [ 28.330350] SET = 0, FnV = 0 [ 28.333430] EA = 0, S1PTW = 0 [ 28.336597] Información de cancelación de datos: [ 28.339499] ISV = 0, ISS = 0x00000004 [ 28.343362] CM = 0, WnR = 0 [ 28.346354] tabla de páginas de usuario: páginas de 4k, VA de 48 bits, pgdp=0000000100bf7000 [ 28.352842] [000071775f776600] pgd=00000000000000000, p4d=0000000000000000 [ 28.359695] Error interno: Ups: 96000004 [#1] PREEMPT SMP [ 28.365310] Módulos vinculados en: prestera_pci(+) prestera uio_pdrv_genirq [ 28.372005] CPU: 0 PID: 1291 Comm: kworker/0:1H No contaminado 5.11.0-rc4 #1 [ 28.378846] Nombre de hardware: DNI Placa AmazonGo1 A7040 (DT) [ 28.384283] Cola de trabajo : prestera_fw_wq prestera_fw_evt_work_fn [prestera_pci] [ 28.391413] pstate: 60000085 (nZCv daIf -PAN -UAO -TCO BTYPE=--) [ 28.397468] pc : get_work_pool+0x48/0x60 [ 28.401442] lr : try_to _grab_pending+0x6c/0x1b0 [28.406018] sp : ffff80001391bc60 [ 28.409358] x29: ffff80001391bc60 x28: 0000000000000000 [ 28.414725] x27: ffff000104fc8b40 x26: ffff80001127de88 [ 28.4200 89] x25: 0000000000000000 x24: ffff000106119760 [ 28.425452] x23: ffff00010775dd60 x22: ffff00010567e000 [ 28.430814] x21: 000000000000000000 x20: ffff80001391bcb0 [28.436175] x19: ffff00010775deb8 x18: 00000000000000c0 [ 28.441537] x17: 0000000000000000 x16: 000000008d9b0e88 [ 28.446898] x15: 00000000000000 01 x14: 00000000000002ba [ 28.452261] x13: 80a3002c00000002 x12: 00000000000005f4 [ 28.457622] x11: 0000000000000030 x10: 00000000000 0000c [28.462985] x9: 000000000000000c x8: 0000000000000030 [28.468346] x7: ffff800014400000 x6: ffff000106119758 [28.473708] x5: 00000000000000003 x4: ffff00010775dc60 [28.4790 68] x3: 0000000000000000 x2: 00000000000000060 [28.484429] x1: 000071775f776600 x0: ffff00010775deb8 [28.489791] Rastreo de llamadas: [28.492259] get_work_pool+ 0x48/ 0x60 [ 28.495874] cancel_delayed_work+0x38/0xb0 [ 28.500011] prestera_port_handle_event+0x90/0xa0 [prestera] [ 28.505743] prestera_evt_recv+0x98/0xe0 [prestera] [ 28.510683] prestera_fw _evt_work_fn+0x180/0x228 [prestera_pci] [ 28.516660] proceso_one_work+0x1e8/0x360 [ 28.520710] work_thread+0x44/0x480 [ 28.524412] kthread+0x154/0x160 [ 28.527670] ret_from_fork+0x10/0x38 [ 28.531290] Código: a8c17bfd d50323bf d65f03c0 92 78dc21 (f9400020) [28.537429] ---[ final de seguimiento 5eced933df3a080b ]--- • https://git.kernel.org/stable/c/501ef3066c89d7f9045315e1be58749cf9e6814d https://git.kernel.org/stable/c/0ce6052802be2cb61a57b753e41301339c88c839 https://git.kernel.org/stable/c/b5bba6ede42693f50ce1c9944315cefed7491061 https://git.kernel.org/stable/c/9d1ba11fabdd8f25abb24272ef1621417981320b https://git.kernel.org/stable/c/333980481b99edb24ebd5d1a53af70a15d9146de • CWE-400: Uncontrolled Resource Consumption •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47022 – mt76: mt7615: fix memleak when mt7615_unregister_device()
https://notcve.org/view.php?id=CVE-2021-47022
In the Linux kernel, the following vulnerability has been resolved: mt76: mt7615: fix memleak when mt7615_unregister_device() mt7615_tx_token_put() should get call before mt76_free_pending_txwi(). En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mt76: mt7615: corrige memleak cuando mt7615_unregister_device() mt7615_tx_token_put() debería recibir una llamada antes que mt76_free_pending_txwi(). • https://git.kernel.org/stable/c/aec5719681405af21102c2407b01f83ed19e9833 https://git.kernel.org/stable/c/1aca6c30d4b655a4fd29c4ad66985b60def88eed https://git.kernel.org/stable/c/a6275e934605646ef81b02d8d1164f21343149c9 https://git.kernel.org/stable/c/4fa28c807da54c1d720b3cc12e48eb9bea1e2c8f https://git.kernel.org/stable/c/107bcbb219ac84d885ac63b25246f8d33212bc47 https://git.kernel.org/stable/c/6c5b2b0c6e5a6ce2d8f9f85b8b72bfad60eaa506 https://git.kernel.org/stable/c/8ab31da7b89f71c4c2defcca989fab7b42f87d71 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47021 – mt76: mt7915: fix memleak when mt7915_unregister_device()
https://notcve.org/view.php?id=CVE-2021-47021
In the Linux kernel, the following vulnerability has been resolved: mt76: mt7915: fix memleak when mt7915_unregister_device() mt7915_tx_token_put() should get call before mt76_free_pending_txwi(). En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mt76: mt7915: corrige memleak cuando mt7915_unregister_device() mt7915_tx_token_put() debería recibir una llamada antes que mt76_free_pending_txwi(). • https://git.kernel.org/stable/c/4e9e896f81932e337a93ad61cd3d9647571c4637 https://git.kernel.org/stable/c/f285dfb98562e8380101095d168910df1d07d8be https://git.kernel.org/stable/c/81483309ce861a9fa7835322787f68a443fea364 https://git.kernel.org/stable/c/d754c80ae82a662e692a82faad71b8c218cb7f52 https://git.kernel.org/stable/c/e9d32af478cfc3744a45245c0b126738af4b3ac4 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47019 – mt76: mt7921: fix possible invalid register access
https://notcve.org/view.php?id=CVE-2021-47019
In the Linux kernel, the following vulnerability has been resolved: mt76: mt7921: fix possible invalid register access Disable the interrupt and synchronze for the pending irq handlers to ensure the irq tasklet is not being scheduled after the suspend to avoid the possible invalid register access acts when the host pcie controller is suspended. [17932.910534] mt7921e 0000:01:00.0: pci_pm_suspend+0x0/0x22c returned 0 after 21375 usecs [17932.910590] pcieport 0000:00:00.0: calling pci_pm_suspend+0x0/0x22c @ 18565, parent: pci0000:00 [17932.910602] pcieport 0000:00:00.0: pci_pm_suspend+0x0/0x22c returned 0 after 8 usecs [17932.910671] mtk-pcie 11230000.pcie: calling platform_pm_suspend+0x0/0x60 @ 22783, parent: soc [17932.910674] mtk-pcie 11230000.pcie: platform_pm_suspend+0x0/0x60 returned 0 after 0 usecs ... 17933.615352] x1 : 00000000000d4200 x0 : ffffff8269ca2300 [17933.620666] Call trace: [17933.623127] mt76_mmio_rr+0x28/0xf0 [mt76] [17933.627234] mt7921_rr+0x38/0x44 [mt7921e] [17933.631339] mt7921_irq_tasklet+0x54/0x1d8 [mt7921e] [17933.636309] tasklet_action_common+0x12c/0x16c [17933.640754] tasklet_action+0x24/0x2c [17933.644418] __do_softirq+0x16c/0x344 [17933.648082] irq_exit+0xa8/0xac [17933.651224] scheduler_ipi+0xd4/0x148 [17933.654890] handle_IPI+0x164/0x2d4 [17933.658379] gic_handle_irq+0x140/0x178 [17933.662216] el1_irq+0xb8/0x180 [17933.665361] cpuidle_enter_state+0xf8/0x204 [17933.669544] cpuidle_enter+0x38/0x4c [17933.673122] do_idle+0x1a4/0x2a8 [17933.676352] cpu_startup_entry+0x24/0x28 [17933.680276] rest_init+0xd4/0xe0 [17933.683508] arch_call_rest_init+0x10/0x18 [17933.687606] start_kernel+0x340/0x3b4 [17933.691279] Code: aa0003f5 d503201f f953eaa8 8b344108 (b9400113) [17933.697373] ---[ end trace a24b8e26ffbda3c5 ]--- [17933.767846] Kernel panic - not syncing: Fatal exception in interrupt En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mt76: mt7921: corrige un posible acceso no válido al registro. Deshabilite la interrupción y la sincronización de los controladores irq pendientes para garantizar que el tasklet irq no se programe después de la suspensión para evitar el posible acceso no válido al registro. actúa cuando el controlador pcie del host está suspendido. [17932.910534] mt7921e 0000:01:00.0: pci_pm_suspend+0x0/0x22c devolvió 0 después de 21375 usos [17932.910590] pcieport 0000:00:00.0: llamando a pci_pm_suspend+0x0/0x22c @ 18565, padre: pci0000:00 [17932.910602] pcieport 0000: 00:00.0: pci_pm_suspend+0x0/0x22c devolvió 0 después de 8 usos [17932.910671] mtk-pcie 11230000.pcie: llamando a platform_pm_suspend+0x0/0x60 @ 22783, padre: soc [17932.910674] mtk-pcie 11230 000.pcie: plataforma_pm_suspend+0x0/ 0x60 devolvió 0 después de 0 usos... 17933.615352] x1: 00000000000d4200 x0: ffffff8269ca2300 [17933.620666] Rastreo de llamadas: [17933.623127] mt76_mmio_rr+0x28/0xf0 [mt76] [1 7933.627234] mt7921_rr+0x38/0x44 [mt7921e] [17933.631339] mt7921_irq_tasklet+ 0x54/0x1d8 [mt7921e] [17933.636309] tasklet_action_common+0x12c/0x16c [17933.640754] tasklet_action+0x24/0x2c [17933.644418] __do_softirq+0x16c/0x344 [17933.648 082] irq_exit+0xa8/0xac [17933.651224] planificador_ipi+0xd4/0x148 [17933.654890] handle_IPI +0x164/0x2d4 [17933.658379] gic_handle_irq+0x140/0x178 [17933.662216] el1_irq+0xb8/0x180 [17933.665361] cpuidle_enter_state+0xf8/0x204 [17933.669544] c puidle_enter+0x38/0x4c [17933.673122] do_idle+0x1a4/0x2a8 [17933.676352] cpu_startup_entry+0x24 /0x28 [17933.680276] rest_init+0xd4/0xe0 [17933.683508] arch_call_rest_init+0x10/0x18 [17933.687606] start_kernel+0x340/0x3b4 [17933.691279] Código: aa0003f5 d5032 01f f953eaa8 8b344108 (b9400113) [17933.697373] ---[ final de seguimiento a24b8e26ffbda3c5 ]- -- [17933.767846] Pánico del kernel: no se sincroniza: excepción fatal en la interrupción • https://git.kernel.org/stable/c/ffa1bf97425bd511b105ce769976e20a845a71e9 https://git.kernel.org/stable/c/b13cbc536990ff609afa878b6211cd6f6265ba60 https://git.kernel.org/stable/c/fe3fccde8870764ba3e60610774bd7bc9f8faeff •