Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: comprobar la compatibilidad del tamaño de la franja al volver a montar también Deshabilitamos el tamaño de la franja en __ext4_fill_super si no es un múltiplo de la relación del clúster; sin embargo, esta comprobación se omite al intentar volver a montar. Esto puede dejarnos con casos en los que stripe < cluster_ratio después de remount:set, lo que hace que EXT4_B2C(sbi->s_stripe) se convierta en 0, lo que puede causar algunos errores imprevistos como dividir por 0. Solucione eso agregando la comprobación en la ruta de montaje también.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Error en la verificación de la extensión de signo del paquete data/data_end/data_meta syzbot informó de un fallo del kernel debido a el commit 1f1e864b6555 ("bpf: Manejar los accesos a miembros ctx de la extensión de signo"). La razón se debe a la extensión de signo de la carga de 32 bits para el campo uapi del paquete data/data_end/data_meta. El código original se ve así: r2 = *(s32 *)(r1 + 76) /* load __sk_buff->data */ r3 = *(u32 *)(r1 + 80) /* load __sk_buff->data_end */ r0 = r2 r0 += 8 if r3 > r0 goto +1 ... Tenga en cuenta que la carga de __sk_buff->data tiene una extensión de signo de 32 bits. Después de la verificación y convert_ctx_accesses(), el código asm final se ve así: r2 = *(u64 *)(r1 +208) r2 = (s32)r2 r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 ... Tenga en cuenta que 'r2 = (s32)r2' puede hacer que la dirección __sk_buff->data del núcleo sea inválida, lo que puede causar un error en tiempo de ejecución. Actualmente, en el código C, normalmente tenemos void *data = (void *)(long)skb->data; void *data_end = (void *)(long)skb->data_end; ... y generará r2 = *(u64 *)(r1 +208) r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 Si permitimos la extensión de signo, void *data = (void *)(long)(int)skb->data; void *data_end = (void *)(long)skb->data_end; ... el código generado se ve así r2 = *(u64 *)(r1 +208) r2 <<= 32 r2 s>>= 32 r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 y esto causará un error de verificación ya que "r2 <<= 32" no está permitido ya que "r2" es un puntero de paquete. Para solucionar este problema en el caso r2 = *(s32 *)(r1 + 76) /* load __sk_buff->data */, este parche agregó una verificación adicional en la función de devolución de llamada is_valid_access() para el acceso a los paquetes data/data_end/data_meta. Si esos accesos son con la extensión sign-extenstion, la verificación fallará. [1] https://lore.kernel.org/bpf/000000000000c90eee061d236d37@google.com/

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf, lsm: Agregar comprobación para el valor de retorno de BPF LSM Un programa bpf que devuelve un número positivo adjunto al gancho file_alloc_security hace que el kernel entre en pánico. Esto sucede porque el sistema de archivos no puede filtrar el número positivo devuelto por el programa LSM usando IS_ERR y malinterpreta este número positivo como un puntero de archivo. Dado que el gancho file_alloc_security nunca devolvió un número positivo antes de la introducción de BPF LSM, y otros ganchos BPF LSM pueden encontrar problemas similares, este parche agrega la comprobación del valor de retorno de LSM en el verificador, para garantizar que no se devuelva ningún valor inesperado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Compruebe link_res->hpo_dp_link_enc antes de usarlo [QUÉ Y CÓMO] Las funciones dp_enable_link_phy y dp_disable_link_phy pueden pasar link_res sin inicializar hpo_dp_link_enc y es necesario comprobar si hay valores nulos antes de desreferenciar. Esto soluciona 2 problemas de FORWARD_NULL informados por Coverity.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: IB/core: Arreglar la limpieza del flujo de error ib_cache_setup_one Cuando ib_cache_update devuelve un error, salimos de ib_cache_setup_one instantáneamente sin una limpieza adecuada, aunque antes de esto ya habíamos realizado con éxito gid_table_setup_one, que da como resultado la siguiente ADVERTENCIA del kernel. Realice una limpieza adecuada utilizando gid_table_cleanup_one antes de devolver el error para solucionar el problema. ADVERTENCIA: CPU: 4 PID: 922 en drivers/infiniband/core/cache.c:806 gid_table_release_one+0x181/0x1a0 Módulos vinculados: CPU: 4 UID: 0 PID: 922 Comm: c_repro No contaminado 6.11.0-rc1+ #3 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:gid_table_release_one+0x181/0x1a0 Código: 44 8b 38 75 0c e8 2f cb 34 ff 4d 8b b5 28 05 00 00 e8 23 cb 34 ff 44 89 f9 89 da 4c 89 f6 48 c7 c7 d0 58 14 83 e8 4f de 21 ff <0f> 0b 4c 8b 75 30 e9 54 ff ff ff 48 8 3 c4 10 5b 5d 41 5c 41 5d 41 RSP: 0018:ffffc90002b835b0 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff811c8527 RDX: 0000000000000000 RSI: ffffffff811c8534 RDI: 0000000000000001 RBP: ffff8881011b3d00 R08: ffff88810b3abe00 R09: 205d303839303631 R10: 666572207972746e R11: 72746e6520444947 R12: 0000000000000001 R13: ffff888106390000 R14: ffff8881011f2110 R15: 0000000000000001 FS: 00007fecc3b70800(0000) GS:ffff88813bd00000(0000) knlGS:00000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000340 CR3: 000000010435a001 CR4: 00000000003706b0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 00000000000000400 Seguimiento de llamadas: ? show_regs+0x94/0xa0 ? __warn+0x9e/0x1c0 ? gid_table_release_one+0x181/0x1a0 ? report_bug+0x1f9/0x340 ? gid_table_release_one+0x181/0x1a0 ? handle_bug+0xa2/0x110 ? exc_invalid_op+0x31/0xa0 ? asm_exc_invalid_op+0x16/0x20 ? __warn_printk+0xc7/0x180 ? __warn_printk+0xd4/0x180 ? __pfx_ib_device_release+0x10/0x10 device_release+0x44/0xd0 kobject_put+0x135/0x3d0 put_device+0x20/0x30 rxe_net_add+0x7d/0xa0 rxe_newlink+0xd7/0x190 nldev_newlink+0x1b0/0x2a0 ? Obtener tarea pid+0xb0/0xd0 ? error_proc_nth_write+0x5b/0x140 ? __fget_light+0x9a/0x200 ? preempt_count_add+0x47/0xa0 __sys_sendmsg+0x61/0xd0 hacer_syscall_64+0x50/0x110 entrada_SYSCALL_64_después_hwframe+0x76/0x7e

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/rtrs-clt: Restablecer cid a con_num - 1 para permanecer dentro de los límites En la función init_conns(), después del bucle for create_con() y create_cm() si algo falla. En el bucle for de limpieza después de la etiqueta destroy, accedemos a memoria fuera de los límites porque cid está configurado en clt_path->s.con_num. Esta confirmación restablece el cid a clt_path->s.con_num - 1, para permanecer dentro de los límites en el bucle de limpieza más tarde.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/iwcm: Fix WARNING:at_kernel/workqueue.c:#check_flush_dependency En el commit aee2424246f9 ("RDMA/iwcm: Fix a use-after-free related to destroying CM IDs"), se invoca la función flush_workqueue para vaciar la cola de trabajo iwcm_wq. Pero en ese momento, la cola de trabajo iwcm_wq se creó a través de la función alloc_ordered_workqueue sin el indicador WQ_MEM_RECLAIM. Debido a que el proceso actual está intentando vaciar todo iwcm_wq, si iwcm_wq no tiene el indicador WQ_MEM_RECLAIM, verifique que el proceso actual no esté recuperando memoria o ejecutándose en una cola de trabajo que no tenga el indicador WQ_MEM_RECLAIM, ya que eso puede romper la garantía de progreso hacia adelante y provocar un bloqueo. El seguimiento de la llamada es el siguiente: [ 125.350876][ T1430] Seguimiento de la llamada: [ 125.356281][ T1430] [ 125.361285][ T1430] ? __warn (kernel/panic.c:693) [ 125.367640][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.375689][ T1430] ? report_bug (lib/bug.c:180 lib/bug.c:219) [ 125.382505][ T1430] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminador 1)) [ 125.395831][ T1430] ? asm_exc_invalid_op (arch/x86/include/asm/idtentry.h:621) [ 125.403125][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminador 9)) [ 125.410984][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminador 9)) [ 125.418764][ T1430] __flush_workqueue (kernel/workqueue.c:3970) [ 125.426021][ T1430] ? __pfx___might_resched (kernel/sched/core.c:10151) [ 125.433431][ T1430] ? destroy_cm_id (drivers/infiniband/core/iwcm.c:375) iw_cm [ 125.441209][ T1430] ? __pfx___flush_workqueue (kernel/workqueue.c:3910) [ 125.473900][ T1430] ? _raw_spin_lock_irqsave (arch/x86/include/asm/atomic.h:107 include/linux/atomic/atomic-arch-fallback.h:2170 include/linux/atomic/atomic-instrumented.h:1302 include/asm-generic/qspinlock.h:111 include/linux/spinlock.h:187 include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162) [ 125.473909][ T1430] ? __pfx__raw_spin_lock_irqsave (núcleo/bloqueo/spinlock.c:161) [ 125.482537][ T1430] _destroy_id (controladores/infiniband/core/cma.c:2044) rdma_cm [ 125.495072][ T1430] nvme_rdma_free_queue (controladores/nvme/host/rdma.c:656 controladores/nvme/host/rdma.c:650) nvme_rdma [ 125.505827][ T1430] nvme_rdma_reset_ctrl_work (controladores/nvme/host/rdma.c:2180) nvme_rdma [ 125.505831][ T1430] proceso_uno_trabajo (kernel/workqueue.c:3231) [ 125.515122][ T1430] subproceso_de_trabajo (kernel/workqueue.c:3306 kernel/workqueue.c:3393) [ 125.515127][ T1430] ? __pfx_subproceso_de_trabajo (kernel/workqueue.c:3339) [ 125.531837][ T1430] subproceso_de_trabajo (kernel/kthread.c:389) [ 125.539864][ T1430] ? __pfx_kthread (kernel/kthread.c:342) [ 125.550628][ T1430] ret_from_fork (arch/x86/kernel/process.c:147) [ 125.558840][ T1430] ? __pfx_kthread (kernel/kthread.c:342) [ 125.558844][ T1430] ret_from_fork_asm (arch/x86/entry/entry_64.S:257) [ 125.566487][ T1430] [ 125.566488][ T1430] ---[ fin de seguimiento 000000000000000 ]---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drivers: media: dvb-frontends/rtl2830: corrige un error de escritura fuera de los límites Asegúrate de que el índice en rtl2830_pid_filter no supere 31 para evitar el acceso fuera de los límites. dev->filters es un valor de 32 bits, por lo que las funciones set_bit y clear_bit solo deben funcionar en índices de 0 a 31. Si el índice es 32, intentará acceder a un bit 33 inexistente, lo que provocará un acceso fuera de los límites. Cambia la comprobación de límites de índice > 32 a índice >= 32 para resolver este problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drivers: media: dvb-frontends/rtl2832: corrige un error de escritura fuera de los límites Asegúrate de que el índice en rtl2832_pid_filter no supere 31 para evitar el acceso fuera de los límites. dev->filters es un valor de 32 bits, por lo que las funciones set_bit y clear_bit solo deben funcionar en índices de 0 a 31. Si el índice es 32, intentará acceder a un bit 33 inexistente, lo que provocará un acceso fuera de los límites. Cambia la comprobación de límites de índice > 32 a índice >= 32 para resolver este problema. [hverkuil: se agregó la etiqueta de correcciones, rtl2830_pid_filter -> rtl2832_pid_filter en logmsg]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nilfs2: soluciona una posible desreferencia de puntero nulo en nilfs_btree_insert() Serie de parches "nilfs2: soluciona posibles problemas con nodos de árbol b vacíos". Esta serie aborda tres posibles problemas con nodos de árbol b vacíos que pueden ocurrir con imágenes de sistema de archivos dañadas, incluido uno descubierto recientemente por syzbot. Este parche (de 3): Si un árbol b está roto en el dispositivo y la altura del árbol b es mayor que 2 (el nivel del nodo raíz es mayor que 1) incluso si el número de nodos secundarios de la raíz del árbol b es 0, se produce una desreferencia de puntero NULL en nilfs_btree_prepare_insert(), que se llama desde nilfs_btree_insert(). Esto se debe a que, cuando el número de nodos secundarios de la raíz del árbol b es 0, nilfs_btree_do_lookup() no establece el encabezado del búfer de bloque en ninguno de los path[x].bp_bh, dejándolo como el valor inicial de NULL, pero si el nivel del nodo raíz del árbol b es mayor que 1, se llama a nilfs_btree_get_nonroot_node(), que accede a la memoria del búfer de path[x].bp_bh. Solucione este problema agregando una verificación a nilfs_btree_root_broken(), que realiza verificaciones de cordura al leer el nodo raíz desde el dispositivo, para detectar esta inconsistencia. Gracias a Lizhi Xu por intentar resolver el error y aclarar la causa desde el principio.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: evitar OOB cuando system.data xattr cambia debajo del sistema de archivos Al buscar una entrada en un directorio en línea, si e_value_offs se cambia debajo del sistema de archivos por algún cambio en el dispositivo de bloque, conducirá a un acceso fuera de los límites que KASAN detecta como un UAF. EXT4-fs (loop0): sistema de archivos montado 00000000-0000-0000-0000-00000000000 r/w sin diario. Modo de cuota: ninguno. loop0: se detectó un cambio de capacidad de 2048 a 2047 ======================================================================= ERROR: KASAN: use after free en ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500 Lectura de tamaño 1 en la dirección ffff88803e91130f por la tarea syz-executor269/5103 CPU: 0 UID: 0 PID: 5103 Comm: syz-executor269 No contaminado 6.11.0-rc4-syzkaller #0 Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 01/04/2014 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:93 [en línea] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [en línea] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500 ext4_find_inline_entry+0x4be/0x5e0 fs/ext4/inline.c:1697 __ext4_find_entry+0x2b4/0x1b30 fs/ext4/namei.c:1573 ext4_lookup_entry fs/ext4/namei.c:1727 [en línea] ext4_lookup+0x15f/0x750 fs/ext4/namei.c:1795 lookup_one_qstr_excl+0x11f/0x260 fs/namei.c:1633 filename_create+0x297/0x540 fs/namei.c:3980 do_symlinkat+0xf9/0x3a0 fs/namei.c:4587 __do_sys_symlinkat fs/namei.c:4610 [en línea] __se_sys_symlinkat fs/namei.c:4607 [en línea] __x64_sys_symlinkat+0x95/0xb0 fs/namei.c:4607 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f3e73ced469 Código: 28 00 00 00 75 05 48 83 c4 28 c3 e8 21 18 00 00 90 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 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff4d40c258 EFLAGS: 00000246 ORIG_RAX: 000000000000010a RAX: ffffffffffffffda RBX: 0032656c69662f2e RCX: 00007f3e73ced469 RDX: 0000000020000200 RSI: 00000000ffffff9c RDI: 00000000200001c0 RBP: 0000000000000000 R08: 00007fff4d40c290 R09: 00007fff4d40c290 R10: 0023706f6f6c2f76 R11: 0000000000000246 R12: 00007fff4d40c27c R13: 0000000000000003 R14: 431bde82d7b634db R15: 00007fff4d40c2b0 Llamada ext4_xattr_ibody_find justo después de leer el inodo con ext4_get_inode_loc conducirá a una verificación de la validez de los xattrs, evitando este problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: comprobar la compatibilidad con el descarte para zonas convencionales Como muestra la función auxiliar f2fs_bdev_support_discard(), f2fs comprueba si los dispositivos de bloque de destino admiten el descarte llamando a bdev_max_discard_sectors() y bdev_is_zoned(). Esta comprobación funciona bien en la mayoría de los casos, pero no funciona para zonas convencionales en dispositivos de bloque con zonas. F2fs supone que los dispositivos de bloque con zonas admiten el descarte y llama a __submit_discard_cmd(). Cuando se llama a __submit_discard_cmd() para zonas que requieren escritura secuencial, funciona bien ya que __submit_discard_cmd() emite comandos de restablecimiento de zona en lugar de comandos de descarte. Sin embargo, cuando se llama a __submit_discard_cmd() para zonas convencionales, se llama a __blkdev_issue_discard() incluso cuando los dispositivos no admiten el descarte. La llamada inapropiada a __blkdev_issue_discard() no era un problema antes de el commit 30f1e7241422 ("bloqueo: mover las comprobaciones de descarte al controlador ioctl") porque __blkdev_issue_discard() comprobaba si los dispositivos de destino admitían o no el descarte. Si no, devolvía EOPNOTSUPP. Después de el commit, __blkdev_issue_discard() ya no lo comprueba. Siempre devuelve cero y establece NULL en el puntero bio indicado. Este puntero NULL activa f2fs_bug_on() en __submit_discard_cmd(). El ERROR se vuelve a crear con los comandos siguientes en el paso de desmontaje, donde /dev/nullb0 es un null_blk zonificado con un tamaño total de 5 GB, un tamaño de zona de 128 MB y 10 zonas convencionales. $ mkfs.f2fs -f -m /dev/nullb0 $ mount /dev/nullb0 /mnt $ for ((i=0;i<5;i++)); do dd if=/dev/zero of=/mnt/test bs=65536 count=1600 conv=fsync; done $ umount /mnt Para corregir el ERROR, evite la llamada __blkdev_issue_discard() inapropiada. Cuando se solicita el descarte para zonas convencionales, verifique si el dispositivo admite el descarte o no. Si no es así, devuelva EOPNOTSUPP.