Page 351 of 2293 results (0.018 seconds)

CVSS: -EPSS: 0%CPEs: 7EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: crypto: xilinx - call finalize with bh disabled When calling crypto_finalize_request, BH should be disabled to avoid triggering the following calltrace: ------------[ cut here ]------------ WARNING: CPU: 2 PID: 74 at crypto/crypto_engine.c:58 crypto_finalize_request+0xa0/0x118 Modules linked in: cryptodev(O) CPU: 2 PID: 74 Comm: firmware:zynqmp Tainted: G O 6.8.0-rc1-yocto-standard #323 Hardware name: ZynqMP ZCU102 Rev1.0 (DT) pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : crypto_finalize_request+0xa0/0x118 lr : crypto_finalize_request+0x104/0x118 sp : ffffffc085353ce0 x29: ffffffc085353ce0 x28: 0000000000000000 x27: ffffff8808ea8688 x26: ffffffc081715038 x25: 0000000000000000 x24: ffffff880100db00 x23: ffffff880100da80 x22: 0000000000000000 x21: 0000000000000000 x20: ffffff8805b14000 x19: ffffff880100da80 x18: 0000000000010450 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000003 x13: 0000000000000000 x12: ffffff880100dad0 x11: 0000000000000000 x10: ffffffc0832dcd08 x9 : ffffffc0812416d8 x8 : 00000000000001f4 x7 : ffffffc0830d2830 x6 : 0000000000000001 x5 : ffffffc082091000 x4 : ffffffc082091658 x3 : 0000000000000000 x2 : ffffffc7f9653000 x1 : 0000000000000000 x0 : ffffff8802d20000 Call trace: crypto_finalize_request+0xa0/0x118 crypto_finalize_aead_request+0x18/0x30 zynqmp_handle_aes_req+0xcc/0x388 crypto_pump_work+0x168/0x2d8 kthread_worker_fn+0xfc/0x3a0 kthread+0x118/0x138 ret_from_fork+0x10/0x20 irq event stamp: 40 hardirqs last enabled at (39): [<ffffffc0812416f8>] _raw_spin_unlock_irqrestore+0x70/0xb0 hardirqs last disabled at (40): [<ffffffc08122d208>] el1_dbg+0x28/0x90 softirqs last enabled at (36): [<ffffffc080017dec>] kernel_neon_begin+0x8c/0xf0 softirqs last disabled at (34): [<ffffffc080017dc0>] kernel_neon_begin+0x60/0xf0 ---[ end trace 0000000000000000 ]--- En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: crypto: xilinx - llamada a finalizar con bh deshabilitado Al llamar a crypto_finalize_request, BH debe estar deshabilitado para evitar que se active el siguiente seguimiento de llamadas: ------------[ cut aquí ]------------ ADVERTENCIA: CPU: 2 PID: 74 en crypto/crypto_engine.c:58 crypto_finalize_request+0xa0/0x118 Módulos vinculados en: cryptodev(O) CPU: 2 PID: 74 Comm : firmware:zynqmp Contaminado: GO 6.8.0-rc1-yocto-standard #323 Nombre del hardware: ZynqMP ZCU102 Rev1.0 (DT) pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc: crypto_finalize_request+0xa0/0x118 lr: crypto_finalize_request+0x104/0x118 sp: ffffffc085353ce0 x29: ffffffc085353ce0 x28: 00000000000000000 x27: ffffff8808ea8688 x26: 15038 x25: 0000000000000000 x24: ffffff880100db00 x23: ffffff880100da80 x22: 0000000000000000 x21: 0000000000000000 x20: ffffff8805b14000 x19: ffffff880100da80 x18: 0000000000010450 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000003 x13: 0000000000000000 x12: ffffff880100dad0 x11: 0000000000000000 x10: ffffffc0832dcd08 x9 : ffffffc0812416d8 x8 : 00000000000001f4 x7 : ffffffc0830d2830 x6 : 0000000000000001 x5 : ffffffc082091000 x4 : ffffffc082091658 x3 : 0000000000000000 x2 : ffffffc7f9653000 x1: 0000000000000000 x0: ffffff8802d20000 Rastreo de llamadas: crypto_finalize_request+0xa0/0x118 crypto_finalize_aead_request+0x18/0x30 zynqmp_handle_aes_req+0xcc/0x388 crypto_pump_work+0x 168/0x2d8 kthread_worker_fn+0xfc/0x3a0 kthread+0x118/0x138 ret_from_fork+0x10/0x20 sello de evento irq: 40 hardirqs habilitado por última vez en (39): [] _raw_spin_unlock_irqrestore+0x70/0xb0 hardirqs habilitado por última vez en (40): [] el1_dbg+0x28/0x90 softirqs habilitado por última vez en (36): [] _comenzar +0x8c/0xf0 softirqs se deshabilitó por última vez en (34): [] kernel_neon_begin+0x60/0xf0 ---[ final de seguimiento 0000000000000000 ]--- • https://git.kernel.org/stable/c/4d96f7d48131fefe30d7c1d1e2a23ef37164dbf5 https://git.kernel.org/stable/c/8a01335aedc50a66d04dd39203c89f4bc8042596 https://git.kernel.org/stable/c/03e6d4e948432a61b35783323b6ab2be071d2619 https://git.kernel.org/stable/c/a71f66bd5f7b9b35a8aaa49e29565eca66299399 https://git.kernel.org/stable/c/23bc89fdce71124cd2126fc919c7076e7cb489cf https://git.kernel.org/stable/c/9db89b1fb85557892e6681724b367287de5f9f20 https://git.kernel.org/stable/c/dbf291d8ffffb70f48286176a15c6c54f0bb0743 https://git.kernel.org/stable/c/a853450bf4c752e664abab0b2fad395b7 •

CVSS: -EPSS: 0%CPEs: 3EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: drm/bridge: adv7511: fix crash on irq during probe Moved IRQ registration down to end of adv7511_probe(). If an IRQ already is pending during adv7511_probe (before adv7511_cec_init) then cec_received_msg_ts could crash using uninitialized data: Unable to handle kernel read from unreadable memory at virtual address 00000000000003d5 Internal error: Oops: 96000004 [#1] PREEMPT_RT SMP Call trace: cec_received_msg_ts+0x48/0x990 [cec] adv7511_cec_irq_process+0x1cc/0x308 [adv7511] adv7511_irq_process+0xd8/0x120 [adv7511] adv7511_irq_handler+0x1c/0x30 [adv7511] irq_thread_fn+0x30/0xa0 irq_thread+0x14c/0x238 kthread+0x190/0x1a8 En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/bridge: adv7511: corrige el fallo en irq durante la sonda Se movió el registro de IRQ al final de adv7511_probe(). Si ya hay una IRQ pendiente durante adv7511_probe (antes de adv7511_cec_init), entonces cec_received_msg_ts podría fallar usando datos no inicializados: No se puede manejar la lectura del kernel desde memoria ilegible en la dirección virtual 00000000000003d5 Error interno: Ups: 96000004 [#1] PREEMPT_RT SMP Seguimiento de llamadas: _ts+0x48 /0x990 [cec] adv7511_cec_irq_process+0x1cc/0x308 [adv7511] adv7511_irq_process+0xd8/0x120 [adv7511] adv7511_irq_handler+0x1c/0x30 [adv7511] irq_thread_fn+0x30/0xa0 leer+0x14c/0x238 khilo+0x190/0x1a8 • https://git.kernel.org/stable/c/3b1b975003e4a3da4b93ab032487a3ae4afca7b5 https://git.kernel.org/stable/c/955c1252930677762e0db2b6b9e36938c887445c https://git.kernel.org/stable/c/28a94271bd50e4cf498df0381f776f8ea40a289e https://git.kernel.org/stable/c/aeedaee5ef5468caf59e2bb1265c2116e0c9a924 •

CVSS: 6.4EPSS: 0%CPEs: 9EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: media: pvrusb2: fix uaf in pvr2_context_set_notify [Syzbot reported] BUG: KASAN: slab-use-after-free in pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35 Read of size 4 at addr ffff888113aeb0d8 by task kworker/1:1/26 CPU: 1 PID: 26 Comm: kworker/1:1 Not tainted 6.8.0-rc1-syzkaller-00046-gf1a27f081c1f #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 Workqueue: usb_hub_wq hub_event Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc4/0x620 mm/kasan/report.c:488 kasan_report+0xda/0x110 mm/kasan/report.c:601 pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35 pvr2_context_notify drivers/media/usb/pvrusb2/pvrusb2-context.c:95 [inline] pvr2_context_disconnect+0x94/0xb0 drivers/media/usb/pvrusb2/pvrusb2-context.c:272 Freed by task 906: kasan_save_stack+0x33/0x50 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640 poison_slab_object mm/kasan/common.c:241 [inline] __kasan_slab_free+0x106/0x1b0 mm/kasan/common.c:257 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2121 [inline] slab_free mm/slub.c:4299 [inline] kfree+0x105/0x340 mm/slub.c:4409 pvr2_context_check drivers/media/usb/pvrusb2/pvrusb2-context.c:137 [inline] pvr2_context_thread_func+0x69d/0x960 drivers/media/usb/pvrusb2/pvrusb2-context.c:158 [Analyze] Task A set disconnect_flag = !0, which resulted in Task B's condition being met and releasing mp, leading to this issue. [Fix] Place the disconnect_flag assignment operation after all code in pvr2_context_disconnect() to avoid this issue. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: pvrusb2: corrige uaf en pvr2_context_set_notify [Syzbot informó] ERROR: KASAN: slab-use-after-free en pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2 -context.c:35 Lectura del tamaño 4 en la dirección ffff888113aeb0d8 por tarea kworker/1:1/26 CPU: 1 PID: 26 Comm: kworker/1:1 No contaminado 6.8.0-rc1-syzkaller-00046-gf1a27f081c1f #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 25/01/2024 Cola de trabajo: usb_hub_wq hub_event Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c :106 print_address_description mm/kasan/report.c:377 [en línea] print_report+0xc4/0x620 mm/kasan/report.c:488 kasan_report+0xda/0x110 mm/kasan/report.c:601 pvr2_context_set_notify+0x2c4/0x310 controladores/ media/usb/pvrusb2/pvrusb2-context.c:35 pvr2_context_notify controladores/media/usb/pvrusb2/pvrusb2-context.c:95 [en línea] pvr2_context_disconnect+0x94/0xb0 controladores/media/usb/pvrusb2/pvrusb2-context.c :272 Liberado por la tarea 906: kasan_save_stack+0x33/0x50 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640 veneno_slab_object mm/kasan/common.c:241 [en línea] __kasan_slab_free+0x106/0x1b0 mm/kasan/common.c:257 kasan_slab_free include/linux/kasan.h:184 [en línea] slab_free_hook mm/slub.c:2121 [en línea] slab_free mm/slub.c:4299 [en línea] kfree+0x105/0x340 mm/slub.c:4409 pvr2_context_check drivers/media/usb/pvrusb2/pvrusb2-context.c:137 [en línea] pvr2_context_thread_func+0x69d/0x960 controladores/medios /usb/pvrusb2/pvrusb2-context.c:158 [Analizar] La tarea A estableció desconectar_flag = !0, lo que resultó en que se cumpliera la condición de la tarea B y se liberara mp, lo que generó este problema. [Solución] Coloque la operación de asignaciónconnect_flag después de todo el código en pvr2_context_disconnect() para evitar este problema. • https://git.kernel.org/stable/c/e5be15c63804e05b5a94197524023702a259e308 https://git.kernel.org/stable/c/ed8000e1e8e9684ab6c30cf2b526c0cea039929c https://git.kernel.org/stable/c/d29ed08964cec8b9729bc55c7bb23f679d7a18fb https://git.kernel.org/stable/c/ab896d93fd6a2cd1afeb034c3cc9226cb499209f https://git.kernel.org/stable/c/eb6e9dce979c08210ff7249e5e0eceb8991bfcd7 https://git.kernel.org/stable/c/3a1ec89708d2e57e2712f46241282961b1a7a475 https://git.kernel.org/stable/c/8e60b99f6b7ccb3badeb512f5eb613ad45904592 https://git.kernel.org/stable/c/40cd818fae875c424a8335009db33c7b5 • CWE-416: Use After Free •

CVSS: -EPSS: 0%CPEs: 9EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: Fix a null pointer crash in mtk_drm_crtc_finish_page_flip It's possible that mtk_crtc->event is NULL in mtk_drm_crtc_finish_page_flip(). pending_needs_vblank value is set by mtk_crtc->event, but in mtk_drm_crtc_atomic_flush(), it's is not guarded by the same lock in mtk_drm_finish_page_flip(), thus a race condition happens. Consider the following case: CPU1 CPU2 step 1: mtk_drm_crtc_atomic_begin() mtk_crtc->event is not null, step 1: mtk_drm_crtc_atomic_flush: mtk_drm_crtc_update_config( !!mtk_crtc->event) step 2: mtk_crtc_ddp_irq -> mtk_drm_finish_page_flip: lock mtk_crtc->event set to null, pending_needs_vblank set to false unlock pending_needs_vblank set to true, step 2: mtk_crtc_ddp_irq -> mtk_drm_finish_page_flip called again, pending_needs_vblank is still true //null pointer Instead of guarding the entire mtk_drm_crtc_atomic_flush(), it's more efficient to just check if mtk_crtc->event is null before use. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/mediatek: corrige un fallo del puntero nulo en mtk_drm_crtc_finish_page_flip Es posible que mtk_crtc-&gt;event sea NULL en mtk_drm_crtc_finish_page_flip(). El valor pendiente_needs_vblank lo establece mtk_crtc-&gt;event, pero en mtk_drm_crtc_atomic_flush(), no está protegido por el mismo bloqueo en mtk_drm_finish_page_flip(), por lo que ocurre una condición de carrera. Considere el siguiente caso: CPU1 CPU2 paso 1: mtk_drm_crtc_atomic_begin() mtk_crtc-&gt;event is not null, paso 1: mtk_drm_crtc_atomic_flush: mtk_drm_crtc_update_config( !! • https://git.kernel.org/stable/c/119f5173628aa7a0c3cf9db83460d40709e8241d https://git.kernel.org/stable/c/accdac6b71d5a2b84040c3d2234f53a60edc398e https://git.kernel.org/stable/c/dfde84cc6c589f2a9f820f12426d97365670b731 https://git.kernel.org/stable/c/4688be96d20ffa49d2186523ee84f475f316fd49 https://git.kernel.org/stable/c/9beec711a17245b853d64488fd5b739031612340 https://git.kernel.org/stable/c/d2bd30c710475b2e29288827d2c91f9e6e2b91d7 https://git.kernel.org/stable/c/a3dd12b64ae8373a41a216a0b621df224210860a https://git.kernel.org/stable/c/9acee29a38b4d4b70f1f583e5ef9a245d •

CVSS: -EPSS: 0%CPEs: 3EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: scsi: hisi_sas: Fix a deadlock issue related to automatic dump If we issue a disabling PHY command, the device attached with it will go offline, if a 2 bit ECC error occurs at the same time, a hung task may be found: [ 4613.652388] INFO: task kworker/u256:0:165233 blocked for more than 120 seconds. [ 4613.666297] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 4613.674809] task:kworker/u256:0 state:D stack: 0 pid:165233 ppid: 2 flags:0x00000208 [ 4613.683959] Workqueue: 0000:74:02.0_disco_q sas_revalidate_domain [libsas] [ 4613.691518] Call trace: [ 4613.694678] __switch_to+0xf8/0x17c [ 4613.698872] __schedule+0x660/0xee0 [ 4613.703063] schedule+0xac/0x240 [ 4613.706994] schedule_timeout+0x500/0x610 [ 4613.711705] __down+0x128/0x36c [ 4613.715548] down+0x240/0x2d0 [ 4613.719221] hisi_sas_internal_abort_timeout+0x1bc/0x260 [hisi_sas_main] [ 4613.726618] sas_execute_internal_abort+0x144/0x310 [libsas] [ 4613.732976] sas_execute_internal_abort_dev+0x44/0x60 [libsas] [ 4613.739504] hisi_sas_internal_task_abort_dev.isra.0+0xbc/0x1b0 [hisi_sas_main] [ 4613.747499] hisi_sas_dev_gone+0x174/0x250 [hisi_sas_main] [ 4613.753682] sas_notify_lldd_dev_gone+0xec/0x2e0 [libsas] [ 4613.759781] sas_unregister_common_dev+0x4c/0x7a0 [libsas] [ 4613.765962] sas_destruct_devices+0xb8/0x120 [libsas] [ 4613.771709] sas_do_revalidate_domain.constprop.0+0x1b8/0x31c [libsas] [ 4613.778930] sas_revalidate_domain+0x60/0xa4 [libsas] [ 4613.784716] process_one_work+0x248/0x950 [ 4613.789424] worker_thread+0x318/0x934 [ 4613.793878] kthread+0x190/0x200 [ 4613.797810] ret_from_fork+0x10/0x18 [ 4613.802121] INFO: task kworker/u256:4:316722 blocked for more than 120 seconds. [ 4613.816026] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 4613.824538] task:kworker/u256:4 state:D stack: 0 pid:316722 ppid: 2 flags:0x00000208 [ 4613.833670] Workqueue: 0000:74:02.0 hisi_sas_rst_work_handler [hisi_sas_main] [ 4613.841491] Call trace: [ 4613.844647] __switch_to+0xf8/0x17c [ 4613.848852] __schedule+0x660/0xee0 [ 4613.853052] schedule+0xac/0x240 [ 4613.856984] schedule_timeout+0x500/0x610 [ 4613.861695] __down+0x128/0x36c [ 4613.865542] down+0x240/0x2d0 [ 4613.869216] hisi_sas_controller_prereset+0x58/0x1fc [hisi_sas_main] [ 4613.876324] hisi_sas_rst_work_handler+0x40/0x8c [hisi_sas_main] [ 4613.883019] process_one_work+0x248/0x950 [ 4613.887732] worker_thread+0x318/0x934 [ 4613.892204] kthread+0x190/0x200 [ 4613.896118] ret_from_fork+0x10/0x18 [ 4613.900423] INFO: task kworker/u256:1:348985 blocked for more than 121 seconds. [ 4613.914341] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 4613.922852] task:kworker/u256:1 state:D stack: 0 pid:348985 ppid: 2 flags:0x00000208 [ 4613.931984] Workqueue: 0000:74:02.0_event_q sas_port_event_worker [libsas] [ 4613.939549] Call trace: [ 4613.942702] __switch_to+0xf8/0x17c [ 4613.946892] __schedule+0x660/0xee0 [ 4613.951083] schedule+0xac/0x240 [ 4613.955015] schedule_timeout+0x500/0x610 [ 4613.959725] wait_for_common+0x200/0x610 [ 4613.964349] wait_for_completion+0x3c/0x5c [ 4613.969146] flush_workqueue+0x198/0x790 [ 4613.973776] sas_porte_broadcast_rcvd+0x1e8/0x320 [libsas] [ 4613.979960] sas_port_event_worker+0x54/0xa0 [libsas] [ 4613.985708] process_one_work+0x248/0x950 [ 4613.990420] worker_thread+0x318/0x934 [ 4613.994868] kthread+0x190/0x200 [ 4613.998800] ret_from_fork+0x10/0x18 This is because when the device goes offline, we obtain the hisi_hba semaphore and send the ABORT_DEV command to the device. However, the internal abort timed out due to the 2 bit ECC error and triggers automatic dump. In addition, since the hisi_hba semaphore has been obtained, the dump cannot be executed and the controller cannot be reset. Therefore, the deadlocks occur on the following circular dependencies ---truncated--- En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: hisi_sas: soluciona un problema de interbloqueo relacionado con el volcado automático. Si emitimos un comando de desactivación PHY, el dispositivo conectado se desconectará si se produce un error ECC de 2 bits en el Al mismo tiempo, se puede encontrar una tarea colgada: [ 4613.652388] INFORMACIÓN: tarea kworker/u256:0:165233 bloqueada durante más de 120 segundos. [4613.666297] "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" desactiva este mensaje. [ 4613.674809] tarea:kworker/u256:0 estado:D pila: 0 pid:165233 ppid: 2 banderas:0x00000208 [ 4613.683959] Cola de trabajo: 0000:74:02.0_disco_q sas_revalidate_domain [libsas] [ 4613.691518] Rastreo de llamadas: [4613.694678] __switch_to +0xf8/0x17c [ 4613.698872] __programación+0x660/0xee0 [ 4613.703063] programación+0xac/0x240 [ 4613.706994] programación_timeout+0x500/0x610 [ 4613.711705] c [ 4613.715548] abajo+0x240/0x2d0 [ 4613.719221] hisi_sas_internal_abort_timeout+0x1bc /0x260 [hisi_sas_main] [ 4613.726618] sas_execute_internal_abort+0x144/0x310 [libsas] [ 4613.732976] sas_execute_internal_abort_dev+0x44/0x60 [libsas] [ 4613.739504] _dev.isra.0+0xbc/0x1b0 [hisi_sas_main] [ 4613.747499] hisi_sas_dev_gone+0x174/0x250 [hisi_sas_main] [ 4613.753682] sas_notify_lldd_dev_gone+0xec/0x2e0 [libsas] [ 4613.759781] sas_unregister_common_dev+0x4c/0x7a0 [libsas] [ 4613.765962] sas_destruct_devices+0xb8/0x120 [libsas] [ 4613.771709] sas_do_revalidate_domain.constprop.0+0x1b8/0x31c [libsas ] [ 4613.778930] sas_revalidate_domain+0x60/0xa4 [libsas] [ 4613.784716] Process_one_work+0x248/0x950 [ 4613.789424] trabajador_thread+0x318/0x934 [ 4613.793878] 0x200 [4613.797810] ret_from_fork+0x10/0x18 [4613.802121] INFORMACIÓN: tarea kworker/u256:4:316722 bloqueado durante más de 120 segundos. [4613.816026] "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" desactiva este mensaje. [ 4613.824538] tarea:kworker/u256:4 estado:D pila: 0 pid:316722 ppid: 2 banderas:0x00000208 [ 4613.833670] Cola de trabajo: 0000:74:02.0 hisi_sas_rst_work_handler [hisi_sas_main] [ 4613.841491 ] Rastreo de llamadas: [4613.844647] __switch_to+ 0xf8/0x17c [ 4613.848852] __programación+0x660/0xee0 [ 4613.853052] programación+0xac/0x240 [ 4613.856984] programación_timeout+0x500/0x610 [ 4613.861695] c [ 4613.865542] abajo+0x240/0x2d0 [ 4613.869216] hisi_sas_controller_prereset+0x58/ 0x1fc [hisi_sas_main] [ 4613.876324] hisi_sas_rst_work_handler+0x40/0x8c [hisi_sas_main] [ 4613.883019] Process_one_work+0x248/0x950 [ 4613.887732] trabajador_thread+0x318/0x934 [ 461 3.892204] kthread+0x190/0x200 [ 4613.896118] ret_from_fork+0x10/0x18 [ 4613.900423] INFORMACIÓN: tarea kworker/u256:1:348985 bloqueada durante más de 121 segundos. [4613.914341] "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" desactiva este mensaje. [ 4613.922852] tarea:kworker/u256:1 estado:D pila: 0 pid:348985 ppid: 2 banderas:0x00000208 [ 4613.931984] Cola de trabajo: 0000:74:02.0_event_q sas_port_event_worker [libsas] [ 4613.939549] Rastreo de llamadas: [4613.942702] __switch_to +0xf8/0x17c [ 4613.946892] __schedule+0x660/0xee0 [ 4613.951083] Schedule+0xac/0x240 [ 4613.955015] Schedule_timeout+0x500/0x610 [ 4613.959725] x610 [ 4613.964349] espera_para_compleción+0x3c/0x5c [ 4613.969146] descarga_cola de trabajo+0x198 /0x790 [ 4613.973776] sas_porte_broadcast_rcvd+0x1e8/0x320 [libsas] [ 4613.979960] sas_port_event_worker+0x54/0xa0 [libsas] [ 4613.985708] Process_one_work+0x248/0x950 [ 4613.9 90420] hilo_trabajador+0x318/0x934 [ 4613.994868] kthread+0x190/0x200 [ 4613.998800 ] ret_from_fork+0x10/0x18 Esto se debe a que cuando el dispositivo se desconecta, obtenemos el semáforo hisi_hba y enviamos el comando ABORT_DEV al dispositivo. Sin embargo, el aborto interno expiró debido al error ECC de 2 bits y activa el volcado automático. • https://git.kernel.org/stable/c/2ff07b5c6fe9173e7a7de3b23f300d71ad4d8fde https://git.kernel.org/stable/c/e022dd3b875315a2d2001a512e98d1dc8c991f4a https://git.kernel.org/stable/c/85c98073ffcfe9e46abfb9c66f3364467119d563 https://git.kernel.org/stable/c/3c4f53b2c341ec6428b98cb51a89a09b025d0953 •