From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753275Ab2ITHNV (ORCPT ); Thu, 20 Sep 2012 03:13:21 -0400 Received: from mail-pb0-f46.google.com ([209.85.160.46]:40865 "EHLO mail-pb0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751165Ab2ITHNU (ORCPT ); Thu, 20 Sep 2012 03:13:20 -0400 MIME-Version: 1.0 In-Reply-To: References: <1348090423-32665-1-git-send-email-minipli@googlemail.com> <1348090423-32665-6-git-send-email-minipli@googlemail.com> <1348094309.2636.80.camel@bwh-desktop.uk.solarflarecom.com> Date: Thu, 20 Sep 2012 09:13:19 +0200 Message-ID: Subject: Re: [PATCH 5/6] xfrm_user: ensure user supplied esn replay window is valid From: Mathias Krause To: Ben Hutchings Cc: "David S. Miller" , Steffen Klassert , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Martin Willi Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 20, 2012 at 8:12 AM, Mathias Krause wrote: > What still might happen is the overflow in xfrm_replay_state_esn_len() > resulting in a to small bitmap allocation for the requested replay > size. But that gets catched in xfrm_init_replay(). Little late, but > hey. Sorry, I mixed that up. The replay_window check in xfrm_init_replay() has only little to do with the bmp_len overflow. But changing the return type of xfrm_replay_state_esn_len() to size_t and by doing so, making the all the size compares operating on positive values, we'll at least allocate enough memory to not run into memory corruptions. Though, the replay window will be much smaller, than requested -- due to the overflow. But userland should expect this. A check for some upper limit in verify_replay() could catch this early. Mathias