From: Jaipaul Cheernam <[email protected]> NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-6554 Upstream-commit: https://github.com/the-tcpdump-group/libpcap/commit/ff3c83475ac303c6b681c52ad0b6e14795a8e0ce Signed-off-by: Jaipaul Cheernam <[email protected]> Signed-off-by: Yoann Congal <[email protected]> --- .../libpcap/libpcap/05-CVE-2026-6554.patch | 94 +++++++++++++++++++ .../libpcap/libpcap_1.10.6.bb | 1 + 2 files changed, 95 insertions(+) create mode 100644 meta/recipes-connectivity/libpcap/libpcap/05-CVE-2026-6554.patch
diff --git a/meta/recipes-connectivity/libpcap/libpcap/05-CVE-2026-6554.patch b/meta/recipes-connectivity/libpcap/libpcap/05-CVE-2026-6554.patch new file mode 100644 index 00000000000..208225105d5 --- /dev/null +++ b/meta/recipes-connectivity/libpcap/libpcap/05-CVE-2026-6554.patch @@ -0,0 +1,94 @@ +From ee37e79521d28a04b09f5c37b835ae7955c15e75 Mon Sep 17 00:00:00 2001 +From: Denis Ovsienko <[email protected]> +Date: Thu, 30 Jul 2026 13:34:33 +0100 +Subject: [PATCH] CVE-2026-6554: Limit "ja L" looping in pcap_offline_filter(). + +This vulnerability has been discovered by Kaixuan LI. + +The current revision of pcapint_filter_with_aux_data() assumes that any +"ja L" instruction in a filter program does not jump to itself or to a +prior instruction that is guaranteed to reach the same "ja L" again. +This holds for programs that have been generated by libpcap. + +However, this does not necessarily hold for programs that come from an +external source via pcap_offline_filter() or [deprecated] bpf_filter(). +If the interpreter executes such a program, upon reaching such an +instruction it will begin looping infinitely. + +To mitigate this problem, in pcapint_filter_with_aux_data() enforce a +hard-coded limit on the number of backward jumps per packet. Ibid., and +in pcapint_validate_filter() as well, reject the only immediately +detectable case of an infinite loop. + +(backported from commit 63c005c25aeabf1404968add49fc885da3e127e0) + +(cherry picked from commit ff3c83475ac303c6b681c52ad0b6e14795a8e0ce) + +Upstream-Status: Backport [https://github.com/the-tcpdump-group/libpcap/commit/ff3c83475ac303c6b681c52ad0b6e14795a8e0ce] +CVE: CVE-2026-6554 + +Notes on backporting to 1.10.6: + - The stray BPF_S_ANC_* enum removed upstream in 1.10.7 (commit ff47ba55) is + still present in 1.10.6, so the new MAX_BACKWARD_JUMPS define is added + alongside it instead of replacing it. + - The upstream CHANGES/changelog hunk is not backported. + +Signed-off-by: Jaipaul Cheernam <[email protected]> +--- +diff --git a/bpf_filter.c b/bpf_filter.c +index 0178aae5..bc6d149f 100644 +--- a/bpf_filter.c ++++ b/bpf_filter.c +@@ -70,6 +70,8 @@ enum { + BPF_S_ANC_VLAN_TAG_PRESENT, + }; + ++#define MAX_BACKWARD_JUMPS 64U ++ + /* + * Kernel BPF implementations tend to define BPF_MAXINSNS to 512 or 4096, the + * userland interpreter in libpcap is meant to support much longer filter +@@ -144,6 +146,7 @@ pcapint_filter_with_aux_data(const struct bpf_insn *pc, const u_int proglen, + A = 0; + X = 0; + const struct bpf_insn *pc0 = pc; ++ unsigned backward_jumps = 0; + --pc; + for (;;) { + ++pc; +@@ -318,6 +321,17 @@ DIAG_ON_DEFAULT_ONLY_SWITCH + */ + if ((bpf_u_int32)(pc - pc0) + 1 + pc->k >= proglen) + return 0; ++ /* ++ * Terminate the program if this is a non-forward jump ++ * and is: ++ * - a guaranteed infinite loop because it jumps to ++ * itself (exactly the same as in the validator), or ++ * - a backward jump after many enough backward jumps ++ * already made for this packet. ++ */ ++ if ((bpf_int32)pc->k < 0 && ((bpf_int32)pc->k == -1 || ++ backward_jumps++ >= MAX_BACKWARD_JUMPS)) ++ return 0; + /* + * XXX - we currently implement "ip6 protochain" + * with backward jumps, so sign-extend pc->k. +@@ -605,6 +619,17 @@ pcapint_validate_filter(const struct bpf_insn *f, int len) + */ + if (from + p->k >= (u_int)len) + return 0; ++ /* ++ * The only type of infinite loop that can be ++ * detected in this function is a "ja L" that ++ * jumps to itself. For this only k == -1 ++ * needs to be tested because the check above ++ * has already rejected all other values that ++ * would wrap the pointer equivalently on ++ * 32-bit architectures. ++ */ ++ if ((bpf_int32)p->k == -1) ++ return 0; + break; + case BPF_JEQ: + case BPF_JGT: diff --git a/meta/recipes-connectivity/libpcap/libpcap_1.10.6.bb b/meta/recipes-connectivity/libpcap/libpcap_1.10.6.bb index 258a15f5bac..6ca75117e17 100644 --- a/meta/recipes-connectivity/libpcap/libpcap_1.10.6.bb +++ b/meta/recipes-connectivity/libpcap/libpcap_1.10.6.bb @@ -16,6 +16,7 @@ SRC_URI = "https://www.tcpdump.org/release/${BP}.tar.xz \ file://02-CVE-2026-31912.patch \ file://03-CVE-2026-31911.patch \ file://04-CVE-2026-6244.patch \ + file://05-CVE-2026-6554.patch \ " SRC_URI[sha256sum] = "ec97d1206bdd19cb6bdd043eaa9f0037aa732262ec68e070fd7c7b5f834d5dfc"
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#246161): https://lists.openembedded.org/g/openembedded-core/message/246161 Mute This Topic: https://lists.openembedded.org/mt/121305650/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
