Date:   Fri, 3 Feb 2023 09:10:55 +0000
From:   Giovanni Cabiddu <giovanni.cabiddu@intel.com>
To:     Herbert Xu <herbert@gondor.apana.org.au>
CC:     <linux-crypto@vger.kernel.org>, <qat-linux@intel.com>,
        <stable@vger.kernel.org>, Vladis Dronov <vdronov@redhat.com>,
        Fiona Trahe <fiona.trahe@intel.com>
Subject: Re: [PATCH] crypto: qat - fix out-of-bounds read
Message-ID: <Y9zPn9hgTjG1k9Qc@gcabiddu-mobl1.ger.corp.intel.com>
References: <20230201155944.23379-1-giovanni.cabiddu@intel.com>
 <Y9xduyjbaxFdaCUT@gondor.apana.org.au>
 <Y9yrZk9KnICxqkZp@gcabiddu-mobl1.ger.corp.intel.com>
 <Y9zKTHFvYHrmfqdW@gondor.apana.org.au>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <Y9zKTHFvYHrmfqdW@gondor.apana.org.au>
Organization: Intel Research and Development Ireland Ltd - Co. Reg. #308263 -
 Collinstown Industrial Park, Leixlip, County Kildare - Ireland
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?4NLskgqyn9ACnmr7c2vhWyP4ISc/IvVKRref7UluYdUHHhi7H2QgKMp5ewo6?=
 =?us-ascii?Q?WmVSLoBh8eRZbSyTpQmbWyIKca4S1lZIY8y8OCN1RQbz5KGd6asdBOAFmhrm?=
 =?us-ascii?Q?1Bg0/2GpC1BClx0ErUs7JLLIAIjcIQqCqUQbByH8z3p10petNkYb2vnx4FO4?=
 =?us-ascii?Q?/mNJyvb9yIJumYFL4oOlFtAivt/q4gPU+OhTTNqrcx/HfnLMBepKWcZqOv9y?=
 =?us-ascii?Q?Ln+W7adro41jQ2M2WmQMSyQgvSxI8Cl6lV8AsINaRHNHChqwS2Ya+Kk5vUyC?=
 =?us-ascii?Q?NFvLaNzQELWM5fd8jzmJKXDQwPDQecY33gM9dCxutBMnTLl+xlg6/f/ScGRs?=
 =?us-ascii?Q?rTinBRqqDPio2urroWyUToDEP/LMA18DiCGIc0/KixlYAUVxpDpCVHIxq3Ly?=
 =?us-ascii?Q?+/UjETYo6iGF/COQeNI3zMbM3iGgptGGJxfSqNrNumYE9MsEH1JxEVonthx5?=
 =?us-ascii?Q?ZPv0DQFoCxurwcJz+p72nEE07Ph65zWUKI8ZOt7wvjHo8TZVIWduLolQqpDB?=
 =?us-ascii?Q?eRDqMyum6hrSxGz4kw6yPpZgHFXvRx8y1Z3k7u7aCT10z6hLsXJjlCsdpG7Y?=
 =?us-ascii?Q?IrichMhw0hFFeydOjwP+NoaB6Cl+ISSsOQlMCf18/KfcefAG5f7kEhWXv8FW?=
 =?us-ascii?Q?dfeasohNImx7TOlz/B++SGzWLkRmTlaj9+d81IFVRizwONWq3+wLrmyN6f47?=
 =?us-ascii?Q?LSl4+yJ2bIV/rAuCrewqZE2LyGsVvJbKpTDp6W39bFJY9MHGchQ+b81IkV/Z?=
 =?us-ascii?Q?//I2U+UhKjCu8bDIyfRHD1UC2XNGnuV+TSbdFO0adby2JSyO1sVM3OqoPZc8?=
 =?us-ascii?Q?Ub1P0D/+KwjZYvvvhwOqRrusdQBEWp0kpX9f7z1tyMST5JkZHQ8qIJnZ1jcX?=
 =?us-ascii?Q?I1iknHG944ctEvreGfgiTPJ/CleIHE6z7KEiS6BXsrwwqNUOruop812D0eBx?=
 =?us-ascii?Q?cCSgTtOkb9moKjM0apBs2vScA6R8256qvmypSABbJeql0MPK5UdwP6AQ0LD/?=
 =?us-ascii?Q?Nef+Ei3m2CL6Lj3Z9KQibi2hEtB3ro7exIPEZTwDpkZv7Q4tLSW4rHY5/7zS?=
 =?us-ascii?Q?yRxc9q1FU5TmGFVvGwuJtgNJcTDXkKVWa0t7kv6xa8r8eIycLRLDVt5NHwZ2?=
 =?us-ascii?Q?79/jYumwyIabPYclK4LhSnji7dkf2Q6SYsBURf8GdK0AXmf8uiC+Dj8g0JPn?=
 =?us-ascii?Q?0SRvm97b3MUOUsThyrMf6o2okm7t+UZ7tYji11lcvjj3NDKZa5WMsuN1VdX+?=
 =?us-ascii?Q?rWOF/v/4P4vB81UKXjZlaBpsNfGZvokVv3NJyhVtjPv5gEwLJV4ZXWXJVjpE?=
 =?us-ascii?Q?o2bRZChkFkssY9Iuq2DjWJIX/6YOmx5PXYtHOSH6BmLQaRE5rDapJSCzW9XU?=
 =?us-ascii?Q?jQQH5jt3SBESjpOHaJd+ayNhvr6hhMShcLE4QRlfwGDMX7c21d6WEgzWkE7t?=
 =?us-ascii?Q?WTON5LYBDLDIMMxY8Xwf/O3CUTqmUmQ+xz0JZSHtByexBtumfUL5UiFGKcQv?=
 =?us-ascii?Q?GZnC30ljt4OFVVdjv80tkXtiGkhIjKTTkDAFBDV0Hta1yHAIjUb8AOkBR/sk?=
 =?us-ascii?Q?bHMiBgVjZRb9XejDadCK4puxXZ948w4Nl2uaIjAsnCYEOVSvoSaqul3PDGWR?=
 =?us-ascii?Q?dQ=3D=3D?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 4921c4f1-6972-414a-325c-08db05c691b2
X-MS-Exchange-CrossTenant-AuthSource: CY5PR11MB6366.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Feb 2023 09:11:01.0513
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: xXP1QKbC9eoTiLSKgOOHejsAXGiI5FLUN59glfpTJjkXyxxiAaoh9TSaSpx9k0zkOC9TIEmYuMPOL+MpruflSWPA4Jef+4JRdFe+JsZKwkA=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW5PR11MB5905
X-OriginatorOrg: intel.com
Precedence: bulk
List-ID: <linux-crypto.vger.kernel.org>
X-Mailing-List: linux-crypto@vger.kernel.org

On Fri, Feb 03, 2023 at 04:48:12PM +0800, Herbert Xu wrote:
> On Fri, Feb 03, 2023 at 06:36:22AM +0000, Giovanni Cabiddu wrote:
> >
> > The content descriptor structure (cd) is already initialized to zero
> > before the function qat_alg_skcipher_init_com() is called.
> > This is done in
> >   (1) qat_alg_skcipher_newkey() implicitly by dma_alloc_coherent(),
> >       the first time setkey() is called for a tfm or
> 
> Sorry but what zeroes the memory in this case? The only zeroing
> I can find in newkey is when you free the memory.
dma_alloc_coherent() returns zero'd memory.
When implemented originally that code used dma_zalloc_coherent(). This
was phased out in Kernel 5.0 by 750afb08ca71.

	commit 750afb08ca71310fcf0c4e2cb1565c63b8235b60
	Author: Luis Chamberlain <mcgrof@kernel.org>
	Date:   Fri Jan 4 09:23:09 2019 +0100

	cross-tree: phase out dma_zalloc_coherent()

	We already need to zero out memory for dma_alloc_coherent(), as such
	using dma_zalloc_coherent() is superflous. Phase it out.
	...

Regards,

-- 
Giovanni