glibc: cherry-pick fix for CVE-2023-4911 "Looney Tunables"

[ghost]

Description of changes

• Reported by Qualys. Advisory, which notes that:

historically, the processing of environment variables such as LD_PRELOAD, LD_AUDIT, and LD_LIBRARY_PATH has been a fertile source of vulnerabilities in the dynamic loader."

• There is a working exploit.

• Upstream fix commit

Things done

• Built on platform(s)
  • x86_64-linux
  • powerpc64le-linux
  • mips64el-linux
  • aarch64-linux

See also

• [staging] glibc: cherry-pick fix for CVE-2023-4911 "Looney Tunables" #258857

[martinetd]

Patch matches the relevant part of https://sourceware.org/git/?p=glibc.git;a=commit;h=1056e5b4c3f2d90ed2b4a55f96add28da2f4c8fa "tunables: Terminate if end of input is reached (CVE-2023-4911)"

Thanks!

[fiksn]

Until this gets merged I am running an overlay like this on my machine:

self: super:
let fetchpatch = (import super.path { }).fetchpatch; in
{
  glibc = super.glibc.overrideAttrs (old: rec {
    patches = old.patches ++ [
      (fetchpatch {
        name = "CVE-2023-4911.patch";
        url = "https://sourceware.org/git/?p=glibc.git;a=commitdiff_plain;h=1056e5b4c3f2d90ed2b4a55f96add28da2f4c8fa;hp=0d5f9ea97f1b39f2a855756078771673a68497e1";
        hash = "sha256-3J55jF0I7AUHyh8QAFCDcBCpfymmnlgrlMcSM1/dM6I=";
        excludes = [ "*tst-env-setuid-tunables.c*" ];
      })
    ];
  });
}

this should be equivalent or am I missing something?

[ghost]

this should be equivalent or am I missing something?

What you wrote will build glibc twice... first it will build an unpatched glibc and use that to build curl and fetchPatch in order to download the fix. Then it will rebuild glibc a second time with the fix.

For personal use, probably not a big deal. Avoiding build-everything-twice is why I had to put a copy of the patch in the PR.

You might be able to avoid this by using fetchurlBoot and the cgit url for the single-file patch (it's nice that cgit offers this!) The URL you want is the one that's in the .nix file in my PR as a comment at the top of the .patch file in this PR. We can't do this in nixpkgs either though, because the patches that cgit spits out aren't guaranteed to be bit-for-bit identical when you upgrade cgit -- things like header formatting and whitespace often change.

PS, you can drop the rec keyword.

[fiksn]

You might be able to avoid this by using fetchurlBoot and the cgit url for the single-file patch (it's nice that cgit offers this!)

I see, so fetchurlBoot is a way to break this chicken and egg problem.
Actually this one got me quite confused. When I used super.fetchpatch this apparently called the bare-bones boot function which failed with a weird message about:

fetchurl/boot.nix:5:1 called with unexpected argument 'postFetch'

This error message should probably get improved in the lines of "you are using the minimalistic version of fetchurl, make sure to use the real one like this..."

That's why I ended up with:

let fetchpatch = (import super.path { }).fetchpatch; in

which is quite ugly.

We can't do this in nixpkgs either though, because the patches that cgit spits out aren't guaranteed to be bit-for-bit identical when you upgrade cgit -- things like header formatting and whitespace often change.

Oh didn't know that. So if they upgrade cgit build might break because hash will be different. But doesn't fetchpatch already use filterdiff to "normalize" the patch? And hash is then based on that output, meaning any whitespace changes of the cgit output shouldn't matter. But OTOH I can understand that having the patch locally is much easier indeed.

PS, you can drop the rec keyword.

Ah yeah, thx.

[flokli]

Closing this in favor of #258972 (backport PR #258975).

It targets staging, and contains a patchlevel update.