From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com [209.85.128.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C9471BA3D for ; Sun, 9 Aug 2026 18:40:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786300840; cv=none; b=EM7FKIVPsgttSFH75ozzA1OwGi7jNZIeh1YiXnRPHcZK4e4Pb90owiZmGWBCvd780IYJ1TS197sGK184nLNT6s1uY8Pi3Md51ubuRCHLRAAIT8jqLA///fdWYVG5scWozEpNDEGth50bCO+Vba27QYkfGgZznxDb7IcT/h1x1CU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786300840; c=relaxed/simple; bh=BTaA6JwaIpBYpd3xTefpiG6O1M2Eh4d5feVxt6nr09g=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=GDblvLJV5ossngYyq6Acu3Xh77d43dm07OtTyx+702+Ws+oJjYEXeROBMp6Jt26Zy4qXMAgzG9XIt7YB/bUooy1IonKcQuIQ6tHPfWd+jw3h2AFHilW3sz8SwIT17tE7eU/B92DEO6E0UFsLTPKGLUrgWzE7Rvk8JepyuXzK+Rg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=philpotter.co.uk; spf=pass smtp.mailfrom=philpotter.co.uk; dkim=pass (2048-bit key) header.d=philpotter-co-uk.20251104.gappssmtp.com header.i=@philpotter-co-uk.20251104.gappssmtp.com header.b=OkjJ71iU; arc=none smtp.client-ip=209.85.128.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=philpotter.co.uk Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=philpotter.co.uk Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=philpotter-co-uk.20251104.gappssmtp.com header.i=@philpotter-co-uk.20251104.gappssmtp.com header.b="OkjJ71iU" Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-495757ccbc1so14146685e9.2 for ; Sun, 09 Aug 2026 11:40:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=philpotter-co-uk.20251104.gappssmtp.com; s=20251104; t=1786300837; x=1786905637; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=Q6O/ty+EeA9XL289lj4SeUbLrncl33JHOLZKGfvoUwI=; b=OkjJ71iUSY9YdgalCihkPIrdfvn4WwOrRDC9uxYjZkQl2/EDbu9qf4ZJHJNpnD9kpg pLJGcqcVSKEtXRA7sNcT3g+mtcI8v3Kf5KxlATK3N8/b5Df708DODU7QQFbUQhL0Jxwa /e9QigSQYuqljFVMvAF9ost3HVzcM6Plu7H2VIoxZ8mKhO0ZExfZC2sdoTQU6qJZgDsg +8wwgbm9ktXG00fdj0bzr5QKSN02TM4Tk732BIhRD+e+DZJbunMrPnI+7nmfm7nMqTd1 6c3eTLikqR4lAxrYOBLdhiXCe36mcSn+RW1Ycg4jkjyTPd9Z8E228u1GRujyzZ0LI4/M PBnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786300837; x=1786905637; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=Q6O/ty+EeA9XL289lj4SeUbLrncl33JHOLZKGfvoUwI=; b=iDyCb4MkkYpgWIVPcEIZz70jk84UsOQYfOL1cXU1leXyccyCnnfGC7uIRxB3dDWUEL lZNHOYZG3t86AIzM7xt9Jnd8eWhINOr74X2p/uVcCg9l4/wuw66LdxCM4mHXLwzTwTew XMCzdIzPLtT7r3ZNS7FVWbrYBPLuHLlfcy9l9atv0hTRkx8mjzW9ezUNeL0VQMp6UVqZ +wuGtzbwkcp9cHrg8U5tza9hEizMPFi5g0+QL27+Ikb5N8HZcic60kjrEKvq+qOufo6R jD89Cq8+FZK8ukHy7HOffyMwYNZiPOFXku5E9Lc8yPAKBRWPV7TDzhUPphRCC5NDpNaV H2nA== X-Forwarded-Encrypted: i=1; AHgh+RpLWymJY8GyJ5NQULMgSXLMSAA+bBOEyfdzmJHX9+ERR6BWZdpoe4nCPCnij/k2XR7InS2aW487ABWoocQ=@vger.kernel.org X-Gm-Message-State: AOJu0YxP+JKLgXqEh9GaPg1vKPi+nA68sZYEdBEmwZHy6LzwboMh+4QM zpbpC/zqKsGZ6L9IIYUpWBof0790Ayv1A7LvJ5n4RbXS57NeQMm0Tkkv/gTM6bbzM5w= X-Gm-Gg: AR+sD10TkQOUFmehyyE2eTxtg6Sn4Di80sPhAA9VpxH8H1ZmIQRtiSjWfUODNqyR2Pa XefQycHb4mLcq5Z/x2SCJV0zD9xrF7yj16Mb9AkAy23ZxxmHQLZVtkp3dUlnylv/uLCK4xFJruh QayagaJp0bGhRUB6RLWt+jfqILr3XYAHaftVYYFD6WInZHjumtZmxtUZkhpPo2LSAtvWboRKd9a lqkVPhf82Gz6cejX/tw6NH5NTE8dR5Iaxlpapd8WgQLV+W023Y6s1Qd0gtiJMor1K/xikq4apYB VZkBwHP2EkTT32yvb+Y0cZH4hI/U9ZT63M6E7ZelL1Xsqss8Gr9fGwKJcVyrRLZMbUha/03Wwpb ZjPOir/bdK2J04Dr3qf8BkFfCtVoBdS9ygGhy64R8tASXypIOE05twHnAUWK+spsWGiZtO91WFF 0gPAQqBG9QMQJPj3ESOo1j4LquDkB3XoBJI/cXW7LL/A4Z0Np92bMtIJ+NGc/nmWiOE31ORqv/o czvZX1D0tTDI2Jdf/wKntopqLRmdUZjDFuD4cq2JXMvDcM= X-Received: by 2002:a05:600c:6a8a:b0:498:ee7:e407 with SMTP id 5b1f17b1804b1-4994e7d3f2fmr414861075e9.17.1786300836642; Sun, 09 Aug 2026 11:40:36 -0700 (PDT) Received: from equinox (2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6.1.f.d.0.b.8.0.1.0.0.2.ip6.arpa. [2001:8b0:df16::2]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4995427a404sm337108885e9.9.2026.08.09.11.40.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 09 Aug 2026 11:40:36 -0700 (PDT) Date: Sun, 9 Aug 2026 19:40:34 +0100 From: Phillip Potter To: Sreeraj S Kurup Cc: Phillip Potter , linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] cdrom: fix stack memory leaks in ioctl handlers Message-ID: References: <20260804164728.3636-1-sreekuttan2156239@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260804164728.3636-1-sreekuttan2156239@gmail.com> On Tue, Aug 04, 2026 at 04:47:28PM +0000, Sreeraj S Kurup wrote: > Multiple ioctl handlers in drivers/cdrom/cdrom.c allocate structures on > the kernel stack that are subsequently copied back to user space via > copy_to_user(). Uninitialized structure padding bytes or unpopulated > fields in these stack-allocated structures leak sensitive kernel stack > memory to user space. > > Explicitly zero-initialize local structures across the affected output > ioctl handlers using standard {0} initialization: > > - cdrom_ioctl_multisession: struct cdrom_multisession info > - cdrom_ioctl_timed_media_change: struct cdrom_timed_media_change_info > - cdrom_ioctl_get_mcn: struct cdrom_mcn mcn > - cdrom_ioctl_get_subchnl: struct cdrom_subchnl q > - cdrom_ioctl_read_tochdr: struct cdrom_tochdr header > - cdrom_ioctl_read_tocentry: struct cdrom_tocentry entry > - mmc_ioctl_cdrom_subchannel: struct cdrom_subchnl q > > This prevents kernel stack memory disclosure vulnerabilities when > copying data structures back to user space. > > --- > v2: > - Expanded coverage to all remaining ioctl handlers in cdrom.c that > copy stack structures back to user space. > > Signed-off-by: Sreeraj S Kurup > --- > drivers/cdrom/cdrom.c | 14 +++++++------- > 1 file changed, 7 insertions(+), 7 deletions(-) > > diff --git a/drivers/cdrom/cdrom.c b/drivers/cdrom/cdrom.c > index 4f1fd389260f..85be658bbfa3 100644 > --- a/drivers/cdrom/cdrom.c > +++ b/drivers/cdrom/cdrom.c > @@ -2254,7 +2254,7 @@ EXPORT_SYMBOL_GPL(cdrom_multisession); > static int cdrom_ioctl_multisession(struct cdrom_device_info *cdi, > void __user *argp) > { > - struct cdrom_multisession info; > + struct cdrom_multisession info = {0}; > int ret; > > cd_dbg(CD_DO_IOCTL, "entering CDROMMULTISESSION\n"); > @@ -2361,7 +2361,7 @@ static int cdrom_ioctl_timed_media_change(struct cdrom_device_info *cdi, > { > int ret; > struct cdrom_timed_media_change_info __user *info; > - struct cdrom_timed_media_change_info tmp_info; > + struct cdrom_timed_media_change_info tmp_info = {0}; > > if (!CDROM_CAN(CDC_MEDIA_CHANGED)) > return -ENOSYS; > @@ -2510,7 +2510,7 @@ static int cdrom_ioctl_get_capability(struct cdrom_device_info *cdi) > static int cdrom_ioctl_get_mcn(struct cdrom_device_info *cdi, > void __user *argp) > { > - struct cdrom_mcn mcn; > + struct cdrom_mcn mcn = {0}; > int ret; > > cd_dbg(CD_DO_IOCTL, "entering CDROM_GET_MCN\n"); > @@ -2598,7 +2598,7 @@ static int cdrom_ioctl_changer_nslots(struct cdrom_device_info *cdi) > static int cdrom_ioctl_get_subchnl(struct cdrom_device_info *cdi, > void __user *argp) > { > - struct cdrom_subchnl q; > + struct cdrom_subchnl q = {0}; > u8 requested, back; > int ret; > > @@ -2629,7 +2629,7 @@ static int cdrom_ioctl_get_subchnl(struct cdrom_device_info *cdi, > static int cdrom_ioctl_read_tochdr(struct cdrom_device_info *cdi, > void __user *argp) > { > - struct cdrom_tochdr header; > + struct cdrom_tochdr header = {0}; > int ret; > > /* cd_dbg(CD_DO_IOCTL, "entering CDROMREADTOCHDR\n"); */ > @@ -2669,7 +2669,7 @@ EXPORT_SYMBOL_GPL(cdrom_read_tocentry); > static int cdrom_ioctl_read_tocentry(struct cdrom_device_info *cdi, > void __user *argp) > { > - struct cdrom_tocentry entry; > + struct cdrom_tocentry entry = {0}; > int ret; > > if (copy_from_user(&entry, argp, sizeof(entry))) > @@ -3055,7 +3055,7 @@ static noinline int mmc_ioctl_cdrom_subchannel(struct cdrom_device_info *cdi, > void __user *arg) > { > int ret; > - struct cdrom_subchnl q; > + struct cdrom_subchnl q = {0}; > u_char requested, back; > if (copy_from_user(&q, (struct cdrom_subchnl __user *)arg, sizeof(q))) > return -EFAULT; > -- > 2.54.0 > Hi Sreeraj, Thanks again for this and your previous patch. I've now had a look at this, and I would have to politely dispute the 'fixing of memory leaks' here. All of these structures (with the exception of struct cdrom_mcn mcn) are effectively immediately fed into copy_from_user(...), which should be overwriting the entire structure (including padding) with bytes from the provided userspace pointer. If this fails, the functions bail immediately. As for 'struct cdrom_mcn mcn', this structure is fed to an ioctl function pointer which ultimately ends up invoking sr_get_mcn(...) which populates the first 13 bytes of the array and zero terminates it by setting the final byte to 0. If this function fails, cdrom_ioctl_get_mcn(...) likewise bails. There are thus no vulnerabilities to be fixed here. There is no possible case (unless I'm missing it) in which any of these lines in their current state could lead to kernel stack memory being leaked back to userspace. For that reason, I'm not going to take this patch as it isn't fixing anything. While I agree with defensive programming in general, these cases have already been handled without explicit stack initialisation. All the best. Regards, Phil