CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47090 – mm/hwpoison: clear MF_COUNT_INCREASED before retrying get_any_page()
https://notcve.org/view.php?id=CVE-2021-47090
In the Linux kernel, the following vulnerability has been resolved: mm/hwpoison: clear MF_COUNT_INCREASED before retrying get_any_page() Hulk Robot reported a panic in put_page_testzero() when testing madvise() with MADV_SOFT_OFFLINE. The BUG() is triggered when retrying get_any_page(). This is because we keep MF_COUNT_INCREASED flag in second try but the refcnt is not increased. page dumped because: VM_BUG_ON_PAGE(page_ref_count(page) == 0) ------------[ cut here ]------------ kernel BUG at include/linux/mm.h:737! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 5 PID: 2135 Comm: sshd Tainted: G B 5.16.0-rc6-dirty #373 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: release_pages+0x53f/0x840 Call Trace: free_pages_and_swap_cache+0x64/0x80 tlb_flush_mmu+0x6f/0x220 unmap_page_range+0xe6c/0x12c0 unmap_single_vma+0x90/0x170 unmap_vmas+0xc4/0x180 exit_mmap+0xde/0x3a0 mmput+0xa3/0x250 do_exit+0x564/0x1470 do_group_exit+0x3b/0x100 __do_sys_exit_group+0x13/0x20 __x64_sys_exit_group+0x16/0x20 do_syscall_64+0x34/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae Modules linked in: ---[ end trace e99579b570fe0649 ]--- RIP: 0010:release_pages+0x53f/0x840 En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mm/hwpoison: borre MF_COUNT_INCREASED antes de volver a intentar get_any_page() Hulk Robot informó un pánico en put_page_testzero() al probar madvise() con MADV_SOFT_OFFLINE. El ERROR() se activa al volver a intentar get_any_page(). • https://git.kernel.org/stable/c/b94e02822debdf0cc473556aad7dcc859f216653 https://git.kernel.org/stable/c/1f207076740101fed87074a6bc924dbe806f08a5 https://git.kernel.org/stable/c/c691e7575eff76e563b0199c23ec46bd454f43e3 https://git.kernel.org/stable/c/2a57d83c78f889bf3f54eede908d0643c40d5418 •
CVSS: 3.3EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47089 – kfence: fix memory leak when cat kfence objects
https://notcve.org/view.php?id=CVE-2021-47089
In the Linux kernel, the following vulnerability has been resolved: kfence: fix memory leak when cat kfence objects Hulk robot reported a kmemleak problem: unreferenced object 0xffff93d1d8cc02e8 (size 248): comm "cat", pid 23327, jiffies 4624670141 (age 495992.217s) hex dump (first 32 bytes): 00 40 85 19 d4 93 ff ff 00 10 00 00 00 00 00 00 .@.............. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: seq_open+0x2a/0x80 full_proxy_open+0x167/0x1e0 do_dentry_open+0x1e1/0x3a0 path_openat+0x961/0xa20 do_filp_open+0xae/0x120 do_sys_openat2+0x216/0x2f0 do_sys_open+0x57/0x80 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 unreferenced object 0xffff93d419854000 (size 4096): comm "cat", pid 23327, jiffies 4624670141 (age 495992.217s) hex dump (first 32 bytes): 6b 66 65 6e 63 65 2d 23 32 35 30 3a 20 30 78 30 kfence-#250: 0x0 30 30 30 30 30 30 30 37 35 34 62 64 61 31 32 2d 0000000754bda12- backtrace: seq_read_iter+0x313/0x440 seq_read+0x14b/0x1a0 full_proxy_read+0x56/0x80 vfs_read+0xa5/0x1b0 ksys_read+0xa0/0xf0 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 I find that we can easily reproduce this problem with the following commands: cat /sys/kernel/debug/kfence/objects echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak The leaked memory is allocated in the stack below: do_syscall_64 do_sys_open do_dentry_open full_proxy_open seq_open ---> alloc seq_file vfs_read full_proxy_read seq_read seq_read_iter traverse ---> alloc seq_buf And it should have been released in the following process: do_syscall_64 syscall_exit_to_user_mode exit_to_user_mode_prepare task_work_run ____fput __fput full_proxy_release ---> free here However, the release function corresponding to file_operations is not implemented in kfence. As a result, a memory leak occurs. Therefore, the solution to this problem is to implement the corresponding release function. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: kfence: repara la pérdida de memoria cuando los objetos cat kfence Hulk robot informó un problema kmemleak: objeto sin referencia 0xffff93d1d8cc02e8 (tamaño 248): comm "cat", pid 23327, jiffies 4624670141 (edad 495992.217s ) volcado hexadecimal (primeros 32 bytes): 00 40 85 19 d4 93 ff ff 00 10 00 00 00 00 00 00 .@.............. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................. rastreo inverso: seq_open+0x2a/0x80 full_proxy_open+0x167/0x1e0 do_dentry_open+0x1e1/0x3a0 path_openat+0x961/0xa20 do_filp_open+0xae/0x120 do_sys_openat2+0x216/0x2f0 do_sys_open+0x57/0x80 do_syscall_64+0x33/0x40 Entry_SYSCALL_64_after_hwframe+0x44/0xa9 objeto sin referencia 0xffff93d419854000 (tamaño 4096): comm "cat", pid 23327, Jiffies 4624670141 (edad 495992,217 s) volcado hexadecimal (primeros 32 bytes) : 6b 66 65 6e 63 65 2d 23 32 35 30 3a 20 30 78 30 kfence-#250: 0x0 30 30 30 30 30 30 30 37 35 34 62 64 61 31 32 2d 0000000754bda1 2- rastreo inverso: seq_read_iter+0x313/0x440 seq_read+ 0x14b/0x1a0 full_proxy_read+0x56/0x80 vfs_read+0xa5/0x1b0 ksys_read+0xa0/0xf0 do_syscall_64+0x33/0x40 Entry_SYSCALL_64_after_hwframe+0x44/0xa9 Creo que podemos reproducir fácilmente este problema con los siguientes comandos: cat /sys/kernel/ depurar/ kfence/objects echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak La memoria filtrada se asigna en la pila siguiente: do_syscall_64 do_sys_open do_dentry_open full_proxy_open seq_open ---> alloc seq_file vfs_read full_proxy_read seq_read seq_read_iter traverse - --> alloc seq_buf Y debería haberse liberado en el siguiente proceso: do_syscall_64 syscall_exit_to_user_mode exit_to_user_mode_prepare task_work_run ____fput __fput full_proxy_release ---> free aquí Sin embargo, la función de liberación correspondiente a file_operatives no está implementada en kfence. Como resultado, se produce una pérdida de memoria. • https://git.kernel.org/stable/c/0ce20dd840897b12ae70869c69f1ba34d6d16965 https://git.kernel.org/stable/c/2f06c8293d27f6337f907042c602c9c953988c48 https://git.kernel.org/stable/c/0129ab1f268b6cf88825eae819b9b84aa0a85634 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47088 – mm/damon/dbgfs: protect targets destructions with kdamond_lock
https://notcve.org/view.php?id=CVE-2021-47088
In the Linux kernel, the following vulnerability has been resolved: mm/damon/dbgfs: protect targets destructions with kdamond_lock DAMON debugfs interface iterates current monitoring targets in 'dbgfs_target_ids_read()' while holding the corresponding 'kdamond_lock'. However, it also destructs the monitoring targets in 'dbgfs_before_terminate()' without holding the lock. This can result in a use_after_free bug. This commit avoids the race by protecting the destruction with the corresponding 'kdamond_lock'. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/damon/dbgfs: protege las destrucciones de objetivos con kdamond_lock La interfaz DAMON debugfs itera los objetivos de monitoreo actuales en 'dbgfs_target_ids_read()' mientras mantiene el correspondiente 'kdamond_lock'. • https://git.kernel.org/stable/c/4bc05954d0076655cfaf6f0135585bdc20cd6b11 https://git.kernel.org/stable/c/330c6117a82c16a9a365a51cec5c9ab30b13245c https://git.kernel.org/stable/c/34796417964b8d0aef45a99cf6c2d20cebe33733 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2021-47087 – tee: optee: Fix incorrect page free bug
https://notcve.org/view.php?id=CVE-2021-47087
In the Linux kernel, the following vulnerability has been resolved: tee: optee: Fix incorrect page free bug Pointer to the allocated pages (struct page *page) has already progressed towards the end of allocation. It is incorrect to perform __free_pages(page, order) using this pointer as we would free any arbitrary pages. Fix this by stop modifying the page pointer. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: tee: optee: corrige el error de liberación de página incorrecta. El puntero a las páginas asignadas (página de estructura *página) ya ha avanzado hacia el final de la asignación. • https://git.kernel.org/stable/c/3c712f14d8a9354a8807c15c64c8dd334499cc42 https://git.kernel.org/stable/c/1340dc3fb75ea69221f4f5dcb0cbace55ad0331c https://git.kernel.org/stable/c/ec185dd3ab257dc2a60953fdf1b6622f524cc5b7 https://git.kernel.org/stable/c/255e17923b22cb7abd026e044416d61f6bd0eec0 https://git.kernel.org/stable/c/806142c805cacd098e61bdc0f72c778a2389fe4a https://git.kernel.org/stable/c/ad338d825e3f7b96ee542bf313728af2d19fe9ad https://git.kernel.org/stable/c/91e94e42f6fc49635f1a16d8ae3f79552bcfda29 https://git.kernel.org/stable/c/18549bf4b21c739a9def39f27dcac53e2 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47083 – pinctrl: mediatek: fix global-out-of-bounds issue
https://notcve.org/view.php?id=CVE-2021-47083
In the Linux kernel, the following vulnerability has been resolved: pinctrl: mediatek: fix global-out-of-bounds issue When eint virtual eint number is greater than gpio number, it maybe produce 'desc[eint_n]' size globle-out-of-bounds issue. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: pinctrl: mediatek: soluciona el problema global fuera de los límites Cuando el número eint virtual eint es mayor que el número gpio, puede producir un tamaño 'desc[eint_n]' globle-out- cuestión de fuera de los límites. • https://git.kernel.org/stable/c/f373298e1bf0c6ea097c0bcc558dc43ad53e421f https://git.kernel.org/stable/c/441d3873664d170982922c5d2fc01fa89d9439ed https://git.kernel.org/stable/c/fb563baa3eb8e7a15f2cff3c2695e2cca0493e69 https://git.kernel.org/stable/c/2d5446da5acecf9c67db1c9d55ae2c3e5de01f8d •