CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47550 – drm/amd/amdgpu: fix potential memleak
https://notcve.org/view.php?id=CVE-2021-47550
In the Linux kernel, the following vulnerability has been resolved: drm/amd/amdgpu: fix potential memleak In function amdgpu_get_xgmi_hive, when kobject_init_and_add failed There is a potential memleak if not call kobject_put. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amd/amdgpu: corrige una posible fuga de mem en la función amdgpu_get_xgmi_hive, cuando falla kobject_init_and_add Hay una posible fuga de mem si no se llama a kobject_put. • https://git.kernel.org/stable/c/c746945fb6bcbe3863c9ea6369c7ef376e38e5eb https://git.kernel.org/stable/c/75752ada77e0726327adf68018b9f50ae091baeb https://git.kernel.org/stable/c/27dfaedc0d321b4ea4e10c53e4679d6911ab17aa • CWE-401: Missing Release of Memory after Effective Lifetime •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47549 – sata_fsl: fix UAF in sata_fsl_port_stop when rmmod sata_fsl
https://notcve.org/view.php?id=CVE-2021-47549
In the Linux kernel, the following vulnerability has been resolved: sata_fsl: fix UAF in sata_fsl_port_stop when rmmod sata_fsl When the `rmmod sata_fsl.ko` command is executed in the PPC64 GNU/Linux, a bug is reported: ================================================================== BUG: Unable to handle kernel data access on read at 0x80000800805b502c Oops: Kernel access of bad area, sig: 11 [#1] NIP [c0000000000388a4] .ioread32+0x4/0x20 LR [80000000000c6034] .sata_fsl_port_stop+0x44/0xe0 [sata_fsl] Call Trace: .free_irq+0x1c/0x4e0 (unreliable) .ata_host_stop+0x74/0xd0 [libata] .release_nodes+0x330/0x3f0 .device_release_driver_internal+0x178/0x2c0 .driver_detach+0x64/0xd0 .bus_remove_driver+0x70/0xf0 .driver_unregister+0x38/0x80 .platform_driver_unregister+0x14/0x30 .fsl_sata_driver_exit+0x18/0xa20 [sata_fsl] .__se_sys_delete_module+0x1ec/0x2d0 .system_call_exception+0xfc/0x1f0 system_call_common+0xf8/0x200 ================================================================== The triggering of the BUG is shown in the following stack: driver_detach device_release_driver_internal __device_release_driver drv->remove(dev) --> platform_drv_remove/platform_remove drv->remove(dev) --> sata_fsl_remove iounmap(host_priv->hcr_base); <---- unmap kfree(host_priv); <---- free devres_release_all release_nodes dr->node.release(dev, dr->data) --> ata_host_stop ap->ops->port_stop(ap) --> sata_fsl_port_stop ioread32(hcr_base + HCONTROL) <---- UAF host->ops->host_stop(host) The iounmap(host_priv->hcr_base) and kfree(host_priv) functions should not be executed in drv->remove. These functions should be executed in host_stop after port_stop. Therefore, we move these functions to the new function sata_fsl_host_stop and bind the new function to host_stop. En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: sata_fsl: corrige UAF en sata_fsl_port_stop cuando rmmod sata_fsl Cuando se ejecuta el comando `rmmod sata_fsl.ko` en el PPC64 GNU/Linux se reporta un error: ====== ==================================================== ========== ERROR: No se puede manejar el acceso a los datos del kernel al leer en 0x80000800805b502c Ups: Acceso al kernel del área defectuosa, firma: 11 [#1] NIP [c0000000000388a4] .ioread32+0x4/0x20 LR [80000000000c6034 ] .sata_fsl_port_stop+0x44/0xe0 [sata_fsl] Seguimiento de llamadas: .free_irq+0x1c/0x4e0 (no confiable) .ata_host_stop+0x74/0xd0 [libata] .release_nodes+0x330/0x3f0 .device_release_driver_internal+0x178/0x2c0. driver_detach+0x64/0xd0 . bus_remove_driver+0x70/0xf0 .driver_unregister+0x38/0x80 .platform_driver_unregister+0x14/0x30 .fsl_sata_driver_exit+0x18/0xa20 [sata_fsl] . • https://git.kernel.org/stable/c/faf0b2e5afe7dae072d2715763c7f992b612b628 https://git.kernel.org/stable/c/cdcd80292106df5cda325426e96495503e41f947 https://git.kernel.org/stable/c/91ba94d3f7afca195b224f77a72044fbde1389ce https://git.kernel.org/stable/c/325ea49fc43cbc03a5e1e37de8f0ca6357ced4b1 https://git.kernel.org/stable/c/0769449b0a5eabc3545337217ae690e46673e73a https://git.kernel.org/stable/c/77393806c76b6b44f1c44bd957788c8bd9152c45 https://git.kernel.org/stable/c/4a46b2f5dce02539e88a300800812bd24a45e097 https://git.kernel.org/stable/c/adf098e2a8a1e1fc075d6a5ba2edd13cf •
CVSS: 9.8EPSS: 0%CPEs: 7EXPL: 0CVE-2021-47548 – ethernet: hisilicon: hns: hns_dsaf_misc: fix a possible array overflow in hns_dsaf_ge_srst_by_port()
https://notcve.org/view.php?id=CVE-2021-47548
In the Linux kernel, the following vulnerability has been resolved: ethernet: hisilicon: hns: hns_dsaf_misc: fix a possible array overflow in hns_dsaf_ge_srst_by_port() The if statement: if (port >= DSAF_GE_NUM) return; limits the value of port less than DSAF_GE_NUM (i.e., 8). However, if the value of port is 6 or 7, an array overflow could occur: port_rst_off = dsaf_dev->mac_cb[port]->port_rst_off; because the length of dsaf_dev->mac_cb is DSAF_MAX_PORT_NUM (i.e., 6). To fix this possible array overflow, we first check port and if it is greater than or equal to DSAF_MAX_PORT_NUM, the function returns. En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: ethernet: hisilicon: hns: hns_dsaf_misc: corrige un posible desbordamiento de matriz en hns_dsaf_ge_srst_by_port() La sentencia if: if (port >= DSAF_GE_NUM) return; limita el valor del puerto a menos de DSAF_GE_NUM (es decir, 8). Sin embargo, si el valor del puerto es 6 o 7, podría producirse un desbordamiento de la matriz: port_rst_off = dsaf_dev->mac_cb[port]->port_rst_off; porque la longitud de dsaf_dev->mac_cb es DSAF_MAX_PORT_NUM (es decir, 6). Para solucionar este posible desbordamiento de la matriz, primero verificamos el puerto y si es mayor o igual a DSAF_MAX_PORT_NUM, la función regresa. • https://git.kernel.org/stable/c/948968f8747650447c8f21c9fdba0e1973be040b https://git.kernel.org/stable/c/abbd5faa0748d0aa95d5191d56ff7a17a6275bd1 https://git.kernel.org/stable/c/dd07f8971b81ad98cc754b179b331b57f35aa1ff https://git.kernel.org/stable/c/99bb25cb6753beaf2c2bc37927c2ecc0ceff3f6d https://git.kernel.org/stable/c/22519eff7df2d88adcc2568d86046ce1e2b52803 https://git.kernel.org/stable/c/fc7ffa7f10b9454a86369405d9814bf141b30627 https://git.kernel.org/stable/c/a66998e0fbf213d47d02813b9679426129d0d114 https://access.redhat.com/security/cve/CVE-2021-47548 • CWE-129: Improper Validation of Array Index •
CVSS: 4.4EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47547 – net: tulip: de4x5: fix the problem that the array 'lp->phy[8]' may be out of bound
https://notcve.org/view.php?id=CVE-2021-47547
In the Linux kernel, the following vulnerability has been resolved: net: tulip: de4x5: fix the problem that the array 'lp->phy[8]' may be out of bound In line 5001, if all id in the array 'lp->phy[8]' is not 0, when the 'for' end, the 'k' is 8. At this time, the array 'lp->phy[8]' may be out of bound. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: tulip: de4x5: soluciona el problema de que la matriz 'lp->phy[8]' puede estar fuera de límites En la línea 5001, si todos los ID de la matriz 'lp ->phy[8]' no es 0, cuando termina 'for', 'k' es 8. En este momento, la matriz 'lp->phy[8]' puede estar fuera de límite. • https://git.kernel.org/stable/c/ec5bd0aef1cec96830d0c7e06d3597d9e786cc98 https://git.kernel.org/stable/c/142ead3dc70411bd5977e8c47a6d8bf22287b3f8 https://git.kernel.org/stable/c/d3dedaa5a601107cfedda087209772c76e364d58 https://git.kernel.org/stable/c/2c1a6a9a011d622a7c61324a97a49801ba425eff https://git.kernel.org/stable/c/77ff166909458646e66450e42909e0adacc99049 https://git.kernel.org/stable/c/f059fa40f0fcc6bc7a12e0f2a2504e9a4ff74f1f https://git.kernel.org/stable/c/12f907cb11576b8cd0b1d95a16d1f10ed5bb7237 https://git.kernel.org/stable/c/61217be886b5f7402843677e4be7e7e83 •
CVSS: 6.3EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47544 – tcp: fix page frag corruption on page fault
https://notcve.org/view.php?id=CVE-2021-47544
In the Linux kernel, the following vulnerability has been resolved: tcp: fix page frag corruption on page fault Steffen reported a TCP stream corruption for HTTP requests served by the apache web-server using a cifs mount-point and memory mapping the relevant file. The root cause is quite similar to the one addressed by commit 20eb4f29b602 ("net: fix sk_page_frag() recursion from memory reclaim"). Here the nested access to the task page frag is caused by a page fault on the (mmapped) user-space memory buffer coming from the cifs file. The page fault handler performs an smb transaction on a different socket, inside the same process context. Since sk->sk_allaction for such socket does not prevent the usage for the task_frag, the nested allocation modify "under the hood" the page frag in use by the outer sendmsg call, corrupting the stream. The overall relevant stack trace looks like the following: httpd 78268 [001] 3461630.850950: probe:tcp_sendmsg_locked: ffffffff91461d91 tcp_sendmsg_locked+0x1 ffffffff91462b57 tcp_sendmsg+0x27 ffffffff9139814e sock_sendmsg+0x3e ffffffffc06dfe1d smb_send_kvec+0x28 [...] ffffffffc06cfaf8 cifs_readpages+0x213 ffffffff90e83c4b read_pages+0x6b ffffffff90e83f31 __do_page_cache_readahead+0x1c1 ffffffff90e79e98 filemap_fault+0x788 ffffffff90eb0458 __do_fault+0x38 ffffffff90eb5280 do_fault+0x1a0 ffffffff90eb7c84 __handle_mm_fault+0x4d4 ffffffff90eb8093 handle_mm_fault+0xc3 ffffffff90c74f6d __do_page_fault+0x1ed ffffffff90c75277 do_page_fault+0x37 ffffffff9160111e page_fault+0x1e ffffffff9109e7b5 copyin+0x25 ffffffff9109eb40 _copy_from_iter_full+0xe0 ffffffff91462370 tcp_sendmsg_locked+0x5e0 ffffffff91462370 tcp_sendmsg_locked+0x5e0 ffffffff91462b57 tcp_sendmsg+0x27 ffffffff9139815c sock_sendmsg+0x4c ffffffff913981f7 sock_write_iter+0x97 ffffffff90f2cc56 do_iter_readv_writev+0x156 ffffffff90f2dff0 do_iter_write+0x80 ffffffff90f2e1c3 vfs_writev+0xa3 ffffffff90f2e27c do_writev+0x5c ffffffff90c042bb do_syscall_64+0x5b ffffffff916000ad entry_SYSCALL_64_after_hwframe+0x65 The cifs filesystem rightfully sets sk_allocations to GFP_NOFS, we can avoid the nesting using the sk page frag for allocation lacking the __GFP_FS flag. Do not define an additional mm-helper for that, as this is strictly tied to the sk page frag usage. v1 -> v2: - use a stricted sk_page_frag() check instead of reordering the code (Eric) En el kernel de Linux, se resolvió la siguiente vulnerabilidad: tcp: corregir corrupción de fragmentos de página en falla de página Steffen informó una corrupción de flujo TCP para solicitudes HTTP atendidas por el servidor web Apache usando un punto de montaje cifs y mapeando la memoria del archivo relevante. La causa raíz es bastante similar a la abordada por el commit 20eb4f29b602 ("net: fix sk_page_frag() recursividad desde la recuperación de memoria"). • https://git.kernel.org/stable/c/5640f7685831e088fe6c2e1f863a6805962f8e81 https://git.kernel.org/stable/c/c6f340a331fb72e5ac23a083de9c780e132ca3ae https://git.kernel.org/stable/c/5a9afcd827cafe14a95c9fcbded2c2d104f18dfc https://git.kernel.org/stable/c/dacb5d8875cc6cd3a553363b4d6f06760fcbe70c https://access.redhat.com/security/cve/CVE-2021-47544 https://bugzilla.redhat.com/show_bug.cgi?id=2283406 • CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer •