hardy custom binary kernels have incorrect version reported in /proc/version_signature

Bug Description

SRU Justification:
Impact: all binary-custom kernels including those in EC2 report an incorrect and very old kernel version via /proc/version_signature
Fix: see patch attached below
Testcase: compare the contents of /proc/version_signature to uname -a

===

All custom binaries are built with the wrong contents in the /proc/version_signature file. _all_ custom binaries report the same unchanging version, which is both not for their flavour and not the right base version:

$ uname -a && cat /proc/version_signature
Linux ip-10-36-7-174 2.6.24-29-xen #1 SMP Thu Apr 21 20:44:30 UTC 2011 i686 GNU/Linux
Ubuntu 2.6.24-4.6-generic

This leads to great confusion identifying the kernel, which is particularly serious on -xen where the kernel can come from outside the domU.

Proposed patch.

This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-hardy' to 'verification-done-hardy'.

If verification is not done by one week from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

test@d1521:~$ uname -a && cat /proc/version_signature
Linux d1521 2.6.24-29-xen #1 SMP Fri Jun 24 19:54:17 UTC 2011 x86_64 GNU/Linux
Ubuntu 2.6.24-29.91-xen

This bug was fixed in the package linux - 2.6.24-29.91

---------------
linux (2.6.24-29.91) hardy-proposed; urgency=low

[Steve Conklin]

* Release Tracking Bug
- LP: #801636

[Andy Whitcroft]

* custom binaries need VERSION_SIGNATURE updated during prepare
- LP: #794698

[Stefan Bader]

* (config) Disable COMPAT_VDSO for i386 Xen kernels
- LP: #794715
* XEN: Add yield points to blktap and blkback
- LP: #791212
- CVE-2010-4247
* xen: Fix memory corruption caused by double free
- LP: #705562

[Upstream Kernel Changes]

* agp: fix arbitrary kernel memory writes, CVE-1011-2022
- LP: #788684
- CVE-1011-2022
* agp: fix OOM and buffer overflow
- LP: #791918
- CVE-2011-1746
* tty: icount changeover for other main devices, CVE-2010-4076,
CVE-2010-4077
- LP: #794034
- CVE-2010-4077
* fs/partitions/efi.c: corrupted GUID partition tables can cause kernel
oops
- LP: #795418
- CVE-2011-1577
* Fix corrupted OSF partition table parsing
- LP: #796606
- CVE-2011-1163
* proc: avoid information leaks to non-privileged processes
- LP: #799906
- CVE-2011-0726
* proc: protect mm start_code/end_code in /proc/pid/stat
- LP: #799906
- CVE-2011-0726
* sctp: Fix a race between ICMP protocol unreachable and connect()
- LP: #799828
- CVE-2010-4526
* xen: blkback, blktap: Fix potential resource leak
- LP: #800254
-- Steve Conklin <email address hidden> 2011年6月24日 10:59:11 -0500

Not sure if this is related or if I am doing something wrong, but this looks like it is also present in Lucid. I built a custom kernel to add PPS support. The first version went well, however re-building with newer (or older) source from the Git repos yields '/proc/version_signature' to lie.

My first build was with 2.6.32-33.66; version sig is correct, was also running native 2.6.32-33.66 at the time.
The next was with 2.6.32-33.72; version sig still says 2.6.32-33.66, running 2.6.32-33.66 w/PPS patch at the time.
Last test was with 2.6.32-28.55; version sig still says 2.6.32-33.66, running 2.6.32-33.72 w/PPS patch at the time.

Tried on two systems...any one have any ideas why this is happening? The kernels work fine otherwise. Thanks.

Also, in my script, I just add '+pps' to the kernel name...

2.6.x-y.z-[STRING]+pps

And the revision number is...

2.6.x-y.z~1
2.6.x-y.z~2
2.6.x-y.z~n ... and so on.

Oops, I ment...

2.6.x-y-[STRING]+pps

...not...

2.6.x-y.z-[STRING]+pps

for the kernel name.