CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-38617 – kunit/fortify: Fix mismatched kvalloc()/vfree() usage
https://notcve.org/view.php?id=CVE-2024-38617
In the Linux kernel, the following vulnerability has been resolved: kunit/fortify: Fix mismatched kvalloc()/vfree() usage The kv*() family of tests were accidentally freeing with vfree() instead of kvfree(). Use kvfree() instead. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: kunit/fortify: corrige el uso no coincidente de kvalloc()/vfree() La familia de pruebas kv*() se liberaba accidentalmente con vfree() en lugar de kvfree(). Utilice kvfree() en su lugar. • https://git.kernel.org/stable/c/9124a26401483bf2b13a99cb4317dce3f677060f https://git.kernel.org/stable/c/7880dbf4eafe22a6a41a42e774f1122c814ed02d https://git.kernel.org/stable/c/42d21c9727028fe7ee392223ba127484b1b8677e https://git.kernel.org/stable/c/03758d5a0932016b6d5f5bfbca580177e6bc937a https://git.kernel.org/stable/c/998b18072ceb0613629c256b409f4d299829c7ec •
CVSS: 8.2EPSS: 0%CPEs: 5EXPL: 0CVE-2024-38616 – wifi: carl9170: re-fix fortified-memset warning
https://notcve.org/view.php?id=CVE-2024-38616
In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: re-fix fortified-memset warning The carl9170_tx_release() function sometimes triggers a fortified-memset warning in my randconfig builds: In file included from include/linux/string.h:254, from drivers/net/wireless/ath/carl9170/tx.c:40: In function 'fortify_memset_chk', inlined from 'carl9170_tx_release' at drivers/net/wireless/ath/carl9170/tx.c:283:2, inlined from 'kref_put' at include/linux/kref.h:65:3, inlined from 'carl9170_tx_put_skb' at drivers/net/wireless/ath/carl9170/tx.c:342:9: include/linux/fortify-string.h:493:25: error: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning] 493 | __write_overflow_field(p_size_field, size); Kees previously tried to avoid this by using memset_after(), but it seems this does not fully address the problem. I noticed that the memset_after() here is done on a different part of the union (status) than the original cast was from (rate_driver_data), which may confuse the compiler. Unfortunately, the memset_after() trick does not work on driver_rates[] because that is part of an anonymous struct, and I could not get struct_group() to do this either. Using two separate memset() calls on the two members does address the warning though. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: carl9170: volver a corregir la advertencia de memset fortificado La función carl9170_tx_release() a veces activa una advertencia de memset fortificado en mis compilaciones de randconfig: en el archivo incluido en include/linux/string. h:254, de drivers/net/wireless/ath/carl9170/tx.c:40: en la función 'fortify_memset_chk', insertado desde 'carl9170_tx_release' en drivers/net/wireless/ath/carl9170/tx.c:283:2 , incluido desde 'kref_put' en include/linux/kref.h:65:3, incluido desde 'carl9170_tx_put_skb' en drivers/net/wireless/ath/carl9170/tx.c:342:9: include/linux/fortify-string .h:493:25: error: llamada a '__write_overflow_field' declarada con advertencia de atributo: escritura detectada más allá del tamaño del campo (primer parámetro); ¿Quizás usar struct_group()? • https://git.kernel.org/stable/c/fb5f6a0e8063b7a84d6d44ef353846ccd7708d2e https://git.kernel.org/stable/c/13857683126e8a6492af73c74d702835f7a2175b https://git.kernel.org/stable/c/87586467098281f04fa93e59fe3a516b954bddc4 https://git.kernel.org/stable/c/0c38c9c460bb8ce8d6f6cf316e0d71a70983ec83 https://git.kernel.org/stable/c/042a39bb8e0812466327a5102606e88a5a4f8c02 https://git.kernel.org/stable/c/066afafc10c9476ee36c47c9062527a17e763901 • CWE-400: Uncontrolled Resource Consumption •
CVSS: 4.4EPSS: 0%CPEs: 8EXPL: 0CVE-2024-38615 – cpufreq: exit() callback is optional
https://notcve.org/view.php?id=CVE-2024-38615
In the Linux kernel, the following vulnerability has been resolved: cpufreq: exit() callback is optional The exit() callback is optional and shouldn't be called without checking a valid pointer first. Also, we must clear freq_table pointer even if the exit() callback isn't present. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cpufreq: la devolución de llamada exit() es opcional La devolución de llamada exit() es opcional y no debe llamarse sin verificar primero un puntero válido. Además, debemos borrar el puntero freq_table incluso si la devolución de llamada exit() no está presente. • https://git.kernel.org/stable/c/91a12e91dc39137906d929a4ff6f9c32c59697fa https://git.kernel.org/stable/c/2d730b465e377396d2a09a53524b96b111f7ccb6 https://git.kernel.org/stable/c/dfc56ff5ec9904c008e9376d90a6d7e2d2bec4d3 https://git.kernel.org/stable/c/35db5e76d5e9f752476df5fa0b9018a2398b0378 https://git.kernel.org/stable/c/8bc9546805e572ad101681437a49939f28777273 https://git.kernel.org/stable/c/3e99f060cfd2e36504d62c9132b453ade5027e1c https://git.kernel.org/stable/c/ae37ebca325097d773d7bb6ec069123b30772872 https://git.kernel.org/stable/c/a8204d1b6ff762d2171d365c2c8560285 • CWE-459: Incomplete Cleanup •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-38614 – openrisc: traps: Don't send signals to kernel mode threads
https://notcve.org/view.php?id=CVE-2024-38614
In the Linux kernel, the following vulnerability has been resolved: openrisc: traps: Don't send signals to kernel mode threads OpenRISC exception handling sends signals to user processes on floating point exceptions and trap instructions (for debugging) among others. There is a bug where the trap handling logic may send signals to kernel threads, we should not send these signals to kernel threads, if that happens we treat it as an error. This patch adds conditions to die if the kernel receives these exceptions in kernel mode code. En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: openrisc: trampas: no envía señales a subprocesos en modo kernel. El manejo de excepciones de OpenRISC envía señales a los procesos del usuario sobre excepciones de punto flotante e instrucciones de captura (para depuración), entre otros. Hay un error en el que la lógica de manejo de trampas puede enviar señales a los subprocesos del kernel. No debemos enviar estas señales a los subprocesos del kernel; si eso sucede, lo tratamos como un error. • https://git.kernel.org/stable/c/27267655c5313ba0f5a3caa9ad35d887d9a12574 https://git.kernel.org/stable/c/c0ed9a711e3392d73e857faa031d8d349c0d70db https://git.kernel.org/stable/c/075c0405b0d7d9fc490609e988a3af0069596538 https://git.kernel.org/stable/c/cea9d0015c140af39477dd5eeb9b20233a45daa9 https://git.kernel.org/stable/c/c88cfb5cea5f8f9868ef02cc9ce9183a26dcf20f •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-38613 – m68k: Fix spinlock race in kernel thread creation
https://notcve.org/view.php?id=CVE-2024-38613
In the Linux kernel, the following vulnerability has been resolved: m68k: Fix spinlock race in kernel thread creation Context switching does take care to retain the correct lock owner across the switch from 'prev' to 'next' tasks. This does rely on interrupts remaining disabled for the entire duration of the switch. This condition is guaranteed for normal process creation and context switching between already running processes, because both 'prev' and 'next' already have interrupts disabled in their saved copies of the status register. The situation is different for newly created kernel threads. The status register is set to PS_S in copy_thread(), which does leave the IPL at 0. Upon restoring the 'next' thread's status register in switch_to() aka resume(), interrupts then become enabled prematurely. resume() then returns via ret_from_kernel_thread() and schedule_tail() where run queue lock is released (see finish_task_switch() and finish_lock_switch()). A timer interrupt calling scheduler_tick() before the lock is released in finish_task_switch() will find the lock already taken, with the current task as lock owner. This causes a spinlock recursion warning as reported by Guenter Roeck. As far as I can ascertain, this race has been opened in commit 533e6903bea0 ("m68k: split ret_from_fork(), simplify kernel_thread()") but I haven't done a detailed study of kernel history so it may well predate that commit. Interrupts cannot be disabled in the saved status register copy for kernel threads (init will complain about interrupts disabled when finally starting user space). • https://git.kernel.org/stable/c/533e6903bea0440816a0f517b0845ccea4cc7917 https://git.kernel.org/stable/c/2a8d1d95302c7d52c6ac8fa5cb4a6948ae0d3a14 https://git.kernel.org/stable/c/5213cc01d0464c011fdc09f318705603ed3a746b https://git.kernel.org/stable/c/4eeffecc8e3cce25bb559502c2fd94a948bcde82 https://git.kernel.org/stable/c/77b2b67a0f8bce260c53907e5749d61466d90c87 https://git.kernel.org/stable/c/0d9ae1253535f6e85a016e09c25ecbe6f7f59ef0 https://git.kernel.org/stable/c/f3baf0f4f92af32943ebf27b960e0552c6c082fd https://git.kernel.org/stable/c/f1d4274a84c069be0f6098ab10c3443fc •