Patch bison for CVE-2026-56389, CVE-2026-56390[MEDIUM]

[v-swapsahu]

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

Patch bison for CVE-2026-56389, CVE-2026-56390

Change Log

Bison:

• SPECS/bison/CVE-2026-56389.patch
• SPECS/bison/CVE-2026-56390.patch
• SPECS/bison/bison.spec
• toolkit/resources/manifests/package/pkggen_core_aarch64.txt
• toolkit/resources/manifests/package/pkggen_core_x86_64.txt
• toolkit/resources/manifests/package/toolchain_aarch64.txt
• toolkit/resources/manifests/package/toolchain_x86_64.txt

Frr:

• SPECS/frr/0006-fix-bison-output-file-directives.patch
• SPECS/frr/frr.spec

Does this affect the toolchain?

YES

Associated issues

• #xxxx

Links to CVEs

• https://nvd.nist.gov/vuln/detail/cve-2026-56389
• https://nvd.nist.gov/vuln/detail/cve-2026-56390

Test Methodology

Patch Application:

Bison:

Frr:

[azure-pipelines]

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

[v-swapsahu]

Patch analysis

CVE-2026-56389:
The AI-generated patch matches the upstream fix exactly.

print_html() no longer reads the xsltproc binary path from the attacker-controllable %define tool.xsltproc grammar directive; it is now hardcoded to "xsltproc", resolved via PATH.

CVE-2026-56390:
Backported: Yes
The patch aligns with the upstream fix, with a minor modification.

It adds valid_output_file_name() and applies it to both the %header and %output directives in src/parse-gram.y. This functionally matches the security-relevant part of the upstream commit.

The Bison CVE hardening in #18260 was reverted in #18531 because it broke frr's %build.

Why frr failed:

The FRR build failure is caused by the Bison hardening changes introduced in CVE-2026-56390 ("tighten up output file names").

The patch adds the following validation:

static bool
valid_output_file_name (char const *file)
{
  return !strchr (file, '/');
}

As a result, Bison now rejects any %output, %header, or %defines directive whose value contains a path separator (/).

FRR's grammar contains:

%defines "lib/command_parse.h"
%output  "lib/command_parse.c"

Both directives are therefore rejected with:

error: invalid %header file name ignored
error: invalid %output file name ignored

During the build, Azure Linux runs autoreconf -ivf followed by configure, regenerating the build system from the .am files. FRR's lib/subdir.am overrides Automake's normal ylwrap handling and uses a custom suffix rule:

.y.c:
       $(AM_V_YACC)$(am__skipyacc) $(YACCCOMPILE) $<

Since no -o option is passed, Bison relies entirely on the in-grammar directives to determine the output locations:

%defines "lib/command_parse.h"
%output  "lib/command_parse.c"

After the bison's CVE fix, those directives are rejected because they contain /, causing parser generation to fail.

How the Fix Works

For the target: lib/command_parse.c
the suffix rule expands to: bison -y -d ... -o lib/command_parse.c lib/command_parse.y

This preserves the original output layout while avoiding the hardened %output/%defines path validation.

Verification

Build logs after the change show Bison being invoked with the explicit output path:

Parser generation completes successfully, and the FRR build proceeds normally.

Pipelines - Run PR-18682+bison+frr+unknown has been triggered and it has passed.

Patch Application:

Bison:

Frr:

[azure-pipelines]

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