linux-kernel - Re: [PATCH 5.10 264/530] spi: spi-zynqmp-gqspi: fix use-after-free in zynqmp_qspi_exec

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: <20210516203423.GA11471@duo.ucw.cz>
Date:   Sun, 16 May 2021 22:34:23 +0200
From:   Pavel Machek <pavel@...x.de>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        Quanyang Wang <quanyang.wang@...driver.com>,
        Mark Brown <broonie@...nel.org>,
        Sasha Levin <sashal@...nel.org>
Subject: Re: [PATCH 5.10 264/530] spi: spi-zynqmp-gqspi: fix use-after-free
 in zynqmp_qspi_exec_op

Hi!

> When handling op->addr, it is using the buffer "tmpbuf" which has been
> freed. This will trigger a use-after-free KASAN warning. Let's use
> temporary variables to store op->addr.val and op->cmd.opcode to fix
> this issue.

I believe this is "cure worse than a disassease".

> +++ b/drivers/spi/spi-zynqmp-gqspi.c
> @@ -926,8 +926,9 @@ static int zynqmp_qspi_exec_op(struct spi_mem *mem,
>  	struct zynqmp_qspi *xqspi = spi_controller_get_devdata
>  				    (mem->spi->master);
>  	int err = 0, i;
> -	u8 *tmpbuf;
>  	u32 genfifoentry = 0;
> +	u16 opcode = op->cmd.opcode;
> +	u64 opaddr;
>  
>  	dev_dbg(xqspi->dev, "cmd:%#x mode:%d.%d.%d.%d\n",
>  		op->cmd.opcode, op->cmd.buswidth, op->addr.buswidth,
> @@ -940,14 +941,8 @@ static int zynqmp_qspi_exec_op(struct spi_mem *mem,
>  	genfifoentry |= xqspi->genfifobus;
>  
>  	if (op->cmd.opcode) {
> -		tmpbuf = kzalloc(op->cmd.nbytes, GFP_KERNEL | GFP_DMA);
> -		if (!tmpbuf) {
> -			mutex_unlock(&xqspi->op_lock);
> -			return -ENOMEM;
> -		}
> -		tmpbuf[0] = op->cmd.opcode;
>  		reinit_completion(&xqspi->data_completion);
> -		xqspi->txbuf = tmpbuf;
> +		xqspi->txbuf = &opcode;
>  		xqspi->rxbuf = NULL;
>  		xqspi->bytes_to_transfer = op->cmd.nbytes;
>  		xqspi->bytes_to_receive = 0;

So this replaces "op->cmd.nbytes" bytes big DMA buffer with 2 bytes on
stack.

First, if op->cmd.nbytes is > 2, DMA will overrun that buffer. That
can't be healthy.

Second, you really should not run DMA from on-stack buffers.

Best regards,
								Pavel
-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

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