CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47566 – proc/vmcore: fix clearing user buffer by properly using clear_user()
https://notcve.org/view.php?id=CVE-2021-47566
In the Linux kernel, the following vulnerability has been resolved: proc/vmcore: fix clearing user buffer by properly using clear_user() To clear a user buffer we cannot simply use memset, we have to use clear_user(). With a virtio-mem device that registers a vmcore_cb and has some logically unplugged memory inside an added Linux memory block, I can easily trigger a BUG by copying the vmcore via "cp": systemd[1]: Starting Kdump Vmcore Save Service... kdump[420]: Kdump is using the default log level(3). kdump[453]: saving to /sysroot/var/crash/127.0.0.1-2021-11-11-14:59:22/ kdump[458]: saving vmcore-dmesg.txt to /sysroot/var/crash/127.0.0.1-2021-11-11-14:59:22/ kdump[465]: saving vmcore-dmesg.txt complete kdump[467]: saving vmcore BUG: unable to handle page fault for address: 00007f2374e01000 #PF: supervisor write access in kernel mode #PF: error_code(0x0003) - permissions violation PGD 7a523067 P4D 7a523067 PUD 7a528067 PMD 7a525067 PTE 800000007048f867 Oops: 0003 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 468 Comm: cp Not tainted 5.15.0+ #6 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.14.0-27-g64f37cc530f1-prebuilt.qemu.org 04/01/2014 RIP: 0010:read_from_oldmem.part.0.cold+0x1d/0x86 Code: ff ff ff e8 05 ff fe ff e9 b9 e9 7f ff 48 89 de 48 c7 c7 38 3b 60 82 e8 f1 fe fe ff 83 fd 08 72 3c 49 8d 7d 08 4c 89 e9 89 e8 <49> c7 45 00 00 00 00 00 49 c7 44 05 f8 00 00 00 00 48 83 e7 f81 RSP: 0018:ffffc9000073be08 EFLAGS: 00010212 RAX: 0000000000001000 RBX: 00000000002fd000 RCX: 00007f2374e01000 RDX: 0000000000000001 RSI: 00000000ffffdfff RDI: 00007f2374e01008 RBP: 0000000000001000 R08: 0000000000000000 R09: ffffc9000073bc50 R10: ffffc9000073bc48 R11: ffffffff829461a8 R12: 000000000000f000 R13: 00007f2374e01000 R14: 0000000000000000 R15: ffff88807bd421e8 FS: 00007f2374e12140(0000) GS:ffff88807f000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2374e01000 CR3: 000000007a4aa000 CR4: 0000000000350eb0 Call Trace: read_vmcore+0x236/0x2c0 proc_reg_read+0x55/0xa0 vfs_read+0x95/0x190 ksys_read+0x4f/0xc0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae Some x86-64 CPUs have a CPU feature called "Supervisor Mode Access Prevention (SMAP)", which is used to detect wrong access from the kernel to user buffers like this: SMAP triggers a permissions violation on wrong access. In the x86-64 variant of clear_user(), SMAP is properly handled via clac()+stac(). To fix, properly use clear_user() when we're dealing with a user buffer. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: proc/vmcore: corrige el borrado del búfer del usuario usando correctamente clear_user() Para borrar un búfer de usuario no podemos simplemente usar memset, tenemos que usar clear_user(). Con un dispositivo virtio-mem que registra un vmcore_cb y tiene algo de memoria lógicamente desconectada dentro de un bloque de memoria de Linux agregado, puedo desencadenar fácilmente un ERROR copiando el vmcore a través de "cp": systemd[1]: Iniciando el servicio Kdump Vmcore Save. . kdump[420]: Kdump está utilizando el nivel de registro predeterminado (3). kdump[453]: guardar en /sysroot/var/crash/127.0.0.1-2021-11-11-14:59:22/ kdump[458]: guardar vmcore-dmesg.txt en /sysroot/var/crash/127.0 .0.1-2021-11-11-14:59:22/ kdump[465]: guardar vmcore-dmesg.txt completo kdump[467]: guardar vmcore ERROR: no se puede manejar el error de página para la dirección: 00007f2374e01000 #PF: escritura del supervisor acceso en modo kernel #PF: error_code(0x0003) - violación de permisos PGD 7a523067 P4D 7a523067 PUD 7a528067 PMD 7a525067 PTE 800000007048f867 Ups: 0003 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 468 Comm: p No contaminado 5.15.0+ # 6 Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS rel-1.14.0-27-g64f37cc530f1-prebuilt.qemu.org 01/04/2014 RIP: 0010:read_from_oldmem.part.0.cold+0x1d/ 0x86 Código: ff ff ff e8 05 ff fe ff e9 b9 e9 7f ff 48 89 de 48 c7 c7 38 3b 60 82 e8 f1 fe fe ff 83 fd 08 72 3c 49 8d 7d 08 4c 89 e9 89 e8 <49> c7 45 00 00 00 00 00 49 C7 44 05 F8 00 00 00 00 48 83 E7 F81 RSP: 0018: FFFFFC9000073BE08 EFLAGS: 00010212 RAX: 00000000000000001000 RBX: 000000002FD000 RCX: 00007F2374E RSI: 000000000000FFFFDFFF RDI: 00007F2374E01008 RBP: 000000000000001000 R08: 0000000000000000 R09: ffffc9000073bc50 R10: ffffc9000073bc48 R11: ffffffff829461a8 R12: 000000000000f000 R13: 00007f2374e01000 R14: 0000000000000000 R15: 88807bd421e8 FS: 00007f2374e12140(0000) GS:ffff88807f000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2 : 00007f2374e01000 CR3: 000000007a4aa000 CR4: 0000000000350eb0 Seguimiento de llamadas: read_vmcore+0x236/0x2c0 proc_reg_read+0x55/0xa0 vfs_read+0x95/0x190 do_syscall_64+0x3b/0x90 Entry_SYSCALL_64_after_hwframe+0x44/0xae Algunas CPU x86-64 tienen una función de CPU llamada "Prevención de acceso en modo supervisor (SMAP)", que se utiliza para detectar accesos incorrectos desde el kernel a los búferes de usuario como este: SMAP desencadena una violación de permisos en caso de acceso incorrecto. • https://git.kernel.org/stable/c/997c136f518c5debd63847e78e2a8694f56dcf90 https://git.kernel.org/stable/c/a9e164bd160be8cbee1df70acb379129e3cd2e7c https://git.kernel.org/stable/c/33a7d698f30fa0b99d50569e9909d3baa65d8f6a https://git.kernel.org/stable/c/99d348b82bcb36171f24411d3f1a15706a2a937a https://git.kernel.org/stable/c/9ef384ed300d1bcfb23d0ab0b487d544444d4b52 https://git.kernel.org/stable/c/fd7974c547abfb03072a4ee706d3a6f182266f89 https://git.kernel.org/stable/c/a8a917058faf4abaec9fb614bb6d5f8fe3529ec6 https://git.kernel.org/stable/c/7b3a34f08d11e7f05cd00b8e09adaa151 • CWE-501: Trust Boundary Violation •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47552 – blk-mq: cancel blk-mq dispatch work in both blk_cleanup_queue and disk_release()
https://notcve.org/view.php?id=CVE-2021-47552
In the Linux kernel, the following vulnerability has been resolved: blk-mq: cancel blk-mq dispatch work in both blk_cleanup_queue and disk_release() For avoiding to slow down queue destroy, we don't call blk_mq_quiesce_queue() in blk_cleanup_queue(), instead of delaying to cancel dispatch work in blk_release_queue(). However, this way has caused kernel oops[1], reported by Changhui. The log shows that scsi_device can be freed before running blk_release_queue(), which is expected too since scsi_device is released after the scsi disk is closed and the scsi_device is removed. Fixes the issue by canceling blk-mq dispatch work in both blk_cleanup_queue() and disk_release(): 1) when disk_release() is run, the disk has been closed, and any sync dispatch activities have been done, so canceling dispatch work is enough to quiesce filesystem I/O dispatch activity. 2) in blk_cleanup_queue(), we only focus on passthrough request, and passthrough request is always explicitly allocated & freed by its caller, so once queue is frozen, all sync dispatch activity for passthrough request has been done, then it is enough to just cancel dispatch work for avoiding any dispatch activity. [1] kernel panic log [12622.769416] BUG: kernel NULL pointer dereference, address: 0000000000000300 [12622.777186] #PF: supervisor read access in kernel mode [12622.782918] #PF: error_code(0x0000) - not-present page [12622.788649] PGD 0 P4D 0 [12622.791474] Oops: 0000 [#1] PREEMPT SMP PTI [12622.796138] CPU: 10 PID: 744 Comm: kworker/10:1H Kdump: loaded Not tainted 5.15.0+ #1 [12622.804877] Hardware name: Dell Inc. PowerEdge R730/0H21J3, BIOS 1.5.4 10/002/2015 [12622.813321] Workqueue: kblockd blk_mq_run_work_fn [12622.818572] RIP: 0010:sbitmap_get+0x75/0x190 [12622.823336] Code: 85 80 00 00 00 41 8b 57 08 85 d2 0f 84 b1 00 00 00 45 31 e4 48 63 cd 48 8d 1c 49 48 c1 e3 06 49 03 5f 10 4c 8d 6b 40 83 f0 01 <48> 8b 33 44 89 f2 4c 89 ef 0f b6 c8 e8 fa f3 ff ff 83 f8 ff 75 58 [12622.844290] RSP: 0018:ffffb00a446dbd40 EFLAGS: 00010202 [12622.850120] RAX: 0000000000000001 RBX: 0000000000000300 RCX: 0000000000000004 [12622.858082] RDX: 0000000000000006 RSI: 0000000000000082 RDI: ffffa0b7a2dfe030 [12622.866042] RBP: 0000000000000004 R08: 0000000000000001 R09: ffffa0b742721334 [12622.874003] R10: 0000000000000008 R11: 0000000000000008 R12: 0000000000000000 [12622.881964] R13: 0000000000000340 R14: 0000000000000000 R15: ffffa0b7a2dfe030 [12622.889926] FS: 0000000000000000(0000) GS:ffffa0baafb40000(0000) knlGS:0000000000000000 [12622.898956] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [12622.905367] CR2: 0000000000000300 CR3: 0000000641210001 CR4: 00000000001706e0 [12622.913328] Call Trace: [12622.916055] <TASK> [12622.918394] scsi_mq_get_budget+0x1a/0x110 [12622.922969] __blk_mq_do_dispatch_sched+0x1d4/0x320 [12622.928404] ? pick_next_task_fair+0x39/0x390 [12622.933268] __blk_mq_sched_dispatch_requests+0xf4/0x140 [12622.939194] blk_mq_sched_dispatch_requests+0x30/0x60 [12622.944829] __blk_mq_run_hw_queue+0x30/0xa0 [12622.949593] process_one_work+0x1e8/0x3c0 [12622.954059] worker_thread+0x50/0x3b0 [12622.958144] ? rescuer_thread+0x370/0x370 [12622.962616] kthread+0x158/0x180 [12622.966218] ? • https://git.kernel.org/stable/c/e03513f58919d9e2bc6df765ca2c9da863d03d90 https://git.kernel.org/stable/c/2a19b28f7929866e1cec92a3619f4de9f2d20005 •
CVSS: 6.5EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47551 – drm/amd/amdkfd: Fix kernel panic when reset failed and been triggered again
https://notcve.org/view.php?id=CVE-2021-47551
In the Linux kernel, the following vulnerability has been resolved: drm/amd/amdkfd: Fix kernel panic when reset failed and been triggered again In SRIOV configuration, the reset may failed to bring asic back to normal but stop cpsch already been called, the start_cpsch will not be called since there is no resume in this case. When reset been triggered again, driver should avoid to do uninitialization again. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amd/amdkfd: corrige el pánico del kernel cuando el reinicio falla y se activa nuevamente. En la configuración SRIOV, el reinicio puede no lograr que asic vuelva a la normalidad, pero ya se ha llamado a detener cpsch, el No se llamará a start_cpsch ya que en este caso no hay ningún currículum. Cuando el reinicio se activa nuevamente, el controlador debe evitar realizar la desinicialización nuevamente. • https://git.kernel.org/stable/c/74aafe99efb68f15e50be9f7032c2168512f98a8 https://git.kernel.org/stable/c/06c6f8f86ec243b89e52f0c3dc7062bcb9de74df https://git.kernel.org/stable/c/2cf49e00d40d5132e3d067b5aa6d84791929ab15 •
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 •