From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 EFCB733985 for ; Sun, 21 Jun 2026 05:37:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782020269; cv=none; b=aXiDessTKDpNfzeGgPOsyhxr+VO2fvMhz+DlMM+b+tgcVLxk+eSNVdJKbLTx4w605Fti6TcyLSD5v7TT8Uc02a1BxX1FhhwR4pTxqnRF1TbUoUBcctZVTh51C7X2x8XgsThAz2gDhjJqe4IuvXS5s/ousizW/srY2b+/JvPXN5o= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782020269; c=relaxed/simple; bh=NF3n3Vcgk9Bp5LBLasSNyNKAETNxia84J/bcLgzPs0w=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=HGYnf5+qUygz7KacEypdBCXg9EZ1kOO3Aff69kjTP+CnFafZBreQP4wXhCUwLx+5QjZ00OmceQn4syRBkZKFH5HN9BARQG/TcQdb+AbiZO4Q/qaJHQ3/LXPvJ6WYy4VFGisDYf6Fa9WuQk475gYJ6mWBLGa4Ysy8dydyPSOy2ko= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=U4kbEL2M; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="U4kbEL2M" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1E90B1F000E9; Sun, 21 Jun 2026 05:37:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1782020267; bh=GGPG9/H4KP8QUf+nezcvKYbLnAlZ6MSSTz1Lmu6WdrU=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=U4kbEL2M82xQ1esXHnlsEKJ4vgOjHhbfLcA+G8f1PSwOhSJYZAn8zmKTuc4V1B2wY GHo/YhAuatgjrt5cBjxpKcVcKK8vM25Z327fQL+bhO/fVPqWwdPdQ1yO6uYgkOmup+ zfR5TLcB8P+/cjQJJ6gxq2onzaS00SwMxaXjK92k= Date: Sun, 21 Jun 2026 07:38:02 +0200 From: Greg Kroah-Hartman To: hexlabsecurity@proton.me Cc: Arnd Bergmann , Alexander Graf , linux-kernel@vger.kernel.org, The AWS Nitro Enclaves Team Subject: Re: [PATCH] misc: nsm: bound the device-reported response length Message-ID: <2026062124-unsalted-wiry-6920@gregkh> References: <20260620-b4-disp-a54b7dd6-v1-1-79d1f236a854@proton.me> 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: <20260620-b4-disp-a54b7dd6-v1-1-79d1f236a854@proton.me> On Sat, Jun 20, 2026 at 09:42:11PM -0500, Bryam Vargas via B4 Relay wrote: > From: Bryam Vargas > > nsm_sendrecv_msg_locked() stores the virtqueue used-ring length reported > by the NSM device into msg->resp.len without bounding it to the response > buffer. A malicious or buggy backend can report a length larger than the > response buffer; parse_resp_raw() then copies that many bytes out of the > fixed buffer to user space, disclosing adjacent kernel heap (an > out-of-bounds read). The request path already floors its length in > fill_req_raw(); the response path lacks the symmetric check. > > Clamp the stored length to the size of the response buffer. Well-behaved > devices report no more than the posted buffer size, so conforming traffic > is unaffected. Is this really the only place where a "buggy" device that is bound to the driver can cause any problems? Shouldn't the driver only be bound to trusted devices to start with? thanks, greg k-h