CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47026 – RDMA/rtrs-clt: destroy sysfs after removing session from active list
https://notcve.org/view.php?id=CVE-2021-47026
In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-clt: destroy sysfs after removing session from active list A session can be removed dynamically by sysfs interface "remove_path" that eventually calls rtrs_clt_remove_path_from_sysfs function. The current rtrs_clt_remove_path_from_sysfs first removes the sysfs interfaces and frees sess->stats object. Second it removes the session from the active list. Therefore some functions could access non-connected session and access the freed sess->stats object even-if they check the session status before accessing the session. For instance rtrs_clt_request and get_next_path_min_inflight check the session status and try to send IO to the session. The session status could be changed when they are trying to send IO but they could not catch the change and update the statistics information in sess->stats object, and generate use-after-free problem. (see: "RDMA/rtrs-clt: Check state of the rtrs_clt_sess before reading its stats") This patch changes the rtrs_clt_remove_path_from_sysfs to remove the session from the active session list and then destroy the sysfs interfaces. Each function still should check the session status because closing or error recovery paths can change the status. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/rtrs-clt: destruye sysfs después de eliminar la sesión de la lista activa Una sesión se puede eliminar dinámicamente mediante la interfaz sysfs "remove_path" que eventualmente llama a la función rtrs_clt_remove_path_from_sysfs. • https://git.kernel.org/stable/c/6a98d71daea186247005099758af549e6afdd244 https://git.kernel.org/stable/c/b64415c6b3476cf9fa4d0aea3807065b8403a937 https://git.kernel.org/stable/c/676171f9405dcaa45a33d18241c32f387dbaae39 https://git.kernel.org/stable/c/d3cca8067d43dfee4a3535c645b55f618708dccb https://git.kernel.org/stable/c/7f4a8592ff29f19c5a2ca549d0973821319afaad •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47025 – iommu/mediatek: Always enable the clk on resume
https://notcve.org/view.php?id=CVE-2021-47025
In the Linux kernel, the following vulnerability has been resolved: iommu/mediatek: Always enable the clk on resume In mtk_iommu_runtime_resume always enable the clk, even if m4u_dom is null. Otherwise the 'suspend' cb might disable the clk which is already disabled causing the warning: [ 1.586104] infra_m4u already disabled [ 1.586133] WARNING: CPU: 0 PID: 121 at drivers/clk/clk.c:952 clk_core_disable+0xb0/0xb8 [ 1.594391] mtk-iommu 10205000.iommu: bound 18001000.larb (ops mtk_smi_larb_component_ops) [ 1.598108] Modules linked in: [ 1.598114] CPU: 0 PID: 121 Comm: kworker/0:2 Not tainted 5.12.0-rc5 #69 [ 1.609246] mtk-iommu 10205000.iommu: bound 14027000.larb (ops mtk_smi_larb_component_ops) [ 1.617487] Hardware name: Google Elm (DT) [ 1.617491] Workqueue: pm pm_runtime_work [ 1.620545] mtk-iommu 10205000.iommu: bound 19001000.larb (ops mtk_smi_larb_component_ops) [ 1.627229] pstate: 60000085 (nZCv daIf -PAN -UAO -TCO BTYPE=--) [ 1.659297] pc : clk_core_disable+0xb0/0xb8 [ 1.663475] lr : clk_core_disable+0xb0/0xb8 [ 1.667652] sp : ffff800011b9bbe0 [ 1.670959] x29: ffff800011b9bbe0 x28: 0000000000000000 [ 1.676267] x27: ffff800011448000 x26: ffff8000100cfd98 [ 1.681574] x25: ffff800011b9bd48 x24: 0000000000000000 [ 1.686882] x23: 0000000000000000 x22: ffff8000106fad90 [ 1.692189] x21: 000000000000000a x20: ffff0000c0048500 [ 1.697496] x19: ffff0000c0048500 x18: ffffffffffffffff [ 1.702804] x17: 0000000000000000 x16: 0000000000000000 [ 1.708112] x15: ffff800011460300 x14: fffffffffffe0000 [ 1.713420] x13: ffff8000114602d8 x12: 0720072007200720 [ 1.718727] x11: 0720072007200720 x10: 0720072007200720 [ 1.724035] x9 : ffff800011b9bbe0 x8 : ffff800011b9bbe0 [ 1.729342] x7 : 0000000000000009 x6 : ffff8000114b8328 [ 1.734649] x5 : 0000000000000000 x4 : 0000000000000000 [ 1.739956] x3 : 00000000ffffffff x2 : ffff800011460298 [ 1.745263] x1 : 1af1d7de276f4500 x0 : 0000000000000000 [ 1.750572] Call trace: [ 1.753010] clk_core_disable+0xb0/0xb8 [ 1.756840] clk_core_disable_lock+0x24/0x40 [ 1.761105] clk_disable+0x20/0x30 [ 1.764501] mtk_iommu_runtime_suspend+0x88/0xa8 [ 1.769114] pm_generic_runtime_suspend+0x2c/0x48 [ 1.773815] __rpm_callback+0xe0/0x178 [ 1.777559] rpm_callback+0x24/0x88 [ 1.781041] rpm_suspend+0xdc/0x470 [ 1.784523] rpm_idle+0x12c/0x170 [ 1.787831] pm_runtime_work+0xa8/0xc0 [ 1.791573] process_one_work+0x1e8/0x360 [ 1.795580] worker_thread+0x44/0x478 [ 1.799237] kthread+0x150/0x158 [ 1.802460] ret_from_fork+0x10/0x30 [ 1.806034] ---[ end trace 82402920ef64573b ]--- [ 1.810728] ------------[ cut here ]------------ In addition, we now don't need to enable the clock from the function mtk_iommu_hw_init since it is already enabled by the resume. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu/mediatek: habilite siempre clk al reanudar. En mtk_iommu_runtime_resume habilite siempre clk, incluso si m4u_dom es nulo. De lo contrario, el cb 'suspender' podría desactivar el clk que ya está desactivado provocando la advertencia: [1.586104] infra_m4u ya desactivado [1.586133] ADVERTENCIA: CPU: 0 PID: 121 en drivers/clk/clk.c:952 clk_core_disable+0xb0/0xb8 [ 1.594391] mtk-iommu 10205000.iommu: enlazado 18001000.larb (ops mtk_smi_larb_component_ops) [ 1.598108] Módulos vinculados en: [ 1.598114] CPU: 0 PID: 121 Comm: kworker/0:2 No contaminado 5.12.0 -rc5 #69 [ 1.609246] mtk-iommu 10205000.iommu: enlazado 14027000.larb (ops mtk_smi_larb_component_ops) [ 1.617487] Nombre del hardware: Google Elm (DT) [ 1.617491] Cola de trabajo: pm pm_runtime_work [ 1.620545] mtk-iomm u 10205000.iommu: encuadernado 19001000.larb (ops mtk_smi_larb_component_ops) [1.627229] pstate: 60000085 (nZCv daIf -PAN -UAO -TCO BTYPE=--) [1.659297] pc: clk_core_disable+0xb0/0xb8 [1.663475] lr: clk_core_disable+0xb0/0x b8 [1.667652] sp: ffff800011b9bbe0 [ 1.670959] x29: ffff800011b9bbe0 x28: 0000000000000000 [ 1.676267] x27: ffff800011448000 x26: ffff8000100cfd98 [ 1.681574] x25: ffff800011b9 bd48 x24: 0000000000000000 [ 1.686882] x23: 0000000000000000 x22: ffff8000106fad90 [ 1.692189] x21: 0000000000000000a x20: ffff0000c004850 0 [1,697496] x19: ffff0000c0048500 x18: ffffffffffffffff [ 1.702804] x17: 0000000000000000 x16: 00000000000000000 [ 1.708112] x15: ffff800011460300 x14: ffffffffffe000 0 [ 1.713420] x13: ffff8000114602d8 x12: 0720072007200720 [ 1.718727] x11: 0720072007200720 x10: 0720072007200720 [ 1.724035] x9 : ffff800 011b9bbe0 x8: ffff800011b9bbe0 [ 1.729342] x7: 0000000000000009 x6: ffff8000114b8328 [1.734649] x5: 0000000000000000 x4: 00000000000000000 [1.739956] x3: 00000000ffff ffff x2: ffff800011460298 [1.745263] x1: 1af1d7de276f4500 x0: 0000000000000000 [1.750572] Rastreo de llamadas: [1.753010] clk_core_disable+0xb0/0xb8 [ 1.756840] clk_core_disable_lock+0x24/0x40 [ 1.761105] clk_disable+0x20/0x30 [ 1.764501] mtk_iommu_runtime_suspend+0x88/0xa8 [ 1.769114] pm_generic_runtime_suspend+0x2c/0x48 [ 1 .773815] __rpm_callback+0xe0/0x178 [ 1.777559] rpm_callback+0x24/0x88 [ 1.781041] rpm_suspend+0xdc/0x470 [ 1.784523] rpm_idle+0x12c/0x170 [ 1.787831] pm_runtime_work+0xa8/0xc0 [ 1.791573] Process_one_work+0x1e8/0x360 [ 1.795580] trabajador_thread+0x44/0x478 [ 1.799237] kthread+0x150/0x158 [ 1.802460] ret_from_fork+ 0x10/0x30 [1.806034] ---[ final de seguimiento 82402920ef64573b ]--- [ 1.810728] ------------[ cortar aquí ]------------ Además , ahora no necesitamos habilitar el reloj desde la función mtk_iommu_hw_init ya que ya está habilitado en el currículum. • https://git.kernel.org/stable/c/c0b57581b73be7b43f39e0dff201c93413f6a668 https://git.kernel.org/stable/c/5cad9e2caa9613fdcd246bd4ebf0ffbec1cba2ca https://git.kernel.org/stable/c/b34ea31fe013569d42b7e8681ef3f717f77c5b72 •
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 •