linux-kernel - [perf] yet another 32/64-bit range check failure

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-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.10.1404222329590.28273@vincent-weaver-1.um.maine.edu>
Date:	Tue, 22 Apr 2014 23:40:07 -0400 (EDT)
From:	Vince Weaver <vincent.weaver@...ne.edu>
To:	linux-kernel@...r.kernel.org
cc:	Ingo Molnar <mingo@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>
Subject: [perf] yet another 32/64-bit range check failure

More fun found by the perf_fuzzer...

In kernel/events/core.c 
SYSCALL_DEFINE5(perf_event_open,

We check if flags is valid like this:

        /* for future expandability... */
        if (flags & ~PERF_FLAG_ALL)
                return -EINVAL;

but flags is a 64-bit value but ~PERF_FLAG_ALL is 32-bit.

This means values like 0x800000000000ULL are treated as valid even though 
they aren't.

This is allowing events to be allocated memory but not being freed somehow
before returning EINVAL (a memory leak).
At least it looks like this is happening in the huge traces I have trying 
to track down the perf_fuzzer memory corruption bug.

I'd send a patch to fix the above, but it's late and I can't figure out 
where exactly to stick ULL to get PERF_FLAG_ALL to be upgraded to 64-bit.

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