Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: l2tp: pasa la longitud correcta del mensaje a ip6_append_data l2tp_ip6_sendmsg necesita evitar tener en cuenta el encabezado de transporte dos veces al unir más datos en un skbuff ya parcialmente ocupado. Para gestionar esto, verificamos si skbuff contiene datos usando skb_queue_empty al decidir cuántos datos agregar usando ip6_append_data. Sin embargo, el código que realizó el cálculo era incorrecto: ulen = len + skb_queue_empty(&sk->sk_write_queue)? transhdrlen : 0; ...debido a la precedencia del operador C, esto termina configurando ulen en transhdrlen para mensajes con una longitud distinta de cero, lo que resulta en paquetes corruptos en el cable. Agregue paréntesis para corregir el cálculo de acuerdo con la intención original.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ARM: ep93xx: Agregar terminador a gpiod_lookup_table Sin el terminador, si se pasa un con_id a gpio_find() que no existe en la tabla de búsqueda, la función no dejará de repetirse correctamente y eventualmente causará un oops

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/qedr: corrija el flujo de error qedr_create_user_qp Evite la siguiente advertencia asegurándose de liberar los recursos asignados en caso de que qedr_init_user_queue() falle. -----------[ cortar aquí ]----------- ADVERTENCIA: CPU: 0 PID: 143192 en drivers/infiniband/core/rdma_core.c:874 uverbs_destroy_ufile_hw+0xcf/ 0xf0 [ib_uverbs] Módulos vinculados en: tls target_core_user uio target_core_pscsi target_core_file target_core_iblock ib_srpt ib_srp scsi_transport_srp nfsd nfs_acl rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd Grace fscache netfs 8 021q garp mrp stp llc ext4 mbcache jbd2 opa_vnic ib_umad ib_ipoib sunrpc rdma_ucm ib_isert iscsi_target_mod target_core_mod ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm hfi1 intel_rapl_msr intel_rapl_common mgag200 qedr sb_edac drm_shmem_helper rdmavt x86_pkg_temp_thermal drm_kms_helper intel_powerclamp ib_uverbs coretemp i2c_algo_bit kvm_intel dell_wmi_descriptor ipmi_ssif sparse_keymap kvm ib_core rfkill syscopyarea sysfillrect video sysimgblt irqbypass ipmi_si ipmi_devintf fb_sys_fops rapl iTCO_wdt mxm_wmi iTCO_vendor_support intel_cstate pcspkr dcdbas intel_uncore ipmi_msghandler lpc_ich acpi_power_meter mei_me mei fusible drm xfs libcrc32c qede sd_mod ahci libahci t10_pi sg crct10dif_pclmul crc32_pclmul crc32c_intel qed libata tg3 ghash_clmulni_intel megaraid_sas crc8 wmi [última descarga: ib_srpt] CPU: 0 PID: 143192 Comm: fi_rdm_tagged_p Kdump: cargado No contaminado 5.14.0-408.el 9.x86_64 #1 Nombre del hardware: Dell Inc. PowerEdge R430/03XKDV, BIOS 2.14.0 25/01/2022 RIP: 0010:uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs] Código: 5d 41 5c 41 5d 41 5e e9 0f 26 1b dd 48 89 df e8 67 6a ff ff 49 8b 86 10 01 00 00 48 85 c0 74 9c 4c 89 e7 e8 83 c0 cb dd eb 92 <0f> 0b eb be 0f 0b be 04 00 00 00 48 89 df e8 8e f5 ff ff e9 6d ff RSP: 0018:ffffb7c6cadfbc 60 EF BANDERAS: 00010286 RAX: ffff8f0889ee3f60 RBX: ffff8f088c1a5200 RCX: 00000000802a0016 RDX: 00000000802a0017 RSI: 00000000000000001 RDI: ffff8f0880042600 RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000 R10: ffff8f11fffd5000 R11: 00000000000039000 R12: ffff8f0d5b36cd80 R13: ff ff8f088c1a5250 R14: ffff8f1206d91000 R15: 0000000000000000 FS: 00000000000000000( 0000) GS:ffff8f11d7c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000147069200e20 CR3: 00000001c7 210002 CR4: 00000000001706f0 Seguimiento de llamadas: ? show_trace_log_lvl+0x1c4/0x2df? show_trace_log_lvl+0x1c4/0x2df? ib_uverbs_close+0x1f/0xb0 [ib_uverbs] ? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs] ? __advertir+0x81/0x110 ? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs] ? report_bug+0x10a/0x140? handle_bug+0x3c/0x70? exc_invalid_op+0x14/0x70? asm_exc_invalid_op+0x16/0x20? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs] ib_uverbs_close+0x1f/0xb0 [ib_uverbs] __fput+0x94/0x250 task_work_run+0x5c/0x90 do_exit+0x270/0x4a0 do_group_exit+0x2d/0x90 get_signal+0x8 7c/0x8c0 arch_do_signal_or_restart+0x25/0x100 ? ib_uverbs_ioctl+0xc2/0x110 [ib_uverbs] exit_to_user_mode_loop+0x9c/0x130 exit_to_user_mode_prepare+0xb6/0x100 syscall_exit_to_user_mode+0x12/0x40 do_syscall_64+0x69/0x90 ? syscall_exit_work+0x103/0x130? syscall_exit_to_user_mode+0x22/0x40? do_syscall_64+0x69/0x90? syscall_exit_work+0x103/0x130? syscall_exit_to_user_mode+0x22/0x40? do_syscall_64+0x69/0x90? do_syscall_64+0x69/0x90? common_interrupt+0x43/0xa0 Entry_SYSCALL_64_after_hwframe+0x72/0xdc RIP: 0033:0x1470abe3ec6b Código: no se puede acceder a los bytes del código de operación en RIP 0x1470abe3ec41. RSP: 002b:00007fff13ce9108 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: fffffffffffffffc RBX: 00007fff13ce9218 RCX: 00001470abe3ec6b RDX: 00007fff13ce9 200 RSI: 00000000c0181b01 RDI: 00000000000000004 RBP: 00007fff13ce91e0 R08: 0000558d9655da10 R09: 0000558d9655dd00 R10: 00007fff13ce95c0 R11: 0000000000000246 R12: 00007fff13ce9358 R13: 0000000000000013 R14: 0000558d9655db50 R15: 00007fff13ce9470 --[ final de seguimiento 888a9b92e04c5c97 ]--

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: arp: Evita el desbordamiento en arp_req_get(). syzkaller informó una escritura desbordada en arp_req_get(). [0] Cuando se emite ioctl(SIOCGARP), arp_req_get() busca una entrada vecina y copia neigh->ha para estructurar arpreq.arp_ha.sa_data. El arp_ha aquí es struct sockaddr, no struct sockaddr_storage, por lo que el búfer sa_data tiene solo 14 bytes. En el siguiente símbolo, se desbordan 2 bytes al siguiente campo int, arp_flags. Inicializamos el campo justo después de memcpy(), por lo que no es un problema. Sin embargo, cuando dev->addr_len es mayor que 22 (por ejemplo, MAX_ADDR_LEN), se sobrescribe arp_netmask, que podría configurarse como htonl(0xFFFFFFFFUL) en arp_ioctl() antes de llamar a arp_req_get(). Para evitar el desbordamiento, limitemos la longitud máxima de memcpy(). Tenga en cuenta que el commit b5f0de6df6dc ("net: dev: Convert sa_data to flexible array in struct sockaddr") simplemente silenció a syzkaller. [0]: memcpy: escritura detectada en todos los campos (tamaño 16) de un solo campo "r->arp_ha.sa_data" en net/ipv4/arp.c:1128 (tamaño 14) ADVERTENCIA: CPU: 0 PID: 144638 en net /ipv4/arp.c:1128 arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128 Módulos vinculados en: CPU: 0 PID: 144638 Comm: syz-executor.4 No contaminado 6.1.74 #31 Nombre de hardware: QEMU PC estándar (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-5 01/04/2014 RIP: 0010:arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128 Código: fd ff ff e8 41 42 de fb b9 0e 00 00 00 4c 89 fe 48 c7 c2 20 6d ab 87 48 c7 c7 80 6d ab 87 c6 05 25 af 72 04 01 e8 5f 8d ad fb <0f> 0b e9 6c fd ff ff e8 13 42 de fb be 03 00 00 00 4c 89 e7 e8 a6 RSP: 0018:ffffc900050b7998 EFLAGS: 00010286 RAX: 00000000000000000 RBX: ffff88803a815000 RCX: 0000000000000 000 RDX: 0000000000000000 RSI: ffffffff8641a44a RDI: 0000000000000001 RBP: ffffc900050b7a98 R08: 00000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 203a7970636d656d R12: ffff888039c54000 R13: 1ffff92000a16f37 R14: ffff88803a815084 R15: 0000000000000010 FS: 0000 7f172bf306c0(0000) GS:ffff88805aa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f172b3569f0 CR3: 0000000057f12005 CR4 : 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 00000000000000000 DR6: 00000000ffe0ff0 DR7: 000000 0000000400 PKRU: 55555554 Seguimiento de llamadas: arp_ioctl+0x33f/0x4b0 net/ipv4/arp.c:1261 inet_ioctl+0x314/0x3a0 net/ ipv4/af_inet.c:981 sock_do_ioctl+0xdf/0x260 net/socket.c:1204 sock_ioctl+0x3ef/0x650 net/socket.c:1321 vfs_ioctl fs/ioctl.c:51 [en línea] __do_sys_ioctl fs/ioctl.c:870 [en línea] __se_sys_ioctl fs/ioctl.c:856 [en línea] __x64_sys_ioctl+0x18e/0x220 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:51 [en línea] do_syscall_64+0x37/0x90 arch/x86/ entrada/common.c:81 entrada_SYSCALL_64_after_hwframe+0x64/0xce RIP: 0033:0x7f172b262b8d Código: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f172bf300b8 EFLAGS: 0000024 6 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX : 00007f172b3abf80 RCX: 00007f172b262b8d RDX: 0000000020000000 RSI: 0000000000008954 RDI: 00000000000000003 RBP: 00007f172b2d3493 R08: 0 000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000000000000 R13: 000000000000000b R14: 00007f172b3abf80 R15: 00007f172bf10000

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: afs: aumenta el tamaño del búfer en afs_update_volume_status() La longitud máxima del volumen->valor vid es de 20 caracteres. Por lo tanto, aumente el tamaño de idbuf[] hasta 24 para evitar el desbordamiento. Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE. [DH: En realidad, es 20 + NUL, así que auméntalo a 24 y usa snprintf()]

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net/sched: act_mirred: use el trabajo pendiente para el ingreso duplicado. La prueba que Davide agregó en el compromiso ca22da2fbd69 ("act_mirred: use el trabajo pendiente para llamadas anidadas para el ingreso duplicado") bloquea nuestras máquinas virtuales de prueba. aproximadamente cada 10 ejecuciones, con el conocido punto muerto tcp_v4_rcv -> tcp_v4_rcv informado por lockdep. El problema descrito anteriormente por Davide (ver Enlace) es que si invertimos el flujo de tráfico con la redirección (salida -> entrada) podemos llegar al mismo socket que generó el paquete. Y es posible que todavía estemos sosteniendo el bloqueo del enchufe. La solución común a estos puntos muertos es colocar el paquete en el trabajo pendiente de Rx, en lugar de ejecutar la ruta de Rx en línea. Haga eso para todas las reversiones de salida -> entrada, no solo una vez que comenzamos a anidar llamadas reflejadas. En el pasado, existía la preocupación de que la dirección indirecta del trabajo pendiente provocara la pérdida de informes de errores o estadísticas menos precisas. Pero la solución actual no parece solucionar el problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dccp/tcp: Unhash sk de ehash para error de asignación de tb2 después de check_estalblished(). syzkaller informó una advertencia [0] en inet_csk_destroy_sock() sin reproducción. WARN_ON(inet_sk(sk)->inet_num && !inet_csk(sk)->icsk_bind_hash); Sin embargo, el registro del syzkaller insinuó que connect() falló justo antes de la advertencia debido a FAULT_INJECTION. [1] Cuando se llama a connect() para un socket independiente, buscamos un puerto efímero disponible. Si existe un depósito bhash para el puerto, llamamos a __inet_check_establecido() o __inet6_check_establecido() para verificar si el depósito es reutilizable. Si es reutilizable, agregamos el socket en ehash y configuramos inet_sk(sk)->inet_num. Luego, buscamos el depósito bhash2 correspondiente e intentamos asignarlo si no existe. Aunque rara vez ocurre en el uso real, si la asignación falla, debemos revertir los cambios mediante check_establecido(). De lo contrario, un enchufe desconectado podría ocupar ilegalmente una entrada ehash. Tenga en cuenta que no volvemos a colocar tw en ehash porque es posible que sk ya haya respondido a un paquete para tw y sería mejor liberar tw antes bajo tal presión de memoria. [0]: ADVERTENCIA: CPU: 0 PID: 350830 en net/ipv4/inet_connection_sock.c:1193 inet_csk_destroy_sock (net/ipv4/inet_connection_sock.c:1193) Módulos vinculados en: Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996 ), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 01/04/2014 RIP: 0010:inet_csk_destroy_sock (net/ipv4/inet_connection_sock.c:1193) Código: 41 5c 41 5d 41 5e e9 2d 4a 3d fd e8 28 4a 3d fd 48 89 ef e8 f0 cd 7d ff 5b 5d 41 5c 41 5d 41 5e e9 13 4a 3d fd e8 0e 4a 3d fd <0f> 0b e9 61 fe ff ff e8 02 4a 3d fd 4c 89 e 7 be 03 00 00 00 e8 05 RSP: 0018:ffffc9000b21fd38 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000009e78 RCX: ffffffff840bae40 RDX: ffff88806e 46c600 RSI: ffffffff840bb012 RDI: ffff88811755cca8 RBP: ffff88811755c880 R08: 0000000000000003 R09: 00000000000000000 R10: 0000000000009e78 R11: 00 00000000000000 R12: ffff88811755c8e0 R13: ffff88811755c892 R14: ffff88811755c918 R15: 0000000000000000 FS: 00007f03e5243800(0000) GS:ffff88811ae00000(0000) knl GS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b32f21000 CR3: 0000000112ffe001 CR4: 0000000000770ef0 PKRU: 5555 Llamada 5554 Seguimiento: ? inet_csk_destroy_sock (net/ipv4/inet_connection_sock.c:1193) dccp_close (net/dccp/proto.c:1078) inet_release (net/ipv4/af_inet.c:434) __sock_release (net/socket.c:660) sock_close (net/ socket.c:1423) __fput (fs/file_table.c:377) __fput_sync (fs/file_table.c:462) __x64_sys_close (fs/open.c:1557 fs/open.c:1539 fs/open.c:1539) do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83) Entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:129) RIP: 0033:0x7f03e53852bb Código: 03 00 00 00 0f 05 48 3d 00 f0 ff ff 77 41 c3 48 83 ec 18 89 7c 24 0c e8 43 c9 f5 ff 8b 7c 24 0c 41 89 c0 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 3 5 44 89 c7 89 44 24 0c e8 a1 c9 f5 ff 8b 44 RSP: 002b:00000000005dfba0 EFLAGS: 00000293 ORIG_RAX: 00000000000000003 RAX: ffffffffffffffda RBX: 00000000000000004 RCX: 00007f03e53852bb RDX: 0000000000000002 RSI: 0000000000000002 RDI: 0000000000000003 RBP: 000000000000000000 R08: 0000000000000000 R09: 000000000000167c R10: 0000000008a79680 R11: 0000000000000293 R12: 00007f03e4e43000 R13: 00007f03e4e43170 R14: 00007f03e4e43178 R15: 00007f03e4e431 70 [1]: FAULT_INJECTION: forzando un fallo. nombre failslab, intervalo 1, probabilidad 0, espacio 0, tiempos 0 CPU: 0 PID: 350833 Comm: syz-executor.1 No contaminado 6.7.0-12272-g2121c43f88f5 #9 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996 ), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 01/04/2014 Seguimiento de llamadas: dump_stack_lvl---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: scsi: smartpqi: solucione enable_managed_interrupts Corrija el problema de registro de blk-mq con el parámetro del módulo enable_managed_interrupts habilitado. Cuando desactivamos el indicador PCI_IRQ_AFFINITY predeterminado, el controlador debe registrarse con blk-mq usando blk_mq_map_queues(). Actualmente, el controlador está llamando a blk_mq_pci_map_queues(), lo que genera un seguimiento de la pila y posiblemente un comportamiento indefinido. Seguimiento de pila: [7.860089] scsi host2: smartpqi [7.871934] ADVERTENCIA: CPU: 0 PID: 238 en block/blk-mq-pci.c:52 blk_mq_pci_map_queues+0xca/0xd0 [7.889231] Módulos vinculados en: sd_mod t10_pi sg uas smartpqi (+) crc32c_intel scsi_transport_sas usb_storage dm_mirror dm_region_hash dm_log dm_mod ipmi_devintf ipmi_msghandler fusible [7.924755] CPU: 0 PID: 238 Comm: kworker/0:3 No contaminado 4.18.0-372.88.1.el8_6_smartpqi_test .x86_64 #1 [7.944336] Nombre del hardware: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 08/03/2022 [ 7.963026] Cola de trabajo: eventos work_for_cpu_fn [ 7.978275] RIP: 0010:blk_mq_pci_map_queues+0xca/0xd0 [ 7.978278] Código: 4 8 89 de 89 c7 e8 f6 0f 4f 00 3b 05 c4 b7 8e 01 72 e1 5b 31 c0 5d 41 5c 41 5d 41 5e 41 5f e9 7d df 73 00 31 c0 e9 76 df 73 00 <0f> 0b eb bc 90 90 0f 1f 44 00 00 41 5 7 49 89 y siguientes 41 56 41 55 41 54 [ 7.978280] RSP: 0018:ffffa95fc3707d50 EFLAGS: 00010216 [ 7.978283] RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 000000 0000000010 [ 7.978284] RDX: 00000000000000004 RSI: 0000000000000000 RDI: ffff9190c32d4310 [ 7.978286] RBP: 0000000000000000 R08: ffffa95fc370 7d38 R09: ffff91929b81ac00 [ 7.978287] R10: 00000000000000001 R11: ffffa95fc3707ac0 R12: 00000000000000000 [ 7.978288] R13: ffff9190c32d4000 R14: 0 0000000ffffffff R15: ffff9190c4c950a8 [ 7.978290] FS: 0000000000000000(0000) GS:ffff9193efc00000(0000) knlGS:0000000000000000 [ 7.978292] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [8.172814] CR2: 000055d11166c000 CR3: 00000002dae10002 CR4: 00000000007706f0 [8.172816] DR0: [ 8.172818] PKRU : 55555554 [8.172819] Seguimiento de llamadas: [8.172823] blk_mq_alloc_tag_set+0x12e/0x310 [8.264339] scsi_add_host_with_dma.cold.9+0x30/0x245 [8.279302] pqi_ctrl_init+0xacf/0 xc8e [smartpqi] [8.294085]? pqi_pci_probe+0x480/0x4c8 [smartpqi] [ 8.309015] pqi_pci_probe+0x480/0x4c8 [smartpqi] [ 8.323286] local_pci_probe+0x42/0x80 [ 8.337855] work_for_cpu_fn+0x16/0x20 [ 8.3 51193] proceso_one_work+0x1a7/0x360 [8.364462]? create_worker+0x1a0/0x1a0 [8.379252] work_thread+0x1ce/0x390 [8.392623]? create_worker+0x1a0/0x1a0 [8.406295] kthread+0x10a/0x120 [8.418428]? set_kthread_struct+0x50/0x50 [8.431532] ret_from_fork+0x1f/0x40 [8.444137] ---[ final de seguimiento 1bf0173d39354506 ]---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: crypto: virtio/akcipher: corrige el desbordamiento de pila en memcpy sizeof(struct virtio_crypto_akcipher_session_para) es menor que sizeof(struct virtio_crypto_op_ctrl_req::u), copiar más bytes de la variable de pila provoca el desbordamiento de pila. Clang informa este problema mediante comandos: make -j CC=clang-14 mrproper >/dev/null 2>&1 make -j O=/tmp/crypto-build CC=clang-14 allmodconfig >/dev/null 2>&1 make -j O=/tmp/crypto-build W=1 CC=clang-14 drivers/crypto/virtio/ virtio_crypto_akcipher_algs.o

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: roles: soluciona el problema del puntero NULL al colocar la referencia del módulo. En el diseño actual, el controlador de clase de rol usb obtendrá la referencia del módulo principal usb_role_switch después de que el usuario obtenga el dispositivo usb_role_switch y coloque la referencia después del El usuario puso el dispositivo usb_role_switch. Sin embargo, el dispositivo principal de usb_role_switch se puede eliminar antes de que el usuario coloque usb_role_switch. Si es así, entonces, el problema del puntero NULL se solucionará cuando el usuario coloque la referencia del módulo principal. Esto guardará el puntero del módulo en la estructura de usb_role_switch. Entonces, no necesitamos encontrar el módulo iterando relaciones largas.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Corrección de ejecucións entre bpf_timer_cancel_and_free y bpf_timer_cancel La siguiente ejecución es posible entre bpf_timer_cancel_and_free y bpf_timer_cancel. Dirigirá una UAF en el temporizador->temporizador. bpf_timer_cancel(); spin_lock(); t = temporizador->tiempo; spin_unlock(); bpf_timer_cancel_and_free(); spin_lock(); t = temporizador->temporizador; temporizador->temporizador = NULL; spin_unlock(); hrtimer_cancel(&t->temporizador); klibre(t); /* UAF en t */ hrtimer_cancel(&t->timer); En bpf_timer_cancel_and_free, este parche libera el temporizador->temporizador después de un período de gracia de rcu. Esto requiere una adición de rcu_head a "struct bpf_hrtimer". Otro kfree(t) ocurre en bpf_timer_init, esto no necesita un kfree_rcu porque todavía está bajo spin_lock y otros aún no han visible el temporizador->temporizador. En bpf_timer_cancel, se agrega rcu_read_lock() porque este asistente puede usarse en un contexto de sección no crítica para rcu (por ejemplo, desde un programa bpf que se puede dormir). Se han auditado otros usos de temporizador->temporizador en helpers.c, bpf_timer_cancel() es el único lugar donde se usa temporizador->temporizador fuera de spin_lock. Otra solución considerada es marcar una bandera t-> en bpf_timer_cancel y borrarla una vez finalizado hrtimer_cancel(). En bpf_timer_cancel_and_free, está ocupado esperando a que se borre la bandera antes de kfree(t). Este parche incluye una solución sencilla y libera el temporizador->temporizador después de un período de gracia de rcu.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/srpt: admite la especificación del parámetro srpt_service_guid. Hace que la carga de ib_srpt con este conjunto de parámetros funcione. El comportamiento actual es que configurar ese parámetro mientras se carga el módulo del kernel ib_srpt desencadena el siguiente fallo del kernel: ERROR: desreferencia del puntero NULL del kernel, dirección: 0000000000000000 Seguimiento de llamadas: parse_one+0x18c/0x1d0 parse_args+0xe1/0x230 load_module+0x8de/ 0xa60 init_module_from_file+0x8b/0xd0 idempotent_init_module+0x181/0x240 __x64_sys_finit_module+0x5a/0xb0 do_syscall_64+0x5f/0xe0 Entry_SYSCALL_64_after_hwframe+0x6e/0x76