Page 336 of 2173 results (0.009 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. ] • 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: -EPSS: 0%CPEs: 5EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: nouveau/dmem: handle kcalloc() allocation failure The kcalloc() in nouveau_dmem_evict_chunk() will return null if the physical memory has run out. As a result, if we dereference src_pfns, dst_pfns or dma_addrs, the null pointer dereference bugs will happen. Moreover, the GPU is going away. If the kcalloc() fails, we could not evict all pages mapping a chunk. So this patch adds a __GFP_NOFAIL flag in kcalloc(). Finally, as there is no need to have physically contiguous memory, this patch switches kcalloc() to kvcalloc() in order to avoid failing allocations. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nouveau/dmem: maneja el error de asignación de kcalloc() El kcalloc() en nouveau_dmem_evict_chunk() devolverá nulo si la memoria física se ha agotado. • https://git.kernel.org/stable/c/249881232e1471d28b68f9a3829acc14d150cf5d https://git.kernel.org/stable/c/9acfd8b083a0ffbd387566800d89f55058a68af2 https://git.kernel.org/stable/c/2a84744a037b8a511d6a9055f3defddc28ff4a4d https://git.kernel.org/stable/c/5e81773757a95fc298e96cfd6d4700f07b6192a2 https://git.kernel.org/stable/c/3e82f7383e0b82a835e6b6b06a348b2bc4e2c2ee https://git.kernel.org/stable/c/16e87fe23d4af6df920406494ced5c0f4354567b •