[AutoPR- Security] Patch glib for CVE-2026-58016, CVE-2026-58015, CVE-2026-58014, CVE-2026-58013, CVE-2026-58012, CVE-2026-58011, CVE-2026-58010 [HIGH]

[azurelinux-security]

Auto Patch glib for CVE-2026-58016, CVE-2026-58015, CVE-2026-58014, CVE-2026-58013, CVE-2026-58012, CVE-2026-58011, CVE-2026-58010.

Autosec pipeline run -> https://dev.azure.com/mariner-org/mariner/_build/results?buildId=1150775&view=results

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

What does the PR accomplish, why was it needed?

• Auto Patch glib for CVE-2026-58016 (MEDIUM), CVE-2026-58015 (MEDIUM), CVE-2026-58014 (HIGH), CVE-2026-58013 (MEDIUM), CVE-2026-58012 (MEDIUM), CVE-2026-58011 (MEDIUM), CVE-2026-58010 (MEDIUM).

Change Log

• CVE-2026-58016
• CVE-2026-58015
• CVE-2026-58014
• CVE-2026-58013
• CVE-2026-58012
• CVE-2026-58011
• CVE-2026-58010

Does this affect the toolchain?

YES/NO

Associated issues

• N/A

Links to CVEs

• https://nvd.nist.gov/vuln/detail/CVE-2026-58016
• https://nvd.nist.gov/vuln/detail/CVE-2026-58015
• https://nvd.nist.gov/vuln/detail/CVE-2026-58014
• https://nvd.nist.gov/vuln/detail/CVE-2026-58013
• https://nvd.nist.gov/vuln/detail/CVE-2026-58012
• https://nvd.nist.gov/vuln/detail/CVE-2026-58011
• https://nvd.nist.gov/vuln/detail/CVE-2026-58010

Test Methodology

• Pipeline build id: Buddy Build URL

[Kanishk-Bansal]

Buddy Build

[Kanishk-Bansal]

LGTM

Patch Analysis for CVE-2026-58016 (The critical logic fix matches upstream exactly:
if (!(g_slist_length (stack) >= 1 || strcmp (stack->next->data, "node") != 0)) → if (stack->next != NULL && strcmp (stack->next->data, "node") != 0) (fixes the NULL-deref/short-circuit bug in the D-Bus introspection parser).)

• Buddy Build 
• patch applied during the build (check rpm.log)
• patch include an upstream reference
• PR has security tag

[azurelinux-security]

🔒 CVE Patch Review: CVE-2026-58010, CVE-2026-58011, CVE-2026-58012, CVE-2026-58013, CVE-2026-58014, CVE-2026-58015, CVE-2026-58016

PR #17880 — [AutoPR- Security] Patch glib for CVE-2026-58016, CVE-2026-58015, CVE-2026-58014, CVE-2026-58013, CVE-2026-58012, CVE-2026-58011, CVE-2026-58010 [HIGH]
Package: glib | Branch: fasttrack/3.0

---

Spec File Validation

Check	Status	Detail
Release bump	✅	Release bumped 8 → 9
Patch entry	✅	Patch entries added: ['CVE-2026-58010.patch', 'CVE-2026-58011.patch', 'CVE-2026-58012.patch', 'CVE-2026-58013.patch', 'CVE-2026-58014.patch', 'CVE-2026-58015.patch', 'CVE-2026-58016.patch'] (covers ['CVE-2026-58010', 'CVE-2026-58011', 'CVE-2026-58012', 'CVE-2026-58013', 'CVE-2026-58014', 'CVE-2026-58015', 'CVE-2026-58016'])
Patch application	✅	%autosetup/%autopatch found in full spec — patches applied automatically
Changelog	✅	Changelog entry looks good
Signatures	✅	No source tarball changes — signatures N/A
Manifests	✅	Not a toolchain PR — manifests N/A

---

Build Verification

• Build status: ✅ PASSED
• Artifact downloaded: ✅
• CVE applied during build: ❌

🤖 AI Build Log Analysis

• Risk: medium
• Summary: The provided log is too short to show an actual RPM build, patch application, compilation, or test execution. It only shows successful download and checksum verification of a toolchain RPM (glibc) and GPG key setup. Based on this log alone, the build outcome for glib cannot be determined and there is no evidence that the CVE patch set was applied.
• AI-detected warnings:
  • The log does not include any rpmbuild phases such as %prep, patch application, compilation, installation, or test results.
  • There is no patch/hunk output confirming application of fixes for CVE-2026-58010 through CVE-2026-58016.
  • Only toolchain RPM download and verification are shown, so the actual package build status is unknown.

---

🧪 Test Log Analysis

No test log found (package may not have a %check section).

---

Patch Analysis

• Match type: backport
• Risk assessment: low
• Summary: The PR patch is functionally equivalent to the upstream security fix: it applies the same one-line bounds check correction in gvs_tuple_is_normal() (offset > value.size to offset >= value.size) and includes the same regression test scenario registering tuple-offsets6. The only substantive difference from upstream is an added #include <stdint.h> in the test file plus packaging metadata/signoff changes and shifted line numbers due to the older Azure Linux source tree. Those differences do not affect the security fix itself. | The PR patch is functionally equivalent to the upstream fix for CVE-2026-58011. It includes both upstream commits: the preparatory refactor introducing MIN_DAYS/MAX_DAYS and the actual security fix adding range validation in g_date_time_add_full(), plus the same regression tests. Differences are limited to patch-wrapper metadata, different blob indexes/line offsets due to the target tree version, and Azure-specific packaging annotations; these do not change behavior. | The PR patch is functionally equivalent to the authoritative upstream fix, but it is packaged as a downstream backport in SPECS/glib/CVE-2026-58012.patch rather than being the raw upstream commit. The substantive code changes in glib/gregex.c and the added regression test in glib/tests/regex.c match upstream logic, including the split between UTF-8 and raw-byte case conversion paths for G_REGEX_RAW and the new test coverage for truncated UTF-8 byte sequences in raw mode. Differences are limited to patch metadata, file indices, line offsets, and downstream packaging headers/sign-offs. | The PR patch is functionally equivalent to the upstream fix for CVE-2026-58013. It carries the same core security change in glib/giochannel.c, adding a bounds check before memcmp() to prevent reading past the end of the buffer when a long line terminator is configured, and it also includes the upstream regression test. The only substantive difference versus upstream is an added #include <stdint.h> in the test file, plus packaging metadata/sign-off changes and shifted context lines due to the target tree differing from upstream. | The PR patch is functionally equivalent to the upstream fix and appears to be a clean backport onto an older GLib source tree. The core security hunk in g_key_file_get_locale_string_list() is identical in behavior, adding the required len > 0 guard before accessing value[len - 1]. The associated upstream test additions are also present, including the new empty-locale-string unit test and the fuzzing coverage expansion. Differences are limited to patch packaging metadata, shortened blob IDs, and shifted line numbers/context due to the older downstream code base. | The PR patch is functionally equivalent to the upstream fix set for CVE-2026-58015: it includes the SHA-1 cookie context validation, stricter cookie ID validation, the private client reject-reason vfunc needed by the new test, and the added regression test and meson wiring. The only substantive delta versus upstream is that the downstream patch squashes upstream’s four commits into one vendor patch and adds packaging metadata/commentary, plus one extra header include (<stdint.h>) in gdbusauthmechanism.h. Those differences do not appear to alter the security behavior. | The PR patch is functionally equivalent to the upstream 4-patch series for this CVE, packaged as a single downstream backport patch. It includes the core security-relevant parser fix for invalid nested elements, the defensive assertions on pointer-array dereferences, the new invalid-input unit tests, the test path renames, and the new fuzz target. The only differences are expected backport/context differences against an older GLib tree (for example, the fuzzing/meson.build surrounding entries differ), plus packaging metadata and consolidation into one patch file.

Detailed analysis

Core fix equivalence: yes. The authoritative upstream patch changes the conditional inside gvs_tuple_is_normal() from if (offset > value.size || value.data[offset] != '\0') to if (offset >= value.size || value.data[offset] != '\0'), preventing a one-byte out-of-bounds read when offset == value.size. The PR patch makes this exact same code change in the same function, with only line-number/context differences consistent with a backport to a different source revision. Test coverage: the upstream patch adds test_normal_checking_tuple_offsets6() and registers it in main(). The PR includes the same test logic, same malformed tuple type, same 1-byte heap-backed input, same assertions on g_variant_is_normal_form(), g_variant_get_normal_form(), and equality against the parsed expected variant, and also registers the test under the same path. Differences vs upstream: (1) the PR adds #include <stdint.h> to support uint8_t in the test file; this is harmless and likely needed by the older branch if that type was not already available through transitive includes; (2) patch metadata differs, including Azure signoff and upstream-reference; (3) file indices and hunk offsets differ because this is being carried as a downstream spec patch against an older tree. No upstream hunks appear to be omitted. This is effectively an upstream backport with a minor test-only portability/header addition. Risk is low: the fix narrows a boundary check exactly as upstream intended, and the added regression test reduces the chance of future reintroduction. The only regression consideration is the extra include in the test file, which is standard and non-invasive.

The core security fix hunk is present and matches upstream semantically: after computing new->days and new->usec in g_date_time_add_full(), the PR adds the same validation that rejects results outside the valid Proleptic Gregorian range (0001-01-01 through 9999-12-31) by clearing and unrefing the newly created GDateTime, causing NULL to be returned. This directly addresses the upstream issue of producing a non-NULL invalid GDateTime. The preparatory upstream commit is also included, defining MIN_DAYS and MAX_DAYS and replacing literal bounds checks in g_date_time_from_instant() and g_date_time_deal_with_date_change(); this is functionally identical to upstream and supports the later validation hunk cleanly. The regression tests added to glib/tests/gdatetime.c are also the same in substance, including the TEST_ADD_FULL_ERROR macro and the five out-of-range test cases. Differences versus upstream are non-functional backport/packaging differences: the patch is stored as SPECS/glib/CVE-2026-58011.patch, commit IDs differ, line numbers and source blob hashes differ because it is applied to an older/downstream tree, the patch trailer shows Git version instead of GitLab, and Azure-specific metadata was added (Signed-off-by and Upstream-reference). No upstream hunks appear to be omitted. Because all functional changes and tests are present, and the context drift is typical for a backport with no semantic deviation, the risk of incompleteness is low. Regression risk is also low because the change only adds explicit range rejection for results that upstream already considers invalid elsewhere.

Core security fix equivalence: yes. The upstream vulnerability fix changes replacement interpolation so that case-conversion in G_REGEX_RAW mode operates on bytes via g_ascii_tolower()/g_ascii_toupper() instead of decoding input as UTF-8 with g_utf8_get_char(). The PR contains the same structural changes: replacing the old CHANGE_CASE macro with UTF8_CHANGE_CASE plus RAW_CHANGE_CASE; extending string_append() with a text_is_raw parameter; adding separate raw and UTF-8 handling for both single-character and whole-string case changes; computing is_raw in interpolate_replacement() from match_info->regex->orig_compile_opts & G_REGEX_RAW; and passing that flag through all relevant string_append() call sites while keeping character literal handling on the UTF-8 path. Test equivalence: yes. The PR adds the same test_replace_raw_change_case() regression test and registers it in main(), exercising both \U\0 and \u\0 substitutions against truncated multibyte sequences in raw mode. Differences vs upstream: only downstream packaging/metadata changes are present, such as the patch file wrapper path, Azure sign-off, upstream-reference tag, different blob IDs, and shifted line numbers caused by the older source base. No upstream code hunk appears omitted or semantically altered. Because this is a backport, the changed context line numbers and index hashes are expected and appear safe; the implementation intent and control flow remain aligned with upstream. Regression/incompleteness risk is low: the patch is narrowly scoped, preserves non-RAW behavior, and includes the same upstream regression test coverage.

The core security-fix hunk matches upstream semantically: upstream changes if (memcmp (channel->line_term, nextchar, line_term_len) == 0) to if ((size_t) (lastchar - nextchar) >= line_term_len && memcmp (channel->line_term, nextchar, line_term_len) == 0). The PR applies the exact same logic in glib/giochannel.c, so the out-of-bounds memcmp() condition is addressed in the same way. This is the critical CVE fix and it is preserved without alteration. The associated unit test test_read_line_long_terminator() is also included and is effectively identical to upstream in behavior, validating the long-terminator case against a 2047-byte input and asserting correct read results. Compared with upstream, the PR additionally adds #include <stdint.h> to glib/tests/io-channel.c; this is a harmless compatibility/include fix for use of uint8_t and does not change runtime behavior of the library or test intent. Other differences are packaging-layer only: the patch is added as SPECS/glib/CVE-2026-58013.patch, includes Azure-specific sign-off and an upstream reference, and has different blob indices and line offsets because it is being applied to a downstream tree with slightly different source context. There are no missing upstream hunks: both the code fix and the test addition are present. The context-line shifts appear safe and consistent with a normal downstream backport/application onto a slightly different source revision. Regression risk is low because the code change only narrows when memcmp() is invoked, preventing over-read without altering successful terminator detection when enough buffer remains.

1. Core fix equivalence: Upstream changes glib/gkeyfile.c from if (value[len - 1] == key_file->list_separator) to if (len > 0 && value[len - 1] == key_file->list_separator). The PR applies the same logic, so the one-byte under-read on empty values is addressed in the same way. This is the critical security fix and it is present without alteration.

2. Test and fuzzing coverage: The upstream patch adds extra calls in fuzzing/fuzz_key.c to exercise g_key_file_get_comment() and g_key_file_get_locale_string_list(), and the PR includes those exact additions. Upstream also adds test_locale_string_empty() in glib/tests/keyfile.c and registers it in main(); the PR includes both of these hunks as well. The test content matches upstream semantically.

3. Differences versus upstream: The PR wraps the upstream content in a distro patch file under SPECS/glib/CVE-2026-58014.patch, adds Azure Linux sign-off and an upstream-reference trailer, and uses different file indexes and line offsets. The gkeyfile.c and keyfile.c hunk locations differ from upstream (for example 2421 vs 2462, 850/1961 vs 889/2033), which is expected for a backport to an older source revision. These are context differences, not logic changes.

4. Missing hunks: None. All substantive upstream hunks are represented in the PR patch: fuzzing/fuzz_key.c, glib/gkeyfile.c, and glib/tests/keyfile.c.

5. Backport safety and regression risk: The backport looks straightforward. The only functional code change is a defensive bounds check before reading the final byte of a string, which is low risk and tightly scoped. The added tests increase confidence that empty values no longer crash and that fuzzing covers the relevant parser paths. I do not see any indication that the fix is incomplete or that the backport changed semantics beyond what upstream intended.

---

Core security fix equivalence: yes. In gio/gdbusauthmechanismsha1.c, the PR adds validate_cookie_context() with the same logic as upstream: reject non-ASCII and the forbidden characters /, \\, space, newline, carriage return, tab, and .; require non-empty context; and reject malformed values before looking up the cookie. It also incorporates upstream’s cookie-ID hardening by changing the type from guint to int64_t, checking for empty/non-numeric input, negative values, and values above UINT32_MAX, then casting only after validation when calling keyring_lookup_entry(). These are the critical CVE-relevant hunks and they match upstream behavior. Supporting/test infrastructure: the PR also includes the private API additions from upstream commit 3 (client_get_reject_reason vfunc and wrapper) and the corresponding class wiring changes in gdbusauthmechanismanon.c, gdbusauthmechanismexternal.c, and gdbusauthmechanismsha1.c, as well as the new gio/tests/gdbus-auth-mechanism-sha1.c regression test and gio/tests/meson.build entry from upstream commit 4. Differences vs upstream: the patch is packaged as a single downstream patch file instead of four separate commits; it adds Upstream Patch Reference metadata; and it adds #include <stdint.h> to gio/gdbusauthmechanism.h, which upstream did not need. That extra include is benign and likely compensates for the older Azure Linux tree using int64_t without another guaranteed definition in scope. There are also expected context/index differences from backporting to an older source tree (index hashes, line numbers, and nearby meson offsets). Nothing important appears omitted. Because all upstream hunks are present and the deviations are non-functional packaging/backport adjustments, the patch should be considered equivalent with minor differences rather than a materially different implementation.

Reviewing the actual code changes rather than patch metadata, the PR carries all substantive upstream hunks. In gio/gdbusintrospection.c, all eight assertion additions are present: parse_data_get_annotation(), parse_data_get_arg(), parse_data_get_out_arg(), parse_data_get_method(), parse_data_get_signal(), parse_data_get_property(), parse_data_get_interface(), and parse_data_get_node() each gain the same g_assert(len > 0) before dereferencing pdata[len - 1]. The security-relevant logic fix in parser_start_element() is also identical in effect to upstream: the broken condition !(g_slist_length (stack) >= 1 || strcmp (stack->next->data, "node") != 0) is replaced with stack->next != NULL && strcmp (stack->next->data, "node") != 0, which correctly permits top-level or immediate child-of- nesting and rejects other placements. In gio/tests/gdbus-introspection.c, the PR includes the same test path normalization and the same new test_invalid() coverage with the same XML vectors and expected errors, and it registers the new /gdbus/introspection/invalid test. In fuzzing/, the PR adds the same new fuzz_dbus_node_info_new_for_xml.c source and wires it into meson. The only notable differences from upstream are non-functional: the PR is delivered as a single Azure Linux packaging patch under SPECS/glib/CVE-2026-58016.patch, carries downstream commit metadata, and applies against an older source base, which explains changed file indices and a different neighboring fuzz_targets list in meson.build. Those context differences do not alter the fix. Because no upstream functional hunks are omitted and the backport appears faithful, the residual risk is low; the main caveat is the usual backport risk that line offsets/context differ, but the applied logic matches upstream precisely.

---

Verdict

✅ APPROVED — All checks passed. Ready to merge.