Patch kernel to fix CVE-2026-43456

[omkhar]

Merge Checklist

• 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
• LICENSE-MAP files are up-to-date
• 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

Backport the upstream fix for CVE-2026-43456, a type confusion in the bonding driver's bond_setup_by_slave().

When a non-Ethernet slave (e.g. a GRE tunnel) is enslaved to a bond, the bond blindly copied the slave's header_ops onto itself:

bond_dev->header_ops = slave_dev->header_ops;

A later dev_hard_header() on the bond then invokes e.g. ipgre_header() with the bond device, so netdev_priv() returns the bond's struct bonding reinterpreted as the slave protocol's private type (e.g. struct ip_tunnel) — a type confusion that leads to garbage reads / controlled corruption and local privilege escalation. A public exploit exists (Google kernelCTF, reliable LPE; trigger only needs CAP_NET_ADMIN, obtainable via unprivileged user namespaces).

The upstream fix introduces bond_header_ops wrapper functions that delegate to the active slave's header_ops using the slave's own device, so netdev_priv() always sees the correct type.

Upstream commit: torvalds/linux 950803f7254721c1c15858fbbfae3deaaeeecb11

• Author: Jiayuan Chen <jiayuan.chen@shopee.com>
• Fixes: 1284cd3a2b74 ("bonding: two small fixes for IPoIB support") (2007)
• Reviewed-by: Eric Dumazet <edumazet@google.com>
• Signed-off-by: Paolo Abeni <pabeni@redhat.com>

The fix is a single file (drivers/net/bonding/bond_main.c) and applies cleanly to the 6.6.143.1 (rolling-lts/mariner-3) source via %autosetup -p1.

Change Log

• Add CVE-2026-43456.patch (upstream 950803f7, attribution preserved) to the two from-source kernels: SPECS/kernel (Patch1) and SPECS/kernel-64k (Patch2).
• Bump Release 6.6.143.1-1 -> -2 across the entangled kernel spec set: kernel, kernel-64k, kernel-headers, kernel-signed, kernel-64k-signed, kernel-uki-signed.
• Update the kernel-headers NVR (-1 -> -2) in toolchain_{x86_64,aarch64}.txt and pkggen_core_{x86_64,aarch64}.txt.
• Fixes CVE-2026-43456.

Does this affect the toolchain?

YES — kernel-headers is a core/toolchain package, so its Release bump requires the toolchain_*.txt / pkggen_core_*.txt manifest update (included). No toolchain source changes.

Links to CVEs

• https://nvd.nist.gov/vuln/detail/CVE-2026-43456

Test Methodology

Validated against the exact 6.6.143.1 (rolling-lts/mariner-3) kernel source this spec consumes:

• Patch application: patch -p1 --dry-run of CVE-2026-43456.patch against the consumed bond_main.c returns RC=0; post-apply the raw header_ops copy is gone and the bond_header_ops/bond_header_create/bond_header_parse guard is present.
• Vulnerability reproduced (unpatched 6.6.143.1, self-built KASAN kernel, booted): an ipgre_header kprobe capturing the dev argument shows the bond device (bond1) being passed on 7/7 trigger sends — i.e. the type confusion path is reached (netdev_priv(bond1) = struct bonding handed to GRE code expecting struct ip_tunnel).
• Fix verified (patched 6.6.143.1, same method): the same trigger now shows bond_header_create(bond1) -> ipgre_header(gre1) on 12/12 sends, 0 bond1 — the wrapper routes to the slave's own device, eliminating the confusion.
• Regression: LTP net.ipv6_lib + net.multicast (the single-VM-tolerant drivers/net subsystem suites) — 0 new failures patched vs baseline (the 3 net.multicast fails are Azure-VNet-blocks-L2-multicast environmental, identical on both sides).

(The type confusion is an in-bounds wrong-type read, so it does not crash a naive PoC / KASAN — the kprobe dev-argument differential is the deterministic signal; a crash requires exploit-grade heap shaping, per the public kernelCTF exploit.)

Note to maintainers

This is intentionally an out-of-tree carry: 950803f7 is not yet in linux-6.6.y stable (it is already in 6.12.y and 6.18.y), so [AUTOPATCHER-kernel] cannot pull it yet. I recognise the kernel is normally serviced by auto-upgrade rather than hand-added CVE patches — I'm raising this manually only because there is a public, reliable LPE exploit against the currently-shipping 6.6.143.1, and I'd rather not leave that window open until 6.6.y catches up.

Happy to defer to your preference: keep this as a carry until AUTOPATCHER pulls the stable backport (and I'll close it then), or drop it if you'd rather wait. Also glad to route it through fasttrack/3.0 if that's the appropriate channel for an exigent kernel CVE — please advise.

There is a follow-up upstream commit b7405dcf7385 ("bonding: prevent potential infinite loop in bond_header_parse()", Fixes: 950803f7) that hardens the code this patch adds; it is a broader header_ops->parse ABI change (9 files) and addresses a separate, lower-severity CAP_NET_ADMIN-gated DoS, so I've kept it out of this PR and can raise it separately if you'd like.

[omkhar]

Flagging severity + a handling question for maintainers:

Severity / exigency: CVE-2026-43456 has a public, reliable local-privilege-escalation exploit (Google kernelCTF). The trigger only needs CAP_NET_ADMIN, which an unprivileged local user can obtain via user namespaces — so it's an unprivileged LPE against the currently-shipping 6.6.143.1. The fix is not yet in linux-6.6.y stable (it is in 6.12.y and 6.18.y), so [AUTOPATCHER-kernel] can't pull it yet.

Question: I know the kernel is normally serviced by auto-upgrade rather than hand-added CVE patches. How would you prefer to handle this one?

1. Accept this as an out-of-tree carry now (I'll close it once AUTOPATCHER pulls the 6.6.y backport), or
2. Wait for the stable backport + AUTOPATCHER (I'll close this), or
3. Route it through fasttrack/3.0 if that's the right channel for an exigent kernel CVE.

Happy to follow your call and to adjust the patch/spec as needed. Full validation (kprobe dev-arg differential 7/7 vulnerable → 12/12 fixed, LTP net.* 0 new failures on 6.6.143.1) is in the Test Methodology section.

[omkhar]

One routing question for maintainers: is this eligible for fasttrack/3.0?

Given the public kernelCTF LPE exploit and that the fix isn't yet in linux-6.6.y stable (so AUTOPATCHER-kernel can't pull it yet), expediting seems reasonable — but I don't want to presume the channel, so I've opened this on 3.0-dev rather than targeting fasttrack/3.0 directly.

If you'd like it fast-tracked, I'm happy to retarget the PR to fasttrack/3.0 (or you can re-route it) — just say the word. Otherwise I'm glad to leave it here on 3.0-dev. CI is green; the patch + entangled spec/manifest set are validated.