linux-kernel - Re: [PATCH] Fix a race in pid generation that causes pids to be reused

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20100611182954.20294.qmail@science.horizon.com>
Date:	11 Jun 2010 14:29:54 -0400
From:	"George Spelvin" <linux@...izon.com>
To:	linux-kernel@...r.kernel.org, sqazi@...gle.com
Cc:	allan.stephens@...driver.com, linux@...izon.com,
	peterz@...radead.org, torvalds@...ux-foundation.org
Subject: Re: [PATCH] Fix a race in pid generation that causes pids to be reused

> Isn't: return a - base < b - base, the natural way to express this?

Quite right.

I see people managed to figure it out, but my, what a lot of angst
over something so familiar to any network hacker trying to figure out
if a received sequence number is in the receive window or not.

See include/net/tcp.h:
265: /* is s2<=s1<=s3 ? */
266: static inline int between(__u32 seq1, __u32 seq2, __u32 seq3)
267: {
268: 	return seq3 - seq2 >= seq1 - seq2;
269: }

(If someone wants to fix the far uglier version in net/tipc/link.h...
Allan, Cc: to you.)

If you want to handle strictly conforming ANSI C, then you have to
cast everything to unsigned before the subtraction, but in practice,
casting afterward works just as well:

	return (unsigned)a - (unsigned)base < (unsigned)b - (unsigned)base;
	return (unsigned)(a - base) < (unsigned)(b - base)

Conceptually, it's "is the distance forward from base to a less than
the distance forward from base to b"?  The "forward" is enforced by the
unsigned cast.

If the numbers wrap before UINT_MAX, the logic still works; it doesn't
care if values between PID_MAX_LIMIT and UINT_MAX are "illegal and may not
be assigned" or "by merest chance happen to not be assigned".
--
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/