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

Groups > linux.kernel > #1503661 > unrolled thread

Re: [PATCH] proc: fix NULL dereference when reading /proc/<pid>/auxv

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: [PATCH] proc: fix NULL dereference when reading /proc/<pid>/auxv Al Viro <viro@ZenIV.linux.org.uk> - 2016-10-19 16:30 +0200
    Re: [PATCH] proc: fix NULL dereference when reading /proc/<pid>/auxv Leon Yu <chianglungyu@gmail.com> - 2016-10-19 17:00 +0200
    Re: [PATCH] proc: fix NULL dereference when reading /proc/<pid>/auxv Michal Hocko <mhocko@kernel.org> - 2016-10-19 17:00 +0200

#1503661 — Re: [PATCH] proc: fix NULL dereference when reading /proc/<pid>/auxv

On Wed, Oct 19, 2016 at 09:59:40PM +0800, Leon Yu wrote:
> Reading auxv of any kernel thread results in NULL pointer dereferencing in
> auxv_read() where mm can be NULL or even error code. Fix that by testing mm
> with IS_ERR_OR_NULL() helper. This is also the original behavior changed by
> recent commit c5317167854e ("proc: switch auxv to use of __mem_open()").

What the...  How can it be ERR_PTR(...) after it has passed __mem_open()?
I agree that we ought to check for NULL mm (the only question is whether it's
best done by failing open() or by treating the file as empty), but this
IS_ERR_OR_NULL() is pure cargo-cult, AFAICS.

[toc] | [next] | [standalone]

#1503780

On Wed, Oct 19, 2016 at 10:20 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> On Wed, Oct 19, 2016 at 09:59:40PM +0800, Leon Yu wrote:
> > Reading auxv of any kernel thread results in NULL pointer dereferencing in
> > auxv_read() where mm can be NULL or even error code. Fix that by testing mm
> > with IS_ERR_OR_NULL() helper. This is also the original behavior changed by
> > recent commit c5317167854e ("proc: switch auxv to use of __mem_open()").
>
> What the...  How can it be ERR_PTR(...) after it has passed __mem_open()?

Doh.. didn't realize that IS_ERR() case can't happen.

> I agree that we ought to check for NULL mm (the only question is whether it's
> best done by failing open() or by treating the file as empty), but this
> IS_ERR_OR_NULL() is pure cargo-cult, AFAICS.

Treating the file in question as empty might be a better choice, just in case
something depends on old behavior.

-Leon

[toc] | [prev] | [next] | [standalone]

#1503782

On Wed 19-10-16 15:20:15, Al Viro wrote:
> On Wed, Oct 19, 2016 at 09:59:40PM +0800, Leon Yu wrote:
> > Reading auxv of any kernel thread results in NULL pointer dereferencing in
> > auxv_read() where mm can be NULL or even error code. Fix that by testing mm
> > with IS_ERR_OR_NULL() helper. This is also the original behavior changed by
> > recent commit c5317167854e ("proc: switch auxv to use of __mem_open()").
> 
> What the...  How can it be ERR_PTR(...) after it has passed __mem_open()?
> I agree that we ought to check for NULL mm (the only question is whether it's
> best done by failing open() or by treating the file as empty), but this

I believe failing open is a better approach because even if a particualr
thread has hijacked a mm via use_mm then the output we will provide is
misleading at best. See my suggestion
http://lkml.kernel.org/r/20161019141346.GJ7517@dhcp22.suse.cz
-- 
Michal Hocko
SUSE Labs

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web