On Tue Sep 15, 2026 at 9:16 PM CEST, Jaipaul Cheernam via 
lists.openembedded.org wrote:
> NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-18313
> Upstream-commit: 
> https://github.com/the-tcpdump-group/libpcap/commit/f9775af1a0ec76db60c7213241e6b48f1be10ac7
> Signed-off-by: Jaipaul Cheernam <[email protected]>
> ---
>  .../libpcap/libpcap/06-CVE-2026-18313.patch   | 90 +++++++++++++++++++
>  .../libpcap/libpcap_1.10.6.bb                 |  1 +
>  2 files changed, 91 insertions(+)
>  create mode 100644 
> meta/recipes-connectivity/libpcap/libpcap/06-CVE-2026-18313.patch
>
> diff --git 
> a/meta/recipes-connectivity/libpcap/libpcap/06-CVE-2026-18313.patch 
> b/meta/recipes-connectivity/libpcap/libpcap/06-CVE-2026-18313.patch
> new file mode 100644
> index 0000000000..eae9aaa989
> --- /dev/null
> +++ b/meta/recipes-connectivity/libpcap/libpcap/06-CVE-2026-18313.patch
> @@ -0,0 +1,90 @@
> +From b039b8b66616852673c21ec5c7e0bad3190eae59 Mon Sep 17 00:00:00 2001
> +From: Denis Ovsienko <[email protected]>
> +Date: Sat, 1 Aug 2026 18:24:48 +0100
> +Subject: [PATCH] CVE-2026-18313: Fix a memory leak in rpcapd.
> +
> +This vulnerability was originally reported publicly, hence no credit is
> +given.
> +
> +daemon_unpackapplyfilter() can allocate a temporary buffer for up to
> +RPCAP_BPF_MAXINSNS (8192) BPF instructions (65536 bytes) per each
> +received RPCAP_MSG_UPDATEFILTER_REQ or RPCAP_MSG_STARTCAP_REQ message.
> +It never frees the memory, so repeated messages from a client will
> +eventually leak enough memory on the server to cause problems.  This
> +holds for all connections that pass the validation and some connections
> +that do not.
> +
> +48 bytes in 1 blocks are definitely lost in loss record 2 of 2
> +   at 0x4844818: malloc (vg_replace_malloc.c:446)
> +   by 0x111AAB: daemon_unpackapplyfilter (daemon.c:2372)
> +   by 0x113279: daemon_msg_startcap_req.constprop.0 (daemon.c:2139)
> +   by 0x114808: daemon_serviceloop (daemon.c:901)
> +   by 0x115BC7: accept_connection (rpcapd.c:1321)
> +   by 0x115BC7: accept_connections (rpcapd.c:1118)
> +   by 0x115BC7: main_startup (rpcapd.c:709)
> +   by 0x1112BD: main (rpcapd.c:567)
> +
> +To fix this, after a successful malloc() return exactly once, after the
> +free() call.
> +
> +(backported from commit 26a1c75702b105ac8788014f35f1b5c57fa6043b)
> +
> +(cherry picked from commit f9775af1a0ec76db60c7213241e6b48f1be10ac7)
> +
> +Upstream-Status: Backport 
> [https://github.com/the-tcpdump-group/libpcap/commit/f9775af1a0ec76db60c7213241e6b48f1be10ac7]
> +CVE: CVE-2026-18313
> +
> +Notes on backporting to 1.10.6:
> + - The upstream commit was made after the "bogus instructions" -> "invalid
> +   instructions" message change (commit 836d0fd0), which is not backported.
> +   The 1.10.6 wording ("The filter contains bogus instructions") is therefore
> +   kept; only the memory-leak fix (goto free_and_return_status / free()) is
> +   applied.
> + - The upstream CHANGES/changelog hunk is not backported.
> +
> +Signed-off-by: Jaipaul Cheernam <[email protected]>
> +---
> +diff --git a/rpcapd/daemon.c b/rpcapd/daemon.c
> +index 87274665..b720cc45 100644
> +--- a/rpcapd/daemon.c
> ++++ b/rpcapd/daemon.c
> +@@ -2403,16 +2397,19 @@ daemon_unpackapplyfilter(PCAP_SOCKET sockctrl, SSL 
> *ctrl_ssl, struct session *se
> +     if (bpf_validate(bf_prog.bf_insns, bf_prog.bf_len) == 0)
> +     {
> +             snprintf(errmsgbuf, PCAP_ERRBUF_SIZE, "The filter contains 
> bogus instructions");
> +-            return -2;
> ++            status = -2;
> ++            goto free_and_return_status;

Hi Jaipaul,

There is no need to detail changes happening in the context of your
patch (unless relevant). In this case "Notes on backporting to 1.10.6:"
on "bogus instructions" is confusing since this is not something you
changed during backporting (and is obvious enough).
The note on "CHANGES/changelog" is appreciated but obvious enough so it
could be omitted as well.

I think you're using a LLM to generate those. Please teach it to be more
precise in the change it describe. Try feeding it the interdiff output,
I think that will help.

No need to send v3s for this, this is more a general improvement kind of
thing.

Thanks!
-- 
Yoann Congal
Smile ECS

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#246063): 
https://lists.openembedded.org/g/openembedded-core/message/246063
Mute This Topic: https://lists.openembedded.org/mt/121267057/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to