CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2022-48661 – gpio: mockup: Fix potential resource leakage when register a chip
https://notcve.org/view.php?id=CVE-2022-48661
In the Linux kernel, the following vulnerability has been resolved: gpio: mockup: Fix potential resource leakage when register a chip If creation of software node fails, the locally allocated string array is left unfreed. Free it on error path. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: gpio: maqueta: corrige una posible fuga de recursos al registrar un chip. Si falla la creación del nodo de software, la matriz de cadenas asignada localmente queda sin liberar. Libérelo en la ruta de error. • https://git.kernel.org/stable/c/6fda593f3082ef1aa783ac13e89f673fd69a2cb6 https://git.kernel.org/stable/c/9b26723e058faaf11b532fb4aa16d6849d581790 https://git.kernel.org/stable/c/41f857033c44442a27f591fda8d986e7c9e42872 https://git.kernel.org/stable/c/02743c4091ccfb246f5cdbbe3f44b152d5d12933 • CWE-404: Improper Resource Shutdown or Release •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2022-48660 – gpiolib: cdev: Set lineevent_state::irq after IRQ register successfully
https://notcve.org/view.php?id=CVE-2022-48660
In the Linux kernel, the following vulnerability has been resolved: gpiolib: cdev: Set lineevent_state::irq after IRQ register successfully When running gpio test on nxp-ls1028 platform with below command gpiomon --num-events=3 --rising-edge gpiochip1 25 There will be a warning trace as below: Call trace: free_irq+0x204/0x360 lineevent_free+0x64/0x70 gpio_ioctl+0x598/0x6a0 __arm64_sys_ioctl+0xb4/0x100 invoke_syscall+0x5c/0x130 ...... el0t_64_sync+0x1a0/0x1a4 The reason of this issue is that calling request_threaded_irq() function failed, and then lineevent_free() is invoked to release the resource. Since the lineevent_state::irq was already set, so the subsequent invocation of free_irq() would trigger the above warning call trace. To fix this issue, set the lineevent_state::irq after the IRQ register successfully. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: gpiolib: cdev: configure lineevent_state::irq después del registro IRQ con éxito Al ejecutar la prueba gpio en la plataforma nxp-ls1028 con el siguiente comando gpiomon --num-events=3 --rising-edge gpiochip1 25 Habrá un seguimiento de advertencia como se muestra a continuación: Seguimiento de llamada: free_irq+0x204/0x360 lineevent_free+0x64/0x70 gpio_ioctl+0x598/0x6a0 __arm64_sys_ioctl+0xb4/0x100 invoke_syscall+0x5c/0x130 ...... 0x1a0/0x1a4 El motivo de este problema es que falló la llamada a la función request_threaded_irq() y luego se invoca lineevent_free() para liberar el recurso. Dado que lineevent_state::irq ya estaba configurado, la invocación posterior de free_irq() activaría el seguimiento de llamada de advertencia anterior. • https://git.kernel.org/stable/c/468242724143a8e732f82f664b1e77432d149618 https://git.kernel.org/stable/c/657803b918e097e47d99d1489da83a603c36bcdd https://git.kernel.org/stable/c/97da736cd11ae73bdf2f5e21e24446b8349e0168 https://git.kernel.org/stable/c/b1489043d3b9004dd8d5a0357b08b5f0e6691c43 https://git.kernel.org/stable/c/69bef19d6b9700e96285f4b4e28691cda3dcd0d1 •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2022-48659 – mm/slub: fix to return errno if kmalloc() fails
https://notcve.org/view.php?id=CVE-2022-48659
In the Linux kernel, the following vulnerability has been resolved: mm/slub: fix to return errno if kmalloc() fails In create_unique_id(), kmalloc(, GFP_KERNEL) can fail due to out-of-memory, if it fails, return errno correctly rather than triggering panic via BUG_ON(); kernel BUG at mm/slub.c:5893! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP Call trace: sysfs_slab_add+0x258/0x260 mm/slub.c:5973 __kmem_cache_create+0x60/0x118 mm/slub.c:4899 create_cache mm/slab_common.c:229 [inline] kmem_cache_create_usercopy+0x19c/0x31c mm/slab_common.c:335 kmem_cache_create+0x1c/0x28 mm/slab_common.c:390 f2fs_kmem_cache_create fs/f2fs/f2fs.h:2766 [inline] f2fs_init_xattr_caches+0x78/0xb4 fs/f2fs/xattr.c:808 f2fs_fill_super+0x1050/0x1e0c fs/f2fs/super.c:4149 mount_bdev+0x1b8/0x210 fs/super.c:1400 f2fs_mount+0x44/0x58 fs/f2fs/super.c:4512 legacy_get_tree+0x30/0x74 fs/fs_context.c:610 vfs_get_tree+0x40/0x140 fs/super.c:1530 do_new_mount+0x1dc/0x4e4 fs/namespace.c:3040 path_mount+0x358/0x914 fs/namespace.c:3370 do_mount fs/namespace.c:3383 [inline] __do_sys_mount fs/namespace.c:3591 [inline] __se_sys_mount fs/namespace.c:3568 [inline] __arm64_sys_mount+0x2f8/0x408 fs/namespace.c:3568 En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/slub: corrección para devolver errno si kmalloc() falla. En create_unique_id(), kmalloc(, GFP_KERNEL) puede fallar debido a falta de memoria, si falla, regrese errno correctamente en lugar de provocar pánico mediante BUG_ON(); ¡ERROR del kernel en mm/slub.c:5893! Error interno: Ups - ERROR: 0 [#1] Seguimiento de llamada SMP PREEMPT: sysfs_slab_add+0x258/0x260 mm/slub.c:5973 __kmem_cache_create+0x60/0x118 mm/slub.c:4899 create_cache mm/slab_common.c:229 [ en línea] kmem_cache_create_usercopy+0x19c/0x31c mm/slab_common.c:335 kmem_cache_create+0x1c/0x28 mm/slab_common.c:390 f2fs_kmem_cache_create fs/f2fs/f2fs.h:2766 [en línea] f2fs_init_xattr_caches+0x 78/0xb4 fs/f2fs/xattr. c:808 f2fs_fill_super+0x1050/0x1e0c fs/f2fs/super.c:4149 mount_bdev+0x1b8/0x210 fs/super.c:1400 f2fs_mount+0x44/0x58 fs/f2fs/super.c:4512 Legacy_get_tree+0x30/0x74 fs/ fs_context.c:610 vfs_get_tree+0x40/0x140 fs/super.c:1530 do_new_mount+0x1dc/0x4e4 fs/namespace.c:3040 path_mount+0x358/0x914 fs/namespace.c:3370 do_mount fs/namespace.c:3383 [ en línea] __do_sys_mount fs/namespace.c:3591 [en línea] __se_sys_mount fs/namespace.c:3568 [en línea] __arm64_sys_mount+0x2f8/0x408 fs/namespace.c:3568 • https://git.kernel.org/stable/c/81819f0fc8285a2a5a921c019e3e3d7b6169d225 https://git.kernel.org/stable/c/e9219fa63c5c25804af82c7aa54d1ec770ebe457 https://git.kernel.org/stable/c/a1d83a19cec3bfeb2b3547a1f7631e432a766d1c https://git.kernel.org/stable/c/e996821717c5cf8aa1e1abdb6b3d900a231e3755 https://git.kernel.org/stable/c/016b150992eebc32c4a18f783cf2bb6e2545a3d9 https://git.kernel.org/stable/c/379ac7905ff3f0a6a4e507d3e9f710ec4fab9124 https://git.kernel.org/stable/c/2d6e55e0c03804e1e227b80a5746e086d6c6696c https://git.kernel.org/stable/c/02bcd951aa3c2cea95fb241c20802e950 • CWE-617: Reachable Assertion •
CVSS: 7.8EPSS: 0%CPEs: 3EXPL: 0CVE-2022-48658 – mm: slub: fix flush_cpu_slab()/__free_slab() invocations in task context.
https://notcve.org/view.php?id=CVE-2022-48658
In the Linux kernel, the following vulnerability has been resolved: mm: slub: fix flush_cpu_slab()/__free_slab() invocations in task context. Commit 5a836bf6b09f ("mm: slub: move flush_cpu_slab() invocations __free_slab() invocations out of IRQ context") moved all flush_cpu_slab() invocations to the global workqueue to avoid a problem related with deactivate_slab()/__free_slab() being called from an IRQ context on PREEMPT_RT kernels. When the flush_all_cpu_locked() function is called from a task context it may happen that a workqueue with WQ_MEM_RECLAIM bit set ends up flushing the global workqueue, this will cause a dependency issue. workqueue: WQ_MEM_RECLAIM nvme-delete-wq:nvme_delete_ctrl_work [nvme_core] is flushing !WQ_MEM_RECLAIM events:flush_cpu_slab WARNING: CPU: 37 PID: 410 at kernel/workqueue.c:2637 check_flush_dependency+0x10a/0x120 Workqueue: nvme-delete-wq nvme_delete_ctrl_work [nvme_core] RIP: 0010:check_flush_dependency+0x10a/0x120[ 453.262125] Call Trace: __flush_work.isra.0+0xbf/0x220 ? __queue_work+0x1dc/0x420 flush_all_cpus_locked+0xfb/0x120 __kmem_cache_shutdown+0x2b/0x320 kmem_cache_destroy+0x49/0x100 bioset_exit+0x143/0x190 blk_release_queue+0xb9/0x100 kobject_cleanup+0x37/0x130 nvme_fc_ctrl_free+0xc6/0x150 [nvme_fc] nvme_free_ctrl+0x1ac/0x2b0 [nvme_core] Fix this bug by creating a workqueue for the flush operation with the WQ_MEM_RECLAIM bit set. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: slub: corrige las invocaciones de flu_cpu_slab()/__free_slab() en el contexto de la tarea. Commit 5a836bf6b09f ("mm: slub: mover invocaciones de flu_cpu_slab() invocaciones de __free_slab() fuera del contexto IRQ") movió todas las invocaciones de flu_cpu_slab() a la cola de trabajo global para evitar un problema relacionado con la llamada de desactivate_slab()/__free_slab() desde un Contexto IRQ en núcleos PREEMPT_RT. • https://git.kernel.org/stable/c/5a836bf6b09f99ead1b69457ff39ab3011ece57b https://git.kernel.org/stable/c/61703b248be993eb4997b00ae5d3318e6d8f3c5b https://git.kernel.org/stable/c/df6cb39335cf5a1b918e8dbd8ba7cd9f1d00e45a https://git.kernel.org/stable/c/e45cc288724f0cfd497bb5920bcfa60caa335729 •
CVSS: 7.8EPSS: 0%CPEs: 4EXPL: 0CVE-2022-48657 – arm64: topology: fix possible overflow in amu_fie_setup()
https://notcve.org/view.php?id=CVE-2022-48657
In the Linux kernel, the following vulnerability has been resolved: arm64: topology: fix possible overflow in amu_fie_setup() cpufreq_get_hw_max_freq() returns max frequency in kHz as *unsigned int*, while freq_inv_set_max_ratio() gets passed this frequency in Hz as 'u64'. Multiplying max frequency by 1000 can potentially result in overflow -- multiplying by 1000ULL instead should avoid that... Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: arm64: topología: corrige posible desbordamiento en amu_fie_setup() cpufreq_get_hw_max_freq() devuelve la frecuencia máxima en kHz como *unsigned int*, mientras que freq_inv_set_max_ratio() pasa esta frecuencia en Hz como 'u64 '. Multiplicar la frecuencia máxima por 1000 puede potencialmente resultar en un desbordamiento; multiplicar por 1000ULL debería evitar eso... Encontrado por el Centro de verificación de Linux (linuxtesting.org) con la herramienta de análisis estático SVACE. • https://git.kernel.org/stable/c/cd0ed03a8903a0b0c6fc36e32d133d1ddfe70cd6 https://git.kernel.org/stable/c/904f881b57360cf85de962d84d8614d94431f60e https://git.kernel.org/stable/c/3c3edb82d67b2be9231174ac2af4af60d4af7549 https://git.kernel.org/stable/c/bb6d99e27cbe6b30e4e3bbd32927fd3b0bdec6eb https://git.kernel.org/stable/c/d4955c0ad77dbc684fc716387070ac24801b8bca • CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') •