Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/perf: Se corrige el conteo de referencias en la PMU 'vpa_pmu'. El commit 176cda0619b6 ("powerpc/perf: Añadir interfaz perf para exponer contadores vpa") introdujo 'vpa_pmu' para exponer los contadores de latencia de cambio de contexto L1<->L2 proporcionados por la APIv2 anidada de Book3s-HV al espacio de usuario L1 mediante eventos perf. Sin embargo, la nueva PMU, denominada 'vpa_pmu', no asigna la propiedad de la PMU al módulo 'vpa_pmu'. En consecuencia, el módulo 'vpa_pmu' se puede descargar mientras uno de los eventos de rendimiento aún está activo, lo que puede provocar errores y pánico en el kernel del formato siguiente en un Pseries-LPAR: ERROR: Desreferencia de puntero NULL del kernel en lectura en 0x00000058 NIP [c000000000506cb8] event_sched_out+0x40/0x258 LR [c00000000050e8a4] __perf_remove_from_context+0x7c/0x2b0 Rastreo de llamadas: [c00000025fc3fc30] [c00000025f8457a8] 0xc00000025f8457a8 (no confiable) [c00000025fc3fc80] [ffffffffffffffee0] 0xffffffffffffffee0 [c00000025fc3fcd0] [c000000000501e70] event_function+0xa8/0x120 Pánico del kernel: no se sincroniza: ¡Ay, se está eliminando el controlador de interrupciones! Para solucionarlo, agregue la propiedad del módulo a 'vpa_pmu' para que se contabilice y se evite su descarga al inicializar eventos de rendimiento.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PCI: Se corrige la desreferencia de NULL en la ruta de error de creación de VF de SR-IOV. Se limpia cuando falla la configuración de virtfn para evitar la desreferencia de punteros NULL durante la eliminación del dispositivo. El error del kernel que se muestra a continuación se produjo debido a un flujo de gestión de errores incorrecto cuando falla pci_setup_device(). Se ha añadido pci_iov_scan_device(), que gestiona la asignación y configuración de virtfn y realiza la limpieza si falla pci_setup_device(), de modo que pci_iov_add_virtfn() no necesite llamar a pci_stop_and_remove_bus_device(). Esto impide el acceso a dispositivos virtfn parcialmente inicializados durante la eliminación. ERROR: desreferencia de puntero NULL del kernel, dirección: 00000000000000d0 RIP: 0010:device_del+0x3d/0x3d0 Rastreo de llamadas: pci_remove_bus_device+0x7c/0x100 pci_iov_add_virtfn+0xfa/0x200 sriov_enable+0x208/0x420 mlx5_core_sriov_configure+0x6a/0x160 [mlx5_core] sriov_numvfs_store+0xae/0x1a0 [bhelgaas: registro de confirmaciones, devuelve ERR_PTR(-ENOMEM) directamente]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/mlx5: Corrección del desbordamiento de la variable page_size. Se modifican todas las variables que almacenan el resultado de mlx5_umem_mkc_find_best_pgsz() a unsigned long para admitir valores superiores a 31 y evitar el desbordamiento. Por ejemplo: si intentamos registrar 4 GB de memoria contiguos a la memoria física, el controlador optimizará page_size e intentará usar una clave mkey con un tamaño de entidad de 4 GB. La variable page_size (unsigned int) se desbordará a 0 y se activará la función WARN_ON() en alloc_cacheable_mr(). ADVERTENCIA: CPU: 2 PID: 1203 at drivers/infiniband/hw/mlx5/mr.c:1124 alloc_cacheable_mr+0x22/0x580 [mlx5_ib] Modules linked in: mlx5_ib mlx5_core bonding ip6_gre ip6_tunnel tunnel6 ip_gre gre rdma_rxe rdma_ucm ib_uverbs ib_ipoib ib_umad rpcrdma ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm fuse ib_core [last unloaded: mlx5_core] CPU: 2 UID: 70878 PID: 1203 Comm: rdma_resource_l Tainted: G W 6.14.0-rc4-dirty #43 Tainted: [W]=WARN Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:alloc_cacheable_mr+0x22/0x580 [mlx5_ib] Code: 90 90 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 41 54 41 52 53 48 83 ec 30 f6 46 28 04 4c 8b 77 08 75 21 <0f> 0b 49 c7 c2 ea ff ff ff 48 8d 65 d0 4c 89 d0 5b 41 5a 41 5c 41 RSP: 0018:ffffc900006ffac8 EFLAGS: 00010246 RAX: 0000000004c0d0d0 RBX: ffff888217a22000 RCX: 0000000000100001 RDX: 00007fb7ac480000 RSI: ffff8882037b1240 RDI: ffff8882046f0600 RBP: ffffc900006ffb28 R08: 0000000000000001 R09: 0000000000000000 R10: 00000000000007e0 R11: ffffea0008011d40 R12: ffff8882037b1240 R13: ffff8882046f0600 R14: ffff888217a22000 R15: ffffc900006ffe00 FS: 00007fb7ed013340(0000) GS:ffff88885fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fb7ed1d8000 CR3: 00000001fd8f6006 CR4: 0000000000772eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? __warn+0x81/0x130 ? alloc_cacheable_mr+0x22/0x580 [mlx5_ib] ? report_bug+0xfc/0x1e0 ? handle_bug+0x55/0x90 ? exc_invalid_op+0x17/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? alloc_cacheable_mr+0x22/0x580 [mlx5_ib] create_real_mr+0x54/0x150 [mlx5_ib] ib_uverbs_reg_mr+0x17f/0x2a0 [ib_uverbs] ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0xca/0x140 [ib_uverbs] ib_uverbs_run_method+0x6d0/0x780 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ib_uverbs_cmd_verbs+0x19b/0x360 [ib_uverbs] ? walk_system_ram_range+0x79/0xd0 ? ___pte_offset_map+0x1b/0x110 ? __pte_offset_map_lock+0x80/0x100 ib_uverbs_ioctl+0xac/0x110 [ib_uverbs] __x64_sys_ioctl+0x94/0xb0 do_syscall_64+0x50/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fb7ecf0737b Code: ff ff ff 85 c0 79 9b 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 7d 2a 0f 00 f7 d8 64 89 01 48 RSP: 002b:00007ffdbe03ecc8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007ffdbe03edb8 RCX: 00007fb7ecf0737b RDX: 00007ffdbe03eda0 RSI: 00000000c0181b01 RDI: 0000000000000003 RBP: 00007ffdbe03ed80 R08: 00007fb7ecc84010 R09: 00007ffdbe03eed4 R10: 0000000000000009 R11: 0000000000000246 R12: 00007ffdbe03eed4 R13: 000000000000000c R14: 000000000000000c R15: 00007fb7ecc84150

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/erdma: Impide el use-after-free en erdma_accept_newconn(). Tras llamar a erdma_cep_put(new_cep), new_cep se libera y la desreferencia posterior causa un problema de UAF. Solucione este problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/core: No exponga hw_counters fuera del espacio de nombres init net. el commit 467f432a521a ("RDMA/core: Dividir los atributos sysfs del contador de puerto y dispositivo") casi expuso accidentalmente los contadores hw a espacios de nombres que no son init net. No los expuso completamente, ya que un intento de leer cualquiera de esos contadores conduce a un fallo como este: [42021.807566] ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000028 [42021.814463] #PF: acceso de lectura del supervisor en modo kernel [42021.819549] #PF: error_code(0x0000) - página no presente [42021.824636] PGD 0 P4D 0 [42021.827145] Oops: 0000 [#1] SMP PTI [42021.830598] CPU: 82 PID: 2843922 Comm: switchto-defaul Kdump: cargado Tainted: GSWI XXX [42021.841697] Nombre del hardware: XXX [42021.849619] RIP: 0010:hw_stat_device_show+0x1e/0x40 [ib_core] [42021.855362] Código: 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 49 89 d0 4c 8b 5e 20 48 8b 8f b8 04 00 00 48 81 c7 f0 fa ff ff <48> 8b 41 28 48 29 ce 48 83 c6 d0 48 c1 ee 04 69 d6 ab aa aa aa 48 [42021.873931] RSP: 0018:ffff97fe90f03da0 EFLAGS: 00010287 [42021.879108] RAX: ffff9406988a8c60 RBX: ffff940e1072d438 RCX: 000000000000000 [42021.886169] RDX: ffff94085f1aa000 RSI: ffff93c6cbbdbcb0 RDI: ffff940c7517aef0 [42021.893230] RBP: ffff97fe90f03e70 R08: ffff94085f1aa000 R09: 0000000000000000 [42021.900294] R10: ffff94085f1aa000 R11: ffffffffc0775680 R12: ffffffff87ca2530 [42021.907355] R13: ffff940651602840 R14: ffff93c6cbbdbcb0 R15: ffff94085f1aa000 [42021.914418] FS: 00007fda1a3b9700(0000) GS:ffff94453fb80000(0000) knlGS:0000000000000000 [42021.922423] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [42021.928130] CR2: 0000000000000028 CR3: 00000042dcfb8003 CR4: 000000000003726f0 [42021.935194] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [42021.942257] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [42021.949324] Rastreo de llamadas: [42021.951756] [42021.953842] [] ? show_regs+0x64/0x70 [42021.959030] [] ? __die+0x78/0xc0 [42021.963874] [] ? page_fault_oops+0x2b5/0x3b0 [42021.969749] [] ? asm_exc_page_fault+0x26/0x30 [42021.981517] [] ? __pfx_show_hw_stats+0x10/0x10 [ib_core] [42021.988482] [] ? hw_stat_device_show+0x1e/0x40 [ib_core] [42021.995438] [] dev_attr_show+0x1e/0x50 [42022.000803] [] sysfs_kf_seq_show+0x81/0xe0 [42022.006508] [] seq_read_iter+0xf4/0x410 [42022.011954] [] vfs_read+0x16e/0x2f0 [42022.017058] [] ksys_read+0x6e/0xe0 [42022.022073] [] do_syscall_64+0x6a/0xa0 [42022.027441] [] entry_SYSCALL_64_after_hwframe+0x78/0xe2 El problema se puede reproducir siguiendo estos pasos: ip netns add foo ip netns exec foo bash cat /sys/class/infiniband/mlx4_0/hw_counters/* El pánico se produce porque la conversión del puntero del dispositivo en un puntero ib_device al usar container_of() en hw_stat_device_show() es incorrecta y provoca una corrupción de memoria. Sin embargo, el verdadero problema radica en que los contadores hw nunca deberían exponerse fuera del espacio de nombres de red no init. Para solucionarlo, guarde el índice del grupo de atributos correspondiente (podría ser 1 o 2, dependiendo de la presencia de atributos específicos del controlador) y ponga a cero el puntero al grupo hw_counters para dispositivos compatibles durante la inicialización. Con esta corrección, los contadores hw_counters no están disponibles en un espacio de nombres de red no init: find /sys/class/infiniband/mlx4_0/ -name hw_counters /sys/class/infiniband/mlx4_0/ports/1/hw_counters /sys/class/infiniband/mlx4_0/ports/2/hw_counters /sys/class/infiniband/mlx4_0/hw_counters ip netns add foo ip netns exec foo bash find /sys/class/infiniband/mlx4_0/ -name hw_counters

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: evitar NPD cuando el ASIC no es compatible con DMUB. ctx->dmub_srv devuelve NULL si el ASIC no es compatible con DMUB, lo cual se prueba en dm_dmub_sw_init. Sin embargo, se desreferenciará en dmub_hw_lock_mgr_cmd si should_use_dmub_lock devuelve verdadero. Esto ha sido así desde que se añadió la compatibilidad con dmub para PSR1. Para solucionarlo, verifique dmub_srv en should_use_dmub_lock. [ 37.440832] ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000058 [ 37.447808] #PF: acceso de lectura del supervisor en modo kernel [ 37.452959] #PF: error_code(0x0000) - página no presente [ 37.458112] PGD 0 P4D 0 [ 37.460662] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI [ 37.465553] CPU: 2 UID: 1000 PID: 1745 Comm: DrmThread No contaminado 6.14.0-rc1-00003-gd62e938120f0 #23 99720e1cb1e0fc4773b8513150932a07de3c6e88 [ 37.478324] Nombre del hardware: Google Morphius/Morphius, BIOS Google_Morphius.13434.858.0 26/10/2023 [ 37.487103] RIP: 0010:dmub_hw_lock_mgr_cmd+0x77/0xb0 [ 37.492074] Código: 44 24 0e 00 00 00 00 48 c7 04 24 45 00 00 0c 40 88 74 24 0d 0f b6 02 88 44 24 0c 8b 01 89 44 24 08 85 f6 75 05 c6 44 24 0e 01 <48> 8b 7f 58 48 89 e6 ba 01 00 00 00 e8 08 3c 2a 00 65 48 8b 04 5 [ 37.510822] RSP: 0018:ffff969442853300 EFLAGS: 00010202 [ 37.516052] RAX: 000000000000000 RBX: ffff92db03000000 RCX: ffff969442853358 [ 37.523185] RDX: ffff969442853368 RSI: 00000000000000001 RDI: 0000000000000000 [ 37.530322] RBP: 0000000000000001 R08: 00000000000004a7 R09: 00000000000004a5 [ 37.537453] R10: 0000000000000476 R11: 0000000000000062 R12: ffff92db0ade8000 [ 37.544589] R13: ffff92da01180ae0 R14: ffff92da011802a8 R15: ffff92db03000000 [ 37.551725] FS: 0000784a9cdfc6c0(0000) GS:ffff92db2af00000(0000) knlGS:0000000000000000 [ 37.559814] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 37.565562] CR2: 000000000000058 CR3: 0000000112b1c000 CR4: 00000000003506f0 [ 37.572697] Rastreo de llamadas: [ 37.575152] [ 37.577258] ¿__die_body+0x66/0xb0 [ 37.580756] ? page_fault_oops+0x3e7/0x4a0 [ 37.584861] ? exc_page_fault+0x3e/0xe0 [ 37.588706] ? exc_page_fault+0x5c/0xe0 [ 37.592550] ? asm_exc_page_fault+0x22/0x30 [ 37.596742] ? dmub_hw_lock_mgr_cmd+0x77/0xb0 [ 37.601107] dcn10_cursor_lock+0x1e1/0x240 [ 37.605211] program_cursor_attributes+0x81/0x190 [ 37.609923] commit_planes_for_stream+0x998/0x1ef0 [ 37.614722] update_planes_and_stream_v2+0x41e/0x5c0 [ 37.619703] dc_update_planes_and_stream+0x78/0x140 [ 37.624588] amdgpu_dm_atomic_commit_tail+0x4362/0x49f0 [ 37.629832] ? srso_return_thunk+0x5/0x5f [ 37.633847] ? mark_held_locks+0x6d/0xd0 [ 37.637774] ? _raw_spin_unlock_irq+0x24/0x50 [ 37.642135] ? srso_return_thunk+0x5/0x5f [ 37.646148] ? lockdep_hardirqs_on+0x95/0x150 [ 37.650510] ? srso_return_thunk+0x5/0x5f [ 37.654522] ? _raw_spin_unlock_irq+0x2f/0x50 [ 37.658883] ? srso_return_thunk+0x5/0x5f [ 37.662897] ? esperar_a_común+0x186/0x1c0 [ 37.666998] ? srso_return_thunk+0x5/0x5f [ 37.671009] ? drm_crtc_next_vblank_start+0xc3/0x170 [ 37.675983] confirmación_cola+0xf5/0x1c0 [ 37.679478] drm_atomic_helper_commit+0x2a2/0x2b0 [ 37.684186] drm_atomic_commit+0xd6/0x100 [ 37.688199] ? __cfi___drm_printfn_info+0x10/0x10 [ 37.692911] drm_atomic_helper_update_plane+0xe5/0x130 [ 37.698054] drm_mode_cursor_common+0x501/0x670 [ 37.702600] ? __cfi_drm_mode_cursor_ioctl+0x10/0x10 [ 37.707572] drm_mode_cursor_ioctl+0x48/0x70 [ 37.711851] drm_ioctl_kernel+0xf2/0x150 [ 37.715781] drm_ioctl+0x363/0x590 [ 37.719189] ? __cfi_drm_mode_cursor_ioctl+0x10/0x10 [ 37.724165] amdgpu_drm_ioctl+0x41/0x80 [ 37.728013] __se_sys_ioctl+0x7f/0xd0 [ 37.731685] do_syscall_64+0x87/0x100 [ 37.735355] ? vma_end_read+0x12/0xe0 [ 37.739024] ? srso_return_thunk+0x5/0x5f [ 37.743041] ? find_held_lock+0x47/0xf0 [ 37.746884] ? vma_end_read+0x12/0xe0 [37.750552] ? srso_return_thunk+0x5/0 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PCI: brcmstb: Corrección de la ruta de error tras una llamada a regulator_bulk_get(). Si regulator_bulk_get() devuelve un error y no se crean reguladores, debemos establecer su número en cero. Si no lo hacemos y falla la conexión PCIe, una llamada a regulator_bulk_free() provocará un pánico del kernel. Mientras tanto, imprima el valor del error, ya que no podemos devolver un error hacia arriba, ya que el kernel emitirá una advertencia WARN() en caso de un error de add_bus(). [kwilczynski: registro de confirmaciones, usar coma en el mensaje para que coincida con el estilo de otros mensajes similares]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/msm/gem: Corrección del código de error msm_parse_deps(). La macro SUBMIT_ERROR() convierte el código de error en negativo. Esta operación adicional "-" lo devuelve a positivo (EINVAL). El código de error se pasa a ERR_PTR() y, dado que los valores positivos no son un IS_ERR(), eventualmente generará un error. Elimine el "-". Patchwork: https://patchwork.freedesktop.org/patch/637625/

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/mm/pat: Se corrige la gestión de VM_PAT cuando fork() falla en copy_page_range(). Si track_pfn_copy() falla, ya se agregó el VMA dst al árbol de maple. Si fork() falla, se limpiará el árbol de maple y se encontrará con el VMA dst para el cual no se realizó ninguna reserva ni se copió ninguna tabla de páginas. En consecuencia, untrack_pfn() detectará VM_PAT e intentará obtener la información de PAT de la tabla de páginas, lo cual falla porque esta no se copió. La solución más sencilla sería simplemente borrar el indicador VM_PAT del VMA dst si track_pfn_copy() falla. Sin embargo, la cuestión de simplemente borrar el indicador VM_PAT también es problemática: si pasamos track_pfn_copy() y realizamos una reserva, pero la copia de las tablas de páginas falla, simplemente borraremos el indicador VM_PAT, sin deshacer la reserva correctamente, lo cual también es incorrecto. Así que vamos a solucionarlo correctamente: configuremos el indicador VM_PAT solo si la reserva se realizó correctamente (dejándolo inicialmente en blanco) y deshagámosla si algo sale mal al copiar las tablas de páginas: borremos el indicador VM_PAT después de deshacer la reserva. Tenga en cuenta que cualquier entrada copiada de la tabla de páginas se eliminará cuando se elimine el VMA posteriormente, después de que copy_page_range() se haya ejecutado correctamente; como VM_PAT no está configurado en ese momento, no intentaremos borrarlo de nuevo y untrack_pfn() funcionará correctamente. Tenga en cuenta que dejar estas tablas de páginas sin una reserva no es un problema, ya que estamos cancelando fork(); este proceso nunca se ejecutará. Un reproductor puede activar esto generalmente en el primer intento: https://gitlab.com/davidhildenbrand/scratchspace/-/raw/main/reproducers/pat_fork.c ADVERTENCIA: CPU: 26 PID: 11650 en arch/x86/mm/pat/memtype.c:983 get_pat_info+0xf6/0x110 Módulos vinculados: ... CPU: 26 UID: 0 PID: 11650 Comm: repro3 No contaminado 6.12.0-rc5+ #92 Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 01/04/2014 RIP: 0010:get_pat_info+0xf6/0x110 ... Seguimiento de llamadas: ... untrack_pfn+0x52/0x110 unmap_single_vma+0xa6/0xe0 unmap_vmas+0x105/0x1f0 exit_mmap+0xf6/0x460 __mmput+0x4b/0x120 copy_process+0x1bf6/0x2aa0 kernel_clone+0xab/0x440 __do_sys_clone+0x66/0x90 do_syscall_64+0x95/0x180 Es probable que este caso no se haya encontrado en: d155df53f310 ("x86/mm/pat: borrar VM_PAT si copy_p4d_range falló") ... y en lugar de deshacer la reserva simplemente borramos el indicador VM_PAT. Mantenga la documentación de estas funciones en include/linux/pgtable.h, un lugar es más que suficiente; deberíamos limpiarlo para las otras funciones como track_pfn_remap/untrack_pfn por separado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: staging: vchiq_arm: Se corrige un posible NPR del subproceso keep-alive. Si vchiq_platform_conn_state_changed() no se llama nunca o falla antes de la eliminación del controlador, ka_thread no será un puntero válido a una task_struct. Por lo tanto, realice las comprobaciones necesarias antes de llamar a kthread_stop para evitar un bloqueo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Corrección del error de los límites de la matriz con may_goto. may_goto utiliza 8 bytes adicionales en la pila, lo que provoca que la matriz interpreters[] salga de los límites al calcular el índice mediante stack_size. 1. Si se reescribe un programa BPF, reevalúe el tamaño de la pila. En casos que no sean JIT, rechace la carga directamente. 2. En casos que no sean JIT, el cálculo de interpreters[idx] puede seguir provocando un acceso a la matriz fuera de los límites y simplemente advertir al respecto. 3. En casos con jit_requested, también se debe advertir la ejecución de bpf_func. Por lo tanto, mueva la definición de la función __bpf_prog_ret0_warn fuera de la definición de la macro CONFIG_BPF_JIT_ALWAYS_ON.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: w1: corrección de la desreferencia de puntero nulo en la sonda. La función w1_uart_probe() llama a w1_uart_serdev_open() (que incluye devm_serdev_device_open()) antes de configurar las operaciones del cliente mediante serdev_device_set_client_ops(). Este orden puede desencadenar una desreferencia de puntero nulo en el controlador receive_buf del controlador serdev, ya que asume que serdev->ops es válido cuando SERPORT_ACTIVE está configurado. Esto es similar al problema corregido en el commit 5e700b384ec1 ("platform/chrome: cros_ec_uart: corregir correctamente la condición de ejecución") donde se llamó a devm_serdev_device_open() antes de inicializar completamente el dispositivo. Corrija la ejecución asegurándose de que las operaciones del cliente estén configuradas antes de habilitar el puerto mediante w1_uart_serdev_open().