Boletín de vulnerabilidades

Vulnerabilidades con productos recientemente documentados:

No hay vulnerabilidades nuevas para los productos a los que está suscrito.

Otras vulnerabilidades de los productos a los que usted está suscrito, y cuya información ha sido actualizada recientemente:

• Vulnerabilidad en el slug del proyecto en el plugin LayerSlider de WordPress (CVE-2022-1153)
  Severidad: MEDIA
  Fecha de publicación: 25/04/2022
  Fecha de última actualización: 17/03/2025
  El plugin LayerSlider de WordPress versiones anteriores a 7.1.2, no sanea ni escapa del slug del proyecto antes de devolverlo a varios lugares, lo que podría permitir a usuarios muy privilegiados, como los administradores, llevar a cabo ataques de tipo Cross-Site Scripting incluso cuando la función unfiltered_html no está permitida
  
• Vulnerabilidad en pgAdmin 4 (CVE-2022-0959)
  Severidad: MEDIA
  Fecha de publicación: 16/03/2022
  Fecha de última actualización: 17/03/2025
  Un usuario malintencionado, pero autorizado y autentificado, puede construir una petición HTTP utilizando su token CSRF existente y la cookie de sesión para subir manualmente archivos a cualquier ubicación en la que la cuenta de usuario del sistema operativo bajo la que se ejecuta pgAdmin tenga permiso para escribir
  
• Vulnerabilidad en pgAdmin (CVE-2023-5002)
  Severidad: MEDIA
  Fecha de publicación: 22/09/2023
  Fecha de última actualización: 17/03/2025
  Se encontró una falla en pgAdmin. Este problema ocurre cuando la API HTTP del servidor pgAdmin valida la ruta que un usuario selecciona a las utilidades externas de PostgreSQL, como pg_dump y pg_restore. Las versiones de pgAdmin anteriores a la 7.6 no pudieron controlar adecuadamente el código del servidor ejecutado en esta API, lo que permitió a un usuario autenticado ejecutar comandos arbitrarios en el servidor.
  
• Vulnerabilidad en LayerSlider (CVE-2023-47786)
  Severidad: MEDIA
  Fecha de publicación: 22/11/2023
  Fecha de última actualización: 17/03/2025
  Vulnerabilidad de neutralización inadecuada de la entrada durante la generación de páginas web ('cross-site Scripting') en el complemento LayerSlider <= versiones 7.7.9.
  
• Vulnerabilidad en Tenda AC10V4.0 V16.03.10.20 (CVE-2024-25373)
  Severidad: MEDIA
  Fecha de publicación: 15/02/2024
  Fecha de última actualización: 17/03/2025
  Se descubrió que Tenda AC10V4.0 V16.03.10.20 contenía un desbordamiento en la región stack de la memoria a través del parámetro de página en la función sub_49B384.
  
• Vulnerabilidad en D-Link DIR-823G A1V1.0.2B05 (CVE-2024-27659)
  Severidad: MEDIA
  Fecha de publicación: 29/02/2024
  Fecha de última actualización: 17/03/2025
  Se descubrió que D-Link DIR-823G A1V1.0.2B05 contenía desreferencias de puntero nulo en sub_42AF30(). Esta vulnerabilidad permite a los atacantes provocar una denegación de servicio (DoS) mediante una entrada manipulada.
  
• Vulnerabilidad en D-Link DIR-823G A1V1.0.2B05 (CVE-2024-27660)
  Severidad: MEDIA
  Fecha de publicación: 29/02/2024
  Fecha de última actualización: 17/03/2025
  Se descubrió que D-Link DIR-823G A1V1.0.2B05 contenía desreferencias de puntero nulo en sub_41C488(). Esta vulnerabilidad permite a los atacantes provocar una denegación de servicio (DoS) mediante una entrada manipulada.
  
• Vulnerabilidad en D-Link DIR-823G A1V1.0.2B05 (CVE-2024-27661)
  Severidad: MEDIA
  Fecha de publicación: 29/02/2024
  Fecha de última actualización: 17/03/2025
  Se descubrió que D-Link DIR-823G A1V1.0.2B05 contenía desreferencias de puntero nulo en sub_4484A8(). Esta vulnerabilidad permite a los atacantes provocar una denegación de servicio (DoS) mediante una entrada manipulada.
  
• Vulnerabilidad en D-Link DIR-823G A1V1.0.2B05 (CVE-2024-27662)
  Severidad: MEDIA
  Fecha de publicación: 29/02/2024
  Fecha de última actualización: 17/03/2025
  Se descubrió que D-Link DIR-823G A1V1.0.2B05 contenía desreferencias de puntero nulo en sub_4110f4(). Esta vulnerabilidad permite a los atacantes provocar una denegación de servicio (DoS) mediante una entrada manipulada.
  
• Vulnerabilidad en kernel de Linux (CVE-2021-47166)
  Severidad: MEDIA
  Fecha de publicación: 25/03/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: NFS: no corrompa el valor de pg_bytes_writing en nfs_do_recoalesce() El valor de mirror->pg_bytes_write solo debe actualizarse después de un intento exitoso de eliminar las solicitudes de la lista.
  
• Vulnerabilidad en kernel de Linux (CVE-2021-47167)
  Severidad: MEDIA
  Fecha de publicación: 25/03/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: NFS: corrija una condición de Oopsable en __nfs_pageio_add_request() Asegúrese de que nfs_pageio_error_cleanup() restablezca el contenido de la matriz reflejada, de modo que la estructura refleje el hecho de que ahora está vacía. También cambie la prueba en nfs_pageio_do_add_request() para que sea más sólida verificando si la lista está vacía o no en lugar de confiar en el valor de pg_count.
  
• Vulnerabilidad en kernel de Linux (CVE-2021-47168)
  Severidad: MEDIA
  Fecha de publicación: 25/03/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: NFS: corrige un límite incorrecto en filelayout_decode_layout() El "sizeof(struct nfs_fh)" es dos bytes demasiado grande y podría provocar daños en la memoria. Debería ser NFS_MAXFHSIZE porque ese es el tamaño del búfer ->datos[]. Invertí el tamaño de los argumentos para poner la variable a la izquierda.
  
• Vulnerabilidad en kernel de Linux (CVE-2021-47170)
  Severidad: MEDIA
  Fecha de publicación: 25/03/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: USB: usbfs: No ADVERTIR sobre asignaciones de memoria excesivamente grandes. Syzbot descubrió que el kernel genera una ADVERTENCIA si el usuario intenta enviar una transferencia masiva a través de usbfs con un búfer demasiado grande. Esto no es un error en el kernel; es simplemente una solicitud no válida del usuario y el código usbfs la maneja correctamente. En teoría, lo mismo puede suceder con las transferencias asíncronas o con la tabla de descriptores de paquetes para transferencias isócronas. Para evitar que el subsistema MM se queje de estas solicitudes de asignación incorrectas, agregue el indicador __GFP_NOWARN a las llamadas kmalloc para estos búferes.
  
• Vulnerabilidad en kernel de Linux (CVE-2021-47174)
  Severidad: MEDIA
  Fecha de publicación: 25/03/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: netfilter: nft_set_pipapo_avx2: agregar verificación irq_fpu_usable(), respaldo a una versión que no sea AVX2 Arturo informó este seguimiento: [709732.358791] ADVERTENCIA: CPU: 3 PID: 456 en arch/x86/kernel /fpu/core.c:128 kernel_fpu_begin_mask+0xae/0xe0 [709732.358793] Módulos vinculados en: binfmt_misc nft_nat nft_chain_nat nf_nat nft_counter nft_ct nf_tables nf_conntrack_netlink nfnetlink 8021q garp stp mrp ll c vrf intel_rapl_msr intel_rapl_common skx_edac nfit libnvdimm ipmi_ssif x86_pkg_temp_thermal intel_powerclamp coretemp crc32_pclmul mgag200 ghash_clmulni_intel drm_kms_helper cec aesni_intel drm libaes crypto_simd cryptd pegamento_helper mei_me dell_smbios iTCO_wdt evdev intel_pmc_bxt iTCO_vendor_support dcdbas pcspkr rapl dell_wmi_descriptor wmi_bmof sg i2c_algo_bit perro guardián mei acpi_ipmi ipmi_si botón nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ipmi_devintf ipmi_msghandler ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 dm_mod raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor sd_mod t10_pi crc_t10dif crct10dif_generic raid6_pq libcrc32c crc32c_generic raid1 raid0 multiruta lineal md_mod ahci libahci tg3 libata xhci_pci libphy xhci_hcd ptp usbcore crct10dif_pclmul crct10dif_common bnxt_en crc32c_intel scsi_mod [709732.358941] pps_core i2c_i801 lpc_ich i2c_ smbus wmi usb_common [709732.358957] CPU: 3 PID: 456 Comunicaciones: jbd2/dm-0-8 No contaminado 5.10 .0-0.bpo.5-amd64 #1 Debian 5.10.24-1~bpo10+1 [709732.358959] Nombre del hardware: Dell Inc. PowerEdge R440/04JN2K, BIOS 2.9.3 23/09/2020 [709732.358964] RIP: 0010:kernel_fpu_begin_mask+0xae/0xe0 [709732.358969] Código: ae 54 24 04 83 e3 01 75 38 48 8b 44 24 08 65 48 33 04 25 28 00 00 00 75 33 48 83 c4 10 5b c3 65 8a 05 5e 21 5e 76 84 c0 74 92 <0f> 0b eb 8e f0 80 4f 01 40 48 81 c7 00 14 00 00 e8 dd fb ff ff eb [709732.358972] RSP: 0018:ffffbb9700304740 EFLAGS: 00010202 [709 732.358976] RAX: 00000000000000001 RBX: 0000000000000003 RCX: 0000000000000001 [709732.358979] RDX: ffffbb9700304970 RSI: ffff922fe1952e00 RDI: 00000000000000003 [709732.358981] RBP: ffffbb9700304970 R08: ffff922fc868a600 R09: ffff922fc711e462 [709732.358984] R10: 000000000000005f R11: ffff922ff0b27180 R12: ffffbb9700304960 [709732.358987] R13: ffffbb9700304b08 R14: ffff922fc664b6c8 R15: ffff922fc664b660 [ 709732.358990] FS: 0000000000000000(0000) GS:ffff92371fec0000(0000) knlGS:0000000000000000 [709732.358993] CS: 0010 DS: 0000 ES: 0000 CR0: 00 00000080050033 [709732.358996] CR2: 0000557a6655bdd0 CR3: 000000026020a001 CR4: 00000000007706e0 [709732.358999] DR0: 00000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [709732.359001] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [709732.3590 03] PKRU: 55555554 [709732.359005] Seguimiento de llamadas: [709732.359009] [709732.359035] nft_pipapo_avx2_lookup+0x4c/0x1cba [nf_tables] [709732.359046] ? sched_clock+0x5/0x10 [709732.359054] ? sched_clock_cpu+0xc/0xb0 [709732.359061] ? record_times+0x16/0x80 [709732.359068] ? plist_add+0xc1/0x100 [709732.359073] ? psi_group_change+0x47/0x230 [709732.359079] ? skb_clone+0x4d/0xb0 [709732.359085] ? enqueue_task_rt+0x22b/0x310 [709732.359098] ? bnxt_start_xmit+0x1e8/0xaf0 [bnxt_es] [709732.359102] ? paquete_rcv+0x40/0x4a0 [709732.359121] nft_lookup_eval+0x59/0x160 [nf_tables] [709732.359133] nft_do_chain+0x350/0x500 [nf_tables] [709732.359152] ? nft_lookup_eval+0x59/0x160 [nf_tables] [709732.359163] ? nft_do_chain+0x364/0x500 [nf_tables] [709732.359172]? fib4_rule_action+0x6d/0x80 [709732.359178] ? fib_rules_lookup+0x107/0x250 [709732.359184] nft_nat_do_chain+0x8a/0xf2 [nft_chain_nat] [709732.359193] nf_nat_inet_fn+0xea/0x210 [nf_nat] [709732.359202 ] nf_nat_ipv4_out+0x14/0xa0 [nf_nat] [709732.359207] nf_hook_slow+0x44/0xc0 [709732.359214] salida_ip +0xd2/0x100 [709732.359221] ? __ip_finish_output+0x210/0x210 [709732.359226] ip_forward+0x37d/0x4a0 [709732.359232] ? ip4_key_hashfn+0xb0/0xb0 [709732.359238] ip_subli ---truncado---
  
• Vulnerabilidad en kernel de Linux (CVE-2021-47175)
  Severidad: ALTA
  Fecha de publicación: 25/03/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/sched: fq_pie: arregla el acceso OOB en la ruta de tráfico el siguiente script: # tc qdisc add dev eth0 handle 0x1 root fq_pie flows 2 # tc qdisc add dev eth0 clsact # tc filtrar agregar dev eth0 salida matchall acción skbedit prioridad 0x10002 # ping 192.0.2.2 -I eth0 -c2 -w1 -q produce el siguiente símbolo: ERROR: KASAN: slab-out-of-bounds in fq_pie_qdisc_enqueue+0x1314/0x19d0 [sch_fq_pie] Leer de tamaño 4 en la dirección ffff888171306924 por tarea ping/942 CPU: 3 PID: 942 Comm: ping Not tainted 5.12.0+ #441 Nombre de hardware: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+ 0f1aadab 01/04/2014 Seguimiento de llamadas: dump_stack+0x92/0xc1 print_address_description.constprop.7+0x1a/0x150 kasan_report.cold.13+0x7f/0x111 fq_pie_qdisc_enqueue+0x1314/0x19d0 [sch_fq_pie] __dev_queue_x mit+0x1034/0x2b10 ip_finish_output2+0xc62/0x2120 __ip_finish_output+0x553/0xea0 ip_output+0x1ca/0x4d0 ip_send_skb+0x37/0xa0 raw_sendmsg+0x1c4b/0x2d00 sock_sendmsg+0xdb/0x110 __sys_sendto+0x1d7/0x2b0 __x64_sys_s endto+0xdd/0x1b0 do_syscall_64+0x3c/0x80 Entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7fe69735c3eb Código: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 f3 0f 1e fa 48 8d 05 75 42 2c 00 41 89 ca 8b 00 85 c0 75 14 b8 2c 00 00 00 0f 05 <48 > 3d 00 f0 ff ff 77 75 c3 0f 1f 40 00 41 57 4d 89 c7 41 56 41 89 RSP: 002b:00007fff06d7fb38 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 000055e961413700 RCX: 00007fe69735c3eb RDX: 0000000000000040 RSI: 000055e961413700 RDI: 0000000000000003 RBP: 0000000000000040 R08: 000055e961410500 R09: 00000000000000010 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff06d81260 R13: 00007fff06d7fb40 R14: 00007fff06d7fc30 R15: 000055e96140f0a0 Asignado por la tarea 917: kasan_save_stack+0x19/0x40 __kasan_kmalloc+0x7f/0xa0 __kmalloc_node+0x139/0x280 fq_pie_init+0x555/0x8e8 [ sch_fq_pie] qdisc_create+0x407/0x11b0 tc_modify_qdisc+0x3c2/0x17e0 rtnetlink_rcv_msg+0x346/0x8e0 netlink_rcv_skb+0x120/0x380 netlink_unicast+0x439/0x630 netlink_sendmsg+0x719/ 0xbf0 sock_sendmsg+0xe2/0x110 ____sys_sendmsg+0x5ba/0x890 ___sys_sendmsg+0xe9/0x160 __sys_sendmsg+0xd3 /0x170 do_syscall_64+0x3c/0x80 Entry_SYSCALL_64_after_hwframe+0x44/0xae La dirección con errores pertenece al objeto en ffff888171306800 que pertenece al caché kmalloc-256 de tamaño 256. La dirección con errores se encuentra 36 bytes a la derecha de la región de 256 bytes [ffff888171306 800, ffff888171306900) La dirección del error pertenece a la página: página:00000000bcfb624e refcount:1 mapcount:0 mapeo:0000000000000000 index:0x0 pfn:0x171306 head:00000000bcfb624e order:1 composite_mapcount:0 flags: 0x17ffffc00 10200(losa|cabeza|nodo=0|zona =2|lastcpupid=0x1fffff) raw: 0017ffffc0010200 dead000000000100 dead000000000122 ffff888100042b40 raw: 000000000000000000 0000000000100010 00000001ffffffff 0000000000000000 página volcada porque: kasan: se detectó mal acceso Estado de la memoria alrededor de la dirección con errores: ffff888171306800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888171306880: 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc >ffff888171306900: fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ffff888 171306980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff888171306a00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb corrige la ruta de tráfico fq_pie para evitar seleccionar 'q->flows + q->flows_cnt' como un flujo válido: es una dirección más allá de la memoria asignada.
  
• Vulnerabilidad en kernel de Linux (CVE-2021-47176)
  Severidad: MEDIA
  Fecha de publicación: 25/03/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: s390/dasd: agregar función de disciplina faltante. Se corrigió falla con excepción de operación ilegal en dasd_device_tasklet. El commit b72949328869 ("s390/dasd: Prepárese para el manejo de eventos de ruta adicional") cambió el nombre de la función verificar_ruta para ECKD pero no para Logística de Amazon y DIAG. Esto provoca pánico cuando se llama a la función de verificación de ruta para un dispositivo FBA o DIAG. Para solucionarlo, defina una función contenedora para dasd_generic_verify_path().
  
• Vulnerabilidad en kernel de Linux (CVE-2021-47177)
  Severidad: MEDIA
  Fecha de publicación: 25/03/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: iommu/vt-d: corrige la fuga de sysfs en alloc_iommu() iommu_device_sysfs_add() se llama antes, por lo que debe limpiarse en caso de errores posteriores.
  
• Vulnerabilidad en kernel de Linux (CVE-2021-47178)
  Severidad: MEDIA
  Fecha de publicación: 25/03/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: target: core: Evite smp_processor_id() en código interrumpible Se observó el mensaje de ERROR "ERROR: usar smp_processor_id() en código interrumpible [00000000]" para dispositivos TCMU con configuración de kernel DEBUG_PREEMPT. El mensaje se observó cuando se ejecutó blktests block/005 en dispositivos TCMU con backend fileio o usuario:zbc [1]. La confirmación 1130b499b4a7 ("scsi: target: tcm_loop: Use el asistente de envío LIO wq cmd") desencadenó el síntoma. La confirmación modificó la cola de trabajo para manejar comandos y cambió 'current->nr_cpu_allowed' en la llamada a smp_processor_id(). El mensaje también se observó al apagar el sistema cuando los dispositivos TCMU no se limpiaron [2]. La función smp_processor_id() fue llamada en la cola de trabajo del host SCSI para el manejo de abortos y activó el mensaje de ERROR. Este síntoma se observó independientemente de la confirmación 1130b499b4a7 ("scsi: target: tcm_loop: Use el asistente de envío LIO wq cmd"). Para evitar la verificación del código interrumpible en smp_processor_id(), obtenga el ID de la CPU con raw_smp_processor_id() en su lugar. El ID de la CPU se utiliza para mejorar el rendimiento, luego el movimiento del subproceso a otra CPU no afectará el código. [1] [56.468103] ejecute blktests block/005 el 2021-05-12 14:16:38 [57.369473] check_preemption_disabled: 85 devoluciones de llamada suprimidas [57.369480] ERROR: usar smp_processor_id() en código preferente [00000000]: fio/151 1 [ 57.369506] ERROR: usar smp_processor_id() en código interrumpible [00000000]: fio/1510 [57.369512] ERROR: usar smp_processor_id() en código interrumpible [00000000]: fio/1506 [57.369552] la persona que llama es __target_init_cmd+0 x157/0x170 [objetivo_core_mod] [ 57.369606] CPU: 4 PID: 1506 Comm: fio Not tainted 5.13.0-rc1+ #34 [ 57.369613] Nombre del hardware: Fabricante del sistema Nombre del producto del sistema/PRIME Z270-A, BIOS 1302 15/03/2018 [ 57.369617] Seguimiento de llamadas : [57.369621] ERROR: usar smp_processor_id() en código interrumpible [00000000]: fio/1507 [57.369628] dump_stack+0x6d/0x89 [57.369642] check_preemption_disabled+0xc8/0xd0 [57.369628] la persona que llama es __ target_init_cmd+0x157/0x170 [target_core_mod] [ 57.369655] __target_init_cmd+0x157/0x170 [target_core_mod] [ 57.369695] target_init_cmd+0x76/0x90 [target_core_mod] [ 57.369732] tcm_loop_queuecommand+0x109/0x210 [tcm_loop] [ 57 .369744] scsi_queue_rq+0x38e/0xc40 [ 57.369761] __blk_mq_try_issue_directly+0x109/0x1c0 [ 57.369779 ] blk_mq_try_issue_directly+0x43/0x90 [ 57.369790] blk_mq_submit_bio+0x4e5/0x5d0 [ 57.369812] submit_bio_noacct+0x46e/0x4e0 [ 57.369830] __blkdev_direct_IO_simple+0x1a3/0x2 d0 [57.369859]? set_init_blocksize.isra.0+0x60/0x60 [ 57.369880] generic_file_read_iter+0x89/0x160 [ 57.369898] blkdev_read_iter+0x44/0x60 [ 57.369906] new_sync_read+0x102/0x170 [ 57.369929 ] vfs_read+0xd4/0x160 [ 57.369941] __x64_sys_pread64+0x6e/0xa0 [ 57.369946] ? lockdep_hardirqs_on+0x79/0x100 [ 57.369958] do_syscall_64+0x3a/0x70 [ 57.369965] Entry_SYSCALL_64_after_hwframe+0x44/0xae [ 57.369973] RIP: 0033:0x7f7ed4c1399f [ 5 7.369979] Código: 08 89 3c 24 48 89 4c 24 18 e8 7d f3 ff ff 4c 8b 54 24 18 48 8b 54 24 10 41 89 c0 48 8b 74 24 08 8b 3c 24 b8 11 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 04 24 e8 cd f3 ff ff 48 8b [ 57.369983] RSP: 002b:00007ffd7918c580 EFLAGS: 00000293 ORIG_RAX: 0000000000000011 [ 57.369990] RAX: fffffffffffffffda RBX: 00000000015b4540 RCX: 00 007f7ed4c1399f [ 57.369993] RDX: 0000000000001000 RSI: 00000000015de000 RDI: 000000000000000009 [ 57.369996] RBP: 00000000015b4540 R08: 000 0000000000000 R09: 0000000000000001 [ 57.369999] R10: 0000000000e5c000 R11: 0000000000000293 R12: 00007f7eb5269a70 [ 57.370002] R13: 00000000000000000 R14: 000000000000 1000 R15: 00000000015b4568 [57.370031] CPU: 7 PID: 1507 ---truncado---
  
• Vulnerabilidad en kernel de Linux (CVE-2024-26651)
  Severidad: MEDIA
  Fecha de publicación: 27/03/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: sr9800: Agregar verificación para usbnet_get_endpoints Agregar verificación para usbnet_get_endpoints() y devolver el error si falla para transferir el error.
  
• Vulnerabilidad en kernel de Linux (CVE-2023-52632)
  Severidad: MEDIA
  Fecha de publicación: 02/04/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdkfd: corrige la advertencia de dependencia de bloqueo con srcu ============================== ========================== ADVERTENCIA: posible dependencia de bloqueo circular detectada 6.5.0-kfd-yangp #2289 No contaminado ------ ------------------------------------------------ ktrabajador/ 0:2/996 está intentando adquirir el bloqueo: (srcu){.+.+}-{0:0}, en: __synchronize_srcu+0x5/0x1a0 pero la tarea ya mantiene el bloqueo: ((work_completion)(&svms->deferred_list_work )){+.+.}-{0:0}, en: Process_one_work+0x211/0x560 cuyo bloqueo ya depende del nuevo bloqueo. la cadena de dependencia existente (en orden inverso) es: -> #3 ((work_completion)(&svms->deferred_list_work)){+.+.}-{0:0}: __flush_work+0x88/0x4f0 svm_range_list_lock_and_flush_work+0x3d/0x110 [ amdgpu] svm_range_set_attr+0xd6/0x14c0 [amdgpu] kfd_ioctl+0x1d1/0x630 [amdgpu] __x64_sys_ioctl+0x88/0xc0 -> #2 (&info->lock#2){+.+.}-{3:3}: __mutex_lock+ 0x99/0xc70 amdgpu_amdkfd_gpuvm_restore_process_bos+0x54/0x740 [amdgpu] restaurar_proceso_helper+0x22/0x80 [amdgpu] restaurar_proceso_trabajador+0x2d/0xa0 [amdgpu] proceso_one_work+0x29b/0x560 trabajador_thread+0x3d/0x3d 0 -> #1 ((finalización_trabajo)(&(&proceso- >restore_work)->work)){+.+.}-{0:0}: __flush_work+0x88/0x4f0 __cancel_work_timer+0x12c/0x1c0 kfd_process_notifier_release_internal+0x37/0x1f0 [amdgpu] __mmu_notifier_release+0xad/0x240 exit_mmap+0x6a/0x3 a0 mmentrada +0x6a/0x120 do_exit+0x322/0xb90 do_group_exit+0x37/0xa0 __x64_sys_exit_group+0x18/0x20 do_syscall_64+0x38/0x80 -> #0 (srcu){.+.+}-{0:0}: __lock_acquire+0x1521/0x2 510 lock_sync +0x5f/0x90 __synchronize_srcu+0x4f/0x1a0 __mmu_notifier_release+0x128/0x240 exit_mmap+0x6a/0x3a0 mmput+0x6a/0x120 svm_range_deferred_list_work+0x19f/0x350 [amdgpu] Process_one_work+0x29b/0 x560 trabajador_thread+0x3d/0x3d0 otra información que podría ayudarnos a depurar esto : Existe cadena de: srcu --> &info->lock#2 --> (work_completion)(&svms->deferred_list_work) Posible escenario de bloqueo inseguro: CPU0 CPU1 ---- ---- lock((work_completion)(&svms- >lista_trabajo_diferido)); bloquear(&info->bloquear#2); lock((work_completion)(&svms->deferred_list_work)); sincronización(srcu);
  
• Vulnerabilidad en kernel de Linux (CVE-2023-52633)
  Severidad: MEDIA
  Fecha de publicación: 02/04/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: um: viaje en el tiempo: corrige la corrupción del tiempo En el modo de viaje en el tiempo 'básico' (sin =inf-cpu o =ext), todavía obtenemos interrupciones del temporizador. Esto puede suceder en momentos arbitrarios en el tiempo, es decir, mientras está en timer_read(), lo que adelanta un poco el tiempo. Luego, si recibimos la interrupción después de calcular el nuevo tiempo al que enviar, pero antes de finalizarlo, la interrupción establecerá el tiempo en un valor que es incompatible con el avance, y fallaremos porque el tiempo retrocede cuando hacer el reenvío. Solucione este problema leyendo time_travel_time, calculando el ajuste y realizando el ajuste, todo con las interrupciones desactivadas.
  
• Vulnerabilidad en kernel de Linux (CVE-2023-52634)
  Severidad: MEDIA
  Fecha de publicación: 02/04/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: corrige la lógica enable_otg_wa [Por qué] Cuando cambiamos a otro modo HDMI, deshabilitamos/habilitamos FIFO innecesariamente, lo que hace que los registros HPO y DIG se configuren al mismo tiempo. momento en el que se supone que sólo se debe configurar HPO. Esto puede provocar que el sistema se cuelgue la próxima vez que cambiemos las frecuencias de actualización, ya que hay casos en los que no deshabilitamos OTG/FIFO pero FIFO está habilitado cuando no debería estarlo. [Cómo] Eliminar completamente la activación/desactivación de FIFO.
  
• Vulnerabilidad en kernel de Linux (CVE-2023-52635)
  Severidad: MEDIA
  Fecha de publicación: 02/04/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PM / devfreq: Sincronizar devfreq_monitor_[start/stop] Existe la posibilidad de que un cambio frecuente del gobernador realizado en un bucle provoque corrupción en la lista de temporizadores, donde la cancelación del temporizador se realiza desde dos coloque uno de cancel_delayed_work_sync() y seguido de expire_timers() se puede ver en los rastros [1]. mientras que es verdadero, haga echo "simple_ondemand" > /sys/class/devfreq/1d84000.ufshc/governor echo "rendimiento" > /sys/class/devfreq/1d84000.ufshc/governor done Parece ser un problema con el controlador devfreq donde device_monitor_[start /stop] debe sincronizarse para que el trabajo retrasado se corrompa mientras está en cola, ejecutándose o cancelándose. Usemos el indicador de sondeo y el bloqueo devfreq para sincronizar la cola de la instancia del temporizador dos veces y los datos de trabajo que se corrompen. [1] ... .. -0 [003] 9436.209662: timer_cancel timer=0xffffff80444f0428 -0 [003] 9436.209664: timer_expire_entry timer=0xffffff80444f0428 now=0x10022da1c function=__typeid__ZTS FvP10timer_listE_global_addr baseclk=0x10022da1c -0 [003] 9436.209718: timer_expire_exit timer=0xffffff80444f0428 kworker/u16:6-14217 [003] 9436.209863: timer_start timer=0xffffff80444f0428 function=__typeid__ZTSFvP10timer_listE_global_addr expira = 0x10022da2b ahora = 0x10022da1c banderas = 182452227 proveedor.xxxyyy.ha-1593 [004] 9436.209888: timer_cancel temporizador=0xffffff80444f0428 proveedor.xxxyyy.ha-1593 [004] 9436.216390: timer_init temporizador=0xffffff80444f0428 proveedor.xxxyyy.ha-1593 [004] 9436.216392: timer_start temporizador=0xffffff80444f042 8 función=__typeid__ZTSFvP10timer_listE_global_addr expires=0x10022da2c ahora=0x10022da1d flags=186646532 proveedor.xxxyyy .ha-1593 [005] 9436.220992: timer_cancel timer=0xffffff80444f0428 xxxyyyTraceManag-7795 [004] 9436.261641: timer_cancel timer=0xffffff80444f0428 [2] 9436.261653][ C4] No se puede para manejar la solicitud de paginación del kernel en la dirección virtual dead00000000012a [ 9436.261664][ C4] Mem información de cancelación: [ 9436.261666][ C4] ESR = 0x96000044 [ 9436.261669][ C4] EC = 0x25: DABT (EL actual), IL = 32 bits [ 9436.261671][ C4] SET = 0, FnV = 0 [ 9436.261673][ C4 ] EA = 0, S1PTW = 0 [ 9436.261675][ C4] Información de cancelación de datos: [ 9436.261677][ C4] ISV = 0, ISS = 0x00000044 [ 9436.261680][ C4] CM = 0, WnR = 1 [ 9436.261682][ C4] [dead00000000012a] dirección entre los rangos de direcciones del usuario y del kernel [ 9436.261685][ C4] Error interno: Vaya: 96000044 [#1] SMP PREEMPT [ 9436.261701][ C4] Omitir el volcado del búfer md ftrace para: 0x3a982d0 ... [ 9436.262138][ C4 ] CPU: 4 PID: 7795 Comunicaciones: TraceManag Tainted: GSWO 5.10.149-android12-9-o-g17f915d29d0c #1 [ 9436.262141][ C4] Nombre de hardware: Qualcomm Technologies, Inc. (DT) [ 9436.262144][ C4] pstate : 22400085 (nzCv daIf +PAN -UAO +TCO BTYPE=--) [ 9436.262161][ C4] pc : expire_timers+0x9c/0x438 [ 9436.262164][ C4] lr : expire_timers+0x2a4/0x438 [ 9436.262168][ C4] sp : ffffffc010023dd0 [ 9436.262171][ C4] x29: ffffffc010023df0 x28: ffffffd0636fdc18 [ 9436.262178][ C4] x27: ffffffd063569dd0 x26: ffffffd063536008 [ 9436 .262182][ C4] x25: 0000000000000001 x24: ffffff88f7c69280 [ 9436.262185][ C4] x23: 00000000000000e0 x22: muerto000000000122 [ 9436.262188][ C4] x21: 000000010022da29 x20: ffffff8af72b4e80 [ 9436.262191][ C4] x19: ffffffc010023e50 x18: ffffffc010025038 [ 9436.262195][ C4] x 17: 0000000000000240 x16: 0000000000000201 [ 9436.262199][ C4] x15: ffffffffffffffff x14: ffffff889f3c3100 [ 9436.262203] [ C4] x13: ffffff889f3c3100 x12: 00000000049f56b8 [ 9436.262207][ C4] x11: 00000000049f56b8 x10: 00000000ffffffff [ 9436.262212][ C4] x9 : ffffffc0 10023e50 x8: muerto000000000122 [9436.262216][C4] x7: ffffffffffffffff x6: ffffffc0100239d8 [9436.262220][C4 ]---truncado---
  
• Vulnerabilidad en Kernel de Linux (CVE-2023-52636)
  Severidad: MEDIA
  Fecha de publicación: 02/04/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: "libceph: just wait for more data to be available on the socket". Puede ocurrir una lectura breve mientras se lee el pie de página del mensaje desde el socket. Más tarde, cuando el socket está listo para otra lectura, el mensajero invoca todos los controladores read_partial_*(), incluido read_partial_sparse_msg_data(). La expectativa es que read_partial_sparse_msg_data() saldría, permitiendo al mensajero invocar read_partial() para el pie de página y continuar donde lo dejó. Sin embargo, read_partial_sparse_msg_data() viola eso y termina llamando a la máquina de estado en el cliente OSD. La máquina de estado de lectura dispersa asume que es una nueva operación e interpreta alguna parte del pie de página como el encabezado de lectura dispersa y devuelve extensiones/longitud de datos falsas, etc. Para determinar si read_partial_sparse_msg_data() debe rescatarse, reutilicemos cursor->total_resid . Porque una vez que llega a cero, significa que todas las extensiones y datos se recibieron correctamente en la última lectura; de lo contrario, podría romperse al leer parcialmente cualquiera de las extensiones y datos. Y luego osd_sparse_read() podría continuar donde lo dejó. [idryomov: registro de cambios]
  
• Vulnerabilidad en kernel de Linux (CVE-2024-26656)
  Severidad: MEDIA
  Fecha de publicación: 02/04/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amdgpu: corrige el error de use-after-free. El error se puede activar enviando un solo amdgpu_gem_userptr_ioctl al controlador DRM AMDGPU en cualquier ASIC con una dirección y tamaño no válidos. El error fue reportado por Joonkyo Jung . Por ejemplo, el siguiente código: static void Syzkaller1(int fd) { struct drm_amdgpu_gem_userptr arg; ret int; arg.addr = 0xffffffffffff0000; arg.tamaño = 0x80000000; /*2 Gb*/ arg.flags = 0x7; ret = drmIoctl(fd, 0xc1186451/*amdgpu_gem_userptr_ioctl*/, &arg); } Debido a que la dirección y el tamaño no son válidos, hay una falla en amdgpu_hmm_register->mmu_interval_notifier_insert->__mmu_interval_notifier_insert-> check_shl_overflow, pero incluso en la falla de amdgpu_hmm_register todavía llamamos a amdgpu_hmm_unregister en amdgpu_gem_object_free, lo que provoca el acceso a una dirección incorrecta. La siguiente pila se muestra a continuación cuando el problema se reproduce cuando Kazan está habilitado: [+0.000014] Nombre del hardware: Nombre del producto del sistema ASUS/ROG STRIX B550-F GAMING (WI-FI), BIOS 1401 03/12/2020 [+0.000009] RIP: 0010:mmu_interval_notifier_remove+0x327/0x340 [ +0.000017] Código: ff ff 49 89 44 24 08 48 b8 00 01 00 00 00 00 ad de 4c 89 f7 49 89 47 40 48 83 c0 22 49 89 47 48 e8 ce d1 2d 01 e9 32 ff ff ff <0f> 0b e9 16 ff ff ff 4c 89 ef e8 fa 14 b3 ff e9 36 ff ff ff e8 80 [ +0.000014] RSP: 0018:ffffc90002657988 EFLAGS: 00010246 [ +0.000 013] RAX: 0000000000000000 RBX: 1ffff920004caf35 RCX: ffffffff8160565b [ +0.000011] RDX: dffffc0000000000 RSI: 00000000000000004 RDI: ffff8881a9f78260 [ +0.000010] RBP: ffffc90002 657a70 R08: 0000000000000001 R09: fffff520004caf25 [ +0.000010] R10: 0000000000000003 R11: ffffffff8161d1d6 R12: ffff88810e988c00 [ +0.000010] R1 3 : ffff888126fb5a00 R14: ffff88810e988c0c R15: ffff8881a9f78260 [ +0.000011] FS: 00007ff9ec848540(0000) GS:ffff8883cc880000(0000) knlGS:000000000 0000000 [ +0,000012] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ +0,000010] CR2: 000055b3f7e14328 CR3: 00000001b5770000 CR4: 0000000000350ef0 [+0.000010] Seguimiento de llamadas: [+0.000006] [+0.000007] ? show_regs+0x6a/0x80 [+0.000018]? __advertir+0xa5/0x1b0 [ +0.000019] ? mmu_interval_notifier_remove+0x327/0x340 [+0.000018]? report_bug+0x24a/0x290 [+0.000022] ? handle_bug+0x46/0x90 [+0.000015]? exc_invalid_op+0x19/0x50 [+0.000016]? asm_exc_invalid_op+0x1b/0x20 [+0.000017]? kasan_save_stack+0x26/0x50 [+0.000017]? mmu_interval_notifier_remove+0x23b/0x340 [+0.000019]? mmu_interval_notifier_remove+0x327/0x340 [+0.000019]? mmu_interval_notifier_remove+0x23b/0x340 [+0.000020]? __pfx_mmu_interval_notifier_remove+0x10/0x10 [ +0.000017] ? kasan_save_alloc_info+0x1e/0x30 [ +0.000018] ? srso_return_thunk+0x5/0x5f [+0.000014]? __kasan_kmalloc+0xb1/0xc0 [ +0.000018] ? srso_return_thunk+0x5/0x5f [+0.000013]? __kasan_check_read+0x11/0x20 [ +0.000020] amdgpu_hmm_unregister+0x34/0x50 [amdgpu] [ +0.004695] amdgpu_gem_object_free+0x66/0xa0 [amdgpu] [ +0.004534] ? __pfx_amdgpu_gem_object_free+0x10/0x10 [amdgpu] [ +0.004291] ? do_syscall_64+0x5f/0xe0 [+0.000023]? srso_return_thunk+0x5/0x5f [ +0.000017] drm_gem_object_free+0x3b/0x50 [drm] [ +0.000489] amdgpu_gem_userptr_ioctl+0x306/0x500 [amdgpu] [ +0.004295] ? __pfx_amdgpu_gem_userptr_ioctl+0x10/0x10 [amdgpu] [ +0.004270] ? srso_return_thunk+0x5/0x5f [+0.000014]? __this_cpu_preempt_check+0x13/0x20 [ +0.000015] ? srso_return_thunk+0x5/0x5f [+0.000013]? sysvec_apic_timer_interrupt+0x57/0xc0 [+0.000020]? srso_return_thunk+0x5/0x5f [+0.000014]? asm_sysvec_apic_timer_interrupt+0x1b/0x20 [+0.000022]? drm_ioctl_kernel+0x17b/0x1f0 [drm] [ +0.000496] ? __pfx_amdgpu_gem_userptr_ioctl+0x10/0x10 [amdgpu] [ +0.004272] ? drm_ioctl_kernel+0x190/0x1f0 [drm] [ +0.000492] drm_ioctl_kernel+0x140/0x1f0 [drm] [ +0.000497] ? __pfx_amdgpu_gem_userptr_ioctl+0x10/0x10 [amdgpu] [ +0.004297] ? __pfx_drm_ioctl_kernel+0x10/0x10 [d ---truncado---
  
• Vulnerabilidad en kernel de Linux (CVE-2024-26659)
  Severidad: MEDIA
  Fecha de publicación: 02/04/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xhci: maneja correctamente los eventos isoc Babble y Buffer Overrun xHCI 4.9 prohíbe explícitamente suponer que xHC ha liberado su propiedad de un TD multi-TRB cuando informa un error en uno de los primeros TRB. Sin embargo, el conductor hace tal suposición y libera el TD, permitiendo que los TRB restantes sean liberados o sobrescritos por nuevos TD. El xHC también debe informar la finalización del TRB final debido a que nosotros establecimos la bandera del COI, independientemente de los errores anteriores. Este evento no se puede reconocer si el TD ya se liberó anteriormente, lo que genera el mensaje de error "Evento de transferencia TRB DMA ptr no forma parte del TD actual". Solucione este problema reutilizando la lógica para procesar errores de transacción isoc. Esto también maneja los hosts que no informan la finalización final. Se corrigió el informe de duración de la transferencia sobre errores de Babble. Pueden deberse a un mal funcionamiento del dispositivo, no hay garantía de que se haya llenado el búfer.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-26664)
  Severidad: ALTA
  Fecha de publicación: 02/04/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: hwmon: (coretemp) Arreglar el acceso a memoria fuera de los límites Arreglar un error que pdata->cpu_map[] está configurado antes de la verificación de los límites. El problema podría surgir en sistemas con más de 128 núcleos por paquete.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-26667)
  Severidad: MEDIA
  Fecha de publicación: 02/04/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/msm/dpu: check for valid hw_pp en dpu_encoder_helper_phys_cleanup. El commit 8b45a26f2ba9 ("drm/msm/dpu: reserve bloques cdm para reescritura en caso de salida YUV") introdujo una coincidencia advertencia sobre otro bloque condicional en dpu_encoder_helper_phys_cleanup() que había asumido que hw_pp siempre será válido, lo que puede no ser necesariamente cierto. Arreglemos el otro bloque condicional asegurándonos de que hw_pp sea válido antes de eliminar la referencia a él. Remiendo: https://patchwork.freedesktop.org/patch/574878/
  
• Vulnerabilidad en kernel de Linux (CVE-2024-26668)
  Severidad: MEDIA
  Fecha de publicación: 02/04/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: netfilter: nft_limit: rechazar configuraciones que causan desbordamiento de enteros Rechazar configuraciones falsas donde el contador de token interno se ajusta. Esto sólo ocurre con solicitudes muy grandes, como 17 gbytes/s. Es mejor rechazar esto en lugar de tener un límite de tasa incorrecto.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-26669)
  Severidad: ALTA
  Fecha de publicación: 02/04/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/sched: flower: descarga de plantilla de cadena fija Cuando se elimina una qdisc de un dispositivo de red, la pila indica al controlador subyacente que elimine su devolución de llamada de descarga de flujo del bloque de filtro asociado mediante el comando Comando 'FLOW_BLOCK_UNBIND'. Luego, la pila continúa reproduciendo la eliminación de los filtros en el bloque para este controlador iterando sobre las cadenas en el bloque e invocando la operación de "redescarga" del clasificador que se está utilizando. A su vez, el clasificador en su operación de 'redescarga' prepara y emite un comando 'FLOW_CLS_DESTROY' para cada filtro. Sin embargo, la pila no hace lo mismo con las plantillas de cadena y el controlador subyacente nunca recibe un comando 'FLOW_CLS_TMPLT_DESTROY' cuando se elimina una qdisc. Esto da como resultado una pérdida de memoria [1] que se puede reproducir usando [2]. Para solucionarlo, introduzca una operación 'tmplt_reoffload' y haga que la pila la invoque con los argumentos apropiados como parte de la reproducción. Implemente la operación en el único clasificador que admite plantillas de cadena (flor) emitiendo el comando 'FLOW_CLS_TMPLT_{CREATE,DESTROY}' en función de si una devolución de llamada de descarga de flujo está vinculada a un bloque de filtro o no está vinculada a uno. Por lo que puedo decir, el problema ocurre desde el commit que reordenó tcf_block_offload_unbind() antes de tcf_block_flush_all_chains() en __tcf_block_put(). El orden no se puede invertir ya que se espera que el bloque del filtro se libere después de lavar todas las cadenas. [1] objeto sin referencia 0xffff888107e28800 (tamaño 2048): comm "tc", pid 1079, jiffies 4294958525 (edad 3074.287s) volcado hexadecimal (primeros 32 bytes): b1 a6 7c 11 81 88 ff ff e0 5b b3 10 81 88 ff f ..|......[...... 01 00 00 00 00 00 00 00 e0 aa b0 84 ff ff ff ff ................ retroceso: [] __kmem_cache_alloc_node+0x1e8/0x320 [] __kmalloc+0x4e/0x90 [] mlxsw_sp_acl_ruleset_get+0x34d/0x7a0 [] mlxsw_sp_flower_tmplt_create+0x145/0x180 [] mlxsw_sp_flow_block_cb+0x1ea/0x280 [] tc_setup_cb_call+0x183/0x340 [] fl_tmplt_create+0x3da/0x4c0 [] tc_ctl_chain+0xa15/0x1170 [] rtnetlink_rcv_msg+0x3cc/0xed0 [] netlink_rcv_skb+0x170/0x440 [] netlink_unicast+0x540/0x820 [] netlink_sendmsg+0x8d8/0xda0 [] ____sys_sendmsg+0x30f/0xa80 [] ___sys_ enviarmsg+0x13a/0x1e0 [] __sys_sendmsg+0x11c/0x1f0 [] do_syscall_64+0x40/0xe0 objeto sin referencia 0xffff88816d2c0400 (tamaño 1024): comm "tc", pid 1079, santiamén 4294958525 (edad 3074.287s) volcado hexadecimal (primeros 32 bytes): 40 00 00 00 00 00 00 00 57 f6 38 be 00 00 00 00 @.......W.8..... 10 04 2c 6d 81 88 ff ff 10 04 2c 6d 81 88 ff ff ..,m......, m.... retroceso: [] __kmem_cache_alloc_node+0x1e8/0x320 [] __kmalloc_node+0x51/0x90 [] kvmalloc_node+0xa6/0x1f0 [] bucket_table_alloc.isra.0+0x83/ 0x460 [] rhashtable_init+0x43b/0x7c0 [] mlxsw_sp_acl_ruleset_get+0x428/0x7a0 [] mlxsw_sp_flower_tmplt_create+0x145/0x180 [] mlxsw_sp_flow_block_cb+0x1ea/0x280 [] tc_setup_cb_call+0x183/ 0x340 [] fl_tmplt_create+0x3da/0x4c0 [] tc_ctl_chain+0xa15/0x1170 [] rtnetlink_rcv_msg+0x3cc/0xed0 [] netlink_rcv_skb+0x170/0x440 [] netlink_unicast+0x540/ 0x820 [] netlink_sendmsg+0x8d8/0xda0 [] ____sys_sendmsg+0x30f/0xa80 [2] # ---truncado---
  
• Vulnerabilidad en kernel de Linux (CVE-2024-26670)
  Severidad: MEDIA
  Fecha de publicación: 02/04/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: arm64: entrada: arreglar ARM64_WORKAROUND_SPECULATIVE_UNPRIV_LOAD Actualmente, la solución alternativa ARM64_WORKAROUND_SPECULATIVE_UNPRIV_LOAD no es del todo correcta, ya que se supone que debe aplicarse después del último acceso explícito a la memoria, pero va seguida inmediatamente por un LDR. La solución alternativa ARM64_WORKAROUND_SPECULATIVE_UNPRIV_LOAD se utiliza para manejar las erratas Cortex-A520 2966298 y Cortex-A510 erratas 3117295, que se describen en: * https://developer.arm.com/documentation/SDEN2444153/0600/?lang=en * https:// desarrollador.arm.com/documentation/SDEN1873361/1600/?lang=en En ambos casos, la solución se describe como: | Si el aislamiento de la tabla de páginas está deshabilitado, la lógica de cambio de contexto en | El kernel se puede actualizar para ejecutar la siguiente secuencia en los afectados | núcleos antes de salir a EL0 y después de todos los accesos explícitos a la memoria: | | 1. Un TLBI que no se puede compartir en cualquier contexto y/o dirección, incluido | contextos o direcciones no utilizados, como `TLBI VALE1 Xzr`. | | 2. Un OSD NSH para garantizar la finalización del TLBI. La parte importante es que el TLBI+DSB debe colocarse "después de todos los accesos explícitos a la memoria". Desafortunadamente, tal como se implementó, el TLBI+DSB es seguido inmediatamente por un LDR, como tenemos: | Alternative_if ARM64_WORKAROUND_SPECULATIVE_UNPRIV_LOAD | tlbi vale1, xzr | dsb nsh | alternativa_else_nop_endif | alternativa_si_no ARM64_UNMAP_KERNEL_AT_EL0 | ldr lr, [sp, #S_LR] | agregar sp, sp, #PT_REGS_SIZE // restaurar sp | eremita | alternativa_else_nop_endif | | [... Ruta de retorno de excepción KPTI...] Este parche soluciona este problema reelaborando la lógica para colocar TLBI+DSB inmediatamente antes de ERET, después de todos los accesos explícitos a la memoria. El ERET se encuentra actualmente en un bloque alternativo separado y las alternativas no se pueden anidar. Para tener en cuenta esto, el bloque alternativo para ARM64_UNMAP_KERNEL_AT_EL0 se reemplaza con una única rama alternativa para omitir la lógica KPTI, siendo la nueva forma de la lógica: | Alternative_insn "b .L_skip_tramp_exit_\@", nop, ARM64_UNMAP_KERNEL_AT_EL0 | [... Ruta de retorno de excepción KPTI...] | .L_skip_tramp_exit_\@: | | ldr lr, [sp, #S_LR] | agregar sp, sp, #PT_REGS_SIZE // restaurar sp | | Alternative_if ARM64_WORKAROUND_SPECULATIVE_UNPRIV_LOAD | tlbi vale1, xzr | dsb nsh | alternativa_else_nop_endif | eret La nueva estructura significa que la solución alternativa sólo se aplica cuando KPTI no está en uso; esto está bien, como se indica en las implicaciones documentadas de la fe de erratas: | El aislamiento de la tabla de paginación entre EL0 y los EL de nivel superior evita que | que ocurra el problema. ... y según la descripción de la solución citada anteriormente, la solución sólo es necesaria "si el aislamiento de la tabla de páginas está deshabilitado".
  
• Vulnerabilidad en kernel de Linux (CVE-2024-26671)
  Severidad: MEDIA
  Fecha de publicación: 02/04/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: blk-mq: corrige el bloqueo de IO de la carrera de activación del mapa de bits En blk_mq_mark_tag_wait(), __add_wait_queue() se puede reordenar con el siguiente blk_mq_get_driver_tag() en caso de que se produzca un error en la etiqueta del controlador. Luego, en __sbitmap_queue_wake_up(), waitqueue_active() puede no observar al camarero agregado en blk_mq_mark_tag_wait() y no despertar nada, mientras tanto, blk_mq_mark_tag_wait() no puede obtener la etiqueta del controlador correctamente. Este problema se puede reproducir ejecutando la siguiente prueba en bucle, y se puede observar un bloqueo de fio en < 30 minutos cuando lo ejecuto en mi máquina virtual de prueba en una computadora portátil. modprobe -r scsi_debug modprobe scsi_debug delay=0 dev_size_mb=4096 max_queue=1 host_max_queue=1 submit_queues=4 dev=`ls -d /sys/bus/pseudo/drivers/scsi_debug/adapter*/host*/target*/*/block /* | cabeza -1 | xargs basename` fio --filename=/dev/"$dev" --direct=1 --rw=randrw --bs=4k --io Depth=1 \ --runtime=100 --numjobs=40 --time_based - -name=test \ --ioengine=libaio Solucione el problema agregando una barrera explícita en blk_mq_mark_tag_wait(), lo cual está bien en caso de quedarse sin etiqueta.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-26673)
  Severidad: ALTA
  Fecha de publicación: 02/04/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: netfilter: nft_ct: desinfecta el número de protocolo de capa 3 y 4 en expectativas personalizadas - No permitir familias que no sean NFPROTO_{IPV4,IPV6,INET}. - No permitir el protocolo de capa 4 sin puertos, ya que el puerto de destino es un atributo obligatorio para este objeto.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-26674)
  Severidad: ALTA
  Fecha de publicación: 02/04/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: x86/lib: vuelva a _ASM_EXTABLE_UA() para reparaciones de {get,put}_user() Durante la prueba de inyección de errores de memoria en kernels >= v6.4, el kernel entra en pánico como se muestra a continuación. Sin embargo, este problema no se pudo reproducir en kernels <= v6.3. mce: [Error de hardware]: CPU 296: Excepción de verificación de la máquina: f Banco 1: bd80000000100134 mce: [Error de hardware]: RIP 10: {__get_user_nocheck_4+0x6/0x20} mce: [Error de hardware]: TSC 411a93533ed ADDR 346a87300 40 MISC 86 mce: [Error de hardware]: PROCESADOR 0:a06d0 HORA 1706000767 SOCKET 1 APIC 211 microcódigo 80001490 mce: [Error de hardware]: Ejecute lo anterior a través de 'mcelog --ascii' mce: [Error de hardware]: Verificación de la máquina: Carga de datos en un área irrecuperable del kernel Pánico del kernel - no se sincroniza: verificación fatal de la máquina local El código MCA se puede recuperar de un #MC en el kernel si el tipo de reparación es EX_TYPE_UACCESS, lo que indica explícitamente que el kernel está intentando acceder a la memoria del espacio de usuario. Sin embargo, si el tipo de reparación es EX_TYPE_DEFAULT, lo único que se genera para un #MC en el kernel es pánico. ex_handler_uaccess() advertiría si los usuarios proporcionaban direcciones no canónicas (con el bit 63 claro) a {get, put}_user(), lo cual era inesperado. Por lo tanto, el commit b19b74bc99b1 ("x86/mm: Reelaborar la verificación del rango de direcciones en get_user() y put_user()") reemplazó _ASM_EXTABLE_UA() con _ASM_EXTABLE() para las correcciones de {get, put}_user(). Sin embargo, el nuevo tipo de reparación EX_TYPE_DEFAULT provoca pánico. El commit 6014bc27561f ("x86-64: hacer que access_ok() sea independiente de LAM") agregó la verificación gp_fault_address_ok() justo antes de WARN_ONCE() en ex_handler_uaccess() para no advertir sobre direcciones de usuarios no canónicas debido a LAM. Una vez implementado esto, vuelva a _ASM_EXTABLE_UA() para corregir excepciones de {get,put}_user() para poder manejar correctamente los MCE en el kernel nuevamente. [pb: mensaje de commit. ]
  
• Vulnerabilidad en kernel de Linux (CVE-2024-26675)
  Severidad: MEDIA
  Fecha de publicación: 02/04/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ppp_async: limitar MRU a 64K syzbot activó una advertencia [1] en __alloc_pages(): WARN_ON_ONCE_GFP(order > MAX_PAGE_ORDER, gfp) Willem solucionó un problema similar en el commit c0a2a1b0d631 ("ppp: limite MRU a 64K") Adopte la misma verificación de cordura para ppp_async_ioctl(PPPIOCSMRU) [1]: ADVERTENCIA: CPU: 1 PID: 11 en mm/page_alloc.c:4543 __alloc_pages+0x308/0x698 mm/page_alloc.c:4543 Módulos vinculados en: CPU: 1 PID: 11 Comm: kworker/u4:0 No contaminado 6.8.0-rc2-syzkaller-g41bccc98fb79 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 17/11/2023 Cola de trabajo: events_unbound flux_to_ldisc pstate: 204000c5 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __alloc_pages+0x308/0x698 mm/page_alloc.c:4543 lr : __alloc_pages+0xc8/0x698 mm/page_alloc.c:4537 sp: ffff800093967580 x29: ffff800093967660 x28: ffff8000939675a0 x27: dfff800000000000 x26: ffff70001272ceb4 x25: 0000000000000000 x24: ffff8000 939675c0 x23: 0000000000000000 x22: 0000000000060820 x21: 1ffff0001272ceb8 x20: ffff8000939675e0 x19: 0000000000000010 x18: ffff8000939671 20 x17: ffff800083bded5c x16: ffff80008ac97500 x15: 00000000000000005 x14: 1ffff0001272cebc x13: 0000000000000000 x12: 0000000000000000 x11: ffff70001272cec1 x10: 1ffff0001272cec0 x9: 0000000000000001 x8: ffff800091c 91000 x7: 0000000000000000 x6: 000000000000003f x5: 00000000ffffffff x4: 0000000000000000 x3: 00000000000000020 x2: 0000000000000008 x1: 0000000000000000 x0: ffff8000939675e0 Rastreo de llamadas: __alloc_pages+0x308/ 0x698 mm/page_alloc.c:4543 __alloc_pages_node include/linux/gfp.h:238 [en línea] alloc_pages_node include/linux/gfp.h:261 [en línea] __kmalloc_large_node+0xbc/0x1fc mm/slub.c:3926 __do_kmalloc_node mm/slub .c:3969 [en línea] __kmalloc_node_track_caller+0x418/0x620 mm/slub.c:4001 kmalloc_reserve+0x17c/0x23c net/core/skbuff.c:590 __alloc_skb+0x1c8/0x3d8 net/core/skbuff.c:651 __netdev_alloc_skb+0x b8 /0x3e8 net/core/skbuff.c:715 netdev_alloc_skb include/linux/skbuff.h:3235 [en línea] dev_alloc_skb include/linux/skbuff.h:3248 [en línea] ppp_async_input drivers/net/ppp/ppp_async.c:863 [ en línea] ppp_asynctty_receive+0x588/0x186c controladores/net/ppp/ppp_async.c:341 tty_ldisc_receive_buf+0x12c/0x15c controladores/tty/tty_buffer.c:390 tty_port_default_receive_buf+0x74/0xac controladores/tty/tty_port.c:37 recibir_buf controladores /tty /tty_buffer.c:444 [en línea] Flush_to_ldisc+0x284/0x6e4 controladores/tty/tty_buffer.c:494 Process_one_work+0x694/0x1204 kernel/workqueue.c:2633 Process_scheduled_works kernel/workqueue.c:2706 [en línea] trabajador_thread+0x938/ 0xef4 kernel/workqueue.c:2787 kthread+0x288/0x310 kernel/kthread.c:388 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860
  
• Vulnerabilidad en kernel de Linux (CVE-2024-26677)
  Severidad: MEDIA
  Fecha de publicación: 02/04/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: rxrpc: corrige los ACK retrasados para no establecer el número de serie de referencia. Se corrige la construcción de los ACK retrasados para no establecer el número de serie de referencia, ya que no se pueden usar como referencia RTT.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-26678)
  Severidad: MEDIA
  Fecha de publicación: 02/04/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/efistub: use archivo 1:1: mapeo de memoria para PE/COFF sección .compat La sección .compat es una sección PE ficticia que contiene la dirección del punto de entrada de 32 bits de la imagen del kernel de 64 bits si se puede iniciar desde firmware de 32 bits (es decir, CONFIG_EFI_MIXED=y) Esta sección tiene solo 8 bytes de tamaño y solo se hace referencia a ella desde el cargador, por lo que se coloca al final de la memoria. vista de la imagen, para evitar la necesidad de rellenarla a 4k, lo cual es necesario para las secciones que aparecen en el medio de la imagen. Desafortunadamente, esto viola la especificación PE/COFF, e incluso si la mayoría de los cargadores EFI funcionan correctamente (incluida la implementación de referencia de Tianocore), existen cargadores PE que rechazan dichas imágenes, basándose en que tanto las vistas de archivo como de memoria del contenido del archivo deben ser descritos por los encabezados de las secciones de manera monótonamente creciente sin dejar espacios en blanco. Así que reorganice las secciones para evitar este problema. Esto da como resultado una ligera sobrecarga de relleno (< 4k) que se puede evitar si se desea deshabilitando CONFIG_EFI_MIXED (que solo es necesario en casos excepcionales en estos días)
  
• Vulnerabilidad en kernel de Linux (CVE-2024-26679)
  Severidad: MEDIA
  Fecha de publicación: 02/04/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: inet: lee sk->sk_family una vez en inet_recv_error() se llama a inet_recv_error() sin mantener el bloqueo del socket. El socket IPv6 podría mutar a IPv4 con la opción de socket IPV6_ADDRFORM y generar una advertencia de KCSAN.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-26680)
  Severidad: MEDIA
  Fecha de publicación: 02/04/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: atlantic: corrige el mapeo DMA para el anillo PTP hwts. La función aq_ring_hwts_rx_alloc() asigna bytes AQ_CFG_RXDS_DEF adicionales para el anillo PTP HWTS, pero luego el aq_ring_free() genérico no tiene esto en cuenta. Cree y utilice una función específica para liberar el anillo HWTS y solucionar este problema. Seguimiento: [215.351607] ------------[ cortar aquí ]------------ [ 215.351612] DMA-API: atlantic 0000:4b:00.0: el controlador de dispositivo se libera Memoria DMA con diferente tamaño [dirección del dispositivo=0x00000000fbdd0000] [tamaño del mapa=34816 bytes] [tamaño de desasignación=32768 bytes] [215.351635] ADVERTENCIA: CPU: 33 PID: 10759 en kernel/dma/debug.c:988 check_unmap+0xa6f/ 0x2360... [215.581176] Seguimiento de llamadas: [215.583632] [215.585745]? show_trace_log_lvl+0x1c4/0x2df [215.590114]? show_trace_log_lvl+0x1c4/0x2df [215.594497]? debug_dma_free_coherent+0x196/0x210 [215.599305]? check_unmap+0xa6f/0x2360 [215.603147]? __advertir+0xca/0x1d0 [215.606391] ? check_unmap+0xa6f/0x2360 [215.610237]? report_bug+0x1ef/0x370 [215.613921]? handle_bug+0x3c/0x70 [215.617423]? exc_invalid_op+0x14/0x50 [215.621269]? asm_exc_invalid_op+0x16/0x20 [215.625480]? check_unmap+0xa6f/0x2360 [215.629331]? mark_lock.part.0+0xca/0xa40 [215.633445] debug_dma_free_coherent+0x196/0x210 [215.638079]? __pfx_debug_dma_free_coherent+0x10/0x10 [215.643242] ? slab_free_freelist_hook+0x11d/0x1d0 [ 215.648060] dma_free_attrs+0x6d/0x130 [ 215.651834] aq_ring_free+0x193/0x290 [atlántico] [ 215.656487] aq_ptp_ring_free+0x67/0x110 [atlántico]... [216.127540] ---[fin de seguimiento 6467e5964dd2640b]- -- [ 216.132160] DMA-API: Asignado en: [ 216.132162] debug_dma_alloc_coherent+0x66/0x2f0 [ 216.132165] dma_alloc_attrs+0xf5/0x1b0 [ 216.132168] aq_ring_hwts_rx_alloc+0x150 /0x1f0 [atlántico] [ 216.132193] aq_ptp_ring_alloc+0x1bb/0x540 [atlántico] [216.132213] aq_nic_init+0x4a1/0x760 [atlántico]
  
• Vulnerabilidad en kernel de Linux (CVE-2024-26681)
  Severidad: MEDIA
  Fecha de publicación: 02/04/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netdevsim: evita un posible bucle en nsim_dev_trap_report_work() Muchos informes de syzbot incluyen el siguiente seguimiento [1] Si nsim_dev_trap_report_work() no puede capturar el mutex, debería rearmarse al menos un santiamén después . [1] Envío de NMI desde la CPU 1 a las CPU 0: seguimiento de NMI para la CPU 0 CPU: 0 PID: 32383 Comm: kworker/0:2 Not tainted 6.8.0-rc2-syzkaller-00031-g861c0981648f #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 17/11/2023 Cola de trabajo: eventos nsim_dev_trap_report_work RIP: 0010:bytes_is_nonzero mm/kasan/generic.c:89 [en línea] RIP: 0010:memory_is_nonzero mm/kasan/generic.c:104 [ en línea] RIP: 0010:memory_is_poisoned_n mm/kasan/generic.c:129 [en línea] RIP: 0010:memory_is_poisoned mm/kasan/generic.c:161 [en línea] RIP: 0010:check_region_inline mm/kasan/generic.c:180 [en línea] RIP: 0010:kasan_check_range+0x101/0x190 mm/kasan/generic.c:189 Código: 07 49 39 d1 75 0a 45 3a 11 b8 01 00 00 00 7c 0b 44 89 c2 e8 21 ed ff ff 83 f0 01 5b 5d 41 5c c3 48 85 d2 74 4f 48 01 ea eb 09 <48> 83 c0 01 48 39 d0 74 41 80 38 00 74 f2 eb b6 41 bc 08 00 00 00 RSP: 0018:ffffc90012dcf998 EFLAGS: 00000046 RAX: ffffbfff258af1e RBX: ffffbfff258af1f RCX: ffffffff8168eda3 RDX: ffffbfff258af1f RSI: 0000000000000004 RDI: ffffffff92c578f0 RBP: ffffbfff258af1e R08: 00000000000000000 R09: f ffffbfff258af1e R10: ffffffff92c578f3 R11: ffffffff8acbcbc0 R12: 0000000000000002 R13: ffff88806db38400 R14: 1ffff920025b9f42 R15: ffffffff92c578e8 FS: 0000 000000000000(0000) GS: ffff8880b9800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000c00994e078 CR3: 000000002c250000 CR 4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 00000000000000000 DR6: 00000000ffe0ff0 DR7: 00000 00000000400 Seguimiento de llamadas: < NMI> instrument_atomic_read include/linux/instrumented.h:68 [en línea] atomic_read include/linux/atomic/atomic-instrumented.h:32 [en línea] queued_spin_is_locked include/asm-generic/qspinlock.h: 57 [en línea] debug_spin_unlock kernel/locking/spinlock_debug.c:101 [en línea] do_raw_spin_unlock+0x53/0x230 kernel/locking/spinlock_debug.c:141 __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:150 [en línea] _raw_spin_unlock_irqrestore +0x22/0x70 núcleo /locking/spinlock.c:194 debug_object_activate+0x349/0x540 lib/debugobjects.c:726 debug_work_activate kernel/workqueue.c:578 [en línea] insert_work+0x30/0x230 kernel/workqueue.c:1650 __queue_work+0x62e/0x11d0 kernel/ workqueue.c:1802 __queue_delayed_work+0x1bf/0x270 kernel/workqueue.c:1953 queue_delayed_work_on+0x106/0x130 kernel/workqueue.c:1989 queue_delayed_work include/linux/workqueue.h:563 [en línea] Schedule_delayed_work include/linux/workqueue.h :677 [en línea] nsim_dev_trap_report_work+0x9c0/0xc80 drivers/net/netdevsim/dev.c:842 Process_one_work+0x886/0x15d0 kernel/workqueue.c:2633 Process_scheduled_works kernel/workqueue.c:2706 [en línea] work_thread+0x8b9/0x1290 núcleo /workqueue.c:2787 kthread+0x2c6/0x3a0 kernel/kthread.c:388 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:242
  
• Vulnerabilidad en Kernel de Linux (CVE-2024-26682)
  Severidad: MEDIA
  Fecha de publicación: 02/04/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: "wifi: mac80211: improve CSA/ECSA connection refusal". Como se mencionó en el commit anterior, descubrimos rápidamente que algunos AP tienen elementos ECSA atascados en su respuesta de sondeo, por lo que no se pueden usar si intentamos conectarnos mientras se realiza CSA, nunca nos conectaremos a dicho AP. Mejore esta situación verificando más cuidadosamente e ignorando ECSA si cfg80211 ha detectado previamente que el elemento ECSA está atascado en la respuesta de la sonda. Además, permita conectarse a un AP que esté cambiando a un canal que ya esté usando, a menos que esté usando el modo silencioso. En este caso, es posible que tengamos que ajustar el ancho de banda más adelante. Si en realidad está cambiando de canal, es mejor no intentar conectarse en medio de eso.
  
• Vulnerabilidad en Kernel de Linux (CVE-2024-26683)
  Severidad: MEDIA
  Fecha de publicación: 02/04/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: "wifi: cfg80211: detect stuck ECSA element in probe resp". Recientemente agregamos alguna validación de que no intentamos conectarnos a un AP que se encuentra actualmente en un proceso de cambio de canal, desde entonces es posible que deseemos que el canal esté en silencio o que no podamos conectarnos a tiempo para escuchar el cambio en una baliza. Esto estaba en el commit c09c4f31998b ("wifi: mac80211: no se conecte a un AP mientras esté en un proceso CSA"). Sin embargo, rápidamente recibimos un informe de que esto causó nuevas fallas de conexión, y resulta que el AP al que ahora no podemos conectarnos anuncia permanentemente un anuncio de cambio de canal extendido, incluso en silencio. El AP en cuestión era un Asus RT-AC53, con firmware 3.0.0.4.380_10760-g21a5898. Como primer paso, intente detectar que estamos lidiando con una situación de este tipo, para que mac80211 pueda usarlo más adelante.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-26684)
  Severidad: MEDIA
  Fecha de publicación: 02/04/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: stmmac: xgmac: corrige el manejo del error de seguridad DPP para canales DMA. El commit 56e58d6c8a56 ("net: stmmac: Implement Safety Features in XGMAC core") verifica e informa errores de seguridad, pero deja sin controlar los errores de paridad de ruta de datos para cada canal en DMA, lo que provoca una tormenta de interrupciones. Solucionelo verificando y borrando el registro DMA_DPP_Interrupt_Status.
  
• Vulnerabilidad en WPFront User Role Editor para WordPress (CVE-2024-2931)
  Severidad: MEDIA
  Fecha de publicación: 02/04/2024
  Fecha de última actualización: 17/03/2025
  El complemento WPFront User Role Editor para WordPress es vulnerable a la exposición de información confidencial en todas las versiones hasta la 3.2.1.11184 incluida a través de la acción AJAX wpfront_user_role_editor_assign_roles_user_autocomplete. Esto hace posible que los atacantes autenticados, con acceso de nivel de suscriptor y superior, extraigan y recuperen una lista de todas las direcciones de correo electrónico de los usuarios que están registrados en el sitio.
  
• Vulnerabilidad en kernel de Linux (CVE-2023-52628)
  Severidad: ALTA
  Fecha de publicación: 28/03/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nftables: exthdr: corrige escritura OOB de pila de 4 bytes Si priv->len es múltiplo de 4, entonces dst[len / 4] puede escribir más allá de la matriz de destino que conduce a la corrupción de la pila. Esta construcción es necesaria para limpiar el resto del registro en caso de que ->len NO sea un múltiplo del tamaño del registro, así que hágalo condicional tal como lo hace nft_payload.c. El error se agregó en el ciclo 4.1 y luego se copió/heredó cuando se agregó la compatibilidad con las opciones tcp/sctp e ip. Error informado por el proyecto Zero Day Initiative (ZDI-CAN-21950, ZDI-CAN-21951, ZDI-CAN-21961).
  
• Vulnerabilidad en Tenda AC10U v15.03.06.48 (CVE-2024-30612)
  Severidad: ALTA
  Fecha de publicación: 28/03/2024
  Fecha de última actualización: 17/03/2025
  Tenda AC10U v15.03.06.48 tiene una vulnerabilidad de desbordamiento de la región stack de la memoria en el parámetro deviceId, limitSpeed, limitSpeedUp de la función formSetClientState.
  
• Vulnerabilidad en LayerSlider para WordPress (CVE-2024-2879)
  Severidad: CRÍTICA
  Fecha de publicación: 03/04/2024
  Fecha de última actualización: 17/03/2025
  El complemento LayerSlider para WordPress es vulnerable a la inyección SQL a través de la acción ls_get_popup_markup en las versiones 7.9.11 y 7.10.0 debido a un escape insuficiente en el parámetro proporcionado por el usuario y a la falta de preparación suficiente en la consulta SQL existente. Esto hace posible que atacantes no autenticados agreguen consultas SQL adicionales a consultas ya existentes que pueden usarse para extraer información confidencial de la base de datos.
  
• Vulnerabilidad en kernel de Linux, (CVE-2023-52621)
  Severidad: ALTA
  Fecha de publicación: 26/03/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: verifique rcu_read_lock_trace_held() antes de llamar a los ayudantes de mapas de bpf. Estos tres ayudantes de bpf_map_{lookup,update,delete}_elem() también están disponibles para el programa bpf que se puede dormir, así que agregue el bloqueo correspondiente. aserción para el programa bpf con capacidad para dormir; de lo contrario, se informará la siguiente advertencia cuando un programa bpf con capacidad para dormir manipule el mapa bpf en modo intérprete (también conocido como bpf_jit_enable=0): ADVERTENCIA: CPU: 3 PID: 4985 en kernel/bpf/helpers.c:40. ..... CPU: 3 PID: 4985 Comm: test_progs Not tainted 6.6.0+ #2 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996) ...... RIP: 0010:bpf_map_lookup_elem+0x54/0x60 ...... Seguimiento de llamadas: ? __advertir+0xa5/0x240 ? bpf_map_lookup_elem+0x54/0x60? report_bug+0x1ba/0x1f0? handle_bug+0x40/0x80? exc_invalid_op+0x18/0x50? asm_exc_invalid_op+0x1b/0x20? __pfx_bpf_map_lookup_elem+0x10/0x10 ? rcu_lockdep_current_cpu_online+0x65/0xb0? rcu_is_watching+0x23/0x50? bpf_map_lookup_elem+0x54/0x60? __pfx_bpf_map_lookup_elem+0x10/0x10 ___bpf_prog_run+0x513/0x3b70 __bpf_prog_run32+0x9d/0xd0 ? __bpf_prog_enter_sleepable_recur+0xad/0x120 ? __bpf_prog_enter_sleepable_recur+0x3e/0x120 bpf_trampoline_6442580665+0x4d/0x1000 __x64_sys_getpgid+0x5/0x30 ? do_syscall_64+0x36/0xb0 entrada_SYSCALL_64_after_hwframe+0x6e/0x76
  
• Vulnerabilidad en kernel de Linux (CVE-2023-52622)
  Severidad: MEDIA
  Fecha de publicación: 26/03/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: evita fallos de cambio de tamaño en línea debido a flex bg sobredimensionado Cuando redimensionamos en línea un sistema de archivos ext4 con un flexbg_size sobredimensionado, mkfs.ext4 -F -G 67108864 $dev -b 4096 100M mount $dev $dir resize2fs $dev 16G se activa el siguiente WARN_ON: ===================================== ============================== ADVERTENCIA: CPU: 0 PID: 427 en mm/page_alloc.c:4402 __alloc_pages+0x411/ 0x550 Módulos vinculados en: sg(E) CPU: 0 PID: 427 Comm: resize2fs Contaminado: GE 6.6.0-rc5+ #314 RIP: 0010:__alloc_pages+0x411/0x550 Seguimiento de llamadas: __kmalloc_large_node+0xa2/0x200 __kmalloc+ 0x16e/0x290 text4_resize_fs+0x481/0xd80 __ext4_ioctl+0x1616/0x1d90 text4_ioctl+0x12/0x20 __x64_sys_ioctl+0xf0/0x150 do_syscall_64+0x3b/0x90 ======== =============== ============================================ Esto se debe a que flexbg_size también lo es grande y el tamaño de la matriz new_group_data que se asignará excede MAX_ORDER. Actualmente, el valor mínimo de MAX_ORDER es 8, el valor mínimo de PAGE_SIZE es 4096, el número máximo correspondiente de grupos que se pueden asignar es: (PAGE_SIZE << MAX_ORDER) / sizeof(struct text4_new_group_data) ? 21845 Y el valor que está hacia abajo -alineado a la potencia de 2 es 16384. Por lo tanto, este valor se define como MAX_RESIZE_BG, y el número de grupos agregados cada vez no excede este valor durante el cambio de tamaño y se agrega varias veces para completar el cambio de tamaño en línea. La diferencia es que los metadatos en flex_bg pueden estar más dispersos.
  
• Vulnerabilidad en kernel de Linux (CVE-2023-52624)
  Severidad: ALTA
  Fecha de publicación: 26/03/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Activa DMCUB antes de ejecutar comandos GPINT [Por qué] DMCUB puede estar inactivo cuando intentamos interactuar con el HW a través del buzón GPINT, lo que provoca un bloqueo del sistema. [Cómo] Agregue dc_wake_and_execute_gpint() para ajustar la secuencia de activación, ejecución y suspensión. Si GPINT se ejecuta correctamente, DMCUB volverá a entrar en modo de suspensión después de que se devuelva la respuesta opcional. Funciona de manera similar a la interfaz de comando de la bandeja de entrada.
  
• Vulnerabilidad en kernel de Linux (CVE-2023-52625)
  Severidad: MEDIA
  Fecha de publicación: 26/03/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Refactor DMCUB entra/sale de la interfaz inactiva [Por qué] Podemos quedarnos quietos intentando enviar comandos cuando el DMCUB no está encendido. [Cómo] Necesitamos salir del estado inactivo antes de enviar un comando, pero el proceso que realiza la salida también invoca un comando en sí. Solucionar este problema implica lo siguiente: 1. Usar un estado de software para rastrear si necesitamos o no iniciar el proceso para salir de inactivo o notificarlo. Es posible que el hardware haya salido de un estado inactivo sin el conocimiento del controlador, pero ingresar a uno siempre está restringido a un permiso del controlador, lo que hace que el problema de discrepancia entre el estado del SW y el estado del HW sea puramente de optimización, que rara vez debería solucionarse, en todo caso. . 2. Refactorice cualquier instancia de salida/notificación inactiva para utilizar un contenedor único que mantenga este estado de software. Esto funciona de manera similar a dc_allow_idle_optimizations, pero funciona en el nivel DMCUB y garantiza que el estado esté marcado antes de cualquier notificación/salida inactiva para que no entremos en un bucle infinito. 3. Asegúrese de salir del modo inactivo antes de enviar cualquier comando o esperar a que DMCUB esté inactivo. Este parche se ocupa de la mitad. Un parche futuro se encargará de empaquetar el envío de comandos DMCUB con llamadas a esta nueva interfaz.
  
• Vulnerabilidad en kernel de Linux (CVE-2023-52626)
  Severidad: ALTA
  Fecha de publicación: 26/03/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net/mlx5e: se corrigió el error de precedencia de operación en la marca de tiempo del puerto contexto napi_poll La indirección (*) tiene menor prioridad que el incremento de postfijo (++). La lógica en el contexto napi_poll provocaría una lectura fuera de los límites al incrementar primero la dirección del puntero por espacio de direcciones de bytes y luego desreferenciar el valor. Más bien, la lógica prevista era desreferenciar primero y luego incrementar el valor subyacente.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-26644)
  Severidad: MEDIA
  Fecha de publicación: 26/03/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: no aborte el sistema de archivos al intentar crear una instantánea del subvolumen eliminado. Si el descriptor del archivo fuente de la instantánea ioctl se refiere a un subvolumen eliminado, obtenemos la siguiente cancelación: BTRFS: transacción abortada (error -2) ADVERTENCIA: CPU: 0 PID: 833 en fs/btrfs/transaction.c:1875 create_pending_snapshot+0x1040/0x1190 [btrfs] Módulos vinculados en: pata_acpi btrfs ata_piix libata scsi_mod virtio_net blake2b_generic xor net_failover virtio_rng failover scsi_common rng_core raid6_pq libcrc32c CPU: 0 PID: 833 Comm: t_snapshot_dele No contaminado 6.7.0-rc6 #2 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 01/04/2014 RIP: 0010:create_pending_snapshot +0x1040/0x1190 [btrfs] RSP: 0018:ffffa09c01337af8 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff9982053e7c78 RCX: 0000000000000027 RDX: ffff99 827dc20848 RSI: 0000000000000001 RDI: ffff99827dc20840 RBP: ffffa09c01337c00 R08: 00000000000000000 R09: ffffa09c01337998 R10: 000000000000000003 R11: ffffffffb96da248 R12: fffffffffffffffe R13: ffff99820535bb28 R14: ffff99820b7bd000 R15: ffff99820381ea80 FS: 00007fe20aadabc0(0000) GS:ffff99827dc00000(0000) knlGS:000000000000 0000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000559a120b502f CR3: 00000000055b6000 CR4: 00000000000006f0 Rastreo de llamadas: < TAREA> ? create_pending_snapshot+0x1040/0x1190 [btrfs]? __advertir+0x81/0x130 ? create_pending_snapshot+0x1040/0x1190 [btrfs]? report_bug+0x171/0x1a0? handle_bug+0x3a/0x70? exc_invalid_op+0x17/0x70? asm_exc_invalid_op+0x1a/0x20? create_pending_snapshot+0x1040/0x1190 [btrfs]? create_pending_snapshot+0x1040/0x1190 [btrfs] create_pending_snapshots+0x92/0xc0 [btrfs] btrfs_commit_transaction+0x66b/0xf40 [btrfs] btrfs_mksubvol+0x301/0x4d0 [btrfs] btrfs_mksnapshot+0x8 0/0xb0 [btrfs] __btrfs_ioctl_snap_create+0x1c2/0x1d0 [btrfs] btrfs_ioctl_snap_create_v2+ 0xc4/0x150 [btrfs] btrfs_ioctl+0x8a6/0x2650 [btrfs] ? kmem_cache_free+0x22/0x340? do_sys_openat2+0x97/0xe0 __x64_sys_ioctl+0x97/0xd0 do_syscall_64+0x46/0xf0 Entry_SYSCALL_64_after_hwframe+0x6e/0x76 RIP: 0033:0x7fe20abe83af RSP: 002b:00007ffe6eff13 60 EFLAGS: 00000246 ORIG_RAX: 00000000000000010 RAX: ffffffffffffffda RBX: 00000000000000004 RCX: 00007fe20abe83af RDX: 00007ffe6eff23c0 RSI: 0000000050009417 RDI: 0000000000000003 RBP: 0000000000000003 R08: 0000000000000000 R09: 00007fe20ad16cd0 R10: 0000000000000000 R11: 00 00000000000246 R12: 0000000000000000 R13: 00007ffe6eff13c0 R14: 00007fe20ad45000 R15: 0000559a120b6d58 ---[ final de seguimiento 0000000000000000 ]--- BTRFS: error ( dispositivo vdc: estado A) en create_pending_snapshot:1875: errno=-2 No existe tal entrada Información BTRFS (dispositivo vdc: estado EA): solo lectura forzada Advertencia BTRFS (dispositivo vdc: estado EA): omitir confirmación de transacción abortada. BTRFS: error (dispositivo vdc: estado EA) en cleanup_transaction:2055: errno=-2 No existe tal entrada. Esto sucede porque create_pending_snapshot() inicializa el nuevo elemento raíz como una copia del elemento raíz de origen. Esto incluye el campo de referencias, que es 0 para un subvolumen eliminado. Por lo tanto, la llamada a btrfs_insert_root() inserta una raíz con refs == 0. btrfs_get_new_fs_root() luego encuentra la raíz y devuelve -ENOENT si refs == 0, lo que hace que create_pending_snapshot() aborte. Solucionelo verificando las referencias de la raíz de origen antes de intentar la instantánea, pero después de bloquear subvol_sem para evitar correr con la eliminación.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-26645)
  Severidad: MEDIA
  Fecha de publicación: 26/03/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rastreo: garantiza la visibilidad al insertar un elemento en tracing_map La ejecución de los siguientes dos comandos en paralelo en una máquina multiprocesador AArch64 puede producir esporádicamente una advertencia inesperada sobre entradas de histograma duplicadas: $ while true ; hacer echo hist:key=id.syscall:val=hitcount > \ /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/trigger cat /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/hist sleep 0.001 done $ estrés-ng --sysbadaddr $(nproc) La advertencia tiene el siguiente aspecto: [ 2911.172474] ------------[ cortar aquí ]------------ [ 2911.173111] Duplicados detectados: 1 [2911.173574] ADVERTENCIA: CPU: 2 PID: 12247 en kernel/trace/tracing_map.c:983 tracing_map_sort_entries+0x3e0/0x408 [2911.174702] Módulos vinculados en: iscsi_ibft(E) iscsi_boot_sy sfs(E) rfkill(E ) af_packet(E) nls_iso8859_1(E) nls_cp437(E) vfat(E) fat(E) ena(E) tiny_power_button(E) qemu_fw_cfg(E) botón(E) fusible(E) efi_pstore(E) ip_tables(E) x_tables (E) xfs(E) libcrc32c(E) aes_ce_blk(E) aes_ce_cipher(E) crct10dif_ce(E) polyval_ce(E) polyval_generic(E) ghash_ce(E) gf128mul(E) sm4_ce_gcm(E) sm4_ce_ccm(E) sm4_ce(E ) sm4_ce_cipher(E) sm4(E) sm3_ce(E) sm3(E) sha3_ce(E) sha512_ce(E) sha512_arm64(E) sha2_ce(E) sha256_arm64(E) nvme(E) sha1_ce(E) nvme_core(E) nvme_auth (E) t10_pi(E) sg(E) scsi_mod(E) scsi_common(E) efivarfs(E) [ 2911.174738] Módulos contaminados descargados: cppc_cpufreq(E):1 [ 2911.180985] CPU: 2 PID: 12247 Comm: cat Kdump: cargado Contaminado: GE 6.7.0-default #2 1b58bbb22c97e4399dc09f92d309344f69c44a01 [2911.182398] Nombre de hardware: Amazon EC2 c7g.8xlarge/, BIOS 1.0 1/11/2018 [2911.183208] pstate: 6140 0005 (nZCv daif +PAN -UAO -TCO +DIT - SSBS BTYPE=--) [ 2911.184038] pc : tracing_map_sort_entries+0x3e0/0x408 [ 2911.184667] lr : tracing_map_sort_entries+0x3e0/0x408 [ 2911.185310] sp : ffff8000a1513900 [ 2911.18 5750] x29: ffff8000a1513900 x28: ffff0003f272fe80 x27: 0000000000000001 [ 2911.186600] x26: ffff0003f272fe80 x25: 0000000000000030 x24: 00000000000000008 [ 2911.187458] x23: ffff0003c5788000 x22: ffff0003c16710c8 x21: ffff80008017f180 [ 2911.1883 10] x20: ffff80008017f000 x19: ffff80008017f180 x18: ffffffffffffffff [ 2911.189160] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000a151 34b8 [2911.190015] x14: 0000000000000000 x13: 205d373432323154 x12: 5b5d313131333731 [ 2911.190844] x11: 00000000fffeffff x10: 00000000fffeffff x9 : ffffd1b78274a13c [ 2911.191716] x8 : 00 0000000017ffe8 x7: c0000000fffeffff x6: 000000000057ffa8 [2911.192554] x5: ffff0012f6c24ec0 x4: 00000000000000000 x3: ffff2e5b72b5d000 [2911.193 404] x2: 0000000000000000 x1: 0000000000000000 x0 : ffff0003ff254480 [2911.194259] Rastreo de llamadas: [2911.194626] tracing_map_sort_entries+0x3e0/0x408 [2911.195220] hist_show+0x124/0x800 [2911.195692] seq_read_iter+0x1d4 /0x4e8 [ 2911.196193] seq_read+0xe8/0x138 [ 2911.196638] vfs_read+0xc8/0x300 [ 2911.197078 ] ksys_read+0x70/0x108 [ 2911.197534] __arm64_sys_read+0x24/0x38 [ 2911.198046] invoke_syscall+0x78/0x108 [ 2911.198553] el0_svc_common.constprop.0+0xd0/0x f8 [ 2911.199157] do_el0_svc+0x28/0x40 [ 2911.199613] el0_svc+0x40/0x178 [ 2911.200048] el0t_64_sync_handler+0x13c/0x158 [ 2911.200621] el0t_64_sync+0x1a8/0x1b0 [ 2911.201115] ---[ end trace 0000000000000000 ]--- El problema parece deberse a la reordenación de la CPU de escrituras emitidas desde __tracing_map_insert(). La comprobación de la presencia de un elemento con una clave determinada en esta función es: val = READ_ONCE(entry->val); if (val && llaves_match(key, val->key, map->key_size)) ... La escritura de una nueva entrada es: elt = get_free_elt(map); memcpy(elt->clave, clave, mapa->key_size); entrada->val = elt; El "memcpy(elt->key, key, map->key_size);" y "entrada->val = elt;" Las tiendas pueden volverse visibles en orden inverso en otra CPU.---truncada---
  
• Vulnerabilidad en kernel de Linux (CVE-2024-26646)
  Severidad: MEDIA
  Fecha de publicación: 26/03/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: térmica: intel: hfi: agregar devoluciones de llamada de syscore para PM en todo el sistema El kernel asigna un búfer de memoria y proporciona su ubicación al hardware, que lo utiliza para actualizar la tabla HFI. Esta asignación ocurre durante el arranque y permanece constante durante el tiempo de ejecución. Al salir de la hibernación, el kernel de restauración asigna un segundo búfer de memoria y reprograma el hardware HFI con la nueva ubicación como parte de un inicio normal. La ubicación del segundo búfer de memoria puede diferir de la asignada por el núcleo de la imagen. Cuando el kernel de restauración transfiere el control al kernel de imagen, su búfer HFI deja de ser válido, lo que puede provocar daños en la memoria si el hardware escribe en él (el hardware continúa usando el búfer del kernel de restauración). También es posible que el hardware "olvide" la dirección del búfer de memoria al reanudar desde una suspensión "profunda". En tal escenario también puede ocurrir corrupción de memoria. Para evitar la corrupción de memoria descrita, desactive HFI cuando se prepare para suspender o hibernar. Habilítelo al reanudar. Agregue devoluciones de llamada de syscore para manejar el paquete de la CPU de arranque (los paquetes de CPU que no son de arranque se manejan a través de la CPU sin conexión). Las operaciones de Syscore siempre se ejecutan en la CPU de arranque. Además, HFI solo necesita desactivarse durante la suspensión e hibernación "profundas". Las operaciones de Syscore solo se ejecutan en estos casos. [rjw: ajuste de comentarios, ediciones de asunto y registro de cambios]
  
• Vulnerabilidad en kernel de Linux (CVE-2023-52639)
  Severidad: MEDIA
  Fecha de publicación: 03/04/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: KVM: s390: vsie: corrige la ejecución durante la creación de la sombra. En este momento es posible ver que gmap->private es cero en kvm_s390_vsie_gmap_notifier, lo que provoca un bloqueo. Esto se debe al hecho de que agregamos gmap->private == kvm después de la creación: static int adquirir_gmap_shadow(struct kvm_vcpu *vcpu, struct vsie_page *vsie_page) { [...] gmap = gmap_shadow(vcpu->arch.gmap, asce, edat); si (IS_ERR(gmap)) devuelve PTR_ERR(gmap); gmap->privado = vcpu->kvm; Deje que los niños hereden el campo privado del padre.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-26686)
  Severidad: MEDIA
  Fecha de publicación: 03/04/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs/proc: do_task_stat: use sig->stats_lock para recopilar las estadísticas de subprocesos/hijos lock_task_sighand() puede desencadenar un bloqueo completo. Si los subprocesos NR_CPUS llaman a do_task_stat() al mismo tiempo y el proceso tiene NR_THREADS, girará con irqs deshabilitados O(NR_CPUS * NR_THREADS) tiempo. Cambie do_task_stat() para usar sig->stats_lock para recopilar las estadísticas fuera de ->sección protegida siglock, en el caso probable de que este código se ejecute sin bloqueo.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-26687)
  Severidad: MEDIA
  Fecha de publicación: 03/04/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: xen/events: cierre evtchn después de la limpieza del mapeo. Shutdown_pirq y startup_pirq no están tomando irq_mapping_update_lock porque no pueden hacerlo debido a la inversión de bloqueo. Ambos se llaman con el irq_desc->lock en curso. Sin embargo, el orden de bloqueo es primero irq_mapping_update_lock y luego irq_desc->lock. Esto abre múltiples ejecucións: - Shutdown_pirq puede ser interrumpido por una función que asigna un canal de evento: CPU0 CPU1 Shutdown_pirq { xen_evtchn_close(e) __startup_pirq { EVTCHNOP_bind_pirq -> devuelve el evtchn e set_evtchn_to_irq(e, irq) recién liberado} xen_irq_info_cleanup() { set_evtchn_to_irq( e, -1) } } Supongamos que aquí el canal de eventos e se refiere aquí al mismo número de canal de eventos. Después de esta ejecución, el mapeo evtchn_to_irq para e no es válido (-1). - __startup_pirq compite con __unbind_from_irq de manera similar. Debido a que __startup_pirq no toma irq_mapping_update_lock, puede tomar el evtchn que __unbind_from_irq está liberando y limpiando actualmente. En este caso, aunque el canal de eventos esté asignado, su asignación se puede desarmar en evtchn_to_irq. La solución es limpiar primero las asignaciones y luego cerrar el canal de eventos. De esta manera, cuando se asigna un canal de eventos, se garantiza que sus posibles asignaciones anteriores de evtchn_to_irq ya no estarán configuradas. Este es también el orden inverso de la asignación donde primero se asigna el canal de evento y luego se configuran las asignaciones. En un kernel 5.10 antes de commit 3fcdaf3d7634 ("xen/events: modificar interfaces internas [un]bind"), encontramos un ERROR como el siguiente durante el sondeo de dispositivos NVMe. El problema es que durante nvme_setup_io_queues, se llama a pci_free_irq para cada dispositivo, lo que resulta en una llamada a Shutdown_pirq. Por lo tanto, con muchos dispositivos nvme es probable que alcance esta ejecución durante el arranque porque habrá múltiples llamadas a Shutdown_pirq y startup_pirq que se ejecutan potencialmente en paralelo. ------------[ cortar aquí ]------------ blkfront: xvda: barrera o descarga: deshabilitado; subvenciones persistentes: habilitadas; descriptores indirectos: habilitado; búfer de rebote: ¡ERROR del kernel habilitado en drivers/xen/events/events_base.c:499! código de operación no válido: 0000 [#1] SMP PTI CPU: 44 PID: 375 Comm: kworker/u257:23 No contaminado 5.10.201-191.748.amzn2.x86_64 #1 Nombre de hardware: Xen HVM domU, BIOS 4.11.amazon 24/08 /2006 Cola de trabajo: nvme-reset-wq nvme_reset_work RIP: 0010:bind_evtchn_to_cpu+0xdf/0xf0 Código: 5d 41 5e c3 cc cc cc cc 44 89 f7 e8 2b 55 ad ff 49 89 c5 48 85 c0 0f 84 64 ff ff ff 4c 8b 68 30 41 83 fe ff 0f 85 60 ff ff ff <0f> 0b 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 0f 1f 44 00 00 RSP: 0000:ffffc9000d533b08 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000006 RDX: 0000000000000028 RSI: 00000000ffffffff RDI: 00000000ffffffff RBP: ffff888107419680 R08: 00000000000 00000 R09: ffffffff82d72b00 R10: 00000000000000000 R11: 0000000000000000 R12: 00000000000001ed R13: 00000000000000000 R14: 00000000ffffffff R15 : 0000000000000002 FS: 0000000000000000(0000) GS:ffff88bc8b500000( 0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000000000 CR3: 0000000002610001 CR4: 000000000017 06e0 DR0: 0000000000000000 DR1: 00000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: ? show_trace_log_lvl+0x1c1/0x2d9? show_trace_log_lvl+0x1c1/0x2d9? set_affinity_irq+0xdc/0x1c0? __die_body.cold+0x8/0xd ? morir+0x2b/0x50 ? do_trap+0x90/0x110? bind_evtchn_to_cpu+0xdf/0xf0? do_error_trap+0x65/0x80? bind_evtchn_to_cpu+0xdf/0xf0? exc_invalid_op+0x4e/0x70? bind_evtchn_to_cpu+0xdf/0xf0? asm_exc_invalid_op+0x12/0x20? bind_evtchn_to_cpu+0xdf/0x ---truncado---
  
• Vulnerabilidad en kernel de Linux (CVE-2024-26692)
  Severidad: MEDIA
  Fecha de publicación: 03/04/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: smb: se corrigió la regresión en las escrituras cuando se negoció un tamaño de escritura máximo no estándar. La conversión a netfs en el kernel 6.3 provocó una regresión cuando el servidor estableció el tamaño de escritura máximo en un valor inesperado. que no es un múltiplo de 4096 (de manera similar, si el usuario anula el tamaño máximo de escritura configurando el parámetro de montaje "wsize", pero lo establece en un valor que no es un múltiplo de 4096). Cuando el tamaño de escritura negociado no es un múltiplo de 4096, el código netfs puede omitir el final de la página final al realizar escrituras secuenciales grandes, lo que provoca corrupción de datos. Esta sección de código se está reescribiendo/eliminando debido a un gran cambio en netfs, pero hasta ese momento (es decir, para el kernel 6.3 hasta ahora) no podemos admitir tamaños máximos de escritura no estándar. Agregue una advertencia si un usuario especifica un wsize en el montaje que no es un múltiplo de 4096 (y redondea hacia abajo), también agregue un cambio donde redondeamos hacia abajo el tamaño máximo de escritura si el servidor negocia un valor que no es un múltiplo de 4096 ( también tenemos que comprobar que no lo redondeamos a cero).
  
• Vulnerabilidad en kernel de Linux (CVE-2024-26693)
  Severidad: MEDIA
  Fecha de publicación: 03/04/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux se ha solucionado la siguiente vulnerabilidad: wifi: iwlwifi: mvm: soluciona un fallo cuando nos quedamos sin estaciones Una herramienta DoS que inyecta un montón de marcos de autenticación hacía que nuestro AP fallara. La función iwl_mvm_is_dup() no pudo encontrar los datos dup_data por cola que no estaban asignados. La causa principal de esto es que nos quedamos sin estaciones en el firmware y realmente no agregamos la estación al firmware, pero no devolvimos un error a mac80211. Mac80211 estaba pensando que teníamos la estación y debido a eso, sta_info::uploaded se configuró en 1. Esto permitió que ieee80211_find_sta_by_ifaddr() devolviera un objeto de estación válido, pero que ieee80211_sta no tenía ningún objeto iwl_mvm_sta inicializado y eso causó el bloqueo. Mencioné anteriormente cuando obtuvimos Rx en esa estación.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-26696)
  Severidad: MEDIA
  Fecha de publicación: 03/04/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: nilfs2: corrige un bloqueo en nilfs_lookup_dirty_data_buffers() Syzbot informó un problema de bloqueo en migrar_pages_batch() llamado por mbind() y nilfs_lookup_dirty_data_buffers() llamado en el escritor de registros de nilfs2. Mientras migrar_pages_batch() bloquea una publicación y espera a que se complete la reescritura, el subproceso del escritor de registros que debería completar la reescritura recoge la publicación que se está reescribiendo en nilfs_lookup_dirty_data_buffers() que solicita la creación de registros posteriores y estaba intentando bloquear la fol. Provocando así un punto muerto. En primer lugar, es inesperado que los folios/páginas en medio de la reescritura se actualicen y se ensucien. Nilfs2 agrega una suma de verificación para verificar la validez del registro que se está escribiendo y la usa para la recuperación en el montaje, de modo que se suprimen los cambios de datos durante la reescritura. Dado que esto no funciona, un cierre incorrecto podría provocar que falle la recuperación. La investigación reveló que la causa principal es que la espera para que se complete la reescritura en nilfs_page_mkwrite() es condicional, y si el dispositivo de respaldo no requiere escrituras estables, los datos se pueden modificar sin esperar. Solucione estos problemas haciendo que nilfs_page_mkwrite() espere a que finalice la reescritura independientemente del requisito de escritura estable del dispositivo de respaldo.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-26697)
  Severidad: MEDIA
  Fecha de publicación: 03/04/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: nilfs2: corrige la corrupción de datos en la recuperación de bloques dsync para tamaños de bloques pequeños La función auxiliar nilfs_recovery_copy_block() de nilfs_recovery_dsync_blocks(), que recupera datos de los registros creados por escrituras de sincronización de datos durante un montaje después un apagado incorrecto calcula incorrectamente el desplazamiento en la página al copiar los datos de reparación en la memoria caché de la página del archivo. En entornos donde el tamaño del bloque es menor que el tamaño de la página, esta falla puede causar corrupción de datos y pérdida de bytes de memoria no inicializados durante el proceso de recuperación. Solucione estos problemas corrigiendo este cálculo de desplazamiento de bytes en la página.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-26698)
  Severidad: MEDIA
  Fecha de publicación: 03/04/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: hv_netvsc: corrige la condición de ejecución entre netvsc_probe y netvsc_remove En el commit ac5047671758 ("hv_netvsc: deshabilite NAPI antes de cerrar el canal VMBus"), se llamaba a napi_disable para todos los canales, incluidos todos los subcanales sin confirmando si están habilitados o no. Esto provocó que hv_netvsc se colgara en napi_disable, cuando netvsc_probe() terminó de ejecutarse pero nvdev->subchan_work aún no se inició. netvsc_subchan_work() -> rndis_set_subchannel() no ha creado los subcanales y por eso netvsc_sc_open() no se está ejecutando. netvsc_remove() llama a cancel_work_sync(&nvdev->subchan_work), para lo cual netvsc_subchan_work no se ejecutó. netif_napi_add() establece el bit NAPI_STATE_SCHED porque garantiza que NAPI no se pueda programar. Luego netvsc_sc_open() -> napi_enable borrará el bit NAPIF_STATE_SCHED, para que pueda programarse. napi_disable() hace lo contrario. Ahora, durante netvsc_device_remove(), cuando se llama a napi_disable para esos subcanales, napi_disable se atasca en msleep infinito. Esta solución soluciona este problema garantizando que no se llame a napi_disable() para una estructura NAPI no habilitada. Pero netif_napi_del() sigue siendo necesario para estas estructuras NAPI no habilitadas con fines de limpieza. Rastreo de llamadas: [654.559417] tarea:modprobe estado:D pila: 0 pid: 2321 ppid: 1091 banderas:0x00004002 [654.568030] Rastreo de llamadas: [654.571221] [654.573790] __schedule+0x2d6/0x960 [ 65 4.577733] horario+0x69 /0xf0 [654.581214] Schedule_timeout+0x87/0x140 [654.585463]? __bpf_trace_tick_stop+0x20/0x20 [ 654.590291] msleep+0x2d/0x40 [ 654.593625] napi_disable+0x2b/0x80 [ 654.597437] netvsc_device_remove+0x8a/0x1f0 [hv_netvsc] [ 6 54.603935] rndis_filter_device_remove+0x194/0x1c0 [hv_netvsc] [654.611101]? do_wait_intr+0xb0/0xb0 [ 654.615753] netvsc_remove+0x7c/0x120 [hv_netvsc] [ 654.621675] vmbus_remove+0x27/0x40 [hv_vmbus]
  
• Vulnerabilidad en kernel de Linux (CVE-2024-26705)
  Severidad: MEDIA
  Fecha de publicación: 03/04/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: parisc: BTLB: soluciona el problema al configurar BTLB al iniciar la CPU. Al usar hotplug y activar una CPU de 32 bits, solicite al firmware la información de BTLB para configurar la estática ( bloque) Entradas TLB. Para eso se necesita acceso de escritura a la estructura estática btlb_info, pero como está marcada como __ro_after_init, el kernel falla por defecto y faltan permisos de escritura. Solucione el problema eliminando la anotación __ro_after_init.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-26706)
  Severidad: MEDIA
  Fecha de publicación: 03/04/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: parisc: corrige la corrupción aleatoria de datos del controlador de excepciones La implementación actual del controlador de excepciones, que ayuda al acceder a la memoria del espacio del usuario, puede exhibir corrupción aleatoria de datos si el compilador decide usar un registro diferente al el registro especificado %r29 (definido en ASM_EXCEPTIONTABLE_REG) para el código de error. Si el compilador elige otro registro, el manejador de fallas almacenará -EFAULT en %r29 y, por lo tanto, eliminará cualquier cosa para la que se utilice este registro. Al observar el ensamblaje, encontré que esto sucede a veces en emulate_ldd(). Para resolver el problema, la solución más sencilla sería si de alguna manera fuera posible decirle al manejador de fallas qué registro se utiliza para contener el código de error. No es posible usar %0 o %1 en el ensamblador en línea ya que aparecerá, por ejemplo, como %r29 (con el prefijo "%r"), que el ensamblador GNU no puede convertir a un número entero. Este parche adopta otro enfoque mejor y más flexible: ampliamos el __ex_table (que está fuera de la ruta de ejecución) en 32 palabras. En esta palabra le decimos al compilador que inserte la instrucción ensambladora "o %r0,%r0,%reg", donde %reg hace referencia al registro que el compilador eligió para el código de retorno de error. En caso de un error de acceso, el controlador de fallas encuentra la entrada __ex_table y puede examinar el código de operación. El registro utilizado está codificado en los 5 bits más bajos y el manejador de fallas puede almacenar -EFAULT en este registro. Dado que ampliamos __ex_table a 3 palabras, ya no podemos usar la opción de configuración BUILDTIME_TABLE_SORT.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-26707)
  Severidad: MEDIA
  Fecha de publicación: 03/04/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: hsr: eliminar WARN_ONCE() en send_hsr_supervision_frame() Syzkaller informó [1] que apareció una advertencia después de no poder asignar recursos para skb en hsr_init_skb(). Dado que una llamada WARN_ONCE() no ayudará mucho en este caso, podría ser prudente cambiar a netdev_warn_once(). Como mínimo, suprimirá informes de syzkaller como [1]. Por las dudas, utilice netdev_warn_once() en send_prp_supervision_frame() por motivos similares. [1] HSR: No se pudo enviar la trama de supervisión ADVERTENCIA: CPU: 1 PID: 85 en net/hsr/hsr_device.c:294 send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294 RIP: 0010:send_hsr_supervision_frame+0x60a/ 0x810 net/hsr/hsr_device.c:294 ... Seguimiento de llamadas: hsr_announce+0x114/0x370 net/hsr/hsr_device.c:382 call_timer_fn+0x193/0x590 kernel/time/timer.c:1700 expire_timers kernel/ time/timer.c:1751 [en línea] __run_timers+0x764/0xb20 kernel/time/timer.c:2022 run_timer_softirq+0x58/0xd0 kernel/time/timer.c:2035 __do_softirq+0x21a/0x8de kernel/softirq.c:553 invoke_softirq kernel/softirq.c:427 [en línea] __irq_exit_rcu kernel/softirq.c:632 [en línea] irq_exit_rcu+0xb7/0x120 kernel/softirq.c:644 sysvec_apic_timer_interrupt+0x95/0xb0 arch/x86/kernel/apic/apic.c :1076 asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:649 ... Este problema también se encuentra en kernels más antiguos (al menos hasta 5.10).
  
• Vulnerabilidad en kernel de Linux (CVE-2024-26710)
  Severidad: MEDIA
  Fecha de publicación: 03/04/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: powerpc/kasan: limitar el aumento del tamaño del subproceso KASAN a 32 KB. Se considera que KASAN aumenta el uso de la pila, hasta el punto de que se informó que provoca un desbordamiento de la pila en algunas máquinas de 32 bits ( ver enlace). Para evitar desbordamientos, el tamaño de la pila se duplicó para las compilaciones de KASAN en el commit 3e8635fb2e07 ("powerpc/kasan: Forzar el aumento del tamaño del subproceso con KASAN"). Sin embargo, con un tamaño de pila de 32 KB para empezar, la duplicación conduce a una pila de 64 KB, lo que provoca errores de compilación: arch/powerpc/kernel/switch.S:249: Error: operando fuera de rango (0x000000000000fe50 no está entre 0xffffffffffff8000 y 0x00000000000007fff) Aunque el conjunto podría modificarse, en la práctica una pila de 32 KB parece suficiente incluso para compilaciones KASAN; el uso adicional parece estar en el rango de 2 a 3 KB para una compilación KASAN de 64 bits. Por lo tanto, solo aumente la pila para KASAN si el tamaño de la pila es <32 KB.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-26714)
  Severidad: MEDIA
  Fecha de publicación: 03/04/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: interconexión: qcom: sc8180x: Mark CO0 BCM keepalive El CO0 BCM debe estar activo en todo momento; de lo contrario, algún hardware (como el controlador UFS) pierde su conexión con el resto del SoC, lo que provocó un bloqueo de la plataforma, acompañado de un espectacular logspam. Márquelo como keepalive para evitar tales casos.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-26718)
  Severidad: MEDIA
  Fecha de publicación: 03/04/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dm-crypt, dm-verity: deshabilitar tasklets Los tasklets tienen un problema inherente con la corrupción de la memoria. La función tasklet_action_common llama a tasklet_trylock, luego llama a la devolución de llamada del tasklet y luego llama a tasklet_unlock. Si la devolución de llamada del tasklet libera la estructura que contiene el tasklet o si llama a algún código que pueda liberarlo, tasklet_unlock escribirá en la memoria libre. Las confirmaciones 8e14f610159d y d9a02e016aaf intentan solucionarlo para dm-crypt, pero no es una solución suficiente y la corrupción de datos aún puede ocurrir [1]. No hay ninguna solución para dm-verity y dm-verity escribirá en la memoria libre con cada biografía procesada por tasklet. Habrá colas de trabajo atómicas implementadas en el kernel 6.9 [2]. Tendrán una mejor interfaz y no sufrirán el problema de corrupción de memoria. Pero necesitamos algo que detenga la corrupción de la memoria ahora y que pueda ser compatible con los núcleos estables. Entonces, propongo esta confirmación que deshabilita los tasklets tanto en dm-crypt como en dm-verity. Esta confirmación no elimina la compatibilidad con el tasklet, porque el código del tasklet se reutilizará cuando se implementen las colas de trabajo atómicas. [1] https://lore.kernel.org/all/d390d7ee-f142-44d3-822a-87949e14608b@suse.de/T/ [2] https://lore.kernel.org/lkml/20240130091300.2968534-1- tj@kernel.org/
  
• Vulnerabilidad en kernel de Linux (CVE-2024-26721)
  Severidad: MEDIA
  Fecha de publicación: 03/04/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: drm/i915/dsc: corrige la macro que calcula la dirección de registro DSCC_/DSCA_ PPS Commit bd077259d0a9 ("drm/i915/vdsc: Agregar función para leer cualquier registro PPS") define un Nueva macro para calcular las direcciones de registro DSC PPS con el número PPS como entrada. Esta macro calcula correctamente las direcciones hasta PPS 11 ya que las direcciones se incrementan en 4. Entonces, en ese caso, la siguiente macro funciona correctamente para proporcionar la dirección de registro correcta: _MMIO(_DSCA_PPS_0 + (pps) * 4) Sin embargo, después de PPS 11, la dirección de registro para PPS 12 se incrementa en 12 debido a la asignación de memoria del búfer RC en el medio. Debido a esta discontinuidad en el espacio de direcciones, la macro calcula direcciones incorrectas para PPS 12 - 16, lo que genera lecturas/escrituras incorrectas del valor del parámetro PPS de DSC, lo que provoca corrupción de DSC. Esto se soluciona corrigiendo esta macro para agregar el desplazamiento de 12 para PPS >=12. v3: agregue paréntesis correcto para el argumento pps (Jani Nikula) (seleccionado del commit 6074be620c31dc2ae11af96a1a5ea95580976fb5)
  
• Vulnerabilidad en kernel de Linux (CVE-2024-26726)
  Severidad: MEDIA
  Fecha de publicación: 03/04/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: btrfs: no elimine extend_map para el inodo de espacio libre en el error de escritura Mientras ejecutaba el CI para un cambio no relacionado, encontré el siguiente pánico con generic/648 en btrfs_holes_spacecache. error de aserción: block_start != EXTENT_MAP_HOLE, en fs/btrfs/extent_io.c:1385 ------------[ cortar aquí ]------------ ERROR del kernel en fs /btrfs/extent_io.c:1385! código de operación no válido: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 2695096 Comm: fsstress Kdump: cargado Contaminado: GW 6.8.0-rc2+ #1 RIP: 0010:__extent_writepage_io.constprop.0+0x4c1/0x5c0 Seguimiento de llamadas: < TAREA> extensión_write_cache_pages+0x2ac/0x8f0 extensión_writepages+0x87/0x110 do_writepages+0xd5/0x1f0 filemap_fdatawrite_wbc+0x63/0x90 __filemap_fdatawrite_range+0x5c/0x80 btrfs_fdatawrite_range+0x1f/0x50 btrfs_write_out_ca che+0x507/0x560 btrfs_write_dirty_block_groups+0x32a/0x420 commit_cowonly_roots+0x21b/0x290 btrfs_commit_transaction+0x813 /0x1360 btrfs_sync_file+0x51a/0x640 __x64_sys_fdatasync+0x52/0x90 do_syscall_64+0x9c/0x190 Entry_SYSCALL_64_after_hwframe+0x6e/0x76 Esto sucede porque no logramos escribir el espacio libre en caché en una instancia, volvemos e intentamos escribirlo nuevamente. Sin embargo, en el segundo paso, llamamos a btrfs_get_extent() en el inodo para obtener el mapeo de extensión. Debido a que este es un nuevo grupo de bloques, y con el inodo de espacio libre siempre buscamos la raíz de confirmación para evitar un punto muerto con el árbol, no encontramos nada y devolvemos un EXTENT_MAP_HOLE para el rango solicitado. Esto sucede porque la primera vez que intentamos escribir el caché de espacio, encontramos un error y, en caso de error, descartamos la asignación de extensión. Esto es normal para archivos normales, pero el inodo de caché de espacio libre es especial. Siempre esperamos que el mapa de extensión sea correcto. Por lo tanto, la segunda vez terminamos con un mapa de extensión falso. Dado que estamos desaprobando esta función, la forma más sencilla de solucionarlo es simplemente omitir la eliminación del rango del mapa de extensión para este rango fallido. Acorté la prueba usando inyección de error para enfatizar el área y facilitar su reproducción. Con este parche implementado, ya no entraremos en pánico con mi prueba de inyección de errores.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-26727)
  Severidad: MEDIA
  Fecha de publicación: 03/04/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: btrfs: no haga ASSERT() si el subvolumen recién creado ya se leyó [ERROR] Hay un bloqueo del syzbot, provocado por ASSERT() durante la creación del subvolumen: la aserción falló: ! anon_dev, en fs/btrfs/disk-io.c:1319 ------------[ cortar aquí ]------------ ERROR del kernel en fs/btrfs/disk -io.c:1319! código de operación no válido: 0000 [#1] PREEMPT SMP KASAN RIP: 0010:btrfs_get_root_ref.part.0+0x9aa/0xa60 btrfs_get_new_fs_root+0xd3/0xf0 create_subvol+0xd02/0x1650 btrfs_mksubvol+0xe95/0x12b0 __ btrfs_ioctl_snap_create+0x2f9/0x4f0 btrfs_ioctl_snap_create+0x16b /0x200 btrfs_ioctl+0x35f0/0x5cf0 __x64_sys_ioctl+0x19d/0x210 do_syscall_64+0x3f/0xe0 Entry_SYSCALL_64_after_hwframe+0x63/0x6b ---[ end trace 0000000000000000 ]--- [CA USO] Durante create_subvol(), después de insertar el elemento raíz para el subvolumen recién creado , activaríamos btrfs_get_new_fs_root() para obtener el btrfs_root de ese subvolumen. La idea aquí es que hemos preasignado un número de dispositivo anónimo para el subvolumen, por lo que podemos asignarlo al nuevo subvolumen. Pero realmente no hay nada que impida que cosas como backref caminen para leer el nuevo subvolumen. Si eso sucede antes de que llamemos a btrfs_get_new_fs_root(), se leerá el subvolumen y ya se habrá asignado un nuevo número de dispositivo anónimo. En ese caso, activaríamos ASSERT(), ya que realmente esperamos que nadie lea ese subvolumen (al que aún no se puede acceder desde fs). Pero aún es posible realizar cosas como el recorrido de referencia atrás para activar la lectura en el subvolumen. Por lo tanto, nuestra suposición sobre ASSERT() no es correcta en primer lugar. [FIX] Arréglelo eliminando ASSERT() y simplemente libere @anon_dev, restablezcalo a 0 y continúe. Si otra cosa lee el árbol de subvolumen, ya debería tener asignado un nuevo anon_dev, por lo que solo necesitamos liberar el preasignado.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-26730)
  Severidad: ALTA
  Fecha de publicación: 03/04/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: hwmon: (nct6775) Arreglar el acceso a los registros de configuración de temperatura El número de registros de configuración de temperatura no siempre coincide con el número total de registros de temperatura. Esto puede resultar en errores de acceso reportados si KASAN está habilitado. ERROR: KASAN: global fuera de los límites en nct6775_probe+0x5654/0x6fe9 nct6775_core
  
• Vulnerabilidad en kernel de Linux (CVE-2024-26733)
  Severidad: MEDIA
  Fecha de publicación: 03/04/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: arp: Evita el desbordamiento en arp_req_get(). syzkaller informó una escritura desbordada en arp_req_get(). [0] Cuando se emite ioctl(SIOCGARP), arp_req_get() busca una entrada vecina y copia neigh->ha para estructurar arpreq.arp_ha.sa_data. El arp_ha aquí es struct sockaddr, no struct sockaddr_storage, por lo que el búfer sa_data tiene solo 14 bytes. En el siguiente símbolo, se desbordan 2 bytes al siguiente campo int, arp_flags. Inicializamos el campo justo después de memcpy(), por lo que no es un problema. Sin embargo, cuando dev->addr_len es mayor que 22 (por ejemplo, MAX_ADDR_LEN), se sobrescribe arp_netmask, que podría configurarse como htonl(0xFFFFFFFFUL) en arp_ioctl() antes de llamar a arp_req_get(). Para evitar el desbordamiento, limitemos la longitud máxima de memcpy(). Tenga en cuenta que el commit b5f0de6df6dc ("net: dev: Convert sa_data to flexible array in struct sockaddr") simplemente silenció a syzkaller. [0]: memcpy: escritura detectada en todos los campos (tamaño 16) de un solo campo "r->arp_ha.sa_data" en net/ipv4/arp.c:1128 (tamaño 14) ADVERTENCIA: CPU: 0 PID: 144638 en net /ipv4/arp.c:1128 arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128 Módulos vinculados en: CPU: 0 PID: 144638 Comm: syz-executor.4 No contaminado 6.1.74 #31 Nombre de hardware: QEMU PC estándar (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-5 01/04/2014 RIP: 0010:arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128 Código: fd ff ff e8 41 42 de fb b9 0e 00 00 00 4c 89 fe 48 c7 c2 20 6d ab 87 48 c7 c7 80 6d ab 87 c6 05 25 af 72 04 01 e8 5f 8d ad fb <0f> 0b e9 6c fd ff ff e8 13 42 de fb be 03 00 00 00 4c 89 e7 e8 a6 RSP: 0018:ffffc900050b7998 EFLAGS: 00010286 RAX: 00000000000000000 RBX: ffff88803a815000 RCX: 0000000000000 000 RDX: 0000000000000000 RSI: ffffffff8641a44a RDI: 0000000000000001 RBP: ffffc900050b7a98 R08: 00000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 203a7970636d656d R12: ffff888039c54000 R13: 1ffff92000a16f37 R14: ffff88803a815084 R15: 0000000000000010 FS: 0000 7f172bf306c0(0000) GS:ffff88805aa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f172b3569f0 CR3: 0000000057f12005 CR4 : 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 00000000000000000 DR6: 00000000ffe0ff0 DR7: 000000 0000000400 PKRU: 55555554 Seguimiento de llamadas: arp_ioctl+0x33f/0x4b0 net/ipv4/arp.c:1261 inet_ioctl+0x314/0x3a0 net/ ipv4/af_inet.c:981 sock_do_ioctl+0xdf/0x260 net/socket.c:1204 sock_ioctl+0x3ef/0x650 net/socket.c:1321 vfs_ioctl fs/ioctl.c:51 [en línea] __do_sys_ioctl fs/ioctl.c:870 [en línea] __se_sys_ioctl fs/ioctl.c:856 [en línea] __x64_sys_ioctl+0x18e/0x220 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:51 [en línea] do_syscall_64+0x37/0x90 arch/x86/ entrada/common.c:81 entrada_SYSCALL_64_after_hwframe+0x64/0xce RIP: 0033:0x7f172b262b8d Código: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 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 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f172bf300b8 EFLAGS: 0000024 6 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX : 00007f172b3abf80 RCX: 00007f172b262b8d RDX: 0000000020000000 RSI: 0000000000008954 RDI: 00000000000000003 RBP: 00007f172b2d3493 R08: 0 000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000000000000 R13: 000000000000000b R14: 00007f172b3abf80 R15: 00007f172bf10000
  
• Vulnerabilidad en kernel de Linux (CVE-2024-26735)
  Severidad: MEDIA
  Fecha de publicación: 03/04/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: ipv6:sr: corrige posible use-after-free y null-ptr-deref La estructura de operaciones pernet para el subsystem debe registrarse antes de registrar la familia netlink genérica.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-26736)
  Severidad: ALTA
  Fecha de publicación: 03/04/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: afs: aumenta el tamaño del búfer en afs_update_volume_status() La longitud máxima del volumen->valor vid es de 20 caracteres. Por lo tanto, aumente el tamaño de idbuf[] hasta 24 para evitar el desbordamiento. Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE. [DH: En realidad, es 20 + NUL, así que auméntalo a 24 y usa snprintf()]
  
• Vulnerabilidad en kernel de Linux (CVE-2024-26740)
  Severidad: MEDIA
  Fecha de publicación: 03/04/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net/sched: act_mirred: use el trabajo pendiente para el ingreso duplicado. La prueba que Davide agregó en el compromiso ca22da2fbd69 ("act_mirred: use el trabajo pendiente para llamadas anidadas para el ingreso duplicado") bloquea nuestras máquinas virtuales de prueba. aproximadamente cada 10 ejecuciones, con el conocido punto muerto tcp_v4_rcv -> tcp_v4_rcv informado por lockdep. El problema descrito anteriormente por Davide (ver Enlace) es que si invertimos el flujo de tráfico con la redirección (salida -> entrada) podemos llegar al mismo socket que generó el paquete. Y es posible que todavía estemos sosteniendo el bloqueo del enchufe. La solución común a estos puntos muertos es colocar el paquete en el trabajo pendiente de Rx, en lugar de ejecutar la ruta de Rx en línea. Haga eso para todas las reversiones de salida -> entrada, no solo una vez que comenzamos a anidar llamadas reflejadas. En el pasado, existía la preocupación de que la dirección indirecta del trabajo pendiente provocara la pérdida de informes de errores o estadísticas menos precisas. Pero la solución actual no parece solucionar el problema.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-26741)
  Severidad: MEDIA
  Fecha de publicación: 03/04/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dccp/tcp: Unhash sk de ehash para error de asignación de tb2 después de check_estalblished(). syzkaller informó una advertencia [0] en inet_csk_destroy_sock() sin reproducción. WARN_ON(inet_sk(sk)->inet_num && !inet_csk(sk)->icsk_bind_hash); Sin embargo, el registro del syzkaller insinuó que connect() falló justo antes de la advertencia debido a FAULT_INJECTION. [1] Cuando se llama a connect() para un socket independiente, buscamos un puerto efímero disponible. Si existe un depósito bhash para el puerto, llamamos a __inet_check_establecido() o __inet6_check_establecido() para verificar si el depósito es reutilizable. Si es reutilizable, agregamos el socket en ehash y configuramos inet_sk(sk)->inet_num. Luego, buscamos el depósito bhash2 correspondiente e intentamos asignarlo si no existe. Aunque rara vez ocurre en el uso real, si la asignación falla, debemos revertir los cambios mediante check_establecido(). De lo contrario, un enchufe desconectado podría ocupar ilegalmente una entrada ehash. Tenga en cuenta que no volvemos a colocar tw en ehash porque es posible que sk ya haya respondido a un paquete para tw y sería mejor liberar tw antes bajo tal presión de memoria. [0]: ADVERTENCIA: CPU: 0 PID: 350830 en net/ipv4/inet_connection_sock.c:1193 inet_csk_destroy_sock (net/ipv4/inet_connection_sock.c:1193) Módulos vinculados en: 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:inet_csk_destroy_sock (net/ipv4/inet_connection_sock.c:1193) Código: 41 5c 41 5d 41 5e e9 2d 4a 3d fd e8 28 4a 3d fd 48 89 ef e8 f0 cd 7d ff 5b 5d 41 5c 41 5d 41 5e e9 13 4a 3d fd e8 0e 4a 3d fd <0f> 0b e9 61 fe ff ff e8 02 4a 3d fd 4c 89 e 7 be 03 00 00 00 e8 05 RSP: 0018:ffffc9000b21fd38 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000009e78 RCX: ffffffff840bae40 RDX: ffff88806e 46c600 RSI: ffffffff840bb012 RDI: ffff88811755cca8 RBP: ffff88811755c880 R08: 0000000000000003 R09: 00000000000000000 R10: 0000000000009e78 R11: 00 00000000000000 R12: ffff88811755c8e0 R13: ffff88811755c892 R14: ffff88811755c918 R15: 0000000000000000 FS: 00007f03e5243800(0000) GS:ffff88811ae00000(0000) knl GS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b32f21000 CR3: 0000000112ffe001 CR4: 0000000000770ef0 PKRU: 5555 Llamada 5554 Seguimiento: ? inet_csk_destroy_sock (net/ipv4/inet_connection_sock.c:1193) dccp_close (net/dccp/proto.c:1078) inet_release (net/ipv4/af_inet.c:434) __sock_release (net/socket.c:660) sock_close (net/ socket.c:1423) __fput (fs/file_table.c:377) __fput_sync (fs/file_table.c:462) __x64_sys_close (fs/open.c:1557 fs/open.c:1539 fs/open.c:1539) do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83) Entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:129) RIP: 0033:0x7f03e53852bb Código: 03 00 00 00 0f 05 48 3d 00 f0 ff ff 77 41 c3 48 83 ec 18 89 7c 24 0c e8 43 c9 f5 ff 8b 7c 24 0c 41 89 c0 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 3 5 44 89 c7 89 44 24 0c e8 a1 c9 f5 ff 8b 44 RSP: 002b:00000000005dfba0 EFLAGS: 00000293 ORIG_RAX: 00000000000000003 RAX: ffffffffffffffda RBX: 00000000000000004 RCX: 00007f03e53852bb RDX: 0000000000000002 RSI: 0000000000000002 RDI: 0000000000000003 RBP: 000000000000000000 R08: 0000000000000000 R09: 000000000000167c R10: 0000000008a79680 R11: 0000000000000293 R12: 00007f03e4e43000 R13: 00007f03e4e43170 R14: 00007f03e4e43178 R15: 00007f03e4e431 70 [1]: FAULT_INJECTION: forzando un fallo. nombre failslab, intervalo 1, probabilidad 0, espacio 0, tiempos 0 CPU: 0 PID: 350833 Comm: syz-executor.1 No contaminado 6.7.0-12272-g2121c43f88f5 #9 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996 ), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 01/04/2014 Seguimiento de llamadas: dump_stack_lvl---truncado---
  
• Vulnerabilidad en kernel de Linux (CVE-2024-26742)
  Severidad: ALTA
  Fecha de publicación: 03/04/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: scsi: smartpqi: solucione enable_managed_interrupts Corrija el problema de registro de blk-mq con el parámetro del módulo enable_managed_interrupts habilitado. Cuando desactivamos el indicador PCI_IRQ_AFFINITY predeterminado, el controlador debe registrarse con blk-mq usando blk_mq_map_queues(). Actualmente, el controlador está llamando a blk_mq_pci_map_queues(), lo que genera un seguimiento de la pila y posiblemente un comportamiento indefinido. Seguimiento de pila: [7.860089] scsi host2: smartpqi [7.871934] ADVERTENCIA: CPU: 0 PID: 238 en block/blk-mq-pci.c:52 blk_mq_pci_map_queues+0xca/0xd0 [7.889231] Módulos vinculados en: sd_mod t10_pi sg uas smartpqi (+) crc32c_intel scsi_transport_sas usb_storage dm_mirror dm_region_hash dm_log dm_mod ipmi_devintf ipmi_msghandler fusible [7.924755] CPU: 0 PID: 238 Comm: kworker/0:3 No contaminado 4.18.0-372.88.1.el8_6_smartpqi_test .x86_64 #1 [7.944336] Nombre del hardware: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 08/03/2022 [ 7.963026] Cola de trabajo: eventos work_for_cpu_fn [ 7.978275] RIP: 0010:blk_mq_pci_map_queues+0xca/0xd0 [ 7.978278] Código: 4 8 89 de 89 c7 e8 f6 0f 4f 00 3b 05 c4 b7 8e 01 72 e1 5b 31 c0 5d 41 5c 41 5d 41 5e 41 5f e9 7d df 73 00 31 c0 e9 76 df 73 00 <0f> 0b eb bc 90 90 0f 1f 44 00 00 41 5 7 49 89 y siguientes 41 56 41 55 41 54 [ 7.978280] RSP: 0018:ffffa95fc3707d50 EFLAGS: 00010216 [ 7.978283] RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 000000 0000000010 [ 7.978284] RDX: 00000000000000004 RSI: 0000000000000000 RDI: ffff9190c32d4310 [ 7.978286] RBP: 0000000000000000 R08: ffffa95fc370 7d38 R09: ffff91929b81ac00 [ 7.978287] R10: 00000000000000001 R11: ffffa95fc3707ac0 R12: 00000000000000000 [ 7.978288] R13: ffff9190c32d4000 R14: 0 0000000ffffffff R15: ffff9190c4c950a8 [ 7.978290] FS: 0000000000000000(0000) GS:ffff9193efc00000(0000) knlGS:0000000000000000 [ 7.978292] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [8.172814] CR2: 000055d11166c000 CR3: 00000002dae10002 CR4: 00000000007706f0 [8.172816] DR0: [ 8.172818] PKRU : 55555554 [8.172819] Seguimiento de llamadas: [8.172823] blk_mq_alloc_tag_set+0x12e/0x310 [8.264339] scsi_add_host_with_dma.cold.9+0x30/0x245 [8.279302] pqi_ctrl_init+0xacf/0 xc8e [smartpqi] [8.294085]? pqi_pci_probe+0x480/0x4c8 [smartpqi] [ 8.309015] pqi_pci_probe+0x480/0x4c8 [smartpqi] [ 8.323286] local_pci_probe+0x42/0x80 [ 8.337855] work_for_cpu_fn+0x16/0x20 [ 8.3 51193] proceso_one_work+0x1a7/0x360 [8.364462]? create_worker+0x1a0/0x1a0 [8.379252] work_thread+0x1ce/0x390 [8.392623]? create_worker+0x1a0/0x1a0 [8.406295] kthread+0x10a/0x120 [8.418428]? set_kthread_struct+0x50/0x50 [8.431532] ret_from_fork+0x1f/0x40 [8.444137] ---[ final de seguimiento 1bf0173d39354506 ]---
  
• Vulnerabilidad en kernel de Linux (CVE-2024-26743)
  Severidad: MEDIA
  Fecha de publicación: 03/04/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/qedr: corrija el flujo de error qedr_create_user_qp Evite la siguiente advertencia asegurándose de liberar los recursos asignados en caso de que qedr_init_user_queue() falle. -----------[ cortar aquí ]----------- ADVERTENCIA: CPU: 0 PID: 143192 en drivers/infiniband/core/rdma_core.c:874 uverbs_destroy_ufile_hw+0xcf/ 0xf0 [ib_uverbs] Módulos vinculados en: tls target_core_user uio target_core_pscsi target_core_file target_core_iblock ib_srpt ib_srp scsi_transport_srp nfsd nfs_acl rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd Grace fscache netfs 8 021q garp mrp stp llc ext4 mbcache jbd2 opa_vnic ib_umad ib_ipoib sunrpc rdma_ucm ib_isert iscsi_target_mod target_core_mod ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm hfi1 intel_rapl_msr intel_rapl_common mgag200 qedr sb_edac drm_shmem_helper rdmavt x86_pkg_temp_thermal drm_kms_helper intel_powerclamp ib_uverbs coretemp i2c_algo_bit kvm_intel dell_wmi_descriptor ipmi_ssif sparse_keymap kvm ib_core rfkill syscopyarea sysfillrect video sysimgblt irqbypass ipmi_si ipmi_devintf fb_sys_fops rapl iTCO_wdt mxm_wmi iTCO_vendor_support intel_cstate pcspkr dcdbas intel_uncore ipmi_msghandler lpc_ich acpi_power_meter mei_me mei fusible drm xfs libcrc32c qede sd_mod ahci libahci t10_pi sg crct10dif_pclmul crc32_pclmul crc32c_intel qed libata tg3 ghash_clmulni_intel megaraid_sas crc8 wmi [última descarga: ib_srpt] CPU: 0 PID: 143192 Comm: fi_rdm_tagged_p Kdump: cargado No contaminado 5.14.0-408.el 9.x86_64 #1 Nombre del hardware: Dell Inc. PowerEdge R430/03XKDV, BIOS 2.14.0 25/01/2022 RIP: 0010:uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs] Código: 5d 41 5c 41 5d 41 5e e9 0f 26 1b dd 48 89 df e8 67 6a ff ff 49 8b 86 10 01 00 00 48 85 c0 74 9c 4c 89 e7 e8 83 c0 cb dd eb 92 <0f> 0b eb be 0f 0b be 04 00 00 00 48 89 df e8 8e f5 ff ff e9 6d ff RSP: 0018:ffffb7c6cadfbc 60 EF BANDERAS: 00010286 RAX: ffff8f0889ee3f60 RBX: ffff8f088c1a5200 RCX: 00000000802a0016 RDX: 00000000802a0017 RSI: 00000000000000001 RDI: ffff8f0880042600 RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000 R10: ffff8f11fffd5000 R11: 00000000000039000 R12: ffff8f0d5b36cd80 R13: ff ff8f088c1a5250 R14: ffff8f1206d91000 R15: 0000000000000000 FS: 00000000000000000( 0000) GS:ffff8f11d7c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000147069200e20 CR3: 00000001c7 210002 CR4: 00000000001706f0 Seguimiento de llamadas: ? show_trace_log_lvl+0x1c4/0x2df? show_trace_log_lvl+0x1c4/0x2df? ib_uverbs_close+0x1f/0xb0 [ib_uverbs] ? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs] ? __advertir+0x81/0x110 ? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs] ? report_bug+0x10a/0x140? handle_bug+0x3c/0x70? exc_invalid_op+0x14/0x70? asm_exc_invalid_op+0x16/0x20? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs] ib_uverbs_close+0x1f/0xb0 [ib_uverbs] __fput+0x94/0x250 task_work_run+0x5c/0x90 do_exit+0x270/0x4a0 do_group_exit+0x2d/0x90 get_signal+0x8 7c/0x8c0 arch_do_signal_or_restart+0x25/0x100 ? ib_uverbs_ioctl+0xc2/0x110 [ib_uverbs] exit_to_user_mode_loop+0x9c/0x130 exit_to_user_mode_prepare+0xb6/0x100 syscall_exit_to_user_mode+0x12/0x40 do_syscall_64+0x69/0x90 ? syscall_exit_work+0x103/0x130? syscall_exit_to_user_mode+0x22/0x40? do_syscall_64+0x69/0x90? syscall_exit_work+0x103/0x130? syscall_exit_to_user_mode+0x22/0x40? do_syscall_64+0x69/0x90? do_syscall_64+0x69/0x90? common_interrupt+0x43/0xa0 Entry_SYSCALL_64_after_hwframe+0x72/0xdc RIP: 0033:0x1470abe3ec6b Código: no se puede acceder a los bytes del código de operación en RIP 0x1470abe3ec41. RSP: 002b:00007fff13ce9108 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: fffffffffffffffc RBX: 00007fff13ce9218 RCX: 00001470abe3ec6b RDX: 00007fff13ce9 200 RSI: 00000000c0181b01 RDI: 00000000000000004 RBP: 00007fff13ce91e0 R08: 0000558d9655da10 R09: 0000558d9655dd00 R10: 00007fff13ce95c0 R11: 0000000000000246 R12: 00007fff13ce9358 R13: 0000000000000013 R14: 0000558d9655db50 R15: 00007fff13ce9470 --[ final de seguimiento 888a9b92e04c5c97 ]--
  
• Vulnerabilidad en kernel de Linux (CVE-2024-26751)
  Severidad: MEDIA
  Fecha de publicación: 03/04/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ARM: ep93xx: Agregar terminador a gpiod_lookup_table Sin el terminador, si se pasa un con_id a gpio_find() que no existe en la tabla de búsqueda, la función no dejará de repetirse correctamente y eventualmente causará un oops
  
• Vulnerabilidad en kernel de Linux (CVE-2024-26752)
  Severidad: MEDIA
  Fecha de publicación: 03/04/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: l2tp: pasa la longitud correcta del mensaje a ip6_append_data l2tp_ip6_sendmsg necesita evitar tener en cuenta el encabezado de transporte dos veces al unir más datos en un skbuff ya parcialmente ocupado. Para gestionar esto, verificamos si skbuff contiene datos usando skb_queue_empty al decidir cuántos datos agregar usando ip6_append_data. Sin embargo, el código que realizó el cálculo era incorrecto: ulen = len + skb_queue_empty(&sk->sk_write_queue)? transhdrlen : 0; ...debido a la precedencia del operador C, esto termina configurando ulen en transhdrlen para mensajes con una longitud distinta de cero, lo que resulta en paquetes corruptos en el cable. Agregue paréntesis para corregir el cálculo de acuerdo con la intención original.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-26756)
  Severidad: MEDIA
  Fecha de publicación: 03/04/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: md: No registre sync_thread para remodelar directamente Actualmente, si se interrumpe el proceso de remodelación, volver a ensamblar la matriz registrará sync_thread directamente desde pers->run(), en este caso 'MD_RECOVERY_RUNNING ' se configura directamente, sin embargo, no hay garantía de que md_do_sync() se ejecute, por lo tanto, stop_sync_thread() se bloqueará porque 'MD_RECOVERY_RUNNING' no se puede borrar. En el último parche, asegúrese de que md_do_sync() establezca MD_RECOVERY_DONE; sin embargo, dm-raid test shell/lvconvert-raid-reshape.sh ocasionalmente puede activar el siguiente bloqueo: [root@fedora ~]# cat /proc/1982/stack [<0>] stop_sync_thread+0x1ab/0x270 [md_mod] [<0>] md_frozen_sync_thread+0x5c/0xa0 [md_mod] [<0>] raid_presuspend+0x1e/0x70 [dm_raid] [<0>] dm_table_presuspend_targets+0x40/0xb0 [ dm_mod] [<0>] __dm_destroy+0x2a5/0x310 [dm_mod] [<0>] dm_destroy+0x16/0x30 [dm_mod] [<0>] dev_remove+0x165/0x290 [dm_mod] [<0>] ctl_ioctl+0x4bb/ 0x7b0 [dm_mod] [<0>] dm_ctl_ioctl+0x11/0x20 [dm_mod] [<0>] vfs_ioctl+0x21/0x60 [<0>] __x64_sys_ioctl+0xb9/0xe0 [<0>] do_syscall_64+0xc6/0x230 [<0 >] Entry_SYSCALL_64_after_hwframe+0x6c/0x74 Mientras tanto mddev->recovery es: MD_RECOVERY_RUNNING | MD_RECOVERY_INTR | MD_RECOVERY_RESHAPE | MD_RECOVERY_FROZEN Solucione este problema eliminando el código para registrar sync_thread directamente desde raid10 y raid5. Y deje que md_check_recovery() registre sync_thread.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-26759)
  Severidad: MEDIA
  Fecha de publicación: 03/04/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/swap: corrige la ejecución al omitir swapcache Al omitir swapcache para SWP_SYNCHRONOUS_IO, si dos o más subprocesos intercambian la misma entrada al mismo tiempo, obtienen páginas diferentes (A, B) . Antes de que un subproceso (T0) finalice el intercambio e instale la página (A) en el PTE, otro subproceso (T1) podría finalizar el intercambio de la página (B), liberar la entrada y luego intercambiar la página posiblemente modificada reutilizando la misma entrada. Rompe el control pte_same (T0) porque el valor de PTE no cambia, lo que provoca un problema de ABA. El subproceso (T0) instalará una página bloqueada (A) en el PTE y provocará daños en los datos. Una posible pila de llamadas es así: CPU0 CPU1 ---- ---- do_swap_page() do_swap_page() con la misma entrada swap_read_folio() < - leer en la página A swap_read_folio() <- leer en la página B ... set_pte_at() swap_free() <- la entrada es libre pte_same() <- Verificar pase, PTE parece no haber cambiado, ¡pero la página A está estancada! swap_free() <- ¡Contenido de la página B perdido! set_pte_at() <- ¡página A obsoleta instalada! Y además, para ZRAM, swap_free() permite que el dispositivo de intercambio descarte el contenido de la entrada, por lo que incluso si la página (B) no se modifica, si swap_read_folio() en CPU0 ocurre más tarde que swap_free() en CPU1, también puede causar que los datos pérdida. Para solucionar este problema, reutilice swapcache_prepare, que fijará la entrada de intercambio usando el indicador de caché y permitirá que solo un hilo la intercambie, y también evitará que cualquier código paralelo coloque la entrada en el caché. Suelte el pasador después de desbloquear el PT. Los corredores simplemente dan vueltas y esperan, ya que es un evento raro y muy corto. Se agrega una llamada Schedule_timeout_uninterruptible(1) para evitar errores repetidos de página que desperdician demasiada CPU, provocando bloqueos en vivo o agregando demasiado ruido a las estadísticas de rendimiento. Un problema similar de livelock se describió en el compromiso 029c4628b2eb ("mm: swap: deshacerse de livelock en swapin readahead") Reproductor: este problema de ejecución se puede activar fácilmente utilizando un reproductor bien construido y un brd parcheado (con un retraso en la ruta de lectura) [ 1]: Con la última línea principal 6.8, la pérdida de datos causada por la ejecución se puede observar fácilmente: $ gcc -g -lpthread test-thread-swap-race.c && ./a.out Contaminando 32 MB de región de memoria... Siga intercambiando. .. Comenzando la ronda 0... Generando 65536 trabajadores... Se generaron 32746 trabajadores, espere a que termine... Ronda 0: Error en 0x5aa00, se esperaban 32746, obtuve 32743, ¡3 pérdida de datos! Ronda 0: Error en 0x395200, se esperaba 32746, obtuve 32743, ¡3 pérdida de datos! Ronda 0: Error en 0x3fd000, esperado 32746, obtuve 32737, ¡9 pérdida de datos! Ronda 0 fallida, ¡15 pérdida de datos! Este reproductor genera múltiples subprocesos que comparten la misma región de memoria mediante un pequeño dispositivo de intercambio. Cada dos subprocesos actualiza las páginas asignadas una por una en dirección opuesta tratando de crear una ejecución, con un subproceso dedicado sigue intercambiando los datos usando madvise. El reproductor creó una tasa de reproducción de aproximadamente una vez cada 5 minutos, por lo que la ejecución debería ser totalmente posible en producción. Después de este parche, ejecuté el reproductor durante más de unos cientos de rondas y no se observó pérdida de datos. ---truncado---
  
• Vulnerabilidad en kernel de Linux (CVE-2024-26761)
  Severidad: MEDIA
  Fecha de publicación: 03/04/2024
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: cxl/pci: corrige la desactivación de la memoria si el rango DVSEC CXL no coincide con una ventana CFMWS. El subSYSTEM Linux CXL se basa en el supuesto de que HPA == SPA. Es decir, la dirección física del host (HPA) con la que están programados los registros del decodificador HDM son direcciones físicas del SYSTEM (SPA). Durante la configuración del decodificador HDM, los registros de rango DVSEC CXL (cxl-3.1, 8.1.3.8) se verifican si la memoria está habilitada y el rango CXL está en una ventana HPA que se describe en una estructura CFMWS del puente de host CXL (cxl- 3.1, 9.18.1.3). Ahora, si el HPA no es un SPA, el rango CXL no coincide con una ventana CFMWS y el rango de memoria CXL se desactivará en ese momento. El descodificador HDM deja de funcionar, lo que provoca que la memoria del SYSTEM se desactive y, además, el SYSTEM se cuelgue durante la inicialización del descodificador HDM, normalmente cuando se inicia un kernel habilitado para CXL. Evite que el SYSTEM se cuelgue y no desactive el decodificador HDM si el rango CXL del decodificador no se encuentra en una ventana CFMWS. Tenga en cuenta que el cambio solo soluciona un problema de hardware, pero no implementa la traducción HPA/SPA. Se puede agregar soporte para esto en una serie de parches de seguimiento.
  
• Vulnerabilidad en pgAdmin (CVE-2024-3116)
  Severidad: ALTA
  Fecha de publicación: 04/04/2024
  Fecha de última actualización: 17/03/2025
  pgAdmin <= 8.4 se ve afectado por una vulnerabilidad de ejecución remota de código (RCE) a través de la API de validación de ruta binaria. Esta vulnerabilidad permite a los atacantes ejecutar código arbitrario en el servidor que aloja PGAdmin, lo que representa un grave riesgo para la integridad del sistema de gestión de la base de datos y la seguridad de los datos subyacentes.
  
• Vulnerabilidad en Tenda AC7V1.0 v15.03.06.44 (CVE-2024-32281)
  Severidad: ALTA
  Fecha de publicación: 17/04/2024
  Fecha de última actualización: 17/03/2025
  El firmware Tenda AC7V1.0 v15.03.06.44 contiene una vulnerabilidad de inyección de comandos en la función formexeCommand a través del parámetro cmdinput.
  
• Vulnerabilidad en Tenda AC7V1.0 v15.03.06.44 (CVE-2024-32301)
  Severidad: CRÍTICA
  Fecha de publicación: 17/04/2024
  Fecha de última actualización: 17/03/2025
  El firmware Tenda AC7V1.0 v15.03.06.44 tiene una vulnerabilidad de desbordamiento de pila a través del parámetro PPW en la función fromWizardHandle.
  
• Vulnerabilidad en Tenda FH1205 V2.0.0.7(775) (CVE-2024-32307)
  Severidad: ALTA
  Fecha de publicación: 17/04/2024
  Fecha de última actualización: 17/03/2025
  El firmware Tenda FH1205 V2.0.0.7(775) tiene una vulnerabilidad de desbordamiento de pila ubicada a través del parámetro PPW en la función fromWizardHandle.
  
• Vulnerabilidad en Tenda F1203 V2.0.1.6 (CVE-2024-32310)
  Severidad: ALTA
  Fecha de publicación: 17/04/2024
  Fecha de última actualización: 17/03/2025
  El firmware Tenda F1203 V2.0.1.6 tiene una vulnerabilidad de desbordamiento de pila ubicada en el parámetro PPW de la función fromWizardHandle.
  
• Vulnerabilidad en Tenda F1203 V2.0.1.6 (CVE-2024-32312)
  Severidad: MEDIA
  Fecha de publicación: 17/04/2024
  Fecha de última actualización: 17/03/2025
  El firmware Tenda F1203 V2.0.1.6 tiene una vulnerabilidad de desbordamiento de pila ubicada en el parámetro adslPwd de la función formWanParameterSetting.
  
• Vulnerabilidad en Tenda FH1205 V2.0.0.7(775) (CVE-2024-32313)
  Severidad: MEDIA
  Fecha de publicación: 17/04/2024
  Fecha de última actualización: 17/03/2025
  El firmware Tenda FH1205 V2.0.0.7(775) tiene una vulnerabilidad de desbordamiento de pila ubicada a través del parámetro adslPwd de la función formWanParameterSetting.
  
• Vulnerabilidad en Tenda FH1203 V2.0.1.6 (CVE-2024-32283)
  Severidad: ALTA
  Fecha de publicación: 17/04/2024
  Fecha de última actualización: 17/03/2025
  El firmware Tenda FH1203 V2.0.1.6 tiene una vulnerabilidad de inyección de comando en la función formexeCommand a través del parámetro cmdinput.
  
• Vulnerabilidad en Tenda W30E v1.0 V1.0.1.25(633) (CVE-2024-32285)
  Severidad: ALTA
  Fecha de publicación: 17/04/2024
  Fecha de última actualización: 17/03/2025
  El firmware Tenda W30E v1.0 V1.0.1.25(633) tiene una vulnerabilidad de desbordamiento de pila a través del parámetro de contraseña en la función formaddUserName.
  
• Vulnerabilidad en Tenda W30E v1.0 V1.0.1.25(633) (CVE-2024-32286)
  Severidad: CRÍTICA
  Fecha de publicación: 17/04/2024
  Fecha de última actualización: 17/03/2025
  El firmware Tenda W30E v1.0 V1.0.1.25(633) tiene una vulnerabilidad de desbordamiento de pila ubicada a través del parámetro de página en la función fromVirtualSer.
  
• Vulnerabilidad en Tenda W30E v1.0 V1.0.1.25(633) (CVE-2024-32287)
  Severidad: MEDIA
  Fecha de publicación: 17/04/2024
  Fecha de última actualización: 17/03/2025
  El firmware Tenda W30E v1.0 V1.0.1.25(633) tiene una vulnerabilidad de desbordamiento de pila a través del parámetro qos en la función fromqossetting.
  
• Vulnerabilidad en Tenda W30E v1.0 V1.0.1.25(633) (CVE-2024-32288)
  Severidad: MEDIA
  Fecha de publicación: 17/04/2024
  Fecha de última actualización: 17/03/2025
  El firmware Tenda W30E v1.0 V1.0.1.25(633) tiene una vulnerabilidad de desbordamiento de pila ubicada a través del parámetro de página en la función fromwebExcptypemanFilter.
  
• Vulnerabilidad en Tenda W30E v1.0 v1.0.1.25(633) (CVE-2024-32290)
  Severidad: MEDIA
  Fecha de publicación: 17/04/2024
  Fecha de última actualización: 17/03/2025
  El firmware Tenda W30E v1.0 v1.0.1.25(633) tiene una vulnerabilidad de desbordamiento de pila a través del parámetro de página en la función fromAddressNat.
  
• Vulnerabilidad en Tenda W30E v1.0 (CVE-2024-32291)
  Severidad: ALTA
  Fecha de publicación: 17/04/2024
  Fecha de última actualización: 17/03/2025
  El firmware v1.0.1.25(633) de Tenda W30E v1.0 tiene una vulnerabilidad de desbordamiento de pila a través del parámetro de página en la función fromNatlimit.
  
• Vulnerabilidad en Tenda W30E v1.0 V1.0.1.25(633) (CVE-2024-32292)
  Severidad: ALTA
  Fecha de publicación: 17/04/2024
  Fecha de última actualización: 17/03/2025
  El firmware Tenda W30E v1.0 V1.0.1.25(633) contiene una vulnerabilidad de inyección de comando en la función formexeCommand a través del parámetro cmdinput.
  
• Vulnerabilidad en Tenda W30E v1.0 V1.0.1.25(633) (CVE-2024-32293)
  Severidad: ALTA
  Fecha de publicación: 17/04/2024
  Fecha de última actualización: 17/03/2025
  El firmware Tenda W30E v1.0 V1.0.1.25(633) tiene una vulnerabilidad de desbordamiento de pila a través del parámetro de página en la función fromDhcpListClient.
  
• Vulnerabilidad en Tenda FH1203 v2.0.1.6 (CVE-2024-32299)
  Severidad: ALTA
  Fecha de publicación: 17/04/2024
  Fecha de última actualización: 17/03/2025
  El firmware Tenda FH1203 v2.0.1.6 tiene una vulnerabilidad de desbordamiento de pila a través del parámetro PPW en la función fromWizardHandle.
  
• Vulnerabilidad en Tenda AC10U v1.0 (CVE-2024-32306)
  Severidad: MEDIA
  Fecha de publicación: 17/04/2024
  Fecha de última actualización: 17/03/2025
  Tenda AC10U v1.0 Firmware v15.03.06.49 tiene una vulnerabilidad de desbordamiento de pila ubicada a través del parámetro PPW en la función fromWizardHandle.
  
• Vulnerabilidad en Tenda FH1203 v2.0.1.6 (CVE-2024-32311)
  Severidad: MEDIA
  Fecha de publicación: 17/04/2024
  Fecha de última actualización: 17/03/2025
  El firmware Tenda FH1203 v2.0.1.6 tiene una vulnerabilidad de desbordamiento de pila a través del parámetro adslPwd en la función formWanParameterSetting.
  
• Vulnerabilidad en Tenda AC500 V2.0.1.9(1307) (CVE-2024-32314)
  Severidad: BAJA
  Fecha de publicación: 17/04/2024
  Fecha de última actualización: 17/03/2025
  El firmware Tenda AC500 V2.0.1.9(1307) contiene una vulnerabilidad de inyección de comandos en la función formexeCommand a través del parámetro cmdinput.
  
• Vulnerabilidad en Tenda AC500 V2.0.1.9(1307) (CVE-2024-32316)
  Severidad: MEDIA
  Fecha de publicación: 17/04/2024
  Fecha de última actualización: 17/03/2025
  El firmware Tenda AC500 V2.0.1.9(1307) tiene una vulnerabilidad de desbordamiento de pila en la función fromDhcpListClient.
  
• Vulnerabilidad en Tenda AC10 v4.0 (CVE-2024-32317)
  Severidad: ALTA
  Fecha de publicación: 17/04/2024
  Fecha de última actualización: 17/03/2025
  El firmware Tenda AC10 v4.0 V16.03.10.13 y V16.03.10.20 tiene una vulnerabilidad de desbordamiento de pila a través del parámetro adslPwd en la función formWanParameterSetting.
  
• Vulnerabilidad en Tenda AC500 V2.0.1.9(1307) (CVE-2024-32318)
  Severidad: CRÍTICA
  Fecha de publicación: 17/04/2024
  Fecha de última actualización: 17/03/2025
  El firmware Tenda AC500 V2.0.1.9(1307) tiene una vulnerabilidad de desbordamiento de pila a través del parámetro vlan en la función formSetVlanInfo.
  
• Vulnerabilidad en Tenda AC500 V2.0.1.9(1307) (CVE-2024-32320)
  Severidad: MEDIA
  Fecha de publicación: 17/04/2024
  Fecha de última actualización: 17/03/2025
  El firmware Tenda AC500 V2.0.1.9(1307) tiene una vulnerabilidad de desbordamiento de pila a través del parámetro timeZone en la función formSetTimeZone.
  
• Vulnerabilidad en Tenda FH1206 V1.2.0.8(8155)_EN (CVE-2024-33211)
  Severidad: ALTA
  Fecha de publicación: 23/04/2024
  Fecha de última actualización: 17/03/2025
  Se descubrió que Tenda FH1206 V1.2.0.8(8155)_EN contiene una vulnerabilidad de desbordamiento de búfer en la región stack de la memoria a través del parámetro PPPOEPassword en ip/goform/QuickIndex.
  
• Vulnerabilidad en Tenda FH1206 V1.2.0.8(8155)_EN (CVE-2024-33212)
  Severidad: ALTA
  Fecha de publicación: 23/04/2024
  Fecha de última actualización: 17/03/2025
  Se descubrió que Tenda FH1206 V1.2.0.8(8155)_EN contiene una vulnerabilidad de desbordamiento de búfer en la región stack de la memoria a través del parámetro funcpara1 en ip/goform/setcfm.
  
• Vulnerabilidad en Tenda FH1206 V1.2.0.8(8155)_EN (CVE-2024-33213)
  Severidad: MEDIA
  Fecha de publicación: 23/04/2024
  Fecha de última actualización: 17/03/2025
  Se descubrió que Tenda FH1206 V1.2.0.8(8155)_EN contiene una vulnerabilidad de desbordamiento de búfer en la región stack de la memoria a través del parámetro mitInterface en ip/goform/RouteStatic.
  
• Vulnerabilidad en Tenda FH1206 V1.2.0.8(8155)_EN (CVE-2024-33214)
  Severidad: ALTA
  Fecha de publicación: 23/04/2024
  Fecha de última actualización: 17/03/2025
  Se descubrió que Tenda FH1206 V1.2.0.8(8155)_EN contiene una vulnerabilidad de desbordamiento de búfer en la región stack de la memoria a través del parámetro de entradas en ip/goform/RouteStatic.
  
• Vulnerabilidad en Tenda FH1206 V1.2.0.8(8155)_EN (CVE-2024-33215)
  Severidad: CRÍTICA
  Fecha de publicación: 23/04/2024
  Fecha de última actualización: 17/03/2025
  Se descubrió que Tenda FH1206 V1.2.0.8(8155)_EN contiene una vulnerabilidad de desbordamiento de búfer en la región stack de la memoria a través del parámetro mitInterface en ip/goform/addressNat.
  
• Vulnerabilidad en Tenda FH1206 V1.2.0.8(8155)_EN (CVE-2024-33217)
  Severidad: ALTA
  Fecha de publicación: 23/04/2024
  Fecha de última actualización: 17/03/2025
  Se descubrió que Tenda FH1206 V1.2.0.8(8155)_EN contiene una vulnerabilidad de desbordamiento de búfer en la región stack de la memoria a través del parámetro de página en ip/goform/addressNat.
  
• Vulnerabilidad en Tenda AC18 v15.03.05.19 (CVE-2024-34974)
  Severidad: ALTA
  Fecha de publicación: 14/05/2024
  Fecha de última actualización: 17/03/2025
  Tenda AC18 v15.03.05.19 es vulnerable al desbordamiento del búfer en la función formSetPPTPServer a través del parámetro endIp.
  
• Vulnerabilidad en Tenda AX1806 v1.0.0.1 (CVE-2024-35571)
  Severidad: CRÍTICA
  Fecha de publicación: 20/05/2024
  Fecha de última actualización: 17/03/2025
  Tenda AX1806 v1.0.0.1 contiene un desbordamiento de pila a través del parámetro iptv.stb.mode en la función formSetIptv.
  
• Vulnerabilidad en Tenda AX1806 v1.0.0.1 (CVE-2024-35576)
  Severidad: MEDIA
  Fecha de publicación: 20/05/2024
  Fecha de última actualización: 17/03/2025
  Tenda AX1806 v1.0.0.1 contiene un desbordamiento de pila a través del parámetro iptv.stb.port en la función formSetIptv.
  
• Vulnerabilidad en Tenda AX1806 v1.0.0.1 (CVE-2024-35578)
  Severidad: ALTA
  Fecha de publicación: 20/05/2024
  Fecha de última actualización: 17/03/2025
  Tenda AX1806 v1.0.0.1 contiene un desbordamiento de pila a través del parámetro adv.iptv.stballvlans en la función formSetIptv.
  
• Vulnerabilidad en Tenda AX1806 v1.0.0.1 (CVE-2024-35579)
  Severidad: ALTA
  Fecha de publicación: 20/05/2024
  Fecha de última actualización: 17/03/2025
  Tenda AX1806 v1.0.0.1 contiene un desbordamiento de pila a través del parámetro iptv.city.vlan en la función formSetIptv.
  
• Vulnerabilidad en Tenda AX1806 v1.0.0.1 (CVE-2024-35580)
  Severidad: CRÍTICA
  Fecha de publicación: 20/05/2024
  Fecha de última actualización: 17/03/2025
  Tenda AX1806 v1.0.0.1 contiene un desbordamiento de pila a través del parámetro adv.iptv.stbpvid en la función formSetIptv.
  
• Vulnerabilidad en Tenda AC8v4 V16.03.34.06 (CVE-2024-46652)
  Severidad: CRÍTICA
  Fecha de publicación: 20/09/2024
  Fecha de última actualización: 17/03/2025
  Tenda AC8v4 V16.03.34.06 tiene una vulnerabilidad de desbordamiento de pila en la función fromAdvSetMacMtuWan.
  
• Vulnerabilidad en Tenda AC7 v.15.03.06.44 ate_ifconfig_set (CVE-2024-48825)
  Severidad: ALTA
  Fecha de publicación: 28/10/2024
  Fecha de última actualización: 17/03/2025
  Tenda AC7 v.15.03.06.44 ate_ifconfig_set tiene inyección de comando de pre-autenticación que permite a atacantes remotos ejecutar código arbitrario.
  
• Vulnerabilidad en Tenda AC7 v.15.03.06.44 ate_iwpriv_set (CVE-2024-48826)
  Severidad: ALTA
  Fecha de publicación: 28/10/2024
  Fecha de última actualización: 17/03/2025
  Tenda AC7 v.15.03.06.44 ate_iwpriv_set tiene inyección de comando de pre-autenticación que permite a atacantes remotos ejecutar código arbitrario.
  
• Vulnerabilidad en Tenda AC18 (CVE-2024-57577)
  Severidad: MEDIA
  Fecha de publicación: 16/01/2025
  Fecha de última actualización: 17/03/2025
  Se descubrió que Tenda AC18 V15.03.05.19 contiene un desbordamiento de pila a través del parámetro speed_dir en la función formSetSpeedWan.
  
• Vulnerabilidad en Tenda AC18 (CVE-2024-57578)
  Severidad: ALTA
  Fecha de publicación: 16/01/2025
  Fecha de última actualización: 17/03/2025
  Se descubrió que Tenda AC18 V15.03.05.19 contiene un desbordamiento de pila a través del parámetro funcpara1 en la función formSetCfm.
  
• Vulnerabilidad en Tenda AC8v4 V16.03.34.06 (CVE-2024-57703)
  Severidad: CRÍTICA
  Fecha de publicación: 16/01/2025
  Fecha de última actualización: 17/03/2025
  Tenda AC8v4 V16.03.34.06 tiene una vulnerabilidad de desbordamiento de pila. La función setSchedWifi del archivo /goform/openSchedWifi se ve afectada por esta vulnerabilidad. La manipulación del argumento schedEndTime provoca un desbordamiento del búfer basado en la pila.
  
• Vulnerabilidad en Tenda AC8v4 V16.03.34.06 (CVE-2024-57704)
  Severidad: ALTA
  Fecha de publicación: 16/01/2025
  Fecha de última actualización: 17/03/2025
  Tenda AC8v4 V16.03.34.06 tiene una vulnerabilidad de desbordamiento de pila. La función setSchedWifi del archivo /goform/openSchedWifi se ve afectada por esta vulnerabilidad. La manipulación del argumento schedStartTime provoca un desbordamiento del búfer basado en la pila.
  
• Vulnerabilidad en Huawei Technologies (CVE-2024-12602)
  Severidad: MEDIA
  Fecha de publicación: 06/02/2025
  Fecha de última actualización: 17/03/2025
  Vulnerabilidad de verificación de identidad en el módulo ParamWatcher Impacto: La explotación exitosa de esta vulnerabilidad puede afectar la confidencialidad del servicio.
  
• Vulnerabilidad en Huawei Technologies (CVE-2024-57954)
  Severidad: MEDIA
  Fecha de publicación: 06/02/2025
  Fecha de última actualización: 17/03/2025
  Vulnerabilidad de verificación de permisos en el módulo de librería multimedia Impacto: La explotación exitosa de esta vulnerabilidad puede afectar la confidencialidad del servicio.
  
• Vulnerabilidad en Huawei Technologies (CVE-2024-57955)
  Severidad: MEDIA
  Fecha de publicación: 06/02/2025
  Fecha de última actualización: 17/03/2025
  Vulnerabilidad de escritura arbitraria en el módulo Galería Impacto: La explotación exitosa de esta vulnerabilidad puede afectar la confidencialidad del servicio.
  
• Vulnerabilidad en Huawei Technologies (CVE-2024-57956)
  Severidad: BAJA
  Fecha de publicación: 06/02/2025
  Fecha de última actualización: 17/03/2025
  Vulnerabilidad de lectura fuera de los límites en el módulo de cadena del intérprete Impacto: La explotación exitosa de esta vulnerabilidad puede afectar la disponibilidad.
  
• CVE-2024-57957
  Severidad: MEDIA
  Fecha de publicación: 06/02/2025
  Fecha de última actualización: 17/03/2025
  Vulnerabilidad de control inadecuado de información de registro en el módulo UI Framework Impacto: La explotación exitosa de esta vulnerabilidad puede afectar la confidencialidad del servicio.
  
• Vulnerabilidad en Tenda AC8V4 V16.03.34.06 (CVE-2025-25663)
  Severidad: CRÍTICA
  Fecha de publicación: 20/02/2025
  Fecha de última actualización: 17/03/2025
  Se ha detectado una vulnerabilidad en Tenda AC8V4 V16.03.34.06. La función SUB_0046AC38 del archivo /goform/WifiExtraSet está afectada. La manipulación del argumento wpapsk_crypto provoca un desbordamiento del búfer basado en la pila.
  
• Vulnerabilidad en Tenda AC8V4 V16.03.34.06 (CVE-2025-25664)
  Severidad: CRÍTICA
  Fecha de publicación: 20/02/2025
  Fecha de última actualización: 17/03/2025
  Se descubrió que Tenda AC8V4 V16.03.34.06 contiene un desbordamiento de pila a través del parámetro shareSpeed en la función sub_49E098.
  
• Vulnerabilidad en Tenda AC8V4 V16.03.34.0 (CVE-2025-25667)
  Severidad: CRÍTICA
  Fecha de publicación: 20/02/2025
  Fecha de última actualización: 17/03/2025
  Se descubrió que Tenda AC8V4 V16.03.34.06 contiene un desbordamiento de pila a través del parámetro urls en la función get_parentControl_list_Info.
  
• Vulnerabilidad en Tenda AC8V4 V16.03.34.06 (CVE-2025-25668)
  Severidad: CRÍTICA
  Fecha de publicación: 20/02/2025
  Fecha de última actualización: 17/03/2025
  Se descubrió que Tenda AC8V4 V16.03.34.06 contiene un desbordamiento de pila a través del parámetro shareSpeed en la función sub_47D878.
  
• Vulnerabilidad en Tenda AC10 V1.0 V15.03.06.23 (CVE-2025-25674)
  Severidad: CRÍTICA
  Fecha de publicación: 20/02/2025
  Fecha de última actualización: 17/03/2025
  Tenda AC10 V1.0 V15.03.06.23 es vulnerable a un desbordamiento de búfer en form_fast_setting_wifi_set a través del parámetro ssid.
  
• Vulnerabilidad en Tenda AC10 V1.0 V15.03.06.23 (CVE-2025-25675)
  Severidad: CRÍTICA
  Fecha de publicación: 20/02/2025
  Fecha de última actualización: 17/03/2025
  Tenda AC10 V1.0 V15.03.06.23 tiene una vulnerabilidad de inyección de comandos ubicada en la función formexeCommand. La variable str recibe el parámetro cmdinput de una solicitud POST y luego se asigna a la variable cmd_buf, que se utiliza directamente en la función doSystemCmd, lo que provoca la ejecución arbitraria de un comando.
  
• Vulnerabilidad en kernel de Linux (CVE-2022-49441)
  Severidad: MEDIA
  Fecha de publicación: 26/02/2025
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tty: se corrige el bloqueo causado por llamar a printk() bajo tty_port->lock pty_write() invoca kmalloc() que puede invocar un printk() normal para imprimir un mensaje de error. Esto puede causar un bloqueo en el escenario informado por syz-bot a continuación: CPU0 CPU1 CPU2 ---- ---- ---- lock(console_owner); lock(&port_lock_key); lock(&port->lock); lock(&port_lock_key); lock(&port->lock); lock(console_owner); Como dijo el commit dbdda842fe96 ("printk: Agregar lógica de propietario y espera de consola para equilibrar la carga de escrituras de consola"), dicho bloqueo se puede prevenir usando printk_deferred() en kmalloc() (que se invoca en la sección protegida por port->lock). Pero hay demasiados printk() en la ruta kmalloc() y kmalloc() se puede llamar desde cualquier lugar, por lo que cambiar printk() a printk_deferred() es demasiado complicado y poco elegante. Por lo tanto, este parche elige especificar __GFP_NOWARN en kmalloc(), de modo que no se llame a printk() y se pueda evitar este problema de bloqueo. Syzbot informó el siguiente error de lockdep: ======================================================== ADVERTENCIA: posible dependencia de bloqueo circular detectada 5.4.143-00237-g08ccc19a-dirty #10 Not tainted ------------------------------------------------------ syz-executor.4/29420 is trying to acquire lock: ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: console_trylock_spinning kernel/printk/printk.c:1752 [inline] ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: vprintk_emit+0x2ca/0x470 kernel/printk/printk.c:2023 but task is already holding lock: ffff8880119c9158 (&port->lock){-.-.}-{2:2}, at: pty_write+0xf4/0x1f0 drivers/tty/pty.c:120 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&port->lock){-.-.}-{2:2}: __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159 tty_port_tty_get drivers/tty/tty_port.c:288 [inline] <-- lock(&port->lock); tty_port_default_wakeup+0x1d/0xb0 drivers/tty/tty_port.c:47 serial8250_tx_chars+0x530/0xa80 drivers/tty/serial/8250/8250_port.c:1767 serial8250_handle_irq.part.0+0x31f/0x3d0 drivers/tty/serial/8250/8250_port.c:1854 serial8250_handle_irq drivers/tty/serial/8250/8250_port.c:1827 [inline] <-- lock(&port_lock_key); serial8250_default_handle_irq+0xb2/0x220 drivers/tty/serial/8250/8250_port.c:1870 serial8250_interrupt+0xfd/0x200 drivers/tty/serial/8250/8250_core.c:126 __handle_irq_event_percpu+0x109/0xa50 kernel/irq/handle.c:156 [...] -> #1 (&port_lock_key){-.-.}-{2:2}: __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159 serial8250_console_write+0x184/0xa40 drivers/tty/serial/8250/8250_port.c:3198 <-- lock(&port_lock_key); call_console_drivers kernel/printk/printk.c:1819 [inline] console_unlock+0x8cb/0xd00 kernel/printk/printk.c:2504 vprintk_emit+0x1b5/0x470 kernel/printk/printk.c:2024 <-- lock(console_owner); vprintk_func+0x8d/0x250 kernel/printk/printk_safe.c:394 printk+0xba/0xed kernel/printk/printk.c:2084 register_console+0x8b3/0xc10 kernel/printk/printk.c:2829 univ8250_console_init+0x3a/0x46 drivers/tty/serial/8250/8250_core.c:681 console_init+0x49d/0x6d3 kernel/printk/printk.c:2915 start_kernel+0x5e9/0x879 init/main.c:713 secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:241 -> #0 (console_owner){....}-{0:0}: [...] lock_acquire+0x127/0x340 kernel/locking/lockdep.c:4734 console_trylock_spinning kernel/printk/printk.c:1773 ---truncated---
  
• Vulnerabilidad en kernel de Linux (CVE-2022-49443)
  Severidad: MEDIA
  Fecha de publicación: 26/02/2025
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: list: se corrige una ejecución de datos alrededor de ep->rdllist ep_poll() primero llama a ep_events_available() sin bloqueo mantenido y verifica si ep->rdllist está vacío mediante list_empty_careful(), que lee rdllist->prev. Por lo tanto, todos los accesos a él necesitan alguna protección para evitar el desgarro de almacenamiento/carga. Tenga en cuenta que INIT_LIST_HEAD_RCU() ya tiene la anotación tanto para prev como para next. El commit bf3b9f6372c4 ("epoll: Agregar soporte de sondeo ocupado a epoll con fds de socket") agregó el primer ep_events_available() sin bloqueo, y el commit c5a282e9635e ("fs/epoll: reducir el alcance del bloqueo wq en epoll_wait()") hizo que algunas llamadas ep_events_available() no tuvieran bloqueo y agregó una sola llamada bajo un bloqueo, finalmente el commit e59d3c64cba6 ("epoll: eliminar el bloqueo innecesario para tiempo de espera cero") hizo que el último ep_events_available() no tuviera bloqueo. ERROR: KCSAN: data-race in do_epoll_wait / do_epoll_wait write to 0xffff88810480c7d8 of 8 bytes by task 1802 on cpu 0: INIT_LIST_HEAD include/linux/list.h:38 [inline] list_splice_init include/linux/list.h:492 [inline] ep_start_scan fs/eventpoll.c:622 [inline] ep_send_events fs/eventpoll.c:1656 [inline] ep_poll fs/eventpoll.c:1806 [inline] do_epoll_wait+0x4eb/0xf40 fs/eventpoll.c:2234 do_epoll_pwait fs/eventpoll.c:2268 [inline] __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline] __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275 __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae read to 0xffff88810480c7d8 of 8 bytes by task 1799 on cpu 1: list_empty_careful include/linux/list.h:329 [inline] ep_events_available fs/eventpoll.c:381 [inline] ep_poll fs/eventpoll.c:1797 [inline] do_epoll_wait+0x279/0xf40 fs/eventpoll.c:2234 do_epoll_pwait fs/eventpoll.c:2268 [inline] __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline] __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275 __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae value changed: 0xffff88810480c7d0 -> 0xffff888103c15098 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 1799 Comm: syz-fuzzer Tainted: G W 5.17.0-rc7-syzkaller-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
  
• Vulnerabilidad en kernel de Linux (CVE-2022-49445)
  Severidad: MEDIA
  Fecha de publicación: 26/02/2025
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: pinctrl: renesas: core: Se corrige la posible eliminación de referencias PTR nulas en sh_pfc_map_resources(). Esto provocará una eliminación de referencias PTR nulas al usar 'res', si platform_get_resource() devuelve NULL, por lo que se debe mover el uso de 'res' después de devm_ioremap_resource() que lo comprobará para evitar la eliminación de referencias PTR nulas. Y se utiliza devm_platform_get_and_ioremap_resource() para simplificar el código.
  
• Vulnerabilidad en kernel de Linux (CVE-2022-49446)
  Severidad: MEDIA
  Fecha de publicación: 26/02/2025
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nvdimm: Se corrigen los escenarios de bloqueo de activación de firmware Lockdep informa los siguientes escenarios de bloqueo para la administración de energía del dispositivo raíz CXL, device_prepare(), operaciones y operaciones device_shutdown() para dispositivos 'nd_region': Existe una cadena de: &nvdimm_region_key --> &nvdimm_bus->reconfig_mutex --> system_transition_mutex Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(system_transition_mutex); lock(&nvdimm_bus->reconfig_mutex); lock(system_transition_mutex); lock(&nvdimm_region_key); Chain exists of: &cxl_nvdimm_bridge_key --> acpi_scan_lock --> &cxl_root_key Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&cxl_root_key); lock(acpi_scan_lock); lock(&cxl_root_key); lock(&cxl_nvdimm_bridge_key); Estos se derivan de mantener nvdimm_bus_lock() sobre hibernate_quiet_exec() que recorre toda la topología del dispositivo del sistema tomando device_lock() en el camino. nvdimm_bus_lock() protege contra la anulación del registro, múltiples invocadores de operaciones simultáneas y evita que activate_show() compita con activate_store(). Para los primeros 2, el bloqueo es redundante. La anulación del registro ya borra todos los usuarios de operaciones, y sysfs ya evita que varios subprocesos estén activos en un controlador de operaciones al mismo tiempo. Para el último espacio de usuario ya debería estar esperando a que se complete su último activate_store(), y no necesita activate_show() para borrar el lado de escritura, por lo que este uso de bloqueo se puede eliminar en estos atributos.
  
• Vulnerabilidad en kernel de Linux (CVE-2022-49447)
  Severidad: MEDIA
  Fecha de publicación: 26/02/2025
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ARM: hisi: Agregar la falta de of_node_put después de of_find_compatible_node of_find_compatible_node incrementará el recuento de referencias del device_node devuelto. Llamar a of_node_put() para evitar la pérdida de recuento de referencias
  
• Vulnerabilidad en kernel de Linux (CVE-2022-49448)
  Severidad: MEDIA
  Fecha de publicación: 26/02/2025
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: soc: bcm: Verificar el retorno NULL de devm_kzalloc() Como posible fallo de asignación, devm_kzalloc() puede devolver NULL. Entonces, 'pd->pmb' y las siguientes líneas de código pueden generar una desreferencia de puntero nulo. Por lo tanto, es mejor verificar el valor de retorno de devm_kzalloc() para evitar esta confusión.
  
• Vulnerabilidad en kernel de Linux (CVE-2022-49449)
  Severidad: MEDIA
  Fecha de publicación: 26/02/2025
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: pinctrl: renesas: rzn1: Se corrige la posible eliminación de referencias PTR nulas en sh_pfc_map_resources(). Esto provocará una eliminación de referencias PTR nulas al usar 'res', si platform_get_resource() devuelve NULL, por lo que se debe mover el uso de 'res' después de devm_ioremap_resource() que lo comprobará para evitar la eliminación de referencias PTR nulas. Y se utiliza devm_platform_get_and_ioremap_resource() para simplificar el código.
  
• Vulnerabilidad en kernel de Linux (CVE-2022-49450)
  Severidad: MEDIA
  Fecha de publicación: 26/02/2025
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rxrpc: Se corrige que listen() estableciera la barra demasiado alta para los anillos de preasignación El controlador listen() de AF_RXRPC le permite establecer el backlog hasta 32 (si aumenta el sysctl), pero mientras que los búferes circulares de preasignación tienen 32 ranuras en ellos, una de ellas tiene que ser una ranura muerta porque estamos usando CIRC_CNT(). Esto significa que listen(rxrpc_sock, 32) causará un oops cuando el socket se cierre porque rxrpc_service_prealloc_one() asignó una llamada de más y rxrpc_discard_prealloc() no podrá deshacerse de ellas porque pensará que el anillo está vacío. rxrpc_release_calls_on_socket() luego intenta abortarlas, pero falla porque call->peer aún no está configurado. Solucione esto configurando el backlog máximo en RXRPC_BACKLOG_MAX - 1 para que coincida con la capacidad del anillo. ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000086 ... RIP: 0010:rxrpc_send_abort_packet+0x73/0x240 [rxrpc] Call Trace: ? __wake_up_common_lock+0x7a/0x90 ? rxrpc_notify_socket+0x8e/0x140 [rxrpc] ? rxrpc_abort_call+0x4c/0x60 [rxrpc] rxrpc_release_calls_on_socket+0x107/0x1a0 [rxrpc] rxrpc_release+0xc9/0x1c0 [rxrpc] __sock_release+0x37/0xa0 sock_close+0x11/0x20 __fput+0x89/0x240 task_work_run+0x59/0x90 do_exit+0x319/0xaa0
  
• Vulnerabilidad en kernel de Linux (CVE-2022-49451)
  Severidad: MEDIA
  Fecha de publicación: 26/02/2025
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: firmware: arm_scmi: Se corrige la enumeración de protocolos de lista en el protocolo base Al enumerar protocolos implementados por la plataforma SCMI utilizando BASE_DISCOVER_LIST_PROTOCOLS, la cantidad de protocolos devueltos actualmente se valida de manera incorrecta ya que la verificación emplea una suma entre números enteros sin signo que podría desbordarse y hacer que la verificación en sí se omita silenciosamente si el valor devuelto 'loop_num_ret' es lo suficientemente grande. Arregle la validación evitando la suma.
  
• Vulnerabilidad en kernel de Linux (CVE-2022-49453)
  Severidad: MEDIA
  Fecha de publicación: 26/02/2025
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: soc: ti: ti_sci_pm_domains: Verificación de retorno nulo de devm_kcalloc La función de asignación devm_kcalloc puede fallar y devolver un puntero nulo, lo que provocaría una desreferencia de puntero nulo más adelante. Puede ser mejor verificarlo y devolver directamente -ENOMEM tal como se hizo con devm_kcalloc en el código anterior.
  
• Vulnerabilidad en kernel de Linux (CVE-2022-49454)
  Severidad: MEDIA
  Fecha de publicación: 26/02/2025
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PCI: mediatek: Se corrige la pérdida de recuento de referencias en mtk_pcie_subsys_powerup() La función of_find_compatible_node() devuelve un puntero de nodo con el recuento de referencias incrementado. Deberíamos usar of_node_put() en él cuando termine. Agregue el of_node_put() faltante para liberar el recuento de referencias.
  
• Vulnerabilidad en kernel de Linux (CVE-2022-49455)
  Severidad: ALTA
  Fecha de publicación: 26/02/2025
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: misc: ocxl: se corrige la posible doble liberación en ocxl_file_register_afu. Se llamará a info_release() en device_unregister() cuando el recuento de referencias de info->dev sea 0. Por lo tanto, no es necesario llamar a ocxl_afu_put() y kfree() nuevamente. Corrija esto agregando free_minor() y regrese a la ruta de error err_unregister.
  
• Vulnerabilidad en kernel de Linux (CVE-2022-49457)
  Severidad: MEDIA
  Fecha de publicación: 26/02/2025
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ARM: versátil: se agrega el valor of_node_put faltante en dcscb_init. El puntero device_node es devuelto por of_find_compatible_node con refcount incrementado. Deberíamos usar of_node_put() para evitar la fuga de refcount.
  
• Vulnerabilidad en kernel de Linux (CVE-2022-49459)
  Severidad: MEDIA
  Fecha de publicación: 26/02/2025
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: thermal/drivers/broadcom: se corrige la posible desreferenciación NULL en sr_thermal_probe. platform_get_resource() puede devolver NULL. Se agrega la verificación adecuada para evitar una posible desreferenciación NULL.
  
• Vulnerabilidad en kernel de Linux (CVE-2022-49461)
  Severidad: MEDIA
  Fecha de publicación: 26/02/2025
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: amt: se corrige una pérdida de memoria para un mensaje de publicidad. Cuando una puerta de enlace recibe un mensaje de publicidad, extrae información de retransmisión y luego debería liberarse. Pero el controlador de publicidad no lo libera. Por lo tanto, se produciría una pérdida de memoria.
  
• Vulnerabilidad en kernel de Linux (CVE-2022-49462)
  Severidad: MEDIA
  Fecha de publicación: 26/02/2025
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/msm/a6xx: Se corrige la pérdida de recuento de referencias en a6xx_gpu_init of_parse_phandle() devuelve un puntero de nodo con el recuento de referencias incrementado, deberíamos usar of_node_put() en él cuando ya no lo necesitemos. a6xx_gmu_init() pasa el nodo a of_find_device_by_node() y of_dma_configure(), of_find_device_by_node() tomará su referencia, of_dma_configure() no necesita el nodo después del uso. Agregue of_node_put() faltante para evitar la pérdida de recuento de referencias.
  
• Vulnerabilidad en kernel de Linux (CVE-2022-49463)
  Severidad: MEDIA
  Fecha de publicación: 26/02/2025
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: thermal/drivers/imx_sc_thermal: Se corrige la pérdida de recuento de referencias en imx_sc_thermal_probe. of_find_node_by_name() devuelve un puntero de nodo con el recuento de referencias incrementado; cuando termine, debemos usar of_node_put() en él. Se agrega el error of_node_put() faltante para evitar la pérdida de recuento de referencias.
  
• Vulnerabilidad en kernel de Linux (CVE-2022-49466)
  Severidad: MEDIA
  Fecha de publicación: 26/02/2025
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: regulator: scmi: Se corrige la pérdida de recuento de referencias en scmi_regulator_probe. of_find_node_by_name() devuelve un puntero de nodo con el recuento de referencias incrementado; cuando termine, debemos usar of_node_put() en él. Agregue el error of_node_put() faltante para evitar la pérdida de recuento de referencias.
  
• Vulnerabilidad en kernel de Linux (CVE-2022-49467)
  Severidad: MEDIA
  Fecha de publicación: 26/02/2025
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm: msm: se corrige una posible pérdida de memoria en mdp5_crtc_cursor_set() drm_gem_object_lookup llamará a drm_gem_object_get internamente. Por lo tanto, cursor_bo debe colocarse cuando msm_gem_get_and_pin_iova falla.
  
• Vulnerabilidad en kernel de Linux (CVE-2022-49468)
  Severidad: MEDIA
  Fecha de publicación: 26/02/2025
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: thermal/core: Fix memory leak in __thermal_cooling_device_register() Obtuve una pérdida de memoria de la siguiente manera al realizar la prueba de inyección de fallas: objeto sin referencia 0xffff888010080000 (size 264312): comm "182", pid 102533, jiffies 4296434960 (age 10.100s) hex dump (first 32 bytes): 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... ff ff ff ff ff ff ff ff 40 7f 1f b9 ff ff ff ff ........@....... backtrace: [<0000000038b2f4fc>] kmalloc_order_trace+0x1d/0x110 mm/slab_common.c:969 [<00000000ebcb8da5>] __kmalloc+0x373/0x420 include/linux/slab.h:510 [<0000000084137f13>] thermal_cooling_device_setup_sysfs+0x15d/0x2d0 include/linux/slab.h:586 [<00000000352b8755>] __thermal_cooling_device_register+0x332/0xa60 drivers/thermal/thermal_core.c:927 [<00000000fb9f331b>] devm_thermal_of_cooling_device_register+0x6b/0xf0 drivers/thermal/thermal_core.c:1041 [<000000009b8012d2>] max6650_probe.cold+0x557/0x6aa drivers/hwmon/max6650.c:211 [<00000000da0b7e04>] i2c_device_probe+0x472/0xac0 drivers/i2c/i2c-core-base.c:561 If device_register() fails, thermal_cooling_device_destroy_sysfs() need be called to free the memory allocated in thermal_cooling_device_setup_sysfs().
  
• Vulnerabilidad en kernel de Linux (CVE-2022-49471)
  Severidad: ALTA
  Fecha de publicación: 26/02/2025
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rtw89: cfo: comprobar mac_id para evitar fuera de los límites De alguna manera, el hardware informa mac_id incorrecto y contamina la memoria. Compruebe el índice antes de acceder a la matriz. UBSAN: array-index-out-of-bounds in rtw89/phy.c:2517:23 index 188 is out of range for type 's32 [64]' CPU: 1 PID: 51550 Comm: irq/35-rtw89_pc Tainted: G OE Call Trace: show_stack+0x52/0x58 dump_stack_lvl+0x4c/0x63 dump_stack+0x10/0x12 ubsan_epilogue+0x9/0x45 __ubsan_handle_out_of_bounds.cold+0x44/0x49 ? __alloc_skb+0x92/0x1d0 rtw89_phy_cfo_parse+0x44/0x7f [rtw89_core] rtw89_core_rx+0x261/0x871 [rtw89_core] ? __alloc_skb+0xee/0x1d0 rtw89_pci_napi_poll+0x3fa/0x4ea [rtw89_pci] __napi_poll+0x33/0x1a0 net_rx_action+0x126/0x260 ? __queue_work+0x217/0x4c0 __do_softirq+0xd9/0x315 ? disable_irq_nosync+0x10/0x10 do_softirq.part.0+0x6d/0x90 __local_bh_enable_ip+0x62/0x70 rtw89_pci_interrupt_threadfn+0x182/0x1a6 [rtw89_pci] irq_thread_fn+0x28/0x60 irq_thread+0xc8/0x190 ? irq_thread_fn+0x60/0x60 kthread+0x16b/0x190 ? irq_thread_check_affinity+0xe0/0xe0 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x22/0x30
  
• Vulnerabilidad en kernel de Linux (CVE-2022-49472)
  Severidad: MEDIA
  Fecha de publicación: 26/02/2025
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: phy: micrel: Permitir sondeo sin .driver_data Actualmente, si el elemento .probe está presente en la estructura phy_driver y .driver_data no, se produce una desreferencia de puntero NULL. Permitir pasar .probe sin .driver_data insertando comprobaciones NULL para priv->type.
  
• Vulnerabilidad en kernel de Linux (CVE-2022-49473)
  Severidad: MEDIA
  Fecha de publicación: 26/02/2025
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: ti: j721e-evm: Se corrige la pérdida de recuento de referencias en j721e_soc_probe_* of_parse_phandle() devuelve un puntero de nodo con el recuento de referencias incrementado, deberíamos usar of_node_put() en él cuando ya no sea necesario. Agregue of_node_put() faltante para evitar la pérdida de recuento de referencias.
  
• Vulnerabilidad en kernel de Linux (CVE-2022-49475)
  Severidad: MEDIA
  Fecha de publicación: 26/02/2025
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: spi: spi-fsl-qspi: verificar el valor de retorno después de llamar a platform_get_resource_byname() Causará null-ptr-deref si platform_get_resource_byname() devuelve NULL, necesitamos verificar el valor de retorno.
  
• Vulnerabilidad en kernel de Linux (CVE-2022-49476)
  Severidad: MEDIA
  Fecha de publicación: 26/02/2025
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mt76: mt7921: se corrige el fallo del kernel en mt7921_pci_remove El registro de fallos muestra que es posible que se llame a mt7921_irq_handler mientras se maneja devm_free_irq, por lo que mt76_free_device debe posponerse hasta que se complete devm_free_irq para resolver el fallo, liberamos el dispositivo mt76 demasiado pronto. [ 9299.339655] ERROR: desreferencia de puntero NULL del núcleo, dirección: 0000000000000008 [ 9299.339705] #PF: acceso de lectura del supervisor en modo núcleo [ 9299.339735] #PF: error_code(0x0000) - not-present page [ 9299.339768] PGD 0 P4D 0 [ 9299.339786] Oops: 0000 [#1] SMP PTI [ 9299.339812] CPU: 1 PID: 1624 Comm: prepare-suspend Not tainted 5.15.14-1.fc32.qubes.x86_64 #1 [ 9299.339863] Hardware name: Xen HVM domU, BIOS 4.14.3 01/20/2022 [ 9299.339901] RIP: 0010:mt7921_irq_handler+0x1e/0x70 [mt7921e] [ 9299.340048] RSP: 0018:ffffa81b80c27cb0 EFLAGS: 00010082 [ 9299.340081] RAX: 0000000000000000 RBX: ffff98a4cb752020 RCX: ffffffffa96211c5 [ 9299.340123] RDX: 0000000000000000 RSI: 00000000000d4204 RDI: ffff98a4cb752020 [ 9299.340165] RBP: ffff98a4c28a62a4 R08: ffff98a4c37a96c0 R09: 0000000080150011 [ 9299.340207] R10: 0000000040000000 R11: 0000000000000000 R12: ffff98a4c4eaa080 [ 9299.340249] R13: ffff98a4c28a6360 R14: ffff98a4cb752020 R15: ffff98a4c28a6228 [ 9299.340297] FS: 00007260840d3740(0000) GS:ffff98a4ef700000(0000) knlGS:0000000000000000 [ 9299.340345] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 9299.340383] CR2: 0000000000000008 CR3: 0000000004c56001 CR4: 0000000000770ee0 [ 9299.340432] PKRU: 55555554 [ 9299.340449] Call Trace: [ 9299.340467] [ 9299.340485] __free_irq+0x221/0x350 [ 9299.340527] free_irq+0x30/0x70 [ 9299.340553] devm_free_irq+0x55/0x80 [ 9299.340579] mt7921_pci_remove+0x2f/0x40 [mt7921e] [ 9299.340616] pci_device_remove+0x3b/0xa0 [ 9299.340651] __device_release_driver+0x17a/0x240 [ 9299.340686] device_driver_detach+0x3c/0xa0 [ 9299.340714] unbind_store+0x113/0x130 [ 9299.340740] kernfs_fop_write_iter+0x124/0x1b0 [ 9299.340775] new_sync_write+0x15c/0x1f0 [ 9299.340806] vfs_write+0x1d2/0x270 [ 9299.340831] ksys_write+0x67/0xe0 [ 9299.340857] do_syscall_64+0x3b/0x90 [ 9299.340887] entry_SYSCALL_64_after_hwframe+0x44/0xae
  
• Vulnerabilidad en kernel de Linux (CVE-2022-49477)
  Severidad: MEDIA
  Fecha de publicación: 26/02/2025
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: samsung: Se corrige la pérdida de refcount en aries_audio_probe of_parse_phandle() devuelve un puntero de nodo con refcount incrementado, deberíamos usar of_node_put() en él cuando haya terminado. Si extcon_find_edev_by_node() falla, no llama a of_node_put() Llamar a of_node_put() después de extcon_find_edev_by_node() para corregir esto.
  
• Vulnerabilidad en kernel de Linux (CVE-2022-49478)
  Severidad: ALTA
  Fecha de publicación: 26/02/2025
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: pvrusb2: arreglo array-index-out-of-bounds en pvr2_i2c_core_init Syzbot informó que se usa -1 como índice de matriz. El problema estaba en la falta de verificación de validación. hdw->unit_number se inicializa con -1 y luego, si falla el recorrido de tabla init, este valor permanece sin cambios. Dado que el código usa ciegamente este miembro para la indexación de matrices, agregar una verificación de cordura es la solución más fácil para eso. La inicialización de hdw->workpoll se movió hacia arriba para evitar la advertencia en __flush_work.
  
• Vulnerabilidad en kernel de Linux (CVE-2022-49480)
  Severidad: MEDIA
  Fecha de publicación: 26/02/2025
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: imx-hdmi: se corrige la pérdida de recuento de referencias en imx_hdmi_probe. La referencia que toma la instancia de_find_device_by_node() se debe liberar. Deberíamos usar put_device() para liberarla. Cuando falla devm_kzalloc(), no tiene un put_device(), lo que provocará una pérdida de recuento de referencias. Agregue el put_device() faltante para solucionar esto.
  
• Vulnerabilidad en kernel de Linux (CVE-2022-49481)
  Severidad: MEDIA
  Fecha de publicación: 26/02/2025
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: regulator: pfuze100: Se corrige la pérdida de recuento de referencias en pfuze_parse_regulators_dt. of_node_get() devuelve un nodo con un recuento de referencias incrementado. Se llama a of_node_put() para descartar la referencia cuando ya no se necesita.
  
• Vulnerabilidad en kernel de Linux (CVE-2022-49482)
  Severidad: MEDIA
  Fecha de publicación: 26/02/2025
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: mxs-saif: se corrige la pérdida de recuento de referencias en mxs_saif_probe of_parse_phandle() devuelve un puntero de nodo con el recuento de referencias incrementado, deberíamos usar of_node_put() en él cuando haya terminado.
  
• Vulnerabilidad en kernel de Linux (CVE-2022-49483)
  Severidad: MEDIA
  Fecha de publicación: 26/02/2025
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/msm/disp/dpu1: evitar borrar interrupciones de hardware si hw_intr es nulo durante la desiniciación de drm. Si la inicialización del modo edp falla debido a que el panel no está listo y la sonda se pospone durante el enlace de drm, evitar borrar irq y desreferenciar hw_intr cuando hw_intr es nulo. ERROR: No se puede gestionar la desreferencia del puntero NULL del núcleo en la dirección virtual 0000000000000000 Seguimiento de llamadas: dpu_core_irq_uninstall+0x50/0xb0 dpu_irq_uninstall+0x18/0x24 msm_drm_uninit+0xd8/0x16c msm_drm_bind+0x580/0x5fc try_to_bring_up_master+0x168/0x1c0 __component_add+0xb4/0x178 component_add+0x1c/0x28 dp_display_probe+0x38c/0x400 platform_probe+0xb0/0xd0 really_probe+0xcc/0x2c8 __driver_probe_device+0xbc/0xe8 driver_probe_device+0x48/0xf0 __device_attach_driver+0xa0/0xc8 bus_for_each_drv+0x8c/0xd8 __device_attach+0xc4/0x150 device_initial_probe+0x1c/0x28 Cambios en la versión 2: - Se actualiza el mensaje de confirmación y la etiqueta de correcciones de errores. Patchwork: https://patchwork.freedesktop.org/patch/484430/
  
• Vulnerabilidad en kernel de Linux (CVE-2022-49484)
  Severidad: MEDIA
  Fecha de publicación: 26/02/2025
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mt76: mt7915: se corrige una posible desreferencia de puntero NULL en mt7915_mac_fill_rx_vector. Se corrige una posible desreferencia de puntero NULL en la rutina mt7915_mac_fill_rx_vector si el chip no admite dbdc y el hardware informa que band_idx está establecido en 1.
  
• Vulnerabilidad en kernel de Linux (CVE-2022-49485)
  Severidad: MEDIA
  Fecha de publicación: 26/02/2025
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/v3d: Se corrige la desreferenciación del puntero nulo del puntero perfmon. En el improbable caso de que el puntero perfmon sea nulo, la ruta de retorno WARN_ON se produce después de que el puntero ya haya sido desreferenciado. Solucione esto desreferenciando perfmon solo después de que se haya comprobado que es nulo.
  
• Vulnerabilidad en kernel de Linux (CVE-2022-49486)
  Severidad: MEDIA
  Fecha de publicación: 26/02/2025
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: fsl: Se corrige la pérdida de recuento de referencias en imx_sgtl5000_probe. of_find_i2c_device_by_node() toma una referencia. En las rutas de error, debemos llamar a put_device() para eliminar la referencia y evitar la pérdida de recuento.
  
• Vulnerabilidad en kernel de Linux (CVE-2022-49487)
  Severidad: MEDIA
  Fecha de publicación: 26/02/2025
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mtd: rawnand: intel: corrige posible null-ptr-deref en ebu_nand_probe() Provocará null-ptr-deref al usar 'res', si platform_get_resource() devuelve NULL, así que pase a usar 'res' después de devm_ioremap_resource() que lo comprobará para evitar null-ptr-deref.
  
• Vulnerabilidad en kernel de Linux (CVE-2022-49491)
  Severidad: MEDIA
  Fecha de publicación: 26/02/2025
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/rockchip: vop: corrige posible null-ptr-deref en vop_bind() Provocará null-ptr-deref en resource_size(), si platform_get_resource() devuelve NULL, mueve la llamada a resource_size() después de devm_ioremap_resource() que comprobará 'res' para evitar null-ptr-deref.
  
• Vulnerabilidad en kernel de Linux (CVE-2022-49492)
  Severidad: MEDIA
  Fecha de publicación: 26/02/2025
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nvme-pci: corrige una desreferencia de puntero NULL en nvme_alloc_admin_tags En nvme_alloc_admin_tags, admin_q se puede configurar en un error (normalmente -ENOMEM) si la llamada blk_mq_init_queue no puede configurar la cola, que se comprueba inmediatamente después de la llamada. Sin embargo, cuando devolvemos el mensaje de error a la pila, a nvme_reset_work el error nos lleva a nvme_remove_dead_ctrl() nvme_dev_disable() nvme_suspend_queue(&dev->queues[0]). Aquí, solo comprobamos que admin_q no sea NULL, en lugar de no ser un error o NULL, y comenzamos a inactivar una cola que nunca existió, lo que lleva a una desreferencia de puntero NULL incorrecta.
  
• Vulnerabilidad en kernel de Linux (CVE-2022-49494)
  Severidad: MEDIA
  Fecha de publicación: 26/02/2025
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mtd: rawnand: cadence: se corrige un posible null-ptr-deref en cadence_nand_dt_probe(). Provocará un null-ptr-deref al usar 'res', si platform_get_resource() devuelve NULL, así que pase a usar 'res' después de devm_ioremap_resource() que lo comprobará para evitar un null-ptr-deref. Y use devm_platform_get_and_ioremap_resource() para simplificar el código.
  
• Vulnerabilidad en kernel de Linux (CVE-2022-49495)
  Severidad: MEDIA
  Fecha de publicación: 26/02/2025
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/msm/hdmi: comprobar el valor de retorno después de llamar a platform_get_resource_byname(). Esto provocará un error de referencia nulo si platform_get_resource_byname() devuelve NULL. Necesitamos comprobar el valor de retorno. Patchwork: https://patchwork.freedesktop.org/patch/482992/
  
• Vulnerabilidad en kernel de Linux (CVE-2022-49496)
  Severidad: MEDIA
  Fecha de publicación: 26/02/2025
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: mediatek: vcodec: evitar el bloqueo del kernel cuando se ejecuta rmmod mtk-vcodec-dec.ko Si el controlador admite el modo subdev, el parámetro "dev->pm.dev" será NULL en mtk_vcodec_dec_remove. El kernel se bloqueará cuando se intente ejecutar rmmod mtk-vcodec-dec.ko. [ 4380.702726] pc : do_raw_spin_trylock+0x4/0x80 [ 4380.707075] lr : _raw_spin_lock_irq+0x90/0x14c [ 4380.711509] sp : ffff80000819bc10 [ 4380.714811] x29: ffff80000819bc10 x28: ffff3600c03e4000 x27: 0000000000000000 [ 4380.721934] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 [ 4380.729057] x23: ffff3600c0f34930 x22: ffffd5e923549000 x21: 0000000000000220 [ 4380.736179] x20: 0000000000000208 x19: ffffd5e9213e8ebc x18: 0000000000000020 [ 4380.743298] x17: 0000002000000000 x16: ffffd5e9213e8e90 x15: 696c346f65646976 [ 4380.750420] x14: 0000000000000000 x13: 0000000000000001 x12: 0000000000000040 [ 4380.757542] x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 [ 4380.764664] x8 : 0000000000000000 x7 : ffff3600c7273ae8 x6 : ffffd5e9213e8ebc [ 4380.771786] x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000000 [ 4380.778908] x2 : 0000000000000000 x1 : ffff3600c03e4000 x0 : 0000000000000208 [ 4380.786031] Call trace: [ 4380.788465] do_raw_spin_trylock+0x4/0x80 [ 4380.792462] __pm_runtime_disable+0x2c/0x1b0 [ 4380.796723] mtk_vcodec_dec_remove+0x5c/0xa0 [mtk_vcodec_dec] [ 4380.802466] platform_remove+0x2c/0x60 [ 4380.806204] __device_release_driver+0x194/0x250 [ 4380.810810] driver_detach+0xc8/0x15c [ 4380.814462] bus_remove_driver+0x5c/0xb0 [ 4380.818375] driver_unregister+0x34/0x64 [ 4380.822288] platform_driver_unregister+0x18/0x24 [ 4380.826979] mtk_vcodec_dec_driver_exit+0x1c/0x888 [mtk_vcodec_dec] [ 4380.833240] __arm64_sys_delete_module+0x190/0x224 [ 4380.838020] invoke_syscall+0x48/0x114 [ 4380.841760] el0_svc_common.constprop.0+0x60/0x11c [ 4380.846540] do_el0_svc+0x28/0x90 [ 4380.849844] el0_svc+0x4c/0x100 [ 4380.852975] el0t_64_sync_handler+0xec/0xf0 [ 4380.857148] el0t_64_sync+0x190/0x194 [ 4380.860801] Code: 94431515 17ffffca d503201f d503245f (b9400004)
  
• Vulnerabilidad en kernel de Linux (CVE-2022-49497)
  Severidad: MEDIA
  Fecha de publicación: 26/02/2025
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: eliminar dos BUG() de skb_checksum_help() Tengo un informe de syzbot que logró obtener un bloqueo en skb_checksum_help() Si syzbot puede activar estos BUG(), tiene sentido reemplazarlos con WARN_ON_ONCE() más amigables ya que skb_checksum_help() puede devolver un código de error. Tenga en cuenta que syzbot seguirá fallando allí, hasta que se solucione el error real.
  
• Vulnerabilidad en kernel de Linux (CVE-2022-49498)
  Severidad: MEDIA
  Fecha de publicación: 26/02/2025
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: pcm: Verificar si el puntero de la subsecuencia de puntero es nulo antes de desreferenciarlo La subsecuencia de puntero se desreferencia en la asignación de la tarjeta de puntero antes de que la subsecuencia sea verificada como nula con la macro PCM_RUNTIME_CHECK. Aunque PCM_RUNTIME_CHECK llama a BUG_ON, sigue siendo útil realizar la verificación del puntero antes de que se asigne la tarjeta.
  
• Vulnerabilidad en kernel de Linux (CVE-2022-49499)
  Severidad: MEDIA
  Fecha de publicación: 26/02/2025
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/msm: corrige desreferencias de puntero nulo sin iommu. Comprueba si 'aspace' está configurado antes de usarlo, ya que permanecerá nulo sin IOMMU, como en msm8974.
  
• Vulnerabilidad en kernel de Linux (CVE-2022-49502)
  Severidad: MEDIA
  Fecha de publicación: 26/02/2025
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: rga: corrige posible pérdida de memoria en rga_probe rga->m2m_dev debe liberarse cuando rga_probe falla.
  
• Vulnerabilidad en kernel de Linux (CVE-2022-49507)
  Severidad: MEDIA
  Fecha de publicación: 26/02/2025
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: regulador: da9121: Fix uninit-value in da9121_assign_chip_model() KASAN report slab-out-of-bounds in __regmap_init as follows: BUG: KASAN: slab-out-of-bounds in __regmap_init drivers/base/regmap/regmap.c:841 Read of size 1 at addr ffff88803678cdf1 by task xrun/9137 CPU: 0 PID: 9137 Comm: xrun Tainted: G W 5.18.0-rc2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: dump_stack_lvl+0xe8/0x15a lib/dump_stack.c:88 print_report.cold+0xcd/0x69b mm/kasan/report.c:313 kasan_report+0x8e/0xc0 mm/kasan/report.c:491 __regmap_init+0x4540/0x4ba0 drivers/base/regmap/regmap.c:841 __devm_regmap_init+0x7a/0x100 drivers/base/regmap/regmap.c:1266 __devm_regmap_init_i2c+0x65/0x80 drivers/base/regmap/regmap-i2c.c:394 da9121_i2c_probe+0x386/0x6d1 drivers/regulator/da9121-regulator.c:1039 i2c_device_probe+0x959/0xac0 drivers/i2c/i2c-core-base.c:563 This happend when da9121 device is probe by da9121_i2c_id, but with invalid dts. Thus, chip->subvariant_id is set to -EINVAL, and later da9121_assign_chip_model() will access 'regmap' without init it. Fix it by return -EINVAL from da9121_assign_chip_model() if 'chip->subvariant_id' is invalid.
  
• Vulnerabilidad en kernel de Linux (CVE-2022-49508)
  Severidad: ALTA
  Fecha de publicación: 26/02/2025
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: elan: Se corrige una posible doble liberación en elan_input_configured 'input' es un recurso administrado asignado con devm_input_allocate_device(), por lo que no es necesario llamar a input_free_device() explícitamente o habrá una doble liberación. Según la documentación de devm_input_allocate_device(): * Los dispositivos de entrada administrados no necesitan ser desregistrados explícitamente o * liberados ya que se hará automáticamente cuando el dispositivo propietario se desvincule de * su controlador (o la vinculación falle).
  
• Vulnerabilidad en kernel de Linux (CVE-2022-49510)
  Severidad: MEDIA
  Fecha de publicación: 26/02/2025
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/omap: se corrige el error de coccicheck NULL pero desreferenciado Se corrige la siguiente advertencia de coccicheck: ./drivers/gpu/drm/omapdrm/omap_overlay.c:89:22-25: ERROR: r_ovl es NULL pero desreferenciado. Aquí debería ser ovl->idx en lugar de r_ovl->idx.
  
• Vulnerabilidad en kernel de Linux (CVE-2022-49514)
  Severidad: MEDIA
  Fecha de publicación: 26/02/2025
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: mediatek: Se corrige la gestión de errores en la llamada mt8173_max98090_dev_probe of_node_put(platform_node) para evitar la pérdida de recuento de referencias en la ruta de error.
  
• Vulnerabilidad en kernel de Linux (CVE-2022-49516)
  Severidad: MEDIA
  Fecha de publicación: 26/02/2025
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ice: siempre comprobar los valores del puntero VSI de VF La función ice_get_vf_vsi puede devolver NULL en algunos casos, como si se trataran mensajes durante un reinicio en el que se elimina y se vuelve a crear el VSI. Varios lugares del controlador no se molestan en comprobar si este puntero VSI es válido. Las herramientas de análisis estático pueden informar problemas porque detectan rutas en las que se podría desreferenciar un puntero potencialmente NULL. Solucione esto comprobando el valor de retorno de ice_get_vf_vsi en todas partes.
  
• Vulnerabilidad en kernel de Linux (CVE-2022-49517)
  Severidad: MEDIA
  Fecha de publicación: 26/02/2025
  Fecha de última actualización: 17/03/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: mediatek: Se corrige la falta de of_node_put en mt2701_wm8960_machine_probe. Este puntero de nodo es devuelto por of_parse_phandle() con refcount incrementado en esta función. Se llama a of_node_put() para evitar la fuga de refcount.
  
• Vulnerabilidad en aumsrini Bee Layer Slider (CVE-2025-28879)
  Severidad: MEDIA
  Fecha de publicación: 11/03/2025
  Fecha de última actualización: 17/03/2025
  La vulnerabilidad de neutralización incorrecta de la entrada durante la generación de páginas web ('Cross-site Scripting') en aumsrini Bee Layer Slider permite XSS almacenado. Este problema afecta a Bee Layer Slider desde n/d hasta la versión 1.1.