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 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2021-47082 – tun: avoid double free in tun_free_netdev
https://notcve.org/view.php?id=CVE-2021-47082
In the Linux kernel, the following vulnerability has been resolved: tun: avoid double free in tun_free_netdev Avoid double free in tun_free_netdev() by moving the dev->tstats and tun->security allocs to a new ndo_init routine (tun_net_init()) that will be called by register_netdevice(). ndo_init is paired with the desctructor (tun_free_netdev()), so if there's an error in register_netdevice() the destructor will handle the frees. BUG: KASAN: double-free or invalid-free in selinux_tun_dev_free_security+0x1a/0x20 security/selinux/hooks.c:5605 CPU: 0 PID: 25750 Comm: syz-executor416 Not tainted 5.16.0-rc2-syzk #1 Hardware name: Red Hat KVM, BIOS Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x89/0xb5 lib/dump_stack.c:106 print_address_description.constprop.9+0x28/0x160 mm/kasan/report.c:247 kasan_report_invalid_free+0x55/0x80 mm/kasan/report.c:372 ____kasan_slab_free mm/kasan/common.c:346 [inline] __kasan_slab_free+0x107/0x120 mm/kasan/common.c:374 kasan_slab_free include/linux/kasan.h:235 [inline] slab_free_hook mm/slub.c:1723 [inline] slab_free_freelist_hook mm/slub.c:1749 [inline] slab_free mm/slub.c:3513 [inline] kfree+0xac/0x2d0 mm/slub.c:4561 selinux_tun_dev_free_security+0x1a/0x20 security/selinux/hooks.c:5605 security_tun_dev_free_security+0x4f/0x90 security/security.c:2342 tun_free_netdev+0xe6/0x150 drivers/net/tun.c:2215 netdev_run_todo+0x4df/0x840 net/core/dev.c:10627 rtnl_unlock+0x13/0x20 net/core/rtnetlink.c:112 __tun_chr_ioctl+0x80c/0x2870 drivers/net/tun.c:3302 tun_chr_ioctl+0x2f/0x40 drivers/net/tun.c:3311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:874 [inline] __se_sys_ioctl fs/ioctl.c:860 [inline] __x64_sys_ioctl+0x19d/0x220 fs/ioctl.c:860 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3a/0x80 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tun: evita la doble liberación en tun_free_netdev Evita la doble liberación en tun_free_netdev() moviendo las asignaciones dev->tstats y tun->security a una nueva rutina ndo_init (tun_net_init()) que será llamado por Register_netdevice(). ndo_init está emparejado con el destructor (tun_free_netdev()), por lo que si hay un error en Register_netdevice() el destructor manejará las liberaciones. ERROR: KASAN: doble liberación o no válido en selinux_tun_dev_free_security+0x1a/0x20 security/selinux/hooks.c:5605 CPU: 0 PID: 25750 Comm: syz-executor416 No contaminado 5.16.0-rc2-syzk #1 Nombre de hardware : Red Hat KVM, seguimiento de llamadas de BIOS: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0x89/0xb5 lib/dump_stack.c:106 print_address_description.constprop.9+0x28/0x160 mm/kasan/report. c:247 kasan_report_invalid_free+0x55/0x80 mm/kasan/report.c:372 ____kasan_slab_free mm/kasan/common.c:346 [en línea] __kasan_slab_free+0x107/0x120 mm/kasan/common.c:374 kasan_slab_free include/linux/kasan .h:235 [en línea] slab_free_hook mm/slub.c:1723 [en línea] slab_free_freelist_hook mm/slub.c:1749 [en línea] slab_free mm/slub.c:3513 [en línea] kfree+0xac/0x2d0 mm/slub.c :4561 selinux_tun_dev_free_security+0x1a/0x20 seguridad/selinux/hooks.c:5605 seguridad_tun_dev_free_security+0x4f/0x90 seguridad/seguridad.c:2342 tun_free_netdev+0xe6/0x150 drivers/net/tun.c:2215 netdev_run_todo+0x4df/0x840 net/ núcleo /dev.c:10627 rtnl_unlock+0x13/0x20 net/core/rtnetlink.c:112 __tun_chr_ioctl+0x80c/0x2870 drivers/net/tun.c:3302 tun_chr_ioctl+0x2f/0x40 drivers/net/tun.c:3311 vfs_ioctl fs /ioctl.c:51 [en línea] __do_sys_ioctl fs/ioctl.c:874 [en línea] __se_sys_ioctl fs/ioctl.c:860 [en línea] __x64_sys_ioctl+0x19d/0x220 fs/ioctl.c:860 do_syscall_x64 arch/x86/entry/ common.c:50 [en línea] do_syscall_64+0x3a/0x80 arch/x86/entry/common.c:80 Entry_SYSCALL_64_after_hwframe+0x44/0xae • https://git.kernel.org/stable/c/8eb43d635950e27c29f1e9e49a23b31637f37757 https://git.kernel.org/stable/c/0c0e566f0387490d16f166808c72e9c772027681 https://git.kernel.org/stable/c/a01a4e9f5dc93335c716fa4023b1901956e8c904 https://git.kernel.org/stable/c/3cb5ae77799e8ed6ec3fec0b6b4cd07f01650cc5 https://git.kernel.org/stable/c/158b515f703e75e7d68289bf4d98c664e1d632df •