linux-kernel - Re: [PATCH] vfs: rw_copy_check_uvector()

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: <CAJfpegs9cgVgxbYZSM=SxyJqj=N1QA5npp7ic6i80CMec+3sZw@mail.gmail.com>
Date:	Tue, 22 Apr 2014 10:42:52 +0200
From:	Miklos Szeredi <miklos@...redi.hu>
To:	Dave Jones <davej@...hat.com>, Miklos Szeredi <miklos@...redi.hu>,
	Al Viro <viro@...iv.linux.org.uk>,
	Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux-Fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH] vfs: rw_copy_check_uvector() - free iov on error

On Mon, Apr 21, 2014 at 5:50 PM, Dave Jones <davej@...hat.com> wrote:
> On Wed, Apr 16, 2014 at 02:04:22PM -0400, Dave Jones wrote:
>  > On Tue, Apr 15, 2014 at 04:57:49PM +0200, Miklos Szeredi wrote:
>  >
>  >  > Some callers (aio_run_iocb, vmsplice_to_user) forget to free the iov on
>  >  > error.  This seems to be a recurring problem, with most callers being buggy
>  >  > initially.
>  >
>  > Your patch looks a lot more complete than the quick hack I did a few
>  > days ago when coverity first started nagging about this, but in testing
>  > I've found that something really ugly starts showing up when you patch this
>  >
>  > The symptoms vary, but always are some kind of slab corruption.
>  > Here's the last example:
>  >
>  > =============================================================================
>  > BUG kmalloc-256 (Not tainted): Invalid object pointer 0xffff8802407adc60
>  > -----------------------------------------------------------------------------
>  >
>  > Disabling lock debugging due to kernel taint
>  > INFO: Slab 0xffffea000901eb00 objects=28 used=22 fp=0xffff8802407ad6d0 flags=0x20000000004081
>  > CPU: 1 PID: 1185 Comm: trinity-c1 Tainted: G    B         3.15.0-rc1+ #191
>  >  ffff880243c073c0 00000000f952f249 ffff8800a1a2bc10 ffffffffbd74686d
>  >  ffffea000901eb00 ffff8800a1a2bce8 ffffffffbd1b0cd4 ffffffff00000020
>  >  ffff8800a1a2bcf8 ffff8800a1a2bca8 61766e4943c00a18 656a626f2064696c
>  > Call Trace:
>  >  [<ffffffffbd74686d>] dump_stack+0x4e/0x7a
>  >  [<ffffffffbd1b0cd4>] slab_err+0xb4/0xe0
>  >  [<ffffffffbd0bf3ae>] ? put_lock_stats.isra.23+0xe/0x30
>  >  [<ffffffffbd1b0da6>] ? slab_pad_check.part.44+0xa6/0x170
>  >  [<ffffffffbd744e7f>] free_debug_processing+0x88/0x22a
>  >  [<ffffffffbd1c7041>] ? compat_do_readv_writev+0xe1/0x250
>  >  [<ffffffffbd74506d>] __slab_free+0x4c/0x2c3
>  >  [<ffffffffbd1c6679>] ? do_sync_readv_writev+0x59/0xa0
>  >  [<ffffffffbd1b2614>] kfree+0x214/0x220
>  >  [<ffffffffbd1c7041>] ? compat_do_readv_writev+0xe1/0x250
>  >  [<ffffffffbd1c7041>] compat_do_readv_writev+0xe1/0x250
>  >  [<ffffffffbd0bf716>] ? lock_release_holdtime.part.24+0xe6/0x160
>  >  [<ffffffffbd0a3ccd>] ? get_parent_ip+0xd/0x50
>  >  [<ffffffffbd75642b>] ? preempt_count_sub+0x6b/0xf0
>  >  [<ffffffffbd751a01>] ? _raw_spin_unlock+0x31/0x50
>  >  [<ffffffffbd349883>] ? __this_cpu_preempt_check+0x13/0x20
>  >  [<ffffffffbd1c730a>] compat_writev+0x3a/0x80
>  >  [<ffffffffbd1c85d8>] compat_SyS_writev+0x58/0xd0
>  >  [<ffffffffbd75c6a9>] ia32_do_call+0x13/0x13
>  > FIX kmalloc-256: Object at 0xffff8802407adc60 not freed
>  >
>  >
>  > I also had an incomplete trace that showed vmsplice causing a bug in mm/slub.c:3396
>  > on an earlier run.
>  >
>  > The crash happens very quickly (within a few seconds of running trinity) for me.
>
> Al, Miklos ?

I probably am blind, but I can't see how that will cause slab corruption.

Have you verified that it's just that single patch and no other change?

Thanks,
Miklos
--
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/