Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: jfs: Impide la copia de nlink con valor 0 desde el inodo de disco. syzbot informa de un bloqueo en diFree. [1] Al llamar a "ioctl$LOOP_SET_STATUS64", el valor de desplazamiento pasado es 4, que no coincide con el dispositivo de bucle montado, lo que invalida la asignación de dicho dispositivo. Al crear el directorio y el inodo de iag en diReadSpecial(), al leer la página del inodo de disco fijo (AIT) en modo sin procesar en read_metapage(), los datos de metapágina que devuelve están dañados, lo que provoca que el valor nlink de 0 se asigne al inodo iag al ejecutar copy_from_dinode(), lo que finalmente provoca un bloqueo al acceder a diFree(). Para evitar esto, compruebe primero el valor nlink de dinode antes de configurar el inodo iag. [1] ADVERTENCIA: se detectó un posible bloqueo recursivo 6.12.0-rc7-syzkaller-00212-g4a5df3796467 #0 No contaminado -------------------------------------------- syz-executor301/5309 está intentando adquirir el bloqueo: ffff888044548920 (&(imap->im_aglock[index])){+.+.}-{3:3}, en: diFree+0x37c/0x2fb0 fs/jfs/jfs_imap.c:889 pero la tarea ya tiene el bloqueo: ffff888044548920 (&(imap->im_aglock[index])){+.+.}-{3:3}, en: diAlloc+0x1b6/0x1630 Otra información que podría ayudarnos a depurar esto: Posible escenario de bloqueo inseguro: CPU0 ---- bloqueo(&(imap->im_aglock[índice])); bloqueo(&(imap->im_aglock[índice])); *** BLOQUEO INTERMEDIO *** Puede deberse a la falta de notación de anidamiento de bloqueos. 5 bloqueos mantenidos por syz-executor301/5309: #0: ffff8880422a4420 (sb_writers#9){.+.+}-{0:0}, en: mnt_want_write+0x3f/0x90 fs/namespace.c:515 #1: ffff88804755b390 (&type->i_mutex_dir_key#6/1){+.+.}-{3:3}, en: inode_lock_nested include/linux/fs.h:850 [en línea] #1: ffff88804755b390 (&type->i_mutex_dir_key#6/1){+.+.}-{3:3}, en: nombre_archivo_crear+0x260/0x540 fs/nombrei.c:4026 #2: ffff888044548920 (&(imap->im_aglock[índice])){+.+.}-{3:3}, en: diAlloc+0x1b6/0x1630 #3: ffff888044548890 (&imap->im_freelock){+.+.}-{3:3}, en: diNewIAG fs/jfs/jfs_imap.c:2460 [en línea] #3: ffff888044548890 (&imap->im_freelock){+.+.}-{3:3}, en: diAllocExt fs/jfs/jfs_imap.c:1905 [en línea] #3: ffff888044548890 (&imap->im_freelock){+.+.}-{3:3}, en: diAllocAG+0x4b7/0x1e50 fs/jfs/jfs_imap.c:1669 #4: ffff88804755a618 (&jfs_ip->rdwrlock/1){++++}-{3:3}, en: diNewIAG fs/jfs/jfs_imap.c:2477 [en línea] #4: ffff88804755a618 (&jfs_ip->rdwrlock/1){++++}-{3:3}, en: diAllocExt fs/jfs/jfs_imap.c:1905 [en línea] #4: ffff88804755a618 (&jfs_ip->rdwrlock/1){++++}-{3:3}, en: diAllocAG+0x869/0x1e50 fs/jfs/jfs_imap.c:1669 seguimiento de pila: CPU: 0 UID: 0 PID: 5309 Comm: syz-executor301 No contaminado 6.12.0-rc7-syzkaller-00212-g4a5df3796467 #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:94 [en línea] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_deadlock_bug+0x483/0x620 kernel/locking/lockdep.c:3037 check_deadlock kernel/locking/lockdep.c:3089 [en línea] validate_chain+0x15e2/0x5920 kernel/locking/lockdep.c:3891 __lock_acquire+0x1384/0x2050 kernel/locking/lockdep.c:5202 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825 __mutex_lock_common kernel/locking/mutex.c:608 [en línea] __mutex_lock+0x136/0xd70 kernel/locking/mutex.c:752 diFree+0x37c/0x2fb0 fs/jfs/jfs_imap.c:889 jfs_evict_inode+0x32d/0x440 fs/jfs/inode.c:156 evict+0x4e8/0x9b0 fs/inode.c:725 diFreeSpecial fs/jfs/jfs_imap.c:552 [en línea] duplicateIXtree+0x3c6/0x550 fs/jfs/jfs_imap.c:3022 diNewIAG fs/jfs/jfs_imap.c:2597 [en línea] diAllocExt fs/jfs/jfs_imap.c:1905 [en línea] diAllocAG+0x17dc/0x1e50 fs/jfs/jfs_imap.c:1669 diAlloc+0x1d2/0x1630 fs/jfs/jfs_imap.c:1590 ialloc+0x8f/0x900 fs/jfs/jfs_inode.c:56 jfs_mkdir+0x1c5/0xba0 fs/jfs/namei.c:225 vfs_mkdir+0x2f9/0x4f0 fs/namei.c:4257 do_mkdirat+0x264/0x3a0 fs/namei.c:4280 __do_sys_mkdirat fs/namei.c:4295 [en línea] __se_sys_mkdirat fs/namei.c:4293 [en línea] __x64_sys_mkdirat+0x87/0xa0 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: jfs: añadir una comprobación de validez para agwidth en dbMount. El ancho en dmapctl del AG es cero, lo que genera un error de división al calcular el nivel de página de control en dbAllocAG. Para evitar este problema, añada una comprobación para agwidth en dbAllocAG.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrección para evitar el acceso fuera de los límites en f2fs_truncate_inode_blocks() syzbot informa un problema de UBSAN como se muestra a continuación: ------------[ cortar aquí ]------------ UBSAN: array-index-out-of-bounds en fs/f2fs/node.h:381:10 el índice 18446744073709550692 está fuera de rango para el tipo '__le32[5]' (también conocido como 'unsigned int[5]') CPU: 0 UID: 0 PID: 5318 Comm: syz.0.0 No contaminado 6.14.0-rc3-syzkaller-00060-g6537cfb395f3 #0 Rastreo de llamadas: __dump_stack lib/dump_stack.c:94 [en línea] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:231 [en línea] __ubsan_handle_out_of_bounds+0x121/0x150 lib/ubsan.c:429 get_nid fs/f2fs/node.h:381 [en línea] f2fs_truncate_inode_blocks+0xa5e/0xf60 fs/f2fs/node.c:1181 f2fs_do_truncate_blocks+0x782/0x1030 fs/f2fs/file.c:808 f2fs_truncate_blocks+0x10d/0x300 fs/f2fs/archivo.c:836 f2fs_truncate+0x417/0x720 fs/f2fs/archivo.c:886 f2fs_file_write_iter+0x1bdb/0x2550 fs/f2fs/archivo.c:5093 aio_write+0x56b/0x7c0 fs/aio.c:1633 io_submit_one+0x8a7/0x18a0 fs/aio.c:2052 __do_sys_io_submit fs/aio.c:2111 [en línea] __se_sys_io_submit+0x171/0x2e0 fs/aio.c:2081 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:0x7f238798cde9 índice 18446744073709550692 (decimal, unsigned long long) = 0xfffffffffffffc64 (hexadecimal, unsigned long long) = -924 (decimal, long long) En f2fs_truncate_inode_blocks(), UBSAN detecta que get_nid() intenta acceder a .i_nid[-924], lo que significa que tanto offset[0] como level deben ser cero. El caso posible debería estar en f2fs_do_truncate_blocks(), tratamos de truncar el tamaño del inodo a cero, sin embargo, dn.ofs_in_node es cero y dn.node_page no es una página de inodo, por lo que no puede truncar la página de inodo y luego pasa free_from en cero a f2fs_truncate_inode_blocks(), lo que da como resultado este problema. if (dn.ofs_in_node || IS_INODE(dn.node_page)) { f2fs_truncate_data_blocks_range(&dn, count); free_from += count; } Supongo que la razón por la que dn.node_page no es una página de inodo podría ser: hay varias entradas nat que comparten la misma dirección de bloque de nodo, una vez que se reutilizó la dirección de bloque de nodo, f2fs_get_node_page() puede cargar un bloque que no sea de inodo. Agreguemos una verificación de cordura para tal condición para evitar problemas de acceso fuera de los límites.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: vlan: no propagar indicadores al abrir Con el bloqueo de la instancia del dispositivo, ahora existe la posibilidad de un interbloqueo: [ 1.211455] =============================================== [ 1.211571] ADVERTENCIA: posible bloqueo recursivo detectado [ 1.211687] 6.14.0-rc5-01215-g032756b4ca7a-dirty #5 No contaminado [ 1.211823] -------------------------------------------- [ 1.211936] ip/184 is trying to acquire lock: [ 1.212032] ffff8881024a4c30 (&dev->lock){+.+.}-{4:4}, at: dev_set_allmulti+0x4e/0xb0 [ 1.212207] [ 1.212207] but task is already holding lock: [ 1.212332] ffff8881024a4c30 (&dev->lock){+.+.}-{4:4}, at: dev_open+0x50/0xb0 [ 1.212487] [ 1.212487] other info that might help us debug this: [ 1.212626] Possible unsafe locking scenario: [ 1.212626] [ 1.212751] CPU0 [ 1.212815] ---- [ 1.212871] lock(&dev->lock); [ 1.212944] lock(&dev->lock); [ 1.213016] [ 1.213016] *** DEADLOCK *** [ 1.213016] [ 1.213143] May be due to missing lock nesting notation [ 1.213143] [ 1.213294] 3 locks held by ip/184: [ 1.213371] #0: ffffffff838b53e0 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_nets_lock+0x1b/0xa0 [ 1.213543] #1: ffffffff84e5fc70 (&net->rtnl_mutex){+.+.}-{4:4}, at: rtnl_nets_lock+0x37/0xa0 [ 1.213727] #2: ffff8881024a4c30 (&dev->lock){+.+.}-{4:4}, at: dev_open+0x50/0xb0 [ 1.213895] [ 1.213895] stack backtrace: [ 1.213991] CPU: 0 UID: 0 PID: 184 Comm: ip Not tainted 6.14.0-rc5-01215-g032756b4ca7a-dirty #5 [ 1.213993] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 [ 1.213994] Call Trace: [ 1.213995] [ 1.213996] dump_stack_lvl+0x8e/0xd0 [ 1.214000] print_deadlock_bug+0x28b/0x2a0 [ 1.214020] lock_acquire+0xea/0x2a0 [ 1.214027] __mutex_lock+0xbf/0xd40 [ 1.214038] dev_set_allmulti+0x4e/0xb0 # real_dev->flags & IFF_ALLMULTI [ 1.214040] vlan_dev_open+0xa5/0x170 # ndo_open on vlandev [ 1.214042] __dev_open+0x145/0x270 [ 1.214046] __dev_change_flags+0xb0/0x1e0 [ 1.214051] netif_change_flags+0x22/0x60 # IFF_UP vlandev [ 1.214053] dev_change_flags+0x61/0xb0 # for each device in group from dev->vlan_info [ 1.214055] vlan_device_event+0x766/0x7c0 # on netdevsim0 [ 1.214058] notifier_call_chain+0x78/0x120 [ 1.214062] netif_open+0x6d/0x90 [ 1.214064] dev_open+0x5b/0xb0 # locks netdevsim0 [ 1.214066] bond_enslave+0x64c/0x1230 [ 1.214075] do_set_master+0x175/0x1e0 # on netdevsim0 [ 1.214077] do_setlink+0x516/0x13b0 [ 1.214094] rtnl_newlink+0xaba/0xb80 [ 1.214132] rtnetlink_rcv_msg+0x440/0x490 [ 1.214144] netlink_rcv_skb+0xeb/0x120 [ 1.214150] netlink_unicast+0x1f9/0x320 [ 1.214153] netlink_sendmsg+0x346/0x3f0 [ 1.214157] __sock_sendmsg+0x86/0xb0 [ 1.214160] ____sys_sendmsg+0x1c8/0x220 [ 1.214164] ___sys_sendmsg+0x28f/0x2d0 [ 1.214179] __x64_sys_sendmsg+0xef/0x140 [ 1.214184] do_syscall_64+0xec/0x1d0 [ 1.214190] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 1.214191] RIP: 0033:0x7f2d1b4a7e56 Device setup: netdevsim0 (down) ^ ^ bond netdevsim1.100@netdevsim1 allmulticast=on (down) Al esclavizar el dispositivo inferior (netdevsim0) que tiene una VLAN, propagamos los indicadores allmuti/promisc de la VLAN durante ndo_open. Esto provoca el (re)bloqueo de real_dev. Allmulti/promisc se propaga cuando cambian los indicadores, no cuando están abiertos. Hay un ligero cambio semántico: las VLAN inactivas ahora propagan los indicadores, pero es poco probable que esto cause los problemas reales. Reproductor: echo 0 1 > /sys/bus/netdevsim/new_device dev_path=$(ls -d /sys/bus/netdevsim/devices/netdevsim0/net/*) dev=$(echo $dev_path | rev | cut -d/ -f1 | rev) ip link set dev $dev name netdevsim0 ip link set dev netdevsim0 up ip link add link netdevsim0 name netdevsim0.100 type vlan id 100 ip link set dev netdevsim0.100 allm ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PCI: vmd: Convertir vmd_dev::cfg_lock en tipo raw_spinlock_t El acceso al espacio de configuración PCI mediante pci_ops::read y pci_ops::write es un acceso de hardware de bajo nivel. Se puede acceder a las funciones con interrupciones deshabilitadas incluso en PREEMPT_RT. El pci_lock es un raw_spinlock_t para este propósito. Un spinlock_t se convierte en un bloqueo inactivo en PREEMPT_RT, por lo que no se puede adquirir con interrupciones deshabilitadas. Se accede a vmd_dev::cfg_lock en el mismo contexto que el pci_lock. Convertir vmd_dev::cfg_lock en un tipo raw_spinlock_t para que pueda usarse con interrupciones deshabilitadas. Esto se informó como: ERROR: función inactiva llamada desde un contexto no válido en kernel/locking/spinlock_rt.c:48 Rastreo de llamadas: rt_spin_lock+0x4e/0x130 vmd_pci_read+0x8d/0x100 [vmd] pci_user_read_config_byte+0x6f/0xe0 pci_read_config+0xfe/0x290 sysfs_kf_bin_read+0x68/0x90 [bigeasy: reformular el mensaje de confirmación] Probado por: Luis Claudio R. Goncalves [kwilczynski: registro de confirmaciones] [bhelgaas: agregar información del informe de https://lore.kernel.org/lkml/20241218115951.83062-1-ryotkkr98@gmail.com/]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe/vf: No intente activar un reinicio completo de GT si VF Los VF no tienen acceso al registro GDRST(0x941c) que el controlador usa para reiniciar un GT. Intento de activar un reinicio usando debugfs: $ cat /sys/kernel/debug/dri/0000:00:02.1/gt0/force_reset o debido a una condición de bloqueo detectada por el controlador conduce a: [ ] xe 0000:00:02.1: [drm] GT0: intentando reiniciar desde force_reset [xe] [ ] xe 0000:00:02.1: [drm] GT0: reinicio en cola [ ] xe 0000:00:02.1: [drm] GT0: reinicio iniciado [ ] ------------[ cortar aquí ]------------ [ ] xe 0000:00:02.1: [drm] GT0: VF está intentando escribir 0x1 en un registro inaccesible 0x941c+0x0 [ ] ADVERTENCIA: CPU: 3 PID: 3069 en controladores/gpu/drm/xe/xe_gt_sriov_vf.c:996 xe_gt_sriov_vf_write32+0xc6/0x580 [xe] [ ] RIP: 0010:xe_gt_sriov_vf_write32+0xc6/0x580 [xe] [ ] Rastreo de llamadas: [ ] [ ] ? show_regs+0x6c/0x80 [ ] ? __warn+0x93/0x1c0 [ ] ? xe_gt_sriov_vf_write32+0xc6/0x580 [xe] [ ] ? report_bug+0x182/0x1b0 [ ] ? handle_bug+0x6e/0xb0 [ ] ? asm_exc_invalid_op+0x1b/0x20 [ ] ? xe_gt_sriov_vf_write32+0xc6/0x580 [xe] [ ] ? xe_gt_sriov_vf_write32+0xc6/0x580 [xe] [ ] ? xe_gt_tlb_invalidation_reset+0xef/0x110 [xe] [ ] ? Solucione esto enviando la acción H2G VF_RESET(0x5507) en su lugar.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: venus: hfi: se ha añadido una comprobación para gestionar la escritura OOB en la región sfr. sfr->buf_size se encuentra en memoria compartida y puede ser modificado por un usuario malintencionado. Es posible escribir OOB cuando el tamaño es mayor que el del búfer de datos sfr. En estos casos, limite el tamaño al tamaño asignado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: venus: hfi: se ha añadido una comprobación para gestionar el tamaño incorrecto de queue size qsize representa el tamaño de la cola compartida entre el controlador y el firmware de vídeo. El firmware puede modificar este valor a un valor grande no válido. En tal situación, el espacio vacío será mayor que el espacio realmente disponible. Dado que new_wr_idx no se comprueba, el siguiente código resultará en una escritura fuera de banda (OOB). ... qsize = qhdr->q_size if (wr_idx >= rd_idx) empty_space = qsize - (wr_idx - rd_idx) .... if (new_wr_idx < qsize) { memcpy(wr_ptr, packet, dwords << 2) --> Escritura fuera de banda (OOB). Se ha añadido una comprobación para garantizar que qsize se encuentre dentro del tamaño asignado al leer y escribir paquetes en la cola.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: venus: hfi_parser: añadir comprobación para evitar accesos fuera de los límites. Existe la posibilidad de que init_codecs se invoque varias veces durante la manipulación de la carga útil del firmware de vídeo. En tal caso, si codecs_count se incrementa a un valor superior a MAX_CODEC_NUM, puede haber accesos fuera de los límites. Restablezca el contador para que siempre comience desde el principio.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: venus: hfi_parser: refactorización de la lógica de análisis de paquetes HFI. words_count indica el número de palabras en el payload total, mientras que data apunta al payload de varias propiedades dentro de ella. Cuando words_count alcanza la última palabra, data puede acceder a memoria más allá de payload total. Esto puede provocar accesos fuera de banda (OOB). Con este parche, la API de utilidad para gestionar propiedades individuales ahora devuelve el tamaño de los datos consumidos. Por consiguiente, los bytes restantes se calculan antes de analizar el payload, eliminando así las posibilidades de accesos fuera de banda (OOB).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bus: mhi: host: Corrección de la competencia entre unprepare y queue_buf. Un controlador de cliente podría usar mhi_unprepare_from_transfer() para silenciar los datos entrantes durante su desconexión. El controlador de cliente también podría estar procesando datos simultáneamente, lo que resulta en una llamada a mhi_queue_buf(), que invocará mhi_gen_tre(). Si mhi_gen_tre() se ejecuta después de que mhi_unprepare_from_transfer() haya desconectado el canal, se producirá un pánico debido a una desreferencia no válida que provoca un fallo de página. Esto ocurre porque mhi_gen_tre() no verifica el estado del canal después de bloquearlo. Para solucionar esto, haga que mhi_gen_tre() confirme que el estado del canal es válido o devuelva un error para evitar acceder a los datos desinicializados. [mani: etiqueta estable añadida]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: arm/crc-t10dif: corrige el uso de una matriz fuera de alcance en crc_t10dif_arch() Corrige un error tonto en el que se usaba una matriz fuera de su alcance.