<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/drivers/char, branch v3.12.34</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v3.12.34</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v3.12.34'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2014-11-19T17:38:15Z</updated>
<entry>
<title>hwrng: pseries - port to new read API and fix stack corruption</title>
<updated>2014-11-19T17:38:15Z</updated>
<author>
<name>Greg Kurz</name>
<email>gkurz@linux.vnet.ibm.com</email>
</author>
<published>2014-10-31T06:50:11Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=50e52368e667f2a8d5a43c0c9f60b4391a5bc715'/>
<id>urn:sha1:50e52368e667f2a8d5a43c0c9f60b4391a5bc715</id>
<content type='text'>
commit 24c65bc7037e7d0f362c0df70d17dd72ee64b8b9 upstream.

The add_early_randomness() function in drivers/char/hw_random/core.c passes
a 16-byte buffer to pseries_rng_data_read(). Unfortunately, plpar_hcall()
returns four 64-bit values and trashes 16 bytes on the stack.

This bug has been lying around for a long time. It got unveiled by:

commit d3cc7996473a7bdd33256029988ea690754e4e2a
Author: Amit Shah &lt;amit.shah@redhat.com&gt;
Date:   Thu Jul 10 15:42:34 2014 +0530

    hwrng: fetch randomness only after device init

It may trig a oops while loading or unloading the pseries-rng module for both
PowerVM and PowerKVM guests.

This patch does two things:
- pass an intermediate well sized buffer to plpar_hcall(). This is acceptalbe
  since we're not on a hot path.
- move to the new read API so that we know the return buffer size for sure.

Signed-off-by: Greg Kurz &lt;gkurz@linux.vnet.ibm.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</content>
</entry>
<entry>
<title>hwrng: pseries - Return errors to upper levels in pseries-rng.c</title>
<updated>2014-11-19T16:02:03Z</updated>
<author>
<name>Michael Ellerman</name>
<email>michael@ellerman.id.au</email>
</author>
<published>2013-09-25T09:24:17Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=b4dc3a3ad9a91453d3d72a6a3e5218d670dfc7dd'/>
<id>urn:sha1:b4dc3a3ad9a91453d3d72a6a3e5218d670dfc7dd</id>
<content type='text'>
commit d319fe2a0af3509f959d5195fb8916accbf14857 upstream.

We don't expect to get errors from the hypervisor when reading the rng,
but if we do we should pass the error up to the hwrng driver. Otherwise
the hwrng driver will continue calling us forever.

Signed-off-by: Michael Ellerman &lt;michael@ellerman.id.au&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
</entry>
<entry>
<title>random: add and use memzero_explicit() for clearing data</title>
<updated>2014-11-13T18:02:16Z</updated>
<author>
<name>Daniel Borkmann</name>
<email>dborkman@redhat.com</email>
</author>
<published>2014-08-27T03:16:35Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=3b29acb38f39aea8cf7675eadd5214300149bb9e'/>
<id>urn:sha1:3b29acb38f39aea8cf7675eadd5214300149bb9e</id>
<content type='text'>
commit d4c5efdb97773f59a2b711754ca0953f24516739 upstream.

zatimend has reported that in his environment (3.16/gcc4.8.3/corei7)
memset() calls which clear out sensitive data in extract_{buf,entropy,
entropy_user}() in random driver are being optimized away by gcc.

Add a helper memzero_explicit() (similarly as explicit_bzero() variants)
that can be used in such cases where a variable with sensitive data is
being cleared out in the end. Other use cases might also be in crypto
code. [ I have put this into lib/string.c though, as it's always built-in
and doesn't need any dependencies then. ]

Fixes kernel bugzilla: 82041

Reported-by: zatimend@hotmail.co.uk
Signed-off-by: Daniel Borkmann &lt;dborkman@redhat.com&gt;
Acked-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Cc: Alexey Dobriyan &lt;adobriyan@gmail.com&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
</entry>
<entry>
<title>tpm: Provide a generic means to override the chip returned timeouts</title>
<updated>2014-09-17T14:55:02Z</updated>
<author>
<name>Jason Gunthorpe</name>
<email>jgunthorpe@obsidianresearch.com</email>
</author>
<published>2014-05-22T00:26:44Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=3f06fd495304eaca2d7e61b7db3e0c27e152b36e'/>
<id>urn:sha1:3f06fd495304eaca2d7e61b7db3e0c27e152b36e</id>
<content type='text'>
commit 8e54caf407b98efa05409e1fee0e5381abd2b088 upstream.

Some Atmel TPMs provide completely wrong timeouts from their
TPM_CAP_PROP_TIS_TIMEOUT query. This patch detects that and returns
new correct values via a DID/VID table in the TIS driver.

Tested on ARM using an AT97SC3204T FW version 37.16

[PHuewe: without this fix these 'broken' Atmel TPMs won't function on
older kernels]
Signed-off-by: "Berg, Christopher" &lt;Christopher.Berg@atmel.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgunthorpe@obsidianresearch.com&gt;
Signed-off-by: Peter Huewe &lt;peterhuewe@gmx.de&gt;
[bwh: Backported to 3.10:
 - Adjust filename, context
 - s/chip-&gt;ops-&gt;/chip-&gt;vendor./]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
</entry>
<entry>
<title>tpm: missing tpm_chip_put in tpm_get_random()</title>
<updated>2014-09-17T14:55:02Z</updated>
<author>
<name>Jarkko Sakkinen</name>
<email>jarkko.sakkinen@linux.intel.com</email>
</author>
<published>2014-05-09T11:23:10Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=a4ed6bc99bb00d7202cb1e0ef99095d39d76d200'/>
<id>urn:sha1:a4ed6bc99bb00d7202cb1e0ef99095d39d76d200</id>
<content type='text'>
commit 3e14d83ef94a5806a865b85b513b4e891923c19b upstream.

Regression in 41ab999c. Call to tpm_chip_put is missing. This
will cause TPM device driver not to unload if tmp_get_random()
is called.

Signed-off-by: Jarkko Sakkinen &lt;jarkko.sakkinen@linux.intel.com&gt;
Signed-off-by: Peter Huewe &lt;peterhuewe@gmx.de&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</content>
</entry>
<entry>
<title>tpm: Add missing tpm_do_selftest to ST33 I2C driver</title>
<updated>2014-09-03T19:31:23Z</updated>
<author>
<name>Jason Gunthorpe</name>
<email>jgunthorpe@obsidianresearch.com</email>
</author>
<published>2013-11-09T18:17:00Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=f735c9db755564483480fe43a420ad7a252d2317'/>
<id>urn:sha1:f735c9db755564483480fe43a420ad7a252d2317</id>
<content type='text'>
commit f07a5e9a331045e976a3d317ba43d14859d9407c upstream.

Most device drivers do call 'tpm_do_selftest' which executes a
TPM_ContinueSelfTest. tpm_i2c_stm_st33 is just pointlessly different,
I think it is bug.

These days we have the general assumption that the TPM is usable by
the kernel immediately after the driver is finished, so we can no
longer defer the mandatory self test to userspace.

Reported-by: Richard Marciel &lt;rmaciel@linux.vnet.ibm.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgunthorpe@obsidianresearch.com&gt;
Signed-off-by: Peter Huewe &lt;peterhuewe@gmx.de&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
</entry>
<entry>
<title>applicom: dereferencing NULL on error path</title>
<updated>2014-07-02T10:06:04Z</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2014-05-09T11:59:16Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=5289d91feb0e3ffd287979abb7e5b7e02a14f752'/>
<id>urn:sha1:5289d91feb0e3ffd287979abb7e5b7e02a14f752</id>
<content type='text'>
commit 8bab797c6e5724a43b7666ad70860712365cdb71 upstream.

This is a static checker fix.  The "dev" variable is always NULL after
the while statement so we would be dereferencing a NULL pointer here.

Fixes: 819a3eba4233 ('[PATCH] applicom: fix error handling')
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
</entry>
<entry>
<title>ipmi: Reset the KCS timeout when starting error recovery</title>
<updated>2014-06-06T09:40:22Z</updated>
<author>
<name>Corey Minyard</name>
<email>cminyard@mvista.com</email>
</author>
<published>2014-04-14T14:46:52Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=e818ab1909b45811829875764d6a78041f303c09'/>
<id>urn:sha1:e818ab1909b45811829875764d6a78041f303c09</id>
<content type='text'>
commit eb6d78ec213e6938559b801421d64714dafcf4b2 upstream.

The OBF timer in KCS was not reset in one situation when error recovery
was started, resulting in an immediate timeout.

Reported-by: Bodo Stroesser &lt;bstroesser@ts.fujitsu.com&gt;
Signed-off-by: Corey Minyard &lt;cminyard@mvista.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</content>
</entry>
<entry>
<title>ipmi: Fix a race restarting the timer</title>
<updated>2014-05-05T11:39:23Z</updated>
<author>
<name>Bodo Stroesser</name>
<email>bstroesser@ts.fujitsu.com</email>
</author>
<published>2014-04-14T14:46:51Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=10083c00587485c79d86b5c425464418cfc3c586'/>
<id>urn:sha1:10083c00587485c79d86b5c425464418cfc3c586</id>
<content type='text'>
commit 48e8ac2979920ffa39117e2d725afa3a749bfe8d upstream.

With recent changes it is possible for the timer handler to detect an
idle interface and not start the timer, but the thread to start an
operation at the same time.  The thread will not start the timer in that
instance, resulting in the timer not running.

Instead, move all timer operations under the lock and start the timer in
the thread if it detect non-idle and the timer is not already running.
Moving under locks allows the last timeout to be set in both the thread
and the timer.  'Timer is not running' means that the timer is not
pending and smi_timeout() is not running.  So we need a flag to detect
this correctly.

Also fix a few other timeout bugs: setting the last timeout when the
interrupt has to be disabled and the timer started, and setting the last
timeout in check_start_timer_thread possibly racing with the timer

Signed-off-by: Corey Minyard &lt;cminyard@mvista.com&gt;
Signed-off-by: Bodo Stroesser &lt;bstroesser@ts.fujitsu.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
</entry>
<entry>
<title>/dev/mem: handle out-of-bounds read/write</title>
<updated>2014-04-25T16:40:45Z</updated>
<author>
<name>Petr Tesarik</name>
<email>ptesarik@suse.cz</email>
</author>
<published>2014-01-30T08:48:02Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=3566e03b5bc9c06855b07423ab4c6e2710aa21e4'/>
<id>urn:sha1:3566e03b5bc9c06855b07423ab4c6e2710aa21e4</id>
<content type='text'>
commit 08d2d00b291ed4eb91530050274e67a761c1901d upstream.

The loff_t type may be wider than phys_addr_t (e.g. on 32-bit systems).
Consequently, the file offset may be truncated in the assignment.
Currently, /dev/mem wraps around, which may cause applications to read
or write incorrect regions of memory by accident.

Let's follow POSIX file semantics here and return 0 when reading from
and -EFBIG when writing to an offset that cannot be represented by a
phys_addr_t.

Note that the conditional is optimized out by the compiler if loff_t
has the same size as phys_addr_t.

Signed-off-by: Petr Tesarik &lt;ptesarik@suse.cz&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
</entry>
</feed>
