linux-kernel - Re: [3.10] Oopses in kmem_cache_allocate() via prepare

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]

Date:	Sat, 30 Nov 2013 09:25:33 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Simon Kirby <sim@...tway.ca>
Cc:	Ian Applegate <ia@...udflare.com>,
	Al Viro <viro@...iv.linux.org.uk>,
	Christoph Lameter <cl@...two.org>,
	Pekka Enberg <penberg@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Chris Mason <chris.mason@...ionio.com>
Subject: Re: [3.10] Oopses in kmem_cache_allocate() via prepare_creds()

On Sat, Nov 30, 2013 at 1:43 AM, Simon Kirby <sim@...tway.ca> wrote:
> On Tue, Nov 26, 2013 at 03:16:09PM -0800, Linus Torvalds wrote:
>>
>> The pipe-info structure isn't using its own slab cache, it's just
>> using "kmalloc()". So it by definition will merge with all other
>> kmalloc() allocations of the same size (or, to be exact, of "similar
>> enough size to hit the same size bucket"). In your case it's the
>> 192-byte-sized bucket.
>
> I turned on kmalloc-192 tracing to find what else is using it: struct
> nfs_fh, struct bio, and struct cred. Poking around those, struct bio has
> bi_cnt, but it is way down in the struct. struct cred has "usage", but it
> comes first. Hmm. Nevertheless, I set:
>
> CONFIG_DEBUG_MUTEXES=y
> CONFIG_DEBUG_LIST=y
> CONFIG_DEBUG_CREDENTIALS=y
>
> And tried:
>
> diff --git a/include/linux/cred.h b/include/linux/cred.h
> index 04421e8..2646fe9 100644
> --- a/include/linux/cred.h
> +++ b/include/linux/cred.h
> @@ -205,7 +205,9 @@ static inline void validate_process_creds(void)
>   */
>  static inline struct cred *get_new_cred(struct cred *cred)
>  {
> -       atomic_inc(&cred->usage);
> +       if (atomic_inc_return(&cred->usage) == 0x6c) {
> +               WARN_ON(cred->uid == 0x6b);

Oh, damn, I thought you had found it, and got very excited and already
wrote a long email about things I wanted you to try. And then I
started looking closer...

That test is wrong. Both of those fields are 32-bit, so testing them
against 0x6b/0x6c is bogus: you're just catching real cases. The
reason it catches omreport is presumably because omreport runs as some
special user that happens to have uid 107 (on my machine that happens
to be qemu). And having a usage count of 108 isn't particularly
strange either - creds get a lot of re-use.

So close. It *might* still be one of those cases, but it doesn't
really sound very likely. "bi_cnt" is deep inside the struct bio, and
"usage" is at offset 0, not offset 4. And the ns_fh isn't very
interesting.

             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/