From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 48731C00145 for ; Thu, 15 Dec 2022 06:36:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229726AbiLOGgC (ORCPT ); Thu, 15 Dec 2022 01:36:02 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41270 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229448AbiLOGgA (ORCPT ); Thu, 15 Dec 2022 01:36:00 -0500 Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7A38AB1CD; Wed, 14 Dec 2022 22:35:59 -0800 (PST) Received: by mail-pf1-x432.google.com with SMTP id d82so6042663pfd.11; Wed, 14 Dec 2022 22:35:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; 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=+Zntq683qGGW9uGqNJUwpXpXMNNKQE/pGbpUuo9i8rA=; b=guyIeSLZpY8xMW9BqgiBAuwBAeuy4bh5lN7jmOI1KyQAWeiGe+rYvJiYtZP8ehiFTw M6RlR+Hwkcb+l+IHxUVOAiBJpANiV0oCdRqH9W3Qbw3oimOtQG7RptutNUtfBud0Cn/J JkRPM091LtaXylCndoUIKe9gfMcFrPQW2b0wf3MooFotzQl94+8EMrtxVKMU+UooUEHl 0Bv0rnP1c7EBp5nAyBjN1MRno7HPEAQrZdv30wMpyzJ2dlSqplCEIYp4Scr7ALdI3W6q KII3vTiKLKVxVi7Pp0CopY3FV7YQpl4ljXCLvGQb7z2x5zqARoB7TmdJjdGY8Nm71ZaZ 3raA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=+Zntq683qGGW9uGqNJUwpXpXMNNKQE/pGbpUuo9i8rA=; b=gOYcCafbccFwRXKl5gfe99yfO61pmHuCYDojjb/b9zqY5WLmPXpUI5aQAnpNspftIi Mw0cW8DSnDk5HFT6B35XS56+VTIIIlzEPq9vDTJA+8Dw+Q+VTQwdyrBkusgZx53p96Jt ymDr/IWSEu9KpCtvbdb3afj4w8nwgm6jrydi0+zCuliu393ZOkrFLESujEHqK9zp75VA ApNoHb9Myu5hBsejHxL4Am5eomNSIF20tiWfQI8R/DLKD8rnEqoGoKxzus33ceABntQo YSHN6iMH1gXMjImtG3UhNzxvsT+oj/wg2OmAWakeKEh2YTaJzcddiwrKxoImQYPV0v2t hNXQ== X-Gm-Message-State: ANoB5pkBmcphU0jRtUENR/3VkfhJ26dIRyOV1TCu/dMbKBiXMXFlpq2T xYtoNfOyqggSe7kDjyeysTw= X-Google-Smtp-Source: AA0mqf5JgZozvKq87LDQbHlR0OP/IEDZxtyuCWF8YtZEY8Ml4kbCpZ5+ZkNiWYn2Up22K3+XT4o7hg== X-Received: by 2002:aa7:99d0:0:b0:576:f200:bf1b with SMTP id v16-20020aa799d0000000b00576f200bf1bmr5537207pfi.3.1671086158996; Wed, 14 Dec 2022 22:35:58 -0800 (PST) Received: from mail.google.com (125-237-37-88-fibre.sparkbb.co.nz. [125.237.37.88]) by smtp.gmail.com with ESMTPSA id 202-20020a6214d3000000b005774f19b41csm898549pfu.88.2022.12.14.22.35.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 14 Dec 2022 22:35:58 -0800 (PST) Date: Thu, 15 Dec 2022 19:35:52 +1300 From: Paulo Miguel Almeida To: Andy Shevchenko Cc: Kees Cook , Arnd Bergmann , Greg Kroah-Hartman , Ilpo =?utf-8?B?SsOkcnZpbmVu?= , Jiri Slaby , Haowen Bai , linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org Subject: Re: [PATCH] [next] pcmcia: synclink_cs: replace 1-element array with flex-array member Message-ID: References: <202212141124.736E3DE2A8@keescook> <202212141347.9AD66DEBC8@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Dec 15, 2022 at 05:29:15PM +1300, Paulo Miguel Almeida wrote: > On Thu, Dec 15, 2022 at 12:06:46AM +0200, Andy Shevchenko wrote: > > On Wed, Dec 14, 2022 at 11:49 PM Kees Cook wrote: > > > On Wed, Dec 14, 2022 at 10:39:52PM +0200, Andy Shevchenko wrote: > > > > Yes, and Try to make it work with __packed. As I said, the problem is > > > > that the code is relying on something which is architecture dependent > > > > strictly speaking. And hence I disagree with Kees that v2 is okay to > > > > go. > > > > > > I meant that v2 is functionally identical to the existing code. > > > > Ah, sorry for misunderstanding. > > > > I agree with using __packed attribute to remove the extra padding (and > for the reasons you mentioned before). That would reduce the sizeof(RXBUF) > from 8 to 5 (which is good) but that is still 1 byte "too much". > > Piggying back on a suggestion Kees gave before: > > - info->rx_buf_size = sizeof(RXBUF) + info->max_frame_size; > + info->rx_buf_size = sizeof(RXBUF) - 1 + info->max_frame_size; > > That way RXBUF->data will point to the first byte of the frame_size > (MGSLPC_INFO->max_frame_size) which is what is actually needed. > I chose my words poorly here... sorry my brain is a bit fried today. Let me rephrase that last sentence. After that change (or similar change), RXBUF->data will point to the first byte of the buffer allocated during the initialisation process. (which is limited/controlled by the size of MGSLPC_INFO->max_frame_size)... so no 'extra byte/padding' will be there. - Paulo A. > > > > The full change should be something like > > > > > > > > check_add(sizeof(), max_frame_size) > > > > kcalloc(8, size) > > > > > > Right -- this would fix the existing mistakes in size calculation (and > > > is certainly better). > > > > Glad to hear that we are on the same page. > > > > That makes sense to me. > > thanks! > > - Paulo A.