Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/gup: corregir el problema de seguridad de FOLL_FORCE COW y eliminar FOLL_COW Desde que ocurrió el problema de seguridad Dirty COW (CVE-2016-5195), sabemos que FOLL_FORCE puede ser posiblemente peligroso, especialmente si hay ejecuciones que pueden ser explotadas por el espacio de usuario. En este momento, sería suficiente tener algún código que establezca un PTE de una página compartida asignada a R/O sucia, para que FOLL_FORCE pueda escribir en ella por error. Las implicaciones de establecer una PTE protegida contra escritura sucia podrían no ser inmediatamente obvias para todos. Y de hecho, desde el commit 9ae0f87d009c ("mm/shmem: establecer un pte sucio incondicionalmente en mfill_atomic_install_pte"), podemos usar UFFDIO_CONTINUE para asignar una página shmem R/O mientras se marca el pte sucio. Esto puede ser usado por usuarios sin privilegios para modificar el contenido de archivos tmpfs/shmem incluso si no tienen permisos de escritura, y para evitar el sellado de escritura de memfd (COW sucio restringido a tmpfs/shmem [CVE-2022-2590]). Para solucionar definitivamente estos problemas de seguridad, la clave es que solo necesitamos esa lógica de reintento sofisticada (FOLL_COW) para las asignaciones de COW que no permiten escritura (!VM_WRITE). En una asignación de COW, solo se interrumpe si se asigna una página anónima exclusiva. Si se asigna otra cosa, o si la página anónima asignada puede ser compartida (!PageAnonExclusive), se debe generar un fallo de escritura para interrumpir COW. Si no se encuentra una página anónima exclusiva al reintentar, se debe activar la interrupción de COW de nuevo porque algo intervino. Dejemos de lado este manejo de reintentos obligatorios y errores de escritura y utilicemos nuestra bandera PageAnonExclusive() para tomar una decisión similar y usar la misma lógica de COW que en otras partes del kernel. Si encontramos una PTE en una asignación de COW que no asigne una página anónima exclusiva, COW no se rompió correctamente y debemos generar un falso fallo de escritura para romperlo. Al igual que en can_change_pte_writable(), añadido mediante el commit 64fe24a3e05e ("mm/mprotect: intentar evitar errores de escritura en páginas anónimas exclusivas al cambiar la protección") y el commit 76aefad628aa ("mm/mprotect: corregir la comprobación de errores de escritura en can_change_pte_writable()"), nos encargamos de los errores de escritura y uffd-wp manualmente. Por ejemplo, una escritura (write()) mediante /proc/self/mem a un rango protegido por uffd-wp debe fallar en lugar de conceder acceso de escritura silenciosamente y omitir el controlador de errores del espacio de usuario. Tenga en cuenta que FOLL_FORCE no solo se usa para el acceso de depuración, sino que también lo activan aplicaciones sin intenciones de depuración, por ejemplo, al anclar páginas mediante RDMA. Esto corrige CVE-2022-2590. Tenga en cuenta que solo x86_64 y aarch64 se ven afectados, ya que solo estos admiten CONFIG_HAVE_ARCH_USERFAULTFD_MINOR. Afortunadamente, FOLL_COW ya no es necesario para gestionar FOLL_FORCE. Así que simplemente lo eliminaremos. Gracias a Nadav Amit por señalar que la comprobación pte_dirty() en el código de FOLL_FORCE es problemática y podría ser explotable. Nota 1: No comprobamos si la PTE está sucia porque ya no es relevante para tomar la decisión de "fue COWed", y quien modifique la página debe configurarla como sucia de todos modos. Nota 2: Los kernels anteriores a la compatibilidad extendida con uffd-wp y a PageAnonExclusive (< 5.19) pueden simplemente revertir el commit problemática y estar seguros con respecto a UFFDIO_CONTINUE. Una adaptación a la versión 5.19 requiere ajustes menores debido a la falta de vma_soft_dirty_enabled().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/64: Inicializar etiquetas de salto antes de parse_early_param() En 64 bits, llamar a jump_label_init() en setup_feature_keys() es demasiado tarde porque las claves estáticas se pueden usar en subrutinas de parse_early_param(), que a su vez es una subrutina de early_init_devtree(). Por ejemplo, al arrancar con "threadirqs": static_key_enable_cpuslocked(): clave estática '0xc000000002953260' usada antes de llamar a jump_label_init() ADVERTENCIA: CPU: 0 PID: 0 en kernel/jump_label.c:166 static_key_enable_cpuslocked+0xfc/0x120 ... NIP static_key_enable_cpuslocked+0xfc/0x120 LR static_key_enable_cpuslocked+0xf8/0x120 Rastreo de llamadas: static_key_enable_cpuslocked+0xf8/0x120 (no confiable) static_key_enable+0x30/0x50 setup_forced_irqthreads+0x28/0x40 do_early_param+0xa0/0x108 parse_args+0x290/0x4e0 parse_early_options+0x48/0x5c parse_early_param+0x58/0x84 early_init_devtree+0xd4/0x518 early_setup+0xb4/0x214 Por lo tanto, llame a jump_label_init() justo antes de parse_early_param() en early_init_devtree(). [mpe: Agregar seguimiento de llamadas al registro de cambios y ediciones menores de redacción].

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xfrm: política: corregir la desreferencia de puntero nulo de metadatos dst->dev xmit Cuando intentamos transmitir un skb con metadata_dst adjunto (es decir, dst->dev == NULL) a través de la interfaz xfrm, podemos alcanzar una desreferencia de puntero nulo[1] en xfrmi_xmit2() -> xfrm_lookup_with_ifid() debido a la comprobación de un dispositivo skb de bucle invertido cuando no hay ninguna política que desreferencia dst->dev incondicionalmente. No tener dst->dev puede interpretarse como que no es un dispositivo de bucle invertido, así que simplemente agregue una comprobación para un dst_orig->dev nulo. Con esta corrección, los contadores de errores de Tx de la interfaz xfrm suben como de costumbre. [1] net-next calltrace capturado a través de netconsole: ERROR: desreferencia de puntero NULL del kernel, dirección: 00000000000000c0 #PF: acceso de lectura del supervisor en modo kernel #PF: error_code(0x0000) - página no presente PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP CPU: 1 PID: 7231 Comm: ping Kdump: cargado No contaminado 5.19.0+ #24 Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-1.fc36 04/01/2014 RIP: 0010:xfrm_lookup_with_ifid+0x5eb/0xa60 Código: 8d 74 24 38 e8 26 a4 37 00 48 89 c1 e9 12 fc ff ff 49 63 ed 41 83 fd ser 0f 85 ser 01 00 00 41 ser ff ff ff ff 45 31 ed 48 8b 03 80 c0 00 00 00 08 75 0f 41 80 bc 24 19 0d 00 00 01 0f 84 1e 02 RSP: 0018:ffffb0db82c679f0 EFLAGS: 00010246 RAX: 000000000000000 RBX: ffffd0db7fcad430 RCX: ffffb0db82c67a10 RDX: 00000000000000000 RSI: 0000000000000000 RDI: ffffb0db82c67a80 RBP: ffffb0db82c67a80 R08: ffffb0db82c67a14 R09: 0000000000000000 R10: 0000000000000000 R11: ffff8fa449667dc8 R12: ffffffff966db880 R13: 000000000000000 R14: 00000000ffffffff R15: 000000000000000 FS: 00007ff35c83f000(0000) GS:ffff8fa478480000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000000c0 CR3: 000000001ebb7000 CR4: 0000000000350ee0 Seguimiento de llamadas: xfrmi_xmit+0xde/0x460 ? tcf_bpf_act+0x13d/0x2a0 dev_hard_start_xmit+0x72/0x1e0 __dev_queue_xmit+0x251/0xd30 ip_finish_output2+0x140/0x550 ip_push_pending_frames+0x56/0x80 raw_sendmsg+0x663/0x10a0 ? try_charge_memcg+0x3fd/0x7a0 ? __mod_memcg_lruvec_state+0x93/0x110 ? sock_sendmsg+0x30/0x40 sock_sendmsg+0x30/0x40 __sys_sendto+0xeb/0x130 ? manejar_mm_fault+0xae/0x280 ? hacer_dirección_usuario_fault+0x1e7/0x680 ? kvm_read_and_reset_apf_flags+0x3b/0x50 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x34/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7ff35cac1366 Código: eb 0b 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff ff eb b8 0f 1f 00 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 11 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 72 c3 90 55 48 83 ec 30 44 89 4c 24 2c 4c 89 RSP: 002b:00007fff738e4028 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007fff738e57b0 RCX: 00007ff35cac1366 RDX: 0000000000000040 RSI: 0000557164e4b450 RDI: 0000000000000003 RBP: 0000557164e4b450 R08: 00007fff738e7a2c R09: 0000000000000010 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000040 R13: 00007fff738e5770 R14: 00007fff738e4030 R15: 0000001d00000001 Módulos vinculados en: netconsole veth br_netfilter bridge bonding virtio_net [última descarga: netconsole] CR2: 00000000000000c0

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ice: xsk: prohibir el uso de un id de cola no balanceado Corrija el siguiente escenario: 1. ethtool -L $IFACE rx 8 tx 96 2. xdpsock -q 10 -t -z Lo anterior se refiere a un caso en el que el usuario desea adjuntar un socket XSK en modo txonly a un id de cola que no tiene una cola Rx correspondiente. En este momento, la lógica XSK de ice está estrechamente ligada a actuar en un "par de colas", por ejemplo, las colas Tx y Rx en un id de cola dado están deshabilitadas/habilitadas y a ambas se les asignará un grupo XSK, lo cual no funciona para la configuración de cola presentada. Esto da como resultado el splat incluido en la parte inferior, que es básicamente un acceso OOB a la matriz de anillo Rx. Para solucionar esto, permita el uso de los id solo en el ámbito de las colas "combinadas" reportadas por ethtool. Sin embargo, la lógica debe reescribirse para permitir tales configuraciones más adelante, lo que terminaría como una reescritura completa de la ruta de control, así que sigamos con esta solución temporal. [420160.558008] ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000082 [420160.566359] #PF: acceso de lectura del supervisor en modo kernel [420160.572657] #PF: error_code(0x0000) - página no presente [420160.579002] PGD 0 P4D 0 [420160.582756] Oops: 0000 [#1] PREEMPT SMP NOPTI [420160.588396] CPU: 10 PID: 21232 Comm: xdpsock Tainted: G OE 5.19.0-rc7+ #10 [420160.597893] Nombre del hardware: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 19/03/2019 [420160.609894] RIP: 0010:ice_xsk_pool_setup+0x44/0x7d0 [ice] [420160.616968] Código: f3 48 83 ec 40 48 8b 4f 20 48 8b 3f 65 48 8b 04 25 28 00 00 00 48 89 44 24 38 31 c0 48 8d 04 ed 00 00 00 00 48 01 c1 48 8b 11 <0f> b7 92 82 00 00 00 48 85 d2 0f 84 2d 75 00 00 48 8d 72 ff 48 85 [420160.639421] RSP: 0018:ffffc9002d2afd48 EFLAGS: 00010282 [420160.646650] RAX: 0000000000000050 RBX: ffff88811d8bdd00 RCX: ffff888112c14ff8 [420160.655893] RDX: 000000000000000 RSI: ffff88811d8bdd00 RDI: ffff888109861000 [420160.665166] RBP: 000000000000000a R08: 000000000000000a R09: 0000000000000000 [420160.674493] R10: 000000000000889f R11: 0000000000000000 R12: 000000000000000a [420160.683833] R13: 00000000000000a R14: 0000000000000000 R15: ffff888117611828 [420160.693211] FS: 00007fa869fc1f80(0000) GS:ffff8897e0880000(0000) knlGS:0000000000000000 [420160.703645] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [420160.711783] CR2: 000000000000082 CR3: 00000001d076c001 CR4: 00000000007706e0 [420160.721399] DR0: 00000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [420160.731045] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [420160.740707] PKRU: 55555554 [420160.745960] Rastreo de llamadas: [420160.750962] [420160.755597] ? kmalloc_large_node+0x79/0x90 [420160.762703] ? __kmalloc_node+0x3f5/0x4b0 [420160.769341] xp_assign_dev+0xfd/0x210 [420160.775661] ? shmem_file_read_iter+0x29a/0x420 [420160.782896] xsk_bind+0x152/0x490 [420160.788943] __sys_bind+0xd0/0x100 [420160.795097] ? exit_to_user_mode_prepare+0x20/0x120 [420160.802801] __x64_sys_bind+0x16/0x20 [420160.809298] do_syscall_64+0x38/0x90 [420160.815741] entry_SYSCALL_64_after_hwframe+0x63/0xcd [420160.823731] RIP: 0033:0x7fa86a0dd2fb [420160.830264] Code: c3 66 0f 1f 44 00 00 48 8b 15 69 8b 0c 00 f7 d8 64 89 02 b8 ff ff ff ff eb bc 0f 1f 44 00 00 f3 0f 1e fa b8 31 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 3d 8b 0c 00 f7 d8 64 89 01 48 [420160.855410] RSP: 002b:00007ffc1146f618 EFLAGS: 00000246 ORIG_RAX: 0000000000000031 [420160.866366] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fa86a0dd2fb [420160.876957] RDX: 0000000000000010 RSI: 00007ffc1146f680 RDI: 0000000000000003 [420160.887604] RBP: 000055d7113a0520 R08: 00007fa868fb8000 R09: 0000000080000000 [420160.898293] R10: 0000000000008001 R11: 0000000000000246 R12: 000055d7113a04e0 [420160.909038] R13: 000055d7113a0320 R14: 000000000000000a R15: 0000000000000000 [420160.91 ---truncado---

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.