CVSS: 5.5EPSS: 0%CPEs: 9EXPL: 0CVE-2024-39475 – fbdev: savage: Handle err return when savagefb_check_var failed
https://notcve.org/view.php?id=CVE-2024-39475
In the Linux kernel, the following vulnerability has been resolved: fbdev: savage: Handle err return when savagefb_check_var failed The commit 04e5eac8f3ab("fbdev: savage: Error out if pixclock equals zero") checks the value of pixclock to avoid divide-by-zero error. However the function savagefb_probe doesn't handle the error return of savagefb_check_var. When pixclock is 0, it will cause divide-by-zero error. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fbdev: savage: Maneja el retorno de error cuando falla savagefb_check_var. El commit 04e5eac8f3ab("fbdev: savage: Error out if pixclock es igual a cero") verifica el valor de pixclock para evitar división por error cero. • https://git.kernel.org/stable/c/224453de8505aede1890f007be973925a3edf6a1 https://git.kernel.org/stable/c/84dce0f6a4cc5b7bfd7242ef9290db8ac1dd77ff https://git.kernel.org/stable/c/512ee6d6041e007ef5bf200c6e388e172a2c5b24 https://git.kernel.org/stable/c/8c54acf33e5adaad6374bf3ec1e3aff0591cc8e1 https://git.kernel.org/stable/c/070398d32c5f3ab0e890374904ad94551c76aec4 https://git.kernel.org/stable/c/bc3c2e58d73b28b9a8789fca84778ee165a72d13 https://git.kernel.org/stable/c/04e5eac8f3ab2ff52fa191c187a46d4fdbc1e288 https://git.kernel.org/stable/c/a9ca4e80d23474f90841251f4ac0d941f • CWE-369: Divide By Zero •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2024-39474 – mm/vmalloc: fix vmalloc which may return null if called with __GFP_NOFAIL
https://notcve.org/view.php?id=CVE-2024-39474
In the Linux kernel, the following vulnerability has been resolved: mm/vmalloc: fix vmalloc which may return null if called with __GFP_NOFAIL commit a421ef303008 ("mm: allow !GFP_KERNEL allocations for kvmalloc") includes support for __GFP_NOFAIL, but it presents a conflict with commit dd544141b9eb ("vmalloc: back off when the current task is OOM-killed"). A possible scenario is as follows: process-a __vmalloc_node_range(GFP_KERNEL | __GFP_NOFAIL) __vmalloc_area_node() vm_area_alloc_pages() --> oom-killer send SIGKILL to process-a if (fatal_signal_pending(current)) break; --> return NULL; To fix this, do not check fatal_signal_pending() in vm_area_alloc_pages() if __GFP_NOFAIL set. This issue occurred during OPLUS KASAN TEST. Below is part of the log -> oom-killer sends signal to process [65731.222840] [ T1308] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/apps/uid_10198,task=gs.intelligence,pid=32454,uid=10198 [65731.259685] [T32454] Call trace: [65731.259698] [T32454] dump_backtrace+0xf4/0x118 [65731.259734] [T32454] show_stack+0x18/0x24 [65731.259756] [T32454] dump_stack_lvl+0x60/0x7c [65731.259781] [T32454] dump_stack+0x18/0x38 [65731.259800] [T32454] mrdump_common_die+0x250/0x39c [mrdump] [65731.259936] [T32454] ipanic_die+0x20/0x34 [mrdump] [65731.260019] [T32454] atomic_notifier_call_chain+0xb4/0xfc [65731.260047] [T32454] notify_die+0x114/0x198 [65731.260073] [T32454] die+0xf4/0x5b4 [65731.260098] [T32454] die_kernel_fault+0x80/0x98 [65731.260124] [T32454] __do_kernel_fault+0x160/0x2a8 [65731.260146] [T32454] do_bad_area+0x68/0x148 [65731.260174] [T32454] do_mem_abort+0x151c/0x1b34 [65731.260204] [T32454] el1_abort+0x3c/0x5c [65731.260227] [T32454] el1h_64_sync_handler+0x54/0x90 [65731.260248] [T32454] el1h_64_sync+0x68/0x6c [65731.260269] [T32454] z_erofs_decompress_queue+0x7f0/0x2258 --> be->decompressed_pages = kvcalloc(be->nr_pages, sizeof(struct page *), GFP_KERNEL | __GFP_NOFAIL); kernel panic by NULL pointer dereference. erofs assume kvmalloc with __GFP_NOFAIL never return NULL. [65731.260293] [T32454] z_erofs_runqueue+0xf30/0x104c [65731.260314] [T32454] z_erofs_readahead+0x4f0/0x968 [65731.260339] [T32454] read_pages+0x170/0xadc [65731.260364] [T32454] page_cache_ra_unbounded+0x874/0xf30 [65731.260388] [T32454] page_cache_ra_order+0x24c/0x714 [65731.260411] [T32454] filemap_fault+0xbf0/0x1a74 [65731.260437] [T32454] __do_fault+0xd0/0x33c [65731.260462] [T32454] handle_mm_fault+0xf74/0x3fe0 [65731.260486] [T32454] do_mem_abort+0x54c/0x1b34 [65731.260509] [T32454] el0_da+0x44/0x94 [65731.260531] [T32454] el0t_64_sync_handler+0x98/0xb4 [65731.260553] [T32454] el0t_64_sync+0x198/0x19c En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/vmalloc: corrige vmalloc que puede devolver nulo si se llama con __GFP_NOFAIL commit a421ef303008 ("mm: permitir asignaciones !GFP_KERNEL para kvmalloc") incluye soporte para __GFP_NOFAIL, pero presenta un conflicto con el commit dd544141b9eb ("vmalloc: retroceda cuando la tarea actual sea eliminada por OOM"). • https://git.kernel.org/stable/c/9376130c390a76fac2788a5d6e1a149017b4ab50 https://git.kernel.org/stable/c/198a80833e3421d4c9820a4ae907120adf598c91 https://git.kernel.org/stable/c/c55d3564ad25ce87ab7cc6af251f9574faebd8da https://git.kernel.org/stable/c/758678b65164b2158fc1de411092191cb3c394d4 https://git.kernel.org/stable/c/8e0545c83d672750632f46e3f9ad95c48c91a0fc https://access.redhat.com/security/cve/CVE-2024-39474 https://bugzilla.redhat.com/show_bug.cgi?id=2296066 • CWE-476: NULL Pointer Dereference CWE-770: Allocation of Resources Without Limits or Throttling •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2024-39473 – ASoC: SOF: ipc4-topology: Fix input format query of process modules without base extension
https://notcve.org/view.php?id=CVE-2024-39473
In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: ipc4-topology: Fix input format query of process modules without base extension If a process module does not have base config extension then the same format applies to all of it's inputs and the process->base_config_ext is NULL, causing NULL dereference when specifically crafted topology and sequences used. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: SOF: ipc4-topology: arregla la consulta de formato de entrada de módulos de proceso sin extensión base. Si un módulo de proceso no tiene extensión de configuración base, entonces se aplica el mismo formato a todas sus entradas. y el proceso->base_config_ext es NULL, lo que provoca una desreferencia NULL cuando se utilizan secuencias y topologías manipuladas específicamente. • https://git.kernel.org/stable/c/648fea12847695d60ddeebea86597114885ee76e https://git.kernel.org/stable/c/e3ae00ee238bce6cfa5ad935c921181c14d18fd6 https://git.kernel.org/stable/c/9e16f17a2a0e97b43538b272e7071537a3e03368 https://git.kernel.org/stable/c/ffa077b2f6ad124ec3d23fbddc5e4b0ff2647af8 https://access.redhat.com/security/cve/CVE-2024-39473 https://bugzilla.redhat.com/show_bug.cgi?id=2296064 • CWE-476: NULL Pointer Dereference •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2024-39472 – xfs: fix log recovery buffer allocation for the legacy h_size fixup
https://notcve.org/view.php?id=CVE-2024-39472
In the Linux kernel, the following vulnerability has been resolved: xfs: fix log recovery buffer allocation for the legacy h_size fixup Commit a70f9fe52daa ("xfs: detect and handle invalid iclog size set by mkfs") added a fixup for incorrect h_size values used for the initial umount record in old xfsprogs versions. Later commit 0c771b99d6c9 ("xfs: clean up calculation of LR header blocks") cleaned up the log reover buffer calculation, but stoped using the fixed up h_size value to size the log recovery buffer, which can lead to an out of bounds access when the incorrect h_size does not come from the old mkfs tool, but a fuzzer. Fix this by open coding xlog_logrec_hblks and taking the fixed h_size into account for this calculation. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xfs: corrige la asignación del búfer de recuperación de registros para la corrección heredada de h_size. El commit a70f9fe52daa ("xfs: detecta y maneja el tamaño de iclog no válido establecido por mkfs") agregó una corrección para los valores incorrectos de h_size usados para el registro desmontaje inicial en versiones antiguas de xfsprogs. Posteriormente, el commit 0c771b99d6c9 ("xfs: cálculo de limpieza de bloques de encabezado LR") limpió el cálculo del búfer de recuperación de registros, pero dejó de usar el valor h_size fijo para dimensionar el búfer de recuperación de registros, lo que puede provocar un acceso fuera de los límites cuando el h_size incorrecto no proviene de la antigua herramienta mkfs, sino de un fuzzer. • https://git.kernel.org/stable/c/0c771b99d6c9a0552fea5cc43669b726dad8f659 https://git.kernel.org/stable/c/f754591b17d0ee91c2b45fe9509d0cdc420527cb https://git.kernel.org/stable/c/57835c0e7152e36b03875dd6c56dfeed685c1b1f https://git.kernel.org/stable/c/c2389c074973aa94e34992e7f66dac0de37595b5 https://git.kernel.org/stable/c/45cf976008ddef4a9c9a30310c9b4fb2a9a6602a https://access.redhat.com/security/cve/CVE-2024-39472 https://bugzilla.redhat.com/show_bug.cgi?id=2296067 • CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer CWE-770: Allocation of Resources Without Limits or Throttling •
CVSS: 4.4EPSS: 0%CPEs: 7EXPL: 0CVE-2024-39471 – drm/amdgpu: add error handle to avoid out-of-bounds
https://notcve.org/view.php?id=CVE-2024-39471
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: add error handle to avoid out-of-bounds if the sdma_v4_0_irq_id_to_seq return -EINVAL, the process should be stop to avoid out-of-bounds read, so directly return -EINVAL. • https://git.kernel.org/stable/c/5594971e02764aa1c8210ffb838cb4e7897716e8 https://git.kernel.org/stable/c/8112fa72b7f139052843ff484130d6f97e9f052f https://git.kernel.org/stable/c/ea906e9ac61e3152bef63597f2d9f4a812fc346a https://git.kernel.org/stable/c/011552f29f20842c9a7a21bffe1f6a2d6457ba46 https://git.kernel.org/stable/c/5b0a3dc3e87821acb80e841b464d335aff242691 https://git.kernel.org/stable/c/0964c84b93db7fbf74f357c1e20957850e092db3 https://git.kernel.org/stable/c/8b2faf1a4f3b6c748c0da36cda865a226534d520 https://access.redhat.com/security/cve/CVE-2024-39471 • CWE-125: Out-of-bounds Read •