Re: [OE-core] [scarthgap][PATCH v2 2/7] libpcap: Fix CVE-2026-31912

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

On Mon Sep 21, 2026 at 10:17 PM CEST, Jaipaul Cheernam via lists.openembedded.org wrote:
> NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-31912
> Upstream-commit: https://github.com/the-tcpdump-group/libpcap/commit/d3f358d3cffbe1ecb94d5284b3e81f052a0adcb9
>
> Signed-off-by: Jaipaul Cheernam <jaipaul.cheernam@est.tech>
> ---
>  .../libpcap/libpcap/02-CVE-2026-31912.patch   | 525 ++++++++++++++++++
>  .../libpcap/libpcap_1.10.4.bb                 |   1 +
>  2 files changed, 526 insertions(+)
>  create mode 100644 meta/recipes-connectivity/libpcap/libpcap/02-CVE-2026-31912.patch
>
> diff --git a/meta/recipes-connectivity/libpcap/libpcap/02-CVE-2026-31912.patch b/meta/recipes-connectivity/libpcap/libpcap/02-CVE-2026-31912.patch
> new file mode 100644
> index 0000000000..d9fda1ec48
> --- /dev/null
> +++ b/meta/recipes-connectivity/libpcap/libpcap/02-CVE-2026-31912.patch
> @@ -0,0 +1,525 @@
> +From d3f358d3cffbe1ecb94d5284b3e81f052a0adcb9 Mon Sep 17 00:00:00 2001
> +From: Denis Ovsienko <denis@ovsienko.info>
> +Date: Thu, 30 Jul 2026 13:33:55 +0100
> +Subject: [PATCH] CVE-2026-31912: Mind the program bounds in pcap_offline_filter().
> +
> +The current revision of pcapint_filter_with_aux_data() does not know the
> +number of instructions in the filter program, it assumes the program
> +counter always remains within the bounds of the provided filter program
> +and always reaches a return instruction.  This holds for programs that
> +have been generated or validated by libpcap.
> +
> +However, this does not necessarily hold for programs that come from an
> +external source via pcap_offline_filter() or [deprecated] bpf_filter()
> +and have not been explicitly validated.  If the interpreter executes
> +such a program and advances the program counter beyond the last
> +instruction, it will be interpreting memory space after the filter
> +program as BPF instructions, which in the current implementation will
> +eventually cause either abort() (another commit addresses that) or
> +SIGSEGV.
> +
> +To fix the latter problem, in pcapint_filter_with_aux_data() add a
> +parameter for the number of instructions in the program and reject the
> +packet as soon as (or just before) the program counter goes out of
> +bounds.  Update all incoming code paths to specify the length; also in
> +pcap_offline_filter(3PCAP) make it clear the function now requires the
> +'bf_len' member to be set correctly and uses it.
> +
> +(backported from commit d1209988c74dd9330659898d3b676ee6bbe1c551)
> +
> +(cherry picked from commit d3f358d3cffbe1ecb94d5284b3e81f052a0adcb9)
> +

Hello,

> +Notes on backporting to 1.10.4:
> + - Adapted to the 1.10.4 pcap_filter*() names (renamed to pcapint_*()
> +   after 1.10.4).
> + - The upstream CHANGES/changelog hunk is not backported.
> 
> +Upstream-Status: Backport [https://github.com/the-tcpdump-group/libpcap/commit/d3f358d3cffbe1ecb94d5284b3e81f052a0adcb9]

This also drop a pcap-haiku.c hunk. Should'nt we patch pcap-haiku.cpp?
This was before it was rewriten in C.

I may have missed it for the wrynose patch but if a patch is needed, could
you send a fix for wrynose as well?

Also, please check that the backport notes are exhaustive (e.g. there is
also a missing man patch for which a note would have been appreciated)

> +CVE: CVE-2026-31912
> +Signed-off-by: Jaipaul Cheernam <jaipaul.cheernam@est.tech>

I'll hold the series for now. Can you check the above issues for the
whole series?

Regards,
-- 
Yoann Congal
Smile ECS