From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lj1-f179.google.com (mail-lj1-f179.google.com [209.85.208.179]) (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 72B9C3EB810 for ; Mon, 27 Jul 2026 09:26:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785144407; cv=none; b=YaDPDi2ceFiQML6j3cqPcUVUUbB0i8dWJmtDwvlOElLylzeMoiqEqYqrXntbZag6u87sXR5Ml8VLBaOOAwd9EkQBlqDH6qw7VMKTaaok5txL/UZB/2ctJ2jfnme/wR3ViY/wtK1e8tt0E7WtvWlXip0MQtTjHpLgjV2SgFiTNNQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785144407; c=relaxed/simple; bh=1HnK3HcFiLY8fBtrCSFjv5zVe3yaxICG9AUDneVAW6c=; h=From:Date:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Fc9fLjM0uQ1b/pZ2EyNEpYjzyeNahhvgUeeuFFhnvQry1+9wzjCufTtXFYvWWK32ZN3MZP4V7WHkby56PXNBpVYApKVbhxRvkv82P4iQ3zug1w8HBS/rD/w1byKDcoQBofDQDrScMNF/kEd0mpDlWqBUwCyhTMvfu7+EQqQ37+A= 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=CIhrxtlD; arc=none smtp.client-ip=209.85.208.179 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="CIhrxtlD" Received: by mail-lj1-f179.google.com with SMTP id 38308e7fff4ca-39ca0a30148so23997531fa.3 for ; Mon, 27 Jul 2026 02:26:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785144403; x=1785749203; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:date:from:from:to:cc:subject :date:message-id:reply-to:content-type; bh=LY96VBCIVCWyS8BG6OUhwt1DEXbhg7+TrPUmrkQFJKM=; b=CIhrxtlDQ7R9dNBQG/ZrgJUnIH7fuvWPtX9hNigwWDE1L2UJ7vsN1by3O9cF/wUanj q2wLwcv+8QwKQZ+sRXH6DOvKSlzFNbzGqLlRNhJocOhJJtV+M8vjCd2ufLBWm6/nApMs u5U/cvnYHXw+248PqsUL5xS4EcOTgMnAx02Jc0B8nKDFo+QMvAMEbidAihfBRznaclp+ BSEytgZZFMnoP6qgWVzbbQduZmZEzH81bfN3CnLYxMbw7gh/rkZMHrbJ+6z7HBIVSAlF ssz3qgTgVJtZEyNMUMbzVOMpCG52eCidoKbSv7inOF4lqQXBP+VW6kh8O1P+uu4dGgsN CLzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785144403; x=1785749203; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=LY96VBCIVCWyS8BG6OUhwt1DEXbhg7+TrPUmrkQFJKM=; b=J3WfzrdGPrmKzdMjkwK9zON9jDAMKVm4T8OggpKmep6fdMjRWLYPD5qhM4/nIvOA3R Ur3rxhdJC4Qo2Crb1qb9GLv+x8Fa0GrwNwgH/Y57jFLCo5IXmUURsGWMkbvwLg5HuIec zQejQyYY35Kv2pA2EcNU0K6ZwKZX75he72r37mDkIxQEjkLUdSO3Z4gWxkh6PQo9SsVg fpyNItw2fdQajwPnucerMRyjY4D/ooorrffqigzc+THrB4CCFm5gBcBWpA9K1d3c85rH mKV9C8jEcDy4y3s2wa7WoIleYtWeisUggm1Cqjp7St8BVC7dIPU7U6vsySKKTAEwY/wk LT3w== X-Forwarded-Encrypted: i=1; AHgh+RqW6YGKJUZKUN7ljbFcmGG88IlxRw8xz0/I/udsQrCWmsjnmN8hKkXCd+g0DIRkkep983pWzS7jdo5+JZ0=@vger.kernel.org X-Gm-Message-State: AOJu0Yza86iJlnbo5NpvgFde7U0qn8owRtE0RmdcNhR0iCvxJo7Y2fJB WuLoLfzBP4MVx1q4/r54muIwAmRr9p1mMcGBjFaPdhDLg/JVHJ6OdyAg X-Gm-Gg: AR+sD11tATfBQ5WKFmoXY82SZ/pH9vwc8EqPGSwF30SpgFbrSUxfshfVj3LgTFBPgbG RDGGis38ZATutAG3xptg4e/EKJJ0gc0KWVnwzU0fCVoqlu2B+K6taw8lhtMkbg/iVbbvqqr5lwl Ur9qLBe6VxcXprNnTaPDFBSJwNMSY55FzN8zxZU5rWr7BzD5Or6vTKdn8Zr0sR67csfsdhSmFsM vDNxdMghpawyXTs5Pbr337RVROPdh0k/MW9Sx4g7AST20Vq5cRBEwtxYSQuu+jEKbZFsixMwIN+ 1UukgQ93qxBb3lEo4NKdphXZMv4m/8RZ+5n31Zr08hvcrQzoON5aqz63UNenVgEHkLhHX5pHCmY /rM+RhWqDeVay8njAbibeZS+eOHS5mCAy9LaajWKag0Yo4/7LuaKAMQ== X-Received: by 2002:a05:651c:b22:b0:39b:1776:6577 with SMTP id 38308e7fff4ca-39f2886d316mr12710311fa.40.1785144403210; Mon, 27 Jul 2026 02:26:43 -0700 (PDT) Received: from milan ([2001:9b1:d5a0:a500::24b]) by smtp.gmail.com with ESMTPSA id 38308e7fff4ca-39f22173131sm12238271fa.2.2026.07.27.02.26.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 27 Jul 2026 02:26:42 -0700 (PDT) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Mon, 27 Jul 2026 11:26:41 +0200 To: Dev Jain Cc: Matthew Wilcox , kees@kernel.org, akpm@linux-foundation.org, gustavoars@kernel.org, linux-hardening@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, ryan.roberts@arm.com, anshuman.khandual@arm.com, david@kernel.org, urezki@gmail.com Subject: Re: [PATCH] mm/usercopy: harden bounds checking for vmalloc allocations Message-ID: References: <20260722142936.3287702-1-dev.jain@arm.com> <0a312983-3d63-4d60-8ff4-d53dcfff7819@arm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0a312983-3d63-4d60-8ff4-d53dcfff7819@arm.com> On Mon, Jul 27, 2026 at 12:33:49PM +0530, Dev Jain wrote: > > > On 26/07/26 4:16 pm, Matthew Wilcox wrote: > > On Sun, Jul 26, 2026 at 02:23:20PM +0530, Dev Jain wrote: > >> On 22/07/26 7:59 pm, Dev Jain wrote: > >>> The vmalloc allocator stores the actual allocation size inside the > >>> vm_struct structure. We can use this bound in usercopy instead of the > >>> page-aligned va_end to catch usercopy beyond the actual allocation size. > >>> > >>> For vmap, the requested_size field is always page-aligned since it maps a > >>> certain number of pages. Same for vm_map_ram (alongwith, not even having > >>> a vm_struct). So the check is only relevant for vmalloc mappings. > >>> > >>> Because there are early vm areas registered even before vmalloc_init, > >>> requested_size may be zero. So also check whether the requested_size > >>> is set. > >>> > >>> Signed-off-by: Dev Jain > >>> --- > >> > >> Sashiko: > >> > >> 1. "Does this locklessly access area->vm after find_vmap_area() has dropped > >> the busy tree lock? > >> > >> If an out-of-bounds pointer falls into an adjacent vmap_area, and that > >> adjacent area is concurrently freed by another thread, its vm_struct > >> is freed. Additionally, when the vmap_area is moved to the free tree, > >> area->vm (which shares a union with subtree_max_size) is overwritten > >> with an integer size. > >> > >> Would dereferencing vm->flags later in this function cause a use-after-free > >> or a wild pointer dereference?" > >> > >> > >> I don't get it. So usercopy is checking OOB for an object but shouldn't > >> assume the existence of that object while using it? > >> > >> It is a bug in the caller if someone does vfree() while usercopy is operating > >> on the vmalloc object. I don't think usercopy should handle it. For example > >> we don't handle it for slabs currently. > > > > I think the question Sashiko is getting to is how we handle: > > > > char *p = vmalloc(); > > copy_to_user(p - 4); > > Thanks Willy, I completely misread Sashiko's point. > > I think this is an existing problem? We are using area->va_end currently, > so we can access freed memory. > It is a bit mess here since now we need also take into account a requested_size due to vrealloc. We have requested_size, nr_pages and size in the vm_struct. -- Uladzislau Rezki