CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2023-52633 – um: time-travel: fix time corruption
https://notcve.org/view.php?id=CVE-2023-52633
In the Linux kernel, the following vulnerability has been resolved: um: time-travel: fix time corruption In 'basic' time-travel mode (without =inf-cpu or =ext), we still get timer interrupts. These can happen at arbitrary points in time, i.e. while in timer_read(), which pushes time forward just a little bit. Then, if we happen to get the interrupt after calculating the new time to push to, but before actually finishing that, the interrupt will set the time to a value that's incompatible with the forward, and we'll crash because time goes backwards when we do the forwarding. Fix this by reading the time_travel_time, calculating the adjustment, and doing the adjustment all with interrupts disabled. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: um: viaje en el tiempo: corrige la corrupción del tiempo En el modo de viaje en el tiempo 'básico' (sin =inf-cpu o =ext), todavía obtenemos interrupciones del temporizador. Esto puede suceder en momentos arbitrarios en el tiempo, es decir, mientras está en timer_read(), lo que adelanta un poco el tiempo. • https://git.kernel.org/stable/c/0c7478a2da3f5fe106b4658338873d50c86ac7ab https://git.kernel.org/stable/c/4f7dad73df4cdb2b7042103d3922745d040ad025 https://git.kernel.org/stable/c/de3e9d8e8d1ae0a4d301109d1ec140796901306c https://git.kernel.org/stable/c/b427f55e9d4185f6f17cc1e3296eb8d0c4425283 https://git.kernel.org/stable/c/abe4eaa8618bb36c2b33e9cdde0499296a23448c •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2023-52632 – drm/amdkfd: Fix lock dependency warning with srcu
https://notcve.org/view.php?id=CVE-2023-52632
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix lock dependency warning with srcu ====================================================== WARNING: possible circular locking dependency detected 6.5.0-kfd-yangp #2289 Not tainted ------------------------------------------------------ kworker/0:2/996 is trying to acquire lock: (srcu){.+.+}-{0:0}, at: __synchronize_srcu+0x5/0x1a0 but task is already holding lock: ((work_completion)(&svms->deferred_list_work)){+.+.}-{0:0}, at: process_one_work+0x211/0x560 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 ((work_completion)(&svms->deferred_list_work)){+.+.}-{0:0}: __flush_work+0x88/0x4f0 svm_range_list_lock_and_flush_work+0x3d/0x110 [amdgpu] svm_range_set_attr+0xd6/0x14c0 [amdgpu] kfd_ioctl+0x1d1/0x630 [amdgpu] __x64_sys_ioctl+0x88/0xc0 -> #2 (&info->lock#2){+.+.}-{3:3}: __mutex_lock+0x99/0xc70 amdgpu_amdkfd_gpuvm_restore_process_bos+0x54/0x740 [amdgpu] restore_process_helper+0x22/0x80 [amdgpu] restore_process_worker+0x2d/0xa0 [amdgpu] process_one_work+0x29b/0x560 worker_thread+0x3d/0x3d0 -> #1 ((work_completion)(&(&process->restore_work)->work)){+.+.}-{0:0}: __flush_work+0x88/0x4f0 __cancel_work_timer+0x12c/0x1c0 kfd_process_notifier_release_internal+0x37/0x1f0 [amdgpu] __mmu_notifier_release+0xad/0x240 exit_mmap+0x6a/0x3a0 mmput+0x6a/0x120 do_exit+0x322/0xb90 do_group_exit+0x37/0xa0 __x64_sys_exit_group+0x18/0x20 do_syscall_64+0x38/0x80 -> #0 (srcu){.+.+}-{0:0}: __lock_acquire+0x1521/0x2510 lock_sync+0x5f/0x90 __synchronize_srcu+0x4f/0x1a0 __mmu_notifier_release+0x128/0x240 exit_mmap+0x6a/0x3a0 mmput+0x6a/0x120 svm_range_deferred_list_work+0x19f/0x350 [amdgpu] process_one_work+0x29b/0x560 worker_thread+0x3d/0x3d0 other info that might help us debug this: Chain exists of: srcu --> &info->lock#2 --> (work_completion)(&svms->deferred_list_work) Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock((work_completion)(&svms->deferred_list_work)); lock(&info->lock#2); lock((work_completion)(&svms->deferred_list_work)); sync(srcu); En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdkfd: corrige la advertencia de dependencia de bloqueo con srcu ============================== ========================== ADVERTENCIA: posible dependencia de bloqueo circular detectada 6.5.0-kfd-yangp #2289 No contaminado ------ ------------------------------------------------ ktrabajador/ 0:2/996 está intentando adquirir el bloqueo: (srcu){.+.+}-{0:0}, en: __synchronize_srcu+0x5/0x1a0 pero la tarea ya mantiene el bloqueo: ((work_completion)(&svms->deferred_list_work )){+.+.}-{0:0}, en: Process_one_work+0x211/0x560 cuyo bloqueo ya depende del nuevo bloqueo. la cadena de dependencia existente (en orden inverso) es: -> #3 ((work_completion)(&svms->deferred_list_work)){+.+.}-{0:0}: __flush_work+0x88/0x4f0 svm_range_list_lock_and_flush_work+0x3d/0x110 [ amdgpu] svm_range_set_attr+0xd6/0x14c0 [amdgpu] kfd_ioctl+0x1d1/0x630 [amdgpu] __x64_sys_ioctl+0x88/0xc0 -> #2 (&info->lock#2){+.+.}-{3:3}: __mutex_lock+ 0x99/0xc70 amdgpu_amdkfd_gpuvm_restore_process_bos+0x54/0x740 [amdgpu] restaurar_proceso_helper+0x22/0x80 [amdgpu] restaurar_proceso_trabajador+0x2d/0xa0 [amdgpu] proceso_one_work+0x29b/0x560 trabajador_thread+0x3d/0x3d 0 -> #1 ((finalización_trabajo)(&(&proceso- >restore_work)->work)){+.+.}-{0:0}: __flush_work+0x88/0x4f0 __cancel_work_timer+0x12c/0x1c0 kfd_process_notifier_release_internal+0x37/0x1f0 [amdgpu] __mmu_notifier_release+0xad/0x240 exit_mmap+0x6a/0x3 a0 mmentrada +0x6a/0x120 do_exit+0x322/0xb90 do_group_exit+0x37/0xa0 __x64_sys_exit_group+0x18/0x20 do_syscall_64+0x38/0x80 -> #0 (srcu){.+.+}-{0:0}: __lock_acquire+0x1521/0x2 510 lock_sync +0x5f/0x90 __synchronize_srcu+0x4f/0x1a0 __mmu_notifier_release+0x128/0x240 exit_mmap+0x6a/0x3a0 mmput+0x6a/0x120 svm_range_deferred_list_work+0x19f/0x350 [amdgpu] Process_one_work+0x29b/0 x560 trabajador_thread+0x3d/0x3d0 otra información que podría ayudarnos a depurar esto : Existe cadena de: srcu --> &info->lock#2 --> (work_completion)(&svms->deferred_list_work) Posible escenario de bloqueo inseguro: CPU0 CPU1 ---- ---- lock((work_completion)(&svms- >lista_trabajo_diferido)); bloquear(&info->bloquear#2); lock((work_completion)(&svms->deferred_list_work)); sincronización(srcu); • https://git.kernel.org/stable/c/b602f098f716723fa5c6c96a486e0afba83b7b94 https://git.kernel.org/stable/c/752312f6a79440086ac0f9b08d7776870037323c https://git.kernel.org/stable/c/1556c242e64cdffe58736aa650b0b395854fe4d4 https://git.kernel.org/stable/c/2a9de42e8d3c82c6990d226198602be44f43f340 •
CVSS: 7.1EPSS: 0%CPEs: 5EXPL: 0CVE-2024-26668 – netfilter: nft_limit: reject configurations that cause integer overflow
https://notcve.org/view.php?id=CVE-2024-26668
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_limit: reject configurations that cause integer overflow Reject bogus configs where internal token counter wraps around. This only occurs with very very large requests, such as 17gbyte/s. Its better to reject this rather than having incorrect ratelimit. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: netfilter: nft_limit: rechazar configuraciones que causan desbordamiento de enteros Rechazar configuraciones falsas donde el contador de token interno se ajusta. Esto sólo ocurre con solicitudes muy grandes, como 17 gbytes/s. Es mejor rechazar esto en lugar de tener un límite de tasa incorrecto. • https://git.kernel.org/stable/c/d2168e849ebf617b2b7feae44c0c0baf739cb610 https://git.kernel.org/stable/c/79d4efd75e7dbecd855a3b8a63e65f7265f466e1 https://git.kernel.org/stable/c/bc6e242bb74e2ae616bfd2b250682b738e781c9b https://git.kernel.org/stable/c/9882495d02ecc490604f747437a40626dc9160d0 https://git.kernel.org/stable/c/00c2c29aa36d1d1827c51a3720e9f893a22c7c6a https://git.kernel.org/stable/c/c9d9eb9c53d37cdebbad56b91e40baf42d5a97aa https://access.redhat.com/security/cve/CVE-2024-26668 https://bugzilla.redhat.com/show_bug.cgi?id=2272797 • CWE-190: Integer Overflow or Wraparound •
CVSS: 6.0EPSS: 0%CPEs: 9EXPL: 0CVE-2024-26664 – hwmon: (coretemp) Fix out-of-bounds memory access
https://notcve.org/view.php?id=CVE-2024-26664
In the Linux kernel, the following vulnerability has been resolved: hwmon: (coretemp) Fix out-of-bounds memory access Fix a bug that pdata->cpu_map[] is set before out-of-bounds check. The problem might be triggered on systems with more than 128 cores per package. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: hwmon: (coretemp) Arreglar el acceso a memoria fuera de los límites Arreglar un error que pdata->cpu_map[] está configurado antes de la verificación de los límites. El problema podría surgir en sistemas con más de 128 núcleos por paquete. • https://git.kernel.org/stable/c/4f9dcadc55c21b39b072bb0882362c7edc4340bc https://git.kernel.org/stable/c/c00cdfc9bd767ee743ad3a4054de17aeb0afcbca https://git.kernel.org/stable/c/d9f0159da05df869071164edf0c6d7302efc5eca https://git.kernel.org/stable/c/30cf0dee372baf9b515f2d9c7218f905fddf3cdb https://git.kernel.org/stable/c/7108b80a542b9d65e44b36d64a700a83658c0b73 https://git.kernel.org/stable/c/d1de8e1ae924d9dc31548676e4a665b52ebee27e https://git.kernel.org/stable/c/93f0f4e846fcb682c3ec436e3b2e30e5a3a8ee6a https://git.kernel.org/stable/c/1eb74c00c9c3b13cb65e508c5d5a2f11a • CWE-125: Out-of-bounds Read •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-26663 – tipc: Check the bearer type before calling tipc_udp_nl_bearer_add()
https://notcve.org/view.php?id=CVE-2024-26663
In the Linux kernel, the following vulnerability has been resolved: tipc: Check the bearer type before calling tipc_udp_nl_bearer_add() syzbot reported the following general protection fault [1]: general protection fault, probably for non-canonical address 0xdffffc0000000010: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000080-0x0000000000000087] ... RIP: 0010:tipc_udp_is_known_peer+0x9c/0x250 net/tipc/udp_media.c:291 ... Call Trace: <TASK> tipc_udp_nl_bearer_add+0x212/0x2f0 net/tipc/udp_media.c:646 tipc_nl_bearer_add+0x21e/0x360 net/tipc/bearer.c:1089 genl_family_rcv_msg_doit+0x1fc/0x2e0 net/netlink/genetlink.c:972 genl_family_rcv_msg net/netlink/genetlink.c:1052 [inline] genl_rcv_msg+0x561/0x800 net/netlink/genetlink.c:1067 netlink_rcv_skb+0x16b/0x440 net/netlink/af_netlink.c:2544 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1076 netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x53b/0x810 net/netlink/af_netlink.c:1367 netlink_sendmsg+0x8b7/0xd70 net/netlink/af_netlink.c:1909 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0xd5/0x180 net/socket.c:745 ____sys_sendmsg+0x6ac/0x940 net/socket.c:2584 ___sys_sendmsg+0x135/0x1d0 net/socket.c:2638 __sys_sendmsg+0x117/0x1e0 net/socket.c:2667 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b The cause of this issue is that when tipc_nl_bearer_add() is called with the TIPC_NLA_BEARER_UDP_OPTS attribute, tipc_udp_nl_bearer_add() is called even if the bearer is not UDP. tipc_udp_is_known_peer() called by tipc_udp_nl_bearer_add() assumes that the media_ptr field of the tipc_bearer has an udp_bearer type object, so the function goes crazy for non-UDP bearers. This patch fixes the issue by checking the bearer type before calling tipc_udp_nl_bearer_add() in tipc_nl_bearer_add(). En el kernel de Linux, se resolvió la siguiente vulnerabilidad: tipc: verifique el tipo de portador antes de llamar a tipc_udp_nl_bearer_add() syzbot informó la siguiente falla de protección general [1]: falla de protección general, probablemente para la dirección no canónica 0xdffffc0000000010: 0000 [#1 ] PREEMPT SMP KASAN KASAN: null-ptr-deref en el rango [0x00000000000000080-0x0000000000000087] ... RIP: 0010:tipc_udp_is_known_peer+0x9c/0x250 net/tipc/udp_media.c:291 ... Seguimiento de llamadas: tipc_udp_ nl_bearer_add+ 0x212/0x2f0 net/tipc/udp_media.c:646 tipc_nl_bearer_add+0x21e/0x360 net/tipc/bearer.c:1089 genl_family_rcv_msg_doit+0x1fc/0x2e0 net/netlink/genetlink.c:972 genl_family_rcv_msg net/netlink/genetlink. c:1052 [en línea] genl_rcv_msg+0x561/0x800 net/netlink/genetlink.c:1067 netlink_rcv_skb+0x16b/0x440 net/netlink/af_netlink.c:2544 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1076 netlink_unicast_kernel net/netlink/ af_netlink.c:1341 [en línea] netlink_unicast+0x53b/0x810 net/netlink/af_netlink.c:1367 netlink_sendmsg+0x8b7/0xd70 net/netlink/af_netlink.c:1909 sock_sendmsg_nosec net/socket.c:730 [en línea] __sock_sendmsg+0xd 5 /0x180 net/socket.c:745 ____sys_sendmsg+0x6ac/0x940 net/socket.c:2584 ___sys_sendmsg+0x135/0x1d0 net/socket.c:2638 __sys_sendmsg+0x117/0x1e0 net/socket.c:2667 do_syscall_x 64 arco/x86/ Entry/common.c:52 [en línea] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x63/0x6b La causa de este problema es que cuando se llama a tipc_nl_bearer_add() con el atributo TIPC_NLA_BEARER_UDP_OPTS, tipc_udp_nl_bear er_añadir () se llama incluso si el portador no es UDP. tipc_udp_is_known_peer() llamado por tipc_udp_nl_bearer_add() supone que el campo media_ptr de tipc_bearer tiene un objeto de tipo udp_bearer, por lo que la función se vuelve loca para los portadores que no son UDP. Este parche soluciona el problema al verificar el tipo de portador antes de llamar a tipc_udp_nl_bearer_add() en tipc_nl_bearer_add(). • https://git.kernel.org/stable/c/ef20cd4dd1633987bcf46ac34ace2c8af212361f https://git.kernel.org/stable/c/24ec8f0da93b8a9fba11600be8a90f0d73fb46f1 https://git.kernel.org/stable/c/6f70f0b412458c622a12d4292782c8e92e210c2f https://git.kernel.org/stable/c/19d7314f2fb9515bdaac9829d4d8eb34edd1fe95 https://git.kernel.org/stable/c/c1701ea85ef0ec7be6a1b36c7da69f572ed2fd12 https://git.kernel.org/stable/c/3d3a5b31b43515b5752ff282702ca546ec3e48b6 https://git.kernel.org/stable/c/888e3524be87f3df9fa3c083484e4b62b3e3bb59 https://git.kernel.org/stable/c/0cd331dfd6023640c9669d0592bc0fd49 •