Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: btrfs: dev-replace: validar correctamente los nombres de los dispositivos. Hay un informe de syzbot que indica que los búferes de nombres de dispositivos pasados para reemplazar el dispositivo no se verifican adecuadamente para determinar la terminación de la cadena, lo que podría provocar una lectura fuera de los límites. en getname_kernel(). Agregue un asistente que valide los búferes de nombres de dispositivos de origen y de destino. Para devid como fuente, inicialice el búfer en una cadena vacía en caso de que algo intente leerlo más tarde. Esto fue originalmente analizado y solucionado de una manera diferente por Edward Adam Davis (ver enlaces).

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: btrfs: corrige la doble liberación de un dispositivo anónimo después de un error en la creación de la instantánea. Al crear una instantánea podemos hacer una doble liberación de un dispositivo anónimo en caso de que haya un error al realizar la transacción. La segunda liberación puede resultar en la liberación de un número de dispositivo anónimo asignado por algún otro subSYSTEM en el kernel u otro SYSTEM de archivos btrfs. Los pasos que conducen a esto: 1) En ioctl.c:create_snapshot() asignamos un número de dispositivo anónimo y lo asignamos a pendiente_snapshot->anon_dev; 2) Luego llamamos a btrfs_commit_transaction() y terminamos en transaction.c:create_pending_snapshot(); 3) Allí llamamos a btrfs_get_new_fs_root() y le pasamos el número de dispositivo anónimo almacenado en pendiente_snapshot->anon_dev; 4) btrfs_get_new_fs_root() libera ese número de dispositivo anónimo porque btrfs_lookup_fs_root() devolvió una raíz; alguien más ya hizo una búsqueda de la nueva raíz, lo que podría realizar alguna tarea haciendo retroceder la referencia; 5) Después de eso, ocurre algún error en la ruta de confirmación de la transacción, y en ioctl.c:create_snapshot() saltamos a la etiqueta 'fail', y luego liberamos nuevamente el mismo número de dispositivo anónimo, que mientras tanto puede haber sido reasignado en otro lugar, porque pendiente_snapshot->anon_dev todavía tiene el mismo valor que en el paso 1. Recientemente, syzbot se encontró con esto e informó el siguiente seguimiento: ------------[ cortar aquí ]---- -------- ida_free solicitó id=51 que no está asignado. ADVERTENCIA: CPU: 1 PID: 31038 en lib/idr.c:525 ida_free+0x370/0x420 lib/idr.c:525 Módulos vinculados en: CPU: 1 PID: 31038 Comm: syz-executor.2 No contaminado 6.8.0 -rc4-syzkaller-00410-gc02197fc9076 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 25/01/2024 RIP: 0010:ida_free+0x370/0x420 lib/idr.c:525 Código: 10 42 80 3c 28 (...) RSP: 0018:ffffc90015a67300 EFLAGS: 00010246 RAX: be5130472f5dd000 RBX: 00000000000000033 RCX: 0000000000040000 RDX: ffffc90009a7a000 R SI: 000000000003ffff RDI: 0000000000040000 RBP: ffffc90015a673f0 R08: ffffffff81577992 R09: 1ffff92002b4cdb4 R10: dffffc0000000000 R11: ffff52002b4cdb5 R12: 0000000000000246 R13: dffffc0000000000 R14: ffffffff8e256b80 R15: 0000000000000246 FS: 00007fca3f4b46c0(0000) GS:ffff8880b9500000(0000) knlGS :0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f167a17b978 CR3: 000000001ed26000 CR4: 0000000000350ef0 Rastreo de llamadas: < TAREA> btrfs_get_root_ref+0xa48/0xaf0 fs/btrfs/disk-io.c:1346 create_pending_snapshot+0xff2/0x2bc0 fs/btrfs/transaction.c:1837 create_pending_snapshots+0x195/0x1d0 fs/btrfs/transaction.c:1931 btrfs_ transacción_commit+0xf1c/ 0x3740 fs/btrfs/transaction.c:2404 create_snapshot+0x507/0x880 fs/btrfs/ioctl.c:848 btrfs_mksubvol+0x5d0/0x750 fs/btrfs/ioctl.c:998 btrfs_mksnapshot+0xb5/0xf0 fs/btrfs /ioctl.c :1044 __btrfs_ioctl_snap_create+0x387/0x4b0 fs/btrfs/ioctl.c:1306 btrfs_ioctl_snap_create_v2+0x1ca/0x400 fs/btrfs/ioctl.c:1393 btrfs_ioctl+0xa74/0xd40 vfs_ioct l fs/ioctl.c:51 [en línea] __do_sys_ioctl fs/ioctl .c:871 [en línea] __se_sys_ioctl+0xfe/0x170 fs/ioctl.c:857 do_syscall_64+0xfb/0x240 Entry_SYSCALL_64_after_hwframe+0x6f/0x77 RIP: 0033:0x7fca3e67dda9 Código: 28 00 00 00 ( ...) RSP: 002b:00007fca3f4b40c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007fca3e7abf80 RCX: 00007fca3e67dda9 RDX: 00000000200005c0 RSI: 0000000050009 417 RDI: 0000000000000003 RBP: 00007fca3e6ca47a R08: 0000000000000000 R09: 00000000000000000 R10: 00000000000000000 R11: 00000000000000246 R12: 0000000000000000 R13: 000000000000000b R14: 00007fca3e7abf80 R15: 00007fff6bf95658 Donde recibimos un mensaje explícito donde intentamos liberar un número de dispositivo anónimo que no está asignado actualmente.,---truncado---

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: gtp: corrige use-after-free y null-ptr-deref en gtp_newlink() La estructura de operaciones gtp_link_ops para el subSYSTEM debe registrarse después de registrar la estructura de operaciones pernet gtp_net_ops. Syzkaller encontró el error 'fallo de protección general en gtp_genl_dump_pdp': [1010.702740] gtp: módulo GTP descargado [1010.715877] fallo de protección general, probablemente para la dirección no canónica 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI [1010.715888 ] KASAN: ptr nulo -deref en el rango [0x0000000000000008-0x000000000000000f] [ 1010.715895] CPU: 1 PID: 128616 Comm: a.out No contaminado 6.8.0-rc6-std-def-alt1 #1 [ 1010.715899] Nombre de hardware: Estándar QEMU PC (Q35+ ICH9, 2009), BIOS 1.16.0-alt1 01/04/2014 [ 1010.715908] RIP: 0010:gtp_newlink+0x4d7/0x9c0 [gtp] [ 1010.715915] Código: 80 3c 02 00 0f 85 41 04 00 0 0 48 8b bb d8 05 00 00 e8 ed f6 ff ff 48 89 c2 48 89 c5 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 4f 04 00 00 4c 89 e2 4c 8b 6d 00 4 8b8 00 00 00 [ 1010.715920] RSP: 0018:ffff888020fbf180 EFLAGS: 00010203 [ 1010.715929] RAX: dffffc0000000000 RBX: ffff88800399c000 RCX: 0000000000000 000 [ 1010.715933] RDX: 00000000000000001 RSI: ffffffff84805280 RDI: 0000000000000282 [ 1010.715938] RBP: 000000000000000d R08: 000000000000 0001 R09: 0000000000000000 [ 1010.715942] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88800399cc80 [ 1010.715947] R13: 0000000000000000 R14: 00000000000 00000 R15: 0000000000000400 [ 1010.715953] FS: 00007fd1509ab5c0(0000) GS:ffff88805b300000(0000) knlGS:0000000000000000 [ 1010.715958] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1010.715962] CR2: 0000000000000000 CR3: 000000001c07a000 CR4: 0000000000750ee0 [ 1010.715968] PKRU: 55555 554 [1010.715972] Seguimiento de llamadas: [1010.715985]? __die_body.cold+0x1a/0x1f [ 1010.715995] ? die_addr+0x43/0x70 [1010.716002]? exc_general_protection+0x199/0x2f0 [1010.716016]? asm_exc_general_protection+0x1e/0x30 [1010.716026]? gtp_newlink+0x4d7/0x9c0 [gtp] [ 1010.716034] ? gtp_net_exit+0x150/0x150 [gtp] [ 1010.716042] __rtnl_newlink+0x1063/0x1700 [ 1010.716051] ? rtnl_setlink+0x3c0/0x3c0 [1010.716063]? is_bpf_text_address+0xc0/0x1f0 [1010.716070]? kernel_text_address.part.0+0xbb/0xd0 [1010.716076]? __kernel_text_address+0x56/0xa0 [ 1010.716084] ? unwind_get_return_address+0x5a/0xa0 [1010.716091]? create_prof_cpu_mask+0x30/0x30 [1010.716098]? arch_stack_walk+0x9e/0xf0 [1010.716106]? stack_trace_save+0x91/0xd0 [1010.716113]? stack_trace_consume_entry+0x170/0x170 [1010.716121]? __lock_acquire+0x15c5/0x5380 [1010.716139]? mark_held_locks+0x9e/0xe0 [1010.716148]? ¿kmem_cache_alloc_trace+0x35f/0x3c0 [1010.716155]? __rtnl_newlink+0x1700/0x1700 [ 1010.716160] rtnl_newlink+0x69/0xa0 [ 1010.716166] rtnetlink_rcv_msg+0x43b/0xc50 [ 1010.716172] ? rtnl_fdb_dump+0x9f0/0x9f0 [1010.716179]? lock_acquire+0x1fe/0x560 [1010.716188]? netlink_deliver_tap+0x12f/0xd50 [ 1010.716196] netlink_rcv_skb+0x14d/0x440 [ 1010.716202] ? rtnl_fdb_dump+0x9f0/0x9f0 [1010.716208]? netlink_ack+0xab0/0xab0 [1010.716213]? netlink_deliver_tap+0x202/0xd50 [1010.716220]? netlink_deliver_tap+0x218/0xd50 [1010.716226]? __virt_addr_valid+0x30b/0x590 [ 1010.716233] netlink_unicast+0x54b/0x800 [ 1010.716240] ? netlink_attachskb+0x870/0x870 [1010.716248]? __check_object_size+0x2de/0x3b0 [ 1010.716254] netlink_sendmsg+0x938/0xe40 [ 1010.716261] ? netlink_unicast+0x800/0x800 [1010.716269]? __import_iovec+0x292/0x510 [ 1010.716276] ? netlink_unicast+0x800/0x800 [ 1010.716284] __sock_sendmsg+0x159/0x190 [ 1010.716290] ____sys_sendmsg+0x712/0x880 [ 1010.716297] ? sock_write_iter+0x3d0/0x3d0 [1010.716304]? __ia32_sys_recvmmsg+0x270/0x270 [1010.716309]? lock_acquire+0x1fe/0x560 [1010.716315]? Drain_array_locked+0x90/0x90 [ 1010.716324] ___sys_sendmsg+0xf8/0x170 [ 1010.716331] ? sendmsg_copy_msghdr+0x170/0x170 [1010.716337]? lockdep_init_map ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: corrige la ejecución entre la finalización de extensión ordenada y fiemap Para fiemap recientemente dejamos de bloquear el rango de extensión objetivo durante toda la duración de la llamada a fiemap, para evitar un punto muerto en un escenario donde el búfer fiemap resulta ser un rango mapeado en memoria del mismo archivo. Es muy poco probable que este caso de uso sea útil en la práctica, pero puede activarse mediante pruebas difusas (syzbot, etc.). Sin embargo, al no bloquear el rango de extensión objetivo durante toda la duración de la llamada a fiemap, podemos competir con una extensión ordenada. Esto sucede así: 1) La tarea fiemap termina de procesar un elemento de extensión de archivo que cubre el rango de archivos [512K, 1M[, y ese elemento de extensión de archivo es el último elemento de la hoja que se está procesando actualmente; 2) Y la extensión ordenada para el rango de archivos [768K, 2M[, en modo COW, se completa (btrfs_finish_one_ordered()) y el elemento de extensión de archivo que cubre el rango [512K, 1M[ se recorta para cubrir el rango [512K, 768K[ y luego se inserta un nuevo elemento de extensión de archivo para el rango [768K, 2M[ en el árbol de subvolumen del inodo; 3) La tarea fiemap llama a fiemap_next_leaf_item(), que luego llama a btrfs_next_leaf() para encontrar la siguiente hoja/elemento. Esto encuentra que la siguiente clave después de la que procesamos anteriormente (su tipo es BTRFS_EXTENT_DATA_KEY y su desplazamiento es 512K), es la clave correspondiente al nuevo elemento de extensión de archivo insertado por la extensión ordenada, que tiene un tipo de BTRFS_EXTENT_DATA_KEY y un desplazamiento de 768K; 4) Más tarde, el código fiemap termina en emit_fiemap_extent() y activa la advertencia: if (cache->offset + cache->len > offset) { WARN_ON(1); devolver -EINVAL; } Dado que obtenemos 1M > 768K, porque la entrada emitida previamente para la extensión anterior que cubre el rango de archivos [512K, 1M[ termina en un desplazamiento que es mayor que el desplazamiento inicial de la nueva extensión (768K). Esto hace que fiemap falle con -EINVAL además de activar la advertencia que produce un seguimiento de pila como el siguiente: [1621.677651] ------------[ cortar aquí ]----------- - [1621.677656] ADVERTENCIA: CPU: 1 PID: 204366 en fs/btrfs/extent_io.c:2492 emit_fiemap_extent+0x84/0x90 [btrfs] [1621.677899] Módulos vinculados en: btrfs blake2b_generic (...) [1621.677951] CPU: 1 PID: 204366 Comm: pool No contaminado 6.8.0-rc5-btrfs-next-151+ #1 [1621.677954] Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390- prebuilt.qemu.org 01/04/2014 [1621.677956] RIP: 0010:emit_fiemap_extent+0x84/0x90 [btrfs] [1621.678033] Código: 2b 4c 89 63 (...) [1621.678035] RSP: 0018:ffffab160 89ffd20 EFLAGS: 00010206 [1621.678037] RAX: 00000000004fa000 RBX: ffffab16089ffe08 RCX: 0000000000009000 [1621.678039] RDX: 00000000004f9000 RSI: 00000000004f1000 RDI : ffffab16089ffe90 [1621.678040] RBP: 00000000004f9000 R08: 0000000000001000 R09: 00000000000000000 [1621.678041] R10: 0000000000000000 R11 : 0000000000001000 R12: 0000000041d78000 [1621.678043 ] R13: 0000000000001000 R14: 00000000000000000 R15: ffff9434f0b17850 [1621.678044] FS: 00007fa6e20006c0(0000) GS:ffff943bdfa40000(0000) kn lGS:0000000000000000 [1621.678046] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [1621.678048] CR2: 00007fa6b0801000 CR3 : 000000012d404002 CR4: 0000000000370ef0 [1621.678053] DR0: 0000000000000000 DR1: 00000000000000000 DR2: 0000000000000000 [1621.678055] DR 3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [1621.678056] Seguimiento de llamadas: [1621.678074] [1621.678076] ? __advertir+0x80/0x130 [1621.678082] ? emit_fiemap_extent+0x84/0x90 [btrfs] [1621.678159] ? report_bug+0x1f4/0x200 [1621.678164] ? ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: riscv: Sparse-Memory/vmemmap fuera de los límites corrige Offset vmemmap para que la primera página de vmemmap se asigne a la primera página de la memoria física para garantizar que vmemmap Los límites se respetarán durante las operaciones pfn_to_page()/page_to_pfn(). Las macros de conversión producirán direcciones SV39/48/57 correctas para cada DRAM_BASE posible/válida dentro de los límites de la memoria física. v2: Abordar los comentarios de Alex

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: controladores: perf: ctr_get_width la función para legado no está definida Con los parámetros CONFIG_RISCV_PMU_LEGACY=y y CONFIG_RISCV_PMU_SBI=n el kernel de Linux falla cuando intenta el registro de rendimiento: $ perf record ls [ 46.749286] No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 0000000000000000 [ 46.750199] Ups [#1] [ 46.750342] Módulos vinculados en: [ 46.750608] CPU: 0 PID: 107 Comm: perf-exec Not tainted 6.6.0 #2 [ 46.750906] Nombre del hardware : riscv-virtio,qemu (DT) [ 46.751184] epc : 0x0 [ 46.751430 ] ra : arch_perf_update_userpage+0x54/0x13e [ 46.751680] epc : 00000000000000000 ra : ffffffff8072ee52 sp : ff20000 00022b8f0 [46.751958] gp: ffffffff81505988 tp: ff6000000290d400 t0: ff2000000022b9c0 [ 46.752229] t1 : 0000000000000001 t2 : 0000000000000003 s0 : ff2000000022b930 [ 46.752451] s1 : ff600000028fb000 a0 : 0000000000000000 a 1: ff600000028fb000 [46.752673] a2: 0000000ae2751268 a3: 00000000004fb708 a4: 00000000000000004 [46.752895] a5: 0000000000000000 a6: 000000000017ffe3 a7: 00000000000000d2 [46.753117] s2: ff600000028fb000 s3: 0000000ae2751268 s4: 0000000000000000 [46.753338] s5: ffffffff8153e290 s6: ff600000863b9000 s7: ff60000002 961078 [46.753562] s8: ff60000002961048 s9: ff60000002961058 s10: 00000000000000001 [46.753783] s11: 0000000000000018 t3: ffffffffffffff ff t4 : ffffffffffffffff [ 46.754005] t5 : ff6000000292270c t6: ff2000000022bb30 [46.754179] estado: 0000000200000100 badaddr: 00000000000000000 causa: 0000000000000000c [46.754653] Código: No se puede acceder instrucción en 0xffffffffffffffec. [ 46.754939] ---[ end trace 0000000000000000 ]--- [ 46.755131] nota: perf-exec[107] salió con irqs deshabilitados [ 46.755546] nota: perf-exec[107] salió con preempt_count 4 Esto sucede porque en el legado En este caso, la función ctr_get_width no se definió, pero se usa en arch_perf_update_userpage. También elimine el control adicional en riscv_pmu_ctr_get_width_mask

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Previene un posible desbordamiento del búfer en map_hw_resources Agrega una verificación en la función map_hw_resources para evitar un posible desbordamiento del búfer. La función accedía a matrices utilizando un índice que potencialmente podría ser mayor que el tamaño de las matrices, lo que provocaba un desbordamiento del búfer. Agrega una verificación para garantizar que el índice esté dentro de los límites de las matrices. Si el índice está fuera de los límites, se imprime un mensaje de error y, al interrumpirlo, continuará la ejecución ignorando los datos adicionales antes de tiempo para evitar el desbordamiento del búfer. Reportado por smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dml2/dml2_wrapper.c:79 error map_hw_resources(): desbordamiento del búfer 'dml2->v20.scratch.dml_to_dc_pipe_mapping.disp_cfg_to_stream_id' 6 <= 7 controladores/gpu/drm/amd/amdgpu/../display/dc/dml2/dml2_wrapper.c:81 error map_hw_resources(): desbordamiento del búfer 'dml2->v20.scratch.dml_to_dc_pipe_mapping.disp_cfg_to_plane_id' 6 <= 7

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: qcom: corrige el puntero no inicializado dmactl. En el caso de que se llame a __lpass_get_dmactl_handle y el ID del controlador dai_id no sea válido, al puntero dmactl no se le asigna un valor y dmactl contiene un valor basura. ya que no se ha inicializado y, por lo tanto, es posible que la verificación nula no funcione. Solucione esto para inicializar dmactl a NULL. Se podría argumentar que los compiladores modernos establecerán esto en cero, pero es útil mantenerlo inicializado de la misma manera en las funciones __lpass_platform_codec_intf_init y lpass_cdc_dma_daiops_hw_params. Limpia la advertencia de compilación de escaneo clang: sound/soc/qcom/lpass-cdc-dma.c:275:7: advertencia: la condición de rama se evalúa como un valor basura [core.uninitialized.Branch]

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mm/vmscan: corrige un error al llamar a wakeup_kswapd() con un índice de zona incorrecto Con el equilibrio numa activado, cuando se ejecuta un SYSTEM numa donde un nodo numa no tiene su memoria local por lo que no tiene zonas administradas, se ha observado lo siguiente. Es porque se llama a wakeup_kswapd() con un índice de zona incorrecto, -1. Se solucionó verificando el índice antes de llamar a wakeup_kswapd(). > ERROR: no se puede manejar el error de página para la dirección: 00000000000033f3 > #PF: acceso de lectura del supervisor en modo kernel > #PF: error_code(0x0000) - página no presente > PGD 0 P4D 0 > Ups: 0000 [#1] SMP PREEMPT NOPTI > CPU: 2 PID: 895 Comm: masim Not tainted 6.6.0-dirty #255 > Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS > rel-1.16.0-0-gd239552ce722-prebuilt.qemu .org 01/04/2014 > RIP: 0010:wakeup_kswapd (./linux/mm/vmscan.c:7812) > Código: (omitido) > RSP: 0000:ffffc90004257d58 EFLAGS: 00010286 > RAX: ffffffffffffffff RBX: ffff88883f ff0480RCX: 0000000000000003 > RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88883fff0480 > RBP: ffffffffffffffff R08: ff0003ffffffffff R09: ffffffffffffffff > R10: ff ff888106c95540 R11: 0000000055555554 R12: 0000000000000003 > R13: 0000000000000000 R14: 00000000000000000 R15: ffff88883fff0940 > FS: 0000 7fc4b8124740(0000) GS: ffff888827c00000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: 00000000000033f3 CR3: 000000026cc08004 CR4: 0000000000770ee0 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > DR3: 00000000000000000 DR6: 00000000ffe0ff0 DR7: 000 0000000000400 > PKRU: 55555554 > Rastreo de llamadas: > > ? __morir > ? page_fault_oops > ? __pte_offset_map_lock > ? exc_page_fault > ? asm_exc_page_fault > ? wakeup_kswapd > migrar_misplaced_page > __handle_mm_fault > handle_mm_fault > do_user_addr_fault > exc_page_fault > asm_exc_page_fault > RIP: 0033:0x55b897ba0808 > Código: (omitido) > RSP: 002b:00007ffeefa821a0 EFLAGS: 00 010287 > RAX: 000055b89983acd0 RBX: 00007ffeefa823f8 RCX: 000055b89983acd0 > RDX: 00007fc2f8122010 RSI: 0000000000020000 RDI: 000055b89983acd0 > RBP: 00007ffeefa821a0 R08: 0000000000000037 R09: 00000000000000075 > R10: 0000000000000000 R11: 0 000000000000202 R12: 0000000000000000 > R13: 00007ffeefa82410 R14: 000055b897ba5dd8 R15: 00007fc4b8340000 >

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: fbcon: restaurar siempre los datos de fuentes antiguos en fbcon_do_set_font() commit a5a923038d70 (fbdev: fbcon: revertir correctamente los cambios cuando falló vc_resize()) comenzó a restaurar los datos de fuentes antiguos en caso de falla (de vc_resize ()). Pero funciona sólo para fuentes de usuario. Significa que las fuentes internas/del "SYSTEM" no se restauran en absoluto. Entonces, como resultado, la primera llamada a fbcon_do_set_font() no realiza ninguna restauración al fallar vc_resize(). Syzkaller puede reproducir esto para bloquear el SYSTEM en la siguiente invocación de font_get(). Es bastante difícil solucionar el error de asignación en vc_resize() en el primer font_set(), pero no imposible. Esp. si se utiliza la inyección de fallos para ayudar en la ejecución/fallo. Sirius lo demostró: ERROR: no se puede manejar el error de página para la dirección: fffffffffffffff8 #PF: acceso de lectura del supervisor en modo kernel #PF: error_code(0x0000) - página no presente PGD cb7b067 P4D cb7b067 PUD cb7d067 PMD 0 Ups: 0000 [ #1] PREEMPT SMP KASAN CPU: 1 PID: 8007 Comm: poc No contaminado 6.7.0-g9d1694dc91ce #20 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.15.0-1 01/04/2014 RIP : 0010:fbcon_get_font+0x229/0x800 drivers/video/fbdev/core/fbcon.c:2286 Seguimiento de llamadas: con_font_get drivers/tty/vt/vt.c:4558 [en línea] con_font_op+0x1fc/0xf20 drivers/tty /vt/vt.c:4673 controladores vt_k_ioctl/tty/vt/vt_ioctl.c:474 [en línea] vt_ioctl+0x632/0x2ec0 controladores/tty/vt/vt_ioctl.c:752 tty_ioctl+0x6f8/0x1570 controladores/tty/tty_io. c:2803 vfs_ioctl fs/ioctl.c:51 [en línea] ... Así que restaure los datos de fuente en cualquier caso, no solo para las fuentes del usuario. Tenga en cuenta que el 'if' posterior ahora está protegido por 'old_userfont' y no por 'old_data' ya que este último siempre está configurado ahora. (Y se supone que no es NULL. De lo contrario, volveríamos a ver el error anterior).

El control de acceso incorrecto en ITB-GmbH TradePro v9.5 permite a atacantes remotos recibir todas las confirmaciones de pedidos de la tienda en línea a través del complemento printmail.

Vulnerabilidad de inyección SQL en ITB-GmbH TradePro v9.5, permite a atacantes remotos ejecutar consultas SQL a través del componente oordershow en la función de cliente.