[natty, natty/ti-omap4 CVE 1/1] ipv6: make fragment identifications less predictable

Stefan Bader stefan.bader at canonical.com
Wed Aug 24 10:42:35 UTC 2011


On 24.08.2011 12:30, Andy Whitcroft wrote:
> On Wed, Aug 24, 2011 at 11:53:30AM +0200, Stefan Bader wrote:
> 
>>> -static __inline__ void ipv6_select_ident(struct frag_hdr *fhdr)
>>> -{
>>> -	static u32 ipv6_fragmentation_id = 1;
>>> -	static DEFINE_SPINLOCK(ip6_id_lock);
>>> -
>>> -	spin_lock_bh(&ip6_id_lock);
>>> -	fhdr->identification = htonl(ipv6_fragmentation_id);
>>> -	if (++ipv6_fragmentation_id == 0)
>>> -		ipv6_fragmentation_id = 1;
>>> -	spin_unlock_bh(&ip6_id_lock);
>>> -}
> 
> This _old_ code ensures that fragmentation_id is never == 0, and that
> value is used directly without modification.  An id of 0 is invalid.
> 
>>> +static u32 hashidentrnd __read_mostly;
>>> +#define FID_HASH_SZ 16
>>> +static u32 ipv6_fragmentation_id[FID_HASH_SZ];
>>> +
>>> +void __init initialize_hashidentrnd(void)
>>> +{
>>> +	get_random_bytes(&hashidentrnd, sizeof(hashidentrnd));
>>> +}
>>> +
>>> +static u32 __ipv6_select_ident(const struct in6_addr *addr)
>>> +{
>>> +	u32 newid, oldid, hash = jhash2((u32 *)addr, 4, hashidentrnd);
>>> +	u32 *pid = &ipv6_fragmentation_id[hash % FID_HASH_SZ];
>>> +
>>> +	do {
>>> +		oldid = *pid;
>>> +		newid = oldid + 1;
>>> +		if (!(hash + newid))
>>> +			newid++;
>>
>> I am trying to understand what hash + newid is supposed to tell. Looking at the
>> old code there was a test to prevent the id from being 0 when it wrapped. If I
>> understand this patch correctly there is now multiple ids selected based on the
>> addresses hash... So why is the above not just
>>
>> if (!newid)
>>   newid = 1;
>>
>> ?
>>
>>> +	} while (cmpxchg(pid, oldid, newid) != oldid);
>>> +
>>> +	return hash + newid;
>>> +}
> 
> The key here is that the value which will be used is this last one at
> the end.  It will return hash + newid.  It is that value which must not
> be 0 as it is that which is used as the id.  Therefore the check is
> hash + newid not being 0 to match the return.
> 
> -apw

I see. Somehow missed that the whole hash+newid is returned for assignment and
only the newid part being stored in a bucket...



More information about the kernel-team mailing list