[patch 068/123] skbuff: align sk_buff::cb to 64 bit and close some potential holes

From: Greg KH
Date: Fri Mar 12 2010 - 19:21:17 EST


2.6.33-stable review patch. If anyone has any objections, please let me know.

-----------------

From: Felix Fietkau <nbd@xxxxxxxxxxx>

commit da3f5cf1f8ebb0fab5c5fd09adb189166594ad6c upstream.

The alignment requirement for 64-bit load/store instructions on ARM is
implementation defined. Some CPUs (such as Marvell Feroceon) do not
generate an exception, if such an instruction is executed with an
address that is not 64 bit aligned. In such a case, the Feroceon
corrupts adjacent memory, which showed up in my tests as a crash in the
rx path of ath9k that only occured with CONFIG_XFRM set.

This crash happened, because the first field of the mac80211 rx status
info in the cb is an u64, and changing it corrupted the skb->sp field.

This patch also closes some potential pre-existing holes in the sk_buff
struct surrounding the cb[] area.

Signed-off-by: Felix Fietkau <nbd@xxxxxxxxxxx>
Signed-off-by: David S. Miller <davem@xxxxxxxxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxx>

---
include/linux/skbuff.h | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)

--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -315,22 +315,23 @@ struct sk_buff {
struct sk_buff *next;
struct sk_buff *prev;

- struct sock *sk;
ktime_t tstamp;
+
+ struct sock *sk;
struct net_device *dev;

- unsigned long _skb_dst;
-#ifdef CONFIG_XFRM
- struct sec_path *sp;
-#endif
/*
* This is the control buffer. It is free to use for every
* layer. Please put your private variables there. If you
* want to keep them across layers you have to do a skb_clone()
* first. This is owned by whoever has the skb queued ATM.
*/
- char cb[48];
+ char cb[48] __aligned(8);

+ unsigned long _skb_dst;
+#ifdef CONFIG_XFRM
+ struct sec_path *sp;
+#endif
unsigned int len,
data_len;
__u16 mac_len,


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/