Messages in this thread | | | Subject | Re: Linux 4.9.256 | From | Avi Kivity <> | Date | Tue, 9 Feb 2021 10:53:15 +0200 |
| |
On 2/8/21 8:57 PM, Sasha Levin wrote: > On Mon, Feb 08, 2021 at 05:50:21PM +0200, Avi Kivity wrote: >> On 05/02/2021 16.26, Greg Kroah-Hartman wrote: >>> I'm announcing the release of the 4.9.256 kernel. >>> >>> This, and the 4.4.256 release are a little bit "different" than normal. >>> >>> This contains only 1 patch, just the version bump from .255 to .256 >>> which ends >>> up causing the userspace-visable LINUX_VERSION_CODE to behave a bit >>> differently >>> than normal due to the "overflow". >>> >>> With this release, KERNEL_VERSION(4, 9, 256) is the same as >>> KERNEL_VERSION(4, 10, 0). >> >> >> I think this is a bad idea. Many kernel features can only be >> discovered by checking the kernel version. If a feature was >> introduced in 4.10, then an application can be tricked into thinking >> a 4.9 kernel has it. >> >> >> IMO, better to stop LINUX_VERSION_CODE at 255 and introduce a > > In the upstream (and new -stable fix) we did this part. > >> LINUX_VERSION_CODE_IMPROVED that has more bits for patchlevel. > > Do you have a usecase where it's actually needed? i.e. userspace that > checks for -stable patchlevels? >
Not stable patchlevels, but minors. So a change from 4.9 to 4.10 could be harmful.
I have two such examples (not on the 4.9->4.10 boundary), but they test the runtime version from uname(), not LINUX_VERSION_CODE, so they would be vulnerable to such a change.
| |