linux-kernel - Re: [PATCH] Avoid truncating to 'long' in ALIGN() macro

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: <ada64d23ty8.fsf@cisco.com>
Date:	Sun, 26 Nov 2006 11:10:23 -0800
From:	Roland Dreier <rdreier@...co.com>
To:	Andrew Morton <akpm@...l.org>
Cc:	David Miller <davem@...emloft.net>, linux-kernel@...r.kernel.org,
	openib-general@...nib.org, tom@...ngridcomputing.com
Subject: Re: [PATCH] Avoid truncating to 'long' in ALIGN() macro

Commit 4c8bd7ee ("Do not truncate to 'int' in ALIGN() macro.") was
merged to fix the case of code like the following:

	unsigned long addr;
	unsigned int alignment;
	addr = ALIGN(addr, alignment);

The original ALIGN macro calculated a mask as ~(alignment - 1), and
when alignment is just an int, this creates an int mask.  If alignment
is also unsigned, then this mask will not be sign extended when
promoted to a long, which leads to the code above chopping off the top
half of addr when long is 64 bits.

However, the changed ALIGN macro, which computes the mask as
~(alignment - 1UL) actually breaks code like the following when long
is 32 bits:

	u64 addr;
        int alignment;
        addr = ALIGN(addr, alignment);

The reason this breaks is pretty much the same as the original bug
that the change was supposed to fix: ~(alignment - 1UL) creates a mask
that is an unsigned long, which is not sign extended when promoted to
u64 (if long is 32 bits).

As suggested by Dave Miller and Al Viro, I fixed this by having the
ALIGN macro make sure the alignment is promoted to the same type as
the value being aligned before doing the negation.

This second construct is actually used in the amso1100 driver, so that
driver does not work on 32-bit architectures right now.  Unfortunately
almost everyone using it runs 64-bit kernels, so this regression was
not noticed until now.

Signed-off-by: Roland Dreier <rolandd@...co.com>

---
Patch updated as suggested by Dave Miller and Al Viro...

can we merge this for 2.6.20?

diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 24b6111..80955b3 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -31,7 +31,7 @@ #define ULLONG_MAX	(~0ULL)
 #define STACK_MAGIC	0xdeadbeef

 #define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
-#define ALIGN(x,a) (((x)+(a)-1UL)&~((a)-1UL))
+#define ALIGN(x,a) ((typeof(x)) (((x) + (a) - 1) & ~((typeof(x)) (a) - 1)))
 #define FIELD_SIZEOF(t, f) (sizeof(((t*)0)->f))
 #define DIV_ROUND_UP(n,d) (((n) + (d) - 1) / (d))
 #define roundup(x, y) ((((x) + ((y) - 1)) / (y)) * (y))
-
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/