Vulnerabilidades

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> bpf: Deshabilitar la preferencia en bpf_perf_event_output<br /> <br /> La protección de anidamiento en bpf_perf_event_output se basa en la preferencia deshabilitada, lo cual está garantizado para kprobes y tracepoints.<br /> <br /> Sin embargo, bpf_perf_event_output también puede ser llamado desde el contexto de uprobes a través de la función bpf_prog_run_array_sleepable que deshabilita la migración, pero mantiene la preferencia habilitada.<br /> <br /> Esto puede causar que una tarea sea preferida por otra dentro de la protección de anidamiento y eventualmente llevar a que dos tareas usen el mismo búfer perf_sample_data y causen fallos como:<br /> <br /> el kernel intentó ejecutar una página protegida por NX - ¿intento de exploit? (uid: 0)<br /> BUG: no se puede manejar el fallo de página para la dirección: ffffffff82be3eea<br /> ...<br /> Rastro de Llamada:<br /> ? __die+0x1f/0x70<br /> ? page_fault_oops+0x176/0x4d0<br /> ? exc_page_fault+0x132/0x230<br /> ? asm_exc_page_fault+0x22/0x30<br /> ? perf_output_sample+0x12b/0x910<br /> ? perf_event_output+0xd0/0x1d0<br /> ? bpf_perf_event_output+0x162/0x1d0<br /> ? bpf_prog_c6271286d9a4c938_krava1+0x76/0x87<br /> ? __uprobe_perf_func+0x12b/0x540<br /> ? uprobe_dispatcher+0x2c4/0x430<br /> ? uprobe_notify_resume+0x2da/0xce0<br /> ? atomic_notifier_call_chain+0x7b/0x110<br /> ? exit_to_user_mode_prepare+0x13e/0x290<br /> ? irqentry_exit_to_user_mode+0x5/0x30<br /> ? asm_exc_int3+0x35/0x40<br /> <br /> Esto se soluciona deshabilitando la preferencia en bpf_perf_event_output.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> firmware: meson_sm: corrección para evitar una potencial desreferencia de puntero NULL<br /> <br /> of_match_device() puede fallar y devuelve un puntero NULL.<br /> <br /> Esto se corrige comprobando el valor de retorno de of_match_device.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ext4: rechazar la creación de un bloque ea cuando está desmontado<br /> <br /> La expansión del bloque ea necesita acceder a s_root mientras ya está establecido como NULL cuando se activa el desmontaje. Rechazar esta solicitud para evitar un pánico.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net: tls: evitar que las tareas se queden colgadas en el tx_lock<br /> <br /> syzbot envió un informe de tarea colgada y Eric explica que un receptor malintencionado puede mantener RWIN en 0 durante mucho tiempo, por lo que no se garantiza que avancemos. El hilo que tomó el tx_lock y se suspendió puede no liberar el tx_lock durante horas. Usar el modo de suspensión interrumpible donde sea posible y reprogramar el trabajo si no puede adquirir el bloqueo.<br /> <br /> Pruebas: el auto-test existente se supera

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ptp_qoriq: corrige una fuga de memoria en probe()<br /> <br /> Smatch se queja de que:<br /> drivers/ptp/ptp_qoriq.c ptp_qoriq_probe()<br /> advertencia: &amp;#39;base&amp;#39; de ioremap() no liberada.<br /> <br /> Soluciona esto revisando el parámetro de &amp;#39;ptp_qoriq-&amp;gt;base&amp;#39; a &amp;#39;base&amp;#39;.<br /> Esto es solo un error si ptp_qoriq_init() retorna en la<br /> primera ruta de error -ENODEV.<br /> Para otras rutas de error, ptp_qoriq-&amp;gt;base y base son lo mismo.<br /> Y este cambio hace el código más legible.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ALSA: ymfpci: Crear tarjeta con snd_devm_card_new() gestionada por dispositivo<br /> <br /> snd_card_ymfpci_remove() fue eliminada en el commit c6e6bb5eab74 (&amp;#39;ALSA: ymfpci: Asignar recursos con APIs gestionadas por dispositivo&amp;#39;), pero la llamada a snd_card_new() no fue reemplazada por snd_devm_card_new().<br /> <br /> Dado que ya no había una llamada a snd_card_free, la descarga del módulo eventualmente resultaría en un Oops:<br /> <br /> [697561.532887] BUG: incapaz de manejar fallo de página para la dirección: ffffffffc0924480<br /> [697561.532893] #PF: acceso de lectura de supervisor en modo kernel<br /> [697561.532896] #PF: código_de_error(0x0000) - página no presente<br /> [697561.532899] PGD ae1e15067 P4D ae1e15067 PUD ae1e17067 PMD 11a8f5067 PTE 0<br /> [697561.532905] Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> [697561.532909] CPU: 21 PID: 5080 Comm: wireplumber Tainted: G W OE 6.2.7 #1<br /> [697561.532914] Nombre de hardware: System manufacturer System Product Name/TUF GAMING X570-PLUS, BIOS 4408 10/28/2022<br /> [697561.532916] RIP: 0010:try_module_get.part.0+0x1a/0xe0<br /> [697561.532924] Código: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 55 41 54 49 89 fc bf 01 00 00 00 e8 56 3c f8 ff &amp;lt;41&amp;gt; 83 3c 24 02 0f 84 96 00 00 00 41 8b 84 24 30 03 00 00 85 c0 0f<br /> [697561.532927] RSP: 0018:ffffbe9b858c3bd8 EFLAGS: 00010246 [697561.532930] RAX: ffff9815d14f1900 RBX: ffff9815c14e6000 RCX: 0000000000000000 [697561.532933] RDX: 0000000000000000 RSI: ffffffffc055092c RDI: ffffffffb3778c1a [697561.532935] RBP: ffffbe9b858c3be8 R08: 0000000000000040 R09: ffff981a1a741380 [697561.532937] R10: ffffbe9b858c3c80 R11: 00000009d56533a6 R12: ffffffffc0924480 [697561.532939] R13: ffff9823439d8500 R14: 0000000000000025 R15: ffff9815cd109f80 [697561.532942] FS: 00007f13084f1f80(0000) GS:ffff9824aef40000(0000) knlGS:0000000000000000 [697561.532945] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [697561.532947] CR2: ffffffffc0924480 CR3: 0000000145344000 CR4: 0000000000350ee0 [697561.532949] Call Trace: [697561.532951] [697561.532955] try_module_get+0x13/0x30 [697561.532960] snd_ctl_open+0x61/0x1c0 [snd] [697561.532976] snd_open+0xb4/0x1e0 [snd] [697561.532989] chrdev_open+0xc7/0x240 [697561.532995] ? fsnotify_perm.part.0+0x6e/0x160 [697561.533000] ? __pfx_chrdev_open+0x10/0x10 [697561.533005] do_dentry_open+0x169/0x440 [697561.533009] vfs_open+0x2d/0x40 [697561.533012] path_openat+0xa9d/0x10d0 [697561.533017] ? debug_smp_processor_id+0x17/0x20 [697561.533022] ? trigger_load_balance+0x65/0x370 [697561.533026] do_filp_open+0xb2/0x160 [697561.533032] ? _raw_spin_unlock+0x19/0x40 [697561.533036] ? alloc_fd+0xa9/0x190 [697561.533040] do_sys_openat2+0x9f/0x160 [697561.533044] __x64_sys_openat+0x55/0x90 [697561.533048] do_syscall_64+0x3b/0x90 [697561.533052] entry_SYSCALL_64_after_hwframe+0x72/0xdc [697561.533056] RIP: 0033:0x7f1308a40db4 [697561.533059] Code: 24 20 eb 8f 66 90 44 89 54 24 0c e8 46 68 f8 ff 44 8b 54 24 0c 44 89 e2 48 89 ee 41 89 c0 bf 9c ff ff ff b8 01 01 00 00 0f 05 &amp;lt;48&amp;gt; 3d 00 f0 ff ff 77 32 44 89 c7 89 44 24 0c e8 78 68 f8 ff 8b 44 [697561.533062] RSP: 002b:00007ffcce664450 EFLAGS: 00000293 ORIG_RAX: 0000000000000101 [697561.533066] RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f1308a40db4 [697561.533068] RDX: 0000000000080000 RSI: 00007ffcce664690 RDI: 00000000ffffff9c [697561.533070] RBP: 00007ffcce664690 R08: 0000000000000000 R09: 0000000000000012 [697561.533072] R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000080000 [697561.533074] R13: 00007f13054b069b R14: 0000565209f83200 R15: 0000000000000000 [697561.533078]

*** Pendiente de traducción *** Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> vduse: corrección de desreferencia de puntero NULL<br /> <br /> La función de callback vduse_vdpa_set_vq_affinity puede ser llamada<br /> con un valor NULL como cpu_mask al eliminar el dispositivo vduse.<br /> <br /> Este parche restablece el valor de la máscara de afinidad IRQ de virtqueue<br /> para establecer todas las CPUs en lugar de desreferenciar un cpu_mask NULL.<br /> <br /> [ 4760.952149] BUG: desreferencia de puntero NULL del kernel, dirección: 0000000000000000<br /> [ 4760.959110] #PF: acceso de lectura de supervisor en modo kernel<br /> [ 4760.964247] #PF: error_code(0x0000) - página no presente<br /> [ 4760.969385] PGD 0 P4D 0<br /> [ 4760.971927] Oops: 0000 [#1] PREEMPT SMP PTI<br /> [ 4760.976112] CPU: 13 PID: 2346 Comm: vdpa No contaminado 6.4.0-rc6+ #4<br /> [ 4760.982291] Nombre del hardware: Dell Inc. PowerEdge R640/0W23H8, BIOS 2.8.1 06/26/2020<br /> [ 4760.989769] RIP: 0010:memcpy_orig+0xc5/0x130<br /> [ 4760.994049] Código: 16 f8 4c 89 07 4c 89 4f 08 4c 89 54 17 f0 4c 89 5c 17 f8 c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 83 fa 08 72 1b &amp;lt;4c&amp;gt; 8b 06 4c 8b 4c 16 f8 4c 89 07 4c 89 4c 17 f8 c3 cc cc cc cc 66<br /> [ 4761.012793] RSP: 0018:ffffb1d565abb830 EFLAGS: 00010246<br /> [ 4761.018020] RAX: ffff9f4bf6b27898 RBX: ffff9f4be23969c0 RCX: ffff9f4bcadf6400<br /> [ 4761.025152] RDX: 0000000000000008 RSI: 0000000000000000 RDI: ffff9f4bf6b27898<br /> [ 4761.032286] RBP: 0000000000000000 R08: 0000000000000008 R09: 0000000000000000<br /> [ 4761.039416] R10: 0000000000000000 R11: 0000000000000600 R12: 0000000000000000<br /> [ 4761.046549] R13: 0000000000000000 R14: 0000000000000080 R15: ffffb1d565abbb10<br /> [ 4761.053680] FS: 00007f64c2ec2740(0000) GS:ffff9f635f980000(0000) knlGS:0000000000000000<br /> [ 4761.061765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 4761.067513] CR2: 0000000000000000 CR3: 0000001875270006 CR4: 00000000007706e0<br /> [ 4761.074645] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 4761.081775] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [ 4761.088909] PKRU: 55555554<br /> [ 4761.091620] Traza de llamadas:<br /> [ 4761.094074] <br /> [ 4761.096180] ? __die+0x1f/0x70<br /> [ 4761.099238] ? page_fault_oops+0x171/0x4f0<br /> [ 4761.103340] ? exc_page_fault+0x7b/0x180<br /> [ 4761.107265] ? asm_exc_page_fault+0x22/0x30<br /> [ 4761.111460] ? memcpy_orig+0xc5/0x130<br /> [ 4761.115126] vduse_vdpa_set_vq_affinity+0x3e/0x50 [vduse]<br /> [ 4761.120533] virtnet_clean_affinity.part.0+0x3d/0x90 [virtio_net]<br /> [ 4761.126635] remove_vq_common+0x1a4/0x250 [virtio_net]<br /> [ 4761.131781] virtnet_remove+0x5d/0x70 [virtio_net]<br /> [ 4761.136580] virtio_dev_remove+0x3a/0x90<br /> [ 4761.140509] device_release_driver_internal+0x19b/0x200<br /> [ 4761.145742] bus_remove_device+0xc2/0x130<br /> [ 4761.149755] device_del+0x158/0x3e0<br /> [ 4761.153245] ? kernfs_find_ns+0x35/0xc0<br /> [ 4761.157086] device_unregister+0x13/0x60<br /> [ 4761.161010] unregister_virtio_device+0x11/0x20<br /> [ 4761.165543] device_release_driver_internal+0x19b/0x200<br /> [ 4761.170770] bus_remove_device+0xc2/0x130<br /> [ 4761.174782] device_del+0x158/0x3e0<br /> [ 4761.178276] ? __pfx_vdpa_name_match+0x10/0x10 [vdpa]<br /> [ 4761.183336] device_unregister+0x13/0x60<br /> [ 4761.187260] vdpa_nl_cmd_dev_del_set_doit+0x63/0xe0 [vdpa]

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> RDMA/irdma: Corregir condición de carrera de datos en la finalización de solicitud CQP<br /> <br /> KCSAN detecta una condición de carrera de datos en la ubicación de memoria cqp_request-&amp;gt;request_done, a la cual se accede sin bloqueo en irdma_handle_cqp_op mientras se actualiza en irdma_cqp_ce_handler.<br /> <br /> Anotar la intención sin bloqueo con READ_ONCE/WRITE_ONCE para evitar cualquier optimización del compilador como la fusión de cargas y/o la advertencia de KCSAN.<br /> <br /> [222808.417128] BUG: KCSAN: condición de carrera de datos en irdma_cqp_ce_handler [irdma] / irdma_wait_event [irdma]<br /> <br /> [222808.417532] escritura en 0xffff8e44107019dc de 1 bytes por la tarea 29658 en la cpu 5:<br /> [222808.417610] irdma_cqp_ce_handler+0x21e/0x270 [irdma]<br /> [222808.417725] cqp_compl_worker+0x1b/0x20 [irdma]<br /> [222808.417827] process_one_work+0x4d1/0xa40<br /> [222808.417835] worker_thread+0x319/0x700<br /> [222808.417842] kthread+0x180/0x1b0<br /> [222808.417852] ret_from_fork+0x22/0x30<br /> <br /> [222808.417918] lectura en 0xffff8e44107019dc de 1 bytes por la tarea 29688 en la cpu 1:<br /> [222808.417995] irdma_wait_event+0x1e2/0x2c0 [irdma]<br /> [222808.418099] irdma_handle_cqp_op+0xae/0x170 [irdma]<br /> [222808.418202] irdma_cqp_cq_destroy_cmd+0x70/0x90 [irdma]<br /> [222808.418308] irdma_puda_dele_rsrc+0x46d/0x4d0 [irdma]<br /> [222808.418411] irdma_rt_deinit_hw+0x179/0x1d0 [irdma]<br /> [222808.418514] irdma_ib_dealloc_device+0x11/0x40 [irdma]<br /> [222808.418618] ib_dealloc_device+0x2a/0x120 [ib_core]<br /> [222808.418823] __ib_unregister_device+0xde/0x100 [ib_core]<br /> [222808.418981] ib_unregister_device+0x22/0x40 [ib_core]<br /> [222808.419142] irdma_ib_unregister_device+0x70/0x90 [irdma]<br /> [222808.419248] i40iw_close+0x6f/0xc0 [irdma]<br /> [222808.419352] i40e_client_device_unregister+0x14a/0x180 [i40e]<br /> [222808.419450] i40iw_remove+0x21/0x30 [irdma]<br /> [222808.419554] auxiliary_bus_remove+0x31/0x50<br /> [222808.419563] device_remove+0x69/0xb0<br /> [222808.419572] device_release_driver_internal+0x293/0x360<br /> [222808.419582] driver_detach+0x7c/0xf0<br /> [222808.419592] bus_remove_driver+0x8c/0x150<br /> [222808.419600] driver_unregister+0x45/0x70<br /> [222808.419610] auxiliary_driver_unregister+0x16/0x30<br /> [222808.419618] irdma_exit_module+0x18/0x1e [irdma]<br /> [222808.419733] __do_sys_delete_module.constprop.0+0x1e2/0x310<br /> [222808.419745] __x64_sys_delete_module+0x1b/0x30<br /> [222808.419755] do_syscall_64+0x39/0x90<br /> [222808.419763] entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> [222808.419829] valor cambiado: 0x01 -&amp;gt; 0x03

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> bcache: corrección del daño en la lista btree_cache_wait<br /> <br /> Obtenemos un fallo del kernel sobre &amp;#39;corrupción de list_add. next-&amp;gt;prev debería ser prev (ffff9c801bc01210), pero era ffff9c77b688237c. (next=ffffae586d8afe68).&amp;#39;<br /> <br /> crash&amp;gt; struct list_head 0xffff9c801bc01210<br /> struct list_head {<br /> next = 0xffffae586d8afe68,<br /> prev = 0xffffae586d8afe68<br /> }<br /> crash&amp;gt; struct list_head 0xffff9c77b688237c<br /> struct list_head {<br /> next = 0x0,<br /> prev = 0x0<br /> }<br /> crash&amp;gt; struct list_head 0xffffae586d8afe68<br /> struct list_head struct: dirección virtual de kernel inválida: ffffae586d8afe68 tipo: &amp;#39;gdb_readmem_callback&amp;#39;<br /> No se puede acceder a la memoria en la dirección 0xffffae586d8afe68<br /> <br /> [230469.019492] Rastro de Llamada:<br /> [230469.032041] prepare_to_wait+0x8a/0xb0<br /> [230469.044363] ? bch_btree_keys_free+0x6c/0xc0 [escache]<br /> [230469.056533] mca_cannibalize_lock+0x72/0x90 [escache]<br /> [230469.068788] mca_alloc+0x2ae/0x450 [escache]<br /> [230469.080790] bch_btree_node_get+0x136/0x2d0 [escache]<br /> [230469.092681] bch_btree_check_thread+0x1e1/0x260 [escache]<br /> [230469.104382] ? finish_wait+0x80/0x80<br /> [230469.115884] ? bch_btree_check_recurse+0x1a0/0x1a0 [escache]<br /> [230469.127259] kthread+0x112/0x130<br /> [230469.138448] ? kthread_flush_work_fn+0x10/0x10<br /> [230469.149477] ret_from_fork+0x35/0x40<br /> <br /> bch_btree_check_thread() y bch_dirty_init_thread() pueden llamar a mca_cannibalize() para canibalizar otros nodos btree en caché. Solo un hilo puede hacerlo a la vez, por lo que la operación de otros hilos se añadirá a la lista btree_cache_wait.<br /> <br /> Debemos llamar a finish_wait() para eliminar la operación de btree_cache_wait antes de liberar su dirección de memoria. De lo contrario, la lista se dañará. También se debe llamar a bch_cannibalize_unlock() para liberar el btree_cache_alloc_lock y despertar a otros en espera.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> md/raid10: soluciona fuga de memoria del hilo md<br /> <br /> En raid10_run(), si setup_conf() tiene éxito y raid10_run() falló antes de establecer &amp;#39;mddev-&amp;gt;thread&amp;#39;, entonces en la ruta de error &amp;#39;conf-&amp;gt;thread&amp;#39; no es liberado.<br /> <br /> Soluciona el problema estableciendo &amp;#39;mddev-&amp;gt;thread&amp;#39; justo después de setup_conf().

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> mtd: spi-nor: Solución para el desbordamiento de desplazamiento en spi_nor_set_erase_type<br /> <br /> spi_nor_set_erase_type() se utilizaba ya sea para establecer o para enmascarar un tipo de borrado. Cuando lo utilizábamos para enmascarar un tipo de borrado, se producía un desbordamiento de desplazamiento:<br /> UBSAN: desbordamiento de desplazamiento en drivers/mtd/spi-nor/core.c:2237:24<br /> el exponente de desplazamiento 4294967295 es demasiado grande para el tipo &amp;#39;int&amp;#39; de 32 bits<br /> <br /> La configuración de size_{shift, mask} y del código de operación son innecesarias cuando el tamaño de borrado es cero, ya que a lo largo del código solo se considera el tamaño de borrado para determinar si un tipo de borrado es compatible o no. Establecer el código de operación a 0xFF también era incorrecto, ya que nadie garantiza que 0xFF sea un código de operación no utilizado. Por lo tanto, al enmascarar un tipo de borrado, simplemente establezca el tamaño de borrado a cero. Esto solucionará el desbordamiento de desplazamiento.<br /> <br /> [ta: refinar cambios, nuevo mensaje de commit, corregir error de compilación]