Page 358 of 2581 results (0.014 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: ARM: 9359/1: flush: check if the folio is reserved for no-mapping addresses Since commit a4d5613c4dc6 ("arm: extend pfn_valid to take into account freed memory map alignment") changes the semantics of pfn_valid() to check presence of the memory map for a PFN. A valid page for an address which is reserved but not mapped by the kernel[1], the system crashed during some uio test with the following memory layout: node 0: [mem 0x00000000c0a00000-0x00000000cc8fffff] node 0: [mem 0x00000000d0000000-0x00000000da1fffff] the uio layout is:0xc0900000, 0x100000 the crash backtrace like: Unable to handle kernel paging request at virtual address bff00000 [...] CPU: 1 PID: 465 Comm: startapp.bin Tainted: G O 5.10.0 #1 Hardware name: Generic DT based system PC is at b15_flush_kern_dcache_area+0x24/0x3c LR is at __sync_icache_dcache+0x6c/0x98 [...] (b15_flush_kern_dcache_area) from (__sync_icache_dcache+0x6c/0x98) (__sync_icache_dcache) from (set_pte_at+0x28/0x54) (set_pte_at) from (remap_pfn_range+0x1a0/0x274) (remap_pfn_range) from (uio_mmap+0x184/0x1b8 [uio]) (uio_mmap [uio]) from (__mmap_region+0x264/0x5f4) (__mmap_region) from (__do_mmap_mm+0x3ec/0x440) (__do_mmap_mm) from (do_mmap+0x50/0x58) (do_mmap) from (vm_mmap_pgoff+0xfc/0x188) (vm_mmap_pgoff) from (ksys_mmap_pgoff+0xac/0xc4) (ksys_mmap_pgoff) from (ret_fast_syscall+0x0/0x5c) Code: e0801001 e2423001 e1c00003 f57ff04f (ee070f3e) ---[ end trace 09cf0734c3805d52 ]--- Kernel panic - not syncing: Fatal exception So check if PG_reserved was set to solve this issue. [1]: https://lore.kernel.org/lkml/Zbtdue57RO0QScJM@linux.ibm.com/ En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ARM: 9359/1: descarga: verifique si la publicación está reservada para direcciones sin asignación. Desde el commit a4d5613c4dc6 ("arm: extienda pfn_valid para tener en cuenta la alineación del mapa de memoria liberada") cambia la semántica de pfn_valid() para verificar la presencia del mapa de memoria para un PFN. A valid page for an address which is reserved but not mapped by the kernel[1], the system crashed during some uio test with the following memory layout: node 0: [mem 0x00000000c0a00000-0x00000000cc8fffff] node 0: [mem 0x00000000d0000000-0x00000000da1fffff] el diseño de uio es? 0xc0900000, 0x100000 el seguimiento del fallo es como: No se puede manejar la solicitud de paginación del kernel en la dirección virtual bff00000 [...] • https://git.kernel.org/stable/c/a4d5613c4dc6d413e0733e37db9d116a2a36b9f3 https://git.kernel.org/stable/c/6026d4032dbbe3d7f4ac2c8daa923fe74dcf41c4 https://git.kernel.org/stable/c/65c578935bcc26ddc04e6757b2c7be95bf235b31 https://git.kernel.org/stable/c/0c027c2bad7f5111c51a358b5d392e1a695dabff https://git.kernel.org/stable/c/9f7ddc222cae8254e93d5c169a8ae11a49d912a7 https://git.kernel.org/stable/c/fb3a122a978626b33de3367ee1762da934c0f512 https://git.kernel.org/stable/c/0c66c6f4e21cb22220cbd8821c5c73fc157d20dc https://access.redhat.com/security/cve/CVE-2024-26947 • CWE-439: Behavioral Change in New Version or Environment •

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

In the Linux kernel, the following vulnerability has been resolved: kprobes/x86: Use copy_from_kernel_nofault() to read from unsafe address Read from an unsafe address with copy_from_kernel_nofault() in arch_adjust_kprobe_addr() because this function is used before checking the address is in text or not. Syzcaller bot found a bug and reported the case if user specifies inaccessible data area, arch_adjust_kprobe_addr() will cause a kernel panic. [ mingo: Clarified the comment. ] En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: kprobes/x86: use copy_from_kernel_nofault() para leer desde una dirección no segura Lea desde una dirección no segura con copy_from_kernel_nofault() en arch_adjust_kprobe_addr() porque esta función se usa antes de verificar que la dirección esté en texto O no. El bot Syzcaller encontró un error e informó el caso si el usuario especifica un área de datos inaccesible, arch_adjust_kprobe_addr() provocará un pánico en el kernel. [ mingo: Aclaró el comentario. ] An unsafe read function was found in arch/x86/kernel/kprobes/core.c in the Linux kernel . • https://git.kernel.org/stable/c/cc66bb91457827f62e2b6cb2518666820f0a6c48 https://git.kernel.org/stable/c/6417684315087904fffe8966d27ca74398c57dd6 https://git.kernel.org/stable/c/f13edd1871d4fb4ab829aff629d47914e251bae3 https://git.kernel.org/stable/c/20fdb21eabaeb8f78f8f701f56d14ea0836ec861 https://git.kernel.org/stable/c/b69f577308f1070004cafac106dd1a44099e5483 https://git.kernel.org/stable/c/4e51653d5d871f40f1bd5cf95cc7f2d8b33d063b https://access.redhat.com/security/cve/CVE-2024-26946 https://bugzilla.redhat.com/show_bug.cgi?id=2278206 •

CVSS: 8.4EPSS: 0%CPEs: 2EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: crypto: iaa - Fix nr_cpus < nr_iaa case If nr_cpus < nr_iaa, the calculated cpus_per_iaa will be 0, which causes a divide-by-0 in rebalance_wq_table(). Make sure cpus_per_iaa is 1 in that case, and also in the nr_iaa == 0 case, even though cpus_per_iaa is never used if nr_iaa == 0, for paranoia. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: crypto: iaa - Corrige el caso nr_cpus &lt; nr_iaa Si nr_cpus &lt; nr_iaa, el cpus_per_iaa calculado será 0, lo que provoca una división por 0 en rebalance_wq_table(). Asegúrese de que cpus_per_iaa sea 1 en ese caso, y también en el caso de nr_iaa == 0, aunque cpus_per_iaa nunca se use si nr_iaa == 0, para paranoia. • https://git.kernel.org/stable/c/a5ca1be7f9817de4e93085778b3ee2219bdc2664 https://git.kernel.org/stable/c/5a7e89d3315d1be86aff8a8bf849023cda6547f7 • CWE-369: Divide By Zero •

CVSS: -EPSS: 0%CPEs: 2EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: btrfs: zoned: fix use-after-free in do_zone_finish() Shinichiro reported the following use-after-free triggered by the device replace operation in fstests btrfs/070. BTRFS info (device nullb1): scrub: finished on devid 1 with status: 0 ================================================================== BUG: KASAN: slab-use-after-free in do_zone_finish+0x91a/0xb90 [btrfs] Read of size 8 at addr ffff8881543c8060 by task btrfs-cleaner/3494007 CPU: 0 PID: 3494007 Comm: btrfs-cleaner Tainted: G W 6.8.0-rc5-kts #1 Hardware name: Supermicro Super Server/X11SPi-TF, BIOS 3.3 02/21/2020 Call Trace: <TASK> dump_stack_lvl+0x5b/0x90 print_report+0xcf/0x670 ? __virt_addr_valid+0x200/0x3e0 kasan_report+0xd8/0x110 ? do_zone_finish+0x91a/0xb90 [btrfs] ? do_zone_finish+0x91a/0xb90 [btrfs] do_zone_finish+0x91a/0xb90 [btrfs] btrfs_delete_unused_bgs+0x5e1/0x1750 [btrfs] ? __pfx_btrfs_delete_unused_bgs+0x10/0x10 [btrfs] ? • https://git.kernel.org/stable/c/34ca809e055eca5cfe63d9c7efbf80b7c21b4e57 https://git.kernel.org/stable/c/1ec17ef59168a1a6f1105f5dc517f783839a5302 •

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

In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Create debugfs ttm_resource_manager entry only if needed The driver creates /sys/kernel/debug/dri/0/mob_ttm even when the corresponding ttm_resource_manager is not allocated. This leads to a crash when trying to read from this file. Add a check to create mob_ttm, system_mob_ttm, and gmr_ttm debug file only when the corresponding ttm_resource_manager is allocated. crash> bt PID: 3133409 TASK: ffff8fe4834a5000 CPU: 3 COMMAND: "grep" #0 [ffffb954506b3b20] machine_kexec at ffffffffb2a6bec3 #1 [ffffb954506b3b78] __crash_kexec at ffffffffb2bb598a #2 [ffffb954506b3c38] crash_kexec at ffffffffb2bb68c1 #3 [ffffb954506b3c50] oops_end at ffffffffb2a2a9b1 #4 [ffffb954506b3c70] no_context at ffffffffb2a7e913 #5 [ffffb954506b3cc8] __bad_area_nosemaphore at ffffffffb2a7ec8c #6 [ffffb954506b3d10] do_page_fault at ffffffffb2a7f887 #7 [ffffb954506b3d40] page_fault at ffffffffb360116e [exception RIP: ttm_resource_manager_debug+0x11] RIP: ffffffffc04afd11 RSP: ffffb954506b3df0 RFLAGS: 00010246 RAX: ffff8fe41a6d1200 RBX: 0000000000000000 RCX: 0000000000000940 RDX: 0000000000000000 RSI: ffffffffc04b4338 RDI: 0000000000000000 RBP: ffffb954506b3e08 R8: ffff8fee3ffad000 R9: 0000000000000000 R10: ffff8fe41a76a000 R11: 0000000000000001 R12: 00000000ffffffff R13: 0000000000000001 R14: ffff8fe5bb6f3900 R15: ffff8fe41a6d1200 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #8 [ffffb954506b3e00] ttm_resource_manager_show at ffffffffc04afde7 [ttm] #9 [ffffb954506b3e30] seq_read at ffffffffb2d8f9f3 RIP: 00007f4c4eda8985 RSP: 00007ffdbba9e9f8 RFLAGS: 00000246 RAX: ffffffffffffffda RBX: 000000000037e000 RCX: 00007f4c4eda8985 RDX: 000000000037e000 RSI: 00007f4c41573000 RDI: 0000000000000003 RBP: 000000000037e000 R8: 0000000000000000 R9: 000000000037fe30 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f4c41573000 R13: 0000000000000003 R14: 00007f4c41572010 R15: 0000000000000003 ORIG_RAX: 0000000000000000 CS: 0033 SS: 002b En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/vmwgfx: cree la entrada debugfs ttm_resource_manager solo si es necesario. El controlador crea /sys/kernel/debug/dri/0/mob_ttm incluso cuando el ttm_resource_manager correspondiente no está asignado. Esto provoca un bloqueo al intentar leer este archivo. Agregue una marca para crear archivos de depuración mob_ttm, system_mob_ttm y gmr_ttm solo cuando se asigne el ttm_resource_manager correspondiente. crash&gt; bt PID: 3133409 TAREA: ffff8fe4834a5000 CPU: 3 COMANDO: "grep" #0 [ffffb954506b3b20] machine_kexec en ffffffffb2a6bec3 #1 [ffffb954506b3b78] __crash_kexec en ffffffffb2bb598a #2 ffb954506b3c38] crash_kexec en ffffffffb2bb68c1 #3 [ffffb954506b3c50] oops_end en ffffffffb2a2a9b1 # 4 [ffffb954506b3c70] no_context en ffffffffb2a7e913 #5 [ffffb954506b3cc8] __bad_area_nosemaphore en ffffffffb2a7ec8c #6 [ffffb954506b3d10] do_page_fault en ffffffffb2a7f887 #7 54506b3d40] page_fault en ffffffffb360116e [excepción RIP: ttm_resource_manager_debug+0x11] RIP: ffffffffc04afd11 RSP: ffffb954506b3df0 RFLAGS: 00010246 RAX: ffff8fe41a6d1200 RBX: 0000000000000000 RCX: 0000000000000940 RDX: 0000000000000000 RSI: ffffffffc04b4338 RDI: 0000000000000000 RBP: ffffb9545 06b3e08 R8: ffff8fee3ffad000 R9: 0000000000000000 R10: ffff8fe41a76a000 R11: 0000000000000001 R12: 00000000ffffffff R13: 0000000000000001 R14: ffff8fe5bb6f3900 R15: ffff8fe41a6d1200 ORIG_RAX: ffffffffffffff CS: 0010 SS : 0018 #8 [ffffb954506b3e00] ttm_resource_manager_show en ffffffffc04afde7 [ttm] #9 [ffffb954506b3e30] seq_read en ffffffffb2d8f9f3 RIP: 00007f4c4eda8985 RSP: RFLAGS: 00000246 RAX: ffffffffffffffda RBX: 000000000037e000 RCX: 00007f4c4eda8985 RDX: 000000000037e000 RSI: 00007f4c41573000 RDI: 00000000000000 03 PBR: 000000000037e000 R8: 0000000000000000 R9: 000000000037fe30 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f4c41573000 R13: 0000000000000003 R14: 00007f4c41572010 R15: 0000000000000003 ORIG_RAX: 0000000000000000 CS: 0033 SS: 002b A flaw was found in the vmwgfx module in the Linux kernel. Trying to read the /sys/kernel/debug/dri/0/mob_ttm file when the ttm_resource_manager is not allocated will cause a crash, resulting in a denial of service. • https://git.kernel.org/stable/c/af4a25bbe5e7e60ff696ef5c1ec48ab2d51c17c6 https://git.kernel.org/stable/c/016119154981d81c9e8f2ea3f56b9e2b4ea14500 https://git.kernel.org/stable/c/042ef0afc40fa1a22b3608f22915b91ce39d128f https://git.kernel.org/stable/c/25e3ce59c1200f1f0563e39de151f34962ab0fe1 https://git.kernel.org/stable/c/eb08db0fc5354fa17b7ed66dab3c503332423451 https://git.kernel.org/stable/c/4be9075fec0a639384ed19975634b662bfab938f https://access.redhat.com/security/cve/CVE-2024-26940 https://bugzilla.redhat.com/show_bug.cgi?id=2278218 • CWE-20: Improper Input Validation •