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
 

             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