All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Jiri Slaby <jirislaby@kernel.org>
Cc: sparclinux@vger.kernel.org,
	"David S. Miller" <davem@davemloft.net>,
	Joshua Rogers <linux@joshua.hu>,
	linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org,
	stable <stable@kernel.org>, Kees Cook <keescook@chromium.org>
Subject: Re: [PATCH 1/2] tty: vcc: zero-initialize control packet in vcc_send_ctl()
Date: Fri, 31 Jul 2026 14:02:32 +0200	[thread overview]
Message-ID: <2026073124-foster-tremble-7061@gregkh> (raw)
In-Reply-To: <3bf1002b-4e3e-4670-a3d9-2f5b7f67beb7@kernel.org>

On Fri, Jul 31, 2026 at 11:16:57AM +0200, Jiri Slaby wrote:
> On 31. 07. 26, 10:32, Greg Kroah-Hartman wrote:
> > On Fri, Jul 31, 2026 at 10:29:14AM +0200, Jiri Slaby wrote:
> > > On 31. 07. 26, 10:15, Greg Kroah-Hartman wrote:
> > > > From: Joshua Rogers <linux@joshua.hu>
> > > > 
> > > > The stack-allocated struct vio_vcc pkt was partially initialized,
> > > > leaving the tag.stype_env field uninitialized before being sent via
> > > > ldc_write(), potentially leaking kernel stack data to the LDC peer.
> > > > 
> > > > Assisted-by: AISLE:Snapshot
> > > > Cc: stable <stable@kernel.org>
> > > > Signed-off-by: Joshua Rogers <linux@joshua.hu>
> > > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > > ---
> > > >    drivers/tty/vcc.c | 2 +-
> > > >    1 file changed, 1 insertion(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/tty/vcc.c b/drivers/tty/vcc.c
> > > > index 27a55465bf5e..3947bd2b75ac 100644
> > > > --- a/drivers/tty/vcc.c
> > > > +++ b/drivers/tty/vcc.c
> > > > @@ -492,7 +492,7 @@ static ssize_t domain_show(struct device *dev,
> > > >    static int vcc_send_ctl(struct vcc_port *port, int ctl)
> > > >    {
> > > > -	struct vio_vcc pkt;
> > > > +	struct vio_vcc pkt = {};
> > > 
> > > Note this needs not initialize holes.
> > 
> > Does it?  I keep forgetting this if it's really true or not.  I think
> > we've been through this in the past but I can't find the archives.
> > 
> > > I believe there are none here, but memset() is usually
> > > preferred/safer.
> > 
> > Last I remember, a long time ago, the compiler would just use memset()
> > for this, and hit the holes.  Or is that a compiler-specific issue?
> > 
> > Yes, it's more obvious, and I'll be glad to change it, but figuring this
> > out for real would be great :)
> 
> OK, so the standard (C17) does not guarantee zeroing.
> 
> What I found though:
> 
> * both clang and gcc zero the full struct for "{}". There was a bug in gcc <
> 8 where it did not.
> 
> * this is not true for designated initializer, cf. ce50039be49e ("net:
> sched: act_ife: initialize struct tc_ife to fix KMSAN kernel-infoleak")).

Ok, as our compiler is newer than these versions, and this isn't a
designated initializer, we should be ok.

> 
> Adding Kees who is the author of:
> ====
> Memory initialization
> ---------------------
> 
> Memory copied to userspace must always be fully initialized. If not
> explicitly memset(), this will require changes to the compiler to make
> sure structure holes are cleared.
> ====
> 
> He might aware of more bugs.
> 
> 
> 
> FWIW, {} here should be safe for two reasons:
> * not a designated initializer
> * no holes (IMO)

Great, I'll keep this as-is.  Now if only anyone can tell me if this
code is even used anymore :)

thanks,

greg k-h

  reply	other threads:[~2026-07-31 12:02 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-31  8:15 [PATCH 0/2] tty: vcc: Some small vcc bugfixes found by code scans Greg Kroah-Hartman
2026-07-31  8:15 ` [PATCH 1/2] tty: vcc: zero-initialize control packet in vcc_send_ctl() Greg Kroah-Hartman
2026-07-31  8:29   ` Jiri Slaby
2026-07-31  8:32     ` Greg Kroah-Hartman
2026-07-31  9:16       ` Jiri Slaby
2026-07-31 12:02         ` Greg Kroah-Hartman [this message]
2026-07-31  8:15 ` [PATCH 2/2] tty: vcc: hold port lock when clearing tty pointer in vcc_cleanup Greg Kroah-Hartman
2026-07-31  8:32   ` Jiri Slaby

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2026073124-foster-tremble-7061@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=davem@davemloft.net \
    --cc=jirislaby@kernel.org \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=linux@joshua.hu \
    --cc=sparclinux@vger.kernel.org \
    --cc=stable@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.