Page 238 of 3392 results (0.023 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: rcu-tasks: Fix show_rcu_tasks_trace_gp_kthread buffer overflow There is a possibility of buffer overflow in show_rcu_tasks_trace_gp_kthread() if counters, passed to sprintf() are huge. Counter numbers, needed for this are unrealistically high, but buffer overflow is still possible. Use snprintf() with buffer size instead of sprintf(). Found by Linux Verification Center (linuxtesting.org) with SVACE. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rcu-tasks: Corrige show_rcu_tasks_trace_gp_kthread desbordamiento del búfer. Existe la posibilidad de que se produzca un desbordamiento del búfer en show_rcu_tasks_trace_gp_kthread() si los contadores pasados a sprintf() son enormes. Los números de contador necesarios para esto son excesivamente altos, pero aún es posible un desbordamiento del búfer. • https://git.kernel.org/stable/c/edf3775f0ad66879796f594983163f672c4bf1a2 https://git.kernel.org/stable/c/17c43211d45f13d1badea3942b76bf16bcc49281 https://git.kernel.org/stable/c/af7b560c88fb420099e29890aa682b8a3efc8784 https://git.kernel.org/stable/c/08186d0c5fb64a1cc4b43e009314ee6b173ed222 https://git.kernel.org/stable/c/32d988f48ed287e676a29a15ac30701c35849aec https://git.kernel.org/stable/c/6593d857ce5b5b802fb73d8091ac9c84b92c1697 https://git.kernel.org/stable/c/1a240e138071b25944ded0f5b3e357aa99fabcb7 https://git.kernel.org/stable/c/cc5645fddb0ce28492b15520306d09273 •

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

In the Linux kernel, the following vulnerability has been resolved: cppc_cpufreq: Fix possible null pointer dereference cppc_cpufreq_get_rate() and hisi_cppc_cpufreq_get_rate() can be called from different places with various parameters. So cpufreq_cpu_get() can return null as 'policy' in some circumstances. Fix this bug by adding null return check. Found by Linux Verification Center (linuxtesting.org) with SVACE. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cppc_cpufreq: se corrige la posible desreferencia del puntero nulo. cppc_cpufreq_get_rate() y hisi_cppc_cpufreq_get_rate() se pueden llamar desde diferentes lugares con varios parámetros. Entonces cpufreq_cpu_get() puede devolver nulo como 'política' en algunas circunstancias. Corrija este error agregando una verificación de devolución nula. • https://git.kernel.org/stable/c/a28b2bfc099c6b9caa6ef697660408e076a32019 https://git.kernel.org/stable/c/9a185cc5a79ba408e1c73375706630662304f618 https://git.kernel.org/stable/c/769c4f355b7962895205b86ad35617873feef9a5 https://git.kernel.org/stable/c/f84b9b25d045e67a7eee5e73f21278c8ab06713c https://git.kernel.org/stable/c/b18daa4ec727c0266de5bfc78e818d168cc4aedf https://git.kernel.org/stable/c/dfec15222529d22b15e5b0d63572a9e39570cab4 https://git.kernel.org/stable/c/cf7de25878a1f4508c69dc9f6819c21ba177dbfe https://access.redhat.com/security/cve/CVE-2024-38573 • CWE-476: NULL Pointer Dereference •

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

In the Linux kernel, the following vulnerability has been resolved: thermal/drivers/tsens: Fix null pointer dereference compute_intercept_slope() is called from calibrate_8960() (in tsens-8960.c) as compute_intercept_slope(priv, p1, NULL, ONE_PT_CALIB) which lead to null pointer dereference (if DEBUG or DYNAMIC_DEBUG set). Fix this bug by adding null pointer check. Found by Linux Verification Center (linuxtesting.org) with SVACE. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Thermal/drivers/tsens: se corrigió la desreferencia del puntero nulo Compute_intercept_slope() se llama desde calibrate_8960() (en tsens-8960.c) como Compute_intercept_slope(priv, p1, NULL, ONE_PT_CALIB) lo que conduce a la desreferencia del puntero nulo (si DEBUG o DYNAMIC_DEBUG están configurados). Corrija este error agregando una verificación de puntero nulo. Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE. • https://git.kernel.org/stable/c/dfc1193d4dbd6c3cb68c944413146c940bde290a https://git.kernel.org/stable/c/27600e0c5272a262b0903e35ae1df37d33c5c1ad https://git.kernel.org/stable/c/11c731386ed82053c2759b6fea1a82ae946e5e0f https://git.kernel.org/stable/c/2d5ca6e4a2872e92a32fdfd87e04dd7d3ced7278 https://git.kernel.org/stable/c/06d17744b77bc6cb29a6c785f4fad8c4163ee653 https://git.kernel.org/stable/c/fcf5f1b5f308f2eb422f6aca55d295b25890906b https://git.kernel.org/stable/c/d998ddc86a27c92140b9f7984ff41e3d1d07a48f •

CVSS: 5.8EPSS: 0%CPEs: 4EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: gfs2: Fix potential glock use-after-free on unmount When a DLM lockspace is released and there ares still locks in that lockspace, DLM will unlock those locks automatically. Commit fb6791d100d1b started exploiting this behavior to speed up filesystem unmount: gfs2 would simply free glocks it didn't want to unlock and then release the lockspace. This didn't take the bast callbacks for asynchronous lock contention notifications into account, which remain active until until a lock is unlocked or its lockspace is released. To prevent those callbacks from accessing deallocated objects, put the glocks that should not be unlocked on the sd_dead_glocks list, release the lockspace, and only then free those glocks. As an additional measure, ignore unexpected ast and bast callbacks if the receiving glock is dead. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: gfs2: soluciona el posible use-after-free de glock al desmontar Cuando se libera un espacio de bloqueo de DLM y todavía hay bloqueos en ese espacio de bloqueo, DLM desbloqueará esos bloqueos automáticamente. El commit fb6791d100d1b comenzó a explotar este comportamiento para acelerar el desmontaje del sistema de archivos: gfs2 simplemente liberaría las glocks que no quería desbloquear y luego liberaría el espacio de bloqueo. • https://git.kernel.org/stable/c/fb6791d100d1bba20b5cdbc4912e1f7086ec60f8 https://git.kernel.org/stable/c/0636b34b44589b142700ac137b5f69802cfe2e37 https://git.kernel.org/stable/c/e42e8a24d7f02d28763d16ca7ec5fc6d1f142af0 https://git.kernel.org/stable/c/501cd8fabf621d10bd4893e37f6ce6c20523c8ca https://git.kernel.org/stable/c/d98779e687726d8f8860f1c54b5687eec5f63a73 https://access.redhat.com/security/cve/CVE-2024-38570 https://bugzilla.redhat.com/show_bug.cgi?id=2293423 • CWE-416: Use After Free •

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

In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: add a proper sanity check for endpoints Syzkaller reports [1] hitting a warning which is caused by presence of a wrong endpoint type at the URB sumbitting stage. While there was a check for a specific 4th endpoint, since it can switch types between bulk and interrupt, other endpoints are trusted implicitly. Similar warning is triggered in a couple of other syzbot issues [2]. Fix the issue by doing a comprehensive check of all endpoints taking into account difference between high- and full-speed configuration. [1] Syzkaller report: ... WARNING: CPU: 0 PID: 4721 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504 ... Call Trace: <TASK> carl9170_usb_send_rx_irq_urb+0x273/0x340 drivers/net/wireless/ath/carl9170/usb.c:504 carl9170_usb_init_device drivers/net/wireless/ath/carl9170/usb.c:939 [inline] carl9170_usb_firmware_finish drivers/net/wireless/ath/carl9170/usb.c:999 [inline] carl9170_usb_firmware_step2+0x175/0x240 drivers/net/wireless/ath/carl9170/usb.c:1028 request_firmware_work_func+0x130/0x240 drivers/base/firmware_loader/main.c:1107 process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289 worker_thread+0x669/0x1090 kernel/workqueue.c:2436 kthread+0x2e8/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308 </TASK> [2] Related syzkaller crashes: En el kernel de Linux, se resolvió la siguiente vulnerabilidad: wifi: carl9170: agregue una verificación de integridad adecuada para los endpoints Syzkaller informa [1] que aparece una advertencia causada por la presencia de un tipo de endpoint incorrecto en la etapa de envío de URB. Si bien hubo una verificación para un cuarto endpoint específico, dado que puede cambiar de tipo entre masivo e interrupción, se confía implícitamente en otros endpoints. Se activa una advertencia similar en un par de otros problemas de syzbot [2]. Solucione el problema realizando una verificación exhaustiva de todos los endpoints teniendo en cuenta la diferencia entre la configuración de alta y máxima velocidad. [1] Informe de Syzkaller: ... • https://git.kernel.org/stable/c/a84fab3cbfdc427e7d366f1cc844f27b2084c26c https://git.kernel.org/stable/c/eb0f2fc3ff5806cc572cd9055ce7c52a01e97645 https://git.kernel.org/stable/c/ac3ed46a8741d464bc70ebdf7433c1d786cf329d https://git.kernel.org/stable/c/8650725bb0a48b206d5a8ddad3a7488f9a5985b7 https://git.kernel.org/stable/c/6a9892bf24c906b4d6b587f8759ca38bff672582 https://git.kernel.org/stable/c/265c3cda471c26e0f25d0c755da94e1eb15d7a0c https://git.kernel.org/stable/c/62eb07923f3693d55b0c2d9a5a4f1ad72cb6b8fd https://git.kernel.org/stable/c/03ddc74bdfd71b84a55c9f2185d8787f2 •