Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: medios: aspeed: corrige la lógica de manejo del reloj El motor de video usa eclk y vclk para sus fuentes de reloj y su control de reinicio está acoplado con eclk para que la secuencia de habilitación del reloj actual funcione como se muestra a continuación. Habilitar eclk De-assert Video Engine restablece un retraso de 10 ms Habilitar vclk Introduce un reinicio incorrecto en el hardware de Video Engine y eventualmente el hardware genera transferencias de memoria DMA inesperadas que pueden dañar la región de la memoria en patrones aleatorios y esporádicos. Este problema se observa muy raramente en algunos SoC AST2500 específicos, pero provoca un pánico crítico en el kernel al crear varias formas de firma, por lo que es extremadamente difícil de depurar. Además, el problema se observa incluso cuando el motor de vídeo no se utiliza activamente porque udevd enciende el hardware del motor de vídeo durante un breve periodo de tiempo para realizar una consulta en cada arranque. Para solucionar este problema, esta confirmación cambia la lógica de manejo del reloj para activar la anulación de reinicio después de habilitar tanto eclk como vclk. Además, agrega la llamada clk_unprepare para un caso en el que falla la sonda. clk: ast2600: corrige la configuración de restablecimiento para eclk y vclk La configuración de restablecimiento del motor de video debe combinarse con eclk para que coincida con la configuración de los SoC Aspeed anteriores que se define en clk-aspeed.c, ya que todos los SoC Aspeed comparten un único controlador de motor de video. Además, el bit de reinicio 6 se define como reinicio del 'Motor de video' en la hoja de datos, por lo que debe desactivarse cuando eclk está habilitado. Este commit corrige la configuración.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/i915: soluciona el fallo en auto_retire La lógica de retiro utiliza los 2 bits inferiores del puntero a la función de retiro para almacenar indicadores. Sin embargo, no se garantiza que la función auto_retire esté alineada con un múltiplo de 4, lo que provoca fallas cuando saltamos a la dirección incorrecta, por ejemplo así: 2021-04-24T18:03:53.804300Z WARNING kernel: [ 516.876901] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI 2021-04-24T18:03:53.804310Z WARNING kernel: [ 516.876906] CPU: 7 PID: 146 Comm: kworker/u16:6 Tainted: G U 5.4.105-13595-g3cd84167b2df #1 2021-04-24T18:03:53.804311Z WARNING kernel: [ 516.876907] Hardware name: Google Volteer2/Volteer2, BIOS Google_Volteer2.13672.76.0 02/22/2021 2021-04-24T18:03:53.804312Z WARNING kernel: [ 516.876911] Workqueue: events_unbound active_work 2021-04-24T18:03:53.804313Z WARNING kernel: [ 516.876914] RIP: 0010:auto_retire+0x1/0x20 2021-04-24T18:03:53.804314Z WARNING kernel: [ 516.876916] Code: e8 01 f2 ff ff eb 02 31 db 48 89 d8 5b 5d c3 0f 1f 44 00 00 55 48 89 e5 f0 ff 87 c8 00 00 00 0f 88 ab 47 4a 00 31 c0 5d c3 0f <1f> 44 00 00 55 48 89 e5 f0 ff 8f c8 00 00 00 0f 88 9a 47 4a 00 74 2021-04-24T18:03:53.804319Z WARNING kernel: [ 516.876918] RSP: 0018:ffff9b4d809fbe38 EFLAGS: 00010286 2021-04-24T18:03:53.804320Z WARNING kernel: [ 516.876919] RAX: 0000000000000007 RBX: ffff927915079600 RCX: 0000000000000007 2021-04-24T18:03:53.804320Z WARNING kernel: [ 516.876921] RDX: ffff9b4d809fbe40 RSI: 0000000000000286 RDI: ffff927915079600 2021-04-24T18:03:53.804321Z WARNING kernel: [ 516.876922] RBP: ffff9b4d809fbe68 R08: 8080808080808080 R09: fefefefefefefeff 2021-04-24T18:03:53.804321Z WARNING kernel: [ 516.876924] R10: 0000000000000010 R11: ffffffff92e44bd8 R12: ffff9279150796a0 2021-04-24T18:03:53.804322Z WARNING kernel: [ 516.876925] R13: ffff92791c368180 R14: ffff927915079640 R15: 000000001c867605 2021-04-24T18:03:53.804323Z WARNING kernel: [ 516.876926] FS: 0000000000000000(0000) GS:ffff92791ffc0000(0000) knlGS:0000000000000000 2021-04-24T18:03:53.804323Z WARNING kernel: [ 516.876928] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 2021-04-24T18:03:53.804324Z WARNING kernel: [ 516.876929] CR2: 0000239514955000 CR3: 00000007f82da001 CR4: 0000000000760ee0 2021-04-24T18:03:53.804325Z WARNING kernel: [ 516.876930] PKRU: 55555554 2021-04-24T18:03:53.804325Z WARNING kernel: [ 516.876931] Call Trace: 2021-04-24T18:03:53.804326Z WARNING kernel: [ 516.876935] __active_retire+0x77/0xcf 2021-04-24T18:03:53.804326Z WARNING kernel: [ 516.876939] process_one_work+0x1da/0x394 2021-04-24T18:03:53.804327Z WARNING kernel: [ 516.876941] worker_thread+0x216/0x375 2021-04-24T18:03:53.804327Z WARNING kernel: [ 516.876944] kthread+0x147/0x156 2021-04-24T18:03:53.804335Z WARNING kernel: [ 516.876946] ? pr_cont_work+0x58/0x58 2021-04-24T18:03:53.804335Z WARNING kernel: [ 516.876948] ? kthread_blkcg+0x2e/0x2e 2021-04-24T18:03:53.804336Z WARNING kernel: [ 516.876950] ret_from_fork+0x1f/0x40 2021-04-24T18:03:53.804336Z WARNING kernel: [ 516.876952] Modules linked in: cdc_mbim cdc_ncm cdc_wdm xt_cgroup rfcomm cmac algif_hash algif_skcipher af_alg xt_MASQUERADE uinput snd_soc_rt5682_sdw snd_soc_rt5682 snd_soc_max98373_sdw snd_soc_max98373 snd_soc_rl6231 regmap_sdw snd_soc_sof_sdw snd_soc_hdac_hdmi snd_soc_dmic snd_hda_codec_hdmi snd_sof_pci snd_sof_intel_hda_common intel_ipu6_psys snd_sof_xtensa_dsp soundwire_intel soundwire_generic_allocation soundwire_cadence snd_sof_intel_hda snd_sof snd_soc_hdac_hda snd_soc_acpi_intel_match snd_soc_acpi snd_hda_ext_core soundwire_bus snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hwdep snd_hda_core intel_ipu6_isys videobuf2_dma_contig videobuf2_v4l2 videobuf2_common videobuf2_memops mei_hdcp intel_ipu6 ov2740 ov8856 at24 sx9310 dw9768 v4l2_fwnode cros_ec_typec intel_pmc_mux roles acpi_als typec fuse iio_trig_sysfs cros_ec_light_prox cros_ec_lid_angle cros_ec_sensors cros

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: KVM: VMX: deshabilite la preferencia al sondear los MSR devueltos por el usuario. Deshabilite la preferencia al sondear el MSR devuelto por un usuario a través de RDSMR/WRMSR. Si MSR tiene un valor diferente por CPU lógica, WRMSR podría dañar el valor del host si KVM se adelanta entre RDMSR y WRMSR y luego se reprograma en una CPU diferente. De manera oportunista, coloque el asistente en x86 común, SVM usará el asistente en una confirmación futura.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: KVM: nVMX: siempre intente asignar eVMCS después de la migración Cuando se utiliza VMCS iluminado y el estado anidado se migra con vmx_get_nested_state()/vmx_set_nested_state() KVM no puede asignar evmcs página de inmediato: evmcs gpa no es 'struct kvm_vmx_nested_state_hdr' y no podemos leerlo desde la página de asistencia de VP porque el espacio de usuario puede decidir restaurar HV_X64_MSR_VP_ASSIST_PAGE después de restaurar el estado anidado (y QEMU, por ejemplo, hace exactamente eso). Para asegurarse de que eVMCS esté asignado, /vmx_set_nested_state() genera la solicitud KVM_REQ_GET_NESTED_STATE_PAGES. el commit f2c7ef3ba955 ("KVM: nSVM: cancelar KVM_REQ_GET_NESTED_STATE_PAGES en vmexit anidado") agregó la limpieza KVM_REQ_GET_NESTED_STATE_PAGES a nested_vmx_vmexit() para asegurarse de que el mapa de bits del permiso MSR no se cambie cuando ocurre una salida inmediata de L2 a L1 justo después de la migración (causada por un evento pendiente, Por ejemplo). Desafortunadamente, en exactamente la misma situación todavía necesitamos tener eVMCS mapeado para que nested_sync_vmcs12_to_shadow() refleje los cambios en VMCS12 a eVMCS. Como curita, restaure nested_get_evmcs_page() al borrar KVM_REQ_GET_NESTED_STATE_PAGES en nested_vmx_vmexit(). La "solución" está lejos de ser ideal, ya que no podemos propagar fácilmente posibles fallas e incluso si pudiéramos, lo más probable es que ya sea demasiado tarde para hacerlo. Toda la idea 'KVM_REQ_GET_NESTED_STATE_PAGES' para mapear eVMCS después de la migración parece ser frágil ya que nos desviamos demasiado de la ruta 'nativa' cuando la carga de vmptr ocurre en vmx_set_nested_state().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iio: core: arreglar la eliminación de los controladores ioctl Actualmente, los controladores ioctl se eliminan dos veces. Por primera vez durante iio_device_unregister() y luego dentro de iio_device_unregister_eventset() y iio_buffers_free_sysfs_and_mask(). La doble liberación conduce al pánico en el kernel. Para solucionar este problema, no toque directamente la lista de controladores ioctl, sino que permita que el código responsable del registro llame a la rutina de limpieza coincidente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: typec: ucsi: recupera todos los PDO en lugar de solo los primeros 4 commits 4dbc6a4ef06d ("usb: typec: ucsi: guarda objetos de datos de energía en modo PD") introdujo la recuperación de los PDO cuando se conectan a una fuente compatible con PD. Pero solo se reciben los primeros 4 PDO, ya que ese es el número máximo que se puede recuperar a la vez dada la limitación de longitud de MESSAGE_IN (16 bytes). Sin embargo, según las especificaciones de PD, una fuente conectada puede anunciar hasta un máximo de 7 PDO. Si dicha fuente está conectada, es posible que el PPM haya negociado un contrato de energía con uno de los PDO con un índice mayor que 4, y se reflejaría en el campo de posición del objeto del objeto de datos de solicitud (RDO). Esto daría como resultado un acceso fuera de los límites cuando se usa rdo_index() para indexar en la matriz src_pdos en ucsi_psy_get_voltage_now(). Con la ayuda del verificador UBSAN -fsanitize=array-bounds habilitado, este problema exacto se revela cuando se conecta a un adaptador de fuente PD que anuncia 5 PDO y el PPM firma un contrato después de seleccionar el quinto. [ 151.545106][ T70] Excepción inesperada de BRK del kernel en EL1 [ 151.545112][ T70] Error interno: controlador BRK: f2005512 [#1] SMP PREEMPT ... [ 151.545499][ T70] pc : ucsi_psy_get_prop+0x208/0x20c [ 151.545507 ] [ T70] lr : power_supply_show_property+0xc0/0x328 ... [ 151.545542][ T70] Rastreo de llamadas: [ 151.545544][ T70] ucsi_psy_get_prop+0x208/0x20c [ 151.545546][ T70] power_supply_uevent+0x1a4/0x 2f0 [151.545550][T70] dev_uevent+0x200/0x384 [ 151.545555][ T70] kobject_uevent_env+0x1d4/0x7e8 [ 151.545557][ T70] power_supply_changed_work+0x174/0x31c [ 151.545562][ T70] Process_one_work+0x244/0 x6f0 [ 151.545564][ T70] work_thread+0x3e0/0xa64 Nosotros Puede resolver esto recuperando y almacenando hasta un máximo de 7 PDO en la matriz con->src_pdos. Esto implicaría dos llamadas al comando GET_PDOS.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: nbd: corrija el puntero NULL en flush_workqueue Abra /dev/nbdX primero, config_refs será 1 y los punteros en nbd_device seguirán siendo nulos. Desconecte /dev/nbdX, luego haga referencia a un recv_workq nulo. La protección de config_refs en nbd_genl_disconnect es inútil. [656.366194] ERROR: desreferencia del puntero NULL del kernel, dirección: 00000000000000020 [656.368943] #PF: acceso de escritura del supervisor en modo kernel [656.369844] #PF: código_error(0x0002) - página no presente [656.370717] PGD 10cc87067 P 4D 10cc87067 PUD 1074b4067 PMD 0 [656.371693] Ups: 0002 [#1] SMP [656.372242] CPU: 5 PID: 7977 Comm: nbd-client No contaminado 5.11.0-rc5-00040-g76c057c84d28 #1 [656.373661] Nombre de hardware: PC estándar QEMU (i 440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 01/04/2014 [ 656.375904] RIP: 0010:mutex_lock+0x29/0x60 [ 656.376627] Código: 00 0f 1f 44 00 00 55 48 89 fd 48 83 05 6f d7 fe 08 01 e8 7a c3 ff ff 48 83 05 6a d7 fe 08 01 31 c0 65 48 8b 14 25 00 6d 01 00 48 0f b1 55 d [ 656.378934 ] RSP: 0018:ffffc900005eb9b0 EFLAGS: 00010246 [ 656.379350] RAX: 0000000000000000 RBX: 00000000000000000 RCX: 0000000000000000 [ 656.379915 ] RDX: ffff888104cf2600 RSI: fffffffaae8f452 RDI: 0000000000000020 [ 656.380473] RBP: 00000000000000020 R08: 00000000000000000 R09: ffff88813bd6b31 8 [656.381039] R10: 00000000000000c7 R11: fefefefefefefeff R12: ffff888102710b40 [ 656.381599] R13: ffffc900005eb9e0 R14: ffffffffb2930680 R15: ffff88810770ef00 [ 656.3821 66] FS: 00007fdf117ebb40(0000) GS:ffff88813bd40000(0000) knlGS:0000000000000000 [ 656.382806] CS: 0010 DS: 0000 ES: 0000 CR0 : 0000000080050033 [ 656.383261] CR2: 0000000000000020 CR3: 0000000100c84000 CR4: 00000000000006e0 [ 656.383819] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 656.384370] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 656.384927] Seguimiento de llamadas : [656.385111] flux_workqueue+0x92 /0x6c0 [ 656.385395] nbd_disconnect_and_put+0x81/0xd0 [ 656.385716] nbd_genl_disconnect+0x125/0x2a0 [ 656.386034] genl_family_rcv_msg_doit.isra.0+0x102/0x1b0 [ 656 .386422] genl_rcv_msg+0xfc/0x2b0 [656.386685]? nbd_ioctl+0x490/0x490 [656.386954]? genl_family_rcv_msg_doit.isra.0+0x1b0/0x1b0 [ 656.387354] netlink_rcv_skb+0x62/0x180 [ 656.387638] genl_rcv+0x34/0x60 [ 656.387874] netlink_unicast+0x26d/0x590 [ 6 56.388162] netlink_sendmsg+0x398/0x6c0 [656.388451]? netlink_rcv_skb+0x180/0x180 [656.388750] ____sys_sendmsg+0x1da/0x320 [656.389038] ? ____sys_recvmsg+0x130/0x220 [ 656.389334] ___sys_sendmsg+0x8e/0xf0 [ 656.389605] ? ___sys_recvmsg+0xa2/0xf0 [656.389889] ? handle_mm_fault+0x1671/0x21d0 [ 656.390201] __sys_sendmsg+0x6d/0xe0 [ 656.390464] __x64_sys_sendmsg+0x23/0x30 [ 656.390751] do_syscall_64+0x45/0x70 [656.391017] Entry_SYSCALL_64_after_hwframe+0x44/0xa9 Para solucionarlo, simplemente agregue if (nbd->recv_workq) a nbd_disconnect_and_put().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: comprimir: corregir la condición de ejecución de sobrescritura frente a truncar pos_fsstress testcase presenta un pánico como se muestra a continuación: ------------[ cortar aquí ]--- --------- ¡ERROR del kernel en fs/f2fs/compress.c:1082! código de operación no válido: 0000 [#1] SMP PTI CPU: 4 PID: 2753477 Comm: kworker/u16:2 Contaminado: G OE 5.12.0-rc1-custom #1 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.14.0-2 01/04/2014 Cola de trabajo: reescritura wb_workfn (flush-252:16) RIP: 0010:prepare_compress_overwrite+0x4c0/0x760 [f2fs] Seguimiento de llamadas: f2fs_prepare_compress_overwrite+0x5f/0x80 [f2fs] f2fs_write_cache_pages+ 0x468/0x8a0 [f2fs] f2fs_write_data_pages+0x2a4/0x2f0 [f2fs] do_writepages+0x38/0xc0 __writeback_single_inode+0x44/0x2a0 writeback_sb_inodes+0x223/0x4d0 __writeback_inodes_wb+0x56/0xf0 wb_writeback+0x1dd/0 x290 wb_workfn+0x309/0x500 proceso_one_work+0x220/0x3c0 trabajador_thread+0x53/ 0x420 kthread+0x12f/0x150 ret_from_fork+0x22/0x30 La causa principal es que truncate() puede correr con sobrescritura como se muestra a continuación, por lo que un recuento de referencias restante en la página no puede garantizar que la página se adjunte en el árbol de mapeo todo el tiempo, después del truncamiento, más adelante find_lock_page() puede devolver un puntero NULL. - prepare_compress_overwrite - f2fs_pagecache_get_page - unlock_page - f2fs_setattr - truncate_setsize - truncate_inode_page - delete_from_page_cache - find_lock_page Solucione este problema evitando hacer referencia a la página actualizada.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: nvmet-rdma: corrige la deref NULL cuando se completa SEND con error Al ejecutar algo de tráfico y eliminar el enlace en el par, se recibe un error de contador de reintentos excedido. Esto lleva a nvmet_rdma_error_comp que intentó acceder a cq_context para obtener la cola. El cq_context ya no es válido después de la corrección para usar el mecanismo CQ compartido y debe obtenerse de manera similar a cómo se obtiene en otras funciones de wc->qp. [905.786331] nvmet_rdma: El ENVÍO para CQE 0x00000000e3337f90 falló y se superó el contador de reintentos de transporte de estado (12). [905.832048] ERROR: no se puede manejar la desreferencia del puntero NULL del kernel en 0000000000000048 [905.839919] PGD 0 P4D 0 [905.842464] Vaya: 0000 1 SMP NOPTI [905.846144] CPU: 13 PID: 1557 Co mm: kworker/13:1H Kdump: cargado Contaminado : G OE --------- - - 4.18.0-304.el8.x86_64 #1 [ 905.872135] RIP: 0010:nvmet_rdma_error_comp+0x5/0x1b [nvmet_rdma] [ 905.878259] Código: 19 4f c0 e8 89 B3 A5 F6 E9 5B E0 FF FF 0F B7 75 14 4C 89 EA 48 C7 C7 08 1A 4F C0 E8 71 B3 A5 F6 E9 4B E0 FF FF 0F 1F 44 00 00 00 <48> 8B 47 48 48 85 C0 74 08 48 89 c7 e9 98 bf 49 00 e9 c3 e3 ff ff [ 905.897135] RSP: 0018:ffffab601c45fe28 EFLAGS: 00010246 [ 905.902387] RAX: 00000000000000065 RBX: ffff9e729ea2f800 RCX: 0000000000000000 [ 905.909558] RDX: 0000000000000000 RSI: ffff9e72df9567c8 RDI: 00000000000000000 [ 905.916731] RBP : ffff9e729ea2b400 R08: 000000000000074d R09: 0000000000000074 [ 905.923903] R10: 00000000000000000 R11: ffffab601c45fcc0 R12: 00000000000 00010 [ 905.931074] R13: 0000000000000000 R14: 0000000000000010 R15: ffff9e729ea2f400 [ 905.938247] FS: 0000000000000000(0000) GS:ffff9e72 df940000(0000) knlGS:0000000000000000 [ 905.938249] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 905.950067] nvmet_rdma: ENVÍO para CQE 0x00000000c7356cca falló con el contador de reintentos de transporte de estado excedido (12). [ 905.961855] CR2: 0000000000000048 CR3: 000000678d010004 CR4: 00000000007706e0 [ 905.961855] DR0: 00000000000000000 DR1: 00000000000000 00 DR2: 0000000000000000 [ 905.961856] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 00000000000000400 [ 905.961857] PKRU: 55555554 [ 906.0 10315] Seguimiento de llamadas: [906.012778 ] __ib_process_cq+0x89/0x170 [ib_core] [ 906.017509] ib_cq_poll_work+0x26/0x80 [ib_core] [ 906.022152] Process_one_work+0x1a7/0x360 [ 906.026182] ? crear_trabajador+0x1a0/0x1a0 [ 906.030123] hilo_trabajador+0x30/0x390 [ 906.033802] ? create_worker+0x1a0/0x1a0 [ 906.037744] kthread+0x116/0x130 [ 906.040988] ? kthread_flush_work_fn+0x10/0x10 [ 906.045456] ret_from_fork+0x1f/0x40

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: kyber: corrige el acceso fuera de los límites cuando se adelanta __blk_mq_sched_bio_merge() obtiene el ctx y el hctx para la CPU actual y pasa el hctx a ->bio_merge(). kyber_bio_merge() luego obtiene nuevamente el ctx para la CPU actual y lo usa para obtener el contexto Kyber correspondiente en el hctx pasado. Sin embargo, el hilo puede ser reemplazado entre las dos llamadas a blk_mq_get_ctx(), y es posible que el ctx devuelto la segunda vez ya no corresponda al hctx pasado. Esto "funciona" accidentalmente la mayor parte del tiempo, pero puede hacer que leamos basura si el segundo ctx proviene de un hctx con más ctx que el primero (es decir, si ctx->index_hw[hctx->type] > hctx- >nr_ctx). Esto se manifestó como este error de índice de matriz UBSAN fuera de los límites informado por Jakub: UBSAN: array-index-out-of-bounds in ../kernel/locking/qspinlock.c:130:9 index 13106 is out of range for type ' long unsigned int [128]' Seguimiento de llamadas: dump_stack+0xa4/0xe5 ubsan_epilogue+0x5/0x40 __ubsan_handle_out_of_bounds.cold.13+0x2a/0x34 queued_spin_lock_slowpath+0x476/0x480 do_raw_spin_lock+0x1c2/0x1d0 kyber_bio_ fusionar+0x112/0x180 blk_mq_submit_bio+0x1f5/0x1100 submit_bio_noacct +0x7b0/0x870 submit_bio+0xc2/0x3a0 btrfs_map_bio+0x4f0/0x9d0 btrfs_submit_data_bio+0x24e/0x310 submit_one_bio+0x7f/0xb0 submit_extent_page+0xc4/0x440 __extent_writepage_io+0x2b8/0x5e0 __ extensión_writepage+0x28d/0x6e0 extensión_write_cache_pages+0x4d7/0x7a0 extensión_writepages+0xa2/0x110 do_writepages +0x8f/0x180 __writeback_single_inode+0x99/0x7f0 writeback_sb_inodes+0x34e/0x790 __writeback_inodes_wb+0x9e/0x120 wb_writeback+0x4d2/0x660 wb_workfn+0x64d/0xa10 Process_one_work+0x53a/0xa80 work_thread+0x69/0x5b0 kthread+0x20b/0x240 ret_from_fork+0x1f/0x30 solamente Kyber usa hctx, así que solucionelo pasando request_queue a ->bio_merge() en su lugar. BFQ y mq-deadline simplemente usan eso, y Kyber puede mapear las colas él mismo para evitar discrepancias.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: ACPI: scan: Corregir pérdida de memoria en una ruta de manejo de errores Si falla 'acpi_device_set_name()' debemos liberar 'acpi_device_bus_id->bus_id' o hay una (potencial) memoria filtración.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: usb: dwc3: gadget: estructura de gadget libre solo después de liberar los puntos finales. Como parte de el commit e81a7018d93a ("usb: dwc3: asignar estructura de gadget dinámicamente"), se agregó dwc3_gadget_release() que libere la estructura dwc->gadget al retirar el dispositivo cuando se llama a usb_del_gadget_udc() en dwc3_gadget_exit(). Sin embargo, simplemente liberar el gadget da como resultado una situación de puntero colgante: los puntos finales creados en dwc3_gadget_init_endpoints() tienen sus miembros dep->endpoint.ep_list encadenados fuera del list_head anclado en dwc->gadget->ep_list. Por lo tanto, cuando se libera dwc->gadget, el primer dwc3_ep de la lista ahora tiene un puntero anterior colgante y lo mismo ocurre con el siguiente puntero de dwc3_ep al final de la lista. El dwc3_gadget_free_endpoints() que sigue dará como resultado un use-after-free cuando llame a list_del(). Esto se detectó habilitando KASAN y realizando una desvinculación del controlador. La reciente confirmación 568262bf5492 ("usb: dwc3: core: Add Shutdown Callback for dwc3") también expone esto como un pánico durante el apagado. Hay algunas posibilidades para solucionar este problema. Una podría ser realizar un list_del() del propio gadget->ep_list que lo elimine del resto de la cadena dwc3_ep. Otro enfoque es lo que hace este parche, al dividir la llamada usb_del_gadget_udc() en sus componentes separados "del" y "put". Esto permite llamar a dwc3_gadget_free_endpoints() antes de que el gadget se libere finalmente con usb_put_gadget().