Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Message-ID: <e3efd9c01626aa3bed02f10f845533711864bb17.camel@surriel.com>
Subject: Re: crypto: Kernel memory overwrite attempt detected to spans
 multiple pages
From:   Rik van Riel <riel@surriel.com>
To:     Eric Biggers <ebiggers@kernel.org>,
        Kees Cook <keescook@chromium.org>
Cc:     Geert Uytterhoeven <geert@linux-m68k.org>,
        Herbert Xu <herbert@gondor.apana.org.au>,
        linux-security-module <linux-security-module@vger.kernel.org>,
        Linux ARM <linux-arm-kernel@lists.infradead.org>,
        Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Laura Abbott <labbott@redhat.com>
Date:   Wed, 10 Apr 2019 21:37:41 -0400
In-Reply-To: <20190410231156.GB120258@gmail.com>
References: <CAMuHMdWhx0-kspDyLOgTp+9udiBpkMHULSGyMg9uPPV16=FWQg@mail.gmail.com>
         <20190319170911.GB202956@gmail.com> <20190320185719.GB180195@gmail.com>
         <CAGXu5jL-5C1ZGZ1JgaNFqK-z1Pp1N1X8gD3_ysKTCa=omD+_VQ@mail.gmail.com>
         <20190321175122.GA1587@sol.localdomain>
         <20190410031734.GB7140@sol.localdomain>
         <CAGXu5j+SZ2+Zkc=Vp5CXQUHhiR9f_OOnca684JTRW3T0yXdaNQ@mail.gmail.com>
         <20190410190729.GA120258@gmail.com>
         <CAGXu5j+Gfvj9G6s_UQTw6hE11gJb1edt3BXzpbDQdc_dpcHgag@mail.gmail.com>
         <20190410231156.GB120258@gmail.com>
Content-Type: multipart/signed; micalg="pgp-sha256";
        protocol="application/pgp-signature"; boundary="=-I0iYs52hNxEw6RSke2FZ"
Mime-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


--=-I0iYs52hNxEw6RSke2FZ
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2019-04-10 at 16:11 -0700, Eric Biggers wrote:

> You've explained *what* it does again, but not *why*.  *Why* do you
> want
> hardened usercopy to detect copies across page boundaries, when there
> is no
> actual buffer overflow?

When some subsystem in the kernel allocates multiple
pages without _GFP_COMP, there is no way afterwards
to detect exactly how many pages it allocated.

In other words, there is no way to see how large the
buffer is, nor whether the copy operation in question
would overflow it.

--=20
All Rights Reversed.

--=-I0iYs52hNxEw6RSke2FZ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----

iQEzBAABCAAdFiEEKR73pCCtJ5Xj3yADznnekoTE3oMFAlyummUACgkQznnekoTE
3oN5Ogf+JB1+Q62gA3I1CjbG9J1N9Yo0SopCRnifEmRD5OOuHcTnKtJk9cDddftF
JckxLVhf0YXgLZa78GQhNW74dTw/XBgB1tE59q7eYI3srERNjFc8G9cjLMEu0aKS
wpv4wOL0AB7k1eFPvXkDbQ7mnzxb7s8+wGoH4F6Shs4ls9At//2kofAvES14Cfn8
c8lCTakBYcQ4lEhr7dxQ3v//NoD6/ZC6tacDN5A6mgcwM/VkdNgNskDVX25sTn1P
Kvnes/43AAefodugVLVuXCtXhnBM1aJ1zn+J7VgyC5ZJAktdPSNixT6J7xlC16rZ
U5Uf2fWdPx6UWgcs8agsp1NCrvu31w==
=ewwZ
-----END PGP SIGNATURE-----

--=-I0iYs52hNxEw6RSke2FZ--