Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ima: Evite el bloqueo en la sección crítica del lado de lectura de RCU Ocurre un pánico en ima_match_policy: ERROR: no se puede manejar la desreferencia del puntero NULL del kernel en 00000000000000010 PGD 42f873067 P4D 0 Ups: 0000 [#1 ] SMP NOPTI CPU: 5 PID: 1286325 Comm: kubeletmonit.sh Kdump: cargado Contaminado: P Nombre del hardware: QEMU PC estándar (i440FX + PIIX, 1996), BIOS 0.0.0 06/02/2015 RIP: 0010:ima_match_policy+0x84 /0x450 Código: 49 89 fc 41 89 cf 31 ed 89 44 24 14 eb 1c 44 39 7b 18 74 26 41 83 ff 05 74 20 48 8b 1b 48 3b 1d f2 b9 f4 00 0f 84 9c 01 00 <44> 85 73 10 74 ea 44 8b 6b 14 41 f6 c5 01 75 d4 41 f6 c5 02 74 0f RSP: 0018:ff71570009e07a80 EFLAGS: 00010207 RAX: 0000000000000000 RBX: 0000000000 RCX: 0000000000000200 RDX: ffffffffad8dc7c0 RSI: 0000000024924925 RDI: ff3e27850dea2000 RBP: 0000000000000000 R08 : 0000000000000000 R09: ffffffffabfce739 R10: ff3e27810cc42400 R11: 0000000000000000 R12: ff3e2781825ef970 R13: 00000000ff3e2785 R14: 000000000c R15: 0000000000000001 FS: 00007f5195b51740(0000) GS:ff3e278b12d40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: : 0000000080050033 CR2: 0000000000000010 CR3: 0000000626d24002 CR4: 0000000000361ee0 DR0: 0000000000000000 DR1: 00000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: ima_get_action+0x22/0x30 Process_measurement+0xb0/0x830 ? page_add_file_rmap+0x15/0x170? alloc_set_pte+0x269/0x4c0? prep_new_page+0x81/0x140? simple_xattr_get+0x75/0xa0? selinux_file_open+0x9d/0xf0 ima_file_check+0x64/0x90 path_openat+0x571/0x1720 do_filp_open+0x9b/0x110 ? page_counter_try_charge+0x57/0xc0? files_cgroup_alloc_fd+0x38/0x60? __alloc_fd+0xd4/0x250? do_sys_open+0x1bd/0x250 do_sys_open+0x1bd/0x250 do_syscall_64+0x5d/0x1d0 Entry_SYSCALL_64_after_hwframe+0x65/0xca Commit c7423dbdbc9e ("ima: Handle -ESTALE devuelto por ima_filter_rule_match()") introdujo la llamada a ima_lsm _copy_rule dentro de una sección crítica del lado de lectura de RCU que contiene kmalloc con GFP_KERNEL. Esto implica una posible suspensión y viola las limitaciones de las secciones críticas del lado de lectura de RCU en sistemas que no son PREEMPT. Dormir dentro de la sección crítica del lado de lectura de la RCU puede provocar que sincronizar_rcu() regrese antes de tiempo y rompa la protección de la RCU, lo que permite que se produzca una UAF. La causa raíz de este problema podría describirse de la siguiente manera: | Hilo A | Hilo B | | |ima_match_policy | | | rcu_read_lock | |ima_lsm_update_rule | | | sincronizar_rcu | | | | kmalloc(GFP_KERNEL)| | | dormir | ==> sincronizar_rcu regresa temprano | kfree(entrada) | | | | entrada = entrada->siguiente| ==> Sucede UAF y la entrada ahora se vuelve NULL (o podría ser cualquier cosa). | | entrada->acción | ==> Acceder a la entrada puede causar pánico. Para solucionar este problema, estamos convirtiendo todos los kmalloc que se llaman dentro de la sección crítica del lado de lectura de RCU para usar GFP_ATOMIC. [PM: comentario faltante corregido, líneas largas, caso !CONFIG_IMA_LSM_RULES]

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mm: shmem: corrige la obtención de lruvec incorrecto al reemplazar un folio de shmem Al probar shmem swapin, encontré la siguiente advertencia en mi máquina. La razón es que reemplazar una publicación shmem antigua por una nueva hace que mem_cgroup_migrate() borre los datos memcg de la publicación anterior. Como resultado, el folio antiguo no puede obtener el lruvec de memcg correcto necesario para eliminarse de la lista LRU cuando se libera. Esto podría provocar posibles problemas graves, como bloqueos de la lista de LRU debido a que se mantiene el bloqueo de LRU incorrecto y estadísticas de LRU incorrectas. Para solucionar este problema, podemos utilizar mem_cgroup_replace_folio() para reemplazar el antiguo folio shmem. [ 5241.100311] página: refcount:0 mapcount:0 mapeo:00000000000000000 index:0x0 pfn:0x5d9960 [ 5241.100317] head: orden:4 mapcount:0 complete_mapcount:0 nr_pages_mapped:0 pincount:0 [ 5241.100319] banderas: 17fffe0000040068(actualización|lru |head|swapbacked|node=0|zone=2|lastcpupid=0x3ffff) [ 5241.100323] raw: 17fffe0000040068 ffffdffd6687948 fffffdffd69ae008 0000000000000000 [ 5241.100325] raw: 0000000000000 0000000000000000 00000000ffffffff 0000000000000000 [ 5241.100326] cabeza: 17fffe0000040068 ffffdffd6687948 ffffdffd69ae008 000000000 [ 5241.100327] cabeza: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 [ 5241.100328] cabeza: 17fffe0000000204 fffffdffd6665801 ffffffffffffffff 0000000000000000 [ 5241 .100329] encabezado: 0000000a00000010 0000000000000000 00000000ffffffff 0000000000000000 [5241.100330] página volcada porque: VM_WARN_ON_ONCE_FOLIO(!memcg &&!mem_cgroup_disable d()) [ 5241.100338] --------- ---[ cortar aquí ]------------ [ 5241.100339] ADVERTENCIA: CPU: 19 PID: 78402 en include/linux/memcontrol.h:775 folio_lruvec_lock_irqsave+0x140/0x150 [...] [ 5241.100374] pc : folio_lruvec_lock_irqsave+0x140/0x150 [ 5241.100375] lr : folio_lruvec_lock_irqsave+0x138/0x150 [ 5241.100376] sp : ffff80008b38b930 [...] [ 5241 .100398] Seguimiento de llamadas: [5241.100399] folio_lruvec_lock_irqsave+0x140/0x150 [5241.100401] __page_cache_release+ 0x90/0x300 [ 5241.100404] __folio_put+0x50/0x108 [ 5241.100406] shmem_replace_folio+0x1b4/0x240 [ 5241.100409] shmem_swapin_folio+0x314/0x528 [ 5241.1004 11] shmem_get_folio_gfp+0x3b4/0x930 [ 5241.100412] shmem_fault+0x74/0x160 [ 5241.100414] __do_fault+0x40/ 0x218 [ 5241.100417] do_shared_fault+0x34/0x1b0 [ 5241.100419] do_fault+0x40/0x168 [ 5241.100420] handle_pte_fault+0x80/0x228 [ 5241.100422] 0x1c4/0x440 [ 5241.100424] handle_mm_fault+0x60/0x1f0 [ 5241.100426] do_page_fault+0x120/0x488 [ 5241.100429] do_translation_fault+0x4c/0x68 [ 5241.100431] do_mem_abort+0x48/0xa0 [ 5241.100434] el0_da+0x38/0xc0 [ 5241.100436] [ 5241.100437] el0t_64_sync+0x14c/0x150 [ 5241.100439] ---[ final de seguimiento 00000000000000000 ] --- [baolin.wang@linux.alibaba.com: elimine los comentarios menos útiles, según Matthew] Enlace: https://lkml.kernel.org/r/ccad3fe1375b468ebca3227b6b729f3eaf9d8046.1718423197.git.baolin.wang@linux.alibaba. com

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: KVM: solucione una ejecución de datos en last_boosted_vcpu en kvm_vcpu_on_spin() Utilice {READ,WRITE}_ONCE() para acceder a kvm->last_boosted_vcpu para garantizar que las cargas y los almacenes sean atómicos. En el escenario extremadamente improbable de que el compilador rompa los almacenes, es teóricamente posible que KVM intente obtener una vCPU utilizando un índice fuera de los límites, por ejemplo, si la escritura se divide en varios almacenes de 8 bits y se combina con un 32 -carga de bits en una VM con 257 vCPU: CPU0 CPU1 last_boosted_vcpu = 0xff; (last_boosted_vcpu = 0x100) last_boosted_vcpu[15:8] = 0x01; i = (last_boosted_vcpu = 0x1ff) last_boosted_vcpu[7:0] = 0x00; vcpu = kvm->vcpu_array[0x1ff]; Según lo detectado por KCSAN: ERROR: KCSAN: ejecución de datos en kvm_vcpu_on_spin [kvm] / kvm_vcpu_on_spin [kvm] escribe en 0xffffc90025a92344 de 4 bytes por tarea 4340 en la CPU 16: kvm_vcpu_on_spin (arch/x86/kvm/../../. ./virt/kvm/kvm_main.c:4112) kvm handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:? arch/x86/kvm /vmx/vmx.c:6606) kvm_intel vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm __se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c :890) __x64_sys_ioctl (fs/ioctl.c:890) x64_sys_call (arch/x86/entry/syscall_64.c:33) do_syscall_64 (arch/x86/entry/common.c:?) Entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64 .S:130) leído en 0xffffc90025a92344 de 4 bytes por la tarea 4342 en la CPU 4: kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4069) kvm handle_pause (arch/ x86/kvm/vmx/vmx.c:5929) kvm_intel vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:? arch/x86/kvm/vmx/vmx.c:6606) kvm_intel vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86 .c:?) kvm kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm __se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890) __x64_sys_ioctl (fs/ioctl.c:890) x64_sys_call (arch/x86/entry/syscall_64.c:33) do_syscall_64 (arch/x86/entry/common.c:?) Entry_SYSCALL_64_after_hwframe (arch/ x86/entry/entry_64.S:130) valor cambiado: 0x00000012 -> 0x00000000

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: no deja un puntero sk colgando cuando falla la creación del socket. Es posible activar un use-after-free: * adjuntando una sonda fentry a __sock_release() y el sonda que llama al asistente bpf_get_socket_cookie() * ejecuta traceroute -I 1.1.1.1 en una máquina virtual recién iniciada. Un kernel habilitado para KASAN registrará algo como lo siguiente (decodificado y eliminado): =============== ==================================================== = ERROR: KASAN: slab-use-after-free en __sock_gen_cookie (./arch/x86/include/asm/atomic64_64.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include /linux/atomic/atomic-instrumented.h:1611 net/core/sock_diag.c:29) Lectura de tamaño 8 en la dirección ffff888007110dd8 mediante tarea traceroute/299 CPU: 2 PID: 299 Comm: traceroute Contaminado: GE 6.10.0- rc2+ #2 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 01/04/2014 Seguimiento de llamadas: dump_stack_lvl (lib/dump_stack.c:117 ( discriminador 1)) print_report (mm/kasan/report.c:378 mm/kasan/report.c:488)? __sock_gen_cookie (./arch/x86/include/asm/atomic64_64.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 neto /core/sock_diag.c:29) kasan_report (mm/kasan/report.c:603)? __sock_gen_cookie (./arch/x86/include/asm/atomic64_64.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 neto /core/sock_diag.c:29) kasan_check_range (mm/kasan/generic.c:183 mm/kasan/generic.c:189) __sock_gen_cookie (./arch/x86/include/asm/atomic64_64.h:15 ./include /linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 net/core/sock_diag.c:29) bpf_get_socket_ptr_cookie (./arch/x86/include/asm /preempt.h:94 ./include/linux/sock_diag.h:42 net/core/filter.c:5094 net/core/filter.c:5092) bpf_prog_875642cf11f1d139___sock_release+0x6e/0x8e bpf_trampoline_6442506592+0x47/0xaf __ calcetín_release (net/ socket.c:652) __sock_create (net/socket.c:1601) ... Asignado por la tarea 299 en la CPU 2 en 78.328492s: kasan_save_stack (mm/kasan/common.c:48) kasan_save_track (mm/kasan/common. c:68) __kasan_slab_alloc (mm/kasan/common.c:312 mm/kasan/common.c:338) kmem_cache_alloc_noprof (mm/slub.c:3941 mm/slub.c:4000 mm/slub.c:4007) sk_prot_alloc (net/core/sock.c:2075) sk_alloc (net/core/sock.c:2134) inet_create (net/ipv4/af_inet.c:327 net/ipv4/af_inet.c:252) __sock_create (net/socket. c:1572) __sys_socket (net/socket.c:1660 net/socket.c:1644 net/socket.c:1706) __x64_sys_socket (net/socket.c:1718) 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:130) Liberado por la tarea 299 en la CPU 2 a las 78.328502s: kasan_save_stack (mm/kasan/common.c:48) kasan_save_track (mm/kasan/common.c:68) kasan_save_free_info (mm/kasan/generic.c:582) veneno_slab_object (mm/kasan/common.c:242) __kasan_slab_free (mm/kasan/common.c:256) kmem_cache_free ( mm/slub.c:4437 mm/slub.c:4511) __sk_destruct (net/core/sock.c:2117 net/core/sock.c:2208) inet_create (net/ipv4/af_inet.c:397 net/ipv4 /af_inet.c:252) __sock_create (net/socket.c:1572) __sys_socket (net/socket.c:1660 net/socket.c:1644 net/socket.c:1706) __x64_sys_socket (net/socket.c:1718 ) 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:130) Solucione este problema borrando la referencia del socket de estructura en sk_common_release () para cubrir todas las familias de protocolos, cree funciones, que pueden ya adjuntar la referencia al objeto sk con sock_init_data().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dmaengine: idxd: corrija posible Use-After-Free en irq_process_work_list Use list_for_each_entry_safe() para permitir iterar a través de la lista y eliminar la entrada en el proceso de iteración. El descriptor se libera a través de idxd_desc_complete() y existe una pequeña posibilidad de que cause problemas para el iterador de la lista cuando otro subproceso reutiliza el descriptor sin que se elimine de la lista.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: seg6: corrige el paso de parámetros al llamar a NF_HOOK() en los comportamientos End.DX4 y End.DX6 input_action_end_dx4() y input_action_end_dx6() se llaman NF_HOOK() para el gancho PREROUTING, en el gancho PREROUTING , debemos pasar un indev válido y un outdev NULL a NF_HOOK(); de lo contrario, podemos desencadenar una desreferencia del puntero NULL, como se muestra a continuación: [74830.647293] ERROR: desreferencia del puntero NULL del kernel, dirección: 00000000000000090 [74830.655633] #PF: acceso de lectura del supervisor en modo kernel [74830.657888] #PF: error_code(0x0000) - página no presente [74830.659500] PGD 0 P4D 0 [74830.660450] Ups: 0000 [#1] PREEMPT SMP PTI... [74830.664953] Nombre de hardware: Red Hat KVM , BIOS 0.5.1 01/01/2011 [74830.666569] RIP: 0010:rpfilter_mt+0x44/0x15e [ipt_rpfilter] ... [74830.689725] Seguimiento de llamadas: [74830.690402] [74830.690953] ? show_trace_log_lvl+0x1c4/0x2df [74830.692020] ? show_trace_log_lvl+0x1c4/0x2df [74830.693095] ? ipt_do_table+0x286/0x710 [ip_tables] [74830.694275] ? __die_body.cold+0x8/0xd [74830.695205] ? page_fault_oops+0xac/0x140 [74830.696244] ? exc_page_fault+0x62/0x150 [74830.697225] ? asm_exc_page_fault+0x22/0x30 [74830.698344] ? rpfilter_mt+0x44/0x15e [ipt_rpfilter] [74830.699540] ipt_do_table+0x286/0x710 [ip_tables] [74830.700758] ? ip6_route_input+0x19d/0x240 [74830.701752] nf_hook_slow+0x3f/0xb0 [74830.702678] input_action_end_dx4+0x19b/0x1e0 [74830.703735] ? input_action_end_t+0xe0/0xe0 [74830.704734] seg6_local_input_core+0x2d/0x60 [74830.705782] lwtunnel_input+0x5b/0xb0 [74830.706690] __netif_receive_skb_one_core+0x63/0xa0 830.707825] proceso_atrasado+0x99/0x140 [74830.709538] __napi_poll+0x2c/0x160 [74830.710673] net_rx_action+ 0x296/0x350 [74830.711860] __do_softirq+0xcb/0x2ac [74830.713049] do_softirq+0x63/0x90 input_action_end_dx4() pasando un indev NULL a NF_HOOK(), y finalmente activa una desreferencia NULL en rpfilter_mt()->rpfilter_is_lo opback(): bool estático rpfilter_is_loopback (const struct sk_buff *skb, const struct net_device *in) { // in es NULL return skb->pkt_type == PACKET_LOOPBACK || en->flags & IFF_LOOPBACK; }

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netns: haga que get_net_ns() maneje cero refcount net. Syzkaller recibió una advertencia: refcount_t: adición en 0; use-after-free. ADVERTENCIA: CPU: 3 PID: 7890 en lib/refcount.c:25 refcount_warn_saturate+0xdf/0x1d0 Módulos vinculados en: CPU: 3 PID: 7890 Comm: tun No contaminado 6.10.0-rc3-00100-gcaa4f9578aba-dirty #310 Hardware nombre: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 01/04/2014 RIP: 0010:refcount_warn_saturate+0xdf/0x1d0 Código: 41 49 04 31 ff 89 de e8 9f 1e cd fe 84 db 75 9c e8 76 26 cd fe c6 05 b6 41 49 04 01 90 48 c7 c7 b8 8e 25 86 e8 d2 05 b5 fe 90 <0f> 0b 90 90 e9 79 ff ff ff e8 53 26 cd fe 0f b6 1 RSP: 0018: ffff8881067b7da0 EFLAGS: 00010286 RAX: 00000000000000000 RBX: 0000000000000000 RCX: ffffffff811c72ac RDX: ffff8881026a2140 RSI: ffffffff811c72b5 RDI: 0000000000000001 RBP: ffff8881067b7db0 R08: 0000000000000000 R09: 205b5d3730353139 R10: 00000000000000000 R11: 205d303938375420 R12: 8881086500c4 R13: ffff8881086500c4 R14: ffff8881086500b0 R15: ffff888108650040 FS : 00007f5b2961a4c0(0000) GS:ffff88823bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: fd18 CR3: 00000001482f6000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: ? show_regs+0xa3/0xc0? __advertir+0xa5/0x1c0 ? refcount_warn_saturate+0xdf/0x1d0? report_bug+0x1fc/0x2d0? refcount_warn_saturate+0xdf/0x1d0? handle_bug+0xa1/0x110? exc_invalid_op+0x3c/0xb0? asm_exc_invalid_op+0x1f/0x30? __warn_printk+0xcc/0x140 ? __warn_printk+0xd5/0x140 ? refcount_warn_saturate+0xdf/0x1d0 get_net_ns+0xa4/0xc0 ? __pfx_get_net_ns+0x10/0x10 open_ related_ns+0x5a/0x130 __tun_chr_ioctl+0x1616/0x2370 ? __sanitizer_cov_trace_switch+0x58/0xa0? __sanitizer_cov_trace_const_cmp2+0x1c/0x30 ? __pfx_tun_chr_ioctl+0x10/0x10 tun_chr_ioctl+0x2f/0x40 __x64_sys_ioctl+0x11b/0x160 x64_sys_call+0x1211/0x20d0 do_syscall_64+0x9e/0x1d0 Entry_SYSCALL_64_after_h wframe+0x77/0x7f RIP: 0033:0x7f5b28f165d7 Código: b3 66 90 48 8b 05 b1 48 2d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff 73 01 c3 48 8b 0d 81 48 2d 0 8 RSP: 002b:00007ffc2b59c5e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f5b28f165d7 RDX: 000000000 RSI: 00000000000054e3 RDI: 0000000000000003 RBP: 00007ffc2b59c650 R08: 00007f5b291ed8c0 R09: 00007f5b2961a4c0 R10: 690010 R11: 0000000000000246 R12: 0000000000400730 R13: 00007ffc2b59cf40 R14: 0000000000000000 R15: 00000000000000000 Pánico del kernel - no sincronizado: kernel: pánico_on_warn set ... Esto se activa como se muestra a continuación: ns0 ns1 tun_set_iff() //dev is tun0 tun->dev = dev //ip link set tun0 netns ns1 put_net() //ref es 0 __tun_chr_ioctl() //TUNGETDEVNETNS net = dev_net(tun->dev); open_ related_ns(&net->ns, get_net_ns); //ns1 get_net_ns() get_net() //adición en 0 Use may_get_net() en get_net_ns en caso de que la referencia de red sea cero para solucionar este problema

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cachefiles: vacía todas las solicitudes después de configurar CACHEFILES_DEAD En modo bajo demanda, cuando el daemon está procesando una solicitud abierta, si el kernel marca el caché como CACHEFILES_DEAD, cachefiles_daemon_write() siempre devolverá: EIO, por lo que el daemon no puede pasar el copen al kernel. Luego, el proceso del núcleo que está esperando el copen activa una tarea colgada. Dado que el estado DEAD es irreversible, solo se puede salir cerrando /dev/cachefiles. Por lo tanto, después de llamar a cachefiles_io_error() para marcar el caché como CACHEFILES_DEAD, si está en modo bajo demanda, vacíe todas las solicitudes para evitar la tarea suspendida anterior. Es posible que aún podamos leer algunos de los datos almacenados en caché antes de cerrar el fd de /dev/cachefiles. Tenga en cuenta que esto depende del parche que agrega el recuento de referencias al requisito; de lo contrario, puede ser UAF.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: cxl/region: solucione las fugas de memregion en devm_cxl_add_region() Mueva el modo de verificación a __create_region() antes de asignar la memregion para evitar las fugas de memregion.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: landlock: Fix d_parent walk WARN_ON_ONCE() en Collect_domain_accesses() se puede activar al intentar vincular un punto de montaje raíz. Esto no puede funcionar en la práctica porque este directorio está montado, pero la verificación de VFS se realiza después de llamar a security_path_link(). No utilice d_parent del directorio de origen cuando el directorio de origen sea el punto de montaje. [micrófono: Arreglar mensaje de confirmación]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: wwan: iosm: corregir la eliminación del puntero contaminado es un caso de error en la creación de la región. En caso de que falle la creación de la región en ipc_devlink_create_region(), el proceso de eliminación de regiones creadas previamente comienza desde el puntero contaminado que en realidad contiene el valor del código de error. Corrija este error disminuyendo el índice de región antes de eliminarlo. Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5: Se corrige la eliminación del puntero contaminado en caso de error en la creación de reglas de flujo. En caso de que falle la creación de reglas de flujo en mlx5_lag_create_port_sel_table(), en lugar de las reglas creadas previamente, se elimina el puntero contaminado varias veces. Corrija este error utilizando punteros de reglas de flujo correctos. Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE.