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 •
CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2021-47333 – misc: alcor_pci: fix null-ptr-deref when there is no PCI bridge
https://notcve.org/view.php?id=CVE-2021-47333
In the Linux kernel, the following vulnerability has been resolved: misc: alcor_pci: fix null-ptr-deref when there is no PCI bridge There is an issue with the ASPM(optional) capability checking function. A device might be attached to root complex directly, in this case, bus->self(bridge) will be NULL, thus priv->parent_pdev is NULL. Since alcor_pci_init_check_aspm(priv->parent_pdev) checks the PCI link's ASPM capability and populate parent_cap_off, which will be used later by alcor_pci_aspm_ctrl() to dynamically turn on/off device, what we can do here is to avoid checking the capability if we are on the root complex. This will make pdev_cap_off 0 and alcor_pci_aspm_ctrl() will simply return when bring called, effectively disable ASPM for the device. [ 1.246492] BUG: kernel NULL pointer dereference, address: 00000000000000c0 [ 1.248731] RIP: 0010:pci_read_config_byte+0x5/0x40 [ 1.253998] Call Trace: [ 1.254131] ? alcor_pci_find_cap_offset.isra.0+0x3a/0x100 [alcor_pci] [ 1.254476] alcor_pci_probe+0x169/0x2d5 [alcor_pci] En el kernel de Linux, se resolvió la siguiente vulnerabilidad: misc: alcor_pci: corrige null-ptr-deref cuando no hay un puente PCI. Hay un problema con la función de verificación de capacidad ASPM (opcional). Un dispositivo se puede conectar directamente al complejo root; en este caso, bus->self(bridge) será NULL, por lo tanto, priv->parent_pdev es NULL. Dado que alcor_pci_init_check_aspm(priv->parent_pdev) verifica la capacidad ASPM del enlace PCI y completa parent_cap_off, que será utilizado más adelante por alcor_pci_aspm_ctrl() para encender/apagar dinámicamente el dispositivo, lo que podemos hacer aquí es evitar verificar la capacidad si estamos encendidos. el complejo raíz. • https://git.kernel.org/stable/c/d2639ffdcad463b358b6bef8645ff81715daffcb https://git.kernel.org/stable/c/58f69684ba03e5b0e0a3ae844a845280c0f06309 https://git.kernel.org/stable/c/717cf5ae52322ddbdf3ac2c584b34c5970b0d174 https://git.kernel.org/stable/c/09d154990ca82d14aed2b72796f6c8845e2e605d https://git.kernel.org/stable/c/3ce3e45cc333da707d4d6eb433574b990bcc26f5 •