Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfsd: cancelar nfsd_shrinker_work usando el modo de sincronización en nfs4_state_shutdown_net. En el caso normal, cuando ejecutamos `echo 0 > /proc/fs/nfsd/threads`, la función `nfs4_state_destroy_net` en `nfs4_state_shutdown_net` liberará todos los recursos relacionados con el `nfs4_client` con hash. Si `nfsd_client_shrinker` se está ejecutando simultáneamente, la función `expire_client` primero deshará el hash de este cliente y luego lo destruirá. Esto puede generar la siguiente advertencia. Además, también pueden ocurrir numerosos errores de use-after-free. nfsd_client_shrinker echo 0 > /proc/fs/nfsd/threads expire_client nfsd_shutdown_net unhash_client ... nfs4_state_shutdown_net /* no esperará a que el reductor salga */ /* cancel_work(&nn->nfsd_shrinker_work) * nfsd_file para esto /* no destruirá el cliente1 sin hash */ * el cliente1 sigue activo nfs4_state_destroy_net */ nfsd_file_cache_shutdown /* advertencia de activación */ kmem_cache_destroy(nfsd_file_slab) kmem_cache_destroy(nfsd_file_mark_slab) /* liberar nfsd_file y marcar */ __destroy_client ============================================================================ ERROR nfsd_file (no contaminado): objetos restantes en nfsd_file en __kmem_cache_shutdown() -------------------------------------------------------------------- CPU: 4 UID: 0 PID: 764 Comm: sh No contaminado 6.12.0-rc3+ #1 dump_stack_lvl+0x53/0x70 slab_err+0xb0/0xf0 __kmem_cache_shutdown+0x15c/0x310 kmem_cache_destroy+0x66/0x160 nfsd_file_cache_shutdown+0xac/0x210 [nfsd] nfsd_destroy_serv+0x251/0x2a0 [nfsd] nfsd_svc+0x125/0x1e0 [nfsd] write_threads+0x16a/0x2a0 [nfsd] nfsctl_transaction_write+0x74/0xa0 [nfsd] vfs_write+0x1a5/0x6d0 ksys_write+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e ========================================================================= ERROR nfsd_file_mark (Corrompido: GBW): Objetos que permanecen en nfsd_file_mark en __kmem_cache_shutdown() -------------------------------------------------------------------- dump_stack_lvl+0x53/0x70 slab_err+0xb0/0xf0 __kmem_cache_shutdown+0x15c/0x310 kmem_cache_destroy+0x66/0x160 nfsd_file_cache_shutdown+0xc8/0x210 [nfsd] Para resolver este problema, cancele `nfsd_shrinker_work` usando el modo sincrónico en nfs4_state_shutdown_net.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: ISO: Se corrigió que UAF en iso_sock_timeout conn->sk pudiera haberse desvinculado/liberado mientras se esperaba a iso_conn_lock, por lo que esto verifica si conn->sk aún es válido verificando si es parte de iso_sk_list.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: SCO: Se corrige que UAF en sco_sock_timeout conn->sk pueda haberse desvinculado/liberado mientras se esperaba sco_conn_lock, por lo que esto verifica si conn->sk aún es válido verificando si es parte de sco_sk_list.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: sched: usar la sección crítica del lado de lectura de RCU en taprio_dump(). Corrija el posible use-after-free en 'taprio_dump()' agregando allí la sección crítica del lado de lectura de RCU. Nunca visto en x86 pero encontrado en un sistema arm64 habilitado para KASAN al investigar https://syzkaller.appspot.com/bug?extid=b65e0af58423fc8a73aa: [T15862] ERROR: KASAN: slab-use-after-free en taprio_dump+0xa0c/0xbb0 [T15862] Lectura de tamaño 4 en la dirección ffff0000d4bb88f8 por la tarea repro/15862 [T15862] [T15862] CPU: 0 UID: 0 PID: 15862 Comm: repro No contaminado 6.11.0-rc1-00293-gdefaf1a2113a-dirty #2 [T15862] Nombre del hardware: QEMU QEMU Virtual Machine, BIOS edk2-20240524-5.fc40 24/05/2024 [T15862] Seguimiento de llamadas: [T15862] dump_backtrace+0x20c/0x220 [T15862] show_stack+0x2c/0x40 [T15862] dump_stack_lvl+0xf8/0x174 [T15862] print_report+0x170/0x4d8 [T15862] kasan_report+0xb8/0x1d4 [T15862] __asan_report_load4_noabort+0x20/0x2c [T15862] taprio_dump+0xa0c/0xbb0 [T15862] El comando tc_fill_qdisc_notify.isra.0_0x330_0x3a0_tc_modify_qdisc_0x7b8_0x1838_rtnetlink_rcv_msg_0x3c8_0xc20_netlink_rcv_skb_0x1f8_0x3d4_rtnetlink_rcv_0x28_0x40_netlink_unicast_0x51c_0x790_netlink_sendmsg_0x79c_0xc20_tc_sendmsg_0x1a ... [T15862] ____sys_sendmsg+0x6c0/0x840 [T15862] ___sys_sendmsg+0x1ac/0x1f0 [T15862] __sys_sendmsg+0x110/0x1d0 [T15862] __arm64_sys_sendmsg+0x74/0xb0 [T15862] invoke_syscall+0x88/0x2e0 [T15862] el0_svc_common.constprop.0+0xe4/0x2a0 [T15862] do_el0_svc+0x44/0x60 [T15862] el0_svc+0x50/0x184 [T15862] el0t_64_sync_handler+0x120/0x12c [T15862] el0t_64_sync+0x190/0x194 [T15862] [T15862] Asignado por la tarea 15857: [T15862] kasan_save_stack+0x3c/0x70 [T15862] kasan_save_track+0x20/0x3c [T15862] kasan_save_alloc_info+0x40/0x60 [T15862] __kasan_kmalloc+0xd4/0xe0 [T15862] __kmalloc_cache_noprof+0x194/0x334 [T15862] taprio_change+0x45c/0x2fe0 [T15862] tc_modify_qdisc+0x6a8/0x1838 [T15862] rtnetlink_rcv_msg+0x3c8/0xc20 [T15862] netlink_rcv_skb+0x1f8/0x3d4 [T15862] rtnetlink_rcv+0x28/0x40 [T15862] netlink_unicast+0x51c/0x790 [T15862] netlink_sendmsg+0x79c/0xc20 [T15862] __sock_sendmsg+0xe0/0x1a0 [T15862] ____sys_sendmsg+0x6c0/0x840 [T15862] ___sys_sendmsg+0x1ac/0x1f0 [T15862] __sys_sendmsg+0x110/0x1d0 [T15862] __arm64_sys_sendmsg+0x74/0xb0 [T15862] invoke_syscall+0x88/0x2e0 [T15862] el0_svc_common.constprop.0+0xe4/0x2a0 [T15862] do_el0_svc+0x44/0x60 [T15862] el0_svc+0x50/0x184 [T15862] el0t_64_sync_handler+0x120/0x12c [T15862] el0t_64_sync+0x190/0x194 [T15862] [T15862] Liberado por la tarea 6192: [T15862] kasan_save_stack+0x3c/0x70 [T15862] kasan_save_track+0x20/0x3c [T15862] kasan_save_free_info+0x4c/0x80 [T15862] poison_slab_object+0x110/0x160 [T15862] __kasan_slab_free+0x3c/0x74 [T15862] kfree+0x134/0x3c0 [T15862] taprio_free_sched_cb+0x18c/0x220 [T15862] rcu_core+0x920/0x1b7c [T15862] rcu_core_si+0x10/0x1c [T15862] handle_softirqs+0x2e8/0xd64 [T15862] __do_softirq+0x14/0x20

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: sched: arreglado use-after-free en taprio_change(). En 'taprio_change()', el puntero 'admin' puede quedar colgando debido al cambio/eliminación de sched causado por 'advance_sched()', y la sección crítica protegida por 'q->current_entry_lock' es demasiado pequeña para evitar tal escenario (que causa el use-after-free detectado por KASAN). Solucione esto al preferir 'rcu_replace_pointer()' sobre 'rcu_assign_pointer()' para actualizar 'admin' inmediatamente antes de un intento de liberación de programación.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: wwan: fix global oob in wwan_rtnl_policy. La variable wwan_rtnl_link_ops asigna un maxtype *mayor* que lleva a una lectura global fuera de los límites al analizar los atributos netlink. Exactamente la misma causa del error que el oob corregido en la confirmación b33fb5b801c6 ("net: qualcomm: rmnet: fix global oob in rmnet_policy"). ======================================================================= ERROR: KASAN: global fuera de los límites en la librería validation_nla/nlattr.c:388 [en línea] ERROR: KASAN: global fuera de los límites en la librería __nla_validate_parse+0x19d7/0x29a0/nlattr.c:603 Lectura de tamaño 1 en la dirección ffffffff8b09cb60 por la tarea syz.1.66276/323862 CPU: 0 PID: 323862 Comm: syz.1.66276 No contaminado 6.1.70 #1 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 01/04/2014 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0x177/0x231 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:284 [en línea] print_report+0x14f/0x750 mm/kasan/report.c:395 kasan_report+0x139/0x170 mm/kasan/report.c:495 validation_nla lib/nlattr.c:388 [en línea] __nla_validate_parse+0x19d7/0x29a0 lib/nlattr.c:603 __nla_parse+0x3c/0x50 lib/nlattr.c:700 nla_parse_nested_deprecated include/net/netlink.h:1269 [en línea] __rtnl_newlink net/core/rtnetlink.c:3514 [en línea] rtnl_newlink+0x7bc/0x1fd0 net/core/rtnetlink.c:3623 rtnetlink_rcv_msg+0x794/0xef0 net/core/rtnetlink.c:6122 netlink_rcv_skb+0x1de/0x420 net/netlink/af_netlink.c:2508 netlink_unicast_kernel net/netlink/af_netlink.c:1326 [en línea] netlink_unicast+0x74b/0x8c0 net/netlink/af_netlink.c:1352 netlink_sendmsg+0x882/0xb90 net/netlink/af_netlink.c:1874 sock_sendmsg_nosec net/socket.c:716 [en línea] __sock_sendmsg net/socket.c:728 [en línea] ____sys_sendmsg+0x5cc/0x8f0 net/socket.c:2499 ___sys_sendmsg+0x21c/0x290 net/socket.c:2553 __sys_sendmsg net/socket.c:2582 [en línea] __do_sys_sendmsg net/socket.c:2591 [en línea] __se_sys_sendmsg+0x19e/0x270 net/socket.c:2589 do_syscall_x64 arch/x86/entry/common.c:51 [en línea] do_syscall_64+0x45/0x90 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f67b19a24ad RSP: 002b:00007f67b17febb8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f67b1b45f80 RCX: 00007f67b19a24ad RDX: 0000000000000000 RSI: 0000000020005e40 RDI: 0000000000000004 RBP: 00007f67b1a1e01d R08: 000000000000000 R09: 0000000000000000 R10: 000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffd2513764f R14: 00007ffd251376e0 R15: 00007f67b17fed40 La dirección con errores pertenece a la variable: wwan_rtnl_policy+0x20/0x40 La dirección con errores pertenece a la página física: page:ffffea00002c2700 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xb09c flags: 0xfff00000001000(reserved|node=0|zone=1|lastcpupid=0x7ff) raw: 00fff00000001000 ffffea00002c2708 ffffea00002c2708 000000000000000 raw: 000000000000000 0000000000000000 00000001ffffffff 0000000000000000 página volcada porque: kasan: mal acceso detectado la información del propietario de la página no está presente (¿nunca se estableció?) Estado de la memoria alrededor de la dirección con errores: ffffffff8b09ca00: 05 f9 f9 f9 05 f9 f9 f9 00 01 f9 f9 01 f9 f9 ffffffff8b09ca80: 00 00 00 05 f9 f9 f9 f9 00 00 03 f9 f9 f9 f9 f9 >ffffffff8b09cb00: 00 00 00 00 05 f9 f9 f9 00 00 00 00 f9 f9 f9 f9 ^ ffffffff8b09cb80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =================================================================== Según el comentario de `nla_parse_nested_deprecated`, use el tamaño correcto `IFLA_WWAN_MAX` aquí para solucionar este problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rastreo: considerar el carácter NULL al validar la longitud del evento strlen() devuelve una longitud de cadena que excluye el byte nulo. Si la longitud de la cadena es igual a la longitud máxima del búfer, el búfer no tendrá espacio para el carácter de terminación NULL. Esta confirmación verifica esta condición y devuelve un error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: qcom: sc7280: Fix missing Soundwire runtime stream alloc Commit 15c7fab0e047 ("ASoC: qcom: Move Soundwire runtime stream alloc to soundcards") movió la asignación de tiempo de ejecución de flujo Soundwire del controlador Qualcomm Soundwire al controlador de tarjeta de sonido de cada máquina individual, excepto que olvidó actualizar la tarjeta SC7280. Al igual que para otras tarjetas de sonido Qualcomm que usan Soundwire, el controlador de la tarjeta debe asignar y liberar el tiempo de ejecución. De lo contrario, la reproducción de sonido dará como resultado una desreferencia de puntero NULL u otro efecto de accesos a memoria no inicializados (lo que se confirmó en SDM845 que tenía un problema similar).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfsd: arregla la ejecución entre laundromat y free_stateid. Hay una ejecución entre el manejo de laundromat de delegaciones revocadas y un cliente que envía la operación free_stateid. El hilo de laundromat encuentra que la delegación ha expirado y necesita ser revocada, por lo que marca el stid de delegación revocado y lo pone en una lista de reaper, pero luego desbloquea el bloqueo de estado y la revocación de delegación real ocurre sin el bloqueo. Una vez que el stid está marcado como revocado, un hilo de procesamiento de free_stateid en ejecución hace lo siguiente: (1) llama a list_del_init() que lo elimina de la lista de reaper y (2) libera la estructura del stid de delegación. El hilo de laundromat termina sin llamar a la función revoke_delegation() para esta delegación en particular, pero eso significa que no liberará la concesión de bloqueo que existe en el archivo. Ahora, una nueva apertura para este archivo llega y termina encontrando que la lista de arrendamientos no está vacía y llama a nfsd_breaker_owns_lease() que termina intentando desreferenciar un stateid de delegación liberado. Lo que genera la siguiente advertencia de KASAN de use-after-free: kernel: == ... 2069.0.0.0.0 08/03/2024 núcleo: Seguimiento de llamadas: núcleo: dump_backtrace+0x98/0x120 núcleo: show_stack+0x1c/0x30 núcleo: dump_stack_lvl+0x80/0xe8 núcleo: print_address_description.constprop.0+0x84/0x390 núcleo: print_report+0xa4/0x268 núcleo: kasan_report+0xb4/0xf8 núcleo: __asan_report_load8_noabort+0x1c/0x28 núcleo: nfsd_breaker_owns_lease+0x140/0x160 [nfsd] núcleo: nfsd_file_do_acquire+0xb3c/0x11d0 [nfsd] núcleo: nfsd_file_acquire_opened+0x84/0x110 [nfsd] núcleo: nfs4_get_vfs_file+0x634/0x958 [nfsd] núcleo: nfsd4_process_open2+0xa40/0x1a40 [nfsd] núcleo: nfsd4_open+0xa08/0xe80 [nfsd] núcleo: nfsd4_proc_compound+0xb8c/0x2130 [nfsd] núcleo: nfsd_dispatch+0x22c/0x718 [nfsd] núcleo: svc_process_common+0x8e8/0x1960 [sunrpc] núcleo: svc_process+0x3d4/0x7e0 [sunrpc] núcleo: svc_handle_xprt+0x828/0xe10 [sunrpc] kernel: svc_recv+0x2cc/0x6a8 [sunrpc] kernel: nfsd+0x270/0x400 [nfsd] kernel: kthread+0x288/0x310 kernel: ret_from_fork+0x10/0x20 Este parche propone una solución basada en agregar 2 nuevos valores de stid adicionales sc_status que ayudan a coordinar entre la lavandería y otras operaciones (nfsd4_free_stateid() y nfsd4_delegreturn()). Primero, para asegurarse de que una vez que el stid esté marcado como revocado, no sea eliminado por nfsd4_free_stateid(), la lavandería tome una referencia en el stateid. Luego, al coordinar si el stid se ha colocado en la lista cl_revoked o si estamos procesando FREE_STATEID y debemos asegurarnos de eliminarlo de la lista, cada uno verifica ese estado y actúa en consecuencia. Si laundromat ha agregado a la lista cl_revoke antes de la llegada de FREE_STATEID, entonces nfsd4_free_stateid() sabe eliminarlo de la lista. Si nfsd4_free_stateid() encuentra que las operaciones llegaron antes de que laundromat lo haya colocado en la lista cl_revoke, marca el estado como liberado y luego laundromat ya no lo agregará a la lista. Además, para nfsd4_delegreturn() cuando buscamos el stid especificado, necesitamos acceder a los stid que están marcados como eliminados o liberables, significa que laundromat ha comenzado a procesarlo pero no ha terminado y este delegreturn debe devolver nfserr_deleg_revoked y no nfserr_bad_stateid. Este último no activará un FREE_STATEID y la falta del mismo dejará este stid en la lista cl_revoked indefinidamente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: platform/x86/intel/pmc: Corregir pmc_core_iounmap para llamar a iounmap para direcciones válidas. La confirmación 50c6dbdfd16e ("x86/ioremap: Mejorar las comprobaciones del rango de direcciones de iounmap()") introduce una ADVERTENCIA cuando los rangos de direcciones de iounmap no son válidos. En Thinkpad P1 Gen 7 (Meteor Lake-P), esto provocó que apareciera la siguiente advertencia: ADVERTENCIA: CPU: 7 PID: 713 en arch/x86/mm/ioremap.c:461 iounmap+0x58/0x1f0 Módulos vinculados en: rfkill(+) snd_timer(+) fjes(+) snd soundcore intel_pmc_core(+) int3403_thermal(+) int340x_thermal_zone intel_vsec pmt_telemetry acpi_pad pmt_class acpi_tad int3400_thermal acpi_thermal_rel joydev loop nfnetlink zram xe drm_suballoc_helper nouveau i915 mxm_wmi drm_ttm_helper gpu_sched drm_gpuvm drm_exec drm_buddy i2c_algo_bit crct10dif_pclmul crc32_pclmul ttm crc32c_intel polyval_clmulni rtsx_pci_sdmmc ucsi_acpi polyval_generic mmc_core hid_multitouch drm_display_helper ghash_clmulni_intel typec_ucsi nvme sha512_ssse3 video sha256_ssse3 nvme_core intel_vpu sha1_ssse3 rtsx_pci cec typec nvme_auth i2c_hid_acpi i2c_hid wmi pinctrl_meteorlake serio_raw ip6_tables ip_tables fuse CPU: 7 UID: 0 PID: 713 Comm: (udev-worker) No contaminado 6.12.0-rc2iounmap+ #42 Nombre del hardware: LENOVO 21KWCTO1WW/21KWCTO1WW, BIOS N48ET19W (1.06) 18/07/2024 RIP: 0010:iounmap+0x58/0x1f0 Código: 85 6a 01 00 00 48 8b 05 e6 e2 28 04 48 39 c5 72 19 eb 26 cc cc cc 48 ba 00 00 00 00 00 00 32 00 48 8d 44 02 ff 48 39 c5 72 23 <0f> 0b 48 83 c4 08 5b 5d 41 5c c3 cc cc cc cc 48 ba 00 00 00 00 00 RSP: 0018:ffff888131eff038 EFLAGS: 00010207 RAX: ffffc90000000000 RBX: 0000000000000000 RCX: ffff888e33b80000 RDX: dffffc0000000000 RSI: ffff888e33bc29c0 RDI: 0000000000000000 RBP: 0000000000000000 R08: ffff8881598a8000 R09: ffff888e2ccedc10 R10: 0000000000000003 R11: ffffffffb3367634 R12: 00000000fe000000 R13: ffff888101d0da28 R14: ffffffffc2e437e0 R15: ffff888110b03b28 FS: 00007f3c1d4b3980(0000) GS:ffff888e33b80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005651cfc93578 CR3: 0000000124e4c002 CR4: 0000000000f70ef0 DR0: 00000000000000000 DR1: 00000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: 0000000000000400 PKRU: 55555554 Seguimiento de llamadas: ? __warn.cold+0xb6/0x176 ? iounmap+0x58/0x1f0 ? report_bug+0x1f4/0x2b0 ? handle_bug+0x58/0x90 ? exc_invalid_op+0x17/0x40 ? pci_enable_device_flags+0x1e3/0x2e0 ? __pfx_mtl_core_init+0x10/0x10 [intel_pmc_core] pmc_core_ssram_init+0x7f/0x110 [intel_pmc_core] mtl_core_init+0xda/0x130 [intel_pmc_core] ? __mutex_init+0xb9/0x130 pmc_core_probe+0x27e/0x10b0 [intel_pmc_core] ? _raw_spin_lock_irqsave+0x96/0xf0 ? __pfx_pmc_core_probe+0x10/0x10 [intel_pmc_core] ? __pfx_mutex_unlock+0x10/0x10 ? __pfx_mutex_lock+0x10/0x10 ? device_pm_check_callbacks+0x82/0x370 ? acpi_dev_pm_attach+0x234/0x2b0 platform_probe+0x9f/0x150 really_probe+0x1e0/0x8a0 __driver_probe_device+0x18c/0x370 ? __pfx___driver_attach+0x10/0x10 driver_probe_device+0x4a/0x120 __driver_attach+0x190/0x4a0 ? __pfx___driver_attach+0x10/0x10 bus_for_each_dev+0x103/0x180 ? __pfx_bus_for_each_dev+0x10/0x10 ? klist_add_tail+0x136/0x270 bus_add_driver+0x2fc/0x540 driver_register+0x1a5/0x360 ? __pfx_pmc_core_driver_init+0x10/0x10 [intel_pmc_core] do_one_initcall+0xa4/0x380 ? __pfx_do_one_initcall+0x10/0x10 ? kasan_unpoison+0x44/0x70 do_init_module+0x296/0x800 load_module+0x5090/0x6ce0 ? __pfx_load_module+0x10/0x10 ? ima_post_read_file+0x193/0x200 ? __pfx_ima_post_read_file+0x10/0x10 ? rw_verify_area+0x152/0x4c0 ? kernel_read_file+0x257/0x750 ? __pfx_kernel_read_file+0x10/0x10 ? __pfx_filemap_get_read_batch+0x10/0x10 ? init_module_from_file+0xd1/0x130 init_module_from_file+0xd1/0x130 ? __pfx_init_module_from_file+0x10/0 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: md/raid10: se corrige la desreferencia ptr nulo en raid10_size() En raid10_run(), si raid10_set_queue_limits() tiene éxito, el valor de retorno se establece en cero y, si fallan los siguientes procedimientos, raid10_run() devolverá cero mientras que mddev->private sigue siendo NULL, lo que provoca una desreferencia ptr nula en raid10_size(). Solucione el problema sobrescribiendo solo el valor de retorno si raid10_set_queue_limits() falla.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: LoongArch: Habilitar IRQ si do_ale() se activa en un contexto habilitado para irq. La excepción de acceso no alineado se puede activar en un contexto habilitado para irq, como el modo de usuario; en este caso, do_ale() puede llamar a get_user(), lo que puede provocar una suspensión. Entonces obtendremos: ERROR: función inactiva llamada desde un contexto no válido en arch/loongarch/kernel/access-helper.h:7 in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 129, nombre: modprobe preempt_count: 0, esperado: 0 Profundidad de anidación de RCU: 0, esperado: 0 CPU: 0 UID: 0 PID: 129 Comm: modprobe Contaminado: GW 6.12.0-rc1+ #1723 Contaminado: [W]=WARN Pila: 9000000105e0bd48 0000000000000000 9000000003803944 9000000105e08000 9000000105e0bc70 9000000105e0bc78 000000000000000 0000000000000000 9000000105e0bc78 0000000000000001 9000000185e0ba07 9000000105e0b890 ffffffffffffffff 9000000105e0bc78 73924b81763be05b 9000000100194500 000000000000020c 00000000000000a 0000000000000000 000000000000003 000000000000023f0 000000000000e1401 00000000072f8000 0000007ffbb0e260 0000000000000000 000000000000000 9000000005437650 90000000055d5000 0000000000000000 0000000000000003 0000007ffbb0e1f0 000000000000000 000005567b00490 0000000000000000 9000000003803964 0000007ffbb0dfec 000000000000000b0 0000000000000007 0000000000000003 0000000000071c1d ... Seguimiento de llamadas: [<9000000003803964>] show_stack+0x64/0x1a0 [<9000000004c57464>] dump_stack_lvl+0x74/0xb0 [<9000000003861ab4>] __might_resched+0x154/0x1a0 [<900000000380c96c>] emulate_load_store_insn+0x6c/0xf60 [<9000000004c58118>] do_ale+0x78/0x180 [<9000000003801bc8>] handle_ale+0x128/0x1e0 Entonces habilite IRQ si se activa una excepción de acceso no alineado en un contexto habilitado para irq para solucionarlo.