Re: [OE-core] [wrynose][PATCH 1/7] libpcap: Fix CVE-2026-0799

["Yoann Congal" <yoann.congal@smile.fr>]

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 <jaipaul.cheernam@est.tech>
> ---
>  .../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 <denis@ovsienko.info>
> +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 <jaipaul.cheernam@est.tech>
> +---
> + 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