linux-kernel - Re: Linux 4.9.256

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <YCE2nw66fHfk6lFt@kroah.com>
Date:   Mon, 8 Feb 2021 14:03:27 +0100
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Florian Weimer <fweimer@...hat.com>
Cc:     linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
        torvalds@...ux-foundation.org, stable@...r.kernel.org, lwn@....net,
        jslaby@...e.cz
Subject: Re: Linux 4.9.256

On Mon, Feb 08, 2021 at 01:57:12PM +0100, Florian Weimer wrote:
> * Greg Kroah-Hartman:
> 
> > 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).
> >
> > Nothing in the kernel build itself breaks with this change, but given
> > that this is a userspace visible change, and some crazy tools (like
> > glibc and gcc) have logic that checks the kernel version for different
> > reasons, I wanted to do this release as an "empty" release to ensure
> > that everything still works properly.
> 
> I'm looking at this from a glibc perspective.  glibc took the
> KERNEL_VERSION definition and embedded the bit layout into the
> /etc/ld.so.cache, as part of the file format.  Exact impact is still
> unclear at this point.

If we "cap" this at 4, 9, 255 according to what userspace sees, will
that be a problem if we increase the number reported by uname(2)?

And when is the ld.so.cache file "regenerated"?

thanks,

greg k-h