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: 3EXPL: 0CVE-2024-26669 – net/sched: flower: Fix chain template offload
https://notcve.org/view.php?id=CVE-2024-26669
In the Linux kernel, the following vulnerability has been resolved: net/sched: flower: Fix chain template offload When a qdisc is deleted from a net device the stack instructs the underlying driver to remove its flow offload callback from the associated filter block using the 'FLOW_BLOCK_UNBIND' command. The stack then continues to replay the removal of the filters in the block for this driver by iterating over the chains in the block and invoking the 'reoffload' operation of the classifier being used. In turn, the classifier in its 'reoffload' operation prepares and emits a 'FLOW_CLS_DESTROY' command for each filter. However, the stack does not do the same for chain templates and the underlying driver never receives a 'FLOW_CLS_TMPLT_DESTROY' command when a qdisc is deleted. This results in a memory leak [1] which can be reproduced using [2]. Fix by introducing a 'tmplt_reoffload' operation and have the stack invoke it with the appropriate arguments as part of the replay. Implement the operation in the sole classifier that supports chain templates (flower) by emitting the 'FLOW_CLS_TMPLT_{CREATE,DESTROY}' command based on whether a flow offload callback is being bound to a filter block or being unbound from one. As far as I can tell, the issue happens since cited commit which reordered tcf_block_offload_unbind() before tcf_block_flush_all_chains() in __tcf_block_put(). The order cannot be reversed as the filter block is expected to be freed after flushing all the chains. [1] unreferenced object 0xffff888107e28800 (size 2048): comm "tc", pid 1079, jiffies 4294958525 (age 3074.287s) hex dump (first 32 bytes): b1 a6 7c 11 81 88 ff ff e0 5b b3 10 81 88 ff ff ..|......[...... 01 00 00 00 00 00 00 00 e0 aa b0 84 ff ff ff ff ................ backtrace: [<ffffffff81c06a68>] __kmem_cache_alloc_node+0x1e8/0x320 [<ffffffff81ab374e>] __kmalloc+0x4e/0x90 [<ffffffff832aec6d>] mlxsw_sp_acl_ruleset_get+0x34d/0x7a0 [<ffffffff832bc195>] mlxsw_sp_flower_tmplt_create+0x145/0x180 [<ffffffff832b2e1a>] mlxsw_sp_flow_block_cb+0x1ea/0x280 [<ffffffff83a10613>] tc_setup_cb_call+0x183/0x340 [<ffffffff83a9f85a>] fl_tmplt_create+0x3da/0x4c0 [<ffffffff83a22435>] tc_ctl_chain+0xa15/0x1170 [<ffffffff838a863c>] rtnetlink_rcv_msg+0x3cc/0xed0 [<ffffffff83ac87f0>] netlink_rcv_skb+0x170/0x440 [<ffffffff83ac6270>] netlink_unicast+0x540/0x820 [<ffffffff83ac6e28>] netlink_sendmsg+0x8d8/0xda0 [<ffffffff83793def>] ____sys_sendmsg+0x30f/0xa80 [<ffffffff8379d29a>] ___sys_sendmsg+0x13a/0x1e0 [<ffffffff8379d50c>] __sys_sendmsg+0x11c/0x1f0 [<ffffffff843b9ce0>] do_syscall_64+0x40/0xe0 unreferenced object 0xffff88816d2c0400 (size 1024): comm "tc", pid 1079, jiffies 4294958525 (age 3074.287s) hex dump (first 32 bytes): 40 00 00 00 00 00 00 00 57 f6 38 be 00 00 00 00 @.......W.8..... 10 04 2c 6d 81 88 ff ff 10 04 2c 6d 81 88 ff ff .. • https://git.kernel.org/stable/c/bbf73830cd48cff1599811d4f69c7cfd49c7b869 https://git.kernel.org/stable/c/9ed46144cff3598a5cf79955630e795ff9af5b97 https://git.kernel.org/stable/c/c04709b2cc99ae31c346f79f0211752d7b74df01 https://git.kernel.org/stable/c/32f2a0afa95fae0d1ceec2ff06e0e816939964b8 https://access.redhat.com/security/cve/CVE-2024-26669 https://bugzilla.redhat.com/show_bug.cgi?id=2272795 • CWE-402: Transmission of Private Resources into a New Sphere ('Resource Leak') •
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 •