[Lucid][CVE-2013-6282][PATCH 0/1] ARM: 7527/1: uaccess: explicitly check __user pointer when !CPU_USE_DOMAINS

[Seth Forshee]

On Tue, Feb 11, 2014 at 01:42:50PM +0000, Luis Henriques wrote:
> Following this email, I'm sending the backport of CVE-2013-6282 fix
> for Lucid.  And it looks scary!
> 
> I believe this patch could be simplified by removing some #ifdefs
> from it, as CPU_HAS_DOMAINS doesn't exist in Lucid -- it has been
> added in 2.6.38 with commit 247055a ("ARM: 6384/1: Remove the domain
> switching on ARMv6k/v7 CPUs").
> 
> Other than that, its just ARM assembly.  What could possibly go wrong?
> 
> Note that I've only build-tested it (for armel), as I don't have the
> HW to boot it (I would say that a bad backport would break a simple
> boot test).

I'm not entirely sure lucid is vulnerable here. In lucid
__get_user_(1|2|4) always use ldr(b)?t instructions when accessing the
user-supplied address, and likewise the put_user variants always use
str(b)?t. The "t" at the end tells the memory system to do the access as
if executing in user mode. The implementations at the time of the
upstream patch used the TUSER() macro, which drops the "t" when
!CPU_HAS_DOMAINS (which seems odd, but 247055a describes why it's being
done). So I _think_ that makes lucid safe since no memory could be
accessed that isn't also accessible in user mode. I'm not certain
though, so unless someone who is certain can weigh in it probably won't
hurt anything to add the exra checks.

The backport itself looks correct to me, but I do agree that it could be
simplified. It could do with some testing though since this code is
quite subtle.

Seth