<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/drivers/char/tpm, branch v3.18.128</title>
<subtitle>Clone of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git</subtitle>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/'/>
<entry>
<title>tpm_i2c_nuvoton: fix potential buffer overruns caused by bit glitches on the bus</title>
<updated>2018-03-11T15:12:17+00:00</updated>
<author>
<name>Jeremy Boone</name>
<email>jeremy.boone@nccgroup.trust</email>
</author>
<published>2018-02-08T20:31:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=2c4b17404d80293795ffbce1ad980a17a405ec0c'/>
<id>2c4b17404d80293795ffbce1ad980a17a405ec0c</id>
<content type='text'>
commit f9d4d9b5a5ef2f017bc344fb65a58a902517173b upstream.

Discrete TPMs are often connected over slow serial buses which, on
some platforms, can have glitches causing bit flips.  In all the
driver _recv() functions, we need to use a u32 to unmarshal the
response size, otherwise a bit flip of the 31st bit would cause the
expected variable to go negative, which would then try to read a huge
amount of data.  Also sanity check that the expected amount of data is
large enough for the TPM header.

Signed-off-by: Jeremy Boone &lt;jeremy.boone@nccgroup.trust&gt;
Cc: stable@vger.kernel.org
Signed-off-by: James Bottomley &lt;James.Bottomley@HansenPartnership.com&gt;
Reviewed-by: Jarkko Sakkinen &lt;jarkko.sakkinen@linux.intel.com&gt;
Signed-off-by: Jarkko Sakkinen &lt;jarkko.sakkinen@linux.intel.com&gt;
Signed-off-by: James Morris &lt;james.morris@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit f9d4d9b5a5ef2f017bc344fb65a58a902517173b upstream.

Discrete TPMs are often connected over slow serial buses which, on
some platforms, can have glitches causing bit flips.  In all the
driver _recv() functions, we need to use a u32 to unmarshal the
response size, otherwise a bit flip of the 31st bit would cause the
expected variable to go negative, which would then try to read a huge
amount of data.  Also sanity check that the expected amount of data is
large enough for the TPM header.

Signed-off-by: Jeremy Boone &lt;jeremy.boone@nccgroup.trust&gt;
Cc: stable@vger.kernel.org
Signed-off-by: James Bottomley &lt;James.Bottomley@HansenPartnership.com&gt;
Reviewed-by: Jarkko Sakkinen &lt;jarkko.sakkinen@linux.intel.com&gt;
Signed-off-by: Jarkko Sakkinen &lt;jarkko.sakkinen@linux.intel.com&gt;
Signed-off-by: James Morris &lt;james.morris@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>tpm_i2c_infineon: fix potential buffer overruns caused by bit glitches on the bus</title>
<updated>2018-03-11T15:12:17+00:00</updated>
<author>
<name>Jeremy Boone</name>
<email>jeremy.boone@nccgroup.trust</email>
</author>
<published>2018-02-08T20:30:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=b467c15b6bbf7076e1842a87b439d7cce0149d31'/>
<id>b467c15b6bbf7076e1842a87b439d7cce0149d31</id>
<content type='text'>
commit 9b8cb28d7c62568a5916bdd7ea1c9176d7f8f2ed upstream.

Discrete TPMs are often connected over slow serial buses which, on
some platforms, can have glitches causing bit flips.  In all the
driver _recv() functions, we need to use a u32 to unmarshal the
response size, otherwise a bit flip of the 31st bit would cause the
expected variable to go negative, which would then try to read a huge
amount of data.  Also sanity check that the expected amount of data is
large enough for the TPM header.

Signed-off-by: Jeremy Boone &lt;jeremy.boone@nccgroup.trust&gt;
Cc: stable@vger.kernel.org
Signed-off-by: James Bottomley &lt;James.Bottomley@HansenPartnership.com&gt;
Reviewed-by: Jarkko Sakkinen &lt;jarkko.sakkinen@linux.intel.com&gt;
Signed-off-by: Jarkko Sakkinen &lt;jarkko.sakkinen@linux.intel.com&gt;
Signed-off-by: James Morris &lt;james.morris@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 9b8cb28d7c62568a5916bdd7ea1c9176d7f8f2ed upstream.

Discrete TPMs are often connected over slow serial buses which, on
some platforms, can have glitches causing bit flips.  In all the
driver _recv() functions, we need to use a u32 to unmarshal the
response size, otherwise a bit flip of the 31st bit would cause the
expected variable to go negative, which would then try to read a huge
amount of data.  Also sanity check that the expected amount of data is
large enough for the TPM header.

Signed-off-by: Jeremy Boone &lt;jeremy.boone@nccgroup.trust&gt;
Cc: stable@vger.kernel.org
Signed-off-by: James Bottomley &lt;James.Bottomley@HansenPartnership.com&gt;
Reviewed-by: Jarkko Sakkinen &lt;jarkko.sakkinen@linux.intel.com&gt;
Signed-off-by: Jarkko Sakkinen &lt;jarkko.sakkinen@linux.intel.com&gt;
Signed-off-by: James Morris &lt;james.morris@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>tpm: fix a kernel memory leak in tpm-sysfs.c</title>
<updated>2017-08-11T16:30:11+00:00</updated>
<author>
<name>Jarkko Sakkinen</name>
<email>jarkko.sakkinen@linux.intel.com</email>
</author>
<published>2017-06-20T09:38:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=e7ef4f1f48c413486a3583d416ed357c7bdb55ab'/>
<id>e7ef4f1f48c413486a3583d416ed357c7bdb55ab</id>
<content type='text'>
commit 13b47cfcfc60495cde216eef4c01040d76174cbe upstream.

While cleaning up sysfs callback that prints EK we discovered a kernel
memory leak. This commit fixes the issue by zeroing the buffer used for
TPM command/response.

The leak happen when we use either tpm_vtpm_proxy, tpm_ibmvtpm or
xen-tpmfront.

Cc: stable@vger.kernel.org
Fixes: 0883743825e3 ("TPM: sysfs functions consolidation")
Reported-by: Jason Gunthorpe &lt;jgunthorpe@obsidianresearch.com&gt;
Tested-by: Stefan Berger &lt;stefanb@linux.vnet.ibm.com&gt;
Signed-off-by: Jarkko Sakkinen &lt;jarkko.sakkinen@linux.intel.com&gt;
Signed-off-by: James Morris &lt;james.l.morris@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;


</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 13b47cfcfc60495cde216eef4c01040d76174cbe upstream.

While cleaning up sysfs callback that prints EK we discovered a kernel
memory leak. This commit fixes the issue by zeroing the buffer used for
TPM command/response.

The leak happen when we use either tpm_vtpm_proxy, tpm_ibmvtpm or
xen-tpmfront.

Cc: stable@vger.kernel.org
Fixes: 0883743825e3 ("TPM: sysfs functions consolidation")
Reported-by: Jason Gunthorpe &lt;jgunthorpe@obsidianresearch.com&gt;
Tested-by: Stefan Berger &lt;stefanb@linux.vnet.ibm.com&gt;
Signed-off-by: Jarkko Sakkinen &lt;jarkko.sakkinen@linux.intel.com&gt;
Signed-off-by: James Morris &lt;james.l.morris@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;


</pre>
</div>
</content>
</entry>
<entry>
<title>vTPM: set virtual device before passing to ibmvtpm_reset_crq</title>
<updated>2015-07-04T03:02:31+00:00</updated>
<author>
<name>Hon Ching \(Vicky\) Lo</name>
<email>honclo@linux.vnet.ibm.com</email>
</author>
<published>2015-05-22T17:23:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=1cce6f3b54f698daa097222ed783ad6acda417be'/>
<id>1cce6f3b54f698daa097222ed783ad6acda417be</id>
<content type='text'>
[ Upstream commit 9d75f08946e8485109458ccf16f714697c207f41 ]

tpm_ibmvtpm_probe() calls ibmvtpm_reset_crq(ibmvtpm) without having yet
set the virtual device in the ibmvtpm structure. So in ibmvtpm_reset_crq,
the phype call contains empty unit addresses, ibmvtpm-&gt;vdev-&gt;unit_address.

Signed-off-by: Hon Ching(Vicky) Lo &lt;honclo@linux.vnet.ibm.com&gt;
Signed-off-by: Joy Latten &lt;jmlatten@linux.vnet.ibm.com&gt;
Reviewed-by: Ashley Lai &lt;ashley@ahsleylai.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Fixes: 132f76294744 ("drivers/char/tpm: Add new device driver to support IBM vTPM")
Signed-off-by: Peter Huewe &lt;peterhuewe@gmx.de&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 9d75f08946e8485109458ccf16f714697c207f41 ]

tpm_ibmvtpm_probe() calls ibmvtpm_reset_crq(ibmvtpm) without having yet
set the virtual device in the ibmvtpm structure. So in ibmvtpm_reset_crq,
the phype call contains empty unit addresses, ibmvtpm-&gt;vdev-&gt;unit_address.

Signed-off-by: Hon Ching(Vicky) Lo &lt;honclo@linux.vnet.ibm.com&gt;
Signed-off-by: Joy Latten &lt;jmlatten@linux.vnet.ibm.com&gt;
Reviewed-by: Ashley Lai &lt;ashley@ahsleylai.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Fixes: 132f76294744 ("drivers/char/tpm: Add new device driver to support IBM vTPM")
Signed-off-by: Peter Huewe &lt;peterhuewe@gmx.de&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tpm/tpm_i2c_stm_st33: Add status check when reading data on the FIFO</title>
<updated>2015-03-28T13:43:13+00:00</updated>
<author>
<name>Christophe Ricard</name>
<email>christophe.ricard@gmail.com</email>
</author>
<published>2015-01-13T22:13:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=a0366884749ec748126fa1934a030f46dcbf8d45'/>
<id>a0366884749ec748126fa1934a030f46dcbf8d45</id>
<content type='text'>
[ Upstream commit c4eadfafb91d5501095c55ffadaa1168743f39d3 ]

Add a return value check when reading data from the FIFO register.

Cc: &lt;stable@vger.kernel.org&gt;
Reviewed-by: Jason Gunthorpe &lt;jason.gunthorpe@obsidianresearch.com&gt;
Signed-off-by: Christophe Ricard &lt;christophe-h.ricard@st.com&gt;
Reviewed-by: Peter Huewe &lt;peterhuewe@gmx.de&gt;
Signed-off-by: Peter Huewe &lt;peterhuewe@gmx.de&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit c4eadfafb91d5501095c55ffadaa1168743f39d3 ]

Add a return value check when reading data from the FIFO register.

Cc: &lt;stable@vger.kernel.org&gt;
Reviewed-by: Jason Gunthorpe &lt;jason.gunthorpe@obsidianresearch.com&gt;
Signed-off-by: Christophe Ricard &lt;christophe-h.ricard@st.com&gt;
Reviewed-by: Peter Huewe &lt;peterhuewe@gmx.de&gt;
Signed-off-by: Peter Huewe &lt;peterhuewe@gmx.de&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tpm/ibmvtpm: Additional LE support for tpm_ibmvtpm_send</title>
<updated>2015-03-28T13:43:06+00:00</updated>
<author>
<name>jmlatten@linux.vnet.ibm.com</name>
<email>jmlatten@linux.vnet.ibm.com</email>
</author>
<published>2015-02-21T00:11:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=33c5b3ad4b54d9477d5ad85b5fd811d0500676e5'/>
<id>33c5b3ad4b54d9477d5ad85b5fd811d0500676e5</id>
<content type='text'>
[ Upstream commit 62dfd912ab3b5405b6fe72d0135c37e9648071f1 ]

Problem: When IMA and VTPM are both enabled in kernel config,
kernel hangs during bootup on LE OS.

Why?: IMA calls tpm_pcr_read() which results in tpm_ibmvtpm_send
and tpm_ibmtpm_recv getting called. A trace showed that
tpm_ibmtpm_recv was hanging.

Resolution: tpm_ibmtpm_recv was hanging because tpm_ibmvtpm_send
was sending CRQ message that probably did not make much sense
to phype because of Endianness. The fix below sends correctly
converted CRQ for LE. This was not caught before because it
seems IMA is not enabled by default in kernel config and
IMA exercises this particular code path in vtpm.

Tested with IMA and VTPM enabled in kernel config and VTPM
enabled on both a BE OS and a LE OS ppc64 lpar. This exercised
CRQ and TPM command code paths in vtpm.
Patch is against Peter's tpmdd tree on github which included
Vicky's previous vtpm le patches.

Signed-off-by: Joy Latten &lt;jmlatten@linux.vnet.ibm.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # eb71f8a5e33f: "Added Little Endian support to vtpm module"
Cc: &lt;stable@vger.kernel.org&gt;
Reviewed-by: Ashley Lai &lt;ashley@ahsleylai.com&gt;
Signed-off-by: Peter Huewe &lt;peterhuewe@gmx.de&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 62dfd912ab3b5405b6fe72d0135c37e9648071f1 ]

Problem: When IMA and VTPM are both enabled in kernel config,
kernel hangs during bootup on LE OS.

Why?: IMA calls tpm_pcr_read() which results in tpm_ibmvtpm_send
and tpm_ibmtpm_recv getting called. A trace showed that
tpm_ibmtpm_recv was hanging.

Resolution: tpm_ibmtpm_recv was hanging because tpm_ibmvtpm_send
was sending CRQ message that probably did not make much sense
to phype because of Endianness. The fix below sends correctly
converted CRQ for LE. This was not caught before because it
seems IMA is not enabled by default in kernel config and
IMA exercises this particular code path in vtpm.

Tested with IMA and VTPM enabled in kernel config and VTPM
enabled on both a BE OS and a LE OS ppc64 lpar. This exercised
CRQ and TPM command code paths in vtpm.
Patch is against Peter's tpmdd tree on github which included
Vicky's previous vtpm le patches.

Signed-off-by: Joy Latten &lt;jmlatten@linux.vnet.ibm.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # eb71f8a5e33f: "Added Little Endian support to vtpm module"
Cc: &lt;stable@vger.kernel.org&gt;
Reviewed-by: Ashley Lai &lt;ashley@ahsleylai.com&gt;
Signed-off-by: Peter Huewe &lt;peterhuewe@gmx.de&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Added Little Endian support to vtpm module</title>
<updated>2015-03-06T22:52:58+00:00</updated>
<author>
<name>honclo</name>
<email>honclo@imap.linux.ibm.com</email>
</author>
<published>2015-02-13T02:02:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=052f8db44c173a21626f8016753a12d9523909af'/>
<id>052f8db44c173a21626f8016753a12d9523909af</id>
<content type='text'>
commit eb71f8a5e33fa1066fb92f0111ab366a341e1f6c upstream.

The tpm_ibmvtpm module is affected by an unaligned access problem.
ibmvtpm_crq_get_version failed with rc=-4 during boot when vTPM is
enabled in Power partition, which supports both little endian and
big endian modes.

We added little endian support to fix this problem:
1) added cpu_to_be64 calls to ensure BE data is sent from an LE OS.
2) added be16_to_cpu and be32_to_cpu calls to make sure data received
   is in LE format on a LE OS.

Signed-off-by: Hon Ching(Vicky) Lo &lt;honclo@linux.vnet.ibm.com&gt;
Signed-off-by: Joy Latten &lt;jmlatten@linux.vnet.ibm.com&gt;
[phuewe: manually applied the patch :( ]
Reviewed-by: Ashley Lai &lt;ashley@ahsleylai.com&gt;
Signed-off-by: Peter Huewe &lt;peterhuewe@gmx.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit eb71f8a5e33fa1066fb92f0111ab366a341e1f6c upstream.

The tpm_ibmvtpm module is affected by an unaligned access problem.
ibmvtpm_crq_get_version failed with rc=-4 during boot when vTPM is
enabled in Power partition, which supports both little endian and
big endian modes.

We added little endian support to fix this problem:
1) added cpu_to_be64 calls to ensure BE data is sent from an LE OS.
2) added be16_to_cpu and be32_to_cpu calls to make sure data received
   is in LE format on a LE OS.

Signed-off-by: Hon Ching(Vicky) Lo &lt;honclo@linux.vnet.ibm.com&gt;
Signed-off-by: Joy Latten &lt;jmlatten@linux.vnet.ibm.com&gt;
[phuewe: manually applied the patch :( ]
Reviewed-by: Ashley Lai &lt;ashley@ahsleylai.com&gt;
Signed-off-by: Peter Huewe &lt;peterhuewe@gmx.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>tpm/tpm_i2c_stm_st33: Fix potential bug in tpm_stm_i2c_send</title>
<updated>2015-03-06T22:52:57+00:00</updated>
<author>
<name>Christophe Ricard</name>
<email>christophe.ricard@gmail.com</email>
</author>
<published>2014-12-01T18:32:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=4243c6c895971ee74a688f1f235f3fb7ca0f07b3'/>
<id>4243c6c895971ee74a688f1f235f3fb7ca0f07b3</id>
<content type='text'>
commit 1ba3b0b6f218072afe8372d12f1b6bf26a26008e upstream.

When sending data in tpm_stm_i2c_send, each loop iteration send buf.
Send buf + i instead as the goal of this for loop is to send a number
of byte from buf that fit in burstcnt. Once those byte are sent, we are
supposed to send the next ones.

The driver was working because the burstcount value returns always the maximum size for a TPM
command or response. (0x800 for a command and 0x400 for a response).

Reviewed-by: Jason Gunthorpe &lt;jgunthorpe@obsidianresearch.com&gt;
Signed-off-by: Christophe Ricard &lt;christophe-h.ricard@st.com&gt;
Signed-off-by: Peter Huewe &lt;peterhuewe@gmx.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 1ba3b0b6f218072afe8372d12f1b6bf26a26008e upstream.

When sending data in tpm_stm_i2c_send, each loop iteration send buf.
Send buf + i instead as the goal of this for loop is to send a number
of byte from buf that fit in burstcnt. Once those byte are sent, we are
supposed to send the next ones.

The driver was working because the burstcount value returns always the maximum size for a TPM
command or response. (0x800 for a command and 0x400 for a response).

Reviewed-by: Jason Gunthorpe &lt;jgunthorpe@obsidianresearch.com&gt;
Signed-off-by: Christophe Ricard &lt;christophe-h.ricard@st.com&gt;
Signed-off-by: Peter Huewe &lt;peterhuewe@gmx.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>tpm: Fix NULL return in tpm_ibmvtpm_get_desired_dma</title>
<updated>2015-03-06T22:52:57+00:00</updated>
<author>
<name>Hon Ching (Vicky) Lo</name>
<email>honclo@linux.vnet.ibm.com</email>
</author>
<published>2014-11-30T14:01:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=2a7a2065baa0a0d72d77d7875bef78761d2e704c'/>
<id>2a7a2065baa0a0d72d77d7875bef78761d2e704c</id>
<content type='text'>
commit 84eb186bc37c0900b53077ca21cf6dd15823a232 upstream.

There was an oops in tpm_ibmvtpm_get_desired_dma, which caused
kernel panic during boot when vTPM is enabled in Power partition
configured in AMS mode.

vio_bus_probe calls vio_cmo_bus_probe which calls
tpm_ibmvtpm_get_desired_dma to get the size needed for DMA allocation.
The problem is, vio_cmo_bus_probe is called before calling probe, which
for vtpm is tpm_ibmvtpm_probe and it's this function that initializes
and sets up vtpm's CRQ and gets required data values.  Therefore,
since this has not yet been done, NULL is returned in attempt to get
the size for DMA allocation.

We added a NULL check.  In addition, a default buffer size will
be set when NULL is returned.

Signed-off-by: Hon Ching (Vicky) Lo &lt;honclo@linux.vnet.ibm.com&gt;
Signed-off-by: Peter Huewe &lt;peterhuewe@gmx.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 84eb186bc37c0900b53077ca21cf6dd15823a232 upstream.

There was an oops in tpm_ibmvtpm_get_desired_dma, which caused
kernel panic during boot when vTPM is enabled in Power partition
configured in AMS mode.

vio_bus_probe calls vio_cmo_bus_probe which calls
tpm_ibmvtpm_get_desired_dma to get the size needed for DMA allocation.
The problem is, vio_cmo_bus_probe is called before calling probe, which
for vtpm is tpm_ibmvtpm_probe and it's this function that initializes
and sets up vtpm's CRQ and gets required data values.  Therefore,
since this has not yet been done, NULL is returned in attempt to get
the size for DMA allocation.

We added a NULL check.  In addition, a default buffer size will
be set when NULL is returned.

Signed-off-by: Hon Ching (Vicky) Lo &lt;honclo@linux.vnet.ibm.com&gt;
Signed-off-by: Peter Huewe &lt;peterhuewe@gmx.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>char: tpm: Add missing error check for devm_kzalloc</title>
<updated>2015-03-06T22:52:57+00:00</updated>
<author>
<name>Kiran Padwal</name>
<email>kiran.padwal@smartplayin.com</email>
</author>
<published>2014-09-19T07:14:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=73da0742175da3f7b2416771037612cdc1ea52f4'/>
<id>73da0742175da3f7b2416771037612cdc1ea52f4</id>
<content type='text'>
commit bb95cd34ba4c9467114acc78eeddd53ab1c10085 upstream.

Currently these driver are missing a check on the return value of devm_kzalloc,
which would cause a NULL pointer dereference in a OOM situation.

This patch adds a missing check for tpm_i2c_atmel.c and tpm_i2c_nuvoton.c

Signed-off-by: Kiran Padwal &lt;kiran.padwal@smartplayin.com&gt;
Reviewed-By: Jason Gunthorpe &lt;jgunthorpe@obsidianresearch.com&gt;
Signed-off-by: Peter Huewe &lt;peterhuewe@gmx.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit bb95cd34ba4c9467114acc78eeddd53ab1c10085 upstream.

Currently these driver are missing a check on the return value of devm_kzalloc,
which would cause a NULL pointer dereference in a OOM situation.

This patch adds a missing check for tpm_i2c_atmel.c and tpm_i2c_nuvoton.c

Signed-off-by: Kiran Padwal &lt;kiran.padwal@smartplayin.com&gt;
Reviewed-By: Jason Gunthorpe &lt;jgunthorpe@obsidianresearch.com&gt;
Signed-off-by: Peter Huewe &lt;peterhuewe@gmx.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
</feed>
