linux-kernel - Re: [PATCH] lkdtm: fix ACCESS

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: <56321EF7.70407@tycho.nsa.gov>
Date:	Thu, 29 Oct 2015 09:28:23 -0400
From:	Stephen Smalley <sds@...ho.nsa.gov>
To:	Greg KH <gregkh@...uxfoundation.org>
Cc:	keescook@...omium.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] lkdtm: fix ACCESS_USERSPACE test

On 10/27/2015 08:12 PM, Greg KH wrote:
> On Tue, Oct 27, 2015 at 04:47:53PM -0400, Stephen Smalley wrote:
>> Add a copy_to_user() call to the ACCESS_USERSPACE test
>> prior to attempting direct dereferencing of the user
>> address to ensure the page is present.  Otherwise,
>> a fault occurs on arm kernels even prior to the introduction
>> of CONFIG_CPU_SW_DOMAIN_PAN, and there is no difference in
>> behavior for CONFIG_CPU_SW_DOMAIN_PAN=n vs CONFIG_CPU_SW_DOMAIN_PAN=y.
>>
>> Before this change, for any value of CONFIG_CPU_SW_DOMAIN_PAN:
>> lkdtm: Performing direct entry ACCESS_USERSPACE
>> lkdtm: attempting bad read at b6fe8000
>> Unable to handle kernel paging request at virtual address b6fe8000
>>
>> After this change, for CONFIG_CPU_SW_DOMAIN_PAN=n:
>> lkdtm: Performing direct entry ACCESS_USERSPACE
>> lkdtm: attempting bad read at b6efc000
>> lkdtm: attempting bad write at b6efc000
>>
>> After this change, for CONFIG_CPU_SW_DOMAIN_PAN=y:
>> lkdtm: Performing direct entry ACCESS_USERSPACE
>> lkdtm: attempting bad read at b6f7d000
>> Unhandled fault: page domain fault (0x01b) at 0xb6f7d000
>> ...
>>
>> Signed-off-by: Stephen Smalley <sds@...ho.nsa.gov>
>> ---
>>  drivers/misc/lkdtm.c | 8 +++++++-
>>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> Should this also be applied to older kernels (i.e. a stable fix)?

I don't think it qualifies (only a fix for a kernel crash test), but will defer to Kees.

--
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/