CVE-2026-45837

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix use-after-free in arena_vm_close on fork<br /> <br /> arena_vm_open() only bumps vml-&gt;mmap_count but never registers the<br /> child VMA in arena-&gt;vma_list. The vml-&gt;vma always points at the<br /> parent VMA, so after parent munmap the pointer dangles. If the child<br /> then calls bpf_arena_free_pages(), zap_pages() reads the stale<br /> vml-&gt;vma triggering use-after-free.<br /> <br /> Fix this by preventing the arena VMA from being inherited across<br /> fork with VM_DONTCOPY, and preventing VMA splits via the may_split<br /> callback.<br /> <br /> Also reject mremap with a .mremap callback returning -EINVAL. A<br /> same-size mremap(MREMAP_FIXED) on the full arena VMA reaches<br /> copy_vma() through the following path:<br /> <br /> check_prep_vma() - returns 0 early: new_len == old_len<br /> skips VM_DONTEXPAND check<br /> prep_move_vma() - vm_start == old_addr and<br /> vm_end == old_addr + old_len<br /> so may_split is never called<br /> move_vma()<br /> copy_vma_and_data()<br /> copy_vma()<br /> vm_area_dup() - copies vm_private_data (vml pointer)<br /> vm_ops-&gt;open() - bumps vml-&gt;mmap_count<br /> vm_ops-&gt;mremap() - returns -EINVAL, rollback unmaps new VMA<br /> <br /> The refcount ensures the rollback&amp;#39;s arena_vm_close does not free<br /> the vml shared with the original VMA.