linux-kernel - Re: [greybus-dev] [PATCH] greybus: uart: fix uninitialized flow control variable

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Thu, 14 May 2020 09:04:44 +0200
From:   Johan Hovold <johan@...nel.org>
To:     Alex Elder <elder@...aro.org>
Cc:     Arnd Bergmann <arnd@...db.de>, David Lin <dtwlin@...il.com>,
        Johan Hovold <johan@...nel.org>, Alex Elder <elder@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Axel Haslam <ahaslam@...libre.com>, devel@...verdev.osuosl.org,
        linux-kernel@...r.kernel.org, greybus-dev@...ts.linaro.org,
        Greg Kroah-Hartman <gregkh@...gle.com>,
        Johan Hovold <johan@...oldconsulting.com>
Subject: Re: [greybus-dev] [PATCH] greybus: uart: fix uninitialized flow
 control variable

On Wed, Apr 29, 2020 at 03:00:44PM -0500, Alex Elder wrote:
> On 4/29/20 2:00 PM, Arnd Bergmann wrote:
> > gcc-10 points out an uninitialized variable use:
> 
> Wow, nice, checking individual uninitialized fields within
> the structure.
> 
> The structure should really be zero-initialized anyway; it's
> passed as a structure in a message elsewhere.  With your
> change, all fields in the structure are written, but in
> theory the structure could change and stack garbage could
> be sent over the wire.
> 
> What do you think of doing this instead?  Or in addition?
> 
>         struct gb_tty_line_coding newline = { };
> 
> (Presumably that would also silence the warning.)
> 
> I endorse of your change, either way.

Looks like Greg ended up applying an identical version of this patch
that was submitted this week instead.

Taking a closer look at this code I noticed we have two versions of this
line-coding struct which are supposed by be identical, but which could
get out of sync (and have once already it turns out).

Johan