Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: binfmt_flat: soluciona un error de desbordamiento de enteros en sistemas de 32 bits La mayoría de estos tamaños y recuentos están limitados a 256 MB, por lo que el cálculo no da como resultado un desbordamiento de enteros. También es necesario comprobar el recuento de "relocs". De lo contrario, en sistemas de 32 bits, el cálculo de "full_data" podría ser incorrecto. full_data = data_len + relocs * sizeof(unsigned long);

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe/tracing: Arreglar un UAF potencial de TP_printk el commit afd2627f727b ("tracing: Comprobar la desreferencia de "%s" mediante el campo y no el formato TP_printk") expone posibles UAF en el evento de seguimiento xe_bo_move. Arregle estos problemas evitando desreferenciar la matriz xe_mem_type_to_name[] en el momento de TP_printk. Dado que se ha realizado cierta refactorización del código, es posible que se necesite una retroportación explícita para kernels anteriores a la versión 6.10.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm: zynqmp_dp: corrige el desbordamiento de enteros en zynqmp_dp_rate_get() Este parche corrige un posible desbordamiento de enteros en zynqmp_dp_rate_get() El problema surge cuando la expresión drm_dp_bw_code_to_link_rate(dp->test.bw_code) * 10000 se evalúa utilizando 32 bits Ahora la constante es un tipo compatible de 64 bits. Resuelve problemas de cobertura: CID 1636340 y CID 1635811

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/msm/gem: evitar el desbordamiento de enteros en msm_ioctl_gem_submit() Las variables "submit->cmd[i].size" y "submit->cmd[i].offset" son valores u32 que provienen del usuario a través de la función submission_lookup_cmds(). Esta adición podría provocar un error de envoltura de enteros, por lo que se debe utilizar size_add() para evitarlo. Patchwork: https://patchwork.freedesktop.org/patch/624696/

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs/ntfs3: Marcar el inodo como defectuoso tan pronto como se detecte un error en mi_enum_attr() Se amplió la interfaz de la función `mi_enum_attr()` con un parámetro adicional, `struct ntfs_inode *ni`, para permitir marcar el inodo como defectuoso tan pronto como se detecte un error.

En el núcleo de Linux, se ha resuelto la siguiente vulnerabilidad: NFS: Se solucionó un posible desbordamiento de búfer en nfs_sysfs_link_rpc_client() cuyo nombre es char[64], donde el tamaño de clnt->cl_program->name sigue siendo desconocido. Invocar strcat() directamente también provocará un posible desbordamiento de búfer. Cámbielos a strscpy() y strncat() para solucionar posibles problemas.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: firmware: qcom: scm: smc: Handle missing SCM device el commit ca61d6836e6f ("firmware: qcom: scm: fix a NULL-pointer dereference") hace explícito que qcom_scm_get_tzmem_pool() puede devolver NULL, por lo tanto, sus usuarios deben manejar esto.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: ufs: bsg: Establecer bsg_queue en NULL después de la eliminación Actualmente, esto no causa ningún problema, pero creo que es necesario establecer bsg_queue en NULL después de eliminarlo para evitar un posible acceso de use after free (UAF).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: vidtv: Se corrige una desreferencia de puntero nulo en vidtv_mux_stop_thread syzbot informa una desreferencia de puntero nulo en vidtv_mux_stop_thread. [1] Si dvb->mux no se inicializa correctamente mediante vidtv_mux_init() en vidtv_start_streaming(), se activará la desreferencia de puntero nulo sobre mux en vidtv_mux_stop_thread(). Ajuste el tiempo de inicialización de la transmisión y verifíquelo antes de detenerlo. [1] KASAN: null-ptr-deref in range [0x0000000000000128-0x000000000000012f] CPU: 0 UID: 0 PID: 5842 Comm: syz-executor248 Not tainted 6.13.0-rc4-syzkaller-00012-g9b2ffa6148b1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:vidtv_mux_stop_thread+0x26/0x80 drivers/media/test-drivers/vidtv/vidtv_mux.c:471 Code: 90 90 90 90 66 0f 1f 00 55 53 48 89 fb e8 82 2e c8 f9 48 8d bb 28 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 02 7e 3b 0f b6 ab 28 01 00 00 31 ff 89 ee e8 RSP: 0018:ffffc90003f2faa8 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff87cfb125 RDX: 0000000000000025 RSI: ffffffff87d120ce RDI: 0000000000000128 RBP: ffff888029b8d220 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000003 R12: ffff888029b8d188 R13: ffffffff8f590aa0 R14: ffffc9000581c5c8 R15: ffff888029a17710 FS: 00007f7eef5156c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7eef5e635c CR3: 0000000076ca6000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: vidtv_stop_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:209 [inline] vidtv_stop_feed+0x151/0x250 drivers/media/test-drivers/vidtv/vidtv_bridge.c:252 dmx_section_feed_stop_filtering+0x90/0x160 drivers/media/dvb-core/dvb_demux.c:1000 dvb_dmxdev_feed_stop.isra.0+0x1ee/0x270 drivers/media/dvb-core/dmxdev.c:486 dvb_dmxdev_filter_stop+0x22a/0x3a0 drivers/media/dvb-core/dmxdev.c:559 dvb_dmxdev_filter_free drivers/media/dvb-core/dmxdev.c:840 [inline] dvb_demux_release+0x92/0x550 drivers/media/dvb-core/dmxdev.c:1246 __fput+0x3f8/0xb60 fs/file_table.c:450 task_work_run+0x14e/0x250 kernel/task_work.c:239 get_signal+0x1d3/0x2610 kernel/signal.c:2790 arch_do_signal_or_restart+0x90/0x7e0 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop kernel/entry/common.c:111 [inline] exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline] syscall_exit_to_user_mode+0x150/0x2a0 kernel/entry/common.c:218 do_syscall_64+0xda/0x250 arch/x86/entry/common.c:89 entry_SYSCALL_64_after_hwframe+0x77/0x7f

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: rtw89: se corrige la ejecución entre cancel_hw_scan y la finalización de hw_scan El indicador rtwdev->scanning no está protegido por mutex originalmente, por lo que cancel_hw_scan puede pasar la condición, pero de repente la finalización de hw_scan desconfigura el indicador y llama a ieee80211_scan_completed() que liberará local->hw_scan_req. Luego, cancel_hw_scan lanza null-ptr-deref y use-after-free. Arréglelo moviendo la condición de verificación a donde esté protegida por mutex. KASAN: null-ptr-deref in range [0x0000000000000088-0x000000000000008f] CPU: 2 PID: 6922 Comm: kworker/2:2 Tainted: G OE Hardware name: LENOVO 2356AD1/2356AD1, BIOS G7ETB6WW (2.76 ) 09/10/2019 Workqueue: events cfg80211_conn_work [cfg80211] RIP: 0010:rtw89_fw_h2c_scan_offload_be+0xc33/0x13c3 [rtw89_core] Code: 00 45 89 6c 24 1c 0f 85 23 01 00 00 48 8b 85 20 ff ff ff 48 8d RSP: 0018:ffff88811fd9f068 EFLAGS: 00010206 RAX: dffffc0000000000 RBX: ffff88811fd9f258 RCX: 0000000000000001 RDX: 0000000000000011 RSI: 0000000000000001 RDI: 0000000000000089 RBP: ffff88811fd9f170 R08: 0000000000000000 R09: 0000000000000000 R10: ffff88811fd9f108 R11: 0000000000000000 R12: ffff88810e47f960 R13: 0000000000000000 R14: 000000000000ffff R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8881d6f00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007531dfca55b0 CR3: 00000001be296004 CR4: 00000000001706e0 Call Trace: ? show_regs+0x61/0x73 ? __die_body+0x20/0x73 ? die_addr+0x4f/0x7b ? exc_general_protection+0x191/0x1db ? asm_exc_general_protection+0x27/0x30 ? rtw89_fw_h2c_scan_offload_be+0xc33/0x13c3 [rtw89_core] ? rtw89_fw_h2c_scan_offload_be+0x458/0x13c3 [rtw89_core] ? __pfx_rtw89_fw_h2c_scan_offload_be+0x10/0x10 [rtw89_core] ? do_raw_spin_lock+0x75/0xdb ? __pfx_do_raw_spin_lock+0x10/0x10 rtw89_hw_scan_offload+0xb5e/0xbf7 [rtw89_core] ? _raw_spin_unlock+0xe/0x24 ? __mutex_lock.constprop.0+0x40c/0x471 ? __pfx_rtw89_hw_scan_offload+0x10/0x10 [rtw89_core] ? __mutex_lock_slowpath+0x13/0x1f ? mutex_lock+0xa2/0xdc ? __pfx_mutex_lock+0x10/0x10 rtw89_hw_scan_abort+0x58/0xb7 [rtw89_core] rtw89_ops_cancel_hw_scan+0x120/0x13b [rtw89_core] ieee80211_scan_cancel+0x468/0x4d0 [mac80211] ieee80211_prep_connection+0x858/0x899 [mac80211] ieee80211_mgd_auth+0xbea/0xdde [mac80211] ? __pfx_ieee80211_mgd_auth+0x10/0x10 [mac80211] ? cfg80211_find_elem+0x15/0x29 [cfg80211] ? is_bss+0x1b7/0x1d7 [cfg80211] ieee80211_auth+0x18/0x27 [mac80211] cfg80211_mlme_auth+0x3bb/0x3e7 [cfg80211] cfg80211_conn_do_work+0x410/0xb81 [cfg80211] ? __pfx_cfg80211_conn_do_work+0x10/0x10 [cfg80211] ? __kasan_check_read+0x11/0x1f ? psi_group_change+0x8bc/0x944 ? __kasan_check_write+0x14/0x22 ? mutex_lock+0x8e/0xdc ? __pfx_mutex_lock+0x10/0x10 ? __pfx___radix_tree_lookup+0x10/0x10 cfg80211_conn_work+0x245/0x34d [cfg80211] ? __pfx_cfg80211_conn_work+0x10/0x10 [cfg80211] ? update_cfs_rq_load_avg+0x3bc/0x3d7 ? sched_clock_noinstr+0x9/0x1a ? sched_clock+0x10/0x24 ? sched_clock_cpu+0x7e/0x42e ? newidle_balance+0x796/0x937 ? __pfx_sched_clock_cpu+0x10/0x10 ? __pfx_newidle_balance+0x10/0x10 ? __kasan_check_read+0x11/0x1f ? psi_group_change+0x8bc/0x944 ? _raw_spin_unlock+0xe/0x24 ? raw_spin_rq_unlock+0x47/0x54 ? raw_spin_rq_unlock_irq+0x9/0x1f ? finish_task_switch.isra.0+0x347/0x586 ? __schedule+0x27bf/0x2892 ? mutex_unlock+0x80/0xd0 ? do_raw_spin_lock+0x75/0xdb ? __pfx___schedule+0x10/0x10 process_scheduled_works+0x58c/0x821 worker_thread+0x4c7/0x586 ? __kasan_check_read+0x11/0x1f kthread+0x285/0x294 ? __pfx_worker_thread+0x10/0x10 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x29/0x6f ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: rtw89: evitar inicializar la lista mgnt_entry dos veces cuando WoWLAN falla Si WoWLAN falla en el flujo de reanudación, rtw89_ops_add_interface() se activa sin eliminar la interfaz primero. Luego, la lista mgnt_entry se inicializa nuevamente, lo que hace que la comprobación list_empty() en rtw89_chanctx_ops_assign_vif() sea inútil y list_add_tail() nuevamente. Por lo tanto, hemos agregado una comprobación para evitar la doble adición de la lista. rtw89_8852ce 0000:01:00.0: no se pudo comprobar el estado de wow deshabilitado rtw89_8852ce 0000:01:00.0: wow: no se pudo comprobar si el firmware está listo para deshabilitar rtw89_8852ce 0000:01:00.0: wow: no se pudo cambiar al firmware normal rtw89_8852ce 0000:01:00.0: no se pudo deshabilitar wow rtw89_8852ce 0000:01:00.0: no se pudo reanudar para wow -110 rtw89_8852ce 0000:01:00.0: La MAC ya se ha encendido i2c_hid_acpi i2c-ILTK0001:00: PM: acpi_subsys_resume+0x0/0x60 devuelto 0 después de 284705 corrupción de usecs list_add. prev->next debería ser next (ffff9d9719d82228), pero era ffff9d9719f96030. (prev=ffff9d9719f96030). ------------[ cortar aquí ]------------ ¡ERROR del kernel en lib/list_debug.c:34! código de operación no válido: 0000 [#1] PREEMPT SMP NOPTI CPU: 2 PID: 6918 Comm: kworker/u8:19 Contaminado: GUO Nombre del hardware: Google Anraggar/Anraggar, BIOS Google_Anraggar.15217.514.0 25/03/2024 Cola de trabajo: events_unbound async_run_entry_fn RIP: 0010:__list_add_valid_or_report+0x9f/0xb0 Código: e8 56 89 ff ff 0f 0b 48 c7 c7 3e fc e0 96 48 89 c6 e8 45 89 ff ... RSP: 0018:ffffa51b42bbbaf0 EFLAGS: 00010246 RAX: 00000000000000075 RBX: ffff9d9719d82ab0 RCX: 13acb86e047a4400 RDX: 3ffffffffffffffff RSI: 000000000000000 RDI: 00000000ffffdfff RBP: ffffa51b42bbbb28 R08: ffffffff9768e250 R09: 0000000000001fff R10: ffffffff9765e250 R11: 0000000000005ffd R12: ffff9d9719f95c40 R13: ffff9d9719f95be8 R14: ffff9d97081bfd78 R15: ffff9d9719d82060 FS: 0000000000000000(0000) GS:ffff9d9a6fb00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007e7d029a4060 CR3: 0000000345e38000 CR4: 0000000000750ee0 PKRU: 55555554 Seguimiento de llamadas: __die_body+0x68/0xb0 ? die+0xaa/0xd0 ? do_trap+0x9f/0x170 ? __list_add_valid_or_report+0x9f/0xb0 ? __list_add_valid_or_report+0x9f/0xb0 ? handle_invalid_op+0x69/0x90 ? __list_add_valid_or_report+0x9f/0xb0 ? exc_invalid_op+0x3c/0x50 ? asm_exc_invalid_op+0x16/0x20 ? __list_add_valid_or_report+0x9f/0xb0 rtw89_chanctx_ops_assign_vif+0x1f9/0x210 [rtw89_core cbb375c44bf28564ce479002bff66617a25d9ac1] ? __mutex_unlock_slowpath+0xa0/0xf0 rtw89_ops_assign_vif_chanctx+0x4b/0x90 [rtw89_core cbb375c44bf28564ce479002bff66617a25d9ac1] drv_assign_vif_chanctx+0xa7/0x1f0 [mac80211 6efaad16237edaaea0868b132d4f93ecf918a8b6] ieee80211_reconfig+0x9cb/0x17b0 [mac80211 6efaad16237edaaea0868b132d4f93ecf918a8b6] ? __pfx_wiphy_resume+0x10/0x10 [cfg80211 572d03acaaa933fe38251be7fce3b3675284b8ed] ? dev_printk_emit+0x51/0x70 ? _dev_info+0x6e/0x90 wiphy_resume+0x89/0x180 [cfg80211 572d03acaaa933fe38251be7fce3b3675284b8ed] ? __pfx_wiphy_resume+0x10/0x10 [cfg80211 572d03acaaa933fe38251be7fce3b3675284b8ed] dpm_run_callback+0x37/0x1e0 device_resume+0x26d/0x4b0 ? __pfx_dpm_watchdog_handler+0x10/0x10 async_resume+0x1d/0x30 async_run_entry_fn+0x29/0xd0 worker_thread+0x397/0x970 kthread+0xed/0x110 ? __pfx_worker_thread+0x10/0x10 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x38/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommufd/iova_bitmap: Se soluciona el problema de desplazamiento fuera de los límites en iova_bitmap_offset_to_index() Se soluciona un problema de desplazamiento fuera de los límites de UBSAN en iova_bitmap_offset_to_index() donde desplazar la constante "1" (de tipo int) por bitmap->mapped.pgshift (un valor unsigned long) podría resultar en un comportamiento indefinido. La constante "1" tiene como valor predeterminado un "int" de 32 bits, y cuando "pgshift" supera los 31 (por ejemplo, pgshift = 63) la operación de desplazamiento se desborda, ya que el resultado no se puede representar en un tipo de 32 bits. Para resolver esto, la constante se actualiza a "1UL", promoviéndola a un tipo unsigned long para que coincida con el tipo del operando.