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 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2021-47332 – ALSA: usx2y: Don't call free_pages_exact() with NULL address
https://notcve.org/view.php?id=CVE-2021-47332
In the Linux kernel, the following vulnerability has been resolved: ALSA: usx2y: Don't call free_pages_exact() with NULL address Unlike some other functions, we can't pass NULL pointer to free_pages_exact(). Add a proper NULL check for avoiding possible Oops. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: usx2y: No llamar a free_pages_exact() con dirección NULL A diferencia de otras funciones, no podemos pasar un puntero NULL a free_pages_exact(). Agregue una verificación NULL adecuada para evitar posibles Oops. • https://git.kernel.org/stable/c/88262229b778f4f7a896da828d966f94dcb35d19 https://git.kernel.org/stable/c/7d7f30cf182e55023fa8fde4c084b2d37c6be69d https://git.kernel.org/stable/c/bee295f5e03510252d18b25cc1d26230256eb87a https://git.kernel.org/stable/c/82e5ee742fdd8874fe996181b87fafe1eb5f1196 https://git.kernel.org/stable/c/cae0cf651adccee2c3f376e78f30fbd788d0829f •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47331 – usb: common: usb-conn-gpio: fix NULL pointer dereference of charger
https://notcve.org/view.php?id=CVE-2021-47331
In the Linux kernel, the following vulnerability has been resolved: usb: common: usb-conn-gpio: fix NULL pointer dereference of charger When power on system with OTG cable, IDDIG's interrupt arises before the charger registration, it will cause a NULL pointer dereference, fix the issue by registering the power supply before requesting IDDIG/VBUS irq. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: común: usb-conn-gpio: corrige la desreferencia del puntero NULL del cargador. Cuando se enciende el sistema con un cable OTG, la interrupción de IDDIG surge antes del registro del cargador, lo que provocará un puntero NULL desreferencia, solucione el problema registrando la fuente de alimentación antes de solicitar IDDIG/VBUS irq. • https://git.kernel.org/stable/c/8e8d910e9a3a7fba86140aff4924c30955ab228b https://git.kernel.org/stable/c/436906fd248e018403bcda61a9311d9af02912f1 https://git.kernel.org/stable/c/1a133a0996d6b4c83509d570ed4edcba34c44f25 https://git.kernel.org/stable/c/880287910b1892ed2cb38977893b947382a09d21 •