-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
glibc: backport patch to fix CVE-2023-4911 #46415
Conversation
@@ -0,0 +1,417 @@ | |||
From patchwork Tue Oct 3 17:08:10 2023 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we need to include all the email headers?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed most of the headers.
8699f96
to
6b20f80
Compare
6b20f80
to
fd2b430
Compare
revision=1 | ||
revision=2 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just sanity-checking myself here: I'm doing a custom rootfs build courtesy of @JamiKettunen, and it's failing on unresolved shlibs
from the glibc
package. Should the revision suffix in common/shlibs
have been bumped to glibc-2.36_2
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no
that error probably means there's something being installed that was removed from the repositories at some point
the full error message is generally useful to include but also this is not the place to discuss this. create an issue instead
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did not want to spam a massive error message here for something that's likely broken on our end in either the script or our (dated!) package overlay(s).
In any case, substituting glibc-2.36_1
for glibc-2.36_2
in common/shlibs
fixes it. I'll leave it to @JamiKettunen to sort out whether that's expected.
https://lwn.net/ml/oss-security/20231003175031.GA16924@localhost.localdomain/