Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: L2CAP: Fix uaf en l2cap_connect [Syzbot informó] ERROR: KASAN: slab-use-after-free en l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949 Lectura de tamaño 8 en la dirección ffff8880241e9800 por la tarea kworker/u9:0/54 CPU: 0 UID: 0 PID: 54 Comm: kworker/u9:0 No contaminado 6.11.0-rc6-syzkaller-00268-g788220eee30d #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Cola de trabajo: hci2 hci_rx_work Seguimiento de llamadas: __dump_stack lib/dump_stack.c:93 [en línea] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:119 imprimir_dirección_descripción mm/kasan/report.c:377 [en línea] imprimir_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949 l2cap_connect_req net/bluetooth/l2cap_core.c:4080 [en línea] l2cap_bredr_sig_cmd net/bluetooth/l2cap_core.c:4772 [en línea] l2cap_sig_channel net/bluetooth/l2cap_core.c:5543 [en línea] l2cap_recv_frame+0xf0b/0x8eb0 net/bluetooth/l2cap_core.c:6825 l2cap_recv_acldata+0x9b4/0xb70 net/bluetooth/l2cap_core.c:7514 hci_acldata_packet net/bluetooth/hci_core.c:3791 [en línea] hci_rx_work+0xaab/0x1610 net/bluetooth/hci_core.c:4028 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [en línea] worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 ... Liberado por la tarea 5245: kasan_save_stack+0x33/0x60 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:579 poison_slab_object+0xf7/0x160 mm/kasan/common.c:240 __kasan_slab_free+0x32/0x50 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [en línea] slab_free_hook mm/slub.c:2256 [en línea] slab_free mm/slub.c:4477 [en línea] kfree+0x12a/0x3b0 mm/slub.c:4598 l2cap_conn_free net/bluetooth/l2cap_core.c:1810 [en línea] kref_put include/linux/kref.h:65 [en línea] l2cap_conn_put net/bluetooth/l2cap_core.c:1822 [en línea] l2cap_conn_del+0x59d/0x730 net/bluetooth/l2cap_core.c:1802 l2cap_connect_cfm+0x9e6/0xf80 red/bluetooth/l2cap_core.c:7241 hci_connect_cfm include/red/bluetooth/hci_core.h:1960 [en línea] hci_conn_failed+0x1c3/0x370 red/bluetooth/hci_conn.c:1265 hci_abort_conn_sync+0x75a/0xb50 red/bluetooth/hci_sync.c:5583 abort_conn_sync+0x197/0x360 red/bluetooth/hci_conn.c:2917 hci_cmd_sync_work+0x1a4/0x410 red/bluetooth/hci_sync.c:328 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [en línea] worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nf_tables: prevent nf_skb_duplicated democracy syzbot encontró que nf_dup_ipv4() o nf_dup_ipv6() podrían escribir la variable por CPU nf_skb_duplicated de una manera insegura [1]. Deshabilitar la preempción como lo sugiere el splat no es suficiente, también tenemos que deshabilitar las interrupciones suaves. [1] ERROR: uso de __this_cpu_write() en código preemptible [00000000]: syz.4.282/6316 el llamador es nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 CPU: 0 UID: 0 PID: 6316 Comm: syz.4.282 No contaminado 6.11.0-rc7-syzkaller-00104-g7052622fccb1 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:93 [en línea] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 check_preemption_disabled+0x10e/0x120 lib/smp_processor_id.c:49 nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 nft_dup_ipv4_eval+0x1db/0x300 net/ipv4/netfilter/nft_dup_ipv4.c:30 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [en línea] nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288 nft_do_chain_ipv4+0x202/0x320 net/netfilter/nft_chain_filter.c:23 nf_hook_entry_hookfn incluye/linux/netfilter.h:154 [en línea] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook+0x2c4/0x450 incluye/linux/netfilter.h:269 NF_HOOK_COND incluye/linux/netfilter.h:302 [en línea] ip_output+0x185/0x230 net/ipv4/ip_output.c:433 ip_local_out net/ipv4/ip_output.c:129 [en línea] ip_send_skb+0x74/0x100 net/ipv4/ip_output.c:1495 udp_send_skb+0xacf/0x1650 net/ipv4/udp.c:981 udp_sendmsg+0x1c21/0x2a60 net/ipv4/udp.c:1269 sock_sendmsg_nosec net/socket.c:730 [en línea] __sock_sendmsg+0x1a6/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597 ___sys_sendmsg net/socket.c:2651 [en línea] __sys_sendmmsg+0x3b2/0x740 net/socket.c:2737 __do_sys_sendmmsg net/socket.c:2766 [en línea] __se_sys_sendmmsg net/socket.c:2763 [en línea] __x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2763 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f4ce4f7def9 Código: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f4ce5d4a038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133 RAX: ffffffffffffffda RBX: 00007f4ce5135f80 RCX: 00007f4ce4f7def9 RDX: 00000000000000001 RSI: 0000000020005d40 RDI: 0000000000000006 RBP: 00007f4ce4ff0b76 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f4ce5135f80 R15: 00007ffd4cbc6d68

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: static_call: Reemplazar WARN_ON() sin sentido en static_call_module_notify() static_call_module_notify() activa un WARN_ON() cuando la asignación de memoria fallo en __static_call_add_module(). Esto no está realmente justificado, porque el caso de fallo debe ser manejado correctamente por la cadena de llamadas conocida y el código de error se pasa a la aplicación de espacio de usuario que la inicia. Un error en la asignación de memoria no es un problema fatal, pero WARN_ON() deja fuera de servicio la máquina cuando se establece panic_on_warn. Reemplázalo con un pr_warn().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ACPI: batería: se corrige un posible fallo al anular el registro de un gancho de batería Cuando un gancho de batería devuelve un error al añadir una batería nueva, el gancho de batería se anula automáticamente el registro. Sin embargo, el proveedor del gancho de batería no puede saberlo, por lo que más tarde llamará a battery_hook_unregister() en el gancho de batería ya anulado, lo que provocará un fallo. Solucione esto utilizando el encabezado de lista para marcar los ganchos de batería ya anulados como ya anulados para que battery_hook_unregister() pueda ignorarlos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ocfs2: se corrige el error null-ptr-deref cuando falla la carga del diario. Durante el proceso de montaje, si journal_reset() falla debido a que el diario es demasiado corto, entonces provoca que jbd2_journal_load() falle con j_sb_buffer NULL. Posteriormente, ocfs2_journal_shutdown() llama a jbd2_journal_flush()->jbd2_cleanup_journal_tail()-> __jbd2_update_log_tail()->jbd2_journal_update_sb_log_tail() ->lock_buffer(journal->j_sb_buffer), lo que da como resultado un error de desreferencia de puntero nulo. Para resolver este problema, debemos verificar el indicador JBD2_LOADED para asegurarnos de que el diario se cargó correctamente. Además, use journal en lugar de osb->journal directamente para simplificar el código.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath12k: arreglo de acceso fuera de los límites a la matriz en las estadísticas de SoC Actualmente, la matriz ath12k_soc_dp_stats::hal_reo_error está definida con un tamaño máximo de DP_REO_DST_RING_MAX. Sin embargo, la función ath12k_dp_rx_process() accede a ath12k_soc_dp_stats::hal_reo_error utilizando el ID de anillo SRNG de destino REO, lo cual es incorrecto. El ID de anillo SRNG difiere del ID de anillo normal, y este uso conduce a un acceso a la matriz fuera de los límites. Para solucionar este problema, modifique ath12k_dp_rx_process() para utilizar el ID de anillo normal directamente en lugar del ID de anillo SRNG para evitar el acceso a la matriz fuera de los límites. Probado en: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: no leer con anticipación el inodo de reubicación en RST En la reubicación, hacemos lectura anticipada en el inodo de reubicación, pero si el sistema de archivos está respaldado por un árbol de bandas RAID, podemos obtener ENOENT (por ejemplo, debido a que las extensiones preasignadas no se asignan en el RST) a partir de la búsqueda. Pero readahead no maneja el error y envía lecturas no válidas al dispositivo, lo que causa una afirmación en el código de la lista scatter-gather: BTRFS info (device nvme1n1): balance: start -d -m -s BTRFS info (device nvme1n1): relocating block group 6480920576 flags data|raid0 BTRFS error (device nvme1n1): cannot find raid-stripe for logical [6481928192, 6481969152] devid 2, profile raid0 ------------[ cortar aquí ]------------ ¡ERROR del kernel en include/linux/scatterlist.h:115! Ups: código de operación no válido: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 1012 Comm: btrfs No contaminado 6.10.0-rc7+ #567 RIP: 0010:__blk_rq_map_sg+0x339/0x4a0 RSP: 0018:ffffc90001a43820 EFLAGS: 00010202 RAX: 000000000000000 RBX: 000000000000000 RCX: ffffea00045d4802 RDX: 0000000117520000 RSI: 0000000000000000 RDI: ffff8881027d1000 RBP: 0000000000003000 R08: ffffea00045d4902 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000001000 R12: ffff8881003d10b8 R13: ffffc90001a438f0 R14: 000000000000000 R15: 0000000000003000 FS: 00007fcc048a6900(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000002cd11000 CR3: 00000001109ea001 CR4: 0000000000370eb0 Seguimiento de llamadas: ? __die_body.cold+0x14/0x25 ? die+0x2e/0x50 ? do_trap+0xca/0x110 ? do_error_trap+0x65/0x80 ? __blk_rq_map_sg+0x339/0x4a0 ? exc_invalid_op+0x50/0x70 ? __blk_rq_map_sg+0x339/0x4a0 ? asm_exc_invalid_op+0x1a/0x20 ? __blk_rq_map_sg+0x339/0x4a0 nvme_prep_rq.part.0+0x9d/0x770 nvme_queue_rq+0x7d/0x1e0 __blk_mq_issue_directly+0x2a/0x90 ? blk_mq_get_budget_and_tag+0x61/0x90 blk_mq_try_issue_list_directly+0x56/0xf0 blk_mq_flush_plug_list.part.0+0x52b/0x5d0 __blk_flush_plug+0xc6/0x110 blk_finish_plug+0x28/0x40 read_pages+0x160/0x1c0 page_cache_ra_unbounded+0x109/0x180 relocate_file_extent_cluster+0x611/0x6a0 ? btrfs_search_slot+0xba4/0xd20 ? balance_dirty_pages_ratelimited_flags+0x26/0xb00 relocate_data_extent.constprop.0+0x134/0x160 relocate_block_group+0x3f2/0x500 btrfs_relocate_block_group+0x250/0x430 btrfs_relocate_chunk+0x3f/0x130 btrfs_balance+0x71b/0xef0 ? kmalloc_trace_noprof+0x13b/0x280 btrfs_ioctl+0x2c2e/0x3030 ? kvfree_call_rcu+0x1e6/0x340 ? list_lru_add_obj+0x66/0x80 ? mntput_no_expire+0x3a/0x220 __x64_sys_ioctl+0x96/0xc0 do_syscall_64+0x54/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fcc04514f9b Código: No se puede acceder a los bytes del código de operación en 0x7fcc04514f71. RSP: 002b:00007ffeba923370 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fcc04514f9b RDX: 00007ffeba923460 RSI: 00000000c4009420 RDI: 0000000000000003 RBP: 000000000000000 R08: 0000000000000013 R09: 0000000000000001 R10: 00007fcc043fbba8 R11: 0000000000000246 R12: 00007ffeba924fc5 R13: 00007ffeba923460 R14: 0000000000000002 R15: 00000000004d4bb0 Módulos vinculados en: ---[ fin del seguimiento 000000000000000 ]--- RIP: 0010:__blk_rq_map_sg+0x339/0x4a0 RSP: 0018:ffffc90001a43820 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffea00045d4802 RDX: 0000000117520000 RSI: 0000000000000000 RDI: ffff8881027d1000 RBP: 0000000000003000 R08: ffffea00045d4902 R09: 0000000000000000 R10: 0000000000000000 R11: 00000000000001000 R12: ffff8881003d10b8 R13: ffffc90001a438f0 R14: 0000000000000000 R15: 0000000000003000 FS: 00007fcc048a6900(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcc04514f71 CR3: 00000001109ea001 CR4: 0000000000370eb0 Núcleo p ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: l2tp: evitar un posible desbordamiento del recuento de referencias del túnel Cuando se crea una sesión, establece un puntero hacia atrás a su túnel. Cuando el recuento de referencias de la sesión cae a 0, l2tp_session_free descarta el recuento de referencias del túnel si session->tunnel no es NULL. Sin embargo, session->tunnel se establece en l2tp_session_create, antes de que el recuento de referencias del túnel se incremente mediante l2tp_session_register, lo que deja una pequeña ventana donde session->tunnel no es NULL cuando el recuento de referencias del túnel no se ha incrementado. Mover la asignación a l2tp_session_register es trivial, pero l2tp_session_create llama a l2tp_session_set_header_len, que usa session->tunnel para obtener el encap del túnel. Agregue un argumento de encap a l2tp_session_set_header_len para evitar usar session->tunnel. Si las sesiones l2tpv3 tienen identificadores en conflicto, es posible que l2tp_v3_session_get compita con l2tp_session_register y obtenga una sesión que aún no tenga configurado session->tunnel. Agregue una verificación para este caso.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gpiolib: Corrige la posible desreferencia de puntero NULL en gpiod_get_label() En `gpiod_get_label()`, es posible que `srcu_dereference_check()` pueda devolver un puntero NULL, lo que lleva a un escenario en el que se accede a `label->str` sin verificar si `label` en sí es NULL. Este parche agrega una comprobación NULL adecuada para `label` antes de acceder a `label->str`. La comprobación para `label->str != NULL` se elimina porque `label->str` nunca puede ser NULL si `label` no es NULL. Esto corrige el problema en el que el nombre de la etiqueta se imprimía como `(efault)` al volcar el archivo GPIO de sysfs cuando `label == NULL`.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe: Impedir el acceso a puntero nulo en xe_migrate_copy xe_migrate_copy está diseñado para copiar el contenido de los recursos de TTM. Cuando el recurso de origen es nulo, activará una desreferencia de puntero NULL en xe_migrate_copy. Para evitar esta situación, actualice el indicador de origen a verdadero para este caso; el indicador activará xe_migrate_clear en lugar de xe_migrate_copy. Rastreo de problemas: <7> [317.089847] xe 0000:00:02.0: [drm:xe_migrate_copy [xe]] Paso 14, tamaños: 4194304 y 4194304 <7> [317.089945] xe 0000:00:02.0: [drm:xe_migrate_copy [xe]] Paso 15, tamaños: 4194304 y 4194304 <1> [317.128055] ERROR: desreferencia de puntero NULL del núcleo, dirección: 0000000000000010 <1> [317.128064] #PF: acceso de lectura del supervisor en modo núcleo <1> [317.128066] #PF: error_code(0x0000) - no presente página <6> [317.128069] PGD 0 P4D 0 <4> [317.128071] Ups: Ups: 0000 [#1] PREEMPT SMP NOPTI <4> [317.128074] CPU: 1 UID: 0 PID: 1440 Comm: kunit_try_catch Contaminado: G U N 6.11.0-rc7-xe #1 <4> [317.128078] Contaminado: [U]=USUARIO, [N]=PRUEBA <4> [317.128080] Nombre del hardware: Intel Corporation Lunar Lake Client Platform/LNL-M LP5 RVP1, BIOS LNLMFWI1.R00.3221.D80.2407291239 29/07/2024 <4> [317.128082] RIP: 0010:xe_migrate_copy+0x66/0x13e0 [xe] <4> [317.128158] Código: 00 00 48 89 8d e0 fe ff ff 48 8b 40 10 4c 89 85 c8 fe ff ff 44 88 8d bd fe ff ff 65 48 8b 3c 25 28 00 00 00 48 89 7d d0 31 ff <8b> 79 10 48 89 85 a0 fe ff ff 48 8b 00 48 89 b5 d8 fe ff ff 83 ff <4> [317.128162] RSP: 0018:ffffc9000167f9f0 EFLAGS: 00010246 <4> [317.128164] RAX: ffff8881120d8028 RBX: ffff88814d070428 RCX: 0000000000000000 <4> [317.128166] X: ffff88813cb99c00 RSI: 0000000004000000 RDI: 0000000000000000 <4> [317.128168] RBP: ffffc9000167fbb8 R08: ffff88814e7b1f08 R09: 00000000000000001 <4> [317.128170] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88814e7b1f08 <4> [317.128172] R13: ffff88814e7b1f08 R14: ffff88813cb99c00 R15: 0000000000000001 <4> [317.128174] FS: 0000000000000000(0000) GS:ffff88846f280000(0000) knlGS:0000000000000000 <4> [317.128176] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4> [317.128178] CR2: 000000000000010 CR3: 000000011f676004 CR4: 0000000000770ef0 <4> [317.128180] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 <4> [317.128182] DR3: knlGS:0000000000000000 <4> [317.128176] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4> [317.128178] CR2: 0000000000000010 CR3: 000000011f676004 CR4: 0000000000770ef0 <4> [317.128180] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 <4> [317.128182] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: 0000000000000400 <4> [317.128184] PKRU: 55555554 <4> [317.128185] Seguimiento de llamadas: <4> [317.128187] <4> [317.128189] ? show_regs+0x67/0x70 <4> [317.128194] ? __die_body+0x20/0x70 <4> [317.128196] ? __die+0x2b/0x40 <4> [317.128198] ? page_fault_oops+0x15f/0x4e0 <4> [317.128203] ? do_user_addr_fault+0x3fb/0x970 <4> [317.128205] ? lock_acquire+0xc7/0x2e0 <4> [317.128209]? exc_page_fault+0x87/0x2b0 <4> [317.128212] ? asm_exc_page_fault+0x27/0x30 <4> [317.128216] ? xe_migrate_copy+0x66/0x13e0 [xe] <4> [317.128263] ? __lock_acquire+0xb9d/0x26f0 <4> [317.128265] ? __lock_acquire+0xb9d/0x26f0 <4> [317.128267] ? sg_free_append_table+0x20/0x80 <4> [317.128271] ? lock_acquire+0xc7/0x2e0 <4> [317.128273] ? mark_held_locks+0x4d/0x80 <4> [317.128275] ? trace_hardirqs_on+0x1e/0xd0 <4> [317.128278] ? __pm_runtime_resume+0x60/0xa0 <4> [317.128284] xe_bo_move+0x682/0xc50 [xe] <4> [317.128315] ? lock_is_held_type+0xaa/0x120 <4> [317.128318] ttm_bo_handle_move_mem+0xe5/0x1a0 [ttm] <4> [317.128324] ttm_bo_validate+0xd1/0x1a0 [ttm] <4> [317.128328] +0x721/0xc10 [xe] <4> [317.128360] ? find_held_lock+0x31/0x90 <4> [317.128363] ? lock_release+0xd1/0x2a0 <4> [317.128365] ? __pfx_kunit_generic_run_threadfn_adapter+0x10/0x10 [kunit] <4> [317.128370] xe_bo_shrink_kunit+0x11/0x20 [xe] <4> [317.128397] kunit_try_run_case+0x6e/0x150 [kunit]---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe/guc_submit: agregar bloqueo faltante en wedged_fini Cualquier cola no en cuña puede tener un recuento de referencias cero aquí y puede ejecutarse simultáneamente con una destrucción de cola asincrónica, por lo tanto, desreferenciar el ptr de la cola para verificar el estado de cuña después de la búsqueda puede activar UAF si la cola no está en cuña. Solucione esto manteniendo el bloqueo submission_state en torno a la verificación para posponer la liberación y hacer que la verificación sea segura, antes de volver a soltarlo en torno a put() para evitar el punto muerto. (seleccionado de el commit d28af0b6b9580b9f90c265a7da0315b0ad20bbfd)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs/inode: Evitar que dump_mapping() acceda a dentry.d_name.name no válido Se observa que se produce un bloqueo durante la eliminación activa de un dispositivo de memoria, en el que el usuario está accediendo a hugetlb. Consulte el seguimiento de llamadas de la siguiente manera: ------------[ cortar aquí ]------------ ADVERTENCIA: CPU: 1 PID: 14045 en arch/x86/mm/fault.c:1278 do_user_addr_fault+0x2a0/0x790 Módulos vinculados en: kmem device_dax cxl_mem cxl_pmem cxl_port cxl_pci dax_hmem dax_pmem nd_pmem cxl_acpi nd_btt cxl_core crc32c_intel nvme virtiofs fuse nvme_core nfit libnvdimm dm_multipath scsi_dh_rdac scsi_dh_emc s mirror dm_region_hash dm_log dm_mod CPU: 1 PID: 14045 Comm: daxctl No contaminado 6.10.0-rc2-lizhijian+ #492 Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 01/04/2014 RIP: 0010:do_user_addr_fault+0x2a0/0x790 Código: 48 8b 00 a8 04 0f 84 b5 fe ff ff e9 1c ff ff ff 4c 89 e9 4c 89 e2 be 01 00 00 00 bf 02 00 00 00 e8 b5 ef 24 00 e9 42 fe ff ff <0f> 0b 48 83 c4 08 4c 89 ea 48 89 ee 4c 89 e7 5b 5d 41 5c 41 5d 41 RSP: 0000:ffffc90000a575f0 EFLAGS: 00010046 RAX: ffff88800c303600 RBX: 0000000000000000 RCX: 000000000000000 RDX: 00000000000001000 RSI: ffffffff82504162 RDI: ffffffff824b2c36 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 00000000000000000 R11: 0000000000000000 R12: ffffc90000a57658 R13: 0000000000001000 R14: ffff88800bc2e040 R15: 000000000000000 FS: 00007f51cb57d880(0000) GS:ffff88807fd00000(0000) knlGS:000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000001000 CR3: 00000000072e2004 CR4: 00000000001706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: ? __warn+0x8d/0x190 ? do_user_addr_fault+0x2a0/0x790 ? report_bug+0x1c3/0x1d0 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? do_user_addr_fault+0x2a0/0x790 ? exc_page_fault+0x31/0x200 exc_page_fault+0x68/0x200 <...snip...> ERROR: no se puede manejar el error de página para la dirección: 0000000000001000 #PF: acceso de lectura del supervisor en modo kernel #PF: error_code(0x0000) - página no presente PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI ---[ fin del seguimiento 000000000000000 ]--- ERROR: no se puede manejar el error de página para la dirección: 0000000000001000 #PF: acceso de lectura del supervisor en modo kernel #PF: error_code(0x0000) - página no presente PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 14045 Comm: daxctl Kdump: cargado Tainted: GW 6.10.0-rc2-lizhijian+ #492 Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:dentry_name+0x1f4/0x440 <...snip...> ? dentry_name+0x2fa/0x440 vsnprintf+0x1f3/0x4f0 vprintk_store+0x23a/0x540 vprintk_emit+0x6d/0x330 _printk+0x58/0x80 dump_mapping+0x10b/0x1a0 ? __pfx_free_object_rcu+0x10/0x10 __dump_page+0x26b/0x3e0 ? vprintk_emit+0xe0/0x330 ? _printk+0x58/0x80 ? dump_page+0x17/0x50 dump_page+0x17/0x50 do_migrate_range+0x2f7/0x7f0 ? do_migrate_range+0x42/0x7f0 ? offline_pages+0x2f4/0x8c0 offline_pages+0x60a/0x8c0 memory_subsys_offline+0x9f/0x1c0 ? lockdep_hardirqs_on+0x77/0x100 ? _raw_spin_unlock_irqrestore+0x38/0x60 device_offline+0xe3/0x110 state_store+0x6e/0xc0 kernfs_fop_write_iter+0x143/0x200 vfs_write+0x39f/0x560 ksys_write+0x65/0xf0 do_syscall_64+0x62/0x130 Anteriormente, se han realizado algunas comprobaciones de cordura en dump_mapping() antes de que la función de impresión analice '%pd', aunque aún es posible encontrarse con un dentry.d_name.name no válido. Dado que dump_mapping() solo necesita volcar el nombre del archivo, recupérelo por sí mismo de una manera más segura para ----truncado---