Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: paquete: anotar carreras de datos alrededor de ignore_outgoing ignore_outgoing se lee sin bloqueo desde dev_queue_xmit_nit() y paquete_getsockopt() Agregue las anotaciones READ_ONCE()/WRITE_ONCE() apropiadas. syzbot informó: ERROR: KCSAN: carrera de datos en dev_queue_xmit_nit/packet_setsockopt escribir en 0xffff888107804542 de 1 bytes por tarea 22618 en la CPU 0: paquete_setsockopt+0xd83/0xfd0 net/packet/af_packet.c:4003 do_sock_setsockopt net/socket.c :2311 [ en línea] __sys_setsockopt+0x1d8/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 [en línea] __se_sys_setsockopt net/socket.c:2340 [en línea] __x64_sys_setsockopt+0x66/0x80 :2340 do_syscall_64+ 0xd3/0x1d0 Entry_SYSCALL_64_after_hwframe+0x6d/0x75 leído en 0xffff888107804542 de 1 byte por tarea 27 en la CPU 1: dev_queue_xmit_nit+0x82/0x620 net/core/dev.c:2248 xmit_one net/core/dev.c:3527 línea] dev_hard_start_xmit+ 0xcc/0x3f0 net/core/dev.c:3547 __dev_queue_xmit+0xf24/0x1dd0 net/core/dev.c:4335 dev_queue_xmit include/linux/netdevice.h:3091 [en línea] batadv_send_skb_packet+0x264/0x300 net/batman-adv/ send.c:108 batadv_send_broadcast_skb+0x24/0x30 net/batman-adv/send.c:127 batadv_iv_ogm_send_to_if net/batman-adv/bat_iv_ogm.c:392 [en línea] batadv_iv_ogm_emit net/batman-adv/bat_iv_ogm.c:420 [en línea ] batadv_iv_send_outstanding_bat_ogm_packet+0x3f0/0x4b0 net/batman-adv/bat_iv_ogm.c:1700 Process_one_work kernel/workqueue.c:3254 [en línea] Process_scheduled_works+0x465/0x990 kernel/workqueue.c:3335 trabajador_thread+0x526/0x730 núcleo/cola de trabajo.c :3416 kthread+0x1d1/0x210 kernel/kthread.c:388 ret_from_fork+0x4b/0x60 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243 valor cambiado: 0x00 -> 0x01 Reportado por Kernel Concurrency Sanitizer en: CPU: 1 PID: 27 Comm: kworker/u8:1 Contaminado: GW 6.8.0-syzkaller-08073-g480e035fc4c7 #0 Nombre de hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 29/02/2024 Cola de trabajo: bat_events batadv_iv_send_outstanding_bat_ogm_packet

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: hsr: corrigió el acceso a valores uninit en hsr_get_node() KMSAN informó el siguiente problema de acceso a valores uninit [1]: ============== ======================================= ERROR: KMSAN: valor uninit en hsr_get_node+0xa2e /0xa40 net/hsr/hsr_framereg.c:246 hsr_get_node+0xa2e/0xa40 net/hsr/hsr_framereg.c:246 fill_frame_info net/hsr/hsr_forward.c:577 [en línea] hsr_forward_skb+0xe12/0x30e0 net/hsr/hsr_forward.c :615 hsr_dev_xmit+0x1a1/0x270 net/hsr/hsr_device.c:223 __netdev_start_xmit include/linux/netdevice.h:4940 [en línea] netdev_start_xmit include/linux/netdevice.h:4954 [en línea] xmit_one net/core/dev.c :3548 [en línea] dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564 __dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349 dev_queue_xmit include/linux/netdevice.h:3134 [en línea] paquete_xmit+0x9c/ 0x6b0 net/packet/af_packet.c:276 paquete_snd net/packet/af_packet.c:3087 [en línea] paquete_sendmsg+0x8b1d/0x9f30 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [en línea] __sock_sendmsg neto /socket.c:745 [en línea] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [en línea] __se_sys_sendto net/socket.c:2199 [en línea] __x64_sys_sendto+0x125/0x1c0 socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit se creó en slab_post_alloc_hook+0x129/ 0xa70 mm/slab.h: 768 slab_alloc_node mm/slub.c: 3478 [inline] kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c: 3523 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c: 560 __b.biloc. 740 net/core/skbuff.c:651 alloc_skb include/linux/skbuff.h:1286 [en línea] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2787 paquete_alloc_skb net/packet/af_packet.c:2936 [en línea] paquete_snd net/packet/af_packet.c:3030 [en línea] paquete_sendmsg+0x70e8/0x9f30 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [en línea ] __sock_sendmsg net/socket.c:745 [en línea] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [en línea] __se_sys_sendto net/socket.c:2199 [en línea] x125/ 0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x63/0x6b CPU: 1 PID: 5033 Comm: syz-executor334 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 17/11/2023 ============== ======================================== Si el campo ID de tipo de paquete en el encabezado Ethernet es ETH_P_PRP o ETH_P_HSR, pero no va seguido de una etiqueta HSR, hsr_get_skb_sequence_nr() lee un valor no válido como un número de secuencia. Esto causa el problema anterior. Este parche soluciona el problema al devolver NULL si el encabezado Ethernet no va seguido de una etiqueta HSR.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tcp: corrige el manejo de refcnt en __inet_hash_connect(). syzbot informó una advertencia en sk_nulls_del_node_init_rcu(). La confirmación 66b60b0c8c4a ("dccp/tcp: Unhash sk de ehash para falla de asignación de tb2 después de check_estalblished().") intentó solucionar un problema por el cual un socket no conectado ocupa una entrada de ehash cuando falla la asignación de bhash2. En tal caso, necesitamos revertir los cambios realizados por check_establecido(), que no retiene refcnt al insertar el socket en ehash. Entonces, para revertir el cambio, necesitamos __sk_nulls_add_node_rcu() en lugar de sk_nulls_add_node_rcu(). De lo contrario, sock_put() provocará un desbordamiento insuficiente y filtrará el socket. [0]: ADVERTENCIA: CPU: 0 PID: 23948 en include/net/sock.h:799 sk_nulls_del_node_init_rcu+0x166/0x1a0 include/net/sock.h:799 Módulos vinculados en: CPU: 0 PID: 23948 Comm: syz- executor.2 No contaminado 6.8.0-rc6-syzkaller-00159-gc055fc00c07b #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 25/01/2024 RIP: 0010:sk_nulls_del_node_init_rcu+0x166/0x1a0 include/net/ calcetín.h:799 Código: e8 7f 71 c6 f7 83 fb 02 7c 25 e8 35 6d c6 f7 4d 85 f6 0f 95 c0 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 1b 6d c6 f7 90 < 0f> 0b 90 eb b2 e8 10 6d c6 f7 4c 89 e7 be 04 00 00 00 e8 63 e7 d2 RSP: 0018:ffffc900032d7848 EFLAGS: 00010246 RAX: ffffffff89cd0035 RBX: 00001 RCX: 0000000000040000 RDX: ffffc90004de1000 RSI: 000000000003ffff RDI: 0000000000040000 RBP : 1ffff1100439ac26 R08: ffffffff89ccffe3 R09: 1ffff1100439ac28 R10: dffffc0000000000 R11: ffffed100439ac29 R12: ffff888021cd6140 R13: dffffc0000000000 ff ff88802a9bf5c0 R15: ffff888021cd6130 FS: 00007f3b823f16c0(0000) GS:ffff8880b9400000(0000) knlGS:00000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f3b823f0ff8 CR3: 000000004674a000 CR4: 00000000003506f0 DR0: 00000000000000000 DR1: 0000000000000000 DR2: 000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: __inet_hash_connect+0x140f/0x20b0 net/ipv4/inet_hashtables.c:1139 dccp_v6_connect+0xcb9/0x1480 net/dccp/ipv6.c:956 __inet_stream_connect+0x262/0xf30 net/ipv4/af_inet.c:678 inet_stream_connect+0x65/0xa0 net/ipv4/af_inet.c:749 __sys_connect_file net/socket.c:2048 [en línea] __sys_connect+0x2df/0x310 net/socket.c:2065 __do_sys_connect net/socket.c:2075 [en línea] __se_sys_connect net/socket.c:2072 [en línea] __x64_sys_connect+0x7a/0x90 net/socket.c:2072 +0xf9/0x240 Entry_SYSCALL_64_after_hwframe+0x6f/0x77 RIP: 0033:0x7f3b8167dda9 Código: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 4 8 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 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f3b823f10c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002a RAX: ffffffffffffffda RBX: 00007f3b817abf80 RCX : 00007f3b8167dda9 RDX: 000000000000001c RSI: 0000000020000040 RDI: 0000000000000003 RBP: 00007f3b823f1120 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 0000000000000000b R14: 00007f3b817abf80 00007ffd3beb57b8

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: rds: tcp: Se corrige el use-after-free de red en reqsk_timer_handler(). syzkaller informó una advertencia de netns tracker [0] seguida de KASAN splat [1] y otra advertencia de ref tracker [1]. syzkaller no pudo encontrar una reproducción, pero en el registro, la única secuencia sospechosa fue la siguiente: 18:26:22 ejecutando el programa 1: r0 = socket$inet6_mptcp(0xa, 0x1, 0x106) ... connect$inet6(r0, &(0x7f0000000080)={0xa, 0x4001, 0x0, @loopback}, 0x1c) (async) Lo notable aquí es 0x4001 en connect(), que es RDS_TCP_PORT. Entonces, el escenario sería: 1. unshare(CLONE_NEWNET) crea un oyente tcp por red en rds_tcp_listen_init(). 2. syz-executor se conecta a él y crea una solicitud. 3. syz-executor sale () inmediatamente. 4. La red está desmantelada. [0] 5. Se activa el temporizador de reqsk y se produce UAF mientras se libera reqsk. [1] 6. El oyente se libera después del período de gracia de RCU. [2] Básicamente, reqsk supone que el oyente garantiza la seguridad de la red hasta que expiren todos los temporizadores de reqsk manteniendo el refcount del oyente. Sin embargo, este no fue el caso de los sockets del kernel. La confirmación 740ea3c4a0b2 ("tcp: Limpiar la solicitud del oyente del kernel en inet_twsk_purge()") solucionó este problema solo para ehash por red. Apliquemos la misma solución para el ehash global. [0]: ref_tracker: net notrefcnt@0000000065449cc3 tiene 1/1 usuarios en sk_alloc (./include/net/net_namespace.h:337 net/core/sock.c:2146) inet6_create (net/ipv6/af_inet6.c:192 net/ipv6/af_inet6.c:119) __sock_create (net/socket.c:1572) rds_tcp_listen_init (net/rds/tcp_listen.c:279) rds_tcp_init_net (net/rds/tcp.c:577) ops_init (net/core/ net_namespace.c:137) setup_net (net/core/net_namespace.c:340) copy_net_ns (net/core/net_namespace.c:497) create_new_namespaces (kernel/nsproxy.c:110) unshare_nsproxy_namespaces (kernel/nsproxy.c:228 ( discriminador 4)) ksys_unshare (kernel/fork.c:3429) __x64_sys_unshare (kernel/fork.c:3496) 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) ... ADVERTENCIA: CPU: 0 PID: 27 en lib/ref_tracker.c:179 ref_tracker_dir_exit (lib/ref_tracker.c:179) [1]: ERROR: KASAN: slab-use-after-free en inet_csk_reqsk_queue_drop (./include/net/inet_hashtables.h:180 net/ipv4/inet_connection_sock.c:952 net/ipv4/inet_connection_sock.c:966) Lectura de tamaño 8 en la dirección ffff88801b370400 mediante el intercambiador de tareas /0/0 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 (lib/dump_stack .c:107 (discriminador 1)) print_report (mm/kasan/report.c:378 mm/kasan/report.c:488) kasan_report (mm/kasan/report.c:603) inet_csk_reqsk_queue_drop (./include/net/ inet_hashtables.h:180 net/ipv4/inet_connection_sock.c:952 net/ipv4/inet_connection_sock.c:966) reqsk_timer_handler (net/ipv4/inet_connection_sock.c:979 net/ipv4/inet_connection_sock.c:1092) call_timer_fn (./arch /x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/timer.h:127 kernel/time/timer.c:1701) __run_timers.part. 0 (kernel/time/timer.c:1752 kernel/time/timer.c:2038) run_timer_softirq (kernel/time/timer.c:2053) __do_softirq (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/irq.h:142 kernel/softirq.c:554) irq_exit_rcu (kernel/softirq.c:427 kernel/softirq.c:632 kernel/ softirq.c:644) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1076 (discriminator 14)) Asignado por la tarea 258 en la CPU 0 a 83.612050s: kasan_save_stack (mm/kasan/common.c :48) kasan_save_track (mm/kasan/common.c:68) __kasan_slab_alloc (mm/kasan/common.c:343) kmem_cache_alloc (mm/slub.c:3813 mm/slub.c:3860 mm/slub.c:3867 ) copy_net_ns (./include/linux/slab.h:701 net/core/net_namespace.c:421 net/core/net_namespace.c:480) create_new_namespaces (kernel/nsproxy.c:110) unshare_nsproxy_name ---truncado-- -

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: spi: lpspi: evita el posible use-after-free en probe() fsl_lpspi_probe() está asignando/eliminando memoria manualmente con spi_alloc_host()/spi_alloc_target(), pero usa devm_spi_register_controller() . En caso de error después de la última llamada, la memoria se liberará explícitamente en la función de sonda mediante la llamada a spi_controller_put(), pero la administración "devm" externa a probe() la utilizará después (spi_unregister_controller() <- devm_spi_unregister() a continuación). No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 0000000000000070... Rastreo de llamadas: kernfs_find_ns kernfs_find_and_get_ns sysfs_remove_group sysfs_remove_groups device_remove_attrs device_del spi_unregister_controller devm_spi_unregister release_nodes devres_release _todos realmente_probe driver_probe_device __device_attach_driver bus_for_each_drv __device_attach dispositivo_initial_probe bus_probe_device deferred_probe_work_func proceso_one_work trabajador_hilo kthread ret_from_fork

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: comedi: comedi_8255: Corregir error en la inicialización del subdispositivo La refactorización realizada en el commit 5c57b1ccecc7 ("comedi: comedi_8255: Rework subdevice inicializationfunctions") a la inicialización del campo io de la estructura subdev_8255_private se rompió todas las tarjetas que utilizan el módulo drivers/comedi/drivers/comedi_8255.c. Antes de 5c57b1ccecc7, __subdev_8255_init() inicializaba el campo io en la estructura subdev_8255_private recién asignada a la devolución de llamada no NULL proporcionada a la función; de lo contrario, usaba un parámetro de marca para seleccionar entre subdev_8255_mmio y subdev_8255_io. La refactorización eliminó esa lógica y la bandera, ya que subdev_8255_mm_init() y subdev_8255_io_init() ahora pasan explícitamente subdev_8255_mmio y subdev_8255_io respectivamente a __subdev_8255_init(), solo __subdev_8255_init() nunca establece spriv->io en la devolución de llamada proporcionada. Que spriv->io sea NULL conduce a un ERROR posterior: ERROR: desreferencia del puntero NULL del núcleo, dirección: 0000000000000000 PGD 0 P4D 0 Ups: 0010 [#1] SMP PTI CPU: 1 PID: 1210 Comm: systemd-udevd No contaminado 6.7 .3-x86_64 #1 Nombre de hardware: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX RIP: 0010:0x0 Código: No se puede acceder a los bytes del código de operación en 0xffffffffffffffd6. RSP: 0018: FFFFA3F1C02D7B78 EFLAGS: 00010202 RAX: 000000000000000000 RBX: FFFF91F847AEFD00 RCX: 00000000000000009B RDX: 00000000000003 RSI: 00000000000001 RDI: FFF91F840F6FC00 R08: 000000000000000000 R09: 000000000000000001 R10: 000000000000000000 R11: 000000000000005F R12: 0000000000000000000000000000: 0000000000000000 RUBI R15: ffff91f847ce6ba8 FS: 00007f72f4e8f500(0000) GS:ffff91f8d5c80000(0000) knlGS:00000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050 033 CR2: ffffffffffffffd6 CR3: 000000010540e000 CR4: 00000000000406f0 Seguimiento de llamadas: ? __die_body+0x15/0x57 ? page_fault_oops+0x2ef/0x33c? insert_vmap_area.constprop.0+0xb6/0xd5? alloc_vmap_area+0x529/0x5ee? exc_page_fault+0x15a/0x489? asm_exc_page_fault+0x22/0x30 __subdev_8255_init+0x79/0x8d [comedi_8255] pci_8255_auto_attach+0x11a/0x139 [8255_pci] comedi_auto_config+0xac/0x117 [comedi] ? __pfx___driver_attach+0x10/0x10 pci_device_probe+0x88/0xf9 very_probe+0x101/0x248 __driver_probe_device+0xbb/0xed driver_probe_device+0x1a/0x72 __driver_attach+0xd4/0xed bus_for_each_dev+0x76/0xb 8 bus_add_driver+0xbe/0x1be driver_register+0x9a/0xd8 comedi_pci_driver_register+0x28/0x48 [comedia_pci] ? __pfx_pci_8255_driver_init+0x10/0x10 [8255_pci] do_one_initcall+0x72/0x183 do_init_module+0x5b/0x1e8 init_module_from_file+0x86/0xac __do_sys_finit_module+0x151/0x218 do_syscall_ 64+0x72/0xdb Entry_SYSCALL_64_after_hwframe+0x6e/0x76 RIP: 0033:0x7f72f50a0cb9 Código: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 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 8b 0d 47 71 0c 00 f7 d8 64 89 01 48 RSP: 002b:00007ffd47e512d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 RAX: ffffffffffffffda RBX: X: 00007f72f50a0cb9 RDX: 0000000000000000 RSI: 00007f72f52d32df RDI: 000000000000000e RBP: 00000000000000000 R08: 00007f72f5168b20 0000000000000000 R10 : 0000000000000050 R11: 0000000000000246 R12: 00007f72f52d32df R13: 0000000000020000 R14: 0000562dd06785c0 R15: 0000562dcfd0e9a8 K> Módulos vinculados en: 8255_pci(+) comedi_8255 comedi_pci comedi intel_gtt e100(+) acpi_cpufreq rtc_cmos usbhid CR2: 00000000000000000 ---[ end trace 0000000000000000 ]--- RIP: 0010:0x0 Código: No se puede acceder a los bytes del código de operación en 0xffffffffffffffd6. RSP: 0018: FFFFA3F1C02D7B78 EFLAGS: 00010202 RAX: 000000000000000000 RBX: FFFF91F847AEFD00 RCX: 00000000000000009B RDX: 00000000000003 RSI: 00000000000001 RDI: FFF91F840F6FC00 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfs: soluciona el pánico cuando falla nfs4_ff_layout_prepare_ds() Hemos estado viendo el siguiente error de pánico en producción: desreferencia del puntero NULL del kernel, dirección: 0000000000000065 PGD 2f485f067 P4D 2f485f067 PUD 2cc5d8067 PMD RIP : 0010:ff_layout_cancel_io+0x3a/0x90 [nfs_layout_flexfiles] Seguimiento de llamadas: ? __die+0x78/0xc0 ? page_fault_oops+0x286/0x380? __rpc_execute+0x2c3/0x470 [sunrpc] ? rpc_new_task+0x42/0x1c0 [sunrpc] ? exc_page_fault+0x5d/0x110? asm_exc_page_fault+0x22/0x30? ff_layout_free_layoutreturn+0x110/0x110 [nfs_layout_flexfiles]? ff_layout_cancel_io+0x3a/0x90 [nfs_layout_flexfiles]? ff_layout_cancel_io+0x6f/0x90 [nfs_layout_flexfiles] pnfs_mark_matching_lsegs_return+0x1b0/0x360 [nfsv4] pnfs_error_mark_layout_for_return+0x9e/0x110 [nfsv4] ? ff_layout_send_layouterror+0x50/0x160 [nfs_layout_flexfiles] nfs4_ff_layout_prepare_ds+0x11f/0x290 [nfs_layout_flexfiles] ff_layout_pg_init_write+0xf0/0x1f0 [nfs_layout_flexfiles] __nfs_pageio_add_re búsqueda+0x154/0x6c0 [nfs] nfs_pageio_add_request+0x26b/0x380 [nfs] nfs_do_writepage+0x111/0x1e0 [nfs] nfs_writepages_callback+ 0xf/0x30 [nfs] write_cache_pages+0x17f/0x380 ? nfs_pageio_init_write+0x50/0x50 [nfs] ? nfs_writepages+0x6d/0x210 [nfs]? nfs_writepages+0x6d/0x210 [nfs] nfs_writepages+0x125/0x210 [nfs] do_writepages+0x67/0x220? generic_perform_write+0x14b/0x210 filemap_fdatawrite_wbc+0x5b/0x80 file_write_and_wait_range+0x6d/0xc0 nfs_file_fsync+0x81/0x170 [nfs] ? nfs_file_mmap+0x60/0x60 [nfs] __x64_sys_fsync+0x53/0x90 do_syscall_64+0x3d/0x90 Entry_SYSCALL_64_after_hwframe+0x46/0xb0 Inspeccionando el núcleo con drgn pude extraer esto >>> prog.crashed_thread().stack_trace()[0 ] # 0 en 0xffffffffa079657a (ff_layout_cancel_io+0x3a/0x84) en ff_layout_cancel_io en fs/nfs/flexfilelayout/flexfilelayout.c:2021:27 >>> prog.crashed_thread().stack_trace()[0]['idx'] (u32)1 >>> prog.crashed_thread().stack_trace()[0]['flseg'].mirror_array[1].mirror_ds (struct nfs4_ff_layout_ds *)0xffffffffffffffed Esto queda claro en el seguimiento de la pila, llamamos a nfs4_ff_layout_prepare_ds(), lo que podría generar un error inicializando mirror_ds, y luego vamos a limpiarlo todo y nuestra verificación es solo para if (!mirror->mirror_ds). Esto es inconsistente con el resto de usuarios de mirror_ds, que tienen if (IS_ERR_OR_NULL(mirror_ds)) para evitar tropezar con este escenario exacto. Solucione esto en ff_layout_cancel_io() para asegurarnos de que no entremos en pánico cuando recibamos un error. También revisé todas las demás instancias de verificación de mirror_ds y parece que estamos haciendo las verificaciones correctas en todas partes, solo desreferenciando incondicionalmente mirror_ds cuando sabemos que sería válido.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrección para truncar las páginas de meta-inodo a la fuerza El siguiente caso de carrera puede causar corrupción de datos: Hilo Un hilo de GC - gc_data_segment - ra_data_block - página de meta_inodo bloqueada - f2fs_inplace_write_data - invalidate_mapping_pages: no se puede invalidar meta_inode página debido a falla de bloqueo o estado sucio|reescritura - f2fs_submit_page_bio: escribe los últimos datos sucios en el blkaddr antiguo - move_data_block - carga datos antiguos de la página meta_inode - f2fs_submit_page_write: escribe datos antiguos en el blkaddr nuevo Porque invalidate_mapping_pages() omitirá la página de invalidación cuyo estado no está claro incluyendo bloqueado, sucio, reescritura, etc., por lo que debemos usar truncate_inode_pages_range() en lugar de invalidate_mapping_pages() para asegurarnos de que la página meta_inode se elimine.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: NFSv4.2: corrige el ERROR del kernel nfs4_listxattr en mm/usercopy.c:102 Una llamada a listxattr() con un tamaño de búfer = 0 devuelve el tamaño real del búfer necesario para un convocatoria posterior. Cuando el tamaño > 0, nfs4_listxattr() no devuelve un error porque generic_listxattr() o nfs4_listxattr_nfs4_label() consume exactamente todos los bytes, entonces el tamaño es 0 al llamar a nfs4_listxattr_nfs4_user(), lo que luego activa el siguiente ERROR del kernel: [99.403778] ERROR del kernel en mm/usercopy.c:102! [99.404063] Error interno: Ups - ERROR: 00000000f2000800 [#1] SMP [99.408463] CPU: 0 PID: 3310 Comm: python3 No contaminado 6.6.0-61.fc40.aarch64 #1 [ 99.415827] Seguimiento de llamadas: [ 99.41 5985] usercopy_abort+0x70/0xa0 [ 99.416227] __check_heap_object+0x134/0x158 [ 99.416505] check_heap_object+0x150/0x188 [ 99.416696] __check_object_size.part.0+0x78/0x168 [ 99.416886 ] __check_object_size+0x28/0x40 [ 99.417078] listxattr+0x8c/0x120 [ 99.417252] path_listxattr+0x78/0xe0 [ 99.417476] __arm64_sys_listxattr+0x28/0x40 [ 99.417723] invoke_syscall+0x78/0x100 [ 99.417929] 48/0xf0 [ 99.418186] do_el0_svc+0x24/0x38 [ 99.418376] el0_svc+0x3c/ 0x110 [ 99.418554] el0t_64_sync_handler+0x120/0x130 [ 99.418788] el0t_64_sync+0x194/0x198 [ 99.418994] Código: aa0003e3 d000a3e0 91310000 97f49bdb (d42 10000) El problema se reproduce cuando generic_listxattr() devuelve 'system.nfs4_acl', llamando así a lisxattr() con tamaño = 16 activará el error. Agregue verificación en nfs4_listxattr() para devolver el error ERANGE cuando se llama con un tamaño > 0 y el valor de retorno es mayor que el tamaño.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrige la desreferencia del puntero NULL en f2fs_submit_page_write() ERROR: desreferencia del puntero NULL del kernel, dirección: 0000000000000014 RIP: 0010:f2fs_submit_page_write+0x6cf/0x780 [f2fs] Seguimiento de llamadas: ? show_regs+0x6e/0x80? __morir+0x29/0x70 ? page_fault_oops+0x154/0x4a0? prb_read_valid+0x20/0x30? __irq_work_queue_local+0x39/0xd0 ? irq_work_queue+0x36/0x70? do_user_addr_fault+0x314/0x6c0? exc_page_fault+0x7d/0x190? asm_exc_page_fault+0x2b/0x30? f2fs_submit_page_write+0x6cf/0x780 [f2fs] ? f2fs_submit_page_write+0x736/0x780 [f2fs] do_write_page+0x50/0x170 [f2fs] f2fs_outplace_write_data+0x61/0xb0 [f2fs] f2fs_do_write_data_page+0x3f8/0x660 [f2fs] f2fs_write_single_data_page+0 x5bb/0x7a0 [f2fs] f2fs_write_cache_pages+0x3da/0xbe0 [f2fs] .. Es posible que otros hilos hayan agregado este fio a io->bio y hayan enviado el io->bio antes de ingresar a f2fs_submit_page_write(). En este punto io->bio = NULL. Si is_end_zone_blkaddr(sbi, fio->new_blkaddr) de este fio es verdadero, entonces se produce un error de desreferencia de puntero NULL en bio_get(io->bio). El código original para determinar el final de la zona estaba después de "out:", lo que habría pasado por alto a algún fio que es el final de la zona. Moví este código antes de "omitir:" para asegurarme de que esté hecho para cada fio.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: RDMA/srpt: no registrar el controlador de eventos hasta que el dispositivo srpt esté completamente configurado. En raras ocasiones, KASAN informa una escritura de use-after-free en srpt_refresh_port(). Esto parece deberse a que se registra un controlador de eventos antes de que el dispositivo srpt esté completamente configurado y una condición de carrera en caso de error puede dejar en su lugar un controlador de eventos parcialmente configurado. En su lugar, registre el controlador de eventos solo después de que se complete la inicialización del dispositivo srpt.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: hisi_sas: soluciona un problema de interbloqueo relacionado con el volcado automático. Si emitimos un comando de desactivación PHY, el dispositivo conectado se desconectará si se produce un error ECC de 2 bits en el Al mismo tiempo, se puede encontrar una tarea colgada: [ 4613.652388] INFORMACIÓN: tarea kworker/u256:0:165233 bloqueada durante más de 120 segundos. [4613.666297] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" desactiva este mensaje. [ 4613.674809] tarea:kworker/u256:0 estado:D pila: 0 pid:165233 ppid: 2 banderas:0x00000208 [ 4613.683959] Cola de trabajo: 0000:74:02.0_disco_q sas_revalidate_domain [libsas] [ 4613.691518] Rastreo de llamadas: [4613.694678] __switch_to +0xf8/0x17c [ 4613.698872] __programación+0x660/0xee0 [ 4613.703063] programación+0xac/0x240 [ 4613.706994] programación_timeout+0x500/0x610 [ 4613.711705] c [ 4613.715548] abajo+0x240/0x2d0 [ 4613.719221] hisi_sas_internal_abort_timeout+0x1bc /0x260 [hisi_sas_main] [ 4613.726618] sas_execute_internal_abort+0x144/0x310 [libsas] [ 4613.732976] sas_execute_internal_abort_dev+0x44/0x60 [libsas] [ 4613.739504] _dev.isra.0+0xbc/0x1b0 [hisi_sas_main] [ 4613.747499] hisi_sas_dev_gone+0x174/0x250 [hisi_sas_main] [ 4613.753682] sas_notify_lldd_dev_gone+0xec/0x2e0 [libsas] [ 4613.759781] sas_unregister_common_dev+0x4c/0x7a0 [libsas] [ 4613.765962] sas_destruct_devices+0xb8/0x120 [libsas] [ 4613.771709] sas_do_revalidate_domain.constprop.0+0x1b8/0x31c [libsas ] [ 4613.778930] sas_revalidate_domain+0x60/0xa4 [libsas] [ 4613.784716] Process_one_work+0x248/0x950 [ 4613.789424] trabajador_thread+0x318/0x934 [ 4613.793878] 0x200 [4613.797810] ret_from_fork+0x10/0x18 [4613.802121] INFORMACIÓN: tarea kworker/u256:4:316722 bloqueado durante más de 120 segundos. [4613.816026] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" desactiva este mensaje. [ 4613.824538] tarea:kworker/u256:4 estado:D pila: 0 pid:316722 ppid: 2 banderas:0x00000208 [ 4613.833670] Cola de trabajo: 0000:74:02.0 hisi_sas_rst_work_handler [hisi_sas_main] [ 4613.841491 ] Rastreo de llamadas: [4613.844647] __switch_to+ 0xf8/0x17c [ 4613.848852] __programación+0x660/0xee0 [ 4613.853052] programación+0xac/0x240 [ 4613.856984] programación_timeout+0x500/0x610 [ 4613.861695] c [ 4613.865542] abajo+0x240/0x2d0 [ 4613.869216] hisi_sas_controller_prereset+0x58/ 0x1fc [hisi_sas_main] [ 4613.876324] hisi_sas_rst_work_handler+0x40/0x8c [hisi_sas_main] [ 4613.883019] Process_one_work+0x248/0x950 [ 4613.887732] trabajador_thread+0x318/0x934 [ 461 3.892204] kthread+0x190/0x200 [ 4613.896118] ret_from_fork+0x10/0x18 [ 4613.900423] INFORMACIÓN: tarea kworker/u256:1:348985 bloqueada durante más de 121 segundos. [4613.914341] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" desactiva este mensaje. [ 4613.922852] tarea:kworker/u256:1 estado:D pila: 0 pid:348985 ppid: 2 banderas:0x00000208 [ 4613.931984] Cola de trabajo: 0000:74:02.0_event_q sas_port_event_worker [libsas] [ 4613.939549] Rastreo de llamadas: [4613.942702] __switch_to +0xf8/0x17c [ 4613.946892] __schedule+0x660/0xee0 [ 4613.951083] Schedule+0xac/0x240 [ 4613.955015] Schedule_timeout+0x500/0x610 [ 4613.959725] x610 [ 4613.964349] espera_para_compleción+0x3c/0x5c [ 4613.969146] descarga_cola de trabajo+0x198 /0x790 [ 4613.973776] sas_porte_broadcast_rcvd+0x1e8/0x320 [libsas] [ 4613.979960] sas_port_event_worker+0x54/0xa0 [libsas] [ 4613.985708] Process_one_work+0x248/0x950 [ 4613.9 90420] hilo_trabajador+0x318/0x934 [ 4613.994868] kthread+0x190/0x200 [ 4613.998800 ] ret_from_fork+0x10/0x18 Esto se debe a que cuando el dispositivo se desconecta, obtenemos el semáforo hisi_hba y enviamos el comando ABORT_DEV al dispositivo. Sin embargo, el aborto interno expiró debido al error ECC de 2 bits y activa el volcado automático. Además, dado que se obtuvo el semáforo hisi_hba, el volcado no se puede ejecutar y el controlador no se puede restablecer. Por lo tanto, los interbloqueos ocurren en las siguientes dependencias circulares ---truncadas---