CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2022-48663 – gpio: mockup: fix NULL pointer dereference when removing debugfs
https://notcve.org/view.php?id=CVE-2022-48663
In the Linux kernel, the following vulnerability has been resolved: gpio: mockup: fix NULL pointer dereference when removing debugfs We now remove the device's debugfs entries when unbinding the driver. This now causes a NULL-pointer dereference on module exit because the platform devices are unregistered *after* the global debugfs directory has been recursively removed. Fix it by unregistering the devices first. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: gpio: maqueta: corrige la desreferencia del puntero NULL al eliminar debugfs Ahora eliminamos las entradas debugfs del dispositivo al desvincular el controlador. Esto ahora provoca una desreferencia del puntero NULL al salir del módulo porque los dispositivos de la plataforma no están registrados *después* de que el directorio global debugfs se haya eliminado de forma recursiva. Solucionarlo cancelando el registro de los dispositivos primero. • https://git.kernel.org/stable/c/3815e66c2183f3430490e450ba16779cf5214ec6 https://git.kernel.org/stable/c/3a10e8edee2b45a654f1f7b05f747129ec84cf9d https://git.kernel.org/stable/c/bc55c1677edbe86a1c66a35e800df47dff16ad61 https://git.kernel.org/stable/c/bdea98b98f844bd8a983ca880893e509a8b4162f https://git.kernel.org/stable/c/18352095a0d581f6aeb1e9fc9d68cc0152cd64b4 https://git.kernel.org/stable/c/af0bfabf06c74c260265c30ba81a34e7dec0e881 https://git.kernel.org/stable/c/b7df41a6f79dfb18ba2203f8c5f0e9c0b9b57f68 •
CVSS: 7.8EPSS: 0%CPEs: 3EXPL: 0CVE-2022-48662 – drm/i915/gem: Really move i915_gem_context.link under ref protection
https://notcve.org/view.php?id=CVE-2022-48662
In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Really move i915_gem_context.link under ref protection i915_perf assumes that it can use the i915_gem_context reference to protect its i915->gem.contexts.list iteration. However, this requires that we do not remove the context from the list until after we drop the final reference and release the struct. If, as currently, we remove the context from the list during context_close(), the link.next pointer may be poisoned while we are holding the context reference and cause a GPF: [ 4070.573157] i915 0000:00:02.0: [drm:i915_perf_open_ioctl [i915]] filtering on ctx_id=0x1fffff ctx_id_mask=0x1fffff [ 4070.574881] general protection fault, probably for non-canonical address 0xdead000000000100: 0000 [#1] PREEMPT SMP [ 4070.574897] CPU: 1 PID: 284392 Comm: amd_performance Tainted: G E 5.17.9 #180 [ 4070.574903] Hardware name: Intel Corporation NUC7i5BNK/NUC7i5BNB, BIOS BNKBL357.86A.0052.2017.0918.1346 09/18/2017 [ 4070.574907] RIP: 0010:oa_configure_all_contexts.isra.0+0x222/0x350 [i915] [ 4070.574982] Code: 08 e8 32 6e 10 e1 4d 8b 6d 50 b8 ff ff ff ff 49 83 ed 50 f0 41 0f c1 04 24 83 f8 01 0f 84 e3 00 00 00 85 c0 0f 8e fa 00 00 00 <49> 8b 45 50 48 8d 70 b0 49 8d 45 50 48 39 44 24 10 0f 85 34 fe ff [ 4070.574990] RSP: 0018:ffffc90002077b78 EFLAGS: 00010202 [ 4070.574995] RAX: 0000000000000002 RBX: 0000000000000002 RCX: 0000000000000000 [ 4070.575000] RDX: 0000000000000001 RSI: ffffc90002077b20 RDI: ffff88810ddc7c68 [ 4070.575004] RBP: 0000000000000001 R08: ffff888103242648 R09: fffffffffffffffc [ 4070.575008] R10: ffffffff82c50bc0 R11: 0000000000025c80 R12: ffff888101bf1860 [ 4070.575012] R13: dead0000000000b0 R14: ffffc90002077c04 R15: ffff88810be5cabc [ 4070.575016] FS: 00007f1ed50c0780(0000) GS:ffff88885ec80000(0000) knlGS:0000000000000000 [ 4070.575021] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 4070.575025] CR2: 00007f1ed5590280 CR3: 000000010ef6f005 CR4: 00000000003706e0 [ 4070.575029] Call Trace: [ 4070.575033] <TASK> [ 4070.575037] lrc_configure_all_contexts+0x13e/0x150 [i915] [ 4070.575103] gen8_enable_metric_set+0x4d/0x90 [i915] [ 4070.575164] i915_perf_open_ioctl+0xbc0/0x1500 [i915] [ 4070.575224] ? asm_common_interrupt+0x1e/0x40 [ 4070.575232] ? i915_oa_init_reg_state+0x110/0x110 [i915] [ 4070.575290] drm_ioctl_kernel+0x85/0x110 [ 4070.575296] ? • https://git.kernel.org/stable/c/f8246cf4d9a9025d26c609bb2195e7c0a9ce5c40 https://git.kernel.org/stable/c/713fa3e4591f65f804bdc88e8648e219fabc9ee1 https://git.kernel.org/stable/c/f799e0568d6c153368b177e0bbbde7dcc4ce7f1d https://git.kernel.org/stable/c/d119888b09bd567e07c6b93a07f175df88857e02 • CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer •
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: 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') •