Page 541 of 4156 results (0.022 seconds)

CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: perf: RISCV: Fix panic on pmu overflow handler (1 << idx) of int is not desired when setting bits in unsigned long overflowed_ctrs, use BIT() instead. This panic happens when running 'perf record -e branches' on sophgo sg2042. [ 273.311852] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000098 [ 273.320851] Oops [#1] [ 273.323179] Modules linked in: [ 273.326303] CPU: 0 PID: 1475 Comm: perf Not tainted 6.6.0-rc3+ #9 [ 273.332521] Hardware name: Sophgo Mango (DT) [ 273.336878] epc : riscv_pmu_ctr_get_width_mask+0x8/0x62 [ 273.342291] ra : pmu_sbi_ovf_handler+0x2e0/0x34e [ 273.347091] epc : ffffffff80aecd98 ra : ffffffff80aee056 sp : fffffff6e36928b0 [ 273.354454] gp : ffffffff821f82d0 tp : ffffffd90c353200 t0 : 0000002ade4f9978 [ 273.361815] t1 : 0000000000504d55 t2 : ffffffff8016cd8c s0 : fffffff6e3692a70 [ 273.369180] s1 : 0000000000000020 a0 : 0000000000000000 a1 : 00001a8e81800000 [ 273.376540] a2 : 0000003c00070198 a3 : 0000003c00db75a4 a4 : 0000000000000015 [ 273.383901] a5 : ffffffd7ff8804b0 a6 : 0000000000000015 a7 : 000000000000002a [ 273.391327] s2 : 000000000000ffff s3 : 0000000000000000 s4 : ffffffd7ff8803b0 [ 273.398773] s5 : 0000000000504d55 s6 : ffffffd905069800 s7 : ffffffff821fe210 [ 273.406139] s8 : 000000007fffffff s9 : ffffffd7ff8803b0 s10: ffffffd903f29098 [ 273.413660] s11: 0000000080000000 t3 : 0000000000000003 t4 : ffffffff8017a0ca [ 273.421022] t5 : ffffffff8023cfc2 t6 : ffffffd9040780e8 [ 273.426437] status: 0000000200000100 badaddr: 0000000000000098 cause: 000000000000000d [ 273.434512] [<ffffffff80aecd98>] riscv_pmu_ctr_get_width_mask+0x8/0x62 [ 273.441169] [<ffffffff80076bd8>] handle_percpu_devid_irq+0x98/0x1ee [ 273.447562] [<ffffffff80071158>] generic_handle_domain_irq+0x28/0x36 [ 273.454151] [<ffffffff8047a99a>] riscv_intc_irq+0x36/0x4e [ 273.459659] [<ffffffff80c944de>] handle_riscv_irq+0x4a/0x74 [ 273.465442] [<ffffffff80c94c48>] do_irq+0x62/0x92 [ 273.470360] Code: 0420 60a2 6402 5529 0141 8082 0013 0000 0013 0000 (6d5c) b783 [ 273.477921] ---[ end trace 0000000000000000 ]--- [ 273.482630] Kernel panic - not syncing: Fatal exception in interrupt En el kernel de Linux, se resolvió la siguiente vulnerabilidad: perf: RISCV: no se desea corregir el pánico en el controlador de desbordamiento de pmu (1 &lt;&lt; idx) de int al configurar bits en overflowed_ctrs largos sin firmar; use BIT() en su lugar. Este pánico ocurre cuando se ejecuta 'perf record -e sucursales' en sophgo sg2042. [273.311852] No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 0000000000000098 [273.320851] Ups [#1] [273.323179] Módulos vinculados en: [273.326303] CPU: 0 PID: 1475 Comm: perf No contaminado 6.6.0- rc3+#9 [ 273.332521] Nombre de hardware: Sophgo Mango (DT) [ 273.336878] epc : riscv_pmu_ctr_get_width_mask+0x8/0x62 [ 273.342291] ra : pmu_sbi_ovf_handler+0x2e0/0x34e [ 273.347091] epc : ffff80aecd98 ra: ffffffff80aee056 sp: ffffff6e36928b0 [273.354454] gp: ffffffff821f82d0 tp : ffffffd90c353200 T0: 0000002ade4f9978 [273.361815] T1: 000000000000504D55 T2: FFFFFFFF8016CD8C S0: FFFFFFF66E3692A70 [273.369180] 1A8E81800000 [273.376540] A2: 0000003C00070198 A3: 0000003C00DB75A4 A4: 000000000000000015 [273.383901] A5: FFFFFFD7FF8804B0 A6: 0000000000000015 a7: 000000000000002a [273.391327] s2: 000000000000ffff s3: 0000000000000000 s4: ffffffd7ff8803b0 [273.398773] s5: 0000000000504d55 s6: ffffffd905069800 s7: ffffffff821fe210 [273.406139] s8: 000000007ffffff s9: ffffffd7ff8803b0 s10: ffffffd903f29098 [273.413660] s11: 00080000000 t3: 0000000000000003 t4: ffffffff8017a0ca [273.421022] t5: ffffffff8023cfc2 t6: ffffffd9040780e8 [273.426437] estado: 0000000200000100 badaddr: 0000000000000098 causa: 00000d [ 273.434512] [] riscv_pmu_ctr_get_width_mask+0x8/0x62 [ 273.441169] [] handle_percpu_devid_irq+0x98/0x1ee [ 273.447562 ] [] generic_handle_domain_irq+0x28/0x36 [ 273.454151] [] riscv_intc_irq+0x36/0x4e [ 273.459659] [] 0x4a/0x74 [ 273.465442] [] do_irq+0x62/0x92 [ 273.470360] Código: 0420 60a2 6402 5529 0141 8082 0013 0000 0013 0000 (6d5c) b783 [ 273.477921] ---[ final de seguimiento 0000000000000000 ]--- 273.482 630] Pánico del kernel: no se sincroniza: excepción fatal en la interrupción • https://git.kernel.org/stable/c/3ede8e94de6b834b48b0643385e66363e7a04be9 https://git.kernel.org/stable/c/9f599ba3b9cc4bdb8ec1e3f0feddd41bf9d296d6 https://git.kernel.org/stable/c/34b567868777e9fd39ec5333969728a7f0cf179c • CWE-476: NULL Pointer Dereference •

CVSS: 5.5EPSS: 0%CPEs: 9EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: do_sys_name_to_handle(): use kzalloc() to fix kernel-infoleak syzbot identified a kernel information leak vulnerability in do_sys_name_to_handle() and issued the following report [1]. [1] "BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x100 lib/usercopy.c:40 instrument_copy_to_user include/linux/instrumented.h:114 [inline] _copy_to_user+0xbc/0x100 lib/usercopy.c:40 copy_to_user include/linux/uaccess.h:191 [inline] do_sys_name_to_handle fs/fhandle.c:73 [inline] __do_sys_name_to_handle_at fs/fhandle.c:112 [inline] __se_sys_name_to_handle_at+0x949/0xb10 fs/fhandle.c:94 __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94 ... Uninit was created at: slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [inline] __kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517 __do_kmalloc_node mm/slab_common.c:1006 [inline] __kmalloc+0x121/0x3c0 mm/slab_common.c:1020 kmalloc include/linux/slab.h:604 [inline] do_sys_name_to_handle fs/fhandle.c:39 [inline] __do_sys_name_to_handle_at fs/fhandle.c:112 [inline] __se_sys_name_to_handle_at+0x441/0xb10 fs/fhandle.c:94 __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94 ... Bytes 18-19 of 20 are uninitialized Memory access of size 20 starts at ffff888128a46380 Data copied to user address 0000000020000240" Per Chuck Lever's suggestion, use kzalloc() instead of kmalloc() to solve the problem. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: do_sys_name_to_handle(): use kzalloc() para reparar kernel-infoleak syzbot identificó una vulnerabilidad de fuga de información del kernel en do_sys_name_to_handle() y emitió el siguiente informe [1]. [1] "ERROR: KMSAN: kernel-infoleak en instrument_copy_to_user include/linux/instrumented.h:114 [en línea] ERROR: KMSAN: kernel-infoleak en _copy_to_user+0xbc/0x100 lib/usercopy.c:40 instrument_copy_to_user include/linux/ instrumented.h:114 [en línea] _copy_to_user+0xbc/0x100 lib/usercopy.c:40 copy_to_user include/linux/uaccess.h:191 [en línea] do_sys_name_to_handle fs/fhandle.c:73 [en línea] __do_sys_name_to_handle_at fs/fhandle.c :112 [en línea] __se_sys_name_to_handle_at+0x949/0xb10 fs/fhandle.c:94 __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94 ... Uninit se creó en: slab_post_alloc_hook+0x129/0xa70 mm/slab.h: 768 losa_alloc_nodo mm/slub.c:3478 [en línea] __kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517 __do_kmalloc_node mm/slab_common.c:1006 [en línea] __kmalloc+0x121/0x3c0 mm/slab_common.c:1020 kmalloc include/linux/ slab.h:604 [en línea] do_sys_name_to_handle fs/fhandle.c:39 [en línea] __do_sys_name_to_handle_at fs/fhandle.c:112 [en línea] __se_sys_name_to_handle_at+0x441/0xb10 fs/fhandle.c:94 _handle_at+0xe4/0x140 fs/fhandle .c:94 ... Los bytes 18-19 de 20 no están inicializados El acceso a la memoria de tamaño 20 comienza en ffff888128a46380 Datos copiados a la dirección de usuario 0000000020000240" Según la sugerencia de Chuck Lever, use kzalloc() en lugar de kmalloc() para resolver el problema. • https://git.kernel.org/stable/c/990d6c2d7aee921e3bce22b2d6a750fd552262be https://git.kernel.org/stable/c/4bac28f441e3cc9d3f1a84c8d023228a68d8a7c1 https://git.kernel.org/stable/c/772a7def9868091da3bcb0d6c6ff9f0c03d7fa8b https://git.kernel.org/stable/c/cde76b3af247f615447bcfecf610bb76c3529126 https://git.kernel.org/stable/c/423b6bdf19bbc5e1f7e7461045099917378f7e71 https://git.kernel.org/stable/c/e6450d5e46a737a008b4885aa223486113bf0ad6 https://git.kernel.org/stable/c/c1362eae861db28b1608b9dc23e49634fe87b63b https://git.kernel.org/stable/c/cba138f1ef37ec6f961baeab62f312ded • CWE-402: Transmission of Private Resources into a New Sphere ('Resource Leak') CWE-908: Use of Uninitialized Resource •

CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: md: fix kmemleak of rdev->serial If kobject_add() is fail in bind_rdev_to_array(), 'rdev->serial' will be alloc not be freed, and kmemleak occurs. unreferenced object 0xffff88815a350000 (size 49152): comm "mdadm", pid 789, jiffies 4294716910 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc f773277a): [<0000000058b0a453>] kmemleak_alloc+0x61/0xe0 [<00000000366adf14>] __kmalloc_large_node+0x15e/0x270 [<000000002e82961b>] __kmalloc_node.cold+0x11/0x7f [<00000000f206d60a>] kvmalloc_node+0x74/0x150 [<0000000034bf3363>] rdev_init_serial+0x67/0x170 [<0000000010e08fe9>] mddev_create_serial_pool+0x62/0x220 [<00000000c3837bf0>] bind_rdev_to_array+0x2af/0x630 [<0000000073c28560>] md_add_new_disk+0x400/0x9f0 [<00000000770e30ff>] md_ioctl+0x15bf/0x1c10 [<000000006cfab718>] blkdev_ioctl+0x191/0x3f0 [<0000000085086a11>] vfs_ioctl+0x22/0x60 [<0000000018b656fe>] __x64_sys_ioctl+0xba/0xe0 [<00000000e54e675e>] do_syscall_64+0x71/0x150 [<000000008b0ad622>] entry_SYSCALL_64_after_hwframe+0x6c/0x74 En el kernel de Linux, se resolvió la siguiente vulnerabilidad: md: corrige kmemleak de rdev-&gt;serial Si kobject_add() falla en bind_rdev_to_array(), 'rdev-&gt;serial' se asignará y no se liberará, y se produce kmemleak. objeto sin referencia 0xffff88815a350000 (tamaño 49152): comm "mdadm", pid 789, jiffies 4294716910 volcado hexadecimal (primeros 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ retroceso (crc f773277a): [&lt;0000000058b0a453&gt; ] kmemleak_alloc+0x61/0xe0 [&lt;00000000366adf14&gt;] __kmalloc_large_node+0x15e/0x270 [&lt;000000002e82961b&gt;] __kmalloc_node.cold+0x11/0x7f [&lt;00000000f206d60a&gt;] loc_node+0x74/0x150 [&lt;0000000034bf3363&gt;] rdev_init_serial+0x67/0x170 [&lt; 0000000010e08fe9&gt;] mddev_create_serial_pool+0x62/0x220 [&lt;00000000c3837bf0&gt;] bind_rdev_to_array+0x2af/0x630 [&lt;0000000073c28560&gt;] md_add_new_disk+0x400/0x9f0 00000000770e30ff&gt;] md_ioctl+0x15bf/0x1c10 [&lt;000000006cfab718&gt;] blkdev_ioctl+0x191/0x3f0 [&lt; 0000000085086a11&gt;] vfs_ioctl+0x22/0x60 [&lt;0000000018b656fe&gt;] __x64_sys_ioctl+0xba/0xe0 [&lt;00000000e54e675e&gt;] do_syscall_64+0x71/0x150 [&lt;00000 0008b0ad622&gt;] entrada_SYSCALL_64_after_hwframe+0x6c/0x74 • https://git.kernel.org/stable/c/963c555e75b033202dd76cf6325a7b7c83d08d5f https://git.kernel.org/stable/c/fb5b347efd1bda989846ffc74679d181222fb123 https://git.kernel.org/stable/c/f3a1787dc48213f6caea5ba7d47e0222e7fa34a9 https://git.kernel.org/stable/c/beaf11969fd5cbe6f09cefaa34df1ce8578e8dd9 https://git.kernel.org/stable/c/9fd0198f7ef06ae0d6636fb0578560857dead995 https://git.kernel.org/stable/c/6d32c832a88513f65c2c2c9c75954ee8b387adea https://git.kernel.org/stable/c/4c1021ce46fc2fb6115f7e79d353941e6dcad366 https://git.kernel.org/stable/c/6cf350658736681b9d6b0b6e58c5c76b2 • CWE-401: Missing Release of Memory after Effective Lifetime •

CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: block: fix deadlock between bd_link_disk_holder and partition scan 'open_mutex' of gendisk is used to protect open/close block devices. But in bd_link_disk_holder(), it is used to protect the creation of symlink between holding disk and slave bdev, which introduces some issues. When bd_link_disk_holder() is called, the driver is usually in the process of initialization/modification and may suspend submitting io. At this time, any io hold 'open_mutex', such as scanning partitions, can cause deadlocks. For example, in raid: T1 T2 bdev_open_by_dev lock open_mutex [1] ... efi_partition ... md_submit_bio md_ioctl mddev_syspend -> suspend all io md_add_new_disk bind_rdev_to_array bd_link_disk_holder try lock open_mutex [2] md_handle_request -> wait mddev_resume T1 scan partition, T2 add a new device to raid. T1 waits for T2 to resume mddev, but T2 waits for open_mutex held by T1. • https://git.kernel.org/stable/c/1b0a2d950ee2a54aa04fb31ead32144be0bbf690 https://git.kernel.org/stable/c/1e5c5b0abaee7b62a10b9707a62083b71ad21f62 https://git.kernel.org/stable/c/5a87c1f7993bc8ac358a3766bac5dc7126e01e98 https://git.kernel.org/stable/c/03f12122b20b6e6028e9ed69030a49f9cffcbb75 • CWE-667: Improper Locking •

CVSS: 7.8EPSS: 0%CPEs: 9EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: aoe: fix the potential use-after-free problem in aoecmd_cfg_pkts This patch is against CVE-2023-6270. The description of cve is: A flaw was found in the ATA over Ethernet (AoE) driver in the Linux kernel. The aoecmd_cfg_pkts() function improperly updates the refcnt on `struct net_device`, and a use-after-free can be triggered by racing between the free on the struct and the access through the `skbtxq` global queue. This could lead to a denial of service condition or potential code execution. In aoecmd_cfg_pkts(), it always calls dev_put(ifp) when skb initial code is finished. But the net_device ifp will still be used in later tx()->dev_queue_xmit() in kthread. • https://git.kernel.org/stable/c/7562f876cd93800f2f8c89445f2a563590b24e09 https://git.kernel.org/stable/c/ad80c34944d7175fa1f5c7a55066020002921a99 https://git.kernel.org/stable/c/1a54aa506b3b2f31496731039e49778f54eee881 https://git.kernel.org/stable/c/faf0b4c5e00bb680e8e43ac936df24d3f48c8e65 https://git.kernel.org/stable/c/7dd09fa80b0765ce68bfae92f4e2f395ccf0fba4 https://git.kernel.org/stable/c/74ca3ef68d2f449bc848c0a814cefc487bf755fa https://git.kernel.org/stable/c/eb48680b0255a9e8a9bdc93d6a55b11c31262e62 https://git.kernel.org/stable/c/079cba4f4e307c69878226fdf5228c20a • CWE-416: Use After Free •