Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: evitar advertencia del kernel debido a i_nlink negativo de una imagen dañada ADVERTENCIA: CPU: 1 PID: 9426 at fs/inode.c:417 drop_nlink+0xac/0xd0 home/cc/linux/fs/inode.c:417 Modules linked in: CPU: 1 UID: 0 PID: 9426 Comm: syz-executor568 Not tainted 6.14.0-12627-g94d471a4f428 #2 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:drop_nlink+0xac/0xd0 home/cc/linux/fs/inode.c:417 Code: 48 8b 5d 28 be 08 00 00 00 48 8d bb 70 07 00 00 e8 f9 67 e6 ff f0 48 ff 83 70 07 00 00 5b 5d e9 9a 12 82 ff e8 95 12 82 ff 90 <0f> 0b 90 c7 45 48 ff ff ff ff 5b 5d e9 83 12 82 ff e8 fe 5f e6 ff RSP: 0018:ffffc900026b7c28 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff8239710f RDX: ffff888041345a00 RSI: ffffffff8239717b RDI: 0000000000000005 RBP: ffff888054509ad0 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000000 R11: ffffffff9ab36f08 R12: ffff88804bb40000 R13: ffff8880545091e0 R14: 0000000000008000 R15: ffff8880545091e0 FS: 000055555d0c5880(0000) GS:ffff8880eb3e3000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f915c55b178 CR3: 0000000050d20000 CR4: 0000000000352ef0 Call Trace: f2fs_i_links_write home/cc/linux/fs/f2fs/f2fs.h:3194 [inline] f2fs_drop_nlink+0xd1/0x3c0 home/cc/linux/fs/f2fs/dir.c:845 f2fs_delete_entry+0x542/0x1450 home/cc/linux/fs/f2fs/dir.c:909 f2fs_unlink+0x45c/0x890 home/cc/linux/fs/f2fs/namei.c:581 vfs_unlink+0x2fb/0x9b0 home/cc/linux/fs/namei.c:4544 do_unlinkat+0x4c5/0x6a0 home/cc/linux/fs/namei.c:4608 __do_sys_unlink home/cc/linux/fs/namei.c:4654 [inline] __se_sys_unlink home/cc/linux/fs/namei.c:4652 [inline] __x64_sys_unlink+0xc5/0x110 home/cc/linux/fs/namei.c:4652 do_syscall_x64 home/cc/linux/arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xc7/0x250 home/cc/linux/arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fb3d092324b Code: 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 57 00 00 00 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:00007ffdc232d938 EFLAGS: 00000206 ORIG_RAX: 0000000000000057 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fb3d092324b RDX: 00007ffdc232d960 RSI: 00007ffdc232d960 RDI: 00007ffdc232d9f0 RBP: 00007ffdc232d9f0 R08: 0000000000000001 R09: 00007ffdc232d7c0 R10: 00000000fffffffd R11: 0000000000000206 R12: 00007ffdc232eaf0 R13: 000055555d0cebb0 R14: 00007ffdc232d958 R15: 0000000000000001

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrección para realizar una comprobación de cordura en sit_bitmap_size con el siguiente caso de prueba, el cambio de tamaño generará una imagen dañada que contiene metadatos inconsistentes, por lo que al montar dicha imagen, activará el pánico del kernel: touch img truncate -s $((512*1024*1024*1024)) img mkfs.f2fs -f img $((256*1024*1024)) resize.f2fs -s -i img -t $((1024*1024*1024)) mount img /mnt/f2fs ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.h:863! Oops: invalid opcode: 0000 [#1] SMP PTI CPU: 11 UID: 0 PID: 3922 Comm: mount Not tainted 6.15.0-rc1+ #191 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:f2fs_ra_meta_pages+0x47c/0x490 Call Trace: f2fs_build_segment_manager+0x11c3/0x2600 f2fs_fill_super+0xe97/0x2840 mount_bdev+0xf4/0x140 legacy_get_tree+0x2b/0x50 vfs_get_tree+0x29/0xd0 path_mount+0x487/0xaf0 __x64_sys_mount+0x116/0x150 do_syscall_64+0x82/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fdbfde1bcfe La razón es: sit_i->bitmap_size es 192, por lo que el tamaño del mapa de bits sit es 192*8=1536, como máximo hay 1536 bloques sit, sin embargo MAIN_SEGS es 261893, por lo que sit_blk_cnt es 4762, build_sit_entries() -> current_sit_addr() intenta acceder fuera de los límites en sit_bitmap en el desplazamiento de [1536, 4762), si sit_bitmap y sit_bitmap_mirror no coinciden, se activará f2fs_bug_on(). Agreguemos una comprobación de validez en f2fs_sanity_check_ckpt() para evitar problemas.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vgacon: Agregar comprobación para el rango de direcciones vc_origin en vgacon_scroll() Nuestro Syzkaller interno informó el siguiente ERROR (dos veces), que creíamos que era el mismo problema con [1]: ====================================================================== ERROR: KASAN: slab-out-of-bounds in vcs_scr_readw+0xc2/0xd0 drivers/tty/vt/vt.c:4740 Read of size 2 at addr ffff88800f5bef60 by task syz.7.2620/12393 ... Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x72/0xa0 lib/dump_stack.c:106 print_address_description.constprop.0+0x6b/0x3d0 mm/kasan/report.c:364 print_report+0xba/0x280 mm/kasan/report.c:475 kasan_report+0xa9/0xe0 mm/kasan/report.c:588 vcs_scr_readw+0xc2/0xd0 drivers/tty/vt/vt.c:4740 vcs_write_buf_noattr drivers/tty/vt/vc_screen.c:493 [inline] vcs_write+0x586/0x840 drivers/tty/vt/vc_screen.c:690 vfs_write+0x219/0x960 fs/read_write.c:584 ksys_write+0x12e/0x260 fs/read_write.c:639 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x59/0x110 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x78/0xe2 ... Allocated by task 5614: kasan_save_stack+0x20/0x40 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 ____kasan_kmalloc mm/kasan/common.c:374 [inline] __kasan_kmalloc+0x8f/0xa0 mm/kasan/common.c:383 kasan_kmalloc include/linux/kasan.h:201 [inline] __do_kmalloc_node mm/slab_common.c:1007 [inline] __kmalloc+0x62/0x140 mm/slab_common.c:1020 kmalloc include/linux/slab.h:604 [inline] kzalloc include/linux/slab.h:721 [inline] vc_do_resize+0x235/0xf40 drivers/tty/vt/vt.c:1193 vgacon_adjust_height+0x2d4/0x350 drivers/video/console/vgacon.c:1007 vgacon_font_set+0x1f7/0x240 drivers/video/console/vgacon.c:1031 con_font_set drivers/tty/vt/vt.c:4628 [inline] con_font_op+0x4da/0xa20 drivers/tty/vt/vt.c:4675 vt_k_ioctl+0xa10/0xb30 drivers/tty/vt/vt_ioctl.c:474 vt_ioctl+0x14c/0x1870 drivers/tty/vt/vt_ioctl.c:752 tty_ioctl+0x655/0x1510 drivers/tty/tty_io.c:2779 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:871 [inline] __se_sys_ioctl+0x12d/0x190 fs/ioctl.c:857 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x59/0x110 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x78/0xe2 Last potentially related work creation: kasan_save_stack+0x20/0x40 mm/kasan/common.c:45 __kasan_record_aux_stack+0x94/0xa0 mm/kasan/generic.c:492 __call_rcu_common.constprop.0+0xc3/0xa10 kernel/rcu/tree.c:2713 netlink_release+0x620/0xc20 net/netlink/af_netlink.c:802 __sock_release+0xb5/0x270 net/socket.c:663 sock_close+0x1e/0x30 net/socket.c:1425 __fput+0x408/0xab0 fs/file_table.c:384 __fput_sync+0x4c/0x60 fs/file_table.c:465 __do_sys_close fs/open.c:1580 [inline] __se_sys_close+0x68/0xd0 fs/open.c:1565 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x59/0x110 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x78/0xe2 Second to last potentially related work creation: kasan_save_stack+0x20/0x40 mm/kasan/common.c:45 __kasan_record_aux_stack+0x94/0xa0 mm/kasan/generic.c:492 __call_rcu_common.constprop.0+0xc3/0xa10 kernel/rcu/tree.c:2713 netlink_release+0x620/0xc20 net/netlink/af_netlink.c:802 __sock_release+0xb5/0x270 net/socket.c:663 sock_close+0x1e/0x30 net/socket.c:1425 __fput+0x408/0xab0 fs/file_table.c:384 task_work_run+0x154/0x240 kernel/task_work.c:239 exit_task_work include/linux/task_work.h:45 [inline] do_exit+0x8e5/0x1320 kernel/exit.c:874 do_group_exit+0xcd/0x280 kernel/exit.c:1023 get_signal+0x1675/0x1850 kernel/signal.c:2905 arch_do_signal_or_restart+0x80/0x3b0 arch/x86/kernel/signal.c:310 exit_to_user_mode_loop kernel/entry/common.c:111 [inline] exit_to_user_mode_prepare include/linux/entry-common.h:328 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline] syscall_exit_to_user_mode+0x1b3/0x1e0 kernel/entry/common.c:218 do_syscall_64+0x66/0x110 arch/x86/ent ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: configfs-tsm-report: Arregla la desreferencia NULL de tsm_ops A diferencia de sysfs, el tiempo de vida de los objetos configfs está controlado por el espacio de usuario. No hay ningún mecanismo para que el kernel encuentre y elimine todos los elementos de configuración creados. En cambio, el mecanismo configfs-tsm-report tiene una expectativa de que tsm_unregister() puede suceder en cualquier momento y hacer que el acceso establecido a los elementos de configuración empiece a fallar. Esa expectativa no se cumple por completo. Mientras que tsm_report_read(), tsm_report_{is,is_bin}_visible() y tsm_report_make_item() fallan de forma segura si se ha anulado el registro de tsm_ops, tsm_report_privlevel_store() y tsm_report_provider_show() no comprueban el registro de operaciones. Añade las comprobaciones que faltan para que se hayan eliminado los tsm_ops. Ahora, al permitir que tsm_unregister() siempre se ejecute correctamente, se plantea el problema de qué hacer con los elementos de configuración persistentes. Se espera que el administrador que gestiona la eliminación del controlador invitado ${tsm_arch} también sea responsable de eliminar todos los elementos de configuración abiertos. Hasta que se elimine, la recarga y la vinculación del controlador invitado ${tsm_arch} falla. Esto permite el apagado o la revocación de emergencia de las interfaces de atestación y requiere un reinicio coordinado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nvme-tcp: eliminar el conjunto de etiquetas cuando falla la configuración de la segunda cola de administración. El commit 104d0e2f6222 ("nvme-fabrics: restablecer la conexión de administración para una concatenación segura") modificó nvme_tcp_setup_ctrl() para llamar a nvme_tcp_configure_admin_queue() dos veces. La primera llamada prepara la negociación DH-CHAP y la segunda es necesaria para la concatenación segura. Sin embargo, este cambio activó el error "slab-use-after-free" en blk_mq_queue_tag_busy_iter()". Este error se puede recrear repitiendo el caso de prueba blktests nvme/063 varias veces [1]. Cuando ocurre el ERROR, nvme_tcp_create_ctrl() falla en la siguiente cadena de llamadas: nvme_tcp_create_ctrl() nvme_tcp_alloc_ctrl() new=true ... Asignar nvme_tcp_ctrl y admin_tag_set nvme_tcp_setup_ctrl() new=true nvme_tcp_configure_admin_queue() new=true ... Correcto nvme_alloc_admin_tag_set() ... Asignar el conjunto de etiquetas para admin_tag_set nvme_stop_keep_alive() nvme_tcp_teardown_admin_queue() remove=false nvme_tcp_configure_admin_queue() new=false nvme_tcp_alloc_admin_queue() ... Falla, pero no se llama nvme_remove_admin_tag_set() nvme_uninit_ctrl() nvme_put_ctrl() ... Libera nvme_tcp_ctrl y admin_tag_set La primera llamada de nvme_tcp_configure_admin_queue() tiene éxito con el argumento new=true. La segunda llamada falla con el argumento new=false. Esta segunda llamada no llama a nvme_remove_admin_tag_set() en caso de error, debido al argumento new=false. Entonces, el conjunto de etiquetas admin no se elimina. Sin embargo, nvme_tcp_create_ctrl() supone que nvme_tcp_setup_ctrl() llamaría a nvme_remove_admin_tag_set(). Luego libera la estructura nvme_tcp_ctrl que tiene el campo admin_tag_set. Posteriormente, el controlador de tiempo de espera accede al campo admin_tag_set y provoca el error "BUG KASAN slab-use-after-free". Para mantener la etiqueta admin activa, llame a nvme_remove_admin_tag_set() cuando falle la segunda llamada a nvme_tcp_configure_admin_queue(). No regrese de nvme_tcp_setup_ctrl() en caso de error. En su lugar, vaya a la etiqueta "destroy_admin" para llamar a nvme_tcp_teardown_admin_queue(), que a su vez llama a nvme_remove_admin_tag_set().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fbdev: Corregir do_register_framebuffer para evitar la desreferencia null-ptr en fb_videomode_to_var Si fb_add_videomode() en do_register_framebuffer() no puede asignar memoria para fb_videomode, más tarde provocará una desreferencia null-ptr en fb_videomode_to_var(), ya que fb_info se registra sin tener el modo en modelist que se espera que esté allí, es decir, el que se describe en fb_info-&amp;gt;var. ================================================================ <br /> general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 1 PID: 30371 Comm: syz-executor.1 Not tainted 5.10.226-syzkaller #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:fb_videomode_to_var+0x24/0x610 drivers/video/fbdev/core/modedb.c:901 Call Trace: display_to_var+0x3a/0x7c0 drivers/video/fbdev/core/fbcon.c:929 fbcon_resize+0x3e2/0x8f0 drivers/video/fbdev/core/fbcon.c:2071 resize_screen drivers/tty/vt/vt.c:1176 [inline] vc_do_resize+0x53a/0x1170 drivers/tty/vt/vt.c:1263 fbcon_modechanged+0x3ac/0x6e0 drivers/video/fbdev/core/fbcon.c:2720 fbcon_update_vcs+0x43/0x60 drivers/video/fbdev/core/fbcon.c:2776 do_fb_ioctl+0x6d2/0x740 drivers/video/fbdev/core/fbmem.c:1128 fb_ioctl+0xe7/0x150 drivers/video/fbdev/core/fbmem.c:1203 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl fs/ioctl.c:739 [inline] __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:739 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1 ================================================================<br /> Aunque fbcon_init() comprueba previamente si fb_match_mode() en var_to_display() falla, no puede evitar el pánico, ya que fbcon_init() no devuelve un código de error. Considerando esto y el comentario en el código sobre que fb_match_mode() devuelve NULL ("Esto no debería ocurrir"), es mejor evitar el registro de fb_info si su modo no se configuró correctamente. También mueva fb_add_videomode() más cerca del inicio de do_register_framebuffer() para evitar tener que realizar la limpieza en caso de fallo. Encontrado por el Centro de Verificación de Linux (linuxtesting.org) con Syzkaller.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fbdev: Corregir fb_set_var para evitar la desreferencia null-ptr en fb_videomode_to_var Si fb_add_videomode() en fb_set_var() no puede asignar memoria para fb_videomode, más tarde puede conducir a una desreferencia null-ptr en fb_videomode_to_var(), ya que fb_info se registra sin tener el modo en modelist que se espera que esté allí, es decir, el que se describe en fb_info-&amp;gt;var.<br /> ================================================================ <br /> general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 1 PID: 30371 Comm: syz-executor.1 Not tainted 5.10.226-syzkaller #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:fb_videomode_to_var+0x24/0x610 drivers/video/fbdev/core/modedb.c:901 Call Trace: display_to_var+0x3a/0x7c0 drivers/video/fbdev/core/fbcon.c:929 fbcon_resize+0x3e2/0x8f0 drivers/video/fbdev/core/fbcon.c:2071 resize_screen drivers/tty/vt/vt.c:1176 [inline] vc_do_resize+0x53a/0x1170 drivers/tty/vt/vt.c:1263 fbcon_modechanged+0x3ac/0x6e0 drivers/video/fbdev/core/fbcon.c:2720 fbcon_update_vcs+0x43/0x60 drivers/video/fbdev/core/fbcon.c:2776 do_fb_ioctl+0x6d2/0x740 drivers/video/fbdev/core/fbmem.c:1128 fb_ioctl+0xe7/0x150 drivers/video/fbdev/core/fbmem.c:1203 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl fs/ioctl.c:739 [inline] __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:739 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1 ================================================================ <br /> El motivo es que fb_info-&amp;gt;var se modifica en fb_set_var() y, a continuación, se llama a fb_videomode_to_var(). Si no se logra agregar el modo a fb_info-&amp;gt;modelist, fb_set_var() devuelve un error, pero no restaura el valor anterior de fb_info-&amp;gt;var. Si falla, restaure fb_info-&amp;gt;var de la misma forma que se hizo anteriormente en la función. Encontrado por el Centro de Verificación de Linux (linuxtesting.org) con Syzkaller.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipc: corrección para proteger las búsquedas IPCS mediante RCU. syzbot informó del descubrimiento de una vulnerabilidad de use-after-free, [0] [0]: https://lore.kernel.org/all/67af13f8.050a0220.21dd3.0038.GAE@google.com/ idr_for_each() está protegido por rwsem, pero esto no es suficiente. Si no está protegido por la región crítica de lectura de RCU, cuando idr_for_each() llama a radix_tree_node_free() mediante call_rcu() para liberar la estructura radix_tree_node, el nodo se liberará inmediatamente y, al leer el siguiente nodo en radix_tree_for_each_slot(), se podrá leer la memoria ya liberada. Por lo tanto, necesitamos agregar código para asegurarnos de que idr_for_each() esté protegido dentro de la región crítica de lectura de RCU cuando lo llamamos en shm_destroy_orphaned().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/iwcm: Corrección del use-after-free de objetos de trabajo después de la destrucción de cm_id El commit 59c68ac31e15 ("iw_cm: liberar recursos de cm_id en la última desreferencia") simplificó la gestión de recursos de cm_id al liberar cm_id una vez que se eliminaron todas las referencias a cm_id. Las referencias se eliminan al completarse los controladores de eventos iw_cm o cuando la aplicación destruye cm_id. Este commit introdujo la condición de use-after-free donde el objeto cm_id_private aún podría estar en uso por los controladores de eventos durante la destrucción de cm_id. El commit aee2424246f9 ("RDMA/iwcm: Corrección de un use-after-free relacionado con la destrucción de los ID de CM") abordó este use-after-free al vaciar todos los trabajos pendientes en la destrucción de cm_id. Sin embargo, aún quedaba otra posibilidad de use-after-free. Esto sucede con los objetos de trabajo asignados para cada cm_id_priv dentro de alloc_work_entries() durante la creación de cm_id, y posteriormente se liberan en dealloc_work_entries() una vez que se eliminan todas las referencias a cm_id. Si la última referencia de cm_id se decrementa en el manejador de eventos work, el objeto de trabajo para el trabajo en sí se elimina y causa el siguiente ERROR de use-after-free: ERROR: KASAN: slab-use-after-free in __pwq_activate_work+0x1ff/0x250 Read of size 8 at addr ffff88811f9cf800 by task kworker/u16:1/147091 CPU: 2 UID: 0 PID: 147091 Comm: kworker/u16:1 Not tainted 6.15.0-rc2+ #27 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014 Workqueue: 0x0 (iw_cm_wq) Call Trace: dump_stack_lvl+0x6a/0x90 print_report+0x174/0x554 ? __virt_addr_valid+0x208/0x430 ? __pwq_activate_work+0x1ff/0x250 kasan_report+0xae/0x170 ? __pwq_activate_work+0x1ff/0x250 __pwq_activate_work+0x1ff/0x250 pwq_dec_nr_in_flight+0x8c5/0xfb0 process_one_work+0xc11/0x1460 ? __pfx_process_one_work+0x10/0x10 ? assign_work+0x16c/0x240 worker_thread+0x5ef/0xfd0 ? __pfx_worker_thread+0x10/0x10 kthread+0x3b0/0x770 ? __pfx_kthread+0x10/0x10 ? rcu_is_watching+0x11/0xb0 ? _raw_spin_unlock_irq+0x24/0x50 ? rcu_is_watching+0x11/0xb0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x30/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Allocated by task 147416: kasan_save_stack+0x2c/0x50 kasan_save_track+0x10/0x30 __kasan_kmalloc+0xa6/0xb0 alloc_work_entries+0xa9/0x260 [iw_cm] iw_cm_connect+0x23/0x4a0 [iw_cm] rdma_connect_locked+0xbfd/0x1920 [rdma_cm] nvme_rdma_cm_handler+0x8e5/0x1b60 [nvme_rdma] cma_cm_event_handler+0xae/0x320 [rdma_cm] cma_work_handler+0x106/0x1b0 [rdma_cm] process_one_work+0x84f/0x1460 worker_thread+0x5ef/0xfd0 kthread+0x3b0/0x770 ret_from_fork+0x30/0x70 ret_from_fork_asm+0x1a/0x30 Freed by task 147091: kasan_save_stack+0x2c/0x50 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x60 __kasan_slab_free+0x4b/0x70 kfree+0x13a/0x4b0 dealloc_work_entries+0x125/0x1f0 [iw_cm] iwcm_deref_id+0x6f/0xa0 [iw_cm] cm_work_handler+0x136/0x1ba0 [iw_cm] process_one_work+0x84f/0x1460 worker_thread+0x5ef/0xfd0 kthread+0x3b0/0x770 ret_from_fork+0x30/0x70 ret_from_fork_asm+0x1a/0x30 Last potentially related work creation: kasan_save_stack+0x2c/0x50 kasan_record_aux_stack+0xa3/0xb0 __queue_work+0x2ff/0x1390 queue_work_on+0x67/0xc0 cm_event_handler+0x46a/0x820 [iw_cm] siw_cm_upcall+0x330/0x650 [siw] siw_cm_work_handler+0x6b9/0x2b20 [siw] process_one_work+0x84f/0x1460 worker_thread+0x5ef/0xfd0 kthread+0x3b0/0x770 ret_from_fork+0x30/0x70 ret_from_fork_asm+0x1a/0x30 Este error se puede reproducir repitiendo el caso de prueba blktests nvme/061 para el transporte rdma y el controlador siw. Para evitar el uso posterior a la liberación de objetos de trabajo cm_id_private, asegúrese de que la última referencia a cm_id se decremente no en los trabajos del controlador de eventos, sino en el contexto de destrucción de cm_id. Para ello, mo ---truncated---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb: cliente: Se comprueba si la comprobación de añadir NULL en la página automount_fullpath contiene valores nulos en __build_path_from_dentry_optional_prefix cuando tcon-&amp;gt;origin_fullpath no está configurado. Sin embargo, la comprobación no se encuentra disponible cuando sí lo está. Se ha añadido una comprobación para evitar una posible desreferencia de punteros NULL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: se corrige la sobrescritura del archivo uprobe al expandir vma. Serie de parches "Corregir la sobrescritura del archivo uprobe al expandir vma". Este parche (de 4): Se detectó una alerta de error generada por Syzkaller: Error: Estado incorrecto del contador RSS mm:00000000b4a60fca tipo:MM_ANONPAGES val:1. Se puede reproducir con los siguientes pasos: 1. Registrar uprobe en el archivo con desplazamiento cero. 2. Asignar el archivo con mmap en el desplazamiento cero: addr1 = mmap(NULL, 2 * 4096, PROT_NONE, MAP_PRIVATE, fd, 0); 3. Asignar con mremap parte de vma1 al nuevo vma2: addr2 = mremap(addr1, 4096, 2 * 4096, MREMAP_MAYMOVE); 4. mremap de vuelta a la dirección original 1: mremap(addr2, 4096, 4096, MREMAP_MAYMOVE | MREMAP_FIXED, addr1); En el paso 3, el rango vma1 [addr1, addr1 + 4096] se reasignará a la nueva vma2 con rango [addr2, addr2 + 8192] y se reasignará la página uprobe anon de vma1 a vma2, luego desasignará el rango vma1 [addr1, addr1 + 4096]. En el paso 4, el rango vma2 [addr2, addr2 + 4096] se reasignará de nuevo al rango addr [addr1, addr1 + 4096]. Dado que el rango de direcciones [addr1 + 4096, addr1 + 8192] aún asigna el archivo, se requerirá vma_merge_new_range para expandir el rango y luego ejecutar uprobe_mmap en vma_complete. Dado que el desplazamiento de la página de la vma fusionada también tiene desplazamiento cero, se instalará uprobe anon page en la vma fusionada. Sin embargo, el siguiente paso `move_page_tables`, que usa `set_pte_at` para reasignar la pte de uprobe vma2 a la vma fusionada, sobrescribirá la nueva pte de uprobe en la vma fusionada y la dejará huérfana. Dado que la pte de uprobe se reasignará a la vma fusionada, podemos eliminar uprobe_mmap innecesario al fusionar la vma. Este problema se encontró por primera vez en linux-6.6.y y también existe en la comunidad syzkaller: https://lore.kernel.org/all/000000000000ada39605a5e71711@google.com/T/

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Evite la división por cero inicializando el paso ficticio en 1 [Por qué] Si los valores ficticios en `populate_dummy_dml_surface_cfg()` no se actualizan, pueden provocar una división por cero en los llamadores posteriores como CalculateVMAndRowBytes() [Cómo] Inicialice el valor ficticio en un valor para evitar la división por cero.