Page 404 of 4297 results (0.048 seconds)

CVSS: -EPSS: 0%CPEs: 3EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: platform/x86: intel_pmc_core: fix memleak on registration failure In case device registration fails during module initialisation, the platform device structure needs to be freed using platform_device_put() to properly free all resources (e.g. the device name). En el kernel de Linux, se resolvió la siguiente vulnerabilidad: plataforma/x86: intel_pmc_core: corrige memleak en falla de registro En caso de que el registro del dispositivo falle durante la inicialización del módulo, la estructura del dispositivo de la plataforma debe liberarse usando platform_device_put() para liberar adecuadamente todos los recursos ( por ejemplo, el nombre del dispositivo). • https://git.kernel.org/stable/c/938835aa903ae19ad62805134f79bbcf20fc3bea https://git.kernel.org/stable/c/7a37f2e370699e2feca3dca6c8178c71ceee7e8a https://git.kernel.org/stable/c/9ca1324755f1f8629a370af5cc315b175331f5d1 https://git.kernel.org/stable/c/26a8b09437804fabfb1db080d676b96c0de68e7c •

CVSS: -EPSS: 0%CPEs: 3EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: mac80211: fix locking in ieee80211_start_ap error path We need to hold the local->mtx to release the channel context, as even encoded by the lockdep_assert_held() there. Fix it. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mac80211: corrige el bloqueo en la ruta de error ieee80211_start_ap Necesitamos mantener local->mtx para liberar el contexto del canal, incluso codificado por lockdep_assert_held() allí. Arreglalo. • https://git.kernel.org/stable/c/295b02c4be74bebf988593b8322369513fcecf68 https://git.kernel.org/stable/c/ac61b9c6c0549aaeb98194cf429d93c41bfe5f79 https://git.kernel.org/stable/c/c1d1ec4db5f7264cfc21993e59e8f2dcecf4b44f https://git.kernel.org/stable/c/87a270625a89fc841f1a7e21aae6176543d8385c •

CVSS: -EPSS: 0%CPEs: 3EXPL: 0

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: -EPSS: 0%CPEs: 2EXPL: 0

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: 5EXPL: 0

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 •