Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5: LAG, corregir la lógica sobre MLX5_LAG_FLAG_NDEVS_READY Solo establezca MLX5_LAG_FLAG_NDEVS_READY si ambos dispositivos de red están registrados. Hacerlo garantiza que tanto ldev->pf[MLX5_LAG_P0].dev como ldev->pf[MLX5_LAG_P1].dev tengan punteros válidos cuando MLX5_LAG_FLAG_NDEVS_READY esté establecido. El problema principal es la asimetría en la configuración de MLX5_LAG_FLAG_NDEVS_READY y su borrado. La configuración se realiza incorrectamente cuando tanto ldev->pf[MLX5_LAG_P0].dev como ldev->pf[MLX5_LAG_P1].dev están establecidos; Se borra correctamente cuando se borra ldev->pf[i].netdev. Considere el siguiente escenario: 1. PF0 carga y asigna un puntero válido a ldev->pf[MLX5_LAG_P0].dev. 2. PF1 carga y asigna punteros válidos a ldev->pf[MLX5_LAG_P1].dev y ldev->pf[MLX5_LAG_P1].netdev. Esto da como resultado que MLX5_LAG_FLAG_NDEVS_READY se configure. 3. PF0 se descarga antes de asignar dev->pf[MLX5_LAG_P0].netdev. MLX5_LAG_FLAG_NDEVS_READY permanece configurado. La ejecución posterior de mlx5_do_bond() dará como resultado una desreferencia de puntero nulo al llamar a mlx5_lag_is_multipath(). Este parche corrige el siguiente seguimiento de llamada encontrado: [ 1293.475195] ERROR: desreferencia de puntero NULL del kernel, dirección: 00000000000009a8 [ 1293.478756] #PF: acceso de lectura del supervisor en modo kernel [ 1293.481320] #PF: error_code(0x0000) - página no presente [ 1293.483686] PGD 0 P4D 0 [ 1293.484434] Oops: 0000 [#1] SMP PTI [ 1293.485377] CPU: 1 PID: 23690 Comm: kworker/u16:2 No contaminado 5.18.0-rc5_for_upstream_min_debug_2022_05_05_10_13 #1 [ 1293.488039] Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 01/04/2014 [ 1293.490836] Cola de trabajo: mlx5_lag mlx5_do_bond_work [mlx5_core] [ 1293.492448] RIP: 0010:mlx5_lag_is_multipath+0x5/0x50 [mlx5_core] [ 1293.494044] Código: e8 70 40 ff e0 48 8b 14 24 48 83 05 5c 1a 1b 00 01 e9 19 ff ff ff 48 83 05 47 1a 1b 00 01 eb d7 0f 1f 44 00 00 0f 1f 44 00 00 <48> 8b 87 a8 09 00 00 48 85 c0 74 26 48 83 05 a7 1b 1b 00 01 41 b8 [ 1293.498673] RSP: 0018:ffff88811b2fbe40 EFLAGS: 00010202 [ 1293.500152] RAX: ffff88818a94e1c0 RBX: ffff888165eca6c0 RCX: 0000000000000000 [ 1293.501841] RDX: 0000000000000001 RSI: ffff88818a94e1c0 RDI: 0000000000000000 [ 1293.503585] RBP: 0000000000000000 R08: ffff888119886740 R09: ffff888165eca73c [ 1293.505286] R10: 0000000000000018 R11: 0000000000000018 R12: ffff88818a94e1c0 [ 1293.506979] R13: ffff888112729800 R14: 0000000000000000 R15: ffff888112729858 [ 1293.508753] FS: 000000000000000(0000) GS:ffff88852cc40000(0000) knlGS:0000000000000000 [ 1293.510782] CS: 0010 DS: 0000 ES: 0000 CR0: 000000080050033 [ 1293.512265] CR2: 00000000000009a8 CR3: 00000001032d4002 CR4: 0000000000370ea0 [ 1293.514001] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1293.515806] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfc: pn533: Se corrigen los errores de Use-After-Free causados por pn532_cmd_timeout. Cuando se desconecta el dispositivo uart pn532, se llama a pn532_uart_remove(). Sin embargo, no hay funciones en pn532_uart_remove() que puedan eliminar el temporizador cmd_timeout, lo que causaría errores de Use-After-Free. El proceso se muestra a continuación: (hilo 1) | (hilo 2) | pn532_uart_send_frame pn532_uart_remove | mod_timer(&pn532->cmd_timeout,...) ... | (esperar un tiempo) kfree(pn532) //FREE | pn532_cmd_timeout | pn532_uart_send_frame | pn532->... //USE Este parche añade del_timer_sync() a pn532_uart_remove() para evitar errores de Use-After-Free. Además, pn53x_unregister_nfc() está bien sincronizado, establece nfc_dev->shutting_down como verdadero y ninguna llamada al sistema podría reiniciar el temporizador cmd_timeout.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: NFSv4.2 corrige problemas con __nfs42_ssc_open. Al realizar una copia, un servidor de destino no debería aceptar el identificador de archivo proporcionado si no es un identificador de archivo normal. Si alloc_file_pseudo() falla, debemos decrementar una referencia en el inodo recién creado; de lo contrario, se produce una fuga.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xfrm: se corrige una fuga de referencias en __xfrm_policy_check(). El problema ocurre en una ruta de error en __xfrm_policy_check(). Cuando falla la obtención del objeto `pols[1]`, la función simplemente devuelve 0, olvidando decrementar el recuento de referencias de `pols[0]`, que se incrementa previamente mediante xfrm_sk_policy_lookup() o xfrm_policy_lookup(). Esto puede provocar fugas de memoria. Para solucionarlo, reduzca el recuento de referencias de `pols[0]` en esa ruta.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: kprobes: no llamar a disarm_kprobe() para kprobes deshabilitados. La suposición en __disable_kprobe() es errónea, y podría intentar desarmar un kprobe ya desarmado y ejecutar el comando WARN_ONCE() a continuación. [0] Podemos reproducir fácilmente este problema. 1. Escriba 0 en /sys/kernel/debug/kprobes/enabled. # echo 0 > /sys/kernel/debug/kprobes/enabled 2. Ejecute execsnoop. En este momento, un kprobe está deshabilitado. # /usr/share/bcc/tools/execsnoop & [1] 2460 PCOMM PID PPID RET ARGS # cat /sys/kernel/debug/kprobes/list ffffffff91345650 r __x64_sys_execve+0x0 [FTRACE] ffffffff91345650 k __x64_sys_execve+0x0 [DISABLED][FTRACE] 3. Escriba 1 en /sys/kernel/debug/kprobes/enabled, lo cual cambia kprobes_all_disarmed a falso pero no arma el kprobe deshabilitado. # echo 1 > /sys/kernel/debug/kprobes/enabled # cat /sys/kernel/debug/kprobes/list ffffffff91345650 r __x64_sys_execve+0x0 [FTRACE] ffffffff91345650 k __x64_sys_execve+0x0 [DESHABILITADO][FTRACE] 4. Matar execsnoop, cuando __disable_kprobe() llama a disarm_kprobe() para el kprobe deshabilitado y llega a WARN_ONCE() en __disarm_kprobe_ftrace(). # fg /usr/share/bcc/tools/execsnoop ^C En realidad, WARN_ONCE() se dispara dos veces, y __unregister_kprobe_top() pierde algunas limpiezas y deja el kprobe agregado en la tabla hash. Luego, __unregister_trace_kprobe() inicializa tk->rp.kp.list y crea un bucle infinito como este: addedd kprobe.list -> kprobe.list -. ^ | '.__.' En esta situación, estos comandos caen en el bucle infinito y provocan una parada o un bloqueo suave de la RCU. cat /sys/kernel/debug/kprobes/list : show_kprobe_addr() entra en el bucle infinito con la RCU. /usr/share/bcc/tools/execsnoop : warn_kprobe_rereg() contiene kprobe_mutex, y __get_valid_kprobe() queda atascado en el bucle. Para evitar este problema, asegúrese de no llamar a disarm_kprobe() para las kprobes deshabilitadas. [0] No se pudo desarmar kprobe-ftrace en __x64_sys_execve+0x0/0x40 (error -2) ADVERTENCIA: CPU: 6 PID: 2460 en kernel/kprobes.c:1130 __disarm_kprobe_ftrace.isra.19 (kernel/kprobes.c:1129) Módulos vinculados: ena CPU: 6 PID: 2460 Comm: execsnoop No contaminado 5.19.0+ #28 Nombre del hardware: Amazon EC2 c5.2xlarge/, BIOS 1.0 16/10/2017 RIP: 0010:__disarm_kprobe_ftrace.isra.19 (kernel/kprobes.c:1129) Código: 24 8b 02 eb c1 80 3d c4 83 f2 01 00 75 d4 48 8b 75 00 89 c2 48 c7 c7 90 fa 0f 92 89 04 24 c6 05 ab 83 01 e8 e4 94 f0 ff <0f> 0b 8b 04 24 eb b1 89 c6 48 c7 c7 60 fa 0f 92 89 04 24 e8 cc 94 RSP: 0018:ffff9e6ec154bd98 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffff930f7b00 RCX: 0000000000000001 RDX: 0000000080000001 RSI: ffffffff921461c5 RDI: 00000000ffffffff RBP: ffff89c504286da8 R08: 000000000000000 R09: c0000000fffeffff R10: 000000000000000 R11: ffff9e6ec154bc28 R12: ffff89c502394e40 R13: ffff89c502394c00 R14: ffff9e6ec154bc00 R15: 000000000000000 FS: 00007fe800398740(0000) GS:ffff89c812d80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000c00057f010 CR3: 0000000103b54006 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 00000000000000400 PKRU: 55555554 Seguimiento de llamadas: __disable_kprobe (kernel/kprobes.c:1716) disable_kprobe (kernel/kprobes.c:2392) __disable_trace_kprobe (kernel/trace/trace_kprobe.c:340) disable_trace_kprobe (kernel/trace/trace_kprobe.c:429) perf_trace_event_unreg.isra.2 (./include/linux/tracepoint.h:93 kernel/trace/trace_event_perf.c:168) perf_kprobe_destroy (kernel/trace/trace_event_perf.c:295) _free_event (kernel/events/core.c:4971) perf_event_release_kernel (kernel/events/core.c:5176) perf_release (kernel/events/core.c:5186) __fput (fs/file_table.c:321) task_work_run (./include/linux/---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrige null-ptr-deref en f2fs_get_dnode_of_data Hay un problema como el siguiente cuando se prueba la escritura atómica de f2fs: F2FS-fs (loop0): No se puede encontrar un sistema de archivos F2FS válido en el 2.º superbloque F2FS-fs (loop0): crc_offset no válido: 0 F2FS-fs (loop0): f2fs_check_nid_range: nid fuera de rango = 1, ejecute fsck para corregirlo. F2FS-fs (loop0): f2fs_check_nid_range: nid fuera de rango = 2, ejecute fsck para corregirlo. ======================================================================= ERROR: KASAN: null-ptr-deref en f2fs_get_dnode_of_data+0xac/0x16d0 Lectura de tamaño 8 en la dirección 000000000000028 por la tarea rep/1990 CPU: 4 PID: 1990 Comm: rep No contaminado 5.19.0-rc6-next-20220715 #266 Rastreo de llamadas: dump_stack_lvl+0x6e/0x91 print_report.cold+0x49a/0x6bb kasan_report+0xa8/0x130 f2fs_get_dnode_of_data+0xac/0x16d0 f2fs_do_write_data_page+0x2a5/0x1030 move_data_page+0x3c5/0xdf0 do_garbage_collect+0x2015/0x36c0 f2fs_gc+0x554/0x1d30 f2fs_balance_fs+0x7f5/0xda0 f2fs_write_single_data_page+0xb66/0xdc0 f2fs_write_cache_pages+0x716/0x1420 f2fs_write_data_pages+0x84f/0x9a0 do_writepages+0x130/0x3a0 filemap_fdatawrite_wbc+0x87/0xa0 file_write_and_wait_range+0x157/0x1c0 f2fs_do_sync_file+0x206/0x12d0 f2fs_sync_file+0x99/0xc0 vfs_fsync_range+0x75/0x140 f2fs_file_write_iter+0xd7b/0x1850 vfs_write+0x645/0x780 ksys_write+0xf1/0x1e0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd Como el commit 3db1de0e582c cambió la forma de escritura atómica que ahora es un cow_inode para el archivo de escritura atómica, y también marca cow_inode como FI_ATOMIC_FILE. Al escribir en f2fs_do_write_data_page, cow_inode usará el valor nulo de cow_inode. Esto activará null-ptr-deref. Para solucionar el problema, introduzca el indicador FI_COW_FILE para el inodo COW. Fiexes: 3db1de0e582c("f2fs: cambiar la ruta de escritura atómica actual")

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: video: fbdev: i740fb: Comprobación del argumento de i740_calc_vclk(). Dado que el usuario puede controlar los argumentos de ioctl() desde el espacio de usuario, bajo argumentos especiales, esto puede provocar un error de división por cero. Si el usuario proporciona un valor de 'pixclock' incorrecto que hace que el argumento de i740_calc_vclk() sea menor que 'I740_RFREQ_FIX', se producirá un error de división por cero en: drivers/video/fbdev/i740fb.c:353 p_best = min(15, ilog2(I740_MAX_VCO_FREQ / (freq / I740_RFREQ_FIX))); El siguiente registro puede revelarlo: error de división: 0000 [#1] PREEMPT SMP KASAN PTI RIP: 0010:i740_calc_vclk drivers/video/fbdev/i740fb.c:353 [en línea] RIP: 0010:i740fb_decode_var drivers/video/fbdev/i740fb.c:646 [en línea] RIP: 0010:i740fb_set_par+0x163f/0x3b70 drivers/video/fbdev/i740fb.c:742 Seguimiento de llamadas: fb_set_var+0x604/0xeb0 drivers/video/fbdev/core/fbmem.c:1034 do_fb_ioctl+0x234/0x670 drivers/video/fbdev/core/fbmem.c:1110 fb_ioctl+0xdd/0x130 drivers/video/fbdev/core/fbmem.c:1189 Solucione esto verificando primero el argumento de i740_calc_vclk().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nft_tproxy: restricción al gancho de preenrutamiento. TPROXY solo se permite desde el preenrutamiento, pero nft_tproxy no lo comprueba. Esto corrige un fallo (desreferencia nula) al usar tproxy desde la salida, por ejemplo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: flowtable: arreglo de flujos atascados en la limpieza debido a trabajo pendiente Para limpiar la tabla de flujo cuando está libre, normalmente ocurre la siguiente secuencia en orden: 1) Se detiene el trabajo de gc_step para deshabilitar cualquier solicitud de estadísticas/del. 2) Todas las entradas de la tabla de flujo se establecen en estado de desmontaje. 3) Se ejecuta gc_step, que pondrá en cola el trabajo de del de HW para cada entrada de la tabla de flujo. 4) Se espera a que finalice el trabajo del del anterior (vaciado). 5) Se vuelve a ejecutar gc_step, eliminando todas las entradas de la tabla de flujo. 6) Se libera la tabla de flujo. Pero si una entrada de la tabla de flujo ya tiene estadísticas de HW pendientes o trabajo de adición de HW, el paso 3 no pondrá en cola el trabajo de del de HW (se omitirá), el paso 4 esperará a que finalicen las adiciones/estadísticas pendientes y el paso 5 pondrá en cola el trabajo de del de HW que podría ejecutarse después de liberar la tabla de flujo. Para solucionar lo anterior, este parche limpia el trabajo pendiente, luego establece el indicador de desmontaje en todos los flujos en la tabla de flujo y fuerza la ejecución de un recolector de basura para poner en cola el trabajo para eliminar los flujos del hardware, luego limpia este nuevo trabajo pendiente y (finalmente) fuerza la ejecución de otro recolector de basura para eliminar la entrada de la tabla de flujo del software. Rastreo de pila: [47773.882335] ERROR: KASAN: Use-After-Free en down_read+0x99/0x460 [47773.883634] Escritura de tamaño 8 en la dirección ffff888103b45aa8 por la tarea kworker/u20:6/543704 [47773.885634] CPU: 3 PID: 543704 Comm: kworker/u20:6 No contaminado 5.12.0-rc7+ #2 [47773.886745] Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009) [47773.888438] Cola de trabajo: nf_ft_offload_del flow_offload_work_handler [nf_flow_table] [47773.889727] Rastreo de llamadas: [47773.890214] dump_stack+0xbb/0x107 [47773.890818] print_address_description.constprop.0+0x18/0x140 [47773.892990] kasan_report.cold+0x7c/0xd8 [47773.894459] kasan_check_range+0x145/0x1a0 [47773.895174] down_read+0x99/0x460 [47773.899706] nf_flow_offload_tuple+0x24f/0x3c0 [nf_flow_table] [47773.907137] flow_offload_work_handler+0x72d/0xbe0 [nf_flow_table] [47773.913372] process_one_work+0x8ac/0x14e0 [47773.921325] [47773.921325] Allocated by task 592159: [47773.922031] kasan_save_stack+0x1b/0x40 [47773.922730] __kasan_kmalloc+0x7a/0x90 [47773.923411] tcf_ct_flow_table_get+0x3cb/0x1230 [act_ct] [47773.924363] tcf_ct_init+0x71c/0x1156 [act_ct] [47773.925207] tcf_action_init_1+0x45b/0x700 [47773.925987] tcf_action_init+0x453/0x6b0 [47773.926692] tcf_exts_validate+0x3d0/0x600 [47773.927419] fl_change+0x757/0x4a51 [cls_flower] [47773.928227] tc_new_tfilter+0x89a/0x2070 [47773.936652] [47773.936652] Freed by task 543704: [47773.937303] kasan_save_stack+0x1b/0x40 [47773.938039] kasan_set_track+0x1c/0x30 [47773.938731] kasan_set_free_info+0x20/0x30 [47773.939467] __kasan_slab_free+0xe7/0x120 [47773.940194] slab_free_freelist_hook+0x86/0x190 [47773.941038] kfree+0xce/0x3a0 [47773.941644] tcf_ct_flow_table_cleanup_work Descripción del parche original y seguimiento de la pila por Paul Blakey.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: corrección de corrupción de caché de espacio y posibles asignaciones dobles. Al probar space_cache v2 en un conjunto grande de máquinas, encontramos algunos síntomas: 1. Errores "no se puede agregar espacio libre :-17" (EEXIST). 2. Falta de información de espacio libre, a veces detectados con el error "falta información de espacio libre para X". 3. Espacio contabilizado dos veces: rangos asignados en el árbol de extensiones y marcados como libres en dicho árbol, rangos marcados como asignados dos veces en el árbol de extensiones o rangos marcados como libres dos veces en dicho árbol. Si estos últimos se almacenaban en el disco, el siguiente reinicio generaría el error BUG_ON() en add_new_free_space(). 4. En algunos hosts sin corrupción en disco ni mensajes de error, la caché de espacio en memoria (volcada con drgn) no coincidía con el árbol de espacio libre. Todos estos síntomas tienen la misma causa subyacente: una competencia entre el almacenamiento en caché del espacio libre de un grupo de bloques y su devolución a la caché de espacio en memoria para las extensiones fijadas provoca la duplicación de un rango libre en la caché de espacio. Esta competencia se produce cuando se almacena en caché el espacio libre del árbol de espacio libre (space_cache=v2) o del árbol de extensiones (nospace_cache, o space_cache=v1 si es necesario regenerar la caché). Se supone que struct btrfs_block_group::last_byte_to_unpin y struct btrfs_block_group::progress protegen contra esta competencia, pero el commit d0c2f4fa555e ("btrfs: hacer que las sincronizaciones simultáneas esperen menos al esperar el commit de una transacción") interrumpió esto sutilmente al permitir que varias transacciones desanclaran extensiones simultáneamente. Específicamente, la ejecución es la siguiente: 1. Se elimina una extensión de un grupo de bloques no almacenados en caché en la transacción A. 2. Se llama a btrfs_commit_transaction() para la transacción A. 3. btrfs_run_delayed_refs() -> __btrfs_free_extent() ejecuta la referencia retrasada para la extensión eliminada. 4. __btrfs_free_extent() -> do_free_extent_accounting() -> add_to_free_space_tree() agrega la extensión eliminada nuevamente al árbol de espacio libre. 5. do_free_extent_accounting() -> btrfs_update_block_group() -> btrfs_cache_block_group() pone en cola el grupo de bloques para almacenar en caché. block_group->progress se establece en block_group->start. 6. btrfs_commit_transaction() para la transacción A llama a switch_commit_roots(). Establece block_group->last_byte_to_unpin en block_group->progress, que es block_group->start porque el grupo de bloques aún no se ha almacenado en caché. 7. El hilo de caché accede a nuestro grupo de bloques. Dado que las raíces de las confirmaciones ya se han cambiado, load_free_space_tree() detecta la extensión eliminada como libre y la añade a la caché de espacio. Finaliza el almacenamiento en caché y establece block_group->progress en U64_MAX. 8. btrfs_commit_transaction() avanza la transacción A a TRANS_STATE_SUPER_COMMITTED. 9. fsync llama a btrfs_commit_transaction() para la transacción B. Dado que la transacción A ya está en TRANS_STATE_SUPER_COMMITTED y el commit es para fsync, avanza. 10. btrfs_commit_transaction() para la transacción B llama a switch_commit_roots(). Esta vez, el grupo de bloques ya se ha almacenado en caché, por lo que establece block_group->last_byte_to_unpin en U64_MAX. 11. btrfs_commit_transaction() para la transacción A llama a btrfs_finish_extent_commit(), que llama a unpin_extent_range() para la extensión eliminada. Ve que last_byte_to_unpin está establecido en U64_MAX (¡por la transacción B!), por lo que vuelve a añadir la extensión eliminada a la caché de espacio. Esto explica todos nuestros síntomas anteriores: * Si la secuencia de eventos es exactamente la descrita anteriormente, cuando se vuelve a añadir el espacio libre en el paso 11, fallará con EEXIST. * ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rxrpc: Arreglar el bloqueo en sendmsg de rxrpc Corrige tres errores en la implementación de sendmsg de rxrpc: (1) rxrpc_new_client_call() debería liberar el bloqueo del socket al devolver un error de rxrpc_get_call_slot(). (2) rxrpc_wait_for_tx_window_intr() retornará sin el mutex de llamada retenido en caso de que seamos interrumpidos por una señal mientras esperamos espacio de transmisión en el socket o volvemos a bloquear el mutex de llamada posteriormente. Corrige esto mediante: (a) mover el desbloqueo/bloqueo del mutex de llamada hasta rxrpc_send_data() de modo que el bloqueo no se mantenga alrededor de todo rxrpc_wait_for_tx_window*() y (b) indicar a los llamadores superiores si retornamos con el bloqueo eliminado. Tenga en cuenta que esto significa que recvmsg() no se bloqueará en esta llamada mientras esperamos. (3) Después de eliminar y recuperar el mutex de llamada, rxrpc_send_data() debe volver a verificar el estado del búfer tx_pending y la comprobación de tx_total_len en caso de que hayamos utilizado otro sendmsg() en la misma llamada. Pensándolo bien, podría tener sentido tener bloqueos diferentes para sendmsg() y recvmsg(). Probablemente no sea necesario que recvmsg() espere a sendmsg(). Esto significa que recvmsg() puede devolver MSG_EOR, lo que indica que una llamada está inactiva antes de que un sendmsg() a esa llamada regrese, pero eso puede ocurrir de todos modos. Sin la corrección (2), se puede inducir algo como lo siguiente: ¡ADVERTENCIA: se detectó un saldo de desbloqueo incorrecto! 5.16.0-rc6-syzkaller #0 No contaminado ------------------------------------- syz-executor011/3597 está intentando liberar el bloqueo (&call->user_mutex) en: [] rxrpc_do_sendmsg+0xc13/0x1350 net/rxrpc/sendmsg.c:748 ¡pero no hay más bloqueos para liberar! Otra información que podría ayudarnos a depurar esto: syz-executor011/3597 no tiene bloqueos. ... Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_unlock_imbalance_bug include/trace/events/lock.h:58 [en línea] __lock_release kernel/locking/lockdep.c:5306 [en línea] lock_release.cold+0x49/0x4e kernel/locking/lockdep.c:5657 __mutex_unlock_slowpath+0x99/0x5e0 kernel/locking/mutex.c:900 rxrpc_do_sendmsg+0xc13/0x1350 net/rxrpc/sendmsg.c:748 rxrpc_sendmsg+0x420/0x630 net/rxrpc/af_rxrpc.c:561 sock_sendmsg_nosec net/socket.c:704 [en línea] sock_sendmsg+0xcf/0x120 net/socket.c:724 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2409 ___sys_sendmsg+0xf3/0x170 net/socket.c:2463 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2492 do_syscall_x64 arch/x86/entry/common.c:50 [en línea] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae [Gracias a Hawkins Jiawei y Khalid Masum por sus intentos de solucionar este problema]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: lantiq_xrx200: restaurar el búfer si falla la asignación de memoria. En caso de fallo en la asignación de memoria, se almacena una dirección de búfer no válida. Al volver a utilizar este descriptor, el sistema entra en pánico en la función build_skb() al acceder a la memoria.