Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933010AbcLMLfw (ORCPT ); Tue, 13 Dec 2016 06:35:52 -0500 Received: from smtp.codeaurora.org ([198.145.29.96]:59536 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932979AbcLMLft (ORCPT ); Tue, 13 Dec 2016 06:35:49 -0500 DMARC-Filter: OpenDMARC Filter v1.3.1 smtp.codeaurora.org 0328A6121B Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=pass smtp.mailfrom=kvalo@codeaurora.org From: Kalle Valo To: Andy Lutomirski Cc: linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org, linux-wireless@vger.kernel.org, Eric Biggers , linux-crypto@vger.kernel.org, Herbert Xu , Stephan Mueller Subject: Re: [PATCH] orinoco: Use shash instead of ahash for MIC calculations References: <8c273c9c41f51b34bb3115086f1d776895580637.1481575835.git.luto@kernel.org> <8818c45b9ec6a04d85fabf9bb437cf119fd23659.1481575835.git.luto@kernel.org> Date: Tue, 13 Dec 2016 13:35:39 +0200 In-Reply-To: <8818c45b9ec6a04d85fabf9bb437cf119fd23659.1481575835.git.luto@kernel.org> (Andy Lutomirski's message of "Mon, 12 Dec 2016 12:55:55 -0800") Message-ID: <87mvg0kqno.fsf@purkki.adurom.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 674 Lines: 21 Andy Lutomirski writes: > Eric Biggers pointed out that the orinoco driver pointed scatterlists > at the stack. > > Fix it by switching from ahash to shash. The result should be > simpler, faster, and more correct. > > Cc: stable@vger.kernel.org # 4.9 only > Reported-by: Eric Biggers > Signed-off-by: Andy Lutomirski "more correct"? Does this fix a real user visible bug or what? And why just stable 4.9, does this maybe have something to do with CONFIG_VMAP_STACK? I'm just wondering should I push this to 4.10 or -next. This is a driver for ancient hardware so I'm starting to lean for -next. -- Kalle Valo