Re: [PATCH] x86/vdso: fix incorrect size in munmap during map_vdso failure

[Guilherme Giacomo Simoes]

> On Sun, May 03, 2026 at 04:16:09PM -0300, Guilherme Giacomo Simoes wrote:
> > In the map_vdso function, if a failure occurs during the installation of
> > the VVAR mappings, the error path attempts to clean up previously
> > allocated mappings using do_munmap. However, the cleanup for the VVAR
> > mapping was incorrectly using image->size (the size of the vDSO text)
> > instead of the actual size allocated for the VVAR area.
> > 
> > Replace the incorrect image->size parameter with the constant
> > VDSO_NR_PAGES * PAGE_SIZE in the do_munmap call. Ensure the unmap size
> > exactly matches the size used during the vdso_install_vvar_mapping()
> > phase to provide a symmetrical and complete teardown of the memory
> > region.
> 
> Out of curiosity, did you encounter this in the real world?
When I was debug another problem (another unreferenced object), I compile the
kernel, up a qemu with a very small RAM (348MB) and I was run a simple .c
program to debug with a kmemleak scan: 
```
./seupai & while true; do echo scan > /sys/kernel/debug/kmemleak; cat /sys/kernel/debug/kmemleak; sleep 10; done
```
But, I accidentally stumbled upon on this "unreferenced code" in the vdso.

I saw this stack:
```
unreferenced object 0xff110000168eed80 (size 192):
  comm "seupai", pid 7917, jiffies 4294975318
  hex dump (first 32 bytes):
    00 90 f9 2b 7a 7f 00 00 00 b0 f9 2b 7a 7f 00 00  ...+z......+z...
    00 80 a2 12 00 00 11 ff 25 00 00 00 00 00 00 00  ........%.......
  backtrace (crc ee5fc346):
    kmem_cache_alloc_noprof+0x278/0x4c0
    vm_area_alloc+0x20/0x80
    _install_special_mapping+0x2a/0x160
    map_vdso+0x115/0x250
    load_elf_binary+0x109f/0x15c0
    bprm_execve+0x2d2/0x720
    do_execveat_common+0x519/0x580
    __x64_sys_execve+0x38/0x50
    do_syscall_64+0x60/0x1e0
    entry_SYSCALL_64_after_hwframe+0x76/0x7e
```

And I started thinking about this problem, until I found this little bug.

But I had a problem, I couldn't reproduce that bug again... For test my
solution I manually force a problem on third __install_special_mapping from
map_vdso() putting `vma = -ENOMEM` limiting by process name:
```
if (strcmp(current->comm, "seupai") == 0)
	vma = -ENOMEM
```