linux-kernel - Re: 3.6rc6 slab corruption.

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: <CA+55aFy6=1vW4CN0_g8BgSKKdxZNZj9Yd2WG=0BFKjish=Vw=g@mail.gmail.com>
Date:	Tue, 18 Sep 2012 13:35:00 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
Cc:	Dave Jones <davej@...hat.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Srivatsa Vaddagiri <vatsa@...ux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@...ibm.com>,
	Raghavendra K T <raghavendra.kt@...ux.vnet.ibm.com>
Subject: Re: 3.6rc6 slab corruption.

On Tue, Sep 18, 2012 at 12:23 PM, Konrad Rzeszutek Wilk
<konrad.wilk@...cle.com> wrote:
>>
>> It should be easyish to fix by just adding a lock around those things.
>
> Like this:

Not quite.

I suspect you need to protect the "read_from_buffer()" call too, since
otherwise the buffer can be free'd by another thread while being
copied to user space..

>>  - the whole format_array_alloc() code is one buggy piece of sh*t,
>> since afaik there is nothing that guarantees that the values cannot
>> change. So the notion of "let's format the output once to know how big
>> it is, and then a second time to actually print things into the array
>> we just allocated based on the first time" is pure and utter garbage,
>> afaik.
>
> Yikes. The fix could be to allocate a buffer large enough for the maximum
> that %u could take * array_size and not bother with the first pass.

That's the simple approach. An alternative approach would be to start
with a reasonable guess as to the size, and use krealloc() if needed
to expand.

What are the realistic array sizes? If we're talking about arrays of
just 16 words or something, just do the maximum (what, 12 bytes per
32-bit word? 11 bytes for the number, and then space/NUL after that).

If we're talking about potentially much bigger arrays, maybe we need
to use krealloc() to handle it without wasting tons of memory for the
common case..

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