Message-ID: <1bb8de35-16ba-6c7c-0ef6-67a7226a0a2d@oracle.com>
Date:   Sat, 28 Jan 2023 19:40:12 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.4.2
Subject: Re: [PATCH] scsi: aacraid: Allocate cmd_priv with scsicmd
Content-Language: en-US
To:     Kees Cook <keescook@chromium.org>,
        Bart Van Assche <bvanassche@acm.org>
Cc:     Hannes Reinecke <hare@suse.de>,
        Himanshu Madhani <himanshu.madhani@oracle.com>,
        Adaptec OEM Raid Solutions <aacraid@microsemi.com>,
        "James E.J. Bottomley" <jejb@linux.ibm.com>,
        "Martin K. Petersen" <martin.petersen@oracle.com>,
        linux-scsi@vger.kernel.org, stable@vger.kernel.org,
        linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org
References: <20230128000409.never.976-kees@kernel.org>
From:   Vegard Nossum <vegard.nossum@oracle.com>
In-Reply-To: <20230128000409.never.976-kees@kernel.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?MXhaL2tkMFFiLzhDOVp1ZDRHMko4aEFJalJjbUl0WTRndGl0TUhkTWtlZlRa?=
 =?utf-8?B?VDlsSFFiQjhPMmNZOWUyZFNvcDhIVmsyV0lkT2kxd1p2SVM2THNKb2lRdkVr?=
 =?utf-8?B?cUlGTmQ0L1ZmSEpGS1IxU2paZklybDRCRmFIcWdPZXhJSlZWVnVZR08zd3ZQ?=
 =?utf-8?B?QWxBclBsakFCU24xT2VOTHhCN2xCVG9KcVBWV1VFSktVdm5ua3drTUFqeGxS?=
 =?utf-8?B?bm9icEMrR3VnWnJIc3FoeDR4S25aZU1TWHRwZ3d0ZWNsVlhsOWN3aEYwbU9w?=
 =?utf-8?B?UFUwdHd3aTdZakdLNkVpeWhBWUJqbjA0am9uNmc3S3M0dTJMaEZ1YWRVSStZ?=
 =?utf-8?B?OUZGTXlwRlp1b3RsMHdadkZNWVR5cFByN1Z5eStaU3pmQjBlZHJYZ2dUNWth?=
 =?utf-8?B?QUZ1QzNYbjhXWG9NcEZJV2FiVnQyL2JaSXBCUGNtNTRBOCtVN0d3OG1pdWFr?=
 =?utf-8?B?VGlqZ0RqOE9Rbys4MnNTZDlBeWNHZm9jRUxFcFZJQmxHRk9GSUpiRE1IQmpz?=
 =?utf-8?B?dnRDMnJMMkxTYW9jZGRNWGRoN1JSazJWZ2JoUkhuMldaSXBHbWpqcGtoUzVD?=
 =?utf-8?B?enlGeXJQZUt0czBCUEZleHdzV0cxMGxrT1U1clNWK2tqcFAwNGt0cXhjYTRi?=
 =?utf-8?B?NXNQaEJNZ0VkSkV1VWFLaWJyQU1KYmZEYmJjUmN1V25vTVBtdkNNM0dyajlZ?=
 =?utf-8?B?dXZnOFVZRHkrZVRuZ1MxRW9mQk9lVEZnSldSVGx5ZTl5ZmQ3c1dIUlBQeVVB?=
 =?utf-8?B?YkZML1J5UlVhY1JwUWhzdUZhNW1KS2FrUmJiU3E3UUZ6VjloOS9HNjU5WUhV?=
 =?utf-8?B?ajl6OFhkZzQ4WTNaVU9ac1QzOTZybWg1LzFpaFVrd01zUFZ1MkIzZWVhd0Nu?=
 =?utf-8?B?bWtOY0J5dm9KcUM4WHpkcXE3RStDTWgxZzlYMUp4TUpEd0k5Wm5aL0t1YUFM?=
 =?utf-8?B?aWtJbTJnRW1WWldkMWNJVnM3OFB3QUNYdldmRmJWV29pa200U1ZZeWlmWUFM?=
 =?utf-8?B?UXBQWmZiTlhSWW1McU1DWVJUNGpuZDRTM3ErTitKVEVBQ042WnN5TEFmNy9m?=
 =?utf-8?B?RVgwSGJHOFcvMExUMmJUV2RraEtNQWMxSjV4aUZrWVdTd2xEeEdwU3lZYW9X?=
 =?utf-8?B?aDc2dzl5N280aW9lMmgwYWpienAvbWxTb2I1dXYzZmZLdHRvNHVjd0dXelg5?=
 =?utf-8?B?TFFoNGJtVHNzSmtYUGI4YmRNNldBL2cxNEVoNFFZTGJzV0ZDenVmVmZlOVpS?=
 =?utf-8?B?dE53M242cFdRMFB6QzNuTUpWTUZUQnVsSk15RXBNK3hyNzQxUS83WFNBWFgw?=
 =?utf-8?B?ckp5SDNnUU4vd3VnS05aMWU0Rkc5VXh1TUV1S3UyVGVrQkhEVWRZL2ZjeUVB?=
 =?utf-8?B?QzU1cnRYOEpDSTAyZldVWVVtMmw5UklpQ1R4VTZQZ21iajB3Z2xtOVcycTRG?=
 =?utf-8?B?Z1JGMXgvZEpzTnRzNzlYZDNiTUdhekNRc0R6ejJuazBiaUF0WGlONklnNFFi?=
 =?utf-8?B?Ym1kcm0ycmJtQ1gyc3M4QktmbXF0R2R3NVFFbFZqY0d5Y29TcUhQS0hHS2lz?=
 =?utf-8?B?OUlWaEFzVEQ5WVU3QjZaTERPOWV5MVJYOFlHTUhKUFBkeFBxZFRtT3ZlY2pl?=
 =?utf-8?B?U25peVo4UUlPNzZNR3JyY2hFMFV6NEpTNjl5aXQwYUd3UlRZZVBLQisvU2hX?=
 =?utf-8?B?T2o2WGZkbXhQNmsydXRlVVNqM1ozOXVIRWNnWnZ5bW4wNDZ3TklnbmNpbDNa?=
 =?utf-8?B?L1o4THF5YXd0eTFNOHRRQU8vYU84YURjTE1GTm4xeHRTd20wOWhSd0ZINm1p?=
 =?utf-8?B?dCtzSGdDeXhrSERPcnhudFZ3dGkxY2tKcWEvWjh0ekp1elpsRHNvVVBEL2cw?=
 =?utf-8?B?c1pQaXJWdmNmVGV4UTk2ZVh5RDN3ZGMyZGhLUGxxMGF4L0dHdVA0WUZJamxl?=
 =?utf-8?B?czAxbjRMQ2k0QXlYK1BmTUdOczVPWUEraFREOWlpeWdmN1VLOEJEVG4wanZY?=
 =?utf-8?B?Z09MMFNxNE45UzE3Q3cyc1JaanUyRDFkOGg1dFRxWGVFOGl5Tk9CU0lIQzRa?=
 =?utf-8?B?V0dIV0RYMTh6ZmFMdW81UHUxSjB0eDlKNFNGVFMxN09KN3FKRSswMlRjVXNI?=
 =?utf-8?B?Q2xaT1pmdXNHaXgxNWNCQ0JycVZrVmtXWExrSDNpU1lNU2VCUjB3ODNyaVRQ?=
 =?utf-8?B?TXc9PQ==?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: FMN9ZBeNaEqmq/Gi+Lo2qmp+Xm29OiXaMgVa1tpavCRMlp9THQDyBnywrAEWEI7tT1TMlHzi1MaS7ssoeQcLbvmWnHRt70vAbgSZTlSJWFnZWDZvlEWRJq43xY9HOIBXr5jo/htt6SXTW5kpzc8SZbgEYslgQB79gFPG488BAkKlAkKcuUfHLfONgrcTWhdVpldw4IPnMaVhbSpQHiBLaWF+dARGtMSPVJwTG/Qd/de+5OsAInzrurHd3j+tyS0m4XMKyAxg4JuJs+aTO16JF/CHopAAT4p2WCdW36Aq5jP5kaKcJ5ulPrIdaUIrKRbi+lQR6E3Usom+pyBYwnxSsxw6+e/n/r/hs6gG1ha/RQhAUviW6mnyqf6Pr8ddkTlD2ycVUzYfFnWm6+Ig1LJVHIsoc/7Jks+Fbh/l6C4W87/CI0g80NPMWEGqv8vb3obL5haVWRSNfXdhUQURF8UIcC4N8Y3A4JPqwqU6298G3TTy3IfGRxmWUtyAmNGRN/hzJcfCzAREFIZp1+59skfe6D38f7iB5ywkZdUuwBSZtgVmghl8ADGtZcvGyMME5LY2LddtVXR2Aa0gxmXyX5Oa8qf4TFF9RLYkqCnc+ykcgNQEfLiscxWS5/L3VVTnt6WYoXmE/k6Uu5CEV3Dz4KVMT7Dbb/C3pxN5mpmqi0EmZIvysHYCGEsKq2ibeduEBgW/YD+0RpgQGGbh1A6hGnFQ37Dka9wfb+wrlrECOgj2YvhzovNAkKTyaAjVNEccB7G/7mvMoD4AA3sX5qz3XwqxoKZgRuISmXCw1mTU1nQd/CYdr9GJJvRv3wmqyM5yeKlkIOIncooJY+eHnx9saXnVTg9ZASF26gPb5cuJGqpj3clnL5NbQmCsppZRUQUGPZfcD804xYdYbctzHj96aeRq8MVAI0N/Y5eeKvQrTCpa4+Y=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0f5708b4-1ae1-4cc2-7832-08db015f1b39
X-MS-Exchange-CrossTenant-AuthSource: DM8PR10MB5430.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jan 2023 18:40:21.3182
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: UD12OMYtaIb8MECK5pnzCbbP5U8XzxohTyLAZyFEBJSQOrqRXGGygrihi3Tgf56meo2k2rFELgYuBpUMGXEinPknEgpWGcUfq11KjuXoDh4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR10MB6755
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.219,Aquarius:18.0.930,Hydra:6.0.562,FMLib:17.11.122.1
 definitions=2023-01-28_10,2023-01-27_01,2022-06-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 adultscore=0
 suspectscore=0 mlxscore=0 spamscore=0 phishscore=0 bulkscore=0
 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2212070000 definitions=main-2301280182
X-Proofpoint-GUID: VX7_d-zKEthmJhO9z7gOJ7HSKmfdOZvO
X-Proofpoint-ORIG-GUID: VX7_d-zKEthmJhO9z7gOJ7HSKmfdOZvO
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Just a couple of observations.

On 1/28/23 01:04, Kees Cook wrote:
> The aac_priv() helper assumes that the private cmd area immediately
> follows struct scsi_cmnd. Allocate this space as part of scsicmd,
> else there is a risk of heap overflow. Seen with GCC 13:
> 
> ../drivers/scsi/aacraid/aachba.c: In function 'aac_probe_container':
> ../drivers/scsi/aacraid/aachba.c:841:26: warning: array subscript 16 is outside array bounds of 'void[392]' [-Warray-bounds=]

An object of size 392 would get allocated with size 512 (at least by
SLUB, AFAICT), so the risk of something going terribly wrong is probably
fairly small. Not that it shouldn't be fixed, of course...

KASAN should have caught this too, right? Does this mean nobody's tried
this driver with KASAN, or is this some kind of rare code path? (Just
asking for my own understanding.)

>   int aac_probe_container(struct aac_dev *dev, int cid)
>   {
> -	struct scsi_cmnd *scsicmd = kzalloc(sizeof(*scsicmd), GFP_KERNEL);
> -	struct aac_cmd_priv *cmd_priv = aac_priv(scsicmd);
> +	struct aac_cmd_priv *cmd_priv;
> +	struct scsi_cmnd *scsicmd = kzalloc(sizeof(*scsicmd) + sizeof(*cmd_priv), GFP_KERNEL);
>   	struct scsi_device *scsidev = kzalloc(sizeof(*scsidev), GFP_KERNEL);
>   	int status;
>   
> @@ -838,6 +838,7 @@ int aac_probe_container(struct aac_dev *dev, int cid)
>   		while (scsicmd->device == scsidev)
>   			schedule();
>   	kfree(scsidev);
> +	cmd_priv = aac_priv(scsicmd);
>   	status = cmd_priv->status;
>   	kfree(scsicmd);
>   	return status;

aac_priv() uses scsi_cmd_priv() which has the comment:

/*
  * Return the driver private allocation behind the command.
  * Only works if cmd_size is set in the host template.
  */

This is set for this driver:

static struct scsi_host_template aac_driver_template = {
[...]
    .cmd_size                       = sizeof(struct aac_cmd_priv),

I looked around to see if there was some kind of "allocate cmd" helper,
but couldn't find it -- scsi_ioctl_reset() allocates one (together with
struct request) and there are a few uses of ->cmd_size in
drivers/scsi/scsi_lib.c but there doesn't seem to be a common code path
for this.

I guess you could use dev->host->hostt->cmd_size or something, but that
doesn't seem worth it since this is driver specific and we already know
what the correct value should be.

FWIW:

Reviewed-by: Vegard Nossum <vegard.nossum@oracle.com>


Vegard