Page 195 of 4980 results (0.009 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: jfs: fix GPF in diFree Avoid passing inode with JFS_SBI(inode->i_sb)->ipimap == NULL to diFree()[1]. GFP will appear: struct inode *ipimap = JFS_SBI(ip->i_sb)->ipimap; struct inomap *imap = JFS_IP(ipimap)->i_imap; JFS_IP() will return invalid pointer when ipimap == NULL Call Trace: diFree+0x13d/0x2dc0 fs/jfs/jfs_imap.c:853 [1] jfs_evict_inode+0x2c9/0x370 fs/jfs/inode.c:154 evict+0x2ed/0x750 fs/inode.c:578 iput_final fs/inode.c:1654 [inline] iput.part.0+0x3fe/0x820 fs/inode.c:1680 iput+0x58/0x70 fs/inode.c:1670 En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: jfs: corrige GPF en diFree. Evite pasar el inodo con JFS_SBI(inode->i_sb)->ipimap == NULL a diFree()[1]. Aparecerá GFP: struct inode *ipimap = JFS_SBI(ip->i_sb)->ipimap; estructura inomap *imap = JFS_IP(ipimap)->i_imap; JFS_IP() devolverá un puntero no válido cuando ipimap == NULL Seguimiento de llamadas: diFree+0x13d/0x2dc0 fs/jfs/jfs_imap.c:853 [1] jfs_evict_inode+0x2c9/0x370 fs/jfs/inode.c:154 evict+0x2ed/ 0x750 fs/inode.c:578 iput_final fs/inode.c:1654 [en línea] iput.part.0+0x3fe/0x820 fs/inode.c:1680 iput+0x58/0x70 fs/inode.c:1670 • https://git.kernel.org/stable/c/7bde24bde490f3139eee147efc6d60d6040fe975 https://git.kernel.org/stable/c/745c9a59422c63f661f4374ed5181740db4130a1 https://git.kernel.org/stable/c/49def1b0644892e3b113673c13d650c3060b43bc https://git.kernel.org/stable/c/aff8d95b69051d0cf4acc3d91f22299fdbb9dfb3 https://git.kernel.org/stable/c/a21e5cb1a64c904f1f0ef7b2d386fc7d2b1d2ce2 https://git.kernel.org/stable/c/8018936950360f1c503bb385e158cfc5e4945d18 https://git.kernel.org/stable/c/3bb27e27240289b47d3466f647a55c567adbdc3a https://git.kernel.org/stable/c/42f102ea1943ecb10a0756bf75424de5d •

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

In the Linux kernel, the following vulnerability has been resolved: media: v4l2-core: explicitly clear ioctl input data As seen from a recent syzbot bug report, mistakes in the compat ioctl implementation can lead to uninitialized kernel stack data getting used as input for driver ioctl handlers. The reported bug is now fixed, but it's possible that other related bugs are still present or get added in the future. As the drivers need to check user input already, the possible impact is fairly low, but it might still cause an information leak. To be on the safe side, always clear the entire ioctl buffer before calling the conversion handler functions that are meant to initialize them. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: medios: v4l2-core: borrar explícitamente los datos de entrada de ioctl. Como se ve en un informe de error reciente de syzbot, los errores en la implementación de compat ioctl pueden llevar a que los datos de la pila del kernel no inicializados se utilicen como entrada para controladores de ioctl del conductor. El error informado ya está solucionado, pero es posible que otros errores relacionados sigan presentes o se agreguen en el futuro. • https://git.kernel.org/stable/c/dc02c0b2bd6096f2f3ce63e1fc317aeda05f74d8 https://git.kernel.org/stable/c/bfb48b54db25c3b4ef4bef5e0691464ebc4aa335 https://git.kernel.org/stable/c/7b53cca764f9b291b7907fcd39d9e66ad728ee0b •

CVSS: 5.1EPSS: 0%CPEs: 5EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: fbmem: Do not delete the mode that is still in use The execution of fb_delete_videomode() is not based on the result of the previous fbcon_mode_deleted(). As a result, the mode is directly deleted, regardless of whether it is still in use, which may cause UAF. ================================================================== BUG: KASAN: use-after-free in fb_mode_is_equal+0x36e/0x5e0 \ drivers/video/fbdev/core/modedb.c:924 Read of size 4 at addr ffff88807e0ddb1c by task syz-executor.0/18962 CPU: 2 PID: 18962 Comm: syz-executor.0 Not tainted 5.10.45-rc1+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ... Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x137/0x1be lib/dump_stack.c:118 print_address_description+0x6c/0x640 mm/kasan/report.c:385 __kasan_report mm/kasan/report.c:545 [inline] kasan_report+0x13d/0x1e0 mm/kasan/report.c:562 fb_mode_is_equal+0x36e/0x5e0 drivers/video/fbdev/core/modedb.c:924 fbcon_mode_deleted+0x16a/0x220 drivers/video/fbdev/core/fbcon.c:2746 fb_set_var+0x1e1/0xdb0 drivers/video/fbdev/core/fbmem.c:975 do_fb_ioctl+0x4d9/0x6e0 drivers/video/fbdev/core/fbmem.c:1108 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl+0xfb/0x170 fs/ioctl.c:739 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Freed by task 18960: kasan_save_stack mm/kasan/common.c:48 [inline] kasan_set_track+0x3d/0x70 mm/kasan/common.c:56 kasan_set_free_info+0x17/0x30 mm/kasan/generic.c:355 __kasan_slab_free+0x108/0x140 mm/kasan/common.c:422 slab_free_hook mm/slub.c:1541 [inline] slab_free_freelist_hook+0xd6/0x1a0 mm/slub.c:1574 slab_free mm/slub.c:3139 [inline] kfree+0xca/0x3d0 mm/slub.c:4121 fb_delete_videomode+0x56a/0x820 drivers/video/fbdev/core/modedb.c:1104 fb_set_var+0x1f3/0xdb0 drivers/video/fbdev/core/fbmem.c:978 do_fb_ioctl+0x4d9/0x6e0 drivers/video/fbdev/core/fbmem.c:1108 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl+0xfb/0x170 fs/ioctl.c:739 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: fbmem: No elimina el modo que aún está en uso. La ejecución de fb_delete_videomode() no se basa en el resultado del fbcon_mode_deleted() anterior. Como resultado, el modo se elimina directamente, independientemente de si todavía está en uso, lo que puede causar UAF. ==================================================== ================ BUG: KASAN: use-after-free en fb_mode_is_equal+0x36e/0x5e0 \ drivers/video/fbdev/core/modedb.c:924 Lectura de tamaño 4 en addr ffff88807e0ddb1c por tarea syz-executor.0/18962 CPU: 2 PID: 18962 Comm: syz-executor.0 No contaminado 5.10.45-rc1+ #3 Nombre de hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS .. Seguimiento de llamadas: __dump_stack lib/dump_stack.c:77 [en línea] dump_stack+0x137/0x1be lib/dump_stack.c:118 print_address_description+0x6c/0x640 mm/kasan/report.c:385 __kasan_report mm/kasan/report.c: 545 [en línea] kasan_report+0x13d/0x1e0 mm/kasan/report.c:562 fb_mode_is_equal+0x36e/0x5e0 drivers/video/fbdev/core/modedb.c:924 fbcon_mode_deleted+0x16a/0x220 drivers/video/fbdev/core/fbcon .c:2746 fb_set_var+0x1e1/0xdb0 drivers/video/fbdev/core/fbmem.c:975 do_fb_ioctl+0x4d9/0x6e0 drivers/video/fbdev/core/fbmem.c:1108 vfs_ioctl fs/ioctl.c:48 [en línea ] __do_sys_ioctl fs/ioctl.c:753 [en línea] __se_sys_ioctl+0xfb/0x170 fs/ioctl.c:739 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 Entry_SYSCALL_64_after_hwframe+0x44/0xa9 Liberado por tarea 18960: kasan_save_stack mm/kasan/common.c:48 [en línea] kasan_set_track+0x3d/0x70 mm/kasan/common.c:56 kasan_set_free_info+0x17/0x30 mm/kasan/generic.c:355 __kasan_slab_free+0x108/0x140 mm/kasan/ common.c:422 slab_free_hook mm/slub.c:1541 [en línea] slab_free_freelist_hook+0xd6/0x1a0 mm/slub.c:1574 slab_free mm/slub.c:3139 [en línea] kfree+0xca/0x3d0 mm/slub.c: 4121 fb_delete_videomode+0x56a/0x820 controladores/video/fbdev/core/modedb.c:1104 fb_set_var+0x1f3/0xdb0 controladores/video/fbdev/core/fbmem.c:978 do_fb_ioctl+0x4d9/0x6e0 controladores/video/fbdev/core/ fbmem.c:1108 vfs_ioctl fs/ioctl.c:48 [en línea] __do_sys_ioctl fs/ioctl.c:753 [en línea] __se_sys_ioctl+0xfb/0x170 fs/ioctl.c:739 do_syscall_64+0x2d/0x70 arch/x86/entry/ common.c:46 entrada_SYSCALL_64_after_hwframe+0x44/0xa9 A vulnerability was found in the Linux kernel's fbmem subsystem. • https://git.kernel.org/stable/c/13ff178ccd6d3b8074c542a911300b79c4eec255 https://git.kernel.org/stable/c/359311b85ebec7c07c3a08ae2f3def946cad33fa https://git.kernel.org/stable/c/087bff9acd2ec6db3f61aceb3224bde90fe0f7f8 https://git.kernel.org/stable/c/f193509afc7ff37a46862610c93b896044d5b693 https://git.kernel.org/stable/c/d6e76469157d8f240e5dec6f8411aa8d306b1126 https://git.kernel.org/stable/c/0af778269a522c988ef0b4188556aba97fb420cc https://access.redhat.com/security/cve/CVE-2021-47338 https://bugzilla.redhat.com/show_bug.cgi?id=2282422 • CWE-416: Use After Free •

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

In the Linux kernel, the following vulnerability has been resolved: scsi: core: Fix bad pointer dereference when ehandler kthread is invalid Commit 66a834d09293 ("scsi: core: Fix error handling of scsi_host_alloc()") changed the allocation logic to call put_device() to perform host cleanup with the assumption that IDA removal and stopping the kthread would properly be performed in scsi_host_dev_release(). However, in the unlikely case that the error handler thread fails to spawn, shost->ehandler is set to ERR_PTR(-ENOMEM). The error handler cleanup code in scsi_host_dev_release() will call kthread_stop() if shost->ehandler != NULL which will always be the case whether the kthread was successfully spawned or not. In the case that it failed to spawn this has the nasty side effect of trying to dereference an invalid pointer when kthread_stop() is called. The following splat provides an example of this behavior in the wild: scsi host11: error handler thread failed to spawn, error = -4 Kernel attempted to read user page (10c) - exploit attempt? • https://git.kernel.org/stable/c/8958181c1663e24a13434448e7d6b96b5d04900a https://git.kernel.org/stable/c/db08ce595dd64ea9859f7d088b51cbfc8e685c66 https://git.kernel.org/stable/c/2dc85045ae65b9302a1d2e2ddd7ce4c030153a6a https://git.kernel.org/stable/c/79296e292d67fa7b5fb8d8c27343683e823872c8 https://git.kernel.org/stable/c/7a696ce1d5d16a33a6cd6400bbcc0339b2460e11 https://git.kernel.org/stable/c/45d83db4728127944b237c0c8248987df9d478e7 https://git.kernel.org/stable/c/66a834d092930cf41d809c0e989b13cd6f9ca006 https://git.kernel.org/stable/c/d2f0b960d07e52bb664471b4de0ed8b08 •

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

In the Linux kernel, the following vulnerability has been resolved: smackfs: restrict bytes count in smk_set_cipso() Oops, I failed to update subject line. From 07571157c91b98ce1a4aa70967531e64b78e8346 Mon Sep 17 00:00:00 2001 Date: Mon, 12 Apr 2021 22:25:06 +0900 Subject: [PATCH] smackfs: restrict bytes count in smk_set_cipso() Commit 7ef4c19d245f3dc2 ("smackfs: restrict bytes count in smackfs write functions") missed that count > SMK_CIPSOMAX check applies to only format == SMK_FIXED24_FMT case. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: smackfs: restringir el recuento de bytes en smk_set_cipso() Oops, no pude actualizar la línea de asunto. De 07571157c91b98ce1a4aa70967531e64b78e8346 lunes 17 de septiembre 00:00:00 2001 Fecha: lunes 12 de abril de 2021 22:25:06 +0900 Asunto: [PATCH] smackfs: restringir el recuento de bytes en smk_set_cipso() Confirmación 7ef4c1 9d245f3dc2 ("smackfs: restringir el recuento de bytes en smackfs funciones de escritura") perdió ese recuento > La verificación SMK_CIPSOMAX se aplica solo al formato == caso SMK_FIXED24_FMT. • https://git.kernel.org/stable/c/5f9880403e6b71d56924748ba331daf836243fca https://git.kernel.org/stable/c/5c2dca9a7a7ff6a2df34158903515e2e4fd3d2b2 https://git.kernel.org/stable/c/cbd87ba6a13891acf6180783f8234a8b7a3e3d4d https://git.kernel.org/stable/c/135122f174c357b7a3e58f40fa5792156c5e93e6 https://git.kernel.org/stable/c/3780348c1a0e14ffefcaf1fc521f815bcaac94b0 https://git.kernel.org/stable/c/8f5c773a2871cf446e3f36b2834fb25bbb28512b https://git.kernel.org/stable/c/258fd821f69378453c071b9dd767b298810fc766 https://git.kernel.org/stable/c/49ec114a6e62d8d320037ce71c1aaf965 •