Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: hwmon: (mlxreg-fan) Devuelve un valor distinto de cero cuando el estado actual del ventilador se aplica desde sysfs. La velocidad mínima del ventilador se puede aplicar desde sysfs. Por ejemplo, configurar la velocidad actual del ventilador en 20 se utiliza para hacer que la velocidad del ventilador esté al 100 %, 19, para que no esté por debajo del 90 %, etcétera. Esta característica brinda la capacidad de limitar la velocidad del ventilador de acuerdo con algunas consideraciones del sistema, como la ausencia de algunas unidades reemplazables o la alta temperatura ambiente del sistema. La solicitud para cambiar la velocidad mínima del ventilador es una solicitud de configuración y solo se puede configurar mediante el procedimiento de escritura 'sysfs'. En esta situación, el valor del argumento "estado" está por encima de la velocidad máxima nominal del ventilador. En este caso, devuelva un código distinto de cero para evitar la llamada a Thermal_cooling_device_stats_update(), porque en este caso la actualización de estadísticas viola el rango de la tabla de estadísticas térmicas. Los problemas se observan en caso de que el kernel esté configurado con la opción CONFIG_THERMAL_STATISTICS. Aquí está el rastro de KASAN: [159.506659] ERROR: KASAN: slab fuera de los límites en Thermal_cooling_device_stats_update+0x7d/0xb0 [159.516016] Lectura de tamaño 4 en la dirección ffff888116163840 mediante la tarea hw-management.s/7444 [ 625] Llamada Seguimiento: [159.548366] dump_stack+0x92/0xc1 [159.552084]? Thermal_cooling_device_stats_update+0x7d/0xb0 [ 159.635869] Thermal_zone_device_update+0x345/0x780 [ 159.688711] Thermal_zone_device_set_mode+0x7d/0xc0 [ 159.694174] mlxsw_thermal_modules_init+0x48f /0x590 [mlxsw_core] [159.700972]? mlxsw_thermal_set_cur_state+0x5a0/0x5a0 [mlxsw_core] [ 159.731827] mlxsw_thermal_init+0x763/0x880 [mlxsw_core] [ 160.070233] RIP: 0033:0x7fd995909970 [ 160.07423 9] Código: 73 01 c3 48 8b 0d 28 d5 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 99 2d 2c 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d 01 f0 ff .. [ 160.095242] RSP: 00007fff54f5d938 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 160.103722] RAX: ffffffffffffffda RBX: 0000000000000013 RCX: 00007fd995909970 [ 160.111710] RDX: 00000000000000013 RSI: 0000000001906008 RDI: 000000000000 0001 [ 160.119699] RBP: 0000000001906008 R08: 00007fd995bc9760 R09: 00007fd996210700 [ 160.127687] R10: 0000000000000073 R11: 000000246 R12: 00000000000000013 [ 160.135673] R13: 0000000000000001 R14: 00007fd995bc8600 R15: 0000000000000013 [ 160.143671] [ 160.145338] Asignado por tarea 2924: [ 160.149242] x40 [ 160.153541] __kasan_kmalloc+0x7f/0xa0 [ 160.157743] __kmalloc+0x1a2/0x2b0 [ 160.161552] Thermal_cooling_device_setup_sysfs+0xf9/0x1a0 [ 160.167687] __thermal_cooling_device_register+0x1b5/0x500 [ 160.173833] devm_thermal_of_cooling_device_register+0x60/0xa0 [ 160.180356] mlxreg_fan_probe+0x474/0x5e0 [mlxreg_fan] [ 160. 248140] [160.249807] La dirección con errores pertenece al objeto en ffff888116163400 [160.249807] que pertenece al caché kmalloc-1k de tamaño 1024 [ 160.263814] La dirección con errores se encuentra 64 bytes a la derecha de [ 160.263814] Región de 1024 bytes [ffff888116163400, ffff888116163800) [ 160.277536] La dirección con errores pertenece a la página: [ 160.2 82898] página:0000000012275840 refcount :1 mapcount:0 mapeo:0000000000000000 índice:0xffff888116167000 pfn:0x116160 [ 160.294872] head:0000000012275840 orden:3 compuesto_mapcount:0 compuesto_pincount:0 [ 160.303251] banderas: 00000010200(slab|cabeza|nodo=0|zona=2) [ 160.309694 ] sin formato: 0200000000010200 ffffea00046f7208 ffffea0004928208 ffff88810004dbc0 [ 160.318367] sin formato: ffff888116167000 00000000000a0006 00000001ffffffff 0000000000000000 [160.327033] página volcada porque: kasan: mal acceso detectado [160.333270] [160.334937] Estado de la memoria alrededor de la dirección con errores: [160.356469] >ffff888116163800: fc ..

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nf_tables: desvincular la tabla antes de eliminarla syzbot informa de lo sigueinte. UAF: BUG: KASAN: use-after-free en memcmp+0x18f/0x1c0 lib/string.c:955 nla_strcmp+ 0xf2/0x130 lib/nlattr.c:836 nft_table_lookup.part.0+0x1a2/0x460 net/netfilter/nf_tables_api.c:570 nft_table_lookup net/netfilter/nf_tables_api.c:4064 [en línea] nf_tables_getset+0x1b3/0x860 net /filtro de red/ nf_tables_api.c:4064 nfnetlink_rcv_msg+0x659/0x13f0 net/netfilter/nfnetlink.c:285 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2504 El problema es que todas las operaciones de obtención no tienen bloqueo, por lo que el commit_mutex mantenido por () no es suficiente para evitar que una solicitud GET paralela realice accesos de lectura al objeto de la tabla incluso después de sincronizar_rcu(). Para evitar esto, primero desvincule la tabla y almacene los objetos de la tabla en el espacio temporal de la pila.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mac80211: límite inyectado de vht mcs/nss en ieee80211_parse_tx_radiotap. Limite los valores máximos para vht mcs y nss en la rutina ieee80211_parse_tx_radiotap para corregir la siguiente advertencia reportada por syzbot: ADVERTENCIA: CPU: 0 PID : 10717 en include/net/mac80211.h:989 ieee80211_rate_set_vht include/net/mac80211.h:989 [en línea] ADVERTENCIA: CPU: 0 PID: 10717 en include/net/mac80211.h:989 ieee80211_parse_tx_radiotap+0x101e/0x12 d0 neto/ mac80211/tx.c:2244 Módulos vinculados en: CPU: 0 PID: 10717 Comm: syz-executor.5 Not tainted 5.14.0-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01 /2011 RIP: 0010:ieee80211_rate_set_vht include/net/mac80211.h:989 [en línea] RIP: 0010:ieee80211_parse_tx_radiotap+0x101e/0x12d0 net/mac80211/tx.c:2244 RSP: 86f3e8 EFLAGS: 00010216 RAX: 0000000000000618 RBX: ffff88804ef76500 RCX: ffffc900143a5000 RDX: 0000000000040000 RSI: ffffffff888f478e RDI: 0000000000000003 RBP: 00000000ffffffff R08: 000 R09: 0000000000000100 R10: ffffffff888f46f9 R11: 0000000000000000 R12: 00000000ffffff8 R13: ffff88804ef7653c R14: 0000000000000001 R15: 0000000000000004 FS: 00007fbf5718f700(0000) GS:ffff8880b9c00000( 0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b2de23000 CR3: 000000006a671000 CR4: 000000000015 06f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffe0ff0 DR7: 0000000000000600 ieee80211_monitor_select_queue+0xa6 /0x250 net/mac80211/iface.c:740 netdev_core_pick_tx+0x169/0x2e0 net/core/dev.c:4089 __dev_queue_xmit+0x6f9/0x3710 net/core/dev.c:4165 __bpf_tx_skb net/core/filter.c:2114 [ en línea] __bpf_redirect_no_mac net/core/filter.c:2139 [en línea] __bpf_redirect+0x5ba/0xd20 net/core/filter.c:2162 ____bpf_clone_redirect net/core/filter.c:2429 [en línea] bpf_clone_redirect+0x2ae/0x420 net/core /filter.c:2401 bpf_prog_eeb6f53a69e5c6a2+0x59/0x234 bpf_dispatcher_nop_func include/linux/bpf.h:717 [en línea] __bpf_prog_run include/linux/filter.h:624 [en línea] bpf_prog_run include/linux/filter.h:631 [ en línea] bpf_test_run+0x381/0xa30 net/bpf/test_run.c:119 bpf_prog_test_run_skb+0xb84/0x1ee0 net/bpf/test_run.c:663 bpf_prog_test_run kernel/bpf/syscall.c:3307 [en línea] 5df0 núcleo/bpf/ syscall.c:4605 __do_sys_bpf kernel/bpf/syscall.c:4691 [en línea] __se_sys_bpf kernel/bpf/syscall.c:4689 [en línea] __x64_sys_bpf+0x75/0xb0 kernel/bpf/syscall.c:4689 4 arco/x86/ entrada/common.c:50 [en línea] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entrada_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x4665f9

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mac80211-hwsim: corrige el manejo tardío del hrtimer de baliza. Thomas explicó en https://lore.kernel.org/r/87mtoeb4hb.ffs@tglx que nuestro manejo del hrtimer aquí es incorrecto : Si el temporizador se activa tarde (por ejemplo, debido a la programación de vCPU, según lo informado por Dmitry/syzbot), entonces intenta rearmar el temporizador en la próxima fecha límite, que podría haber sido ya en el pasado: 1 2 3 N N+1 | | | ... | | ^ intención de disparar aquí (1) ^ próxima fecha límite aquí (2) ^ realmente disparado aquí La próxima vez que se active, será más tarde, pero aún así intentará programar la próxima fecha límite (ahora 3), etc. hasta que se ponga al día N, pero eso podría llevar mucho tiempo, causando bloqueos, etc. Ahora, todo esto es simulación, así que solo tenemos que arreglarlo, pero tenga en cuenta que el comportamiento es incorrecto incluso según la especificación, ya que no tiene ningún valor enviar todos esos balizas no alineadas: deben estar alineadas con el TBTT (1, 2, 3, ... en la imagen), y si llegamos un poco (o mucho) tarde, simplemente reanudemos en ese punto. Por lo tanto, cambie el código para usar hrtimer_forward_now(), lo que garantizará que el siguiente disparo del temporizador sea en N+1 (en la imagen), es decir, el siguiente punto del intervalo después de la hora actual.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nexthop: corrige pérdidas de memoria en los oyentes de la cadena de notificaciones de nexthop syzkaller descubrió pérdidas de memoria [1] que se pueden reducir a los siguientes comandos: # ip nexthop add id 1 blackhole # devlink dev reload pci /0000:06:00.0 Como parte del flujo de recarga, mlxsw cancelará el registro de sus netdevs y luego cancelará el registro de la cadena de notificación de nexthop. Antes de cancelar el registro de la cadena de notificaciones, mlxsw recibirá notificaciones de eliminación de objetos de nexthop utilizando netdevs registrados por mlxsw o sus superiores. mlxsw no recibirá notificaciones de nexthops que utilicen netdevs que no estén desmantelados como parte del flujo de recarga. Por ejemplo, el blackhole nexthop anterior que utiliza internamente el loopback netdev como su dispositivo nexthop. Una forma de solucionar este problema es hacer que los oyentes vacíen sus tablas de nexthop después de darse de baja de la cadena de notificaciones. Esto es propenso a errores, como lo demuestra este parche, y tampoco es simétrico con la ruta de registro donde un oyente recibe un volcado de todos los nexthops existentes. Por lo tanto, solucione este problema reproduciendo las notificaciones de eliminación del oyente que se está cancelando el registro. Esto es simétrico a la ruta de registro y también consistente con la cadena de notificación de netdev. Lo anterior significa que unregister_nexthop_notifier(), al igual que Register_nexthop_notifier(), tendrá que tomar RTNL para poder iterar sobre los nexthops existentes y que cualquier persona que llame a la función no puede mantener RTNL. Esto es cierto para mlxsw y netdevsim, pero no para el controlador VXLAN. Para evitar un punto muerto, cambie este último para cancelar el registro de su oyente nexthop sin mantener presionado RTNL, haciéndolo simétrico a la ruta de registro. [1] objeto sin referencia 0xffff88806173d600 (tamaño 512): comm "syz-executor.0", pid 1290, jiffies 4295583142 (edad 143.507s) volcado hexadecimal (primeros 32 bytes): 41 9d 1e 60 80 88 ff ff 08 d6 73 1 80 88 ff ff A..`......sa.... 08 d6 73 61 80 88 ff ff 01 00 00 00 00 00 00 00 ..sa............ backtrace: [] kmemleak_alloc_recursive include/linux/kmemleak.h:43 [en línea] [] slab_post_alloc_hook+0x96/0x490 mm/slab.h:522 [] mm/slub.c:3206 [en línea] [] slab_alloc mm/slub.c:3214 [en línea] [] kmem_cache_alloc_trace+0x163/0x370 mm/slub.c:3231 [] kmalloc include/linux/slab.h: 591 [en línea] [] kzalloc include/linux/slab.h:721 [en línea] [] mlxsw_sp_nexthop_obj_group_create drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:4918 [ ] mlxsw_sp_nexthop_obj_new drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:5054 [en línea] [] mlxsw_sp_nexthop_obj_event+0x59a/0x2910 drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:523 9 [] notifier_call_chain+0xbd/0x210 kernel/notifier.c:83 [] blocking_notifier_call_chain kernel/notifier.c:318 [en línea] [] blocking_notifier_call_chain+0x72/0xa0 kernel/notifier.c:306 [] call_nexthop_notifiers+0x156/0x310 net/ipv4/nexthop.c:244 [] insert_nexthop net/ipv4/nexthop.c:2336 [en línea] [] nexthop_add net/ipv4/nexthop.c:2644 [en línea] [] rtm_new_nexthop+0x14e8/0x4d10 net/ipv4/nexthop.c:2913 [] rtnetlink_rcv_msg+0x448/0xbf0 net/core/rtnetlink.c:5572 [ ] netlink_rcv_skb+0x173/0x480 neto/ netlink/af_netlink.c: 2504 [] rtnetlink_rcv+0x22/0x30 net/core/rtnetlink.c: 5590 [] netlink_unicast_kernel net/netlink/af_fffffff.c: 1314 [faff. 6069de>] netlink_unicast +0x5ae/0x7f0 net/netlink/af_netlink.c:1340 [] --- truncado--

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: macb: corrige el use after free en rmmod plat_dev->dev->platform_data es publicado por platform_device_unregister(), el uso de pclk y hclk es un use after free. Dado que la cancelación del registro del dispositivo no necesitará un dispositivo clk, ajustamos la secuencia de llamada a la función para solucionar este problema. [31.261225] ERROR: KASAN: use after free en macb_remove+0x77/0xc6 [macb_pci] [31.275563] Liberado por la tarea 306: [30.276782] platform_device_release+0x25/0x80

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: irqchip/gic-v3-its: soluciona una posible fuga de VPE en caso de error. En its_vpe_irq_domain_alloc, cuando its_vpe_init() devuelve un error, hay un error de uno en uno en el número de VPE. para ser liberado. Solucionelo simplemente pasando el número de VPE asignados, que es el índice del bucle que se itera sobre los VPE. [maz: mensaje de confirmación fijo]

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: dma-debug: evita que un mensaje de error cause problemas de tiempo de ejecución Para algunos controladores, que utilizan la API DMA. Este mensaje de error puede aparecer varios millones de veces por segundo, provocando spam en el búfer printk del kernel y elevando el uso de la CPU hasta el 100% (por lo tanto, debería tener una velocidad limitada). Sin embargo, dado que hay al menos un controlador que está en la línea principal y sufre la condición de error, es más útil err_printk() aquí en lugar de simplemente limitar el valor del mensaje de error (con la esperanza de que así sea más fácil para otros controladores). que sufren este problema para ser detectados).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: blktrace: corrige uaf en el acceso a blk_trace después de eliminarlo mediante sysfs. Hay un problema de use after free desencadenado por el siguiente proceso: P1(sda) P2(sdb) echo 0 > /sys /block/sdb/trace/enable blk_trace_remove_queue sincronizar_rcu blk_trace_free relé_cerrar rcu_read_lock __blk_add_trace trace_note_tsk (Iterar running_trace_list) relé_close_buf relé_destroy_buf kfree(buf) trace_note(sdb's bt) relé_reserve buf->offset <- deferencia nullptr (uso-después) -gratis) !!! rcu_read_unlock [502.714379] ERROR: desreferencia del puntero NULL del kernel, dirección: 0000000000000010 [502.715260] #PF: acceso de lectura de supervisor en modo kernel [502.715903] #PF: error_code(0x0000) - página no presente [502.716546] PGD 103984067 P4D 103984067 PUD 17592b067 PMD 0 [ 502.717252] Vaya: 0000 [#1] SMP [ 502.720308] RIP: 0010:trace_note.isra.0+0x86/0x360 [ 502.732872] Seguimiento de llamadas: [ 502.733193] 0x1a3 [502.733734] blk_add_trace_rq+ 0x7b/0xd0 [ 502.734207] blk_add_trace_rq_issue+0x54/0xa0 [ 502.734755] blk_mq_start_request+0xde/0x1b0 [ 502.735287] scsi_queue_rq+0x528/0x1140 ... [ 502.7427 04] sg_new_write.isra.0+0x16e/0x3e0 [ 502.747501] sg_ioctl+0x466/0x1100 Método de reproducción: ioctl(/dev/sda, BLKTRACESETUP, blk_user_trace_setup[buf_size=127]) ioctl(/dev/sda, BLKTRACESTART) ioctl(/dev/sdb, BLKTRACESETUP, blk_user_trace_setup[buf_size=127]) ioctl(/dev/sdb , BLKTRACESTART) echo 0 > /sys/block/sdb/trace/enable & // Agrega retraso(mdelay/msleep) antes de que el kernel entre blk_trace_free() ioctl$SG_IO(/dev/sda, SG_IO, ...) // Entra trace_note_tsk() después de que blk_trace_free() regresara // Utilice mdelay en la región rcu en lugar de msleep (que puede programarse) Elimine blk_trace de running_list antes de llamar a blk_trace_free() mediante sysfs si blk_trace está en el estado Blktrace_running.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Agregar verificación de tamaño excesivo antes de llamar a kvcalloc() Confirmación 7661809d493b ("mm: no permitir llamadas a kvmalloc() de gran tamaño") agregar la verificación de tamaño excesivo. Cuando la asignación es mayor que lo que admite kmalloc(), se activa la siguiente advertencia: ADVERTENCIA: CPU: 0 PID: 8408 en mm/util.c:597 kvmalloc_node+0x108/0x110 mm/util.c:597 Módulos vinculados en: CPU : 0 PID: 8408 Comm: syz-executor221 No contaminado 5.14.0-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:kvmalloc_node+0x108/0x110 mm/util .c:597 Seguimiento de llamadas: kvmalloc include/linux/mm.h:806 [en línea] kvmalloc_array include/linux/mm.h:824 [en línea] kvcalloc include/linux/mm.h:829 [en línea] check_btf_line kernel/bpf /verifier.c:9925 [en línea] check_btf_info kernel/bpf/verifier.c:10049 [en línea] bpf_check+0xd634/0x150d0 kernel/bpf/verifier.c:13759 bpf_prog_load kernel/bpf/syscall.c:2301 [en línea] __sys_bpf +0x11181/0x126e0 kernel/bpf/syscall.c:4587 __do_sys_bpf kernel/bpf/syscall.c:4691 [en línea] __se_sys_bpf kernel/bpf/syscall.c:4689 [en línea] __x64_sys_bpf+0x78/0x90 pf/syscall.c:4689 do_syscall_x64 arch/x86/entry/common.c:50 [en línea] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 Entry_SYSCALL_64_after_hwframe+0x44/0xae

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xen/balloon: utiliza un subproceso del kernel en lugar de una cola de trabajo. Hoy en día, la expansión de Xen se realiza mediante trabajo retrasado en una cola de trabajo. Esto podría provocar que se informen bloqueos de la cola de trabajo en caso de que se aumenten grandes cantidades de memoria de una vez (aquí 16 GB): BUG: bloqueo de la cola de trabajo - pool cpus=6 node=0 flags=0x0 nice=0 bloqueado durante 64 segundos. Mostrando colas de trabajo ocupadas y grupos de trabajadores: eventos de cola de trabajo: flags=0x0 pwq 12: cpus=6 node=0 flags=0x0 nice=0 active=2/256 refcnt=3 en vuelo: 229:balloon_process pendiente: cache_reap workqueue events_freezable_power_: flags =0x84 pwq 12: cpus=6 nodo=0 banderas=0x0 agradable=0 activo=1/256 refcnt=2 pendiente: disk_events_workfn cola de trabajo mm_percpu_wq: banderas=0x8 pwq 12: cpus=6 nodo=0 banderas=0x0 agradable=0 activo =1/256 refcnt=2 pendiente: vmstat_update pool 12: cpus=6 nodo=0 banderas=0x0 agradable=0 colgado=64s trabajadores=3 inactivo: 2222 43 Esto se puede evitar fácilmente usando un subproceso del kernel dedicado para realizar la expansión trabajar.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nvme-rdma: destruye cm id antes de destruir qp para evitar su use after free. Siempre debemos destruir cm_id antes de destruir qp para evitar que se produzca un evento cma después de que se destruya qp, lo que puede llevar a use after free. En el flujo de error de establecimiento de conexión RDMA, no destruya qp en el controlador de eventos cm. Simplemente informe cm_error al nivel superior, qp se destruirá en nvme_rdma_alloc_queue() después de destruir cm id.