linux-kernel - Re: [PATCH] i2c: core-smbus: don't trace smbus

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190205190849.GA2686@kunai>
Date:   Tue, 5 Feb 2019 20:08:50 +0100
From:   Wolfram Sang <wsa@...-dreams.de>
To:     John Sperbeck <jsperbeck@...gle.com>
Cc:     Steven Rostedt <rostedt@...dmis.org>,
        Ingo Molnar <mingo@...hat.com>, linux-i2c@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] i2c: core-smbus: don't trace smbus_reply data on errors


> > > Hmm, instead of tracing nothing, as this is already a "conditional
> > > trace event", why not add to that condition:
> > >
> > >       TP_CONDITION(res >= 0 && read_write == I2C_SMBUS_READ),
> > >
> > > Unless you want to still trace some data on failure.
> >
> > John, any comment to this?
> >
> 
> The issue we were dealing with was access to uninitialized memory on the stack.
> The change '30f939feaeee i2c: fix kernel memory disclosure in dev interface'
> does the initialization, so the tracing code is no longer affected.
> We just didn't
> have that change in the particular kernel we were testing.
> 
> Still, Steven's suggestion seems fine to me.  Would you like me to create a new
> patch based on that?

I am not a tracing expert, but all that was said here tell me that it
would be better to have the change. So, yes, please, that would be
appreciated.


Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)