From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f179.google.com (mail-qk1-f179.google.com [209.85.222.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 780FF303A04 for ; Thu, 5 Feb 2026 18:42:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770316932; cv=none; b=lXkVKcW/8ZD6PhghgtFuSKuHAaCpeq7iPFx41S8IRWluCuPBrGfu6URWx18XwWgAdgGOEAZyJkz8+s8ghC6K1YGEAsJ6qdVTKy+s92JaT7/YGD7eOO/QzC85ydOYMm33DfQwG9Noqs0UxKVmj7BeARSz+jZ0q4CeLnHPyD3uLyQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770316932; c=relaxed/simple; bh=4YpbVALnnSrYJk1+ZrUMrBtKDo6x/VsB4B3wdVCXimM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=DKIERgMFRMPAUXatrMfX7mYq/3/aGsMbacE/R8VnkgPWEvXKrUDNZyW1cXhzveJBZGpYpVKopJ77Tbsu9z9I8pP0MuicXF7sdR2/su5LbHWFxL4zzrxaii4BZEbhxAonscTpTAn//X/0CK+QgGvHsphRlWmnSglH2c+5qMSK15w= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca; spf=pass smtp.mailfrom=ziepe.ca; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b=VVZb3v7O; arc=none smtp.client-ip=209.85.222.179 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="VVZb3v7O" Received: by mail-qk1-f179.google.com with SMTP id af79cd13be357-8c59bce68a1so80092485a.0 for ; Thu, 05 Feb 2026 10:42:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1770316930; x=1770921730; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=/KaTBsYqoPF9uHZHrraiHcGVEWRIyCizsFESak/HP/0=; b=VVZb3v7Oyuc4fmyCRzgmarC9SDs9PnN0wtUKtWdUYK5HK4u0A/sl5B8Km82ScXqHYv 51E+ZHLReTOvm1oTMmRwC2Vhso5loq3m14mP5oXD3LwWgSm45HrYFCmMgcCU6MhcsKN0 w4k+NsCi82bsQwtgLxrGnetdEg3CWaNsotKxBZ74KTpHMKqWWd678aZ55ihuar7XSyyZ mt6KHZU3FRYE/ZdyfwfgKqb6V0lEi+Pt6I1adZye6vc7HOpvjqZmwPvOm9/XlKot6C00 5bQ/Ewr9JFVr2WPDP69vjuT/qNtqlD6XzzksZY3zJbBIrOeNTq+XK0aD6yeN+j5QEbh5 ZuHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770316930; x=1770921730; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=/KaTBsYqoPF9uHZHrraiHcGVEWRIyCizsFESak/HP/0=; b=P3OYkgPXb0ey3RB+NSoHc6ErirxOBF8prZ0ZqM6b1SSYNRQzzyFTyUaWfPp1Jqg9Cb SRI1/akJgfn10VY+xpn/kg4HAaWMOYe+yzOjKzgOOEnhyCxFoZbhqXqVnjgYelcACyEB FBAuWqC1vXvUOOkpagXEKn2FFeKRV/6LiBwo4a/8AbkVmLGtriEEC2sU0YGf5NhRTT3m xbw+7hRWB6L2vOaXEYx4D/sM4+9SJWj1tYu6yJFQvPwLQOn/ueKh64AujM3LqKUBooCQ tL6TaP/FsoZjf/cx0uIB93WlB7GdSzv5wAe0B1UQAKChiEUVR5V7rczwTfY8rDPd36Yy gyJA== X-Forwarded-Encrypted: i=1; AJvYcCU4q9W7w3dlslpIq0a/M+Mh8YLowikUVVKaGMCHwN3eZGAD0RJVTF/PN9j82OfZbB6bSZKgF765O482A4Y=@vger.kernel.org X-Gm-Message-State: AOJu0YzrRyuL/rSzvKqsb2EVxANamTLC3uXOLMzHT4YSBwbWIOnL1PER s2BA35UJLCmNstUghV82jq6YPibtPoYjHpg5KCsHxV/2+NRSQ34CHFI7kCLaaMePRVI= X-Gm-Gg: AZuq6aLjcaBRgXT2oSbDNpA4c93TqO/mbZg9MWkjZ+U0mWnvNraFok04vHTfeOSwEGL 5roW7bbA/t3goujZL6BfJCcxDhbVWbT+Jsl2f7rAX5XE8/bI7wkFYMqfqkualxGvQRD7Vy0nTHf KCn+9Zs5cJPPzEZWQATWKn/lmcXuvijRSEB+jZTWnNVKWSGwVjswmowXfmImWhTBEnj4SX5t+n3 9VCevMkxqTbjQKf21mVbEE34B6KzB51jD62kC29chLwFNZurdD1RjZla/SmU5S5Y6H6HhRPLkUB nqdr50WX1f5AFwDAvH8g8MIP3zRLmx/aukgjmKr0JIkZ0al+4Ez+mKvM820DIvLctTE5H2/SeWn O/qzY4B58XuerC0QdRIUFGF0zQJtN9BPbFXi7cWYGVSe9KwF9X0KHfSQZQIxLq8mq5s4EFOoINk Pxy0gc0VlOnTUByFpavggiJpCqDkaWaCuQ4H+4ThwgAkR9y+k8BXlsV8IS99/BLym45Gc= X-Received: by 2002:a05:620a:408e:b0:8c9:fc46:235c with SMTP id af79cd13be357-8caf13083e1mr2755785a.71.1770316930104; Thu, 05 Feb 2026 10:42:10 -0800 (PST) Received: from ziepe.ca (hlfxns017vw-142-162-112-119.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.162.112.119]) by smtp.gmail.com with ESMTPSA id af79cd13be357-8ca2fd4135csm455088785a.42.2026.02.05.10.42.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Feb 2026 10:42:07 -0800 (PST) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1vo4Io-00000002BXw-1ydx; Thu, 05 Feb 2026 14:42:06 -0400 Date: Thu, 5 Feb 2026 14:42:06 -0400 From: Jason Gunthorpe To: Andy Gospodarek Cc: Pavan Chebbi , Saeed Mahameed , michael.chan@broadcom.com, linux-kernel@vger.kernel.org, dave.jiang@intel.com, Jonathan.Cameron@huawei.com, gospo@broadcom.com, selvin.xavier@broadcom.com, leon@kernel.org, kalesh-anakkur.purayil@broadcom.com Subject: Re: [PATCH v3 fwctl 4/5] fwctl/bnxt_fwctl: Add bnxt fwctl device Message-ID: <20260205184206.GP2328995@ziepe.ca> References: <20260129155453.3626544-1-pavan.chebbi@broadcom.com> <20260129155453.3626544-5-pavan.chebbi@broadcom.com> <20260205173346.GO2328995@ziepe.ca> 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: On Thu, Feb 05, 2026 at 12:47:53PM -0500, Andy Gospodarek wrote: > Jason, this is all done in bnxtctl_fw_rpc() and the functions it calls > in this (or the v4 version) of this patch. Oh.. No.. You can't do this: + rpc_in.msg = memdup_user(u64_to_user_ptr(msg->req), msg->req_len); // ^^ eventually becomes fw_msg + dma_ptr = fw_msg->msg + msg->offset; + *(__le64 *)(dma_ptr) = cpu_to_le64(dma_addr[i]); There is nothing in here which ensures that every DMA physical address in the mailbox given from userspace is *actually forced to a value by the kernel* The kernel only overwrites values from the user controlled struct fwctl_dma_info_bnxt array. Meaning userspace can just specify any physical address in the message, not include any fwctl_dma_info_bnxt list and it will happily send the user controlled physical address to the FW. Thus userspace can DMA to whatever memory it likes. IOW this is a *HUGE* security error! You are going to struggle very much supporting this kind of ill suited FW API through this interface, I think you need to rework the FW protocol... Or add some very complex kernel validation and do something about forward compatibility... Or only support commands the FW promises will never have a DMA address in them. Shouldn't you guys have caught this during your security review? "don't DMA to random memory" is a very clear fundamental thing in the fwctl rules! Jason