[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXu5jJV4M4y=4OZ3Ph+ovmZbrjosjwb-tS=UEG66rzEdauv+w@mail.gmail.com>
Date: Mon, 1 Apr 2019 11:43:27 -0700
From: Kees Cook <keescook@...omium.org>
To: Jason Gunthorpe <jgg@...pe.ca>
Cc: Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
Tomas Winkler <tomas.winkler@...el.com>,
Phil Baker <baker1tex@...il.com>,
Craig Robson <craig@...tt.com>,
Laura Abbott <labbott@...hat.com>,
LKML <linux-kernel@...r.kernel.org>,
Peter Huewe <peterhuewe@....de>, Arnd Bergmann <arnd@...db.de>,
linux-integrity <linux-integrity@...r.kernel.org>
Subject: Re: [PATCH] tpm: Actually fail on TPM errors during "get random"
On Mon, Apr 1, 2019 at 11:39 AM Jason Gunthorpe <jgg@...pe.ca> wrote:
>
> On Mon, Apr 01, 2019 at 11:32:11AM -0700, Kees Cook wrote:
> > A "get random" may fail with a TPM error, but those codes were returned
> > as-is to the caller, which assumed the result was the number of bytes
> > that had been written to the target buffer, which could lead to an kernel
> > heap memory exposure and over-read.
> >
> > This fixes tpm1_get_random() to mask positive TPM errors into -EIO, as
> > before.
> >
> > [ 18.092103] tpm tpm0: A TPM error (379) occurred attempting get random
> > [ 18.092106] usercopy: Kernel memory exposure attempt detected from SLUB object 'kmalloc-64' (offset 0, size 379)!
> >
> > Link: https://bugzilla.redhat.com/show_bug.cgi?id=1650989
> > Reported-by: Phil Baker <baker1tex@...il.com>
> > Reported-by: Craig Robson <craig@...tt.com>
> > Fixes: 7aee9c52d7ac ("tpm: tpm1: rewrite tpm1_get_random() using tpm_buf structure")
> > Cc: Laura Abbott <labbott@...hat.com>
> > Cc: Tomas Winkler <tomas.winkler@...el.com>
> > Cc: Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
> > Cc: stable@...r.kernel.org
> > Signed-off-by: Kees Cook <keescook@...omium.org>
> > drivers/char/tpm/tpm1-cmd.c | 9 ++++++---
> > 1 file changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/char/tpm/tpm1-cmd.c b/drivers/char/tpm/tpm1-cmd.c
> > index 85dcf2654d11..faeb78ecf960 100644
> > +++ b/drivers/char/tpm/tpm1-cmd.c
> > @@ -510,7 +510,7 @@ struct tpm1_get_random_out {
> > *
> > * Return:
> > * * number of bytes read
> > - * * -errno or a TPM return code otherwise
> > + * * -errno (positive TPM return codes are masked to -EIO)
> > */
> > int tpm1_get_random(struct tpm_chip *chip, u8 *dest, size_t max)
> > {
> > @@ -524,7 +524,7 @@ int tpm1_get_random(struct tpm_chip *chip, u8 *dest, size_t max)
> >
> > rc = tpm_buf_init(&buf, TPM_TAG_RQU_COMMAND, TPM_ORD_GET_RANDOM);
> > if (rc)
> > - return rc;
> > + goto fail;
>
> ?? Does tpm_buf_init() return positive?? Shouldn't..
>
> I think you actually want this:
I didn't check that, but it was tpm_transmit_cmd() that was failing
(and would be covered by the error path change I sent).
>
> diff --git a/drivers/char/tpm/tpm1-cmd.c b/drivers/char/tpm/tpm1-cmd.c
> index 85dcf2654d1102..a01e6fba1aacb6 100644
> --- a/drivers/char/tpm/tpm1-cmd.c
> +++ b/drivers/char/tpm/tpm1-cmd.c
> @@ -510,7 +510,7 @@ struct tpm1_get_random_out {
> *
> * Return:
> * * number of bytes read
> - * * -errno or a TPM return code otherwise
> + * * -errno
> */
> int tpm1_get_random(struct tpm_chip *chip, u8 *dest, size_t max)
> {
> @@ -531,8 +531,10 @@ int tpm1_get_random(struct tpm_chip *chip, u8 *dest, size_t max)
>
> rc = tpm_transmit_cmd(chip, &buf, sizeof(out->rng_data_len),
> "attempting get random");
> - if (rc)
> + if (rc) {
> + rc = -EIO
> goto out;
> + }
>
> out = (struct tpm1_get_random_out *)&buf.data[TPM_HEADER_SIZE];
>
> diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
> index e74c5b7b64bfbd..9fa498b4cf8816 100644
> --- a/drivers/char/tpm/tpm2-cmd.c
> +++ b/drivers/char/tpm/tpm2-cmd.c
> @@ -328,8 +328,10 @@ int tpm2_get_random(struct tpm_chip *chip, u8 *dest, size_t max)
> offsetof(struct tpm2_get_random_out,
> buffer),
> "attempting get random");
> - if (err)
> + if (err) {
> + rc = -EIO;
> goto out;
> + }
>
> out = (struct tpm2_get_random_out *)
> &buf.data[TPM_HEADER_SIZE];
Eeks, I missed tpm2. In both cases, though a negative error would be
masked. I was trying to leave those as-is and only mask positive
errors.
--
Kees Cook
Powered by blists - more mailing lists