Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: octeontx2-pf: Corrección del uso de GFP_KERNEL en contexto atómico en rt. El commit 4af1b64f80fb ("octeontx2-pf: Corrección del ID de lmtst usado en aura free") utiliza get/put_cpu() para proteger el uso del puntero percpu en la retrollamada ->aura_freeptr(), pero también deshabilita innecesariamente la preempción para la asignación de memoria bloqueable. El commit 87b93b678e95 ("octeontx2-pf: Evitar el uso de GFP_KERNEL en contexto atómico") intentó corregir estas advertencias de suspensión dentro de contexto atómico. Sin embargo, solo corrigió la del kernel no rt. Para el kernel rt, aún recibimos advertencias similares a las que se muestran a continuación. ERROR: función inactiva llamada desde contexto no válido en kernel/locking/spinlock_rt.c:46 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper/0 preempt_count: 1, expected: 0 Profundidad de anidamiento de RCU: 0, expected: 0 3 bloqueos mantenidos por swapper/0/1: #0: ffff800009fc5fe8 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_lock+0x24/0x30 #1: ffff000100c276c0 (&mbox->lock){+.+.}-{3:3}, at: otx2_init_hw_resources+0x8c/0x3a4 #2: ffffffbfef6537e0 (&cpu_rcache->lock){+.+.}-{2:2}, en: alloc_iova_fast+0x1ac/0x2ac Preempción deshabilitada en: [] otx2_rq_aura_pool_init+0x14c/0x284 CPU: 20 PID: 1 Comm: swapper/0 Contaminado: GW 6.2.0-rc3-rt1-yocto-preempt-rt #1 Nombre del hardware: Placa Marvell OcteonTX CN96XX (DT) Rastreo de llamadas: dump_backtrace.part.0+0xe8/0xf4 show_stack+0x20/0x30 dump_stack_lvl+0x9c/0xd8 dump_stack+0x18/0x34 __might_resched+0x188/0x224 rt_spin_lock+0x64/0x110 alloc_iova_fast+0x1ac/0x2ac iommu_dma_alloc_iova+0xd4/0x110 __iommu_dma_map+0x80/0x144 iommu_dma_map_page+0xe8/0x260 dma_map_page_attrs+0xb4/0xc0 __otx2_alloc_rbuf+0x90/0x150 otx2_rq_aura_pool_init+0x1c8/0x284 otx2_init_hw_resources+0xe4/0x3a4 otx2_open+0xf0/0x610 __dev_open+0x104/0x224 __dev_change_flags+0x1e4/0x274 dev_change_flags+0x2c/0x7c ic_open_devs+0x124/0x2f8 ip_auto_config+0x180/0x42c do_one_initcall+0x90/0x4dc do_basic_setup+0x10c/0x14c kernel_init_freeable+0x10c/0x13c kernel_init+0x2c/0x140 ret_from_fork+0x10/0x20 Por supuesto, podemos barajar el get/put_cpu() para solo envolver la invocación de ->aura_freeptr() como lo hace el commit 87b93b678e95. Pero solo hay dos devoluciones de llamada ->aura_freeptr(): otx2_aura_freeptr() y cn10k_aura_freeptr(). La variable perpcu no se usa en absoluto en otx2_aura_freeptr(), por lo que get/put_cpu() parece redundante. Podemos mover get/put_cpu() a la devolución de llamada correspondiente que sí usa la variable percpu y evitar así la dispersión de get/put_cpu() en varios lugares.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: octeontx2-pf: Evitar el uso de GFP_KERNEL en un contexto atómico. El uso de GFP_KERNEL en el contexto de deshabilitación de preempción provoca la siguiente advertencia cuando CONFIG_DEBUG_ATOMIC_SLEEP está habilitado. [ 32.542271] ERROR: función de suspensión llamada desde contexto no válido en include/linux/sched/mm.h:274 [ 32.550883] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper/0 [ 32.558707] preempt_count: 1, esperado: 0 [ 32.562710] Profundidad de anidamiento de RCU: 0, esperado: 0 [ 32.566800] CPU: 3 PID: 1 Comm: swapper/0 Tainted: GW 6.2.0-rc2-00269-gae9dcb91c606 #7 [ 32.576188] Nombre del hardware: Placa Marvell CN106XX (DT) [ 32.581232] Rastreo de llamadas: [ 32.583670] dump_backtrace.part.0+0xe0/0xf0 [ 32.587937] show_stack+0x18/0x30 [ 32.591245] dump_stack_lvl+0x68/0x84 [ 32.594900] dump_stack+0x18/0x34 [ 32.598206] __might_resched+0x12c/0x160 [ 32.602122] __might_sleep+0x48/0xa0 [ 32.605689] __kmem_cache_alloc_node+0x2b8/0x2e0 [ 32.610301] __kmalloc+0x58/0x190 [ 32.613610] otx2_sq_aura_pool_init+0x1a8/0x314 [ 32.618134] otx2_open+0x1d4/0x9d0 Para evitar el uso de GFP_ATOMIC para la asignación de memoria, deshabilite la preempción una vez que se haya realizado toda la asignación de memoria.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/core: Fix ib block iterator counter overflow Al registrar un nuevo DMA MR después de seleccionar el mejor tamaño de página alineado para él, iteramos sobre la sglist dada para dividir cada entrada en bloques DMA más pequeños, alineados con el tamaño de página seleccionado. En determinadas circunstancias en las que la entrada sg y el tamaño de página se ajustan a ciertos tamaños y la entrada sg no está alineada con el tamaño de página seleccionado, el tamaño total de las páginas alineadas que necesitamos para cubrir la entrada sg es >= 4 GB. En estas circunstancias, al iterar bloques alineados de página, el contador responsable de contar cuánto avanzamos desde el inicio de la entrada sg se desborda porque su tipo es u32 y pasamos 4 GB de tamaño. Esto puede llevar a un bucle infinito dentro de la función del iterador porque el desbordamiento impide que el contador sea mayor que el tamaño de la entrada sg. Solucione el problema presentado cambiando la condición de avance para eliminar el desbordamiento. Backtrace: [ 192.374329] efa_reg_user_mr_dmabuf [ 192.376783] efa_register_mr [ 192.382579] pgsz_bitmap 0xfffff000 rounddown 0x80000000 [ 192.386423] pg_sz [0x80000000] umem_length[0xc0000000] [ 192.392657] start 0x0 length 0xc0000000 params.page_shift 31 params.page_num 3 [ 192.399559] hp_cnt[3], pages_in_hp[524288] [ 192.403690] umem->sgt_append.sgt.nents[1] [ 192.407905] number entries: [1], pg_bit: [31] [ 192.411397] biter->__sg_nents [1] biter->__sg [0000000008b0c5d8] [ 192.415601] biter->__sg_advance [665837568] sg_dma_len[3221225472] [ 192.419823] biter->__sg_nents [1] biter->__sg [0000000008b0c5d8] [ 192.423976] biter->__sg_advance [2813321216] sg_dma_len[3221225472] [ 192.428243] biter->__sg_nents [1] biter->__sg [0000000008b0c5d8] [ 192.432397] biter->__sg_advance [665837568] sg_dma_len[3221225472]

Razón rechazado: esta identificación de CVE ha sido rechazada o retirada por su autoridad de numeración de CVE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Revertir "wifi: mac80211: corregir pérdida de memoria en ieee80211_if_add()" Esto revierte el commit 13e5afd3d773c6fc6ca2b89027befaaaa1ea7293. ieee80211_if_free() ya se llama desde free_netdev(ndev) porque ndev->priv_destructor == ieee80211_if_free syzbot informó: error de protección general, probablemente para la dirección no canónica 0xdffffc0000000004: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref en el rango [0x000000000000020-0x0000000000000027] CPU: 0 PID: 10041 Comm: syz-executor.0 No contaminado 6.2.0-rc2-syzkaller-00388-g55b98837e37d #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 26/10/2022 RIP: 0010:pcpu_get_page_chunk mm/percpu.c:262 [en línea] RIP: 0010:pcpu_chunk_addr_search mm/percpu.c:1619 [en línea] RIP: 0010:free_percpu mm/percpu.c:2271 [en línea] RIP: 0010:free_percpu+0x186/0x10f0 mm/percpu.c:2254 Código: 80 3c 02 00 0f 85 f5 0e 00 00 48 8b 3b 48 01 ef e8 cf b3 0b 00 48 ba 00 00 00 00 00 fc ff df 48 8d 78 20 48 89 f9 48 c1 e9 03 <80> 3c 11 00 0f 85 3b 0e 00 00 48 8b 58 20 48 b8 00 00 00 00 00 fc RSP: 0018:ffffc90004ba7068 EFLAGS: 00010002 RAX: 000000000000000 RBX: ffff88823ffe2b80 RCX: 0000000000000004 RDX: dffffc0000000000 RSI: ffffffff81c1f4e7 RDI: 0000000000000020 RBP: ffffe8fffe8fc220 R08: 0000000000000005 R09: 00000000000000000 R10: 0000000000000000 R11: 1ffffffff2179ab2 R12: ffff8880b983d000 R13: 000000000000003 R14: 0000607f450fc220 R15: ffff88823ffe2988 FS: 00007fcb349de700(0000) GS:ffff8880b9800000(0000) knlGS:000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b32220000 CR3: 000000004914f000 CR4: 000000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: netdev_run_todo+0x6bf/0x1100 net/core/dev.c:10352 ieee80211_register_hw+0x2663/0x4040 net/mac80211/main.c:1411 mac80211_hwsim_new_radio+0x2537/0x4d80 drivers/net/wireless/mac80211_hwsim.c:4583 hwsim_new_radio_nl+0xa09/0x10f0 drivers/net/wireless/mac80211_hwsim.c:5176 genl_family_rcv_msg_doit.isra.0+0x1e6/0x2d0 net/netlink/genetlink.c:968 genl_family_rcv_msg net/netlink/genetlink.c:1048 [en línea] genl_rcv_msg+0x4ff/0x7e0 net/netlink/genetlink.c:1065 netlink_rcv_skb+0x165/0x440 net/netlink/af_netlink.c:2564 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1076 netlink_unicast_kernel net/netlink/af_netlink.c:1330 [en línea] netlink_unicast+0x547/0x7f0 net/netlink/af_netlink.c:1356 netlink_sendmsg+0x91b/0xe10 net/netlink/af_netlink.c:1932 sock_sendmsg_nosec net/socket.c:714 [en línea] sock_sendmsg+0xd3/0x120 net/socket.c:734 ____sys_sendmsg+0x712/0x8c0 net/socket.c:2476 ___sys_sendmsg+0x110/0x1b0 net/socket.c:2530 __sys_sendmsg+0xf7/0x1c0 net/socket.c:2559 do_syscall_x64 arch/x86/entry/common.c:50 [en línea] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: NFSD: se corrige el problema de use-after-free en nfsd4_ssc_setup_dul(). Si signal_pending() devuelve verdadero, schedule_timeout() no se ejecutará, lo que provocará que la tarea en espera permanezca en la cola de espera. Se solucionó añadiendo una llamada a finish_wait(), lo que garantiza que la tarea en espera siempre se elimine de la cola de espera.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: mdio: validar el parámetro addr en mdiobus_get_phy(). El llamador puede pasar cualquier valor como addr, lo que puede resultar en un acceso fuera de límites a la matriz mdio_map. Un caso existente es stmmac_init_phy(), que puede pasar -1 como addr. Por lo tanto, valide addr antes de usarlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: hci_sync: corrige pérdida de memoria en hci_update_adv_data() Cuando hci_cmd_sync_queue() falla en hci_update_adv_data(), inst_ptr no se libera, lo que provocará una pérdida de memoria. Convierta para usar ERR_PTR/PTR_ERR para pasar la instancia a la devolución de llamada, de modo que no sea necesario asignar memoria.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: hci_conn: Se corrigen fugas de memoria. Cuando hci_cmd_sync_queue() falla en hci_le_terminate_big() o hci_le_big_terminate(), la memoria apuntada por la variable d no se libera, lo que provoca una fuga de memoria. Se añade el proceso de liberación a la ruta de error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: l2tp: cierra todas las condiciones de ejecución en l2tp_tunnel_register() El código en l2tp_tunnel_register() es de alto riesgo de varias maneras: 1. Modifica el socket _after_ publishing it. 2. Llama a setup_udp_tunnel_sock() en un socket existente sin bloquearlo. 3. Cambia la clase de bloqueo de sock sobre la marcha, lo que activa muchos informes de syzbot. Este parche las enmienda todas moviendo el código de inicialización del socket antes de publicarlo y bajo el bloqueo de sock. Como sugirió Jakub, la clase l2tp lockdep no es necesaria ya que podemos simplemente cambiar a bh_lock_sock_nested().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: enetc: evitar bloqueo en enetc_tx_onestep_tstamp() Este splat de lockdep lo dice mejor de lo que yo podría: ================================ ADVERTENCIA: estado de bloqueo inconsistente 6.2.0-rc2-07010-ga9b9500ffaac-dirty #967 No contaminado -------------------------------- uso inconsistente de {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W}. kworker/1:3/179 [HC0[0]:SC0[0]:HE1:SE1] toma: ffff3ec4036ce098 (_xmit_ETHER#2){+.?.}-{3:3}, en: netif_freeze_queues+0x5c/0xc0 {IN-SOFTIRQ-W} estado se registró en: _raw_spin_lock+0x5c/0xc0 sch_direct_xmit+0x148/0x37c __dev_queue_xmit+0x528/0x111c ip6_finish_output2+0x5ec/0xb7c ip6_finish_output+0x240/0x3f0 ip6_output+0x78/0x360 ndisc_send_skb+0x33c/0x85c ndisc_send_rs+0x54/0x12c addrconf_rs_timer+0x154/0x260 call_timer_fn+0xb8/0x3a0 __run_timers.part.0+0x214/0x26c run_timer_softirq+0x3c/0x74 __do_softirq+0x14c/0x5d8 ____do_softirq+0x10/0x20 call_on_irq_stack+0x2c/0x5c do_softirq_own_stack+0x1c/0x30 __irq_exit_rcu+0x168/0x1a0 irq_exit_rcu+0x10/0x40 el1_interrupt+0x38/0x64 marca de evento de irq: 7825 hardirqs habilitados por última vez en (7825): [] exit_to_kernel_mode+0x34/0x130 hardirqs deshabilitados por última vez en (7823): [] __do_softirq+0x550/0x5d8 softirqs habilitados por última vez en (7824): [] __do_softirq+0x46c/0x5d8 softirqs deshabilitados por última vez en (7811): [] ____do_softirq+0x10/0x20 otra información que podría ayudarnos a depurar esto: Posible escenario de bloqueo inseguro: CPU0 ---- lock(_xmit_ETHER#2); lock(_xmit_ETHER#2); *** BLOQUEO INTERMEDIO *** 3 bloqueos mantenidos por kworker/1:3/179: #0: ffff3ec400004748 ((wq_completion)eventos){+.+.}-{0:0}, en: process_one_work+0x1f4/0x6c0 #1: ffff80000a0bbdc8 ((work_completion)(&priv->tx_onestep_tstamp)){+.+.}-{0:0}, en: process_one_work+0x1f4/0x6c0 #2: ffff3ec4036cd438 (&dev->tx_global_lock){+.+.}-{3:3}, en: netif_tx_lock+0x1c/0x34 Cola de trabajo: eventos enetc_tx_onestep_tstamp Rastreo de llamadas: print_usage_bug.part.0+0x208/0x22c mark_lock+0x7f0/0x8b0 __lock_acquire+0x7c4/0x1ce0 lock_acquire.part.0+0xe0/0x220 lock_acquire+0x68/0x84 _raw_spin_lock+0x5c/0xc0 netif_freeze_queues+0x5c/0xc0 netif_tx_lock+0x24/0x34 enetc_tx_onestep_tstamp+0x20/0x100 process_one_work+0x28c/0x6c0worker_thread+0x74/0x450 kthread+0x118/0x11c pero lo diré de todos modos: el elemento de trabajo enetc_tx_onestep_tstamp() se ejecuta en el contexto del proceso, por lo tanto, con softirqs habilitado (Es decir, puede ser interrumpido por un softirq). Si mantenemos la ejecución de netif_tx_lock() cuando hay una interrupción, y luego se programa el softirq NET_TX, se ejecutará netif_tx_lock() por segunda vez y se bloqueará el kernel. Para solucionar esto, use netif_tx_lock_bh(), que impide la ejecución de los softirq.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/sched: sch_taprio: corrección de posible error de use-after-free syzbot reportó un fallo grave [1] en net_tx_action() que no tenía sentido hasta que se reprodujo. Esta reproducción instala una qdisc de Taprio, pero proporciona un atributo TCA_RATE no válido. qdisc_create() debe destruir la qdisc de Taprio recién inicializada, y se llama a taprio_destroy(). Sin embargo, el temporizador hr usado por Taprio ya se había ejecutado, por lo que advance_sched() llamó a __netif_schedule(). Entonces, net_tx_action intentaba usar una qdisc destruida. No podemos deshacer __netif_schedule(), por lo que debemos esperar a que una CPU haya dado servicio a la qdisc antes de continuar. Muchas gracias a Alexander Potapenko por su ayuda. [1] ERROR: KMSAN: valor no inicializado en queued_spin_trylock include/asm-generic/qspinlock.h:94 [en línea] ERROR: KMSAN: valor no inicializado en do_raw_spin_trylock include/linux/spinlock.h:191 [en línea] ERROR: KMSAN: valor no inicializado en __raw_spin_trylock include/linux/spinlock_api_smp.h:89 [en línea] ERROR: KMSAN: valor no inicializado en _raw_spin_trylock+0x92/0xa0 kernel/locking/spinlock.c:138 queued_spin_trylock include/asm-generic/qspinlock.h:94 [en línea] do_raw_spin_trylock include/linux/spinlock.h:191 [en línea] __raw_spin_trylock incluir/linux/spinlock_api_smp.h:89 [en línea] _raw_spin_trylock+0x92/0xa0 kernel/locking/spinlock.c:138 spin_trylock incluir/linux/spinlock.h:359 [en línea] qdisc_run_begin incluir/net/sch_generic.h:187 [en línea] qdisc_run+0xee/0x540 incluir/net/pkt_sched.h:125 net_tx_action+0x77c/0x9a0 net/core/dev.c:5086 __do_softirq+0x1cc/0x7fb kernel/softirq.c:571 run_ksoftirqd+0x2c/0x50 kernel/softirq.c:934 smpboot_thread_fn+0x554/0x9f0 kernel/smpboot.c:164 kthread+0x31b/0x430 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 Uninit se creó en: slab_post_alloc_hook mm/slab.h:732 [en línea] slab_alloc_node mm/slub.c:3258 [en línea] __kmalloc_node_track_caller+0x814/0x1250 mm/slub.c:4970 kmalloc_reserve net/core/skbuff.c:358 [en línea] __alloc_skb+0x346/0xcf0 net/core/skbuff.c:430 alloc_skb include/linux/skbuff.h:1257 [en línea] nlmsg_new include/net/netlink.h:953 [en línea] netlink_ack+0x5f3/0x12b0 net/netlink/af_netlink.c:2436 netlink_rcv_skb+0x55d/0x6c0 net/netlink/af_netlink.c:2507 rtnetlink_rcv+0x30/0x40 net/core/rtnetlink.c:6108 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [en línea] netlink_unicast+0xf3b/0x1270 net/netlink/af_netlink.c:1345 netlink_sendmsg+0x1288/0x1440 net/netlink/af_netlink.c:1921 sock_sendmsg_nosec net/socket.c:714 [en línea] sock_sendmsg net/socket.c:734 [en línea] ____sys_sendmsg+0xabc/0xe90 net/socket.c:2482 ___sys_sendmsg+0x2a1/0x3f0 net/socket.c:2536 __sys_sendmsg net/socket.c:2565 [en línea] __do_sys_sendmsg net/socket.c:2574 [en línea] __se_sys_sendmsg net/socket.c:2572 [en línea] __x64_sys_sendmsg+0x367/0x540 net/socket.c:2572 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+0x63/0xcd CPU: 0 PID: 13 Comm: ksoftirqd/0 No contaminado 6.0.0-rc2-syzkaller-47461-gac3859c02d7f #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 22/07/2022