From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from fout-b6-smtp.messagingengine.com (fout-b6-smtp.messagingengine.com [202.12.124.149]) (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 82615409285 for ; Tue, 13 Oct 2026 05:51:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.12.124.149 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791870679; cv=none; b=sqF8EMceSIO5HBMbUeQk0auTLkKyhwh59oyjw736gNTt+9QBCf7d+twLuSXbU5OyU9/mUSeM9A8MUVJRuOmj3FcQ109Ig0oMOFJ6LUbBwA4EjTsGxW5yiolbE4HLNQ4nXmmjpX6EYbYfEaUOo64tY01Ymy60nZZ6xyzuYbwrum4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791870679; c=relaxed/simple; bh=gg5xzGeRZT9S/kztnXNypgtbGJjOd7cJmItCl+1bAEw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=K/73Sax5pRrALqI9tGcHh0gthAIJNtNip6esw6F+/NVswRV6KRyQ8RXKNQDUYZEFIOgscqXCd+6cidFFwiWfCqyFg8A8yiPLyqbsUOu497QHe7G4VQWZGW2wXKw5kg7WjS2AIDpDmId0ofsdhkWiUULtKTh74MBC010QvZvJREc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=tyhicks.com; spf=pass smtp.mailfrom=tyhicks.com; dkim=pass (2048-bit key) header.d=tyhicks.com header.i=@tyhicks.com header.b=RmANN8e0; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=KXp99qSu; arc=none smtp.client-ip=202.12.124.149 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=tyhicks.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=tyhicks.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=tyhicks.com header.i=@tyhicks.com header.b="RmANN8e0"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="KXp99qSu" Received: from phl-compute-04.internal (phl-compute-04.internal [10.202.2.44]) by mailfout.stl.internal (Postfix) with ESMTP id CC6B91D0011A for ; Tue, 13 Oct 2026 01:51:17 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-04.internal (MEProxy); Tue, 13 Oct 2026 01:51:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tyhicks.com; h= cc:cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm1; t=1791870677; x=1791957077; bh=1qXQBI30vV mPspzTFI9qdidfZ+Xhv2BgqG1F062IFBw=; b=RmANN8e0LB0LfdowURdYceuzBq PrcgE+TrH0ZxfGTeYw6PllERaDdkwTj5vvbwD+C3Ez4NObhlOlBW9/C3bs5zU0kx Hqwz7HcPKUGCv8ZyYotnFF4J1nM00JY8hZEd+usxbu7eQu44Lnsva72QZDFMeVFo U5TCsg8asn8Iu7QRb0kqUPo0+gxQknkP9Z6kJ77YBZ20GNmwJJtbO+XQ6o5BWm8y 1tMy76QUu0JtfWogalWfRVtnNvxY3iIKB62/JNui9QreQHBT4aqSa33aWRPdvDRn Qor4xxrK39r7pNoWV0vDU+bxbip+/qztNA2rcujAzi+Kvhuk9dWhGHynVkOA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1791870677; x=1791957077; bh=1qXQBI30vVmPspzTFI9qdidfZ+Xhv2BgqG1 F062IFBw=; b=KXp99qSugQyGVk8uNM3ppTokLRcK9lqXo8ZY5Vn2RAF28T5XsCj J1RAyOPjrAhiuRY8cnFaHotz5NAkjalP/hB60tTeyMJ91AKPYr1EwwfG1ssr5udI 0igBWBeti2qPPICgjU2beeG2v8mdVPBPLS//jDEUY7qG8shLWLqDa813WNciRXBW 3O3yG78fU2A7n4B3drec5qUAai3RCmm9imr4VeAy23+Rg8K/qzebKo2mihETyE1H N+McND+n/L0D1Uqu1V+xjgMsGM/DdQ9lAj5YaDmk4y0rR0VoYgulYlcIo2M+L75h i8EtdUdHxW43iGBaPobq4MZbZaGxvxxOvtQ== X-DKIM2-Info: draft=ietf-dkim-dkim2-spec-06; repo=github.com/dkim2wg/interop; date=2026-10-04; sw=lmtpprox; action=sign d=tyhicks.com a=rsa-sha256; DKIM2-Signature: i=1; m=1; t=1791870677; d=tyhicks.com; mf=PGNvZGVAdHloaWNrcy5jb20+; rt=PGVjcnlwdGZzQHZnZXIua2VybmVsLm9yZz4=; s=fm1:rsa-sha256:bwr9g39oJZXPiwh2ngeRppglLN1YS9R+ZkOlwoFXkTqHV98 xBSLr6cxceEhREnT5vRVwmPuL9FcJVK4lLos7lM6O7+6Dw0eYjVkSQod5VJ3DCvl rJQwVKL15pb0j9g6bDDPBlDdLpqXbPROkXGC5BUczUMw7MpSYyjkgKeBakER0Hi4 6UXzwKa+vnd5a3gsAZHwZuAMnivwLLx56zTNWeY2mTTlShRGFzjM1Z5ZWe0N9T7X abSBKV33kpI9ykC59AyVw9hiho8ttNGzrwCTS+b//e5ov6i5zlTxTYWLWzk/TbW+ yQnfqL3k2FUhtdBXHO6/c/ny3dT9AOiFUpEHAUg==; X-DKIM2-Info: draft=ietf-dkim-dkim2-spec-06; repo=github.com/dkim2wg/interop; date=2026-10-04; sw=lmtpprox; action=mi-m=1; hc=12; hn=cc,content-disposition,content-type,date,feedback-id,from, in-reply-to,message-id,mime-version,references,subject,to; Message-Instance: m=1; h=sha256:LlSHrOtzpz7B40CIzfmVVOc9bSw3n5JzWwSBVvHgLOg=:gg5xzGeRZT9S/kztnXNypgtbGJjOd7cJmItCl+1bAEw=; X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTEsTU9xCyRnGNf2O8KrrukZOkB1AhEExVz7u+byF70IdbzsNBVuru8eCBPoF/6v2y 5BIpfrWJ4X5izWt7wttIBlBtVYleHJ6XvCp8GsvUZ/ZYOaxrURTOG51Xu2dy+tTbw9WqL0 1/zRxIP42tGJK5aG4UFIlHrzXCrQbQzXc7X1KWic/lfyPwM4dZRKsS0WI/zlboz+XMPGRN qZ+tnSPMkAslGrSDpRurEjK9C+7cKwQpVZDfNMxWXu8ASR8q2y4672YeZgvAewEB5b80j/ qOJp4/TnBK5I0Pdyc8AYJS4jwR06nysZZ+RssSBQduMnCFXC4XzHe3skUXgl8sQYH2qGAU BIM3rMdsYQqIaFq92Mv0Z3XRXy08v/0nXIAnaKTh307HgCecO9SSg+6RmRSkZlp+VY5X24 n7fVd6YjAgYh62DKMMp8Lw28FR/MjJ2SI1+TL14zlO7c96ibLayKUeQuz9XiLEOCaoIpYJ sj+S6KzNk9XrgAIXmYMFFUaEYIl9lBQHoBGljrtSx9jPTavRoLXb4i4ip+iBrCkJNHCKFE /3YbrJOKnyjlM6OPI+yNv5UTnBSXllsCXT8h/rrcSUD4eDo05wcP+g3LKSZ7LH7KA/KQiD ZDOaQHK+UqwViNOc5lNT6mB7aqOVxAwnrktJukBtnj/t8ALgfcAIg6CaLYYw X-ME-Proxy: Feedback-ID: i78e14604:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 13 Oct 2026 01:51:16 -0400 (EDT) Date: Tue, 13 Oct 2026 00:51:15 -0500 From: Tyler Hicks To: Nguyen Ngoc Thang Cc: ecryptfs@vger.kernel.org, linux-kernel@vger.kernel.org, syzbot+dc50906b100ac7a1c34d@syzkaller.appspotmail.com, stable@vger.kernel.org Subject: Re: [PATCH] ecryptfs: validate key payload size before using it as an auth_tok Message-ID: References: <20261011061902.144716-1-ngocthang2710.1999@gmail.com> Precedence: bulk X-Mailing-List: ecryptfs@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: <20261011061902.144716-1-ngocthang2710.1999@gmail.com> On 2026-10-11 13:19:01, Nguyen Ngoc Thang wrote: > ecryptfs_get_key_payload_data() casts the payload of a "user" or > "encrypted" key straight to struct ecryptfs_auth_tok. The payload size is > chosen by whoever added the key, so a payload shorter than the struct > makes later accesses run past the allocation. For example, a 712-byte > "user" key makes write_tag_3_packet() read the password signature beyond > the end of the kmalloc-1k object: > > BUG: KASAN: slab-out-of-bounds in ecryptfs_from_hex+0x18c/0x1d0 > Read of size 1 > write_tag_3_packet+0x145/0x1430 > ecryptfs_generate_key_packet_set+0x7ae/0x1880 > ecryptfs_write_metadata+0x590/0x930 > ecryptfs_create+0x393/0x550 > > Reject payloads smaller than struct ecryptfs_auth_tok with -EINVAL. The > callers already propagate errors from this helper, so mounting with such > a key now fails cleanly. > > Reported-by: syzbot+dc50906b100ac7a1c34d@syzkaller.appspotmail.com > Closes: https://syzkaller.appspot.com/bug?extid=dc50906b100ac7a1c34d > Fixes: 237fead61998 ("[PATCH] ecryptfs: fs/Makefile and fs/Kconfig") > Cc: stable@vger.kernel.org > Signed-off-by: Nguyen Ngoc Thang Hello and thanks for the patch! I've already taken the user key payload fix from another contributor and will take the session key encryption key check from a separate contributor. You can find the links here: * https://lore.kernel.org/ecryptfs/20260917044558.41677-1-neganhat@gmail.com/ * https://lore.kernel.org/ecryptfs/20261004123755.14642-1-adrianox@gmail.com/ > --- > Notes (not for the commit log): > syzbot reports "KASAN: slab-out-of-bounds Read in ecryptfs_from_hex". The > reproducer adds a 712-byte "user" key whose description matches > ecryptfs_sig=; the mount succeeds and the first create makes > write_tag_3_packet() read the signature past the end of the kmalloc-1k > object. Tested in QEMU with syzbot's KASAN config: base kernel hits the > KASAN report, patched kernel fails the mount with -EINVAL. Fixes points at > the initial ecryptfs commit since the history here is grafted; happy to > retarget. > > fs/ecryptfs/ecryptfs_kernel.h | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/fs/ecryptfs/ecryptfs_kernel.h b/fs/ecryptfs/ecryptfs_kernel.h > index 58165928ed1e..863761b3847a 100644 > --- a/fs/ecryptfs/ecryptfs_kernel.h > +++ b/fs/ecryptfs/ecryptfs_kernel.h > @@ -88,6 +88,9 @@ ecryptfs_get_encrypted_key_payload_data(struct key *key) > if (!payload) > return ERR_PTR(-EKEYREVOKED); > > + if (payload->decrypted_datalen < sizeof(struct ecryptfs_auth_tok)) > + return ERR_PTR(-EINVAL); I think Adriano's check on payload_datalen is more accurate. I believe your check would block legitimate encrypted-keys. Tyler > + > return (struct ecryptfs_auth_tok *)payload->payload_data; > } > > @@ -124,6 +127,9 @@ ecryptfs_get_key_payload_data(struct key *key) > if (!ukp) > return ERR_PTR(-EKEYREVOKED); > > + if (ukp->datalen < sizeof(struct ecryptfs_auth_tok)) > + return ERR_PTR(-EINVAL); > + > return (struct ecryptfs_auth_tok *)ukp->data; > } > > -- > 2.43.0 >