Message ID | 20230128000409.never.976-kees@kernel.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp1110850wrn; Fri, 27 Jan 2023 16:09:37 -0800 (PST) X-Google-Smtp-Source: AMrXdXtAtmxAT3rBIQICFol1D0g9AM7lw7kRz5cyOjIMQx2KqykFloGGQqtKy85WURQ2ypK6Sg/+ X-Received: by 2002:a05:6402:10c4:b0:48e:94ec:b7ac with SMTP id p4-20020a05640210c400b0048e94ecb7acmr39780546edu.7.1674864577306; Fri, 27 Jan 2023 16:09:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1674864577; cv=none; d=google.com; s=arc-20160816; b=W095+2LkzjPuDS0M237cpI3oGyh7j2Tmwc6LY4fh9jxap/T2rshBbnX1ZTqCiMJbbs hTUSclublrjryoprh4nmJZ04Sige9htyXkUCgGRjJIjRSgqFrvG2T3Nxh3ckWktWM9IA AvRbPB/VVO/oM2IzeogwqpHo5jHUHGredWTbZDMuqwcBjlKcKJyNBnIa9FgxxmqeJKeJ nVjmYc0Us/S74U5TXOYHWnF3Q30iahBSrkTiKSLz91mvEePXzw0IPOZ9IW4UCbC/UMGS kItraGLERvHK7URuRWIrz6SZuG5zE4dkOGNyZt2+HGONW4RgRQSI5Sup+y72GJJjMikX kTmg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=FDc1f6H36kSbMyhmdOu12h8TguEbHWVRiGzB2+CN2EQ=; b=F06Am/EcZ30c7LIUi6XmmhN7XISu+Hoh+d//t2IQ8NrZxmhWLNXENbX6QNP7mcTQCd iKBxF2pMysFpkoLx922UiDygm6NjKmZRHugXlNaambUyuCC3aLy67Hytl2cobcMWOM4K L/0qXIkpbv39vL/alvjVzVdHfLz1D+q3b6q1zcx0sj89E7ekAZeA8spSVmipcZ/NazGN ne519LY4L/c2g4DXl/uZLYImKwkfFcPdrCow9pRzY/cJag89kiHRMTPoB2xiykL8g1q+ /TpuWRwePiGBt4ELV1nH09q+lvsiS2rKAQeCsvVUz9E5cDc+031BIWgDaZ4zUNzIlrFN 2Pqw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=jqN19sWZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id v25-20020aa7d819000000b004a0e2b46929si6110084edq.515.2023.01.27.16.09.14; Fri, 27 Jan 2023 16:09:37 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=jqN19sWZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232207AbjA1AEU (ORCPT <rfc822;jesperjuhl76@gmail.com> + 99 others); Fri, 27 Jan 2023 19:04:20 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53648 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229776AbjA1AER (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 27 Jan 2023 19:04:17 -0500 Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B32CC834B2 for <linux-kernel@vger.kernel.org>; Fri, 27 Jan 2023 16:04:16 -0800 (PST) Received: by mail-pg1-x52d.google.com with SMTP id 141so4257705pgc.0 for <linux-kernel@vger.kernel.org>; Fri, 27 Jan 2023 16:04:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=FDc1f6H36kSbMyhmdOu12h8TguEbHWVRiGzB2+CN2EQ=; b=jqN19sWZ3nZ1ylcOToqEKpzql3r9UmN8+byIOuXDFEh2VxNe/47KCoXcmXX2cCO8t0 artbB2vnijdLeMOclOlwjOQ4oil+/MxPYfFhyebOQLChNRaruqY1qpqQ2eFTJSg5TdAu i1uFKylpcNV6TRc0ZpzXNmOK0MT8gRs3RUt/A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=FDc1f6H36kSbMyhmdOu12h8TguEbHWVRiGzB2+CN2EQ=; b=dDeQ08uryTUMtqqh+PMSKYq9q8/TZqsyWFkFpFkzKzfeXZJD+94IffyESFkbeeqcpN jovAwx7+q9PeHR0qRQHALyxMKU87DRp+38YzAnMBPLt0brbrBruuv4kEsVYFQG19rhP7 NPjPgBXv1rh89diJ4CiC7pzkIWDML6QR66Igqvk05bmch9FDa8M1lyNGtzI7MEdpy9cm qxfonIlKbAHSavmzWj7eKz8v9QLo4m01RXgVaK0EYC9hh1dKArSEOpSrO4JninwmEB56 bSWzQRBQg3p0+bqi0EgGuDVbMVYBkBz0d5ZG+8fwKnU2sug03mISX2JqdfxmZYjKSb/e PQhw== X-Gm-Message-State: AO0yUKUNBPYqRoD2qMRlO21jgSrp4gU3miLDswZN0GSYpaEIs4kvHEHN a1Z4h/qrhZaRA8JqyWsLq95LFQ== X-Received: by 2002:a62:b505:0:b0:593:9109:4627 with SMTP id y5-20020a62b505000000b0059391094627mr714429pfe.0.1674864256051; Fri, 27 Jan 2023 16:04:16 -0800 (PST) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id x28-20020aa7957c000000b0056bc5ad4862sm2527886pfq.28.2023.01.27.16.04.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 Jan 2023 16:04:15 -0800 (PST) From: Kees Cook <keescook@chromium.org> To: Bart Van Assche <bvanassche@acm.org> Cc: Kees Cook <keescook@chromium.org>, 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 Subject: [PATCH] scsi: aacraid: Allocate cmd_priv with scsicmd Date: Fri, 27 Jan 2023 16:04:13 -0800 Message-Id: <20230128000409.never.976-kees@kernel.org> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=2826; h=from:subject:message-id; bh=8KFZgqjwwJO+qq8QfdeM9HK9KDv6PDJJEB0n/EnuyKA=; b=owEBbQKS/ZANAwAKAYly9N/cbcAmAcsmYgBj1GZ9mcYxxmBFWjb9WJlVcSCr1yuma3vzlXTE6ry5 XFz/f5+JAjMEAAEKAB0WIQSlw/aPIp3WD3I+bhOJcvTf3G3AJgUCY9RmfQAKCRCJcvTf3G3AJnDqD/ 47sfkHG+/a3xdJClnia5fi++tP4YYoZynZ5fqtTBOFFNLI319Zlz2wlqHjfcc1sz2eweq62ksWB2TB YW6aC0dSd+5FoXkT4uVVml2nZDZxy0E9cMn2qJ5pFbZrfCZpmSrashWSunKUeB6Eb4TfkgLG61WIFP SNYnzVIz4DVO/INJgJobsjQyp4axpBZCRpmBiw14V4sIv3fDg+OWXVTqUNHFMm1DULBEPAVxaBx+FQ Vti5fflR3WJMRI7HCoNdsO+iRnZ+FyCybX4oNoYu2SVas+pzDJfwP+NUWc/j5M0ALVZTshiuQBol6U c+3T6d0A/LN3kWyICneQSULVNfMLPw8hcgAZHl9v3tWN5l2O40zGRqliaTZDJ31k+Tfc3vtTzp1aVy N1rAU9Q6dCDJgAPqm8cu6SCUFyQawV5xfY9S0qh4M0kGY0kPaAreBvLizpLSd6rWgB/5eIY+1Lluu2 tEKhMvRr0BQTUtBNKtPxtZYjJtBFAjetGQ8g3ez42Ty0CZ0nONtVCkcAi1PsysjehWBTlTrau8Zr2i /tSBvd730+TfBbfhB3sZcDKpuWL6mL59ZKPRX+8as6QZklDgblu72PXEY+nA4K6uArXk0P9m50S1wY 3qo8bUnPG18px6gVheiFE0q7XMDZ9RHj+yhfnrvE8zSygQh2akGwWKFqbieQ== X-Developer-Key: i=keescook@chromium.org; a=openpgp; fpr=A5C3F68F229DD60F723E6E138972F4DFDC6DC026 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1756222798881126332?= X-GMAIL-MSGID: =?utf-8?q?1756222798881126332?= |
Series |
scsi: aacraid: Allocate cmd_priv with scsicmd
|
|
Commit Message
Kees Cook
Jan. 28, 2023, 12:04 a.m. UTC
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=]
841 | status = cmd_priv->status;
| ^~
In file included from ../include/linux/resource_ext.h:11,
from ../include/linux/pci.h:40,
from ../drivers/scsi/aacraid/aachba.c:22:
In function 'kmalloc',
inlined from 'kzalloc' at ../include/linux/slab.h:720:9,
inlined from 'aac_probe_container' at ../drivers/scsi/aacraid/aachba.c:821:30:
../include/linux/slab.h:580:24: note: at offset 392 into object of size 392 allocated by 'kmalloc_trace'
580 | return kmalloc_trace(
| ^~~~~~~~~~~~~~
581 | kmalloc_caches[kmalloc_type(flags)][index],
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
582 | flags, size);
| ~~~~~~~~~~~~
Fixes: 76a3451b64c6 ("scsi: aacraid: Move the SCSI pointer to private command data")
Cc: Bart Van Assche <bvanassche@acm.org>
Cc: Hannes Reinecke <hare@suse.de>
Cc: Himanshu Madhani <himanshu.madhani@oracle.com>
Cc: Adaptec OEM Raid Solutions <aacraid@microsemi.com>
Cc: "James E.J. Bottomley" <jejb@linux.ibm.com>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: linux-scsi@vger.kernel.org
Cc: stable@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
---
drivers/scsi/aacraid/aachba.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
Comments
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
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=] > 841 | status = cmd_priv->status; > | ^~ > In file included from ../include/linux/resource_ext.h:11, > from ../include/linux/pci.h:40, > from ../drivers/scsi/aacraid/aachba.c:22: > In function 'kmalloc', > inlined from 'kzalloc' at ../include/linux/slab.h:720:9, > inlined from 'aac_probe_container' at ../drivers/scsi/aacraid/aachba.c:821:30: > ../include/linux/slab.h:580:24: note: at offset 392 into object of size 392 allocated by 'kmalloc_trace' > 580 | return kmalloc_trace( > | ^~~~~~~~~~~~~~ > 581 | kmalloc_caches[kmalloc_type(flags)][index], > | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 582 | flags, size); > | ~~~~~~~~~~~~ > > Fixes: 76a3451b64c6 ("scsi: aacraid: Move the SCSI pointer to private command data") > Cc: Bart Van Assche <bvanassche@acm.org> > Cc: Hannes Reinecke <hare@suse.de> > Cc: Himanshu Madhani <himanshu.madhani@oracle.com> > Cc: Adaptec OEM Raid Solutions <aacraid@microsemi.com> > Cc: "James E.J. Bottomley" <jejb@linux.ibm.com> > Cc: "Martin K. Petersen" <martin.petersen@oracle.com> > Cc: linux-scsi@vger.kernel.org > Cc: stable@vger.kernel.org > Signed-off-by: Kees Cook <keescook@chromium.org> > --- > drivers/scsi/aacraid/aachba.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/scsi/aacraid/aachba.c b/drivers/scsi/aacraid/aachba.c > index 4d4cb47b3846..24c049eff157 100644 > --- a/drivers/scsi/aacraid/aachba.c > +++ b/drivers/scsi/aacraid/aachba.c > @@ -818,8 +818,8 @@ static void aac_probe_container_scsi_done(struct scsi_cmnd *scsi_cmnd) > > 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; Reviewed-by: Hannes Reinecke <hare@suse.de> Cheers, Hannes
On 1/27/23 16: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: [ ... ] Bart Van Assche <bvanassche@acm.org>
On 28/01/2023 18:40, Vegard Nossum wrote: > 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. How this driver allocates a SCSI cmd in this fashion is not proper, and hostt->cmd_size would only apply when the SCSI command is allocated in the proper fashion, that being as a request - __scsi_execute() -> scsi_alloc_request() being an example. Hannes did have a conversion for this driver to allocate a request in https://urldefense.com/v3/__https://lore.kernel.org/linux-scsi/8efc0e24-3000-39d9-7676-e0896145f247@suse.de/__;!!ACWV5N9M2RV99hQ!MealB8BN3q8cxYSaB7yKEbHyDmFTNl0YNVQXpVw8Zd0-iNqQ-k4IFxnqONpixfavb0DqGWnkbDVjBJCE22mYq5Ly8Xs$ - hopefully we can progress that work at some stage. Thanks, John
Kees, > 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: Applied to 6.3/scsi-staging, thanks!
On Fri, 27 Jan 2023 16:04:13 -0800, 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=] > 841 | status = cmd_priv->status; > | ^~ > In file included from ../include/linux/resource_ext.h:11, > from ../include/linux/pci.h:40, > from ../drivers/scsi/aacraid/aachba.c:22: > In function 'kmalloc', > inlined from 'kzalloc' at ../include/linux/slab.h:720:9, > inlined from 'aac_probe_container' at ../drivers/scsi/aacraid/aachba.c:821:30: > ../include/linux/slab.h:580:24: note: at offset 392 into object of size 392 allocated by 'kmalloc_trace' > 580 | return kmalloc_trace( > | ^~~~~~~~~~~~~~ > 581 | kmalloc_caches[kmalloc_type(flags)][index], > | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 582 | flags, size); > | ~~~~~~~~~~~~ > > [...] Applied to 6.3/scsi-queue, thanks! [1/1] scsi: aacraid: Allocate cmd_priv with scsicmd https://git.kernel.org/mkp/scsi/c/7ab734fc7598
diff --git a/drivers/scsi/aacraid/aachba.c b/drivers/scsi/aacraid/aachba.c index 4d4cb47b3846..24c049eff157 100644 --- a/drivers/scsi/aacraid/aachba.c +++ b/drivers/scsi/aacraid/aachba.c @@ -818,8 +818,8 @@ static void aac_probe_container_scsi_done(struct scsi_cmnd *scsi_cmnd) 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;