From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 983BB3EDAB2 for ; Tue, 31 Mar 2026 10:22:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774952524; cv=none; b=fcN6IAYsSM2bR4enpnuL2t0zUdtcoUTgogCldcRhSuXXUazaw1b/eEAo/Z88mY3nDwTUOXNDm//9ndYiTZtKMOC6yzQ6HK0MxODUKVSZqvvERLC8ZGTWSIYaQuqpSuicuSjQ6ndIccvFxtL+K4Q7WdVtcqUeu9+TM3zLd/1wVSE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774952524; c=relaxed/simple; bh=DdS5P9Em7i6NU0h74P/W9ImTzQ5Z9jul/Vm9Is3XGGg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=sAMmGw4b7nf56GcGh/Fhld6PcNaWzZN5urPejZHiqGEXHP3IQ3Y+rrMnQdd61VGWirmv7ZDhZLe+jANxPj+9Ks0x1lV2iYyDnO/WXhrjU/BEsjHpemPCQsc3RFbpmZieNz33al7y1UeXhh4G7upLpsDkrnQOeCMDFh0KW4V5SOE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=y5C4LiL3; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="y5C4LiL3" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1F3CDC2BCB3; Tue, 31 Mar 2026 10:22:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1774952524; bh=DdS5P9Em7i6NU0h74P/W9ImTzQ5Z9jul/Vm9Is3XGGg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=y5C4LiL3Sq4GSdakxLXvYrR9JkhcEhUQ1UfK//1qaKXIMTqhfue1IpTpCt+IRjmlA LU6I03oimALaue8w49yjLf3Cf5B/Jzrx1zs0RditFuhqlQZaLAyJB/TKuTw6k+6urO eyKFa8QlRabM9P5L1l7zw79CoIWZkLX1wbLqda+8= Date: Tue, 31 Mar 2026 12:22:01 +0200 From: Greg KH To: "Lorenzo Stoakes (Oracle)" Cc: stable@vger.kernel.org Subject: Re: [PATCH 6.18.y] mm/mseal: update VMA end correctly on merge Message-ID: <2026033151-crinkly-manhunt-7916@gregkh> References: <2026033044-debug-embargo-40fb@gregkh> <20260330110021.56330-1-ljs@kernel.org> Precedence: bulk X-Mailing-List: stable@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: <20260330110021.56330-1-ljs@kernel.org> On Mon, Mar 30, 2026 at 12:00:21PM +0100, Lorenzo Stoakes (Oracle) wrote: > Previously we stored the end of the current VMA in curr_end, and then upon > iterating to the next VMA updated curr_start to curr_end to advance to the > next VMA. > > However, this doesn't take into account the fact that a VMA might be > updated due to a merge by vma_modify_flags(), which can result in curr_end > being stale and thus, upon setting curr_start to curr_end, ending up with > an incorrect curr_start on the next iteration. > > Resolve the issue by setting curr_end to vma->vm_end unconditionally to > ensure this value remains updated should this occur. > > While we're here, eliminate this entire class of bug by simply setting > const curr_[start/end] to be clamped to the input range and VMAs, which > also happens to simplify the logic. > > Reported-by: Antonius > Closes: https://lore.kernel.org/linux-mm/CAK8a0jwWGj9-SgFk0yKFh7i8jMkwKm5b0ao9=kmXWjO54veX2g@mail.gmail.com/ > Suggested-by: David Hildenbrand (ARM) > Acked-by: Vlastimil Babka (SUSE) > Reviewed-by: Pedro Falcato > Signed-off-by: Lorenzo Stoakes (Oracle) > Fixes: 6c2da14ae1e0 ("mm/mseal: rework mseal apply logic") > Cc: > (cherry picked from commit 88995f43fdc2045ff0b030ca054898483004de36) Not a valid git id :(