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

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

[Guilherme Giacomo Simoes]

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.

Signed-off-by: Guilherme Giacomo Simoes <trintaeoitogc@gmail.com>
---
 arch/x86/entry/vdso/vma.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/entry/vdso/vma.c b/arch/x86/entry/vdso/vma.c
index a6bfcc8243cd..d903bce24f15 100644
--- a/arch/x86/entry/vdso/vma.c
+++ b/arch/x86/entry/vdso/vma.c
@@ -178,7 +178,7 @@ static int map_vdso(const struct vdso_image *image, unsigned long addr)
 	if (IS_ERR(vma)) {
 		ret = PTR_ERR(vma);
 		do_munmap(mm, text_start, image->size, NULL);
-		do_munmap(mm, addr, image->size, NULL);
+		do_munmap(mm, addr, VDSO_NR_PAGES * PAGE_SIZE, NULL);
 		goto up_fail;
 	}
 
-- 
2.52.0

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

[Thomas Weißschuh]

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?

> Signed-off-by: Guilherme Giacomo Simoes <trintaeoitogc@gmail.com>

Fixes: e93d2521b27f ("x86/vdso: Split virtual clock pages into dedicated mapping")
Reviewed-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>

> ---
>  arch/x86/entry/vdso/vma.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/x86/entry/vdso/vma.c b/arch/x86/entry/vdso/vma.c
> index a6bfcc8243cd..d903bce24f15 100644
> --- a/arch/x86/entry/vdso/vma.c
> +++ b/arch/x86/entry/vdso/vma.c
> @@ -178,7 +178,7 @@ static int map_vdso(const struct vdso_image *image, unsigned long addr)
>  	if (IS_ERR(vma)) {
>  		ret = PTR_ERR(vma);
>  		do_munmap(mm, text_start, image->size, NULL);
> -		do_munmap(mm, addr, image->size, NULL);
> +		do_munmap(mm, addr, VDSO_NR_PAGES * PAGE_SIZE, NULL);
>  		goto up_fail;
>  	}
>  
> -- 
> 2.52.0
> 

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
```