Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: firmware: sysfb: se corrige la fuga del dispositivo de plataforma en la ruta de error. Asegúrese de liberar el dispositivo de plataforma también en el improbable caso de que falle el registro.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: coresight: syscfg: Se corrige la fuga de memoria en caso de error de registro en cscfg_create_device device_register() llama a device_initialize(), según la documentación de device_initialize: Use put_device() para entregar su referencia en lugar de liberar * @dev directamente una vez que haya llamado a esta función. Para evitar una posible fuga de memoria, use put_device() para la gestión de errores.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iio: accel: mma8452: usa la lógica correcta para obtener mma8452_data La lógica original para obtener mma8452_data es incorrecta, el punto *dev al dispositivo pertenece a iio_dev. No podemos usar este dev para encontrar el i2c_client correcto. La lógica original funcionó porque finalmente usó dev->driver_data para obtener iio_dev. Aquí, usar la API to_i2c_client() es incorrecto y confunde al lector. Para corregir la lógica, debería ser así struct mma8452_data *data = iio_priv(dev_get_drvdata(dev)); Pero después de el commit 8b7651f25962 ("iio: iio_device_alloc(): eliminar drvdata propios innecesarios"), la lógica superior tampoco puede funcionar. Cuando se intenta mostrar la escala disponible en el espacio de usuario, se produce un volcado del kernel y una desreferencia del puntero NULL del manejador del kernel. Por lo tanto, se utiliza dev_to_iio_dev() para corregir la lógica. Dual corrige las etiquetas, ya que la segunda refleja cuándo se expuso el error, mientras que la primera refleja cuándo se introdujo el error original.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tpm: uso try_get_ops() en tpm-space.c Como parte de la conversión en serie para eliminar las operaciones TPM anidadas: https://lore.kernel.org/all/20190205224723.19671-1-jarkko.sakkinen@linux.intel.com/ se eliminó la exposición del chip->tpm_mutex de gran parte del código de nivel superior. En esta conversión, se pasó por alto tpm2_del_space(). Esto no importó mucho porque generalmente se llama poco después de una operación convertida, por lo que solo hay una ventana de ejecución muy pequeña donde se puede quitar el chip antes de que se realice el vaciado de espacio, lo que provoca una desreferencia NULL en el mutex. Sin embargo, hay informes de que esta ventana se alcanza en la práctica, así que solucione esto convirtiendo tpm2_del_space() para usar tpm_try_get_ops(), que realiza todas las comprobaciones de desmontaje antes de adquirir el mutex.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: uaccess: fix entire entiret overflow on access_ok() Tres arquitecturas comprueban el final de un acceso de usuario contra el límite de direcciones sin tener en cuenta un posible desbordamiento. Pasar una longitud negativa u otro desbordamiento aquí devuelve éxito cuando no debería. Utilice la implementación correcta más común aquí, que optimiza para un argumento de "tamaño" constante y convierte el caso común en una única comparación.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mac80211: arregla una posible doble liberación al unirse a la malla Si bien el commit 6a01afcf8468 ("mac80211: mesh: Free ie data when leaving mesh") corrigió una pérdida de memoria al salir/desmontar la malla, introdujo una posible corrupción de memoria causada por una doble liberación al volver a unirse a la malla: ieee80211_leave_mesh() -> kfree(sdata->u.mesh.ie); ... ieee80211_join_mesh() -> copy_mesh_setup() -> old_ie = ifmsh->ie; -> kfree(old_ie); Esta doble liberación/kernel panics se puede reproducir usando wpa_supplicant con una malla cifrada (si se configura sin cifrado a través de "iw", entonces ifmsh->ie siempre es NULL, lo que evita este problema). Y luego llamar a: $ iw dev mesh0 mesh leave $ iw dev mesh0 mesh join my-mesh Tenga en cuenta que normalmente estos comandos no se usan/funcionan cuando se usa wpa_supplicant. Y parece que wpa_supplicant o wpa_cli están pasando por un ciclo NETDEV_DOWN/NETDEV_UP entre un mesh leave y un mesh join donde NETDEV_UP restablece mesh.ie a NULL a través de un memcpy de default_mesh_setup en cfg80211_netdev_notifier_call, que luego también evita la corrupción de memoria. El problema se observó por primera vez en una aplicación que no usaba wpa_supplicant sino "Senf", que implementa sus propias llamadas a nl80211. Se solucionó el problema eliminando el kfree()'ing del IE de malla en la función de unión de malla y dejando únicamente en manos del mesh leave la liberación del IE de malla.

En el núcleo de Linux, se ha resuelto la siguiente vulnerabilidad: can: m_can: m_can_tx_handler(): se corrige el use after free skb can_put_echo_skb() clonará skb y luego lo liberará. Mueva can_put_echo_skb() para la versión 3.0.x de m_can directamente antes del inicio de la transmisión en el hardware, de manera similar a la rama 3.1.x.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cifs: evitar longitudes de salida incorrectas en smb2_ioctl_query_info() Al llamar a smb2_ioctl_query_info() con smb_query_info::flags=PASSTHRU_FSCTL y smb_query_info::output_buffer_length=0, lo siguiente devolvería 0x10 buffer = memdup_user(arg + sizeof(struct smb_query_info), qi.output_buffer_length); if (IS_ERR(buffer)) { kfree(vars); return PTR_ERR(buffer); } en lugar de un puntero válido, lo que hace que la comprobación de IS_ERR() falle. Esto provocaría una deferencia ptr NULL en @buffer al acceder a él más tarde en smb2_ioctl_query_ioctl(). Mientras tanto, evite tener un @buffer más pequeño que 8 bytes para manejar correctamente las solicitudes SMB2_SET_INFO FileEndOfFileInformation cuando smb_query_info::flags=PASSTHRU_SET_INFO. Aquí hay un pequeño reproductor de C que activa un ptr NULL en @buffer cuando pasa un smb_query_info::flags no válido #include #include #include #include #include #include #define die(s) perror(s), exit(1) #define QUERY_INFO 0xc018cf07 int main(int argc, char *argv[]) { int fd; if (argc < 2) exit(1); fd = open(argv[1], O_RDONLY); si (fd == -1) morir("abrir"); si (ioctl(fd, QUERY_INFO, (uint32_t[]) { 0, 0, 0, 4, 0, 0}) == -1) morir("ioctl"); cerrar(fd); devolver 0; } mount.cifs //srv/share /mnt -o ... gcc repro.c && ./a.out /mnt/f0 [ 114.138620] fallo de protección general, probablemente para dirección no canónica 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI [ 114.139310] KASAN: null-ptr-deref en rango [0x000000000000000-0x0000000000000007] [ 114.139775] CPU: 2 PID: 995 Comm: a.out No contaminado 5.17.0-rc8 #1 [ 114.140148] Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS rel-1.15.0-0-g2dd4b9b-rebuilt.opensuse.org 01/04/2014 [ 114.140818] RIP: 0010:smb2_ioctl_query_info+0x206/0x410 [cifs] [ 114.141221] Código: 00 00 00 00 fc ff df 48 c1 ea 03 80 3c 02 00 0f 85 c8 01 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b 7b 28 4c 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 9c 01 00 00 49 8b 3f e8 58 02 fb ff 48 8b 14 24 [ 114.142348] RSP: 0018:ffffc90000b47b00 EFLAGS: 00010256 [ 114.142692] RAX: dffffc0000000000 RBX: ffff888115503200 RCX: fffffffa020580d [ 114.143119] RDX: 00000000000000000 RSI: 000000000000000004 RDI: fffffffa043a380 [ 114.143544] PBR: ffff888115503278 R08: 0000000000000001 R09: 00000000000000003 [ 114.143983] R10: fffffbfff4087470 R11: 0000000000000001 R12: ffff888115503288 [ 114.144424] R13: 00000000ffffffea R14: ffff888115503228 R15: 0000000000000000 [ 114.144852] FS: 00007f7aeabdf740(0000) GS:ffff888151600000(0000) knlGS:00000000000000000 [ 114.145338] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 114.145692] CR2: 00007f7aeacfdf5e CR3: 000000012000e000 CR4: 0000000000350ee0 [ 114.146131] Seguimiento de llamadas: [ 114.146291] [ 114.146432] ? smb2_query_reparse_tag+0x890/0x890 [cifs] [ 114.146800] ? cifs_mapchar+0x460/0x460 [cifs] [ 114.147121] ? rcu_read_lock_sched_held+0x3f/0x70 [ 114.147412] ? cifs_strndup_to_utf16+0x15b/0x250 [cifs] [ 114.147775] ? dentry_path_raw+0xa6/0xf0 [ 114.148024] ? cifs_convert_path_to_utf16+0x198/0x220 [cifs] [ 114.148413] ? smb2_check_message+0x1080/0x1080 [cifs] [ 114.148766] ? rcu_read_lock_sched_held+0x3f/0x70 [ 114.149065] cifs_ioctl+0x1577/0x3320 [cifs] [ 114.149371] ? lock_downgrade+0x6f0/0x6f0 [ 114.149631] ? cifs_readdir+0x2e60/0x2e60 [cifs] [ 114.149956] ? rcu_read_lock_sched_held+0x3f/0x70 [ 114.150250] ? __rseq_handle_notify_resume+0x80b/0xbe0 [ 114.150562] ? __up_read+0x192/0x710 [ 114.150791] ? __ia32_sys_rseq+0xf0/0xf0 [ 114.151025] ? __x64_sys_openat+0x11f/0x1d0 [ 114.151296] __x64_sys_ioctl+0x127/0x190 [ 114.151549] do_syscall_64+0x3b/0x90 [ 114.151768] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 114.152079] RIP: 0033:0x7f7aead043df [ 114.152306] Código: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: pcm: Arreglar un posible bloqueo AB/BA con buffer_mutex y mmap_lock syzbot capturó un posible punto muerto entre PCM runtime->buffer_mutex y mm->mmap_lock. Fue provocado por la corrección reciente para cubrir la lectura/escritura acelerada y otras ioctl, y en esa confirmación, pasé por alto un caso extremo (con suerte el único) que puede tomar el bloqueo de reversión, es decir, el mmap de OSS. La operación mmap de OSS permite excepcionalmente reconfigurar los parámetros dentro de la llamada al sistema mmap de OSS, donde ya se mantiene mm->mmap_mutex. Mientras tanto, las llamadas copy_from/to_user en operaciones de lectura/escritura también toman el mm->mmap_lock internamente, por lo tanto, puede llevar a un punto muerto AB/BA. Ya se vio un problema similar en el pasado y lo arreglamos con un refcount (en el commit b248371628aa). La corrección anterior solo cubría las rutas de llamadas con lectura/escritura de OSS y controles ioctl de OSS, mientras que ahora necesitamos cubrir el acceso concurrente a través de las API de ALSA y OSS. Este parche soluciona el problema anterior al reemplazar el bloqueo buffer_mutex en las operaciones de lectura/escritura con un refcount similar al que hemos usado para OSS. El nuevo campo, runtime->buffer_accessing, mantiene el número de operaciones de lectura/escritura concurrentes. A diferencia de la protección buffer_mutex anterior, esto protege solo alrededor de las llamadas copy_from/to_user(); los otros códigos están básicamente protegidos por el bloqueo de flujo PCM. El refcount puede ser negativo, lo que significa que está bloqueado por los controles ioctl. Si se ve un valor negativo, la lectura/escritura se cancela con -EBUSY. En el lado de los controles ioctl, por otro lado, también verifican este refcount y lo establecen en un valor negativo para bloquear a menos que ya se esté accediendo a él.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rtc: pl031: se corrige la desreferencia de puntero nulo de las funciones rtc Cuando no hay una línea de interrupción, la función de alarma rtc se desactiva. La eliminación del bit de la función de alarma se realizaba antes de las asignaciones del dispositivo ldata->rtc, lo que generaba una desreferencia de puntero nulo. Borre RTC_FEATURE_ALARM después de que se asigne el dispositivo rtc.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ocfs2: se corrige un fallo al montar con la cuota habilitada Se ha informado de un fallo al montar ocfs2 con la cuota habilitada. RIP: 0010:ocfs2_qinfo_lock_res_init+0x44/0x50 [ocfs2] Seguimiento de llamadas: ocfs2_local_read_info+0xb9/0x6f0 [ocfs2] dquot_load_quota_sb+0x216/0x470 dquot_load_quota_inode+0x85/0x100 ocfs2_enable_quotas+0xa0/0x1c0 [ocfs2] ocfs2_fill_super.cold+0xc8/0x1bf [ocfs2] mount_bdev+0x185/0x1b0 legacy_get_tree+0x27/0x40 vfs_get_tree+0x25/0xb0 path_mount+0x465/0xac0 __x64_sys_mount+0x103/0x140 Esto se debe a que, al inicializar dqi_gqlock, los dqi_type y dqi_sb correspondientes no se inicializan correctamente. Este problema lo introduce el commit 6c85c2c72819, que quiere evitar el acceso a variables no inicializadas en casos de error. Por lo tanto, haga que la información de cuota global se inicialice correctamente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: jffs2: corregir pérdida de memoria en jffs2_scan_medium Si se devuelve un error en jffs2_scan_eraseblock() y se ha añadido algo de memoria a los *s de jffs2_summary, podemos observar el siguiente informe de kmemleak: -------------------------------------------- unreferenced object 0xffff88812b889c40 (size 64): comm "mount", pid 692, jiffies 4294838325 (age 34.288s) hex dump (first 32 bytes): 40 48 b5 14 81 88 ff ff 01 e0 31 00 00 00 50 00 @H........1...P. 00 00 01 00 00 00 01 00 00 00 02 00 00 00 09 08 ................ seguimiento inverso:[] __kmalloc+0x613/0x910 [] jffs2_sum_add_dirent_mem+0x5c/0xa0 [] jffs2_scan_medium.cold+0x36e5/0x4794 [] jffs2_do_mount_fs.cold+0xa7/0x2267 [] jffs2_do_fill_super+0x383/0xc30 [] jffs2_fill_super+0x2ea/0x4c0 [] mtd_get_sb+0x254/0x400 [] mtd_get_sb_by_nr+0x4f/0xd0 [] get_tree_mtd+0x498/0x840 [] jffs2_get_tree+0x25/0x30 [] vfs_get_tree+0x8d/0x2e0 [] path_mount+0x50f/0x1e50 [] do_mount+0x107/0x130 [] __se_sys_mount+0x1c5/0x2f0 [] __x64_sys_mount+0xc7/0x160 [] do_syscall_64+0x45/0x70 objeto sin referencia 0xffff888114b54840 (tamaño 32): comm "mount", pid 692, jiffies 4294838325 (antigüedad 34.288s) volcado hexadecimal (primeros 32 bytes): c0 75 b5 14 81 88 ff ff 02 e0 02 00 00 00 02 00 .u.............. 00 00 84 00 00 00 44 00 00 00 6b 6b 6b 6b 6b a5 ......D...kkkkk. backtrace: [] kmem_cache_alloc_trace+0x584/0x880 [] jffs2_sum_add_inode_mem+0x54/0x90 [] jffs2_scan_medium.cold+0x4481/0x4794 [...] objeto sin referencia 0xffff888114b57280 (tamaño 32): comm "mount", pid 692, jiffies 4294838393 (edad 34.357s) volcado hexadecimal (primeros 32 bytes): 10 d5 6c 11 81 88 ff ff 08 e0 05 00 00 00 01 00 ..l............. 00 00 38 02 00 00 28 00 00 00 6b 6b 6b 6b 6b a5 ..8...(...kkkkk. seguimiento inverso: [] kmem_cache_alloc_trace+0x584/0x880 [] jffs2_sum_add_xattr_mem+0x54/0x90 [] jffs2_scan_medium.cold+0x298c/0x4794 [...] objeto sin referencia 0xffff8881116cd510 (tamaño 16): comm "mount", pid 692, jiffies 4294838395 (edad 34.355s) volcado hexadecimal (primeros 16 bytes): 00 00 00 00 00 00 00 00 09 e0 60 02 00 00 6b a5 ..........`...k. backtrace: [] kmem_cache_alloc_trace+0x584/0x880 [] jffs2_sum_add_xref_mem+0x54/0x90 [] jffs2_scan_medium.cold+0x3a20/0x4794 [...] -------------------------------------------- Por lo tanto, debemos llamar a jffs2_sum_reset_collected(s) al salir para liberar la memoria agregada en s. Además, se agrega una nueva etiqueta "out_buf" para evitar la referencia de puntero NULL causada por s que es NULL. (gracias a Zhang Yi por este análisis)