Upgrade coreutils to 9.8 for CVE-2025-5278

[akhila-guruju]

Merge Checklist

All boxes should be checked before merging the PR (just tick any boxes which don't apply to this PR)

• The toolchain has been rebuilt successfully (or no changes were made to it)
• The toolchain/worker package manifests are up-to-date
• Any updated packages successfully build (or no packages were changed)
• Packages depending on static components modified in this PR (Golang, *-static subpackages, etc.) have had their Release tag incremented.
• Package tests (%check section) have been verified with RUN_CHECK=y for existing SPEC files, or added to new SPEC files
• All package sources are available
• cgmanifest files are up-to-date and sorted (./cgmanifest.json, ./toolkit/scripts/toolchain/cgmanifest.json, .github/workflows/cgmanifest.json)
• LICENSE-MAP files are up-to-date (./LICENSES-AND-NOTICES/SPECS/data/licenses.json, ./LICENSES-AND-NOTICES/SPECS/LICENSES-MAP.md, ./LICENSES-AND-NOTICES/SPECS/LICENSE-EXCEPTIONS.PHOTON)
• All source files have up-to-date hashes in the *.signatures.json files
• sudo make go-tidy-all and sudo make go-test-coverage pass
• Documentation has been updated to match any changes to the build system
• Ready to merge

---

Summary

Upgrade coreutils 9.4 → 9.8 (addresses CVE-2025-5278).
Rebase the i18n multibyte patch to 9.8 (coreutils-9.8-i18n.patch). Patch has been taken from Fedora.
Drop CVE-2024-0684.patch, fixed upstream in 9.5.

Build fix

Changed autoreconf -fi → AUTOPOINT=true autoreconf -fi in %build.

Why: coreutils declares AM_GNU_GETTEXT_VERSION([0.19.2]), so autopoint overwrites the tarball's bundled gnulib m4 macros with stale gettext‑0.19 copies that lack gl_ANYTHREADLIB_EARLY, gl_PTHREADLIB, gl_WEAK_SYMBOLS, gl_TYPE_WINT_T_PREREQ → autoreconf fails. Skipping autopoint keeps the tarball's already-coherent macro set (verified: those macros are defined in the bundled m4/threadlib.m4/wint_t.m4).

Chose AUTOPOINT=true over Fedora's sed 's/0.19.2/<gettext-ver>/' because it's version-independent (azl ships gettext 0.22, and gettext-devel is only a virtual Provide here), can't silently no-op on a future rebase, and needs no rpm -q/BuildRequires plumbing. Both fixes are functionally equivalent; this one is lower-maintenance for AZL.

Compatibility:

No library API/ABI change (coreutils ships executables, not a linkable library). Behavioral deltas are CLI-only, documented in NEWS, and auditable. The notable ones for scripts are cp -n/mv -n exit-status revert (9.5), ls -f flag semantics (9.6), and nproc cgroup‑v2 quota awareness (9.8). C/POSIX‑locale default behavior is unchanged.

Refs:
https://src.fedoraproject.org/rpms/coreutils/blob/20976b8be8f329b2ffc60ed31fba89ed8ad2106a/f/coreutils-i18n.patch
https://src.fedoraproject.org/rpms/coreutils/blob/f44/f/coreutils.spec

Change Log

• deleted: SPECS/coreutils/CVE-2024-0684.patch
• renamed: SPECS/coreutils/coreutils-9.4-i18n-1.patch -> SPECS/coreutils/coreutils-9.8-i18n.patch
• modified: SPECS/coreutils/coreutils.signatures.json
• modified: SPECS/coreutils/coreutils.spec
• modified: cgmanifest.json
• modified: toolkit/resources/manifests/package/pkggen_core_aarch64.txt
• modified: toolkit/resources/manifests/package/pkggen_core_x86_64.txt
• modified: toolkit/resources/manifests/package/toolchain_aarch64.txt
• modified: toolkit/resources/manifests/package/toolchain_x86_64.txt

Does this affect the toolchain?

YES

Associated issues

• #xxxx

Links to CVEs

• https://nvd.nist.gov/vuln/detail/CVE-2025-5278

Test Methodology

• Local Build

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[jslobodzian]

@akhila-guruju have you run an analysis for taking this upgrade? It appears to significantly impact the usage of nproc. Although the behavior is corrected in this version, it means anyone using it today in a typical kubernetes/AKS pod could have significant operational differences.

Old behavior (≤9.7):  nproc  calls  sched_getaffinity(2)  and counts the CPUs in the process's affinity mask.

New behavior (9.8):  nproc  also reads  cpu.max  from the process's cgroup-v2 hierarchy and takes the minimum of  affinity_count  and  ceil(quota / period) .

Why containers see a change

A typical Kubernetes/AKS pod with a CPU limit (not just a request) of, say,  500m  on a 16-core node gets:

• CPU affinity mask: still all 16 CPUs (the kernel doesn't pin container tasks to a subset — the scheduler enforces the quota via throttling instead).
• cgroup-v2  cpu.max :  50000 100000  → 0.5 CPU-seconds per 100ms period.

┌───────────┬───────────────────────────────────────┐
│ coreutils │ nproc returns │
├───────────┼───────────────────────────────────────┤
│ ≤9.7 │ 16 (affinity mask) │
├───────────┼───────────────────────────────────────┤
│ 9.8 │ 1 (ceil(0.5) = 1, and min(1, 16) = 1) │
└───────────┴───────────────────────────────────────┘

[akhila-guruju]

Thanks. I verified it against the 9.8 source: nproc now reads cgroup-v2 cpu.max and returns min(affinity_count, cpu_quota). NEWS documents it as "nproc now honors any cgroup v2 configured CPU quotas."

the quota is rounded half-up with a floor of 1, not ceil.

Scope of impact (confirmed in cpu_quota()):

• Only triggers on cgroup-v2 hosts with an explicit CPU limit (cpu.max != max) under a normal scheduler.
• No change for: requests-only/unlimited pods, cgroup-v1 hosts, or callers of nproc --all (which still reports the full node count).

My assessment is that this is an upstream correctness fix, not a regression: The old behavior (full node core count under a CPU limit) is precisely what causes container over-threading, and that over-threading then triggers CFS throttling. The new value matches the pod's real CPU budget, so workloads doing make -j$(nproc), worker_processes auto, JVM/Go/OpenMP auto-sizing, etc. get right-sized. Anyone who deliberately needs the host count can use nproc --all, which is unchanged.

[Kanishk-Bansal]

@jslobodzian we can take #18261