CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47416 – phy: mdio: fix memory leak
https://notcve.org/view.php?id=CVE-2021-47416
In the Linux kernel, the following vulnerability has been resolved: phy: mdio: fix memory leak Syzbot reported memory leak in MDIO bus interface, the problem was in wrong state logic. MDIOBUS_ALLOCATED indicates 2 states: 1. Bus is only allocated 2. Bus allocated and __mdiobus_register() fails, but device_register() was called In case of device_register() has been called we should call put_device() to correctly free the memory allocated for this device, but mdiobus_free() calls just kfree(dev) in case of MDIOBUS_ALLOCATED state To avoid this behaviour we need to set bus->state to MDIOBUS_UNREGISTERED _before_ calling device_register(), because put_device() should be called even in case of device_register() failure. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: phy: mdio: arreglar pérdida de memoria. Syzbot informó una pérdida de memoria en la interfaz del bus MDIO, el problema estaba en una lógica de estado incorrecta. • https://git.kernel.org/stable/c/46abc02175b3c246dd5141d878f565a8725060c9 https://git.kernel.org/stable/c/25e9f88c7e3cc35f5e3d3db199660d28a15df639 https://git.kernel.org/stable/c/2250392d930bd0d989f24d355d6355b0150256e7 https://git.kernel.org/stable/c/f4f502a04ee1e543825af78f47eb7785015cd9f6 https://git.kernel.org/stable/c/2397b9e118721292429fea8807a698e71b94795f https://git.kernel.org/stable/c/414bb4ead1362ef2c8592db723c017258f213988 https://git.kernel.org/stable/c/0d2dd40a7be61b89a7c99dae8ee96389d27b413a https://git.kernel.org/stable/c/064c2616234a7394867c924b5c1303974 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47414 – riscv: Flush current cpu icache before other cpus
https://notcve.org/view.php?id=CVE-2021-47414
In the Linux kernel, the following vulnerability has been resolved: riscv: Flush current cpu icache before other cpus On SiFive Unmatched, I recently fell onto the following BUG when booting: [ 0.000000] ftrace: allocating 36610 entries in 144 pages [ 0.000000] Oops - illegal instruction [#1] [ 0.000000] Modules linked in: [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.13.1+ #5 [ 0.000000] Hardware name: SiFive HiFive Unmatched A00 (DT) [ 0.000000] epc : riscv_cpuid_to_hartid_mask+0x6/0xae [ 0.000000] ra : __sbi_rfence_v02+0xc8/0x10a [ 0.000000] epc : ffffffff80007240 ra : ffffffff80009964 sp : ffffffff81803e10 [ 0.000000] gp : ffffffff81a1ea70 tp : ffffffff8180f500 t0 : ffffffe07fe30000 [ 0.000000] t1 : 0000000000000004 t2 : 0000000000000000 s0 : ffffffff81803e60 [ 0.000000] s1 : 0000000000000000 a0 : ffffffff81a22238 a1 : ffffffff81803e10 [ 0.000000] a2 : 0000000000000000 a3 : 0000000000000000 a4 : 0000000000000000 [ 0.000000] a5 : 0000000000000000 a6 : ffffffff8000989c a7 : 0000000052464e43 [ 0.000000] s2 : ffffffff81a220c8 s3 : 0000000000000000 s4 : 0000000000000000 [ 0.000000] s5 : 0000000000000000 s6 : 0000000200000100 s7 : 0000000000000001 [ 0.000000] s8 : ffffffe07fe04040 s9 : ffffffff81a22c80 s10: 0000000000001000 [ 0.000000] s11: 0000000000000004 t3 : 0000000000000001 t4 : 0000000000000008 [ 0.000000] t5 : ffffffcf04000808 t6 : ffffffe3ffddf188 [ 0.000000] status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000002 [ 0.000000] [<ffffffff80007240>] riscv_cpuid_to_hartid_mask+0x6/0xae [ 0.000000] [<ffffffff80009474>] sbi_remote_fence_i+0x1e/0x26 [ 0.000000] [<ffffffff8000b8f4>] flush_icache_all+0x12/0x1a [ 0.000000] [<ffffffff8000666c>] patch_text_nosync+0x26/0x32 [ 0.000000] [<ffffffff8000884e>] ftrace_init_nop+0x52/0x8c [ 0.000000] [<ffffffff800f051e>] ftrace_process_locs.isra.0+0x29c/0x360 [ 0.000000] [<ffffffff80a0e3c6>] ftrace_init+0x80/0x130 [ 0.000000] [<ffffffff80a00f8c>] start_kernel+0x5c4/0x8f6 [ 0.000000] ---[ end trace f67eb9af4d8d492b ]--- [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task! [ 0.000000] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]--- While ftrace is looping over a list of addresses to patch, it always failed when patching the same function: riscv_cpuid_to_hartid_mask. Looking at the backtrace, the illegal instruction is encountered in this same function. However, patch_text_nosync, after patching the instructions, calls flush_icache_range. But looking at what happens in this function: flush_icache_range -> flush_icache_all -> sbi_remote_fence_i -> __sbi_rfence_v02 -> riscv_cpuid_to_hartid_mask The icache and dcache of the current cpu are never synchronized between the patching of riscv_cpuid_to_hartid_mask and calling this same function. So fix this by flushing the current cpu's icache before asking for the other cpus to do the same. • https://git.kernel.org/stable/c/fab957c11efe2f405e08b9f0d080524bc2631428 https://git.kernel.org/stable/c/427faa29e06f0709476ea1bd59758f997ec8b64e https://git.kernel.org/stable/c/f1c7aa87c423e765e3862349c2f095fdfccdd9b3 https://git.kernel.org/stable/c/bb8958d5dc79acbd071397abb57b8756375fe1ce •
CVSS: 4.7EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47412 – block: don't call rq_qos_ops->done_bio if the bio isn't tracked
https://notcve.org/view.php?id=CVE-2021-47412
In the Linux kernel, the following vulnerability has been resolved: block: don't call rq_qos_ops->done_bio if the bio isn't tracked rq_qos framework is only applied on request based driver, so: 1) rq_qos_done_bio() needn't to be called for bio based driver 2) rq_qos_done_bio() needn't to be called for bio which isn't tracked, such as bios ended from error handling code. Especially in bio_endio(): 1) request queue is referred via bio->bi_bdev->bd_disk->queue, which may be gone since request queue refcount may not be held in above two cases 2) q->rq_qos may be freed in blk_cleanup_queue() when calling into __rq_qos_done_bio() Fix the potential kernel panic by not calling rq_qos_ops->done_bio if the bio isn't tracked. This way is safe because both ioc_rqos_done_bio() and blkcg_iolatency_done_bio() are nop if the bio isn't tracked. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bloque: no llame a rq_qos_ops->done_bio si no se realiza un seguimiento de la biografía. El framework rq_qos solo se aplica en el controlador basado en solicitudes, por lo que: 1) rq_qos_done_bio() no necesita hacerlo ser llamado para un controlador basado en biografía 2) No es necesario llamar a rq_qos_done_bio() para una biografía que no está rastreada, como una biografía terminada por un código de manejo de errores. Especialmente en bio_endio(): 1) la cola de solicitudes se remite a través de bio->bi_bdev->bd_disk->queue, que puede desaparecer ya que el recuento de la cola de solicitudes no se puede mantener en los dos casos anteriores 2) q->rq_qos se puede liberar en blk_cleanup_queue() al llamar a __rq_qos_done_bio() Solucione el posible pánico del kernel al no llamar a rq_qos_ops->done_bio si no se realiza un seguimiento de la biografía. • https://git.kernel.org/stable/c/004b8f8a691205a93d9e80d98b786b2b97424d6e https://git.kernel.org/stable/c/a647a524a46736786c95cdb553a070322ca096e3 https://access.redhat.com/security/cve/CVE-2021-47412 https://bugzilla.redhat.com/show_bug.cgi?id=2282324 • CWE-388: 7PK - Errors •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47410 – drm/amdkfd: fix svm_migrate_fini warning
https://notcve.org/view.php?id=CVE-2021-47410
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix svm_migrate_fini warning Device manager releases device-specific resources when a driver disconnects from a device, devm_memunmap_pages and devm_release_mem_region calls in svm_migrate_fini are redundant. It causes below warning trace after patch "drm/amdgpu: Split amdgpu_device_fini into early and late", so remove function svm_migrate_fini. BUG: https://gitlab.freedesktop.org/drm/amd/-/issues/1718 WARNING: CPU: 1 PID: 3646 at drivers/base/devres.c:795 devm_release_action+0x51/0x60 Call Trace: ? memunmap_pages+0x360/0x360 svm_migrate_fini+0x2d/0x60 [amdgpu] kgd2kfd_device_exit+0x23/0xa0 [amdgpu] amdgpu_amdkfd_device_fini_sw+0x1d/0x30 [amdgpu] amdgpu_device_fini_sw+0x45/0x290 [amdgpu] amdgpu_driver_release_kms+0x12/0x30 [amdgpu] drm_dev_release+0x20/0x40 [drm] release_nodes+0x196/0x1e0 device_release_driver_internal+0x104/0x1d0 driver_detach+0x47/0x90 bus_remove_driver+0x7a/0xd0 pci_unregister_driver+0x3d/0x90 amdgpu_exit+0x11/0x20 [amdgpu] En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amdkfd: corrige la advertencia de svm_migrate_fini. El administrador de dispositivos libera recursos específicos del dispositivo cuando un controlador se desconecta de un dispositivo, las llamadas a devm_memunmap_pages y devm_release_mem_region en svm_migrate_fini son redundantes. Provoca el siguiente seguimiento de advertencia después del parche "drm/amdgpu: dividir amdgpu_device_fini en temprano y tarde", por lo tanto, elimine la función svm_migrate_fini. ERROR: https://gitlab.freedesktop.org/drm/amd/-/issues/1718 ADVERTENCIA: CPU: 1 PID: 3646 en drivers/base/devres.c:795 devm_release_action+0x51/0x60 Seguimiento de llamadas:? • https://git.kernel.org/stable/c/ac7d732b24f4061f8a732ada49b054ab38c63e15 https://git.kernel.org/stable/c/197ae17722e989942b36e33e044787877f158574 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2021-47409 – usb: dwc2: check return value after calling platform_get_resource()
https://notcve.org/view.php?id=CVE-2021-47409
In the Linux kernel, the following vulnerability has been resolved: usb: dwc2: check return value after calling platform_get_resource() It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: usb: dwc2: verifique el valor de retorno después de llamar a platform_get_resource(). Causará null-ptr-deref si platform_get_resource() devuelve NULL, necesitamos verificar el valor de retorno. • https://git.kernel.org/stable/c/4b7f4a0eb92bf37bea4cd838c7f83ea42823ca8b https://git.kernel.org/stable/c/a7182993dd8e09f96839ddc3ac54f9b37370d282 https://git.kernel.org/stable/c/8b9c1c33e51d0959f2aec573dfbac0ffd3f5c0b7 https://git.kernel.org/stable/c/2754fa3b73df7d0ae042f3ed6cfd9df9042f6262 https://git.kernel.org/stable/c/337f00a0bc62d7cb7d10ec0b872c79009a1641df https://git.kernel.org/stable/c/856e6e8e0f9300befa87dde09edb578555c99a82 •