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 •
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 •