CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47339 – media: v4l2-core: explicitly clear ioctl input data
https://notcve.org/view.php?id=CVE-2021-47339
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: -EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47337 – scsi: core: Fix bad pointer dereference when ehandler kthread is invalid
https://notcve.org/view.php?id=CVE-2021-47337
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: 0CVE-2021-47336 – smackfs: restrict bytes count in smk_set_cipso()
https://notcve.org/view.php?id=CVE-2021-47336
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 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47335 – f2fs: fix to avoid racing on fsync_entry_slab by multi filesystem instances
https://notcve.org/view.php?id=CVE-2021-47335
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid racing on fsync_entry_slab by multi filesystem instances As syzbot reported, there is an use-after-free issue during f2fs recovery: Use-after-free write at 0xffff88823bc16040 (in kfence-#10): kmem_cache_destroy+0x1f/0x120 mm/slab_common.c:486 f2fs_recover_fsync_data+0x75b0/0x8380 fs/f2fs/recovery.c:869 f2fs_fill_super+0x9393/0xa420 fs/f2fs/super.c:3945 mount_bdev+0x26c/0x3a0 fs/super.c:1367 legacy_get_tree+0xea/0x180 fs/fs_context.c:592 vfs_get_tree+0x86/0x270 fs/super.c:1497 do_new_mount fs/namespace.c:2905 [inline] path_mount+0x196f/0x2be0 fs/namespace.c:3235 do_mount fs/namespace.c:3248 [inline] __do_sys_mount fs/namespace.c:3456 [inline] __se_sys_mount+0x2f9/0x3b0 fs/namespace.c:3433 do_syscall_64+0x3f/0xb0 arch/x86/entry/common.c:47 entry_SYSCALL_64_after_hwframe+0x44/0xae The root cause is multi f2fs filesystem instances can race on accessing global fsync_entry_slab pointer, result in use-after-free issue of slab cache, fixes to init/destroy this slab cache only once during module init/destroy procedure to avoid this issue. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: f2fs: solución para evitar ejecuciónes en fsync_entry_slab por instancias de múltiples sistemas de archivos. Como informó syzbot, hay un problema de use after free durante la recuperación de f2fs: escritura de use after free en 0xffff88823bc16040 ( en kfence-#10): kmem_cache_destroy+0x1f/0x120 mm/slab_common.c:486 f2fs_recover_fsync_data+0x75b0/0x8380 fs/f2fs/recovery.c:869 f2fs_fill_super+0x9393/0xa420 fs/f2fs/super.c:3945 _bdev+0x26c /0x3a0 fs/super.c:1367 Legacy_get_tree+0xea/0x180 fs/fs_context.c:592 vfs_get_tree+0x86/0x270 fs/super.c:1497 do_new_mount fs/namespace.c:2905 [en línea] path_mount+0x196f/0x2be0 fs /namespace.c:3235 do_mount fs/namespace.c:3248 [en línea] __do_sys_mount fs/namespace.c:3456 [en línea] __se_sys_mount+0x2f9/0x3b0 fs/namespace.c:3433 do_syscall_64+0x3f/0xb0 arch/x86/entry /common.c:47 Entry_SYSCALL_64_after_hwframe+0x44/0xae La causa principal es que varias instancias del sistema de archivos f2fs pueden acelerarse al acceder al puntero global fsync_entry_slab, lo que resulta en un problema de use after free del caché de slab, se corrige para iniciar/destruir este caché de slab solo una vez durante procedimiento de inicio/destrucción del módulo para evitar este problema. • https://git.kernel.org/stable/c/86786603014e0a22d0d6af8e80ae4b8687927048 https://git.kernel.org/stable/c/79fa5d944c875711253a23b8155b36883c696409 https://git.kernel.org/stable/c/e472b276a0d2180808009be38105e12754432e2a https://git.kernel.org/stable/c/cad83c968c2ebe97905f900326988ed37146c347 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2021-47334 – misc/libmasm/module: Fix two use after free in ibmasm_init_one
https://notcve.org/view.php?id=CVE-2021-47334
In the Linux kernel, the following vulnerability has been resolved: misc/libmasm/module: Fix two use after free in ibmasm_init_one In ibmasm_init_one, it calls ibmasm_init_remote_input_dev(). Inside ibmasm_init_remote_input_dev, mouse_dev and keybd_dev are allocated by input_allocate_device(), and assigned to sp->remote.mouse_dev and sp->remote.keybd_dev respectively. In the err_free_devices error branch of ibmasm_init_one, mouse_dev and keybd_dev are freed by input_free_device(), and return error. Then the execution runs into error_send_message error branch of ibmasm_init_one, where ibmasm_free_remote_input_dev(sp) is called to unregister the freed sp->remote.mouse_dev and sp->remote.keybd_dev. My patch add a "error_init_remote" label to handle the error of ibmasm_init_remote_input_dev(), to avoid the uaf bugs. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: misc/libmasm/module: corrige dos use after free en ibmasm_init_one. En ibmasm_init_one, llama a ibmasm_init_remote_input_dev(). Dentro de ibmasm_init_remote_input_dev, mouse_dev y keybd_dev son asignados por input_allocate_device() y asignados a sp->remote.mouse_dev y sp->remote.keybd_dev respectivamente. • https://git.kernel.org/stable/c/1512e7dc5eb08b7d92a12e2bfcd9cb8c4a1ec069 https://git.kernel.org/stable/c/29ba8e2ba89ee2862a26d91204dd5fe77ceee25a https://git.kernel.org/stable/c/5b06ca113bf197aab2ab61288f42506e0049fbab https://git.kernel.org/stable/c/481a76d4749ee3a27f902ba213fdcbb4bb39720e https://git.kernel.org/stable/c/38660031e80eaa6cc9370b031c180612f414b00d https://git.kernel.org/stable/c/b9c87ce3bc6331f82811a8cf8e930423c22523a3 https://git.kernel.org/stable/c/ef1067d2baa847d53c9988510d99fb494de4d12c https://git.kernel.org/stable/c/a7268e8a227d5a4f0bd1584f556246b02 •