Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bpf: corrige la fuga de la dirección del kernel en la recuperación atómica. El cambio en el commit 37086bfdc737 ("bpf: propaga los límites de la pila a los registros en atómicos con BPF_FETCH") alrededor del manejo de check_mem_access() tiene errores ya que esto permitiría a usuarios sin privilegios filtrar punteros del kernel. Por ejemplo, una recuperación atómica/y con -1 en un destino de pila que contiene un puntero derramado migrará el tipo de registro derramado a un escalar, que luego se puede exportar fuera del programa (ya que escalar! = puntero) volcándolo en un valor de mapa. La implementación original de XADD evitaba esta situación mediante el uso de una llamada doble a check_mem_access(), una con BPF_READ y otra posterior con BPF_WRITE, en ambos casos pasando -1 como valor de marcador de posición en lugar de registrarse según la semántica de XADD, ya que no lo hacía contener una recuperación de valor. BPF_READ también incluyó una verificación en check_stack_read_fixed_off() que rechaza el programa si la ranura de la pila es de __is_pointer_value() si dst_regno < 0. Esto último es para distinguir si estamos tratando con un derrame/llenado de pila regular o alguna operación aritmética que no está permitido en valores no escalares, consulte también 6e7e63cbb023 ("bpf: Prohibir XADD en punteros dispersos para usuarios sin privilegios") para obtener más contexto sobre check_mem_access() y su manejo del valor del marcador de posición -1. Una opción mínimamente intrusiva para solucionar la fuga es que el caso BPF_FETCH verifique inicialmente el caso BPF_READ mediante check_mem_access() con -1 como registro, seguido del caso de carga real con load_reg no negativo para propagar los límites de la pila a los registros.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: firmware: arm_scpi: corrige el desbordamiento de cadena en el controlador SCPI genpd. Sin las comprobaciones vinculadas para scpi_pd->name, podría provocar un desbordamiento del búfer al copiar el nombre del dispositivo SCPI del dispositivo correspondiente. El nodo del árbol como cadena de nombre se establece en un tamaño máximo de 30. Arreglemoslo usando devm_kasprintf para que el búfer de cadena se asigne dinámicamente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/msm: corrige el acceso ptr nulo msm_ioctl_gem_submit() Corrige la siguiente desreferencia del puntero nulo en msm_ioctl_gem_submit(): 26545.260705: Rastreo de llamadas: 26545.263223: kref_put+0x1c/0x60 26545.266452 msm: _ioctl_gem_submit+ 0x254/0x744 26545.270937: drm_ioctl_kernel+0xa8/0x124 26545.274976: drm_ioctl+0x21c/0x33c 26545.278478: drm_compat_ioctl+0xdc/0xf0 : __arm64_compat_sys_ioctl+0xc8/0x100 26545.287169: el0_svc_common+0xf8/0x250 26545.291025: do_el0_svc_compat+0x28/0x54 26545.295066: 0 /0x1c 26545.298838: el0_sync_compat_handler+0xa8/0xcc 26545.303403: el0_sync_compat+0x188/0x1c0 26545.307445: Código: d503201f d503201f 52800028 4b0803e8 680008) 26545.318799: Pánico del kernel: no se sincroniza: Ups: excepción fatal

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mac80211: validar que el ID del elemento extendido esté presente Antes de intentar analizar un elemento extendido, verifique que el ID del elemento extendido esté presente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfc: corrige el error de segmentación en nfc_genl_dump_devices_done Cuando falla kmalloc en nfc_genl_dump_devices(), entonces el error de segmentación de nfc_genl_dump_devices_done() se muestra a continuación KASAN: null-ptr-deref en el rango [0x0000000000000008-0x00 0000000000000f] CPU: 0 PID : 25 Comm: kworker/0:1 Not tainted 5.16.0-rc4-01180-g2a987e65025e-dirty #5 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.14.0-6.fc35 04/01/ 2014 Cola de trabajo: eventos netlink_sock_destruct_work RIP: 0010:klist_iter_exit+0x26/0x80 Seguimiento de llamadas: class_dev_iter_exit+0x15/0x20 nfc_genl_dump_devices_done+0x3b/0x50 genl_lock_done+0x84/0xd0 estructura+0x8f/0x270 __sk_destruct+0x64/0x3b0 sk_destruct+0xa8/0xd0 __sk_free+0x2e8/0x3d0 sk_free+0x51/0x90 netlink_sock_destruct_work+0x1c/0x20 Process_one_work+0x411/0x710 trabajador_thread+0x6fd/0xa80

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: i2c: virtio: manejo de finalización de reparación El controlador actualmente supone que la devolución de llamada de notificación solo se recibe cuando el dispositivo termina con todos los búferes en cola. Sin embargo, esto no es cierto, ya que la devolución de llamada de notificación podría llamarse sin que se complete ninguno de los búferes en cola (por ejemplo, con virtio-pci e interrupciones compartidas) o con solo algunos de los búferes completados (ya que el controlador los pone a disposición). al dispositivo en múltiples llamadas virtqueue_add_sgs() separadas). Esto puede provocar datos incorrectos en el bus I2C o daños en la memoria del huésped si el dispositivo funciona con búferes que han sido liberados por el controlador. (El WARN_ON en el controlador también se activa). ERROR kmalloc-128 (Contaminado: GW): Veneno sobrescrito Primer byte 0x0 en lugar de 0x6b Asignado en i2cdev_ioctl_rdwr+0x9d/0x1de age=243 cpu=0 pid=28 memdup_user+0x2e/0xbd i2cdev_ioctl_rdwr+0x9d/0x1de i2cdev_ioctl+0x247/0x2ed vfs_ioctl+0x21/0x30 sys_ioctl+0xb18/0xb41 Liberado en i2cdev_ioctl_rdwr+0x1bb/0x1de age=68 cpu=0 pid=28 0x1cc i2cdev_ioctl_rdwr+0x1bb/0x1de i2cdev_ioctl+0x247/ 0x2ed vfs_ioctl+0x21/0x30 sys_ioctl+0xb18/0xb41 Solucione este problema llamando a virtio_get_buf() desde el controlador de notificación como otros controladores virtio y esperando a que se completen todos los búferes.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: RDMA/irdma: corrige un user-after-free en add_pble_prm Cuando falla irdma_hmc_sd_one, el 'fragmento' se libera mientras todavía está en la lista de información de PBLE. Agregue la entrada del fragmento a la lista de información de PBLE solo después de configurar correctamente la SD en irdma_hmc_sd_one.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net/sched: sch_ets: no elimine las clases inactivas de la lista de turnos Shuang informó que el siguiente script: 1) tc qdisc add dev ddd0 handle 10: parent 1: ets bandas 8 estricto 4 priomap 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 2) mausezahn ddd0 -A 10.10.10.1 -B 10.10.10.2 -c 0 -a propio -b 00:c1:a0: c1:a0:00 -t udp & 3) tc qdisc change dev ddd0 handle 10: ets bands 4 estricto 2 cuantos 2500 2500 priomap 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 falla sistemáticamente cuando la línea 2) se comenta: corrupción list_del, ffff8e028404bd30->el siguiente es LIST_POISON1 (dead000000000100) ------------[ cortar aquí ]------------ ERROR del kernel en lib/list_debug. c:47! código de operación no válido: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 954 Comunicaciones: tc Not tainted 5.16.0-rc4+ #478 Nombre de hardware: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066 +0f1aadab 01/04/2014 RIP: 0010:__list_del_entry_valid.cold.1+0x12/0x47 Código: fe ff 0f 0b 48 89 c1 4c 89 c6 48 c7 c7 08 42 1b 87 e8 1d c5 fe ff 0f 0b 48 89 fe 4 8 89 c2 48 c7 c7 98 42 1b 87 e8 09 c5 fe ff <0f> 0b 48 c7 c7 48 43 1b 87 e8 fb c4 fe ff 0f 0b 48 89 f2 48 89 fe RSP: 0018:ffffae46807a3888 EFLAGS: 246 RAX: 000000000000004eRBX : 0000000000000007 RCX: 0000000000000202 RDX: 0000000000000000 RSI: ffffffff871ac536 RDI: 00000000ffffffff RBP: ffffae46807a3a10 R08: 00000000000 00000 R09: c0000000ffff7fff R10: 00000000000000001 R11: ffffae46807a36a8 R12: ffff8e028404b800 R13: ffff8e028404bd30 R14: dead000000000100 R15: e02fafa2400 FS: 00007efdc92e4480(0000) GS:ffff8e02fb600000 (0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000682f48 CR3: 00000001058be000 CR4: 000000000035 0ef0 Seguimiento de llamadas: ets_qdisc_change+0x58b/0xa70 [sch_ets] tc_modify_qdisc+0x323/0x880 rtnetlink_rcv_msg+0x169/ 0x4a0 netlink_rcv_skb+0x50/0x100 netlink_unicast+0x1a5/0x280 netlink_sendmsg+0x257/0x4d0 sock_sendmsg+0x5b/0x60 ____sys_sendmsg+0x1f2/0x260 ___sys_sendmsg+0x7c/0xc0 __sys_sendmsg+0x57/0xa0 do_syscall_64+0x3a/0x80 Entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033: 0x7efdc8031338 Código: 89 02 48 c7 c0 ff ff ff ff eb b5 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 8d 05 25 43 2c 00 8b 00 85 c0 75 17 b8 2e 00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 41 54 41 89 d4 55 RSP: 002b:00007ffdf1ce9828 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: de RBX: 0000000061b37a97 RCX: 00007efdc8031338 RDX: 0000000000000000 RSI: 00007ffdf1ce9890 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000001 R09: 000000000078a940 R10: 000000000000000c R11: 00000000000000246 R12: 0000000000000001 R 13: 0000000000688880 R14: 0000000000000000 R15: 0000000000000000 Módulos vinculados en: sch_ets sch_tbf dummy rfkill iTCO_wdt iTCO_vendor_support intel_rapl_msr intel_rapl_common pcs pkr i2c_i801 virtio_balloon i2c_smbus lpc_ich ip_tables xfs libcrc32c crct10dif_pclmul crc32_pclmul crc32c_intel serio_raw ghash_clmulni_intel ahci libahci libata virtio_blk virtio_console virtio_net net_failover failover sunrpc dm_mirror dm_region_hash dm_log dm_mod [última descarga: sch_ets] ---[ fin de seguimiento f35878d191 2655c2 ]--- RIP: 0010:__list_del_entry_valid.cold.1+0x12/0x47 Código: fe ff 0f 0b 48 89 c1 4c 89 c6 48 c7 c7 08 42 1b 87 e8 1d c5 fe ff 0f 0b 48 89 fe 48 89 c2 48 c7 c7 98 42 1b 87 e8 09 c5 fe ff <0f> 0b 48 c7 c7 48 43 1b 87 e8 fb c4 fe ff 0f 0b 48 89 f2 48 89 fe RSP: 0018:ffffae46807a3888 EFLAGS: 00010246 RAX: 000000000000004e RBX: 0000000000000007 RCX 000 0000000000202 RDX: 0000000000000000 RSI: ffffffff871ac536 RDI: 00000000ffffffff RBP: ffffae46807a3a10 R08: 0000000000000000 R09: c0000000ffff7fff R10: 0000000000000001 R11: FFFFFAE46807A36A8 R12: FFFFF8E028404B800 R13: FFFF8E028404BD30 R14: Dead000000000100 R15: FFFFF8E02FAFA2400 FUT: GS: FFFF8E02FB600000 (0000) KNLGS: 000000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000 - --truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: hns3: corrige el error de use-after-free en hclgevf_send_mbx_msg Actualmente, la función hns3_remove desinstala primero la instancia del cliente y luego desinstala el dispositivo del motor de aceleración. El dispositivo de red se libera en el proceso de desinstalación de la instancia del cliente, pero el proceso de desinstalación del dispositivo del motor de aceleración aún lo utiliza para rastrear la información del tiempo de ejecución. Esto provoca un problema de use-after-free. Entonces lo soluciona verificando el estado del registro de la instancia para evitar use after free.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: inet_diag: corrige la fuga de información del kernel para sockets UDP KMSAN informó una fuga de información del kernel [1], que puede ser explotada por usuarios sin privilegios. Después del análisis resultó que UDP no estaba inicializando r->idiag_expires. Otros usuarios de inet_sk_diag_fill() podrían cometer el mismo error en el futuro, así que solucione este problema en inet_sk_diag_fill(). [1] ERROR: KMSAN: kernel-infoleak en instrument_copy_to_user include/linux/instrumented.h:121 [en línea] ERROR: KMSAN: kernel-infoleak en copia lib/iov_iter.c:156 [en línea] ERROR: KMSAN: kernel-infoleak en _copy_to_iter+0x69d/0x25c0 lib/iov_iter.c:670 instrument_copy_to_user include/linux/instrumented.h:121 [en línea] copia lib/iov_iter.c:156 [en línea] _copy_to_iter+0x69d/0x25c0 lib/iov_iter.c:670 copy_to_iter include/linux/uio.h:155 [en línea] simple_copy_to_iter+0xf3/0x140 net/core/datagram.c:519 __skb_datagram_iter+0x2cb/0x1280 net/core/datagram.c:425 skb_copy_datagram_iter+0xdc/0x270 net/core/datagram .c:533 skb_copy_datagram_msg include/linux/skbuff.h:3657 [en línea] netlink_recvmsg+0x660/0x1c60 net/netlink/af_netlink.c:1974 sock_recvmsg_nosec net/socket.c:944 [en línea] sock_recvmsg net/socket.c:962 [en línea] sock_read_iter+0x5a9/0x630 net/socket.c:1035 call_read_iter include/linux/fs.h:2156 [en línea] new_sync_read fs/read_write.c:400 [en línea] vfs_read+0x1631/0x1980 fs/read_write.c: 481 ksys_read+0x28c/0x520 fs/read_write.c:619 __do_sys_read fs/read_write.c:629 [en línea] __se_sys_read fs/read_write.c:627 [en línea] __x64_sys_read+0xdb/0x120 fs/read_write.c:627 _arco x64/ x86/entry/common.c:51 [en línea] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 Entry_SYSCALL_64_after_hwframe+0x44/0xae Uninit se creó en: slab_post_alloc_hook mm/slab.h:524 [en línea] slab_alloc_node mm/slub.c:3251 [en línea] __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4974 kmalloc_reserve net/core/skbuff.c:354 [en línea] __alloc_skb+0x545/0xf90 net/core/skbuff.c:426 alloc_skb include/linux/skbuff.h:1126 [en línea] netlink_dump+0x3d5/0x16a0 net/netlink/af_netlink.c:2245 __netlink_dump_start+0xd1c/0xee0 net/netlink/af_netlink.c:2370 netlink_dump_start include/linux/netlink.h:254 [en línea] inet_diag_handler_cmd+0x2e7/0x400 net/ipv4/inet_diag.c:1343 sock_diag_rcv_msg+0x24a/0x620 netlink_rcv_skb+0x447/0x800 net/netlink/af_netlink.c:2491 sock_diag_rcv+0x63/0x80 net/core/sock_diag.c:276 netlink_unicast_kernel net/netlink/af_netlink.c: 1319 [en línea] netlink_unicast+0x1095/0x1360 netLink/af_netlink.c: 1345 netlink_sendmsg+0x16f3/0x1870 net/netlink/af_etlink.c: 1916 sockm. C: 704 [ en línea] sock_sendmsg net/socket.c:724 [en línea] sock_write_iter+0x594/0x690 net/socket.c:1057 do_iter_readv_writev+0xa7f/0xc70 do_iter_write+0x52c/0x1500 fs/read_write.c:851 vfs_writev fs/read_write.c:9 24 [en línea] do_writev+0x63f/0xe30 fs/read_write.c:967 __do_sys_writev fs/read_write.c:1040 [en línea] __se_sys_writev fs/read_write.c:1037 [en línea] __x64_sys_writev+0xe5/0x120 fs/read_write.c:1037 _syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 Entry_SYSCALL_64_after_hwframe+0x44/0xae Los bytes 68-71 de 312 no están inicializados El acceso a la memoria de tamaño 312 comienza en ffff88812ab54000 Datos copiados a la dirección de usuario 0000000020001440 CPU: 1 PID: 6365 Comm: syz-executor801 Not tainted 5.16.0-rc3-syzkaller #0 Nombre de hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sch_cake: no llamar a cake_destroy() desde cake_init() Se supone que las qdiscs no deben llamar a su propio método destroy() desde init(), porque la pila central ya lo hace. syzbot pudo activar el use-after-free: DEBUG_LOCKS_WARN_ON(lock->magic != lock) ADVERTENCIA: CPU: 0 PID: 21902 en kernel/locking/mutex.c:586 __mutex_lock_common kernel/locking/mutex.c:586 [en línea] ADVERTENCIA: CPU: 0 PID: 21902 en kernel/locking/mutex.c:586 __mutex_lock+0x9ec/0x12f0 kernel/locking/mutex.c:740 Módulos vinculados en: CPU: 0 PID: 21902 Comm: syz-executor189 No contaminado 5.16 .0-rc4-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__mutex_lock_common kernel/locking/mutex.c:586 [en línea] RIP: 0010:__mutex_lock+ 0x9ec/0x12f0 kernel/locking/mutex.c:740 Código: 08 84 d2 0f 85 19 08 00 00 8b 05 97 38 4b 04 85 c0 0f 85 27 f7 ff ff 48 c7 c6 20 00 ac 89 48 c7 c7 a0 fe ab 89 e8 bf 76 ba ff <0f> 0b e9 0d f7 ff ff 48 8b 44 24 40 48 8d b8 c8 08 00 00 48 89 f8 RSP: 0018:ffffc9000627f290 EFLAGS: 00010282 RAX: 0000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: ffff88802315d700 RSI: ffffffff815f1db8 RDI: fffff52000c4fe44 RBP: ffff88818f28e000 R08: 0000000000000000 R09: 0000000000000000 R10: ffffffff815ebb5e R11: 00000 R12: 0000000000000000 R13: dffffc0000000000 R14: ffffc9000627f458 R15: 0000000093c30000 FS: 000055556abc400(0000) GS:ffff8880b9c0000 0(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fda689c3303 CR3: 000000001cfbb000 CR4: 0000000000350ef0 Seguimiento de llamadas: tcf_chain0_head_change_cb_del+0x2e/0 x3d0 net/sched/cls_api.c:810 tcf_block_put_ext net/sched/cls_api.c:1381 [ en línea] tcf_block_put_ext net/sched/cls_api.c:1376 [en línea] tcf_block_put+0xbc/0x130 net/sched/cls_api.c:1394 cake_destroy+0x3f/0x80 net/sched/sch_cake.c:2695 qdisc_create.constprop.0+0x9da /0x10f0 net/sched/sch_api.c:1293 tc_modify_qdisc+0x4c5/0x1980 net/sched/sch_api.c:1660 rtnetlink_rcv_msg+0x413/0xb80 net/core/rtnetlink.c:5571 netlink_rcv_skb+0x153/0x420 net/netlink/ af_netlink. c:2496 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [en línea] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1345 netlink_sendmsg+0x904/0xdf0 net/netlink/af_netlink.c:1921 sock_sendmsg_nosec net/socket.c :704 [en línea] sock_sendmsg+0xcf/0x120 net/socket.c:724 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2409 ___sys_sendmsg+0xf3/0x170 net/socket.c:2463 __sys_sendmsg+0xe5/0x1b 0 red/toma. c:2492 do_syscall_x64 arch/x86/entry/common.c:50 [en línea] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 Entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f1bb06badb9 Código: No se puede acceder al código de operación bytes en RIP 0x7f1bb06bad8f. RSP: 002b:00007fff3012a658 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00000000000000003 RCX: 00007f1bb06badb9 RDX: 000000000 RSI: 00000000200007c0 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000003 R09: 0000000000000003 R10: 00000003 R11: 0000000000000246 R12: 00007fff3012a688 R13: 00007fff3012a6a0 R14: 00007fff3012a6e0 R15: 00000000000013c2

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: utilice Latest_dev en btrfs_show_devname El caso de prueba btrfs/238 informa la siguiente advertencia: ADVERTENCIA: CPU: 3 PID: 481 en fs/btrfs/super.c:2509 btrfs_show_devname+0x104 /0x1e8 [btrfs] CPU: 2 PID: 1 Comunicación: systemd Contaminado: GWO 5.14.0-rc1-custom #72 Nombre de hardware: QEMU Máquina virtual QEMU, BIOS 0.0.0 06/02/2015 Rastreo de llamadas: btrfs_show_devname+0x108/ 0x1b4 [btrfs] show_mountinfo+0x234/0x2c4 m_show+0x28/0x34 seq_read_iter+0x12c/0x3c4 vfs_read+0x29c/0x2c8 ksys_read+0x80/0xec __arm64_sys_read+0x28/0x34 x50/0xf8 do_el0_svc+0x88/0x138 el0_svc+0x2c/0x8c el0t_64_sync_handler +0x84/0xe4 el0t_64_sync+0x198/0x19c Motivo: mientras btrfs_prepare_sprout() mueve fs_devices::devices a fs_devices::seed_list, btrfs_show_devname() busca los dispositivos y no encuentra ninguno, lo que genera la advertencia como se muestra arriba. Solución: last_dev se actualiza según los cambios en la lista de dispositivos. Eso significa que podríamos usar el último_dev->name para mostrar el nombre del dispositivo en /proc/self/mounts, el puntero siempre será válido tal como está asignado antes de que el dispositivo se elimine de la lista en eliminar o reemplazar. La protección de la RCU es suficiente, ya que la estructura del dispositivo se libera después de la sincronización.