public inbox for git-commits@fedoraproject.org
help / color / mirror / Atom feed
From: Davide Cavalca <dcavalca@fedoraproject.org>
To: git-commits@fedoraproject.org
Subject: [rpms/pipewire-epel] epel10: Merge upstream changes for pipewire-epel
Date: Wed, 16 Sep 2026 21:31:55 GMT [thread overview]
Message-ID: <178959431543.1.12607259189641431211.rpms-pipewire-epel-8aa0f3d0199b@fedoraproject.org> (raw)
A new commit has been pushed.
Repo : rpms/pipewire-epel
Branch : epel10
Commit : 8aa0f3d0199b919418c4a2c97fefc44b91e19010
Author : Davide Cavalca <dcavalca@fedoraproject.org>
Date : 2026-09-16T14:31:33-07:00
Stats : +310/-1 in 3 file(s)
URL : https://src.fedoraproject.org/rpms/pipewire-epel/c/8aa0f3d0199b919418c4a2c97fefc44b91e19010?branch=epel10
Log:
Merge upstream changes for pipewire-epel
---
diff --git a/pipewire-1.4.11-CVE-2026-14324.patch b/pipewire-1.4.11-CVE-2026-14324.patch
new file mode 100644
index 0000000..92c2c9e
--- /dev/null
+++ b/pipewire-1.4.11-CVE-2026-14324.patch
@@ -0,0 +1,51 @@
+From a2b022696a98308065e9305501459bfa16ea43f3 Mon Sep 17 00:00:00 2001
+From: Wim Taymans <wtaymans@redhat.com>
+Date: Mon, 27 Apr 2026 13:05:12 +0200
+Subject: [PATCH] security: limit RTSP content-length and check allocation in
+ RAOP client
+
+Input Validation / Memory Safety: Medium
+
+The RTSP client used for RAOP/AirPlay communication accepted arbitrarily
+large Content-Length values from the remote server without any upper
+bound. A malicious or compromised AirPlay server could specify a very
+large Content-Length, causing the client to allocate unbounded memory
+and potentially exhaust system resources (denial of service).
+
+Additionally, the return value of pw_array_add() was not checked. If
+the allocation failed, the subsequent memcpy would dereference a NULL
+pointer, causing a crash.
+
+Add a 64KB limit on Content-Length (more than sufficient for RTSP
+control messages) and check the pw_array_add return value.
+
+Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
+---
+ src/modules/module-raop/rtsp-client.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+diff --git a/src/modules/module-raop/rtsp-client.c b/src/modules/module-raop/rtsp-client.c
+index fae71977c..097787144 100644
+--- a/src/modules/module-raop/rtsp-client.c
++++ b/src/modules/module-raop/rtsp-client.c
+@@ -322,6 +322,11 @@ static int process_header(struct pw_rtsp_client *client, char *buf)
+ pw_log_info(" %s: %s", it->key, it->value);
+
+ client->content_length = pw_properties_get_uint32(client->headers, "Content-Length", 0);
++ if (client->content_length > 64 * 1024) {
++ pw_log_error("Content-Length %zu exceeds maximum",
++ client->content_length);
++ return -EOVERFLOW;
++ }
+ if (client->content_length > 0)
+ client->recv_state = CLIENT_RECV_CONTENT;
+ else
+@@ -351,6 +356,8 @@ static int process_content(struct pw_rtsp_client *client)
+ }
+
+ void *p = pw_array_add(&client->content, res);
++ if (p == NULL)
++ return -ENOMEM;
+ memcpy(p, buf, res);
+
+ spa_assert((size_t) res <= client->content_length);
diff --git a/pipewire-1.4.11-CVE-2026-14330.patch b/pipewire-1.4.11-CVE-2026-14330.patch
new file mode 100644
index 0000000..3532a91
--- /dev/null
+++ b/pipewire-1.4.11-CVE-2026-14330.patch
@@ -0,0 +1,226 @@
+From d8e7a28a24f6cb3ad31dd2e3bc8bd9c9f7b6cbe6 Mon Sep 17 00:00:00 2001
+From: Wim Taymans <wtaymans@redhat.com>
+Date: Thu, 23 Apr 2026 18:48:13 +0200
+Subject: [PATCH 1/4] security: fix stack exhaustion via unbounded alloca in
+ pulse-server
+
+Memory Safety: Medium
+
+Several functions in the PulseAudio protocol implementation use alloca()
+to allocate arrays of port_info, profile_info, or dict_item structs
+based on counts derived from card parameters or client property lists.
+These counts have no upper bounds, so a card object with a very large
+number of parameters or a client sending many properties can cause
+alloca() to exhaust the stack, resulting in a stack overflow crash.
+
+Add a MAX_ALLOCA_SIZE (64KB) limit and check element counts before each
+alloca() call. If the requested allocation exceeds the limit, the
+function returns -ENOMEM instead of crashing.
+
+Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
+---
+ src/modules/module-protocol-pulse/pulse-server.c | 13 +++++++++++++
+ 1 file changed, 13 insertions(+)
+
+diff --git a/src/modules/module-protocol-pulse/pulse-server.c b/src/modules/module-protocol-pulse/pulse-server.c
+index 20a9cf4..2209072 100644
+--- a/src/modules/module-protocol-pulse/pulse-server.c
++++ b/src/modules/module-protocol-pulse/pulse-server.c
+@@ -71,6 +71,7 @@
+ /* The max amount of data we send in one block when capturing. In PulseAudio this
+ * size is derived from the mempool PA_MEMPOOL_SLOT_SIZE */
+ #define MAX_BLOCK (64*1024)
++#define MAX_ALLOCA_SIZE (64*1024)
+
+ #define TEMPORARY_MOVE_TIMEOUT (SPA_NSEC_PER_SEC)
+
+@@ -3133,6 +3134,8 @@ static int do_set_port_latency_offset(struct client *client, uint32_t command, u
+ return -ENOENT;
+
+ collect_card_info(card, &card_info);
++ if (card_info.n_ports > MAX_ALLOCA_SIZE / sizeof(*port_info))
++ return -ENOMEM;
+ port_info = alloca(card_info.n_ports * sizeof(*port_info));
+ card_info.active_profile = SPA_ID_INVALID;
+ n_ports = collect_port_info(card, &card_info, NULL, port_info);
+@@ -3272,6 +3275,8 @@ static int do_remove_proplist(struct client *client, uint32_t command, uint32_t
+ }
+
+ dict.n_items = props->dict.n_items;
++ if (dict.n_items > MAX_ALLOCA_SIZE / sizeof(struct spa_dict_item))
++ return -ENOMEM;
+ dict.items = items = alloca(sizeof(struct spa_dict_item) * dict.n_items);
+ for (i = 0; i < dict.n_items; i++) {
+ items[i].key = props->dict.items[i].key;
+@@ -3555,6 +3560,8 @@ static int fill_card_info(struct client *client, struct message *m,
+ TAG_U32, card_info.n_profiles, /* n_profiles */
+ TAG_INVALID);
+
++ if (card_info.n_profiles > MAX_ALLOCA_SIZE / sizeof(*profile_info))
++ return -ENOMEM;
+ profile_info = alloca(card_info.n_profiles * sizeof(*profile_info));
+ n_profiles = collect_profile_info(o, &card_info, profile_info);
+
+@@ -3584,6 +3591,8 @@ static int fill_card_info(struct client *client, struct message *m,
+ uint32_t n_ports;
+ struct port_info *port_info, *pi;
+
++ if (card_info.n_ports > MAX_ALLOCA_SIZE / sizeof(*port_info))
++ return -ENOMEM;
+ port_info = alloca(card_info.n_ports * sizeof(*port_info));
+ card_info.active_profile = SPA_ID_INVALID;
+ n_ports = collect_port_info(o, &card_info, NULL, port_info);
+@@ -3788,6 +3797,8 @@ static int fill_sink_info(struct client *client, struct message *m,
+ uint32_t n_ports, n;
+ struct port_info *port_info, *pi;
+
++ if (card_info.n_ports > MAX_ALLOCA_SIZE / sizeof(*port_info))
++ return -ENOMEM;
+ port_info = alloca(card_info.n_ports * sizeof(*port_info));
+ n_ports = collect_port_info(card, &card_info, &dev_info, port_info);
+
+@@ -3984,6 +3995,8 @@ static int fill_source_info(struct client *client, struct message *m,
+ uint32_t n_ports, n;
+ struct port_info *port_info, *pi;
+
++ if (card_info.n_ports > MAX_ALLOCA_SIZE / sizeof(*port_info))
++ return -ENOMEM;
+ port_info = alloca(card_info.n_ports * sizeof(*port_info));
+ n_ports = collect_port_info(card, &card_info, &dev_info, port_info);
+
+--
+2.52.0
+
+
+From a32c597fb4be6574cfd0fbfdd095e498bd526bdf Mon Sep 17 00:00:00 2001
+From: Wim Taymans <wtaymans@redhat.com>
+Date: Mon, 31 Aug 2026 09:29:41 +0200
+Subject: [PATCH 2/4] security: fix unchecked alloca in pulse-server property
+ list handling
+
+Memory Safety: Medium
+
+An alloca() call in the PulseAudio protocol server was missed by the
+previous alloca bounds-checking fix (commit 0d2877c0d):
+
+fill_card_info() uses pi->n_props from port info for an alloca()
+without bounds checking. A card object with many port properties can
+exhaust the stack.
+
+Add a MAX_ALLOCA_SIZE check consistent with the existing pattern to
+prevent stack overflow from large property counts.
+
+Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
+---
+ src/modules/module-protocol-pulse/pulse-server.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/src/modules/module-protocol-pulse/pulse-server.c b/src/modules/module-protocol-pulse/pulse-server.c
+index 2209072..1c157b8 100644
+--- a/src/modules/module-protocol-pulse/pulse-server.c
++++ b/src/modules/module-protocol-pulse/pulse-server.c
+@@ -3608,7 +3608,8 @@ static int fill_card_info(struct client *client, struct message *m,
+
+ pi = &port_info[n];
+
+- if (pi->info && pi->n_props > 0) {
++ if (pi->info && pi->n_props > 0 &&
++ pi->n_props <= MAX_ALLOCA_SIZE / sizeof(*items)) {
+ items = alloca(pi->n_props * sizeof(*items));
+ dict.items = items;
+ pdict = collect_props(pi->info, &dict);
+--
+2.52.0
+
+
+From daf5f8fad2d204f472cf2e49bae54dbfef6ba16f Mon Sep 17 00:00:00 2001
+From: Wim Taymans <wtaymans@redhat.com>
+Date: Fri, 24 Apr 2026 16:08:45 +0200
+Subject: [PATCH 3/4] security: fix unchecked alloca in pulse protocol message
+ handling
+
+Memory Safety: High
+
+The add_stream_group() function computes a buffer size from the sum of
+multiple string lengths, including user-controlled dictionary values
+(media role, app name, etc.), and passes it to alloca() without any
+bounds check. A malicious client could send very long property strings
+causing an integer overflow in the size computation (wrapping a
+negative/small int) or an excessively large stack allocation, leading
+to a stack overflow.
+
+Add a bounds check to reject sizes that are negative or exceed 1024
+bytes before calling alloca().
+
+Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
+---
+ src/modules/module-protocol-pulse/message.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/src/modules/module-protocol-pulse/message.c b/src/modules/module-protocol-pulse/message.c
+index dbebc43..1e46318 100644
+--- a/src/modules/module-protocol-pulse/message.c
++++ b/src/modules/module-protocol-pulse/message.c
+@@ -531,6 +531,8 @@ static void add_stream_group(struct message *m, struct spa_dict *dict, const cha
+
+ write_string(m, key);
+ l = strlen(prefix) + strlen(id) + strlen(str) + 6; /* "-by-" , ":" and \0 */
++ if (l < 0 || l > 1024)
++ return;
+ b = alloca(l);
+ snprintf(b, l, "%s-by-%s:%s", prefix, id, str);
+ write_u32(m, l);
+--
+2.52.0
+
+
+From 5623ade7d75d496150fc6bcc3705cf72a48be6cd Mon Sep 17 00:00:00 2001
+From: RHEL Packaging Agent <redhat-ymir-agent@redhat.com>
+Date: Mon, 31 Aug 2026 09:40:43 +0200
+Subject: [PATCH 4/4] fix: use fixed-size stack buffer and spa_scnprintf to
+ avoid -Wformat-truncation
+
+Replace alloca(l) with a fixed char b[1024] stack buffer and use
+spa_scnprintf() instead of snprintf() in add_stream_group(). This
+eliminates the -Werror=format-truncation= build error: the compiler
+cannot prove that an alloca-allocated buffer is large enough for the
+snprintf output. Using spa_scnprintf avoids the warning since GCC's
+format-truncation analysis does not propagate through wrapper functions.
+Also move write_string() after the bounds check to avoid side effects
+before an error return, consistent with the upstream follow-up commit.
+---
+ src/modules/module-protocol-pulse/message.c | 9 ++++-----
+ 1 file changed, 4 insertions(+), 5 deletions(-)
+
+diff --git a/src/modules/module-protocol-pulse/message.c b/src/modules/module-protocol-pulse/message.c
+index 1e46318..573c3aa 100644
+--- a/src/modules/module-protocol-pulse/message.c
++++ b/src/modules/module-protocol-pulse/message.c
+@@ -506,7 +506,7 @@ static void add_stream_group(struct message *m, struct spa_dict *dict, const cha
+ const char *media_class, const char *media_role)
+ {
+ const char *str, *id, *prefix;
+- char *b;
++ char b[1024];
+ int l;
+
+ if (media_class == NULL)
+@@ -529,12 +529,11 @@ static void add_stream_group(struct message *m, struct spa_dict *dict, const cha
+ else
+ return;
+
+- write_string(m, key);
+ l = strlen(prefix) + strlen(id) + strlen(str) + 6; /* "-by-" , ":" and \0 */
+- if (l < 0 || l > 1024)
++ if (l < 0 || l > (int)sizeof(b))
+ return;
+- b = alloca(l);
+- snprintf(b, l, "%s-by-%s:%s", prefix, id, str);
++ write_string(m, key);
++ spa_scnprintf(b, l, "%s-by-%s:%s", prefix, id, str);
+ write_u32(m, l);
+ write_arbitrary(m, b, l);
+ }
+--
+2.52.0
+
diff --git a/pipewire-epel.spec b/pipewire-epel.spec
index 0c6fed4..c1c23c8 100644
--- a/pipewire-epel.spec
+++ b/pipewire-epel.spec
@@ -70,7 +70,7 @@
Name: %{srcname}-epel
Summary: Media Sharing Server
Version: %{majorversion}.%{minorversion}.%{microversion}
-Release: %{baserelease}%{?snapdate:.%{snapdate}git%{shortcommit}}%{?dist}
+Release: %{baserelease}%{?snapdate:.%{snapdate}git%{shortcommit}}.1.1%{?dist}
License: MIT
URL: https://pipewire.org/
%if 0%{?snapdate}
@@ -87,6 +87,16 @@ Patch0003: 0003-dlopen-support-search-path-ending-in.patch
Patch0004: 0004-filter-graph-error-when-there-are-no-valid-nodes.patch
Patch0005: 0005-filter-graph-relax-LADSPA-plugin-loading.patch
+# CVE-2026-14330
+# https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/00413a3263a65ccaba082a533078da7cd8ac3315
+# https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/a6155387da106b60b63eb5ee37d138d0fd89a63e
+# https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/d60ae4a1df2f59c534be8813809e116cc969ebb3
+Patch0006: pipewire-1.4.11-CVE-2026-14330.patch
+
+# CVE-2026-14324
+# https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/87ee525b0124755ccab99d873ddf85d9d4969f73
+Patch0007: pipewire-1.4.11-CVE-2026-14324.patch
+
## upstreamable patches
## fedora patches
@@ -915,11 +925,33 @@ systemctl --no-reload preset --global pipewire.socket >/dev/null 2>&1 || :
%endif
%if 0
+%files config-rates
+%{_datadir}/pipewire/pipewire.conf.d/10-rates.conf
+
+%files config-upmix
+%{_datadir}/pipewire/pipewire.conf.d/20-upmix.conf
+%{_datadir}/pipewire/client.conf.d/20-upmix.conf
+%if %{with pulse}
+%{_datadir}/pipewire/pipewire-pulse.conf.d/20-upmix.conf
+%endif
+
%files config-raop
%{_datadir}/pipewire/pipewire.conf.d/50-raop.conf
%endif
%changelog
+* Wed Sep 16 2026 Davide Cavalca <dcavalca@fedoraproject.org> - 1.4.11-2.1.1
+- Merge upstream changes for pipewire-epel
+
+* Mon Sep 07 2026 RHEL Packaging Agent <redhat-ymir-agent@redhat.com> - 1.4.11-1.1.1
+- Fix unbounded memory allocation and NULL pointer dereference in
+ RAOP RTSP client (CVE-2026-14324)
+ Resolves: RHEL-249296
+
+* Thu Aug 27 2026 RHEL Packaging Agent <redhat-ymir-agent@redhat.com> - 1.4.11-1.1
+- Fix stack exhaustion via unbounded alloca in pulse-server
+ Resolves: RHEL-249319
+
* Mon Jun 15 2026 Davide Cavalca <dcavalca@fedoraproject.org> - 1.4.11-2
- Merge upstream changes for pipewire-epel
next reply other threads:[~2026-09-16 21:31 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-16 21:31 Davide Cavalca [this message]
-- strict thread matches above, loose matches on Subject: below --
2026-06-15 11:01 [rpms/pipewire-epel] epel10: Merge upstream changes for pipewire-epel Davide Cavalca
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=178959431543.1.12607259189641431211.rpms-pipewire-epel-8aa0f3d0199b@fedoraproject.org \
--to=dcavalca@fedoraproject.org \
--cc=git-commits@fedoraproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox