Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mlxbf_gige: llame a request_irq() después de inicializar NAPI. El controlador mlxbf_gige encuentra una excepción de puntero NULL en mlxbf_gige_open() cuando kdump está habilitado. La secuencia para reproducir la excepción es la siguiente: a) habilitar kdump b) activar kdump mediante "echo c > /proc/sysrq-trigger" c) el kernel de kdump se ejecuta d) el kernel de kdump carga el módulo mlxbf_gige e) el módulo mlxbf_gige se ejecuta en abierto () cuando se abre la interfaz "oob_net0" f) El módulo mlxbf_gige experimentará una excepción durante su apertura(), algo así como: No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 0000000000000000 Información de cancelación de memoria: ESR = 0x0000000086000004 EC = 0x21 : IABT (EL actual), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: tabla de usuario de error de traducción de nivel 0: 4k páginas, VA de 48 bits, pgdp=00000000e29a4000 [00000000000000000] pgd=0000000000000000, p4d=00000000000000000 Error interno: Vaya: 0000000086000004 [#1] CPU SMP: 0 PID: 812 Comunicaciones: NetworkManager contaminado: G OE 5.15.0-1035-bluefield #37-Ubuntu Nombre de hardware: https ://www .mellanox.com Tarjeta principal BlueField-3 SmartNIC/Tarjeta principal BlueField-3 SmartNIC, BIOS 4.6.0.13024 19 de enero de 2024 pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc: 0x0 lr : __napi_poll+0x40/0x230 sp : ffff800008003e00 x29: ffff800008003e00 x28: 0000000000000000 x27: 00000000ffffffff x26: ffff000066027238 x25: 7cedec00 x24: ffff800008003ec8 x23: 000000000000012c x22: ffff800008003eb7 x21: 00000000000000000 x20: 0000000000000001 x19: ffff000066027238 x 18: 0000000000000000 x17: ffff578fcb450000 x16: ffffa870b083c7c0 x15: 0000aaab010441d0 x14: 0000000000000001 x13: 00726f7272655f65 x12: 6769675f6662786c x11: 0000000000000000 x10: 0000000000000000 x9: ffffa870b0842398 x8: 0000000000000004 x7: fe5a48b9069706ea x6: 17fdb11fc84ae0d2 x5: d94a82549d594f35 x4: 00000000000000 000 x3: 0000000000400100 x2: 0000000000000000 x1: 0000000000000000 x0: ffff000066027238 Llamar seguimiento: 0x0 net_rx_action+0x178/0x360 __do_softirq+0x15c/0x428 __irq_exit_rcu+0xac/0xec irq_exit+0x18/0x2c handle_domain_irq+0x6c/0xa0 gic_handle_irq+0xec/0x1b0 call_on_irq_stack+0x2 0/0x2c do_interrupt_handler+0x5c/0x70 el1_interrupt+0x30/0x50 el1h_64_irq_handler+ 0x18/0x2c el1h_64_irq+0x7c/0x80 __setup_irq+0x4c0/0x950 request_threaded_irq+0xf4/0x1bc mlxbf_gige_request_irqs+0x68/0x110 [mlxbf_gige] mlxbf_gige_open+0x5c/0x170 bf_gige] __dev_open+0x100/0x220 __dev_change_flags+0x16c/0x1f0 dev_change_flags+0x2c/0x70 do_setlink +0x220/0xa40 __rtnl_newlink+0x56c/0x8a0 rtnl_newlink+0x58/0x84 rtnetlink_rcv_msg+0x138/0x3c4 netlink_rcv_skb+0x64/0x130 rtnetlink_rcv+0x20/0x30 netlink_unicast+0x2ec/0x360 netlink_sendmsg+0x278/0x490 __sock_sendmsg+0x5c/0x6c ____sys_sendmsg+0x290/0x2d4 ___sys_sendmsg +0x84/0xd0 __sys_sendmsg+0x70/0xd0 __arm64_sys_sendmsg+0x2c/0x40 invoke_syscall+0x78/0x100 el0_svc_common.constprop.0+0x54/0x184 do_el0_svc+0x30/0xac c+0x48/0x160 el0t_64_sync_handler+0xa4/0x12c el0t_64_sync+0x1a4/0x1a8 Código: valor incorrecto de la PC ---[ seguimiento final 7d1c3f3bf9d81885 ]--- Pánico del kernel - no se sincroniza: Vaya: excepción grave en la interrupción Compensación del kernel: 0x2870a7a00000 de 0xffff800008000000 PHYS_OFFSET: 0x80000000 Características de la CPU: 0x0,000005c1,a33 32a5a Límite de memoria: ninguno --- [fin del pánico del kernel - no se sincroniza: Ups: excepción fatal en la interrupción]--- La excepción ocurre porque hay una interrupción RX pendiente antes de que se ejecute la llamada a request_irq(RX IRQ). Luego, el controlador RX IRQ se activa inmediatamente después de que se completa request_irq(). El ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: tls: obtenga referencia de psock después de tomar rxlock para evitar fugas. Al inicio de tls_sw_recvmsg, tomamos una referencia en psock y luego llamamos a tls_rx_reader_lock. Si eso falla, volvemos directamente sin liberar la referencia. En lugar de agregar una nueva etiqueta, simplemente tome la referencia después de que el bloqueo se haya realizado correctamente, ya que no la necesitamos antes.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: net: wwan: t7xx: Accesos divididos de 64 bits para solucionar problemas de alineación Algunos de los registros están alineados en un límite de 32 bits, provocando fallos de alineación en plataformas de 64 bits. No se puede manejar la solicitud de paginación del kernel en la dirección virtual ffffffc084a1d004 Información de cancelación de memoria: ESR = 0x0000000096000061 EC = 0x25: DABT (EL actual), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x21: alineación falla Información de cancelación de datos: ISV = 0, ISS = 0x00000061, ISS2 = 0x00000000 CM = 0, WnR = 1, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 tabla de intercambio: 4k páginas, VA de 39 bits, pgdp=0000000046ad6000 [ffffffc084a1d004] pgd=100000013ffff003, p4d=100000013ffff003, pud=100000013ffff003, pmd=0068000020a00711 Error interno: Vaya: 0000000096000061 [#1] Módulos SMP vinculados en: mtk_t7xx(+) qcserial pppoe ppp_async opción nft_fib_inet nf_flow_table_inet mt7921u(O) mt7921s(O) mt7921e(O) mt7921_common(O) iwlmvm(O) iwldvm(O) usb_wwan rndis_host qmi_wwan pppox ppp_generic nft_reject_ipv6 nft_reject_ipv4 n ft_reject_inet nft_reject nft_redir nft_quota nft_numgen nft_nat nft_masq nft_log nft_limit nft_hash nft_flow_offload nft_fib_ipv6 nft_fib_ipv4 nft_fib nft_ct nft_chain_nat nf_tables nf_nat nf_flow_table nf_conntrack mt7996e(O) mt792x_usb(O) mt792x_lib(O) mt7915e(O) mt76_usb(O) mt76_sdio(O) mt76_connac_lib(O) mt76(O) mac80211(O) O) huawei_cdc_ncm cfg80211(O) cdc_ncm cdc_ether wwan usbserial usbnet slhc sfp rtc_pcf8563 nfnetlink nf_reject_ipv6 nf_reject_ipv4 nf_log_syslog nf_defrag_ipv6 nf_defrag_ipv4 mt6577_auxadc mdio_i2c libcrc32c compat(O) cdc_wdm c_acm at24 crypto_safexcel pwm_fan i2c_gpio i2c_smbus industrialio i2c_algo_bit i2c_mux_reg i2c_mux_pca954x i2c_mux_pca9541 i2c_mux_gpio i2c_mux dummy oid_registry tun sha512_arm64 sha1_ce sha1_generic seqiv md5 des_generic libdes cbc authencesn authenc leds_gpio xhci_plat_hcd xhci_pci xhci_mtk_hcd xhci_hcd nvme nvme_core gpio_button_hotplug(O) dm_mirror dm_region_hash dm_log dm_crypt dm_mod dax usbcore usb_common ptp aquantia pps_core mii tpm encrypted_keys CPU confiable: 3 PID: 5266 Comm: kworker/u9:1 ted: GO 6.6.22 #0 Nombre del hardware: Bananapi BPI -R4 (DT) Cola de trabajo: md_hk_wq t7xx_fsm_uninit [mtk_t7xx] pstate: 804000c5 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc: t7xx_cldma_hw_set_start_addr+0x1c/0x3c [mtk_t7xx] lr: _cldma_start+0xac/0x13c [mtk_t7xx] sp: ffffffc085d63d30 x29: ffffffc085d63d30 x28: 0000000000000000 x27: 00000000000000000 x26: 0000000000000000 x25: ffffff80c804f2c 0 x24: ffffff80ca196c05 x23: 0000000000000000 x22: ffffff80c814b9b8 x21: ffffff80c814b128 x20: 00000000000000001 x19: ffffff80c814b080 x18: 00000000014 x17: 0000000055c9806b x16: 000000007c5296d0 x15: 000000000f6bca68 x14: 00000000dbdbdce4 x13: 000000001aeaf72a x12: 0000000000000001 x11: 00000000000000000 x10: 0000000000000000 x9: 000 0000000000000 x8: ffffff80ca1ef6b4 x7: ffffff80c814b818 x6: 0000000000000018 x5: 0000000000000870 x4: 0000000000000000 x3: 0000000000000000 0 x2: 000000010a947000 x1: ffffffc084a1d004 x0: ffffffc084a1d004 Rastreo de llamadas: t7xx_cldma_hw_set_start_addr +0x1c/0x3c [mtk_t7xx] t7xx_fsm_uninit+0x578/0x5ec [mtk_t7xx] Process_one_work+0x154/0x2a0 Workers_thread+0x2ac/0x488 kthread+0xe0/0xec ret_from_fork+0x10/0x20 Código: f9400800 9 1001000 8b214001 d50332bf (f9000022) ---[ final de seguimiento 0000000000000000 ]--- La inclusión de io-64-nonatomic-lo-hi.h indica que todos los accesos de 64 bits pueden ser reemplazados por pares de accesos no atómicos de 32 bits. Corrija la alineación obligando a que todos los accesos sean de 32 bits en plataformas de 64 bits.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ice: corrige el error de corrupción de memoria con suspensión y reconstrucción. Anteriormente, el controlador ice entraba en pánico después de la suspensión. Esto se debe a que el controlador *solo* llama a la función ice_vsi_free_q_vectors() por sí mismo, cuando está suspendida. Desde la confirmación b3e7b3a6ee92 ("ice: evitar la eliminación del puntero NULL durante la recarga"), el controlador puso a cero num_q_vectors y solo lo restauró en ice_vsi_cfg_def(). Esto además hace que la función ice_rebuild() asigne un búfer de longitud cero, después del cual se actualiza num_q_vectors, y luego el nuevo valor de num_q_vectors se usa para indexar en el búfer de longitud cero, lo que corrompe la memoria. La solución implica asegurarse de que todo el código que hace referencia a num_q_vectors solo lo haga después de que se haya restablecido mediante ice_vsi_cfg_def(). No realicé una bisección completa, pero pude probar con el kernel 6.1.77 y ese controlador Ice funciona bien para suspender/reanudar sin pánico, por lo que en algún momento desde entonces, se introdujo este problema. También limpie un inicio innecesario de una variable local en la función que se está modificando. PÁNICO desde 6.8.0-rc1: [1026674.915596] PM: suspender salida [1026675.664697] ice 0000:17:00.1: reinicio de PTP exitoso [1026675.664707] ice 0000:17:00.1: 2755 ms transcurridos entre la actualización y el tiempo de PHC en caché [102667 5.667660] ice 0000:b1:00.0: restablecimiento de PTP exitoso [1026675.675944] ice 0000:b1:00.0: 2832 ms transcurridos entre la actualización y el tiempo de PHC en caché [1026677.137733] ixgbe 0000:31:00.0 ens787: el enlace de NIC está activo 1 Gbps, control de flujo: Ninguno [1026677.190201] ERROR: desreferencia del puntero NULL del núcleo, dirección: 0000000000000010 [1026677.192753] ice 0000:17:00.0: reinicio de PTP exitoso [1026677.192764] ice 0000:17:00.0: 4548 mseg. entre la actualización y el tiempo de PHC en caché [1026677.197928] # PF: acceso de lectura del supervisor en modo kernel [1026677.197933] #PF: error_code(0x0000) - página no presente [1026677.197937] PGD 1557a7067 P4D 0 [1026677.212133] ice 0000:b1:00.1: reinicio de PTP exitoso [1026677.2 12143] hielo 0000:b1 :00.1: Pasaron 4344 ms entre la actualización y el tiempo de PHC en caché [1026677.212575] [1026677.243142] Vaya: 0000 [#1] PREEMPT SMP NOPTI [1026677.247918] CPU: 23 PID: 42790 Comm: kworker/23:0 Kdump: cargado Ta Inted: GW 6.8.0-rc1+ #1 [1026677.257989] Nombre de hardware: Intel Corporation M50CYP2SBSTD/M50CYP2SBSTD, BIOS SE5C620.86B.01.01.0005.2202160810 16/02/2022 [1026677.269367] Cola de trabajo: ice ice_service_tas k [hielo] [1026677.274592] RIP: 0010:ice_vsi_rebuild_set_coalesce +0x130/0x1e0 [ice] [1026677.281421] Código: 0f 84 3a ff ff ff 41 0f b7 74 ec 02 66 89 b0 22 02 00 00 81 e6 ff 1f 00 00 e8 ec fd ff ff e9 35 ff ff 4 8 8b 43 30 49 63 ed <41> 0f b7 34 24 41 83 c5 01 48 8b 3c e8 66 89 b7 aa 02 00 00 81 e6 [1026677.300877] RSP: 0018:ff3be62a6399bcc0 EFLAGS: 2 [1026677.306556] RAX: ff28691e28980828 RBX: ff28691e41099828 RCX: 0000000000188000 [1026677.314148] RDX: 0000000000000000 RSI: 0000000000000010 RDI: ff28691e41099828 [1026677.321730] RBP: 0000000000 000000 R08: 0000000000000000 R09: 00000000000000000 [1026677.329311] R10: 0000000000000007 R11: ffffffffffffffc0 R12: 0000000000000010 [102 6677.336896] R13: 00000000000000000 R14: 0000000000000000 R15: ff28691e0eaa81a0 [ 1026677.344472] FS: 0000000000000000(0000) GS:ff28693cbffc0000(0000) knlGS:0000000000000000 [1026677.353000] CS: 0010 DS: 0000 ES: 0000 : 0000000080050033 [1026677.359195] CR2: 0000000000000010 CR3: 0000000128df4001 CR4: 0000000000771ef0 [1026677.366779] DR0: 00000000000 00000 DR1: 0000000000000000 DR2: 0000000000000000 [1026677.374369] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [1026677.3 81952] PKRU: 55555554 [1026677.385116] Seguimiento de llamadas: [1026677.388023] [1026677.390589] ? __morir+0x20/0x70 [1026677.394105] --truncado--

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: wifi: iwlwifi: mvm: rfi: corrige posibles fugas de respuesta Si falla la verificación de la longitud de la payload de rx, o si falla kmemdup(), aún necesitamos liberar la respuesta del comando. Arregla eso.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: wifi: iwlwifi: mvm: elige la versión de SESSION_PROTECTION_NOTIF Cuando queremos saber si debemos buscar el mac_id o el link_id en la estructura iwl_mvm_session_prot_notif, debemos mirar la versión de SESSION_PROTECTION_NOTIF . Esto provoca ADVERTENCIAS: ADVERTENCIA: CPU: 0 PID: 11403 en drivers/net/wireless/intel/iwlwifi/mvm/time-event.c:959 iwl_mvm_rx_session_protect_notif+0x333/0x340 [iwlmvm] RIP:iwl_mvm_rx_session_protect_notif+0x 333/0x340 [ iwlmvm] Código: 00 49 c7 84 24 48 07 00 00 00 00 00 00 41 c6 84 24 78 07 00 00 ff 4c 89 f7 e8 e9 71 54 d9 e9 7d fd ff ff 0f 0b e9 23 fe ff ff <0f> 0b e9 1c fe ff ff 66 0f 1f 44 00 00 90 90 90 90 90 90 90 90 90 RSP: 0018:ffffb4bb00003d40 EFLAGS: 00010202 RAX: 0000000000000000 RBX: ffff9ae63a 361000 RCX: ffff9ae4a98b60d4 RDX: ffff9ae4588499c0 RSI: 0000000000000305 RDI: ffff9ae4a98b6358 RBP: ffffb4bb00003d68 R08 : 0000000000000003 R09: 0000000000000010 R10: ffffb4bb00003d00 R11: 000000000000000f R12: ffff9ae441399050 R13: ffff9ae4761329e8 R14: 000000000001 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff9ae7af400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 0000000080050033 CR2: 000055fb75680018 CR3: 00000003dae32006 CR4: 0000000000f70ef0 PKRU: 55555554 Seguimiento de llamadas: ? show_regs+0x69/0x80? __advertir+0x8d/0x150 ? iwl_mvm_rx_session_protect_notif+0x333/0x340 [iwlmvm] ? report_bug+0x196/0x1c0? handle_bug+0x45/0x80? exc_invalid_op+0x1c/0xb0? asm_exc_invalid_op+0x1f/0x30? iwl_mvm_rx_session_protect_notif+0x333/0x340 [iwlmvm] iwl_mvm_rx_common+0x115/0x340 [iwlmvm] iwl_mvm_rx_mq+0xa6/0x100 [iwlmvm] iwl_pcie_rx_handle+0x263/0xa10 wifi] iwl_pcie_napi_poll_msix+0x32/0xd0 [iwlwifi]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfsd: corrigió la ruta de limpieza de errores en nfsd_rename() Confirme a8b0026847b8 ("rename(): evite un punto muerto en el caso de que los padres no tengan un ancestro común") agregó una ruta de rescate de errores . Sin embargo, este camino no elimina la protección de remontaje adquirida. Corrija la ruta de limpieza para eliminar correctamente la protección de remontaje.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: nfc: nci: corrigió el valor uninit en nci_dev_up y nci_ntf_packet syzbot informó el siguiente problema de acceso al valor uninit [1][2]: nci_rx_work() analiza y procesa el paquete recibido. Cuando la longitud del payload es cero, cada controlador de tipo de mensaje lee el payload no inicializado y KMSAN detecta este problema. La recepción de un paquete con un payload de tamaño cero se considera inesperada y, por lo tanto, dichos paquetes deben descartarse silenciosamente. Este parche resolvió este problema verificando el tamaño del payload antes de llamar a los códigos de controlador de cada tipo de mensaje.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tcp: termina correctamente los temporizadores para los sockets del kernel. Recibimos varios informes de syzbot sobre los temporizadores tcp que se activan después de que se han desmantelado las redes correspondientes. Afortunadamente, Josef Bacik pudo provocar el problema con más frecuencia y pudo probar un parche que escribí hace dos años. Cuando los sockets TCP están cerrados, llamamos a inet_csk_clear_xmit_timers() para "detener" los temporizadores. Se puede llamar a inet_csk_clear_xmit_timers() desde cualquier contexto, incluso cuando se mantiene el bloqueo del socket. Esta es la razón por la que usa sk_stop_timer(), también conocido como del_timer(). Esto significa que los cronómetros en curso podrían finalizar mucho más tarde. Para los sockets de usuario, esto está bien porque cada temporizador en ejecución tiene una referencia en el socket, y el socket de usuario tiene una referencia en las redes. Para los sockets del kernel, corremos el riesgo de que la red se libere antes de que se complete el temporizador, porque los sockets del kernel no mantienen referencias en las redes. Este parche agrega la función inet_csk_clear_xmit_timers_sync() que usa sk_stop_timer_sync() para garantizar que todos los temporizadores finalicen antes de que se libere el socket del kernel. Los módulos que utilizan sockets del kernel los cierran en su controlador netns exit(). También agregue el asistente sock_not_owned_by_me() para obtener soporte LOCKDEP: no se debe llamar a inet_csk_clear_xmit_timers_sync() mientras se mantiene el bloqueo del socket. Es muy posible que podamos revertir en el futuro la confirmación 3a58f13a881e ("net: rds: adquirir refcount en sockets TCP") que intentó resolver el problema solo en rds. (net/smc/af_smc.c y net/mptcp/subflow.c tienen código similar) Probablemente podamos eliminar las pruebas check_net() de tcp_out_of_resources() y __tcp_close() en el futuro.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: gro: corrige la transferencia de propiedad. Si los paquetes se agrupan con fraglist, es posible que se segmenten más adelante y continúen su viaje en la pila. En skb_segment_list esos skbs se pueden reutilizar tal cual. Esto es un problema ya que su destructor se eliminó en skb_gro_receive_list pero no la referencia a su socket, y luego no pueden quedar huérfanos. Solucione este problema eliminando también la referencia al socket. Por ejemplo, esto se podría observar, ¡BUG del kernel en include/linux/skbuff.h:3131! (skb_orphan) RIP: 0010:ip6_rcv_core+0x11bc/0x19a0 Seguimiento de llamadas: ipv6_list_rcv+0x250/0x3f0 __netif_receive_skb_list_core+0x49d/0x8f0 netif_receive_skb_list_internal+0x634/0xd40 napi_complete_done+0x1 d2/0x7d0 gro_cell_poll+0x118/0x1f0 Se encuentra una construcción similar en skb_gro_receive, aplique el mismo cambio allí.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: phy: micrel: corrige una posible desreferencia del puntero null en lan8814_get_sig_rx() y lan8814_get_sig_tx() ptp_parse_header() puede devolver NULL como ptp_header debido a un tipo de paquete anormal o a un paquete dañado. Corrija este error agregando ptp_header check. Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net/sched: corrige lockdep splat en qdisc_tree_reduce_backlog() qdisc_tree_reduce_backlog() se llama con el bloqueo de qdisc retenido, no con RTNL. Debemos usar qdisc_lookup_rcu() en lugar de qdisc_lookup() syzbot informó: ADVERTENCIA: uso sospechoso de RCU 6.1.74-syzkaller #0 No contaminado ---------------------- ------- ¡net/sched/sch_api.c:305 uso sospechoso de rcu_dereference_protected()! otra información que podría ayudarnos a depurar esto: rcu_scheduler_active = 2, debug_locks = 1 3 bloqueos mantenidos por udevd/1142: #0: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, en: rcu_lock_acquire include/linux /rcupdate.h:306 [en línea] #0: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, en: rcu_read_lock include/linux/rcupdate.h:747 [en línea] #0: ffffffff87c729a0 (rcu_read_lock ){....}-{1:2}, en: net_tx_action+0x64a/0x970 net/core/dev.c:5282 #1: ffff888171861108 (&sch->q.lock){+.-.}-{ 2:2}, en: spin_lock include/linux/spinlock.h:350 [en línea] #1: ffff888171861108 (&sch->q.lock){+.-.}-{2:2}, en: net_tx_action+0x754 /0x970 net/core/dev.c:5297 #2: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, en: rcu_lock_acquire include/linux/rcupdate.h:306 [en línea] #2: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, en: rcu_read_lock include/linux/rcupdate.h:747 [en línea] #2: ffffffff87c729a0 (rcu_read_lock){....}-{1:2} , en: qdisc_tree_reduce_backlog+0x84/0x580 net/sched/sch_api.c:792 stack backtrace: CPU: 1 PID: 1142 Comm: udevd Not tainted 6.1.74-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 25/01/2024 Seguimiento de llamadas: [] __dump_stack lib/dump_stack.c:88 [en línea] [] dump_stack_lvl+0x1b1/0x28f lib/dump_stack.c:106 [ ] dump_stack+0x15/0x1e lib/dump_stack.c:113 [] lockdep_rcu_suspicious+0x1b9/0x260 kernel/locking/lockdep.c:6592 [] qdisc_lookup+0xac/0x6f0 net/sched/sch_a foto.c: 305 [] qdisc_tree_reduce_backlog+0x243/0x580 net/sched/sch_api.c:811 [] pfifo_tail_enqueue+0x32c/0x4b0 net/sched/sch_fifo.c:51 [ ] qdisc_enqueue incluye/net/sch_generic .h:833 [en línea] [] netem_dequeue+0xeb3/0x15d0 net/sched/sch_netem.c:723 [] dequeue_skb net/sched/sch_generic.c:292 [en línea] [] qdisc_restart net/sched/sch_generic.c:397 [en línea] [] __qdisc_run+0x249/0x1e60 net/sched/sch_generic.c:415 [] qdisc_run+0xd6/0x260 include/net/pkt_sched.h:125 [] net_tx_action+0x7c9/0x970 net/core/dev.c:5313 [] __do_softirq+0x2bd/0x9bd kernel/softirq.c:616 [] invoke_softirq kernel/softirq.c: 447 [ en línea] [] __irq_exit_rcu+0xca/0x230 kernel/softirq.c:700 [] irq_exit_rcu+0x9/0x20 kernel/softirq.c:712 [] sysvec_apic_timer_interrupt+0 x42/0x90 arco/x86/ kernel/apic/apic.c:1107 [] asm_sysvec_apic_timer_interrupt+0x1b/0x20 arch/x86/include/asm/idtentry.h:656