Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: netfilter: nft_set_pipapo_avx2: agregar verificación irq_fpu_usable(), respaldo a una versión que no sea AVX2 Arturo informó este seguimiento: [709732.358791] ADVERTENCIA: CPU: 3 PID: 456 en arch/x86/kernel /fpu/core.c:128 kernel_fpu_begin_mask+0xae/0xe0 [709732.358793] Módulos vinculados en: binfmt_misc nft_nat nft_chain_nat nf_nat nft_counter nft_ct nf_tables nf_conntrack_netlink nfnetlink 8021q garp stp mrp ll c vrf intel_rapl_msr intel_rapl_common skx_edac nfit libnvdimm ipmi_ssif x86_pkg_temp_thermal intel_powerclamp coretemp crc32_pclmul mgag200 ghash_clmulni_intel drm_kms_helper cec aesni_intel drm libaes crypto_simd cryptd pegamento_helper mei_me dell_smbios iTCO_wdt evdev intel_pmc_bxt iTCO_vendor_support dcdbas pcspkr rapl dell_wmi_descriptor wmi_bmof sg i2c_algo_bit perro guardián mei acpi_ipmi ipmi_si botón nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ipmi_devintf ipmi_msghandler ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 dm_mod raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor sd_mod t10_pi crc_t10dif crct10dif_generic raid6_pq libcrc32c crc32c_generic raid1 raid0 multiruta lineal md_mod ahci libahci tg3 libata xhci_pci libphy xhci_hcd ptp usbcore crct10dif_pclmul crct10dif_common bnxt_en crc32c_intel scsi_mod [709732.358941] pps_core i2c_i801 lpc_ich i2c_ smbus wmi usb_common [709732.358957] CPU: 3 PID: 456 Comunicaciones: jbd2/dm-0-8 No contaminado 5.10 .0-0.bpo.5-amd64 #1 Debian 5.10.24-1~bpo10+1 [709732.358959] Nombre del hardware: Dell Inc. PowerEdge R440/04JN2K, BIOS 2.9.3 23/09/2020 [709732.358964] RIP: 0010:kernel_fpu_begin_mask+0xae/0xe0 [709732.358969] Código: ae 54 24 04 83 e3 01 75 38 48 8b 44 24 08 65 48 33 04 25 28 00 00 00 75 33 48 83 c4 10 5b c3 65 8a 05 5e 21 5e 76 84 c0 74 92 <0f> 0b eb 8e f0 80 4f 01 40 48 81 c7 00 14 00 00 e8 dd fb ff ff eb [709732.358972] RSP: 0018:ffffbb9700304740 EFLAGS: 00010202 [709 732.358976] RAX: 00000000000000001 RBX: 0000000000000003 RCX: 0000000000000001 [709732.358979] RDX: ffffbb9700304970 RSI: ffff922fe1952e00 RDI: 00000000000000003 [709732.358981] RBP: ffffbb9700304970 R08: ffff922fc868a600 R09: ffff922fc711e462 [709732.358984] R10: 000000000000005f R11: ffff922ff0b27180 R12: ffffbb9700304960 [709732.358987] R13: ffffbb9700304b08 R14: ffff922fc664b6c8 R15: ffff922fc664b660 [ 709732.358990] FS: 0000000000000000(0000) GS:ffff92371fec0000(0000) knlGS:0000000000000000 [709732.358993] CS: 0010 DS: 0000 ES: 0000 CR0: 00 00000080050033 [709732.358996] CR2: 0000557a6655bdd0 CR3: 000000026020a001 CR4: 00000000007706e0 [709732.358999] DR0: 00000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [709732.359001] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [709732.3590 03] PKRU: 55555554 [709732.359005] Seguimiento de llamadas: [709732.359009] [709732.359035] nft_pipapo_avx2_lookup+0x4c/0x1cba [nf_tables] [709732.359046] ? sched_clock+0x5/0x10 [709732.359054] ? sched_clock_cpu+0xc/0xb0 [709732.359061] ? record_times+0x16/0x80 [709732.359068] ? plist_add+0xc1/0x100 [709732.359073] ? psi_group_change+0x47/0x230 [709732.359079] ? skb_clone+0x4d/0xb0 [709732.359085] ? enqueue_task_rt+0x22b/0x310 [709732.359098] ? bnxt_start_xmit+0x1e8/0xaf0 [bnxt_es] [709732.359102] ? paquete_rcv+0x40/0x4a0 [709732.359121] nft_lookup_eval+0x59/0x160 [nf_tables] [709732.359133] nft_do_chain+0x350/0x500 [nf_tables] [709732.359152] ? nft_lookup_eval+0x59/0x160 [nf_tables] [709732.359163] ? nft_do_chain+0x364/0x500 [nf_tables] [709732.359172]? fib4_rule_action+0x6d/0x80 [709732.359178] ? fib_rules_lookup+0x107/0x250 [709732.359184] nft_nat_do_chain+0x8a/0xf2 [nft_chain_nat] [709732.359193] nf_nat_inet_fn+0xea/0x210 [nf_nat] [709732.359202 ] nf_nat_ipv4_out+0x14/0xa0 [nf_nat] [709732.359207] nf_hook_slow+0x44/0xc0 [709732.359214] salida_ip +0xd2/0x100 [709732.359221] ? __ip_finish_output+0x210/0x210 [709732.359226] ip_forward+0x37d/0x4a0 [709732.359232] ? ip4_key_hashfn+0xb0/0xb0 [709732.359238] ip_subli ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/sched: fq_pie: arregla el acceso OOB en la ruta de tráfico el siguiente script: # tc qdisc add dev eth0 handle 0x1 root fq_pie flows 2 # tc qdisc add dev eth0 clsact # tc filtrar agregar dev eth0 salida matchall acción skbedit prioridad 0x10002 # ping 192.0.2.2 -I eth0 -c2 -w1 -q produce el siguiente símbolo: ERROR: KASAN: slab-out-of-bounds in fq_pie_qdisc_enqueue+0x1314/0x19d0 [sch_fq_pie] Leer de tamaño 4 en la dirección ffff888171306924 por tarea ping/942 CPU: 3 PID: 942 Comm: ping Not tainted 5.12.0+ #441 Nombre de hardware: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+ 0f1aadab 01/04/2014 Seguimiento de llamadas: dump_stack+0x92/0xc1 print_address_description.constprop.7+0x1a/0x150 kasan_report.cold.13+0x7f/0x111 fq_pie_qdisc_enqueue+0x1314/0x19d0 [sch_fq_pie] __dev_queue_x mit+0x1034/0x2b10 ip_finish_output2+0xc62/0x2120 __ip_finish_output+0x553/0xea0 ip_output+0x1ca/0x4d0 ip_send_skb+0x37/0xa0 raw_sendmsg+0x1c4b/0x2d00 sock_sendmsg+0xdb/0x110 __sys_sendto+0x1d7/0x2b0 __x64_sys_s endto+0xdd/0x1b0 do_syscall_64+0x3c/0x80 Entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7fe69735c3eb Código: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 f3 0f 1e fa 48 8d 05 75 42 2c 00 41 89 ca 8b 00 85 c0 75 14 b8 2c 00 00 00 0f 05 <48 > 3d 00 f0 ff ff 77 75 c3 0f 1f 40 00 41 57 4d 89 c7 41 56 41 89 RSP: 002b:00007fff06d7fb38 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 000055e961413700 RCX: 00007fe69735c3eb RDX: 0000000000000040 RSI: 000055e961413700 RDI: 0000000000000003 RBP: 0000000000000040 R08: 000055e961410500 R09: 00000000000000010 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff06d81260 R13: 00007fff06d7fb40 R14: 00007fff06d7fc30 R15: 000055e96140f0a0 Asignado por la tarea 917: kasan_save_stack+0x19/0x40 __kasan_kmalloc+0x7f/0xa0 __kmalloc_node+0x139/0x280 fq_pie_init+0x555/0x8e8 [ sch_fq_pie] qdisc_create+0x407/0x11b0 tc_modify_qdisc+0x3c2/0x17e0 rtnetlink_rcv_msg+0x346/0x8e0 netlink_rcv_skb+0x120/0x380 netlink_unicast+0x439/0x630 netlink_sendmsg+0x719/ 0xbf0 sock_sendmsg+0xe2/0x110 ____sys_sendmsg+0x5ba/0x890 ___sys_sendmsg+0xe9/0x160 __sys_sendmsg+0xd3 /0x170 do_syscall_64+0x3c/0x80 Entry_SYSCALL_64_after_hwframe+0x44/0xae La dirección con errores pertenece al objeto en ffff888171306800 que pertenece al caché kmalloc-256 de tamaño 256. La dirección con errores se encuentra 36 bytes a la derecha de la región de 256 bytes [ffff888171306 800, ffff888171306900) La dirección del error pertenece a la página: página:00000000bcfb624e refcount:1 mapcount:0 mapeo:0000000000000000 index:0x0 pfn:0x171306 head:00000000bcfb624e order:1 composite_mapcount:0 flags: 0x17ffffc00 10200(losa|cabeza|nodo=0|zona =2|lastcpupid=0x1fffff) raw: 0017ffffc0010200 dead000000000100 dead000000000122 ffff888100042b40 raw: 000000000000000000 0000000000100010 00000001ffffffff 0000000000000000 página volcada porque: kasan: se detectó mal acceso Estado de la memoria alrededor de la dirección con errores: ffff888171306800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888171306880: 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc >ffff888171306900: fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ffff888 171306980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff888171306a00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb corrige la ruta de tráfico fq_pie para evitar seleccionar 'q->flows + q->flows_cnt' como un flujo válido: es una dirección más allá de la memoria asignada.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: s390/dasd: agregar función de disciplina faltante. Se corrigió falla con excepción de operación ilegal en dasd_device_tasklet. El commit b72949328869 ("s390/dasd: Prepárese para el manejo de eventos de ruta adicional") cambió el nombre de la función verificar_ruta para ECKD pero no para Logística de Amazon y DIAG. Esto provoca pánico cuando se llama a la función de verificación de ruta para un dispositivo FBA o DIAG. Para solucionarlo, defina una función contenedora para dasd_generic_verify_path().

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: iommu/vt-d: corrige la fuga de sysfs en alloc_iommu() iommu_device_sysfs_add() se llama antes, por lo que debe limpiarse en caso de errores posteriores.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: target: core: Evite smp_processor_id() en código interrumpible Se observó el mensaje de ERROR "ERROR: usar smp_processor_id() en código interrumpible [00000000]" para dispositivos TCMU con configuración de kernel DEBUG_PREEMPT. El mensaje se observó cuando se ejecutó blktests block/005 en dispositivos TCMU con backend fileio o usuario:zbc [1]. La confirmación 1130b499b4a7 ("scsi: target: tcm_loop: Use el asistente de envío LIO wq cmd") desencadenó el síntoma. La confirmación modificó la cola de trabajo para manejar comandos y cambió 'current->nr_cpu_allowed' en la llamada a smp_processor_id(). El mensaje también se observó al apagar el sistema cuando los dispositivos TCMU no se limpiaron [2]. La función smp_processor_id() fue llamada en la cola de trabajo del host SCSI para el manejo de abortos y activó el mensaje de ERROR. Este síntoma se observó independientemente de la confirmación 1130b499b4a7 ("scsi: target: tcm_loop: Use el asistente de envío LIO wq cmd"). Para evitar la verificación del código interrumpible en smp_processor_id(), obtenga el ID de la CPU con raw_smp_processor_id() en su lugar. El ID de la CPU se utiliza para mejorar el rendimiento, luego el movimiento del subproceso a otra CPU no afectará el código. [1] [56.468103] ejecute blktests block/005 el 2021-05-12 14:16:38 [57.369473] check_preemption_disabled: 85 devoluciones de llamada suprimidas [57.369480] ERROR: usar smp_processor_id() en código preferente [00000000]: fio/151 1 [ 57.369506] ERROR: usar smp_processor_id() en código interrumpible [00000000]: fio/1510 [57.369512] ERROR: usar smp_processor_id() en código interrumpible [00000000]: fio/1506 [57.369552] la persona que llama es __target_init_cmd+0 x157/0x170 [objetivo_core_mod] [ 57.369606] CPU: 4 PID: 1506 Comm: fio Not tainted 5.13.0-rc1+ #34 [ 57.369613] Nombre del hardware: Fabricante del sistema Nombre del producto del sistema/PRIME Z270-A, BIOS 1302 15/03/2018 [ 57.369617] Seguimiento de llamadas : [57.369621] ERROR: usar smp_processor_id() en código interrumpible [00000000]: fio/1507 [57.369628] dump_stack+0x6d/0x89 [57.369642] check_preemption_disabled+0xc8/0xd0 [57.369628] la persona que llama es __ target_init_cmd+0x157/0x170 [target_core_mod] [ 57.369655] __target_init_cmd+0x157/0x170 [target_core_mod] [ 57.369695] target_init_cmd+0x76/0x90 [target_core_mod] [ 57.369732] tcm_loop_queuecommand+0x109/0x210 [tcm_loop] [ 57 .369744] scsi_queue_rq+0x38e/0xc40 [ 57.369761] __blk_mq_try_issue_directly+0x109/0x1c0 [ 57.369779 ] blk_mq_try_issue_directly+0x43/0x90 [ 57.369790] blk_mq_submit_bio+0x4e5/0x5d0 [ 57.369812] submit_bio_noacct+0x46e/0x4e0 [ 57.369830] __blkdev_direct_IO_simple+0x1a3/0x2 d0 [57.369859]? set_init_blocksize.isra.0+0x60/0x60 [ 57.369880] generic_file_read_iter+0x89/0x160 [ 57.369898] blkdev_read_iter+0x44/0x60 [ 57.369906] new_sync_read+0x102/0x170 [ 57.369929 ] vfs_read+0xd4/0x160 [ 57.369941] __x64_sys_pread64+0x6e/0xa0 [ 57.369946] ? lockdep_hardirqs_on+0x79/0x100 [ 57.369958] do_syscall_64+0x3a/0x70 [ 57.369965] Entry_SYSCALL_64_after_hwframe+0x44/0xae [ 57.369973] RIP: 0033:0x7f7ed4c1399f [ 5 7.369979] Código: 08 89 3c 24 48 89 4c 24 18 e8 7d f3 ff ff 4c 8b 54 24 18 48 8b 54 24 10 41 89 c0 48 8b 74 24 08 8b 3c 24 b8 11 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 04 24 e8 cd f3 ff ff 48 8b [ 57.369983] RSP: 002b:00007ffd7918c580 EFLAGS: 00000293 ORIG_RAX: 0000000000000011 [ 57.369990] RAX: fffffffffffffffda RBX: 00000000015b4540 RCX: 00 007f7ed4c1399f [ 57.369993] RDX: 0000000000001000 RSI: 00000000015de000 RDI: 000000000000000009 [ 57.369996] RBP: 00000000015b4540 R08: 000 0000000000000 R09: 0000000000000001 [ 57.369999] R10: 0000000000e5c000 R11: 0000000000000293 R12: 00007f7eb5269a70 [ 57.370002] R13: 00000000000000000 R14: 000000000000 1000 R15: 00000000015b4568 [57.370031] CPU: 7 PID: 1507 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: NFSv4: corrige una desreferencia de puntero NULL en pnfs_mark_matching_lsegs_return(). Confirme los cambios de144ff4234f _pnfs_return_layout() para llamar a pnfs_mark_matching_lsegs_return() pasando NULL como argumento de estructura pnfs_layout_range. Desafortunadamente, pnfs_mark_matching_lsegs_return() no verifica si tenemos un valor aquí antes de eliminar la referencia a él, lo que provoca un error. Puedo alcanzar este bloqueo de manera consistente cuando ejecuto pruebas básicas de Connectathon en NFS v4.1/v4.2 contra Ontap.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: NFC: nci: corrige la pérdida de memoria en nci_allocate_device nfcmrvl_disconnect no logra liberar el campo hci_dev en la estructura nci_dev. Solucione este problema liberando hci_dev en nci_free_device. ERROR: pérdida de memoria, objeto sin referencia 0xffff888111ea6800 (tamaño 1024): comunicación "kworker/1:0", pid 19, jiffies 4294942308 (edad 13.580 s) volcado hexadecimal (primeros 32 bytes): 00 00 00 00 00 00 00 00 00 60 fd 0c 81 88 ff ff .........`...... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ............. ... seguimiento: [<000000004bc25d43>] kmalloc include/linux/slab.h:552 [en línea] [<000000004bc25d43>] kzalloc include/linux/slab.h:682 [en línea] [<000000004bc25d43>] nci_hci_allocate+0x21/ 0xd0 net/nfc/nci/hci.c:784 [<00000000c59cff92>] nci_allocate_device net/nfc/nci/core.c:1170 [en línea] [<00000000c59cff92>] nci_allocate_device+0x10b/0x160 net/nfc/nci/core. c:1132 [<00000000006e0a8e>] nfcmrvl_nci_register_dev+0x10a/0x1c0 controladores/nfc/nfcmrvl/main.c:153 [<000000004da1b57e>] nfcmrvl_probe+0x223/0x290 controladores/nfc/nfcmr vl/usb.c:345 [<00000000d506aed9>] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396 [<00000000bc632c92>] very_probe+0x159/0x4a0 drivers/base/dd.c:554 [<00000000f5009125>] driver_probe_device+0x84/0x100 drivers/base/dd .c:740 [<000000000ce658ca>] __device_attach_driver+0xee/0x110 controladores/base/dd.c:846 [<000000007067d05f>] bus_for_each_drv+0xb7/0x100 controladores/base/bus.c:431 [<00000000f8e1337 2>] __device_attach+0x122 /0x250 controladores/base/dd.c:914 [<000000009cf68860>] bus_probe_device+0xc6/0xe0 controladores/base/bus.c:491 [<00000000359c965a>] dispositivo_add+0x5be/0xc30 controladores/base/core.c:3109 [ <00000000086e4bd3>] usb_set_configuration+0x9d9/0xb90 controladores/usb/core/message.c:2164 [<00000000ca036872>] usb_generic_driver_probe+0x8c/0xc0 controladores/usb/core/generic.c:238 [<00000000d40d3 6f6>] dispositivo_probe_usb+0x5c/ 0x140 controladores/usb/core/driver.c:293 [<00000000bc632c92>] very_probe+0x159/0x4a0 controladores/base/dd.c:554

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: dsa: corrige un bloqueo si ->get_sset_count() falla. Si ds->ops->get_sset_count() falla, entonces "count" es un código de error negativo como - EOPNOTSUPP. Debido a que "i" es un int sin signo, el código de error negativo se promociona a un valor muy alto y el bucle corromperá la memoria hasta que el sistema falle. Solucione este problema buscando códigos de error y cambiando el tipo de "i" a solo int.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: dsa: mt7530: corregir fugas de tráfico de VLAN El campo PCR_MATRIX se configuró en todos 1 cuando el filtrado de VLAN está habilitado, pero no se restableció cuando está deshabilitado, lo que puede causar fugas de tráfico: enlace ip agregar puente tipo br0 vlan_filtering 1 enlace ip agregar puente tipo br1 vlan_filtering 1 conjunto de enlaces ip swp0 master br0 conjunto de enlaces ip swp1 maestro br1 conjunto de enlaces ip br0 puente tipo vlan_filtering 0 conjunto de enlaces ip br1 tipo puente vlan_filtering 0 # tráfico en br0 y br1 comenzarán a filtrarse entre sí. Como port_bridge_{add,del} ha configurado PCR_MATRIX correctamente, elimine la escritura PCR_MATRIX de mt7530_port_set_vlan_aware.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: spi: spi-fsl-dspi: reparar una fuga de recursos en una ruta de manejo de errores 'dspi_request_dma()' debe deshacerse mediante una llamada 'dspi_release_dma()' en la ruta de manejo de errores de la función de sonda, como ya se hizo en la función de eliminación

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tipc: skb_linearize el skb principal al volver a ensamblar mensajes No es una buena idea agregar el frag skb a la frag_list de un skb si la frag_list ya tiene skbs de otro lugar, como por ejemplo este skb fue creado por pskb_copy() donde se clonó frag_list (todos los skbs que contenía fueron skb_get'ed) y se compartió con varios skbs. Sin embargo, el nuevo fragmento skb adjunto solo debería haber sido visto por el skb actual. De lo contrario, causará uso después de fallas gratuitas, ya que varios skbs ven este fragmento skb agregado, pero solo se llamó a skb_get una vez. Lo mismo sucede con un skb actualizado por pskb_may_pull() con un skb skb_cloned. Li Shuang ha informado de bastantes fallos causados por esto al realizar pruebas en dispositivos macvlan: [] ¡ERROR del kernel en net/core/skbuff.c:1970! [] Seguimiento de llamadas: [] skb_clone+0x4d/0xb0 [] macvlan_broadcast+0xd8/0x160 [macvlan] [] macvlan_process_broadcast+0x148/0x150 [macvlan] [] Process_one_work+0x1a7/0x360 [] trabajador_thread+0x30/0x390 [] ERROR del kernel en mm/usercopy.c:102! [] Seguimiento de llamadas: [] __check_heap_object+0xd3/0x100 [] __check_object_size+0xff/0x16b [] simple_copy_to_iter+0x1c/0x30 [] __skb_datagram_iter+0x7d/0x310 [] __skb_datagram_iter+0x2a5/0x310 [] skb_copy_datagram _iter+0x3b/0x90 [] tipc_recvmsg +0x14a/0x3a0 [tipc] [] ____sys_recvmsg+0x91/0x150 [] ___sys_recvmsg+0x7b/0xc0 [] ¡ERROR del kernel en mm/slub.c:305! [] Seguimiento de llamadas: [] [] kmem_cache_free+0x3ff/0x400 [] __netif_receive_skb_core+0x12c/0xc40 [] ? kmem_cache_alloc+0x12e/0x270 [] netif_receive_skb_internal+0x3d/0xb0 [] ? get_rx_page_info+0x8e/0xa0 [be2net] [] be_poll+0x6ef/0xd00 [be2net] [] ? irq_exit+0x4f/0x100 [] net_rx_action+0x149/0x3b0 ... Este parche es para solucionarlo linealizando el skb principal si tiene frag_list configurado en tipc_buf_append(). Tenga en cuenta que elegimos hacer esto antes de llamar a skb_unshare(), ya que __skb_linearize() evitará skb_copy(). Además, tampoco podemos simplemente eliminar frag_list desde el principio.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tipc: espere y salga hasta que todas las colas de trabajo estén terminadas. En algunos hosts, se podría desencadenar un bloqueo simplemente repitiendo estos comandos varias veces: # modprobe tipc # tipc portador habilitar media udp nombre UDP1 localip 127.0.0.1 # rmmod tipc [] ERROR: no se puede manejar la solicitud de paginación del kernel en ffffffffc096bb00 [] Cola de trabajo: eventos 0xffffffffc096bb00 [] Seguimiento de llamadas: []? proceso_one_work+0x1a7/0x360 []? hilo_trabajador+0x30/0x390 []? crear_trabajador+0x1a0/0x1a0 []? kthread+0x116/0x130 []? kthread_flush_work_fn+0x10/0x10 []? ret_from_fork+0x35/0x40 Al retirar el módulo TIPC, el calcetín del túnel UDP se retrasará para liberarse en una cola de trabajo, ya que sock_release() no se puede realizar en rtnl_lock(). Si la cola de trabajo está programada para ejecutarse después de eliminar el módulo TIPC, el kernel fallará porque el código de la función de cola de trabajo cleanup_beareri() ya no existe al intentar invocarlo. Para solucionarlo, este parche introduce un miembro wq_count en tipc_net para rastrear el número de colas de trabajo programadas y esperar y salir hasta que todas las colas de trabajo estén terminadas en tipc_exit_net().