On Wed, Apr 01, 2020 at 09:24:43AM +0000, Schmid, Carsten wrote: > >From eb5a13ddc30824c20f1e2b662d2c821ad3808526 Mon Sep 17 00:00:00 2001 > From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> > Date: Fri, 4 Jan 2019 12:56:09 -0800 > Subject: [PATCH] make 'user_access_begin()' do 'access_ok()' > > [ Upstream commit 594cc251fdd0d231d342d88b2fdff4bc42fb0690 ] > > Fixes CVE-2018-20669 > Backported from v5.0-rc1 > Patch 1/1 Also, that cve was "supposed" to already be fixed in the 4.19.13 kernel release for some reason, and it's a drm issue, not a core access_ok() issue. So why is this needed for 4.14? > > Originally, the rule used to be that you'd have to do access_ok() > separately, and then user_access_begin() before actually doing the > direct (optimized) user access. > > But experience has shown that people then decide not to do access_ok() > at all, and instead rely on it being implied by other operations or > similar. Which makes it very hard to verify that the access has > actually been range-checked. > > If you use the unsafe direct user accesses, hardware features (either > SMAP - Supervisor Mode Access Protection - on x86, or PAN - Privileged > Access Never - on ARM) do force you to use user_access_begin(). But > nothing really forces the range check. > > By putting the range check into user_access_begin(), we actually force > people to do the right thing (tm), and the range check vill be visible > near the actual accesses. We have way too long a history of people > trying to avoid them. > > Signed-off-by: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> No s-o-by from you? > --- > Rationale: > When working on stability and security for a project with 4.14 kernel, > i backported patches from upstream. > Want to give this work back to the community, as 4.14 is a SLTS. What is "SLTS"? thanks, greg k-h
