Vulnerabilidades

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 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: 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)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: jffs2: se corrige la pérdida de memoria en jffs2_do_mount_fs Si jffs2_build_filesystem() en jffs2_do_mount_fs() devuelve un error, podemos observar el siguiente informe de kmemleak: -------------------------------------------- objeto sin referencia 0xffff88811b25a640 (tamaño 64): comm "mount", pid 691, jiffies 4294957728 (edad 71,952 s) volcado hexadecimal (primeros 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ seguimiento inverso: [] kmem_cache_alloc_trace+0x584/0x880 [] jffs2_sum_init+0x86/0x130 [] jffs2_do_mount_fs+0x798/0xac0 [] jffs2_do_fill_super+0x383/0xc30 [] jffs2_fill_super+0x2ea/0x4c0 [...] objeto sin referencia 0xffff88812c760000 (tamaño 65536): comm "montar", pid 691, jiffies 4294957728 (edad 71,952 s) volcado hexadecimal (primeros 32 bytes): bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ seguimiento inverso: [] __kmalloc+0x6b9/0x910 [] jffs2_sum_init+0xd7/0x130 [] jffs2_do_mount_fs+0x798/0xac0 [] jffs2_do_fill_super+0x383/0xc30 [] jffs2_fill_super+0x2ea/0x4c0 [...] -------------------------------------------- Esto se debe a que los recursos asignados en jffs2_sum_init() no se liberan. Llame a jffs2_sum_exit() para liberar estos recursos y resolver el problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: remoteproc: Se corrige la comprobación de recuento en rproc_coredump_write(). Se comprueba que el recuento sea 0 para evitar un posible desbordamiento. Se hace que la comprobación sea la misma que en rproc_recovery_write().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: NFSD: evitar el desbordamiento de enteros en sistemas de 32 bits. En un sistema de 32 bits, la operación "len * sizeof(*p)" puede tener un desbordamiento de enteros.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cifs: fix handlecache y multiuser En multiuser, cada usuario individual tiene su propia estructura tcon para el recurso compartido y, por lo tanto, su propio identificador para un directorio en caché. Cuando desmontamos un recurso compartido de este tipo, debemos asegurarnos de liberar la entrada dentry fijada para cada uno de esos tcon y no solo el tcon maestro. De lo contrario, recibiremos advertencias desagradables al desmontar que indican que las dentry aún están en uso: [ 3459.590047] ERROR: Dentry 00000000115c6f41{i=12000000019d95,n=/} aún en uso\ (2) [desmontaje de cifs cifs] ... [ 3459.590492] Seguimiento de llamadas: [ 3459.590500] d_walk+0x61/0x2a0 [ 3459.590518] ? shrink_lock_dentry.part.0+0xe0/0xe0 [ 3459.590526] shrink_dcache_for_umount+0x49/0x110 [ 3459.590535] generic_shutdown_super+0x1a/0x110 [ 3459.590542] kill_anon_super+0x14/0x30 [ 3459.590549] cifs_kill_sb+0xf5/0x104 [cifs] [ 3459.590773] deactivate_locked_super+0x36/0xa0 [ 3459.590782] cleanup_mnt+0x131/0x190 [ 3459.590789] task_work_run+0x5c/0x90 [ 3459.590798] exit_to_user_mode_loop+0x151/0x160 [ 3459.590809] exit_to_user_mode_prepare+0x83/0xd0 [ 3459.590818] syscall_exit_to_user_mode+0x12/0x30 [ 3459.590828] do_syscall_64+0x48/0x90 [ 3459.590833] entry_SYSCALL_64_after_hwframe+0x44/0xae

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: NFSD: evitar desbordamiento en nfssvc_decode_writeargs() Smatch se queja: fs/nfsd/nfsxdr.c:341 nfssvc_decode_writeargs() advierte: no hay límite inferior en 'args->len' Cambie el tipo a sin signo para evitar este problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/i915/gem: agregar comprobación de los límites faltante en vm_access Una comprobación de los límites faltante en vm_access() puede provocar una lectura o escritura fuera de los límites en el área de memoria adyacente, ya que el atributo len no se valida antes de memcpy más adelante en la función, lo que potencialmente afecta a: [ 183.637831] ERROR: no se puede manejar la falla de página para la dirección: ffffc90000c86000 [ 183.637934] #PF: acceso de lectura de supervisor en modo kernel [ 183.637997] #PF: error_code(0x0000) - página no presente [ 183.638059] PGD 100000067 P4D 100000067 PUD 100258067 PMD 106341067 PTE 0 [ 183.638144] Oops: 0000 [#2] PREEMPT SMP NOPTI [ 183.638201] CPU: 3 PID: 1790 Comm: poc Contaminado: GD 5.17.0-rc6-ci-drm-11296+ #1 [ 183.638298] Nombre del hardware: Intel Corporation CoffeeLake Client Platform/CoffeeLake H DDR4 RVP, BIOS CNLSFWR1.R00.X208.B00.1905301319 30/05/2019 [ 183.638430] RIP: 0010:memcpy_erms+0x6/0x10 [ 183.640213] RSP: 0018:ffffc90001763d48 EFLAGS: 00010246 [ 183.641117] RAX: ffff888109c14000 RBX: ffff888111bece40 RCX: 0000000000000ffc [ 183.642029] RDX: 0000000000001000 RSI: ffffc90000c86000 RDI: ffff888109c14004 [ 183.642946] RBP: 0000000000000ffc R08: 800000000000016b R09: 0000000000000000 [ 183.643848] R10: ffffc90000c85000 R11: 0000000000000048 R12: 00000000000001000 [ 183.644742] R13: ffff888111bed190 R14: ffff888109c14000 R15: 0000000000001000 [ 183.645653] FS: 00007fe5ef807540(0000) GS:ffff88845b380000(0000) knlGS:0000000000000000 [ 183.646570] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 183.647481] CR2: ffffc90000c86000 CR3: 000000010ff02006 CR4: 00000000003706e0 [ 183.648384] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 000000000000000 [ 183.649271] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 183.650142] Seguimiento de llamadas: [ 183.650988] [ 183.651793] vm_access+0x1f0/0x2a0 [i915] [ 183.652726] __access_remote_vm+0x224/0x380 [ 183.653561] mem_rw.isra.0+0xf9/0x190 [ 183.654402] vfs_read+0x9d/0x1b0 [ 183.655238] ksys_read+0x63/0xe0 [ 183.656065] do_syscall_64+0x38/0xc0 [ 183.656882] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 183.657663] RIP: 0033:0x7fe5ef725142 [ 183.659351] RSP: 002b:00007ffe1e81c7e8 EFLAGS: 00000246 ORIG_RAX: 000000000000000 [ 183.660227] RAX: ffffffffffffffda RBX: 0000557055dfb780 RCX: 00007fe5ef725142 [ 183.661104] RDX: 0000000000001000 RSI: 00007ffe1e81d880 RDI: 000000000000005 [ 183.661972] RBP: 00007ffe1e81e890 R08: 0000000000000030 R09: 0000000000000046 [ 183.662832] R10: 0000557055dfc2e0 R11: 0000000000000246 R12: 0000557055dfb1c0 [ 183.663691] R13: 00007ffe1e81e980 R14: 000000000000000 R15: 000000000000000 Cambios desde v1: - Condición if actualizada con range_overflows_t [Chris Wilson] [mauld: ordena el mensaje de confirmación y agrega Cc: estable] (seleccionado de el commit 661412e301e2ca86799aa4f400d1cf0bd38c57c6)