From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dl1-f42.google.com (mail-dl1-f42.google.com [74.125.82.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BBE3A38946A for ; Tue, 5 May 2026 12:24:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777983868; cv=none; b=CtbCWCorPJ/wslZgXRL6/PUxegkbW+yIKdggnaLuMkBtzZFQYUhZDkMr5ZofcOsxPjLbb1UgGY88pYD1LTa6Oe1m7zsoWzNZ364A8aJWIW7c7cZAEXQlCnFWhPEJFr8HKuxwB4LaYfI9PguwCR+EUEhw2Vz97uUeJ1zFwfe8b8c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777983868; c=relaxed/simple; bh=XwtzyvVoq/FI79BeTEsgPbz5I+q/W42RbxbuViQdtJU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ZnY/GjoY/qavCLxOZ7sSDV23r8RxW0zbYW1TG8B+5f/xlNX4tSfjqpe9aGer5Px6ZEoBYqDFaUnocpD55Cgm12iswD5BdjLSk+YVf0P7gQpDFV7FDvWT9O48MfWGtgr4KupnyqjMipmk2UnPGBoACm9aVvtT6+GNxJGGobdQDNA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=OIuKWIJw; arc=none smtp.client-ip=74.125.82.42 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="OIuKWIJw" Received: by mail-dl1-f42.google.com with SMTP id a92af1059eb24-130c653cce4so871194c88.1 for ; Tue, 05 May 2026 05:24:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1777983867; x=1778588667; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=EqxIXJiqhxlert69J4qGQ3USztshRmXgAunZbFXErrk=; b=OIuKWIJw/eJr28abbjvXcBxTBUP28MN4CSUnw1XApOdkvcbOriRkfl3M4/A3qUUhP+ PWpnJhA4MjkNdZQL74a3+NBZMkbSEtCDRqY8AywxE8aRd5Ke3Uf9j2dEjA8uigGhOETP 3amCbxPvnmVfBvBafau4R5SO6Vx3sBU17gWwOxKpp155kL1X5bl23C8AXKkhtTeHOPMZ AhuiI4ESI+nrGfIcZbAyhpVo0ZpWkx2CISF2m2+cWRVMjGnAAnjN6wyQgMtAv58TBueZ VYTAi8BPBGf3XyQHOLRf1sx7RMYWeithpbe51ucLzttSgK5MSctVZ18rKVYfwpmtzNrV sWAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777983867; x=1778588667; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=EqxIXJiqhxlert69J4qGQ3USztshRmXgAunZbFXErrk=; b=qiwNKmF4QUOlRkO3E26kiCM0OGpxar/nhbbOvoHIdrrTdib5dSMTtwkyRbbXWqHzze OVgHy+yez6lcs62y5codUlwIY1mpnFAcognM48dkwH+HI6E8sLpi5gizhQ6GQ9iN8Whf j/LsoFnWzS4OZxcoinp1wEeElhbeXEyv8R/4cGG59NLlsdIKIRaJYra+w9RbsnvpeFbM aDe8SLgoG+0yAthyfqxcoPnXixJ1SwHnpviEdsmIKNymUHmjdi+YuZmJpcxCzFfWeYYF WIry/GeTTOO77dX6u42hXek/jIYNqMhXAMqtu9qB+mKYoTpbITKm4ClmWF3HlWFchHyP /qnQ== X-Forwarded-Encrypted: i=1; AFNElJ9pUYZOGKmzRCemtdk5jYfRYhO+PRIc0Q5tenJTcsG/cnhUBN86WaD0H3j9z06vbH84v2ljGC4LYBfwmzQ=@vger.kernel.org X-Gm-Message-State: AOJu0Yzzb7CQUHT/bridCplMiUv+uENaDoYD5o0rg5AogR+t5gTEB/Ur RA84zTDv1TzkjnI5fT3VIcrX7HoeLHO0cq9v2KFmj1RCDF1oSM1/a6cC X-Gm-Gg: AeBDiev5BmPJcD9DIODjIiPhc2oDtrpi/Lx4bVhJZX4clhQ7NUPpqPU36VJTRu2HgZW sIiqLdJCqTVp59uLOdUVT1aJV8xkhzW5dbPlg53TeG8GROJgcoe0T3yUZRNQJ93/PIIpJBaziRn 6SL9dZThgB9L9rageNEC6z8gKzKQM0pI8A/Mkai2YctrSgkW+ZRj5Y+2T7k6+A7heFfXQ4raKCs fJ/eBCSJq/m0lrzxYXyD+fk/FWOdfrn1HfbchK8T7Tkt4IcQ8EFT5YO8wak3YcqXp3fn1o4H/ju Xm0F9NSyHcgY+rCN8CUhcno1PunABKO74DoHQ/rtlx5E0j4VbUFpjbtdKEPrR49HFOI64DqEzBs PsAH6F6CBN+KJ65ZK28lHrvxFRR2GtixtKMjXW6kVxkOOHv7eyA0Hrktn4Cl0njzG+8JeLWo6g9 o/iRxZRjZELMph5KsDa2jJvX6yQKhBGee4Eg== X-Received: by 2002:a05:7022:ec88:b0:12d:de3f:d844 with SMTP id a92af1059eb24-12dfd8770b2mr6501058c88.39.1777983866913; Tue, 05 May 2026 05:24:26 -0700 (PDT) Received: from fedora ([187.120.154.237]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-12df84250f1sm20142030c88.11.2026.05.05.05.24.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 May 2026 05:24:26 -0700 (PDT) From: Guilherme Giacomo Simoes To: thomas.weissschuh@linutronix.de Cc: bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com, linux-kernel@vger.kernel.org, luto@kernel.org, mingo@redhat.com, tglx@kernel.org, trintaeoitogc@gmail.com, x86@kernel.org Subject: Re: [PATCH] x86/vdso: fix incorrect size in munmap during map_vdso failure Date: Tue, 5 May 2026 09:24:16 -0300 Message-ID: <20260505122416.1037381-1-trintaeoitogc@gmail.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260505133747-904434f5-1bd3-467b-a9a1-99f48a4322fc@linutronix.de> References: <20260505133747-904434f5-1bd3-467b-a9a1-99f48a4322fc@linutronix.de> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit > 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 ```