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  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:	Tue, 08 Jul 2008 11:28:32 +0200
From:	Johannes Weiner <>
To:	Rusty Russell <>
Cc:	Mike Travis <>,,
	"H. Anvin" <>,
	Christoph Lameter <>,
	Ingo Molnar <>
Subject: Re: Dangerous code in cpumask_of_cpu?

[ fixed christoph's address in cc]

Johannes Weiner <> writes:

>> I guess because we dereference it immediately again, the location is not
>> clobbered yet.  At least in my test case, gcc assembled it to code that
>> puts the address in eax and derefences it immediately, before eax is
>> reused:
> Gee, just ignore this bs.  The address is in eax, not the value.

My theory was half-right.  Since the code is a macro, there is no call
and hence no stack clean-up.  And although it is UB, it works correctly
as the value is not yet clobbered when we access it again.  Converting
foo to a macro yields this:

        movl    $42, -8(%ebp)
        leal    -8(%ebp), %eax
        movl    (%eax), %eax

gcc only emits a warning if the scope we leak a local address from is
that of a function.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists