Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: ISO: Verifique el indicador de socket en lugar de hcon. Esto corrige la siguiente advertencia del verificador estático de Smatch: net/bluetooth/iso.c:1364 iso_sock_recvmsg() error: previamente asumimos 'pi ->conn->hcon' podría ser nulo (línea 1359) net/bluetooth/iso.c 1347 static int iso_sock_recvmsg(struct socket *sock, struct msghdr *msg, 1348 size_t len, int flags) 1349 { 1350 struct sock *sk = calcetín->sk; 1351 estructura iso_pinfo *pi = iso_pi(sk); 1352 1353 BT_DBG("sk%p",sk); 1354 1355 if (test_and_clear_bit(BT_SK_DEFER_SETUP, &bt_sk(sk)->flags)) { 1356 lock_sock(sk); 1357 interruptor (sk->sk_state) { 1358 caso BT_CONNECT2: 1359 si (pi->conn->hcon && ^^^^^^^^^^^^^^ Si ->hcon es NULL 1360 test_bit(HCI_CONN_PA_SYNC, &pi ->conn->hcon->flags)) { 1361 iso_conn_big_sync(sk); 1362 sk->sk_state = BT_LISTEN; 1363 } else { --> 1364 iso_conn_defer_accept(pi->conn->hcon); ^^^^^^^^^^^^^^ entonces estamos 1365 sk->sk_state = BT_CONFIG; 1366 } 1367 liberación_sock(sk); 1368 devuelve 0; 1369 caso BT_CONNECTED: 1370 si (test_bit(BT_SK_PA_SYNC,

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: evitar desbordamientos en la lógica de limitación sucia La lógica de limitación sucia se entremezcla con suposiciones de que los límites sucios en unidades PAGE_SIZE caben en 32 bits (de modo que varias multiplicaciones caben en 64 bits) . Si los límites terminan siendo mayores, tendremos desbordamientos, posibles divisiones entre 0, etc. Solucione estos problemas nunca permitiendo límites sucios tan grandes, ya que de todos modos tienen un valor práctico dudoso. Para las interfaces dirty_bytes/dirty_background_bytes podemos simplemente negarnos a establecer límites tan grandes. Para dirty_ratio / dirty_background_ratio no es tan simple ya que el límite sucio se calcula a partir de la cantidad de memoria disponible que puede cambiar debido a la conexión en caliente de la memoria, etc. Entonces, al convertir límites sucios de proporciones a números de páginas, simplemente no permitimos el el resultado excede UINT_MAX. Este es un problema que se puede activar solo desde la raíz y que ocurre cuando el operador establece límites sucios en >16 TB.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cdrom: reorganice la verificación de last_media_change para evitar un desbordamiento involuntario. Al ejecutar syzkaller con el sanitizador de ajuste de enteros firmado recientemente reintroducido, nos encontramos con este símbolo: [366.015950] UBSAN: desbordamiento de enteros firmados en .. /drivers/cdrom/cdrom.c:2361:33 [ 366.021089] -9223372036854775808 - 346321 no se puede representar en el tipo '__s64' (también conocido como 'long long') [ 366.025894] El programa syz-executor.4 está utilizando un ioctl SCSI obsoleto, conviértalo a SG_IO [366.027502] CPU: 5 PID: 28472 Comm: syz-executor.7 Not tainted 6.8.0-rc2-00035-gb3ef86b5a957 #1 [366.027512] Nombre de hardware: PC estándar QEMU (i440FX + PIIX, 1996) , BIOS 1.16.3-debian-1.16.3-2 01/04/2014 [ 366.027518] Seguimiento de llamadas: [ 366.027523] [ 366.027533] dump_stack_lvl+0x93/0xd0 [ 366.027899] 1b0 [366.038787] ata1 .00: ¿multi_count 32 no válido se ignora [366.043924] cdrom_ioctl+0x2c3f/0x2d10 [366.063932]? __pm_runtime_resume+0xe6/0x130 [ 366.071923] sr_block_ioctl+0x15d/0x1d0 [ 366.074624] ? __pfx_sr_block_ioctl+0x10/0x10 [ 366.077642] blkdev_ioctl+0x419/0x500 [ 366.080231] ? __pfx_blkdev_ioctl+0x10/0x10 ... Históricamente, el sanitizador de desbordamiento de enteros con signo no funcionaba en el kernel debido a su interacción con `-fwrapv` pero desde entonces esto se ha cambiado [1] en la versión más reciente de Clang. Se volvió a habilitar en el kernel con el compromiso 557f8c582a9ba8ab ("ubsan: reintroducir el sanitizadorde desbordamiento firmado"). Reorganicemos la verificación para no realizar ninguna aritmética y así no activar el sanitizador.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Bluetooth: qca: corrija el error de habilitación de BT nuevamente para QCA6390 después de un reinicio en caliente. La confirmación 272970be3dab ("Bluetooth: hci_qca: corrija el apagado del controlador en un serdev cerrado") causará el siguiente problema de regresión: BT puede No se habilitará después de los pasos siguientes: arranque en frío -> habilitar BT -> deshabilitar BT -> reinicio en caliente -> falla de habilitación de BT si la propiedad enable-gpios no está configurada dentro de DT|ACPI para QCA6390. El compromiso es solucionar un problema de use after free dentro de qca_serdev_shutdown() agregando una condición para evitar que el serdev se vacíe o escriba después de cerrarse, pero también introduce este problema de regresión con respecto a los pasos anteriores, ya que el VSC no se envía para restablecer el controlador durante el reinicio en caliente. . Se solucionó enviando el VSC para restablecer el controlador dentro de qca_serdev_shutdown() una vez que BT estuvo habilitado, y el problema de use after free también se solucionó con este cambio ya que el serdev todavía está abierto antes de vaciarse o escribirse. Verificado por la computadora portátil Dell XPS 13 9310 de la máquina informada en las siguientes dos confirmaciones del kernel: confirmación e00fc2700a3f ("Bluetooth: btusb: solución de activación de la implementación de coredump para QCA") del árbol siguiente de bluetooth. confirme b23d98d46d28 ("Bluetooth: btusb: solución que activa la implementación de coredump para QCA") del árbol principal de Linux.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mlxsw: core_linecards: corrige la doble desasignación de memoria en caso de un archivo INI no válido En caso de un archivo INI no válido, mlxsw_linecard_types_init() desasigna la memoria pero no restablece el puntero a NULL y devuelve 0. En caso de que se produzca algún error después de la llamada a mlxsw_linecard_types_init(), mlxsw_linecards_init() llama a mlxsw_linecard_types_fini(), que realiza la desasignación de memoria nuevamente. Agregue el reinicio del puntero a NULL. Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: riscv: kexec: evitar interbloqueo en la ruta de bloqueo de kexec Si se llama al código de bloqueo de kexec en el contexto de interrupción, la función machine_kexec_mask_interrupts() activará un interbloqueo al intentar adquirir el spinlock irqdesc y luego desactive irqchip en la función irq_set_irqchip_state(). A diferencia de arm64, riscv solo requiere que el controlador irq_eoi complete la EOI y mantener irq_set_irqchip_state() solo dejará este posible punto muerto sin ningún uso. Así que simplemente lo eliminamos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5: E-switch, crea ACL de entrada cuando sea necesario Actualmente, la acl de entrada se utiliza para tres funciones. Se crea solo cuando la coincidencia de metadatos de vport y la etiqueta prio están habilitadas. Pero el modo de retraso de respaldo activo también lo usa. Es independiente de la coincidencia de metadatos de vport y de la etiqueta prio. Y la coincidencia de metadatos de vport se puede desactivar usando el siguiente comando devlink: # devlink dev param set pci/0000:08:00.0 name esw_port_metadata \ value false cmode runtime Si no se crea la acl de entrada, entrará en pánico al crear una regla de eliminación para la copia de seguridad activa modo de retraso. Si lo crea siempre, habrá una degradación del rendimiento de aproximadamente un 5 %. Solucionarlo creando una acl de entrada cuando sea necesario. Si esw_port_metadata es verdadero, la acl de entrada existe, luego cree una regla de eliminación utilizando la acl de entrada existente. Si esw_port_metadata es falso, cree una acl de entrada y luego cree una regla de eliminación.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfc/nci: agregue la verificación de inconsistencia entre la longitud de los datos de entrada y el recuento write$nci(r0, &(0x7f0000000740)=ANY=[@ANYBLOB="610501"], 0xf ) Syzbot construyó una llamada write() con una longitud de datos de 3 bytes pero un valor de conteo de 15, que pasó muy pocos datos para cumplir con los requisitos básicos de la función nci_rf_intf_activated_ntf_packet(). Por lo tanto, aumentar la comparación entre la longitud de los datos y el valor del recuento para evitar problemas causados por una longitud y un recuento de datos inconsistentes.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amd/display: ASSERT cuando no se puede encontrar el índice por avión/ID de flujo [POR QUÉ] find_disp_cfg_idx_by_plane_id y find_disp_cfg_idx_by_stream_id devuelven un índice de matriz y devuelven -1 cuando no se encuentran; sin embargo, -1 no es un número de índice válido. [CÓMO] Cuando esto suceda, llame a ASSERT() y devuelva un número positivo (que es menor que el tamaño de la matriz de quienes llaman). Esto soluciona 4 problemas de OVERRUN y 2 NEGATIVE_RETURNS informados por Coverity.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: no devolver ID de flujo negativo para la matriz [POR QUÉ] Resource_stream_to_stream_idx devuelve un índice de matriz y devuelve -1 cuando no se encuentra; sin embargo, -1 no es un número de índice de matriz válido. [CÓMO] Cuando esto suceda, llame a ASSERT() y devuelva un cero en su lugar. Esto soluciona problemas de OVERRUN y NEGATIVE_RETURNS informados por Coverity.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu: corrige las advertencias del puntero err_addr doble libre. En amdgpu_umc_bad_page_polling_timeout, amdgpu_umc_handle_bad_pages se ejecutará muchas veces para que err_addr libre doble en algún caso especial. Así que establezca err_addr en NULL para evitar las advertencias.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: rtw89: fw: la descarga de escaneo prohíbe todos los canales de 6 GHz si no hay una banda de 6 GHz. Tenemos alguna política a través de BIOS para bloquear los usos de 6 GHz. En este caso, la banda de 6 GHz será NULL incluso si se trata de un chip WiFi 7. Por lo tanto, agregue manejo NULL aquí para evitar fallos.