Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1501956 > unrolled thread

Re: [kernel-hardening] [PATCH] lib: harden strncpy_from_user

Started byLoganaden Velvindron <loganaden@gmail.com>
First post2016-10-17 15:10 +0200
Last post2016-10-17 15:10 +0200
Articles 1 — 1 participant

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [kernel-hardening] [PATCH] lib: harden strncpy_from_user Loganaden Velvindron <loganaden@gmail.com> - 2016-10-17 15:10 +0200

#1501956 — Re: [kernel-hardening] [PATCH] lib: harden strncpy_from_user

FromLoganaden Velvindron <loganaden@gmail.com>
Date2016-10-17 15:10 +0200
SubjectRe: [kernel-hardening] [PATCH] lib: harden strncpy_from_user
Message-ID<stfPX-3TZ-11@gated-at.bofh.it>
On Mon, Oct 17, 2016 at 5:04 PM, Mark Rutland <mark.rutland@arm.com> wrote:
> On Fri, Aug 26, 2016 at 02:57:58PM -0400, Kees Cook wrote:
>> On Fri, Aug 26, 2016 at 10:31 AM, Mark Rutland <mark.rutland@arm.com> wrote:
>> > The strncpy_from_user() accessor is effectively a copy_from_user()
>> > specialised to copy strings, terminating early at a NUL byte if
>> > possible. In other respects it is identical, and can be used to copy an
>> > arbitrarily large buffer from userspace into the kernel. Conceptually,
>> > it exposes a similar attack surface.
>> >
>> > As with copy_from_user(), we check the destination range when the kernel
>> > is built with KASAN, but unlike copy_from_user() we do not check the
>> > destination buffer when using HARDENED_USERCOPY. As strncpy_from_user()
>> > calls get_user() in a loop, we must call check_object_size() explicitly.
>> >
>> > This patch adds this instrumentation to strncpy_from_user(), per the
>> > same rationale as with the regular copy_from_user(). In the absence of
>> > hardened usercopy this will have no impact as the instrumentation
>> > expands to an empty static inline function.
>
> [...]
>
>> Ah, yes, good catch! (And to repeat what you mentioned to me in
>> passing in the hall: there appear to be other users of get_user() in a
>> loop in other places in the kernel that will likely need some
>> attention too.)
>
> I was reminded of this as it just hit mainline; is it worth dropping a
> TODO on the KSPP wiki? I suspect I won't have the time to delve much
> further into this in the near term, and it might be a good intro task
> for someone.
>
> Thanks,
> Mark.

Yes. I believe that it is.

[toc] | [standalone]


Back to top | Article view | linux.kernel


csiph-web