Vulnerabilidades

Vulnerabilidad almacenada de Cross-Site Scripting en Gophish que afecta a la versión 0.12.1. Esta vulnerabilidad podría permitir a un atacante almacenar un payload de JavaScript maliciosa en el menú de la campaña y activar payload cuando la campaña se elimine del menú.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdkfd: Reparar advertencia de dependencia de bloqueo =============================== ======================== ADVERTENCIA: posible dependencia de bloqueo circular detectada 6.5.0-kfd-fkuehlin #276 No contaminado -------- ---------------------------------------------- ktrabajador/8: 2/2676 está intentando adquirir el bloqueo: ffff9435aae95c88 ((work_completion)(&svm_bo->eviction_work)){+.+.}-{0:0}, en: __flush_work+0x52/0x550 pero la tarea ya mantiene el bloqueo: ffff9435cd8e1720 ( &svms->lock){+.+.}-{3:3}, en: svm_range_deferred_list_work+0xe8/0x340 [amdgpu] cuyo bloqueo ya depende del nuevo bloqueo. la cadena de dependencia existente (en orden inverso) es: -> #2 (&svms->lock){+.+.}-{3:3}: __mutex_lock+0x97/0xd30 kfd_ioctl_alloc_memory_of_gpu+0x6d/0x3c0 [amdgpu] kfd_ioctl+0x1b2 /0x5d0 [amdgpu] __x64_sys_ioctl+0x86/0xc0 do_syscall_64+0x39/0x80 Entry_SYSCALL_64_after_hwframe+0x63/0xcd -> #1 (&mm->mmap_lock){++++}-{3:3}: down_read+0x42/0x160 svm_range_evi ct_svm_bo_worker+ 0x8b/0x340 [amdgpu] proceso_one_work+0x27a/0x540 trabajador_thread+0x53/0x3e0 kthread+0xeb/0x120 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x11/0x20 -> #0 ((work_completion)(&svm_bo->eviction_work) ){+.+ .}-{0:0}: __lock_acquire+0x1426/0x2200 lock_acquire+0xc1/0x2b0 __flush_work+0x80/0x550 __cancel_work_timer+0x109/0x190 svm_range_bo_release+0xdc/0x1c0 [amdgpu] svm_range_free+0x175 /0x180 [amdgpu] svm_range_deferred_list_work+0x15d/0x340 [amdgpu] Process_one_work+0x27a/0x540 trabajador_thread+0x53/0x3e0 kthread+0xeb/0x120 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x11/0x20 otra información que podría ayudarnos a depurar esto: Existe cadena de: (work_completion)(&svm_bo->eviction_work) --> &mm->mmap_lock --> &svms->lock Posible escenario de bloqueo inseguro: CPU0 CPU1 ---- ---- lock(&svms->lock); bloquear(&mm->mmap_lock); bloquear(&svms->bloquear); lock((work_completion)(&svm_bo->eviction_work)); Creo que esto realmente no puede llevar a un punto muerto en la práctica, porque svm_range_evict_svm_bo_worker solo toma mmap_read_lock si el recuento de BO no es 0. Eso significa que es imposible que svm_range_bo_release se esté ejecutando al mismo tiempo. Sin embargo, no existe una buena forma de anotar esto. Para evitar el problema, tome una referencia de BO en svm_range_schedule_evict_svm_bo en lugar de en el trabajador. De esa manera, es imposible que un BO sea liberado mientras el trabajo de desalojo está pendiente y la llamada cancel_work_sync en svm_range_bo_release puede eliminarse. v2: Use svm_bo_ref_unless_zero y explicó por qué es seguro. También se eliminaron las comprobaciones redundantes que ya se realizan en amdkfd_fence_enable_signaling.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: pds_core: evita problemas de ejecución relacionados con adminq. Hay varias rutas que pueden resultar en el uso de adminq de pdsc. [1] pdsc_adminq_isr y el trabajo resultante de queue_work(), es decir, pdsc_work_thread()->pdsc_process_adminq() [2] pdsc_adminq_post() Cuando el dispositivo se reinicia mediante reinicio de PCIe y/o un ciclo fw_down/fw_up debido a un estado incorrecto de PCIe o mal estado del dispositivo, adminq se destruye y se vuelve a crear. Puede ocurrir una desreferencia de puntero NULL si [1] o [2] ocurre después de que adminq ya esté destruido. Para solucionar este problema, agregue algunas comprobaciones de estado adicionales e implemente el recuento de referencias para usos de adminq. Se utilizó el recuento de referencias porque varios subprocesos pueden intentar acceder a adminq al mismo tiempo a través de [1] o [2]. Además, varios clientes (es decir, pds-vfio-pci) pueden utilizar [2] al mismo tiempo. adminq_refcnt se inicializa en 1 cuando adminq se ha asignado y está listo para usar. Los usuarios/clientes de adminq (es decir, [1] y [2]) incrementarán el refcnt cuando utilicen adminq. Cuando el controlador entra en un ciclo fw_down, establecerá el bit PDSC_S_FW_DEAD y luego esperará a que adminq_refcnt llegue a 1. Configurar PDSC_S_FW_DEAD antes de esperar evitará más incrementos de adminq_refcnt. Esperar a que adminq_refcnt llegue a 1 permite que cualquier usuario actual de adminq finalice antes de que el controlador libere adminq. Una vez que adminq_refcnt llega a 1, el controlador borra el refcnt para indicar que adminq se elimina y no se puede utilizar. En el ciclo fw_up, el controlador inicializará una vez más adminq_refcnt en 1, lo que permitirá utilizar adminq nuevamente.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: af_unix: corrige el bloqueo positivo en sk_diag_dump_icons() syzbot informó un bloqueo del bloqueo [1]. La confirmación culpada insinuó la posible violación de lockdep y el código usó unix_state_lock_nested() en un intento de silenciar lockdep. No es suficiente, porque unix_state_lock_nested() ya se usa desde unix_state_double_lock(). Necesitamos usar una subclase separada. Este parche agrega una enumeración distinta para hacer las cosas más explícitas. Utilice también swap() en unix_state_double_lock() como limpieza. v2: agregue una palabra clave en línea faltante a unix_state_lock_nested() [1] ADVERTENCIA: se detectó posible dependencia de bloqueo circular 6.8.0-rc1-syzkaller-00356-g8a696a29c690 #0 No contaminado syz-executor.1/2542 está intentando adquirir el bloqueo: ffff88808b5df9e8 (rlock-AF_UNIX){+.+.}-{2:2}, en: skb_queue_tail+0x36/0x120 net/core/skbuff.c:3863 pero la tarea ya mantiene el bloqueo: ffff88808b5dfe70 (&u->lock/1) {+.+.}-{2:2}, en: unix_dgram_sendmsg+0xfc7/0x2200 net/unix/af_unix.c:2089 cuyo bloqueo ya depende del nuevo bloqueo. la cadena de dependencia existente (en orden inverso) es: -> #1 (&u->lock/1){+.+.}-{2:2}: lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754 _raw_spin_lock_nested+0x31/0x40 kernel/locking/spinlock.c:378 sk_diag_dump_icons net/unix/diag.c:87 [en línea] sk_diag_fill+0x6ea/0xfe0 net/unix/diag.c:157 sk_diag_dump net/unix/diag.c: 196 [en línea] unix_diag_dump+0x3e9/0x630 net/unix/diag.c:220 netlink_dump+0x5c1/0xcd0 net/netlink/af_netlink.c:2264 __netlink_dump_start+0x5d7/0x780 net/netlink/af_netlink.c:2370 netlink_dump_start include/linux /netlink.h:338 [en línea] unix_diag_handler_dump+0x1c3/0x8f0 net/unix/diag.c:319 sock_diag_rcv_msg+0xe3/0x400 netlink_rcv_skb+0x1df/0x430 net/netlink/af_netlink.c:2543 sock_diag_rcv+0x2a/0x 40 neto/núcleo /sock_diag.c:280 netlink_unicast_kernel net/netlink/af_netlink.c:1341 [en línea] netlink_unicast+0x7e6/0x980 net/netlink/af_netlink.c:1367 netlink_sendmsg+0xa37/0xd70 net/netlink/af_netlink.c:1908 sock_sendmsg_nosec net/ socket.c:730 [en línea] __sock_sendmsg net/socket.c:745 [en línea] sock_write_iter+0x39a/0x520 net/socket.c:1160 call_write_iter include/linux/fs.h:2085 [en línea] new_sync_write fs/read_write.c :497 [en línea] vfs_write+0xa74/0xca0 fs/read_write.c:590 ksys_write+0x1a0/0x2c0 fs/read_write.c:643 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xf5/0x230 arch /x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x63/0x6b -> #0 (rlock-AF_UNIX){+.+.}-{2:2}: check_prev_add kernel/locking/lockdep.c:3134 [en línea] check_prevs_add kernel/locking/lockdep.c:3253 [en línea] validar_chain+0x1909/0x5ab0 kernel/locking/lockdep.c:3869 __lock_acquire+0x1345/0x1fd0 kernel/locking/lockdep.c:5137 lock_acquire+0x1e3/0x530 kernel/locking/ lockdep.c:5754 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [en línea] _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162 skb_queue_tail+0x36/0x120 net/core/skbuff.c:3863 unix_dgram_send mensaje+0x15d9/ 0x2200 net/unix/af_unix.c:2112 sock_sendmsg_nosec net/socket.c:730 [en línea] __sock_sendmsg net/socket.c:745 [en línea] ____sys_sendmsg+0x592/0x890 net/socket.c:2584 ___sys_sendmsg net/socket.c :2638 [en línea] __sys_sendmmsg+0x3b2/0x730 net/socket.c:2724 __do_sys_sendmmsg net/socket.c:2753 [en línea] __se_sys_sendmmsg net/socket.c:2750 [en línea] __x64_sys_sendmmsg+0xa0/0xb0 net /socket.c: 2750 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x230 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x63/0x6b otra información que podría ayudarnos a depurar esto: Posible escenario de bloqueo inseguro : CPU0 ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: llc: llame a sock_orphan() en el momento del lanzamiento syzbot informó un rastro interesante [1] causado por un puntero sk->sk_wq obsoleto en un socket llc cerrado. En El commit ff7b11aa481f ("net: socket: set sock->sk to NULL after call proto_ops::release()") Eric Biggers insinuó que a algunos protocolos les falta un sock_orphan(), necesitamos realizar una auditoría completa. En net-next, planeo borrar sock->sk de sock_orphan() y modificar el parche de Eric para agregar una advertencia. [1] ERROR: KASAN: slab-use-after-free en list_empty include/linux/list.h:373 [en línea] ERROR: KASAN: slab-use-after-free en waitqueue_active include/linux/wait.h:127 [en línea] ERROR: KASAN: slab-use-after-free en sock_def_write_space_wfree net/core/sock.c:3384 [en línea] ERROR: KASAN: slab-use-after-free en sock_wfree+0x9a8/0x9d0 net/core/sock .c:2468 Lectura del tamaño 8 en la dirección ffff88802f4fc880 por tarea ksoftirqd/1/27 CPU: 1 PID: 27 Comm: ksoftirqd/1 Not tainted 6.8.0-rc1-syzkaller-00049-g6098d87eaf31 #0 Nombre de hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 01/04/2014 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0xd9/0x1b0 lib/dump_stack .c:106 print_address_description mm/kasan/report.c:377 [en línea] print_report+0xc4/0x620 mm/kasan/report.c:488 kasan_report+0xda/0x110 mm/kasan/report.c:601 list_empty include/linux/ list.h:373 [en línea] waitqueue_active include/linux/wait.h:127 [en línea] sock_def_write_space_wfree net/core/sock.c:3384 [en línea] sock_wfree+0x9a8/0x9d0 net/core/sock.c:2468 skb_release_head_state+ 0xa3/0x2b0 net/core/skbuff.c:1080 skb_release_all net/core/skbuff.c:1092 [en línea] napi_consume_skb+0x119/0x2b0 net/core/skbuff.c:1404 e1000_unmap_and_free_tx_resource+0x144/0x200 drivers/net/ethernet/ intel/e1000/e1000_main.c:1970 e1000_clean_tx_irq controladores/net/ethernet/intel/e1000/e1000_main.c:3860 [en línea] e1000_clean+0x4a1/0x26e0 controladores/net/ethernet/intel/e1000/e1000_main.c:3801 __ napi_poll. constprop.0+0xb4/0x540 net/core/dev.c:6576 napi_poll net/core/dev.c:6645 [en línea] net_rx_action+0x956/0xe90 net/core/dev.c:6778 __do_softirq+0x21a/0x8de kernel/ softirq.c:553 run_ksoftirqd kernel/softirq.c:921 [en línea] run_ksoftirqd+0x31/0x60 kernel/softirq.c:913 smpboot_thread_fn+0x660/0xa10 kernel/smpboot.c:164 kthread+0x2c6/0x3a0 kernel/kthread.c :388 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:242 Asignado por tarea 5167: kasan_save_stack+0x33/0x50 mm/ kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:314 [en línea] __kasan_slab_alloc+0x81/0x90 mm/kasan/common.c:340 kasan_slab_alloc incluir /linux/kasan.h:201 [en línea] slab_post_alloc_hook mm/slub.c:3813 [en línea] slab_alloc_node mm/slub.c:3860 [en línea] kmem_cache_alloc_lru+0x142/0x6f0 mm/slub.c:3879 alloc_inode_sb include/linux/ fs.h:3019 [en línea] sock_alloc_inode+0x25/0x1c0 net/socket.c:308 alloc_inode+0x5d/0x220 fs/inode.c:260 new_inode_pseudo+0x16/0x80 fs/inode.c:1005 sock_alloc+0x40/0x270 net /socket.c:634 __sock_create+0xbc/0x800 net/socket.c:1535 sock_create net/socket.c:1622 [en línea] __sys_socket_create net/socket.c:1659 [en línea] __sys_socket+0x14c/0x260 net/socket.c :1706 __do_sys_socket net/socket.c:1720 [en línea] __se_sys_socket net/socket.c:1718 [en línea] __x64_sys_socket+0x72/0xb0 net/socket.c:1718 do_syscall_x64 arch/x86/entry/common.c:52 [en línea ] do_syscall_64+0xd3/0x250 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x63/0x6b Liberado por la tarea 0: kasan_save_stack+0x33/0x50 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/ common.c:68 kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640 veneno_slab_object mm/kasan/common.c:241 [en línea] __kasan_slab_free+0x121/0x1b0 mm/kasan/common.c:257 kasan_slab_free include/linux /kasan.h:184 [en línea] slab_free_hook mm/slub.c:2121 [en línea ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ipmr: corrige el pánico del kernel al reenviar paquetes mcast El stacktrace fue: [86.305548] ERROR: desreferencia del puntero NULL del kernel, dirección: 0000000000000092 [86.306815] #PF: acceso de lectura del supervisor en modo kernel [ 86.307717] #PF: error_code(0x0000) - página no presente [ 86.308624] PGD 0 P4D 0 [ 86.309091] Ups: 0000 [#1] PREEMPT SMP NOPTI [ 86.309883] CPU: 2 PID: 3139 Comm: pimd Contaminado: GU 6.8.0-6wind-knet #1 [ 86.311027] Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS rel-1.11.1-0-g0551a4be2c-prebuilt.qemu-project.org 01/04/2014 [ 86.312728] RIP: 0010:ip_mr_forward (/build/work/knet/net/ipv4/ipmr.c:1985) [86.313399] Código: f9 1f 0f 87 85 03 00 00 48 8d 04 5b 48 8d 04 83 49 8d 44 c 5 00 48 8b 40 70 48 39 c2 0f 84 d9 00 00 00 49 8b 46 58 48 83 e0 fe <80> b8 92 00 00 00 00 0f 84 55 ff ff 49 83 47 38 01 45 85 e4 0f [ 86.316565] RSP : 0018:ffffad21c0583ae0 EFLAGS: 00010246 [ 86.317497] RAX: 0000000000000000 RBX: 00000000000000000 RCX: 00000000000000000 [ 86.318596] RDX: ff ff9559cb46c000 RSI: 0000000000000000 RDI: 0000000000000000 [ 86.319627] RBP: ffffad21c0583b30 R08: 00000000000000000 R09: 00000000000000000 [ 86.320650] R10: 0000000000000000 R11 : 0000000000000000 R12: 00000000000000001 [ 86.321672] R13: ffff9559c093a000 R14: ffff9559cc00b800 R15: ffff9559c09c1d80 [ 86.322873] FS: 0 0007f85db661980(0000) GS:ffff955a79d00000(0000) knlGS:0000000000000000 [ 86.324291] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [86.325314] CR2: 0000000000000092 CR3: 000000002f13a000 CR4: 0000000000350ef0 [86.326589] Seguimiento de llamadas: [86.327036] [86.327434] ? show_regs (/build/work/knet/arch/x86/kernel/dumpstack.c:479) [86.328049]? __die (/build/work/knet/arch/x86/kernel/dumpstack.c:421 /build/work/knet/arch/x86/kernel/dumpstack.c:434) [86.328508] ? page_fault_oops (/build/work/knet/arch/x86/mm/fault.c:707) [86.329107]? do_user_addr_fault (/build/work/knet/arch/x86/mm/fault.c:1264) [86.329756]? srso_return_thunk (/build/work/knet/arch/x86/lib/retpoline.S:223) [86.330350]? __irq_work_queue_local (/build/work/knet/kernel/irq_work.c:111 (discriminador 1)) [86.331013]? exc_page_fault (/build/work/knet/./arch/x86/include/asm/paravirt.h:693 /build/work/knet/arch/x86/mm/fault.c:1515 /build/work/knet/arch /x86/mm/fault.c:1563) [86.331702]? asm_exc_page_fault (/build/work/knet/./arch/x86/include/asm/idtentry.h:570) [86.332468]? ip_mr_forward (/build/work/knet/net/ipv4/ipmr.c:1985) [86.333183]? srso_return_thunk (/build/work/knet/arch/x86/lib/retpoline.S:223) [ 86.333920] ipmr_mfc_add (/build/work/knet/./include/linux/rcupdate.h:782 /build/work/knet /net/ipv4/ipmr.c:1009 /build/work/knet/net/ipv4/ipmr.c:1273) [86.334583]? __pfx_ipmr_hash_cmp (/build/work/knet/net/ipv4/ipmr.c:363) [ 86.335357] ip_mroute_setsockopt (/build/work/knet/net/ipv4/ipmr.c:1470) [ 86.336135] ? srso_return_thunk (/build/work/knet/arch/x86/lib/retpoline.S:223) [86.336854]? ip_mroute_setsockopt (/build/work/knet/net/ipv4/ipmr.c:1470) [ 86.337679] do_ip_setsockopt (/build/work/knet/net/ipv4/ip_sockglue.c:944) [ 86.338408] ? __pfx_unix_stream_read_actor (/build/work/knet/net/unix/af_unix.c:2862) [86.339232]? srso_return_thunk (/build/work/knet/arch/x86/lib/retpoline.S:223) [86.339809]? aa_sk_perm (/build/work/knet/security/apparmor/include/cred.h:153 /build/work/knet/security/apparmor/net.c:181) [ 86.340342] ip_setsockopt (/build/work/knet/net /ipv4/ip_sockglue.c:1415) [86.340859] raw_setsockopt (/build/work/knet/net/ipv4/raw.c:836) [86.341408] ? security_socket_setsockopt (/build/work/knet/security/security.c:4561 (discriminador 13)) [ 86.342116] sock_common_setsockopt (/build/work/knet/net/core/sock.c:3716) [ 86.342747] do_sock_setsockopt (/build /work/knet/net/socket.c:2313) [ 86.343363] __sys_setsockopt (/build/work/knet/./include/linux/file.h:32 /build/work/kn ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: core: Saque scsi_host_busy() del bloqueo del host para activar el controlador EH Dentro de scsi_eh_wakeup(), se llama a scsi_host_busy() y se verifica con el bloqueo del host cada vez para decidir si se produce un error. Es necesario activar el controlador kthread. Esto puede ser demasiado pesado en caso de recuperación, como por ejemplo: - N colas de hardware - la profundidad de la cola es M para cada cola de hardware - cada scsi_host_busy() itera sobre (N * M) etiquetas/solicitudes Si la recuperación se activa en caso de que todas las solicitudes están en curso, cada scsi_eh_wakeup() está estrictamente serializado, cuando se llama a scsi_eh_wakeup() para la última solicitud en curso, scsi_host_busy() se ha ejecutado (N * M - 1) veces y la solicitud se ha iterado durante ( N*M - 1) * (N * M) veces. Si tanto N como M son lo suficientemente grandes, se puede activar un bloqueo duro al adquirir el bloqueo del host, y se observa en mpi3mr (128 colas hw, profundidad de cola 8169). Solucione el problema llamando a scsi_host_busy() fuera del bloqueo del host. No necesitamos el bloqueo del host para obtener el recuento de ocupación porque el bloqueo del host nunca cubre eso. [mkp: elimine las variables 'ocupadas' innecesarias señaladas por Bart]

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: UBSAN: array-index-out-of-bounds en dtSplitRoot Syzkaller informó el siguiente problema: oop0: se detectó un cambio de capacidad de 0 a 32768 UBSAN: array-index-out-of- límites en fs/jfs/jfs_dtree.c:1971:9 índice -2 está fuera de rango para el tipo 'struct dtslot [128]' CPU: 0 PID: 3613 Comm: syz-executor270 No contaminado 6.0.0-syzkaller-09423- g493ffd6605b2 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 22/09/2022 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c: 106 ubsan_epilogue lib/ubsan.c:151 [en línea] __ubsan_handle_out_of_bounds+0xdb/0x130 lib/ubsan.c:283 dtSplitRoot+0x8d8/0x1900 fs/jfs/jfs_dtree.c:1971 dtSplitUp fs/jfs/jfs_dtree.c:9 85 [en línea ] dtInsert+0x1189/0x6b80 fs/jfs/jfs_dtree.c:863 jfs_mkdir+0x757/0xb00 fs/jfs/namei.c:270 vfs_mkdir+0x3b3/0x590 fs/namei.c:4013 do_mkdirat+0x279/0x550 f s/namei. c:4038 __do_sys_mkdirat fs/namei.c:4053 [en línea] __se_sys_mkdirat fs/namei.c:4051 [en línea] __x64_sys_mkdirat+0x85/0x90 fs/namei.c:4051 do_syscall_x64 arch/x86/entry/common.c:50 [ inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 Entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fcdc0113fd9 Código: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 F7 48 89 D6 48 89 CA 4D 89 C2 4D 89 C8 4C 8B 4C 24 08 0F 05 <48> 3D 01 F0 FF FF 73 01 C3 48 C7 C1 C0 FF FF FF F7 D8 64 89 01 48 RSP: 002B: 00007ffeb8bc67d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000102 RAX: ffffffffffffffda RBX: 00000000000000000 RCX: 00007fcdc0113fd9 RDX: 00000000000000000 RSI: 0000000020000340 RDI: 0000000000000003 RBP: 00007fcdc00d37a0 R08: 0000000000000000 R09: 00007fcdc00d37a0 R10: 00005555559a72c0 R11: 0000000000000246 R12: 00000000f8008000 R13: 0000000000000000 R14: 00083878000000f8 R15 : 0000000000000000 El problema se produce cuando el valor de fsi es inferior a -1. La verificación para romper el ciclo cuando el valor fsi se convierte en -1 está presente, pero syzbot pudo producir un valor menor que -1, lo que causa el error. Este parche simplemente agrega el cambio para los valores menores que 0. El parche se prueba a través de syzbot.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: FS:JFS:UBSAN:array-index-out-of-bounds en dbAdjTree Syzkaller informó el siguiente problema: UBSAN: array-index-out-of-bounds en fs/jfs /jfs_dmap.c:2867:6 el índice 196694 está fuera del rango para el tipo 's8[1365]' (también conocido como 'carácter firmado[1365]') CPU: 1 PID: 109 Comm: jfsCommit No contaminado 6.6.0-rc3-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/08/2023 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106 ubsan_epilogue lib/ubsan.c:217 [en línea] __ubsan_handle_out_of_bounds+0x11c/0x150 lib/ubsan.c:348 dbAdjTree+0x474/0x4f0 fs/jfs/jfs_dmap.c:2867 dbJoin+0x210/0x2d0 fs/jfs/jfs _dmap.c: 2834 dbFreeBits+0x4eb/0xda0 fs/jfs/jfs_dmap.c:2331 dbFreeDmap fs/jfs/jfs_dmap.c:2080 [en línea] dbFree+0x343/0x650 fs/jfs/jfs_dmap.c:402 txFreeMap+0x798/0xd50 fs/j fs /jfs_txnmgr.c:2534 txUpdateMap+0x342/0x9e0 txLazyCommit fs/jfs/jfs_txnmgr.c:2664 [en línea] jfs_lazycommit+0x47a/0xb70 fs/jfs/jfs_txnmgr.c:2732 kthread+0x2d3/0x3 70 kernel/kthread.c:388 ret_from_fork+0x48/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304 ============== ==================================================== ================ Pánico del kernel: no se sincroniza: UBSAN: pánico_on_warn configurado... CPU: 1 PID: 109 Comm: jfsCommit No contaminado 6.6.0-rc3-syzkaller #0 Hardware nombre: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/08/2023 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106 pánico+0x30f /0x770 Kernel/Panic.C: 340 check_panic_on_warn+0x82/0xa0 kernel/Panic.c: 236 UBSAN_EPILOGO LIB/UBSAN.C: 223 [Inline] __ubsan_handle_out_of_bounds+0x13c/0x150 LIB/UB/UBSAN.C: 4F0 FS /jfs/jfs_dmap.c:2867 dbJoin+0x210/0x2d0 fs/jfs/jfs_dmap.c:2834 dbFreeBits+0x4eb/0xda0 fs/jfs/jfs_dmap.c:2331 dbFreeDmap fs/jfs/jfs_dmap.c:2080 [en línea] dbFree +0x343/0x650 fs/jfs/jfs_dmap.c:402 txFreeMap+0x798/0xd50 fs/jfs/jfs_txnmgr.c:2534 txUpdateMap+0x342/0x9e0 txLazyCommit fs/jfs/jfs_txnmgr.c:2664 [en línea] jf s_lazycommit+0x47a/0xb70 fs/jfs/jfs_txnmgr.c:2732 kthread+0x2d3/0x370 kernel/kthread.c:388 ret_from_fork+0x48/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64. S:304 Desplazamiento del kernel: deshabilitado Reinicio en 86400 segundos. El problema se produce cuando el valor de lp se vuelve mayor que CTLTREESIZE, que es el tamaño máximo de stree. Agregar una verificación simple resuelve este problema. Dave: Como la función devuelve un valor nulo, un buen manejo de errores requeriría una reorganización del código más intrusiva, así que modifiqué el parche de Osama en use WARN_ON_ONCE por falta de una opción más limpia. El parche se prueba mediante syzbot.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ACPI: extlog: corrige la verificación de desreferencia del puntero NULL El complemento gcc -fanalyzer [1] intenta detectar varios patrones de comportamiento incorrecto. La herramienta informa: drivers/acpi/acpi_extlog.c: En función 'extlog_exit': drivers/acpi/acpi_extlog.c:307:12: advertencia: verificación de 'extlog_l1_addr' para NULL después de desreferenciarlo [-Wanalyzer-deref-before -verificar] | | 306 | ((struct extlog_l1_head *)extlog_l1_addr)->flags &= ~FLAG_OS_OPTIN; | | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~ | | | | | (1) Aquí se elimina la referencia al puntero 'extlog_l1_addr' | 307 | si (extlog_l1_addr) | | ~ | | | | | (2) El puntero 'extlog_l1_addr' está marcado como NULL aquí pero ya se eliminó la referencia en (1) | Corrija la verificación de desreferencia del puntero NULL en extlog_exit().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/lib: validar tamaño para operaciones vectoriales Parte del código fp/vmx en sstep.c asume un cierto tamaño máximo para las instrucciones que se emula. Sin embargo, el tamaño de esas operaciones se determina por separado en analyse_instr(). Agregue una verificación para validar la suposición sobre el tamaño máximo de las operaciones, a fin de evitar daños no deseados en la pila del kernel.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: powerpc/mm: corrige la desreferencia del puntero nulo en pgtable_cache_add kasprintf() devuelve un puntero a la memoria asignada dinámicamente que puede ser NULL en caso de falla. Asegúrese de que la asignación se haya realizado correctamente comprobando la validez del puntero.