A signedness issue has been found in next_pidmap() function when the "last"
parameter is negative as next_pidmap() just quietly accepted whatever
"last" pid that was passed in, which is not all that safe when one of the
users is /proc.

Setting f_pos to negative value when accessing /proc via readdir()/getdents()
resulted in sign extension of this value when map pointer was being
constructed.

This later lead to #GP becasue the final pointer was not cannonical (x86_64).

map = &pid_ns->pidmap[(last + 1)/BITS_PER_PAGE];
 ffffffff810ac3b4:       48 63 f6                movslq %esi,%rsi      <- sign extension (f_pos+-)
 ffffffff810ac3b7:       81 e2 ff 7f 00 00       and    $0x7fff,%edx 
 ffffffff810ac3bd:       48 c1 ee 0f             shr    $0xf,%rsi
 ffffffff810ac3c1:       48 c1 e6 04             shl    $0x4,%rsi
 ffffffff810ac3c5:       48 8d 5c 37 08          lea    0x8(%rdi,%rsi,1),%rbx 
  ...
if (unlikely(!map->page)) 
 ffffffff810ac3cc:       48 8b 7b 08             mov    0x8(%rbx),%rdi <- #GP

Only x86_64 architecture seems to be vulnerable to this particular issue
(tested ppc64, s390x, ia64).

Reference:
http://groups.google.com/group/fa.linux.kernel/browse_thread/thread/93c1088451fd3522/4a28ecb7f755a88d?#4a28ecb7f755a88d

Upstream commit:
http://git.kernel.org/linus/c78193e9
http://git.kernel.org/linus/d8bdc59f

Acknowledgements:

Red Hat would like to thank Robert Swiecki for reporting this issue.