Vulnerabilidades

Mbed TLS anterior a la versión 3.6.4 presenta una condición de ejecución en la detección de AESNI si se producen ciertas optimizaciones del compilador. Un atacante podría extraer una clave AES de un programa multiproceso o realizar una falsificación de GCM.

Mbed TLS anterior a 3.6.4 tiene un desbordamiento de búfer basado en montón de un byte que analiza PEM, en mbedtls_pem_read_buffer y dos funciones mbedtls_pk_parse, a través de una entrada PEM no confiable.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sched/rt: Corrección de la ejecución en push_rt_task. Descripción general ======== Cuando una CPU elige llamar a push_rt_task y selecciona una tarea para enviarla a la cola de ejecución de otra CPU, llamará al método find_lock_lowest_rq, que generaría un doble bloqueo en las colas de ejecución de ambas CPU. Si uno de los bloqueos no está disponible, puede provocar que se elimine el bloqueo actual de la cola de ejecución y se vuelvan a adquirir ambos bloqueos a la vez. Durante este periodo, es posible que la tarea ya se haya migrado y se esté ejecutando en otra CPU. Estos casos ya se han gestionado. Sin embargo, si la tarea se migra y ya se ha ejecutado, y otra CPU está intentando despertarla (ttwu), de modo que se vuelve a poner en cola en la cola de ejecución (on_rq es 1), y además, si la tarea la ejecutó la misma CPU, las comprobaciones actuales pasarán aunque la tarea se haya migrado y ya no esté en la lista de tareas que se pueden enviar. Fallos ======= Este error provocó bastantes tipos de fallos que desencadenaron pánicos del kernel con varias firmas de fallo, como fallos de aserción, fallos de página, desreferencias de puntero nulo y errores de corrupción de cola, todos procedentes del propio programador. Algunos de los fallos: -> kernel BUG at kernel/sched/rt.c:1616! BUG_ON(idx >= MAX_RT_PRIO) Call Trace: ? __die_body+0x1a/0x60 ? die+0x2a/0x50 ? do_trap+0x85/0x100 ? pick_next_task_rt+0x6e/0x1d0 ? do_error_trap+0x64/0xa0 ? pick_next_task_rt+0x6e/0x1d0 ? exc_invalid_op+0x4c/0x60 ? pick_next_task_rt+0x6e/0x1d0 ? asm_exc_invalid_op+0x12/0x20 ? pick_next_task_rt+0x6e/0x1d0 __schedule+0x5cb/0x790 ? update_ts_time_stats+0x55/0x70 schedule_idle+0x1e/0x40 do_idle+0x15e/0x200 cpu_startup_entry+0x19/0x20 start_secondary+0x117/0x160 secondary_startup_64_no_verify+0xb0/0xbb -> BUG: kernel NULL pointer dereference, address: 00000000000000c0 Call Trace: ? __die_body+0x1a/0x60 ? no_context+0x183/0x350 ? __warn+0x8a/0xe0 ? exc_page_fault+0x3d6/0x520 ? asm_exc_page_fault+0x1e/0x30 ? pick_next_task_rt+0xb5/0x1d0 ? pick_next_task_rt+0x8c/0x1d0 __schedule+0x583/0x7e0 ? update_ts_time_stats+0x55/0x70 schedule_idle+0x1e/0x40 do_idle+0x15e/0x200 cpu_startup_entry+0x19/0x20 start_secondary+0x117/0x160 secondary_startup_64_no_verify+0xb0/0xbb -> BUG: unable to handle page fault for address: ffff9464daea5900 kernel BUG at kernel/sched/rt.c:1861! BUG_ON(rq->cpu != task_cpu(p)) -> kernel BUG at kernel/sched/rt.c:1055! BUG_ON(!rq->nr_running) Call Trace: ? __die_body+0x1a/0x60 ? die+0x2a/0x50 ? do_trap+0x85/0x100 ? dequeue_top_rt_rq+0xa2/0xb0 ? do_error_trap+0x64/0xa0 ? dequeue_top_rt_rq+0xa2/0xb0 ? exc_invalid_op+0x4c/0x60 ? dequeue_top_rt_rq+0xa2/0xb0 ? asm_exc_invalid_op+0x12/0x20 ? dequeue_top_rt_rq+0xa2/0xb0 dequeue_rt_entity+0x1f/0x70 dequeue_task_rt+0x2d/0x70 __schedule+0x1a8/0x7e0 ? blk_finish_plug+0x25/0x40 schedule+0x3c/0xb0 futex_wait_queue_me+0xb6/0x120 futex_wait+0xd9/0x240 do_futex+0x344/0xa90 ? get_mm_exe_file+0x30/0x60 ? audit_exe_compare+0x58/0x70 ? audit_filter_rules.constprop.26+0x65e/0x1220 __x64_sys_futex+0x148/0x1f0 do_syscall_64+0x30/0x80 entry_SYSCALL_64_after_hwframe+0x62/0xc7 -> BUG: unable to handle page fault for address: ffff8cf3608bc2c0 Call Trace: ? __die_body+0x1a/0x60 ? no_context+0x183/0x350 ? spurious_kernel_fault+0x171/0x1c0 ? exc_page_fault+0x3b6/0x520 ? plist_check_list+0x15/0x40 ? plist_check_list+0x2e/0x40 ? asm_exc_page_fault+0x1e/0x30 ? _cond_resched+0x15/0x30 ? futex_wait_queue_me+0xc8/0x120 ? futex_wait+0xd9/0x240 ? try_to_wake_up+0x1b8/0x490 ? futex_wake+0x78/0x160 ? do_futex+0xcd/0xa90 ? plist_check_list+0x15/0x40 ? plist_check_list+0x2e/0x40 ? plist_del+0x6a/0xd0 ? plist_check_list+0x15/0x40 ? plist_check_list+0x2e/0x40 ? dequeue_pushable_task+0x20/0x70 ? __schedule+0x382/0x7e0 ? asm_sysvec_reschedule_i ---truncado---

OP-TEE es un Entorno de Ejecución Confiable (TEE) diseñado para complementar un kernel Linux no seguro que se ejecuta en núcleos Arm; los núcleos Cortex-A utilizan la tecnología TrustZone. En la versión 4.5.0, mediante un binario tee-supplicant especialmente manipulado que se ejecuta en el espacio de usuario de REE, un atacante puede generar un pánico en un TA que utiliza la API de Almacenamiento Seguro de libutee. Muchas funciones de libutee, en particular las que conforman la API de Almacenamiento Seguro, entrarán en pánico si una llamada al sistema devuelve un código de retorno inesperado. Este comportamiento está estipulado por la especificación de la API del Núcleo Interno de TEE. Sin embargo, en la implementación de OP-TEE, los códigos de retorno de las operaciones de almacenamiento seguro se transfieren sin sanear desde el tee-supplicant de REE, a través del controlador tee del kernel de Linux, a través del kernel de OP-TEE, de vuelta a libutee. De este modo, un atacante con acceso al espacio de usuario REE y la capacidad de detener tee-supplicant y reemplazarlo con su propio proceso (generalmente trivial para un usuario root y, dependiendo de la forma en que se configuren los permisos, potencialmente disponible incluso para usuarios menos privilegiados) puede ejecutar un proceso tee-supplicant malicioso que responde a las solicitudes de almacenamiento con códigos de respuesta inesperados, lo que provoca pánico en el TA solicitante. Esto es particularmente peligroso para los TA creados con `TA_FLAG_SINGLE_INSTANCE` (que corresponde a `gpd.ta.singleInstance` y `TA_FLAG_INSTANCE_KEEP_ALIVE` (que corresponde a `gpd.ta.keepAlive`). El comportamiento de estos TA puede depender de la memoria que se conserva entre sesiones, y la capacidad de un atacante de generar pánico en el TA y recargarlo con un espacio de memoria limpio puede comprometer el comportamiento de esos TA. Un ejemplo crítico de esto es el TA optee_ftpm. Utiliza la memoria viva mantenida para almacenar valores de PCR, que crucialmente deben ser no reiniciables. Un atacante que puede provocar un pánico en el TA fTPM puede reiniciar los PCR y luego extenderlos con lo que elija, falsificando mediciones de arranque, accediendo a datos sellados y potencialmente más. El impacto de este problema depende significativamente del comportamiento de los TA afectados. Para algunos, podría manifestarse como una denegación de servicio, mientras que para otros, como el TA fTPM, Puede resultar en la divulgación de datos confidenciales. Cualquier usuario de la TA fTPM se ve afectado, pero podrían producirse ataques similares en otras TA que utilizan la API de Almacenamiento Seguro. Hay una solución disponible en el commit 941a58d78c99c4754fbd4ec3079ec9e1d596af8f.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc64/ftrace: arregla el r15 dañado durante el parche en vivo Si bien r15 siempre se daña con PPC_FTRACE_OUT_OF_LINE, no se restaura en la secuencia de parche en vivo, lo que lleva a fallas no tan obvias como las siguientes: ERROR: No se puede manejar el acceso a los datos del kernel en escritura en 0xc0000000000f9078 Dirección de instrucción errónea: 0xc0000000018ff958 Oops: Acceso al kernel de área defectuosa, sig: 11 [#1] ... NIP: c0000000018ff958 LR: c0000000018ff930 CTR: c0000000009c0790 REGS: c00000005f2e7790 TRAP: 0300 Tainted: GK (6.14.0+) MSR: 8000000000009033 CR: 2822880b XER: 20040000 CFAR: c0000000008addc0 DAR: c0000000000f9078 DSISR: 0a000000 IRQMASK: 1 GPR00: c0000000018f2584 c00000005f2e7a30 c00000000280a900 c000000017ffa488 GPR04: 00000000000000008 00000000000000000 c0000000018f24fc 000000000000000d GPR08: fffffffffffe0000 000000000000000d 0000000000000000 00000000000008000 GPR12: c0000000009c0790 c000000017ffa480 c00000005f2e7c78 c000000000f9070 GPR16: c00000005f2e7c90 000000000000000 000000000000000 000000000000000 GPR20: 000000000000000 c00000005f3efa80 c00000005f2e7c60 c00000005f2e7c88 GPR24: c00000005f2e7c60 0000000000000001 c00000000000f9078 0000000000000000 GPR28: 00007fff97960000 c000000017ffa480 0000000000000000 c0000000000f9078 ... Rastreo de llamadas: check_heap_object+0x34/0x390 (no confiable) __mutex_unlock_slowpath.isra.0+0xe4/0x230 seq_read_iter+0x430/0xa90 proc_reg_read_iter+0xa4/0x200 vfs_read+0x41c/0x510 ksys_read+0xa4/0x190 system_call_exception+0x1d0/0x440 system_call_vectored_common+0x15c/0x2ec Arréglelo restaurando r15 siempre.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: imaginación: corrige una posible pérdida de memoria en e5010_probe() Agrega video_device_release() para liberar la memoria asignada por video_device_alloc() si algo sale mal.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: jfs: validar parámetros AG en dbMount() para evitar fallos Validar db_agheight, db_agwidth y db_agstart en dbMount para detectar metadatos dañados de forma temprana y evitar un comportamiento indefinido en dbAllocAG. Los límites se derivan de L2LPERCTL, LPERCTL/MAXAG y CTLTREESIZE: - agheight: 0 a L2LPERCTL/2 (0 a 5) garantiza un desplazamiento (L2LPERCTL - 2*agheight) >= 0. - agwidth: 1 a min(LPERCTL/MAXAG, 2^(L2LPERCTL - 2*agheight)) garantiza un agperlev >= 1. - Rangos: 1-8 (agheight 0-3), 1-4 (agheight 4), 1 (agheight 5). - LPERCTL/MAXAG = 1024/128 = 8 limita las hojas por AG; 2^(10 - 2*agheight) evita la división a 0. - agstart: 0 a CTLTREESIZE-1 - agwidth*(MAXAG-1) mantiene ti dentro de stree (tamaño 1365). - Rangos: 0-1237 (agwidth 1), 0-348 (agwidth 8). UBSAN: cambio fuera de límites en fs/jfs/jfs_dmap.c:1400:9 el exponente de cambio -335544310 es negativo CPU: 0 UID: 0 PID: 5822 Comm: syz-executor130 No contaminado 6.14.0-rc5-syzkaller #0 Nombre del hardware: Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:231 [inline] __ubsan_handle_shift_out_of_bounds+0x3c8/0x420 lib/ubsan.c:468 dbAllocAG+0x1087/0x10b0 fs/jfs/jfs_dmap.c:1400 dbDiscardAG+0x352/0xa20 fs/jfs/jfs_dmap.c:1613 jfs_ioc_trim+0x45a/0x6b0 fs/jfs/jfs_discard.c:105 jfs_ioctl+0x2cd/0x3e0 fs/jfs/ioctl.c:131 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl+0xf5/0x170 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Encontrado por el Centro de verificación de Linux (linuxtesting.org) con Syzkaller.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: cxusb: ya no juzga rbuf cuando falla la escritura. syzbot reportó un valor no inicializado en cxusb_i2c_xfer. [1] Solo cuando la operación de escritura de usb_bulk_msg() en dvb_usb_generic_rw() se realiza correctamente y rlen es mayor que 0, se ejecutará la operación de lectura de usb_bulk_msg() para leer rlen bytes de datos del dispositivo dvb en rbuf. En este caso, aunque rlen es 1, la operación de escritura falló, lo que provocó que la operación de lectura de dvb no se ejecutara y, en última instancia, la variable i no se inicializara. [1] ERROR: KMSAN: valor no inicializado en cxusb_gpio_tuner drivers/media/usb/dvb-usb/cxusb.c:124 [en línea] ERROR: KMSAN: uninit-value in cxusb_i2c_xfer+0x153a/0x1a60 drivers/media/usb/dvb-usb/cxusb.c:196 cxusb_gpio_tuner drivers/media/usb/dvb-usb/cxusb.c:124 [inline] cxusb_i2c_xfer+0x153a/0x1a60 drivers/media/usb/dvb-usb/cxusb.c:196 __i2c_transfer+0xe25/0x3150 drivers/i2c/i2c-core-base.c:-1 i2c_transfer+0x317/0x4a0 drivers/i2c/i2c-core-base.c:2315 i2c_transfer_buffer_flags+0x125/0x1e0 drivers/i2c/i2c-core-base.c:2343 i2c_master_send include/linux/i2c.h:109 [inline] i2cdev_write+0x210/0x280 drivers/i2c/i2c-dev.c:183 do_loop_readv_writev fs/read_write.c:848 [inline] vfs_writev+0x963/0x14e0 fs/read_write.c:1057 do_writev+0x247/0x5c0 fs/read_write.c:1101 __do_sys_writev fs/read_write.c:1169 [inline] __se_sys_writev fs/read_write.c:1166 [inline] __x64_sys_writev+0x98/0xe0 fs/read_write.c:1166 x64_sys_call+0x2229/0x3c80 arch/x86/include/generated/asm/syscalls_64.h:21 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: vidtv: Al finalizar el proceso posterior a un fallo de inicialización, syzbot reportó una lectura slab-use-after-free en vidtv_mux_init. [1] Tras un fallo en la inicialización de PSI, se accede de nuevo al miembro si, lo que genera este uaf. Tras un fallo en la inicialización de si, es necesario finalizar el proceso posterior. [1] ERROR: KASAN: slab-use-after-free in vidtv_mux_pid_ctx_init drivers/media/test-drivers/vidtv/vidtv_mux.c:78 [inline] BUG: KASAN: slab-use-after-free in vidtv_mux_init+0xac2/0xbe0 drivers/media/test-drivers/vidtv/vidtv_mux.c:524 Read of size 8 at addr ffff88802fa42acc by task syz.2.37/6059 CPU: 0 UID: 0 PID: 6059 Comm: syz.2.37 Not tainted 6.14.0-rc5-syzkaller #0 Hardware name: Google Compute Engine, BIOS Google 02/12/2025 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xc3/0x670 mm/kasan/report.c:521 kasan_report+0xd9/0x110 mm/kasan/report.c:634 vidtv_mux_pid_ctx_init drivers/media/test-drivers/vidtv/vidtv_mux.c:78 vidtv_mux_init+0xac2/0xbe0 drivers/media/test-drivers/vidtv/vidtv_mux.c:524 vidtv_start_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:194 vidtv_start_feed drivers/media/test-drivers/vidtv/vidtv_bridge.c:239 dmx_section_feed_start_filtering drivers/media/dvb-core/dvb_demux.c:973 dvb_dmxdev_feed_start drivers/media/dvb-core/dmxdev.c:508 [inline] dvb_dmxdev_feed_restart.isra.0 drivers/media/dvb-core/dmxdev.c:537 dvb_dmxdev_filter_stop+0x2b4/0x3a0 drivers/media/dvb-core/dmxdev.c:564 dvb_dmxdev_filter_free drivers/media/dvb-core/dmxdev.c:840 [inline] dvb_demux_release+0x92/0x550 drivers/media/dvb-core/dmxdev.c:1246 __fput+0x3ff/0xb70 fs/file_table.c:464 task_work_run+0x14e/0x250 kernel/task_work.c:227 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0xad8/0x2d70 kernel/exit.c:938 do_group_exit+0xd3/0x2a0 kernel/exit.c:1087 __do_sys_exit_group kernel/exit.c:1098 [inline] __se_sys_exit_group kernel/exit.c:1096 [inline] __x64_sys_exit_group+0x3e/0x50 kernel/exit.c:1096 x64_sys_call+0x151f/0x1720 arch/x86/include/generated/asm/syscalls_64.h:232 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f871d58d169 Code: Unable to access opcode bytes at 0x7f871d58d13f. RSP: 002b:00007fff4b19a788 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f871d58d169 RDX: 0000000000000064 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 00007fff4b19a7ec R08: 0000000b4b19a87f R09: 00000000000927c0 R10: 0000000000000001 R11: 0000000000000246 R12: 0000000000000003 R13: 00000000000927c0 R14: 000000000001d553 R15: 00007fff4b19a840 Allocated by task 6059: kasan_save_stack+0x33/0x60 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:394 kmalloc_noprof include/linux/slab.h:901 [inline] kzalloc_noprof include/linux/slab.h:1037 [inline] vidtv_psi_pat_table_init drivers/media/test-drivers/vidtv/vidtv_psi.c:970 vidtv_channel_si_init drivers/media/test-drivers/vidtv/vidtv_channel.c:423 vidtv_mux_init drivers/media/test-drivers/vidtv/vidtv_mux.c:519 vidtv_start_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:194 vidtv_start_feed drivers/media/test-drivers/vidtv/vidtv_bridge.c:239 dmx_section_feed_start_filtering drivers/media/dvb-core/dvb_demux.c:973 dvb_dmxdev_feed_start drivers/media/dvb-core/dmxdev.c:508 [inline] dvb_dmxdev_feed_restart.isra.0 drivers/media/dvb-core/dmxdev.c:537 dvb_dmxdev_filter_stop+0x2b4/0x3a0 drivers/media/dvb-core/dmxdev.c:564 dvb_dmxdev_filter_free drivers/media/dvb-core/dmxdev.c:840 [inline] dvb_demux_release+0x92/0x550 drivers/media/dvb-core/dmxdev.c:1246 __fput+0x3ff/0xb70 fs/file_tabl ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: NFSD: se corrige la ejecución entre el registro de nfsd y exports_proc A partir de ahora, nfsd llama a create_proc_exports_entry() al inicio de init_nfsd y realiza una limpieza mediante remove_proc_entry() al final de exit_nfsd. Lo que provoca errores OOP del kernel si hay una ejecución entre las siguientes 2 operaciones: (i) exportfs -r (ii) mount -t nfsd none /proc/fs/nfsd for 5.4 kernel ARM64: CPU 1: el1_irq+0xbc/0x180 arch_counter_get_cntvct+0x14/0x18 running_clock+0xc/0x18 preempt_count_add+0x88/0x110 prep_new_page+0xb0/0x220 get_page_from_freelist+0x2d8/0x1778 __alloc_pages_nodemask+0x15c/0xef0 __vmalloc_node_range+0x28c/0x478 __vmalloc_node_flags_caller+0x8c/0xb0 kvmalloc_node+0x88/0xe0 nfsd_init_net+0x6c/0x108 [nfsd] ops_init+0x44/0x170 register_pernet_operations+0x114/0x270 register_pernet_subsys+0x34/0x50 init_nfsd+0xa8/0x718 [nfsd] do_one_initcall+0x54/0x2e0 CPU 2 : Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 PC is at : exports_net_open+0x50/0x68 [nfsd] Call trace: exports_net_open+0x50/0x68 [nfsd] exports_proc_open+0x2c/0x38 [nfsd] proc_reg_open+0xb8/0x198 do_dentry_open+0x1c4/0x418 vfs_open+0x38/0x48 path_openat+0x28c/0xf18 do_filp_open+0x70/0xe8 do_sys_open+0x154/0x248 Sometimes it crashes at exports_net_open() and sometimes cache_seq_next_rcu(). and same is happening on latest 6.14 kernel as well: [ 0.000000] Linux version 6.14.0-rc5-next-20250304-dirty ... [ 285.455918] Unable to handle kernel paging request at virtual address 00001f4800001f48 ... [ 285.464902] pc : cache_seq_next_rcu+0x78/0xa4 ... [ 285.469695] Call trace: [ 285.470083] cache_seq_next_rcu+0x78/0xa4 (P) [ 285.470488] seq_read+0xe0/0x11c [ 285.470675] proc_reg_read+0x9c/0xf0 [ 285.470874] vfs_read+0xc4/0x2fc [ 285.471057] ksys_read+0x6c/0xf4 [ 285.471231] __arm64_sys_read+0x1c/0x28 [ 285.471428] invoke_syscall+0x44/0x100 [ 285.471633] el0_svc_common.constprop.0+0x40/0xe0 [ 285.471870] do_el0_svc_compat+0x1c/0x34 [ 285.472073] el0_svc_compat+0x2c/0x80 [ 285.472265] el0t_32_sync_handler+0x90/0x140 [ 285.472473] el0t_32_sync+0x19c/0x1a0 [ 285.472887] Code: f9400885 93407c23 937d7c27 11000421 (f86378a3) [ 285.473422] ---[ fin del seguimiento 0000000000000000 ]--- Se reprodujo simplemente con el siguiente script: mientras [ 1 ] do /exportfs -r done & mientras [ 1 ] do insmod /nfsd.ko mount -t nfsd none /proc/fs/nfsd umount /proc/fs/nfsd rmmod nfsd done & Por lo tanto, la exportación de interfaces al espacio de usuario se realizará Por fin, listo y con limpieza desde el principio. Con el cambio, no hay problemas de POO del kernel.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfsd: Inicializar ssc antes de laundromat_work para evitar la desreferencia de punteros NULL. En nfs4_state_start_net(), laundromat_work puede acceder a nfsd_ssc a través de nfs4_laundromat -> nfsd4_ssc_expire_umount. Si nfsd_ssc no se inicializa, esto puede causar la desreferencia de punteros NULL. Normalmente, el inicio retrasado de laundromat_work permite que la inicialización de nfsd_ssc se complete con tiempo suficiente. Sin embargo, cuando el núcleo espera demasiado tiempo las respuestas del espacio de usuario (p. ej., en la ruta nfs4_state_start_net -> nfsd4_end_grace -> nfsd4_record_grace_done -> nfsd4_cld_grace_done -> cld_pipe_upcall -> __cld_pipe_upcall -> wait_for_completion), el trabajo retrasado puede comenzar antes de que finalice la inicialización de nfsd_ssc. Para solucionar esto, mueva la inicialización de nfsd_ssc antes de iniciar laundromat_work.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: kvaser_pciefd: refinar la lógica de manejo de echo_skb_max, propensa a errores. echo_skb_max debería definir el límite superior admitido de echo_skb[] asignado dentro del priv del dispositivo de red. El valor de tamaño correspondiente proporcionado por este controlador a alloc_candev() es KVASER_PCIEFD_CAN_TX_MAX_COUNT, que es 17. Sin embargo, posteriormente, echo_skb_max se redondea a la potencia de dos más cercana (para el caso máximo, sería 32) y los índices de transmisión/recepción calculados posteriormente durante la transmisión/recepción pueden superar el límite superior de la matriz. Kasan informó esto para el caso de confirmación dentro de kvaser_pciefd_handle_ack_packet(), aunque la función xmit ya había detectado el mismo problema anteriormente. ERROR: KASAN: slab-out-of-bounds in kvaser_pciefd_handle_ack_packet+0x2d7/0x92a drivers/net/can/kvaser_pciefd.c:1528 Read of size 8 at addr ffff888105e4f078 by task swapper/4/0 CPU: 4 UID: 0 PID: 0 Comm: swapper/4 Not tainted 6.15.0 #12 PREEMPT(voluntary) Call Trace: dump_stack_lvl lib/dump_stack.c:122 print_report mm/kasan/report.c:521 kasan_report mm/kasan/report.c:634 kvaser_pciefd_handle_ack_packet drivers/net/can/kvaser_pciefd.c:1528 kvaser_pciefd_read_packet drivers/net/can/kvaser_pciefd.c:1605 kvaser_pciefd_read_buffer drivers/net/can/kvaser_pciefd.c:1656 kvaser_pciefd_receive_irq drivers/net/can/kvaser_pciefd.c:1684 kvaser_pciefd_irq_handler drivers/net/can/kvaser_pciefd.c:1733 __handle_irq_event_percpu kernel/irq/handle.c:158 handle_irq_event kernel/irq/handle.c:210 handle_edge_irq kernel/irq/chip.c:833 __common_interrupt arch/x86/kernel/irq.c:296 common_interrupt arch/x86/kernel/irq.c:286 El recuento máximo de transmisiones es importante para kvaser_pciefd_tx_avail(), pero no para la generación de números de secuencia. Podemos calcularlo como nos convenga, sin tener en cuenta el recuento máximo de transmisiones. La única desventaja es que el tamaño de echo_skb[] debería corresponder al número máximo de secuencia (no al recuento máximo de transmisiones), por lo que, en algunos casos, se consumiría más memoria de la que se podría. Por lo tanto, el tamaño de echo_skb[] subyacente debe ser suficiente para el valor máximo de transmisión redondeado. Encontrado por el Centro de Verificación de Linux (linuxtesting.org) con Syzkaller.