On Thu Sep 10, 2026 at 7:11 AM CEST, Jaipaul Cheernam via lists.openembedded.org wrote: > NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-0799 > Upstream-commit: > https://github.com/the-tcpdump-group/libpcap/commit/48e8960a7108e9e828f9d7bdc7e97bdab841aec7 > Signed-off-by: Jaipaul Cheernam <[email protected]> > --- > .../libpcap/libpcap/01-CVE-2026-0799.patch | 87 +++++++++++++++++++ > .../libpcap/libpcap_1.10.6.bb | 1 + > 2 files changed, 88 insertions(+) > create mode 100644 > meta/recipes-connectivity/libpcap/libpcap/01-CVE-2026-0799.patch > > diff --git a/meta/recipes-connectivity/libpcap/libpcap/01-CVE-2026-0799.patch > b/meta/recipes-connectivity/libpcap/libpcap/01-CVE-2026-0799.patch > new file mode 100644 > index 0000000000..58289d7e3b > --- /dev/null > +++ b/meta/recipes-connectivity/libpcap/libpcap/01-CVE-2026-0799.patch > @@ -0,0 +1,87 @@ > +From 3c55fdefa576c7a06feab86a9e4341be414de49b Mon Sep 17 00:00:00 2001 > +From: Denis Ovsienko <[email protected]> > +Date: Thu, 30 Jul 2026 13:33:41 +0100 > +Subject: [PATCH] CVE-2026-0799: Access M[] safely in the BPF interpreter. > + > +Include Security identified and reported this problem as a potential > +vulnerability in 2018 (case reference "I7"). Their work was sponsored > +by Mozilla under the Secure Open Source program. The vulnerability has > +been independently confirmed only recently. > + > +The current revision of pcapint_filter_with_aux_data() can, but does not > +check whether a scratch memory register index is valid in the "ld M[k]", > +"ldx M[k]", "st M[k]" and "stx M[k]" BPF instructions, and assumes this > +is always the case. This holds for programs that have been generated or > +validated by libpcap. > + > +However, this does not necessarily hold for programs that come via > +pcap_offline_filter() or [deprecated] bpf_filter() from an external > +source and have not been explicitly validated. If the interpreter > +executes such a program with an invalid index, it will read/write the > +process memory at arbitrary locations starting at the current stack > +frame. Depending on the address, the memory layout and the OS, this can > +result in stack buffer overflow, SIGSEGV, SIGBUS or other effects. To > +fix this, in the interpreter reject the packet if the index is invalid. > + > +(backported from commit 569f8fd3524192acbabf93c9cd704471bb38f84a) > + > +(cherry picked from commit 48e8960a7108e9e828f9d7bdc7e97bdab841aec7) > + > +Notes on backporting to 1.10.6: > + - The CHANGES entry added by this and the following CVE patches is a > + downstream addition to record the backported security fixes. It does not > + come from upstream: rather than import the upstream 1.10.7 changelog block > + (which also lists unrelated, non-backported changes) or claim a 1.10.7 > + release in a 1.10.6 tree, a dedicated "1.10.6 + backported CVE fixes" > + section is used, listing only the CVEs actually backported here. > + > +Upstream-Status: Backport > [https://github.com/the-tcpdump-group/libpcap/commit/48e8960a7108e9e828f9d7bdc7e97bdab841aec7] > +CVE: CVE-2026-0799 > +Signed-off-by: Jaipaul Cheernam <[email protected]> > +--- > + CHANGES | 4 ++++ > + bpf_filter.c | 8 ++++++++ > + 2 files changed, 12 insertions(+) > +diff --git a/CHANGES b/CHANGES > +index cb603f8..74f8ddf 100644 > +--- a/CHANGES > ++++ b/CHANGES > +@@ -1,3 +1,7 @@ > ++1.10.6 + backported CVE fixes / The Tcpdump Group > ++ Backported security fixes: > ++ CVE-2026-0799: Access M[] safely in the BPF interpreter. > ++
Hello, Instead of writing a new changelog, just drop the upstream change. I don't think we want to maintain the CHANGES files unless there is a good reason. Since we will have conflicts on this file, let's make an easy one and drop the upstream change systematically. What do you think? Regards, -- Yoann Congal Smile ECS
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#245839): https://lists.openembedded.org/g/openembedded-core/message/245839 Mute This Topic: https://lists.openembedded.org/mt/121176212/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
