linux-kernel - Re: [PATCH v2 00/11] test_user

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: <20150811.103228.1155026747582145108.davem@davemloft.net>
Date:	Tue, 11 Aug 2015 10:32:28 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	james.hogan@...tec.com
Cc:	linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
	keescook@...omium.org, akpm@...ux-foundation.org, monstr@...str.eu,
	lftan@...era.com, jonas@...thpole.se, chris@...kel.net,
	jcmvbkbc@...il.com, nios2-dev@...ts.rocketboards.org,
	linux@...ts.openrisc.net, linux-xtensa@...ux-xtensa.org
Subject: Re: [PATCH v2 00/11] test_user_copy improvements

From: James Hogan <james.hogan@...tec.com>
Date: Tue, 11 Aug 2015 12:07:20 +0100

> Out of interest, is the zeroing a strict requirement for correct use, or
> a safety precaution to prevent data leakage in case of bad error checking?
> 
> (A quick look reveals that for copy_from_user() when access_ok() fails,
> only arm, arm64, frv, m32r, m68k, sparc, tile, x86, and xtensa do this).

It is required, otherwise the kernel buffer is left partially initialized
which can lead to security bugs.

> That's a good point. The reversed tests aren't really safe in that case.
> With MIPS EVA the user address is very likely to be a valid
> non-TLB-mapped address to kernel mode, and will zero arbitrary memory.
> They could also potentially crash the kernel if user memory isn't
> normally kernel accessible and the arch doesn't fix up faults for the
> kernel accesses (not EVA, but maybe sparc64?).

Sparc64 would fault on an invalid kernel address, but the problem here
is that the addresses are actually valid kernel ones.

> It is also possible (though less likely) that the kernel address will
> have a valid user mapping at the same address, so the reversed
> copy_to_user test may well leak arbitrary kernel memory to user memory
> without faulting.

Yes, this is also a problem.

>> Also, I think the tests you added and protected with MIPS ifdefs could
>> equally be enabled on sparc64.
> 
> Yes, it sounds like it. I'll try the ARCH_SPLIT_VA_SPACE idea.

Great!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/