Vulnerabilidades

IBM TXSeries for Multiplatforms 10.1 es vulnerable a una denegación de servicio, causada por la aplicación incorrecta del tiempo de espera en operaciones de lectura individuales. Al realizar ataques de tipo slowloris, un atacante remoto podría aprovechar esta vulnerabilidad para provocar una denegación de servicio.

IBM TXSeries for Multiplatforms 10.1 podría permitir que un atacante remoto provoque una denegación de servicio mediante conexiones persistentes debido a una asignación incorrecta de recursos.

IBM Sterling Secure Proxy 6.0.0.0, 6.0.0.1, 6.0.0.2, 6.0.0.3, 6.1.0.0 y 6.2.0.0 podrían permitir que un atacante no autorizado recupere o altere contenidos de información confidencial debido a asignaciones de permisos incorrectas.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dm array: se corrige la liberación de un bloque de matriz defectuoso dos veces en dm_array_cursor_end Cuando dm_bm_read_lock() falla debido a errores de bloqueo o suma de comprobación, libera el bloque defectuoso implícitamente mientras deja atrás un puntero de salida no válido. El llamador de dm_bm_read_lock() no debe operar en este puntero dm_block no válido, o conducirá a un resultado indefinido. Por ejemplo, dm_array_cursor almacena en caché incorrectamente el puntero no válido al leer un bloque de matriz defectuoso, lo que causa una doble liberación en dm_array_cursor_end(), y luego alcanza el BUG_ON en dm-bufio cache_put(). Reproducir los pasos: 1. inicializar un dispositivo de caché dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 65536 linear /dev/sdc 8192" dmsetup create corig --table "0 524288 linear /dev/sdc $262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 dmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" 2. borrar el segundo bloque de matriz sin conexión dmsteup remove cache cmeta cdata corig mapping_root=$(dd if=/dev/sdc bs=1c count=8 skip=192 \ 2>/dev/null | hexdump -e '1/8 "%u\n"') ablock=$(dd if=/dev/sdc bs=1c count=8 skip=$((4096*mapping_root+2056)) \ 2>/dev/null | hexdump -e '1/8 "%u\n"') dd if=/dev/zero of=/dev/sdc bs=4k count=1 seek=$ablock 3. Intente volver a abrir el dispositivo de caché dmsetup create cmeta --table "0 8192 lineal /dev/sdc 0" dmsetup create cdata --table "0 65536 lineal /dev/sdc 8192" dmsetup create corig --table "0 524288 lineal /dev/sdc $262144" dmsetup create cache --table "0 524288 caché /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" Registros del kernel: (snip) device-mapper: array: array_block_check failed: blocknr 0 != wanted 10 device-mapper: block manager: array validator check failed for block 10 device-mapper: array: get_ablock failed device-mapper: cache metadata: dm_array_cursor_next for mapping failed ------------[ corte aquí ]------------ ¡ERROR del kernel en drivers/md/dm-bufio.c:638! Se corrige configurando el puntero de bloque en caché en NULL en caso de errores. Además del reproductor descrito anteriormente, esta corrección se puede verificar utilizando la prueba "array_cursor/damaged" en dm-unit: dm-unit run /pdata/array_cursor/damaged --kernel-dir

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: se corrige el error de división en los cálculos de escala del plano DM dm_get_plane_scale no tiene en cuenta el tamaño de escala del plano igual a cero, lo que genera un error en el kernel debido a la división por cero. Se soluciona estableciendo el tamaño de escala exterior como cero cuando el tamaño de dst es cero, de forma similar a lo que hace drm_calc_scale(). Este problema comenzó con la introducción del modo de superposición del cursor que utiliza esta función para evaluar los cambios del modo del cursor a través de dm_crtc_get_cursor_mode() antes de verificar el estado del plano. [Dec17 17:14] Ups: error de división: 0000 [#1] PREEMPT SMP NOPTI [ +0.000018] CPU: 5 PID: 1660 Comm: surface-DP-1 No contaminado 6.10.0+ #231 [ +0.000007] Nombre del hardware: Valve Jupiter/Jupiter, BIOS F7A0131 30/01/2024 [ +0.000004] RIP: 0010:dm_get_plane_scale+0x3f/0x60 [amdgpu] [ +0.000553] Código: 44 0f b7 41 3a 44 0f b7 49 3e 83 e0 0f 48 0f a3 c2 73 21 69 41 28 e8 03 00 00 31 d2 41 f7 f1 31 d2 89 06 69 41 2c e8 03 00 00 <41> f7 f0 89 07 e9 d7 d8 7e e9 44 89 c8 45 89 c1 41 89 c0 eb d4 66 [ +0.000005] RSP: 0018:ffffa8df0de6b8a0 EFLAGS: 00010246 [ +0.000006] RAX: 00000000000003e8 RBX: ffff9ac65c1f6e00 RCX: ffff9ac65d055500 [ +0,000003] RDX: 0000000000000000 RSI: ffffa8df0de6b8b0 RDI: ffffa8df0de6b8b4 [ +0.000004] RBP: ffff9ac64e7a5800 R08: 000000000000000 R09: 0000000000000a00 [ +0.000003] R10: 0000000000000ff R11: 0000000000000054 R12: ffff9ac6d0700010 [ +0.000003] R13: ffff9ac65d054f00 R14: ffff9ac65d055500 R15: ffff9ac64e7a60a0 [ +0.000004] FS: 00007f869ea00640(0000) GS:ffff9ac970080000(0000) knlGS:0000000000000000 [ +0.000004] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ +0.000003] CR2: 000055ca701becd0 CR3: 000000010e7f2000 CR4: 0000000000350ef0 [ +0.000004] Rastreo de llamadas: [ +0.000007] [ +0.000006] ? __die_body.cold+0x19/0x27 [ +0.000009] ? die+0x2e/0x50 [ +0.000007] ? do_trap+0xca/0x110 [ +0.000007] ? do_error_trap+0x6a/0x90 [ +0.000006] ? dm_get_plane_scale+0x3f/0x60 [amdgpu] [ +0.000504] ? exc_divide_error+0x38/0x50 [ +0.000005] ? dm_get_plane_scale+0x3f/0x60 [amdgpu] [ +0.000488] ? [+0.000050] ¿ __pfx_drm_mode_atomic_ioctl+0x10/0x10 [drm] [ +0.000047] drm_ioctl_kernel+0xb3/0x100 [drm] [ +0.000062] drm_ioctl+0x27a/0x4f0 [drm] [ +0.000049] ? __pfx_drm_mode_atomic_ioctl+0x10/0x10 [drm] [ +0.000055] amdgpu_drm_ioctl+0x4e/0x90 [amdgpu] [ +0.000360] __x64_sys_ioctl+0x97/0xd0 [ +0.000010] do_syscall_64+0x82/0x190 [ +0.000008] ? __pfx_drm_mode_createblob_ioctl+0x10/0x10 [drm] [ +0.000044] ? srso_return_thunk+0x5/0x5f [ +0.000006] ? drm_ioctl_kernel+0xb3/0x100 [drm] [ +0.000040] ? srso_return_thunk+0x5/0x5f [ +0.000005] ? __check_object_size+0x50/0x220 [ +0.000007] ? srso_return_thunk+0x5/0x5f [ +0.000005] ? srso_return_thunk+0x5/0x5f [ +0.000005] ? drm_ioctl+0x2a4/0x4f0 [drm] [ +0.000039] ? __pfx_drm_mode_createblob_ioctl+0x10/0x10 [drm] [ +0.000043] ? srso_return_thunk+0x5/0x5f [ +0.000005] ? srso_return_thunk+0x5/0x5f [ +0.000005] ? __pm_runtime_suspend+0x69/0xc0 [ +0.000006] ? srso_return_thunk+0x5/0x5f [ +0.000005] ? amdgpu_drm_ioctl+0x71/0x90 [amdgpu] [ +0.000366] ? srso_return_thunk+0x5/0x5f [ +0.000006] ? syscall_salir_al_modo_usuario+0x77/0x210 [ +0.000007] ? srso_return_thunk+0x5/0x5f [ +0.000005] ? do_syscall_64+0x8e/0x190 [ +0.000006] ? srso_return_thunk+0x5/0x5f [ +0.000006] ? do_syscall_64+0x8e/0x190 [ +0.000006] ? srso_return_thunk+0x5/0x5f [ +0.000007] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ +0.000008] RIP: 0033:0x55bb7cd962bc [ +0.000007] Código: 4c 89 6c 24 18 4c 89 64 24 20 4c 89 74 24 28 0f 57 c0 0f 11 44 24 30 89 c7 48 8d 54 24 08 b8 10 00 00 00 be bc 64 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdkfd: wq_release envía una señal a dma_fence solo cuando está disponible kfd_process_wq_release() envía una señal de desalojo a dma_fence_signal(), que se activa si dma_fence es NULL. kfd_process->ef se inicializa mediante kfd_process_device_init_vm() a través de ioctl. Esto significa que el desalojo es NULL para un nuevo kfd_process creado, y cerrar un kfd_process justo después de abrirlo activará la advertencia. Esta confirmación envía una señal condicional al desalojo en kfd_process_wq_release() solo cuando está disponible. [ 503.660882] ADVERTENCIA: CPU: 0 PID: 9 en drivers/dma-buf/dma-fence.c:467 dma_fence_signal+0x74/0xa0 [ 503.782940] Cola de trabajo: kfd_process_wq kfd_process_wq_release [amdgpu] [ 503.789640] RIP: 0010:dma_fence_signal+0x74/0xa0 [ 503.877620] Seguimiento de llamadas: [ 503.880066] [ 503.882168] ? __warn+0xcd/0x260 [ 503.885407] ? dma_fence_signal+0x74/0xa0 [ 503.889416] ? report_bug+0x288/0x2d0 [ 503.893089] ? handle_bug+0x53/0xa0 [ 503.896587] ? exc_invalid_op+0x14/0x50 [ 503.900424] ? asm_exc_invalid_op+0x16/0x20 [ 503.904616] ? __kthread_parkme+0x82/0x140 [503.935631] ? __pfx_worker_thread+0x10/0x10 [ 503.939904] kthread+0x2a8/0x380 [ 503.943132] ? __pfx_kthread+0x10/0x10 [ 503.954210] ret_from_fork_asm+0x1a/0x30 [ 503.958142] [ 503.960328] ---[ fin del seguimiento 000000000000000 ]--- (seleccionado de el commit 2774ef7625adb5fb9e9265c26a59dca7b8fd171e)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu: Agregar un bloqueo al acceder a la función de recorte del compañero Al ejecutar videos de YouTube y juegos de Steam simultáneamente, el evaluador encontró un problema de condición de ejecución/bloqueo del sistema con la configuración de múltiples pantallas. Agregar un bloqueo a la función de recorte del asignador de compañeros sería la solución. [ 7197.250436] error de protección general, probablemente para la dirección no canónica 0xdead000000000108 [ 7197.250447] RIP: 0010:__alloc_range+0x8b/0x340 [amddrm_buddy] [ 7197.250470] Seguimiento de llamadas: [ 7197.250472] [ 7197.250475] ? asm_exc_general_protection+0x27/0x30 [7197.250498] ? __alloc_range+0x8b/0x340 [amddrm_buddy] [7197.250501] ? __alloc_range+0x109/0x340 [amddrm_buddy] [ 7197.250506] amddrm_buddy_block_trim+0x1b5/0x260 [amddrm_buddy] [ 7197.250511] amdgpu_vram_mgr_new+0x4f5/0x590 [amdgpu] [ 7197.250682] amdttm_resource_alloc+0x46/0xb0 [amdttm] [ 7197.250689] ttm_bo_alloc_resource+0xe4/0x370 [amdttm] [ 7197.250696] amdttm_bo_validate+0x9d/0x180 [amdttm] [ [7197.250701] amdgpu_bo_pin+0x15a/0x2f0 [amdgpu] [ 7197.250831] amdgpu_dm_plane_helper_prepare_fb+0xb2/0x360 [amdgpu] [ 7197.251025] ? drm_atomic_helper_prepare_planes.part.0+0x2f/0x1e0 [ 7197.251035] drm_atomic_helper_prepare_planes+0x5d/0x70 [ 7197.251037] drm_atomic_helper_commit+0x84/0x160 [ 7197.251040] drm_atomic_nonblocking_commit+0x59/0x70 [ 7197.251043] drm_mode_atomic_ioctl+0x720/0x850 [ 7197.251047] ? __pfx_drm_mode_atomic_ioctl+0x10/0x10 [ 7197.251049] drm_ioctl_kernel+0xb9/0x120 [ 7197.251053] ? srso_alias_return_thunk+0x5/0xfbef5 [ 7197.251056] drm_ioctl+0x2d4/0x550 [ 7197.251058] ? __pfx_drm_mode_atomic_ioctl+0x10/0x10 [ 7197.251063] amdgpu_drm_ioctl+0x4e/0x90 [ amdgpu] [ 7197.251186] __x64_sys_ioctl+0xa0/0xf0 [ 7197.251190] x64_sys_call+0x143b/0x25c0 [ 7197.251193] do_syscall_64+0x7f/0x180 [ 7197.251197] ? srso_alias_return_thunk+0x5/0xfbef5 [ 7197.251199] ? amdgpu_display_user_framebuffer_create+0x215/0x320 [amdgpu] [ 7197.251329] ? drm_internal_framebuffer_create+0xb7/0x1a0 [ 7197.251332] ? srso_alias_return_thunk+0x5/0xfbef5 (seleccionado de el commit 3318ba94e56b9183d0304577c74b33b6b01ce516)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: zlib: arregla los bytes avail_in para la ruta de compresión de hardware zlib s390 Dado que la longitud de los datos de entrada que se pasan a zlib_compress_folios() puede ser arbitraria, configurar siempre strm.avail_in como un múltiplo de PAGE_SIZE puede provocar que los bytes de lectura superen el rango de entrada. Actualmente, esto activa una afirmación en btrfs_compress_folios() en el kernel de depuración (ver a continuación). Arregla el cálculo de strm.avail_in para la ruta de aceleración de hardware S390. La afirmación falló: *total_in <= orig_len, en fs/btrfs/compression.c:1041 ------------[ corte aquí ]------------ ¡ERROR del kernel en fs/btrfs/compression.c:1041! Evento de monitor: 0040 ilc:2 [#1] PREEMPT SMP CPU: 16 UID: 0 PID: 325 Comm: kworker/u273:3 No contaminado 6.13.0-20241204.rc1.git6.fae3b21430ca.300.fc41.s390x+debug #1 Nombre de hardware: IBM 3931 A01 703 (z/VM 7.4.0) Cola de trabajo: btrfs-delalloc btrfs_work_helper Krnl PSW: 0704d00180000000 0000021761df6538 (btrfs_compress_folios+0x198/0x1a0) R:0 T:1 IO:1 EX:1 Clave:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 RI:0 EA:3 Krnl GPRS: 0000000080000000 0000000000000001 0000000000000047 0000000000000000 000000000000006 ffffff01757bb000 000001976232fcc0 000000000000130c 000001976232fcd0 000001976232fcc8 00000118ff4a0e30 0000000000000001 00000111821ab400 0000011100000000 0000021761df6534 000001976232fb58 Código Krnl: 0000021761df6528: c020006f5ef4 larl %r2,0000021762be2310 0000021761df652e: c0e5ffbd09d5 brasl %r14,00000217615978d8 #0000021761df6534: af000000 mc 0,0 >0000021761df6538: 0707 bcr 0,%r7 0000021761df653a: 0707 bcr 0,%r7 0000021761df653c: 0707 bcr 0,%r7 0000021761df653e: 0707 bcr 0,%r7 0000021761df6540: c004004bb7ec brcl 0,000002176276d518 Seguimiento de llamadas: [<0000021761df6538>] btrfs_compress_folios+0x198/0x1a0 ([<0000021761df6534>] btrfs_compress_folios+0x194/0x1a0) [<0000021761d97788>] rango_archivo_comprimir+0x3b8/0x6d0 [<0000021761dcee7c>] ayuda_trabajo_btrfs+0x10c/0x160 [<0000021761645760>] trabajo_proceso_uno+0x2b0/0x5d0 [<000002176164637e>] subproceso_trabajador+0x20e/0x3e0 [<000002176165221a>] subproceso_k+0x15a/0x170 [<00000217615b859c>] __ret_de_bifurcación+0x3c/0x60 [<00000217626e72d2>] ret_de_bifurcación+0xa/0x38 INFORMACIÓN: bloqueo_dep es Desactivado. Dirección del último evento de ruptura: [<0000021761597924>] _printk+0x4c/0x58 Pánico del kernel: no se sincroniza: Excepción fatal: panic_on_oops

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/mediatek: Establecer private->all_drm_private[i]->drm en NULL si mtk_drm_bind devuelve err El puntero debe establecerse en NULL, de lo contrario KASAN se queja de use-after-free. Porque en mtk_drm_bind, todos los drm de private se establecen de la siguiente manera. private->all_drm_private[i]->drm = drm; Y drm será liberado por drm_dev_put en caso de que mtk_drm_kms_init devuelva un error. Sin embargo, la ruta de apagado aún accede a la memoria asignada previamente en drm_atomic_helper_shutdown. [ 84.874820] watchdog: watchdog0: ¡watchdog no se detuvo! [ 86.512054] ======================================================================= [ 86.513162] ERROR: KASAN: use-after-free en drm_atomic_helper_shutdown+0x33c/0x378 [ 86.514258] Lectura de tamaño 8 en la dirección ffff0000d46fc068 por la tarea shutdown/1 [ 86.515213] [ 86.515455] CPU: 1 UID: 0 PID: 1 Comm: shutdown No contaminado 6.13.0-rc1-mtk+gfa1a78e5d24b-dirty #55 [ 86.516752] Nombre del hardware: Producto desconocido/Producto desconocido, BIOS 2022.10 10/01/2022 [ 86.517960] Rastreo de llamadas: [ 86.518333] show_stack+0x20/0x38 (C) [ 86.518891] dump_stack_lvl+0x90/0xd0 [ 86.519443] print_report+0xf8/0x5b0 [ 86.519985] kasan_report+0xb4/0x100 [ 86.520526] __asan_report_load8_noabort+0x20/0x30 [ 86.521240] drm_atomic_helper_shutdown+0x33c/0x378 [ 86.521966] apagado_drm_mtk+0x54/0x80 [ 86.522546] apagado_plataforma+0x64/0x90 [ 86.523137] apagado_dispositivo+0x260/0x5b8 [ 86.523728] reinicio_núcleo+0x78/0xf0 [ 86.524282] __do_sys_reboot+0x258/0x2f0 [ 86.524871] __arm64_sys_reboot+0x90/0xd8 [ 86.525473] invocar_syscall+0x74/0x268 [ 86.526041] el0_svc_common.constprop.0+0xb0/0x240 [ 86.526751] do_el0_svc+0x4c/0x70 [ 86.527251] el0_svc+0x4c/0xc0 [ 86.527719] el0t_64_sync_handler+0x144/0x168 [ 86.528367] el0t_64_sync+0x198/0x1a0 [ 86.528920] [ 86.529157] La dirección con errores pertenece a la página física: [ 86.529972] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff0000d46fd4d0 pfn:0x1146fc [86.531319] indicadores: 0xbfffc0000000000(node=0|zone=2|lastcpupid=0xffff) [86.532267] sin procesar: 0bfffc0000000000 0000000000000000 dead000000000122 0000000000000000 [86.533390] sin procesar: ffff0000d46fd4d0 000000000000000 00000000ffffffff 0000000000000000 [86.534511] página volcada porque: kasan: se detectó un acceso incorrecto [ 86.535323] [ 86.535559] Estado de la memoria alrededor de la dirección con errores: [ 86.536265] ffff0000d46fbf00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 86.537314] ffff0000d46fbf80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 86.538363] >ffff0000d46fc000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 86.544733] ^ [ 86.551057] ffff0000d46fc080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 86.557510] ffff0000d46fc100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 86.563928] ===================================================================== [ 86.571093] Deshabilitando la depuración de bloqueo debido a una corrupción del kernel [ 86.577642] No se puede gestionar la solicitud de paginación del kernel en la dirección virtual e0e9c0920000000b [ 86.581834] KASAN: tal vez acceso a memoria salvaje en el rango [0x0752049000000058-0x075204900000005f] ...

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfs: Arreglar oops en nfs_netfs_init_request() al copiar a caché Cuando netfslib quiere copiar algunos datos que acaban de leerse en nombre de nfs, crea una nueva solicitud de escritura y llama a nfs_netfs_init_request() para inicializarla, pero con un puntero de archivo NULL. Esto hace que nfs_file_open_context() dé un error; sin embargo, en realidad no necesitamos el contexto nfs ya que solo vamos a escribir en la caché. Arregla esto simplemente devolviendo si no se nos da un puntero de archivo y emitiendo una advertencia si la solicitud fue para algo distinto a copiar a caché. Además, arregla nfs_netfs_free_request() para que no intente liberar el contexto si el puntero es NULL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfs: Arreglar la gestión de enomem en lecturas en búfer Si netfs_read_to_pagecache() obtiene un error de ->prepare_read() o de netfs_prepare_read_iterator(), necesita decrementar ->nr_outstanding, cancelar la subsolicitud y salir del bucle de emisión. Actualmente, solo hace esto para dos de los casos, pero hay dos más que no se gestionan. Arregle esto moviendo la gestión a un lugar común y saltando a él desde los cuatro lugares. Esto es preferible a insertar un contenedor alrededor de netfs_prepare_read_iterator() como lo propuso Dmitry Antipov[1].

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs: relajar las aserciones en caso de fallo en la codificación de identificadores de archivos La codificación de identificadores de archivos normalmente se realiza mediante un método >encode_fh() del sistema de archivos que puede fallar por varias razones. Los usuarios heredados de exportfs_encode_fh(), es decir, nfsd y la llamada al sistema name_to_handle_at(2) están preparados para hacer frente a la posibilidad de un fallo en la codificación de un identificador de archivo. Hay algunos otros usuarios de exportfs_encode_{fh,fid}() que actualmente tienen una aserción WARN_ON() cuando ->encode_fh() falla. Relajen esas aserciones porque son incorrectas. El segundo informe de error vinculado indica el commit 16aac5ad1fa9 ("ovl: compatibilidad con la codificación de identificadores de archivos no decodificables") en v6.6 como el commit regresiva, pero esto no es exacto. El commit mencionado anteriormente solo aumenta las posibilidades de la aserción y permite activar la aserción con el reproductor usando overlayfs, inotify y drop_caches. Activar esta aserción siempre fue posible con otros sistemas de archivos y otras razones de fallas de ->encode_fh() y, más particularmente, también fue posible con el mismo reproductor exacto usando overlayfs que está montado con las opciones index=on,nfs_export=on también en kernels < v6.6. Por lo tanto, no estoy listando el commit mencionado anteriormente como un commit de correcciones. Sugerencia de retroportación: este parche tendrá un conflicto trivial que se aplica a v6.6.y, y otros conflictos triviales que se aplican a kernels estables < v6.6.